見出し画像

【メモ】正しいものを正しくつくる 本読み会 第2回

アジャイル開発とは

早く(ただし少しだけ)形を作る。
アジャイル開発は、プロダクトを必要とする人と、作り手の間での利害と想いが一致するやり方であり、あり方だ。

スクラムはフレームワーク

スクラムはプロセスのフレームワークであり、開発プロセスのそのものではない。そもそもソフトウェア開発限定のものではない。現在では様々なシーンで利用されている。

あくまでも「入れ物」であり、その中に様々なプラクティスなどを入れることによって現場にあったプロセスとなる。うーん。奥が深いですね。

スクラムは経験主義に基づいている

自分達で経験を積み重ねていく必要がある。チームの練度に合わせて徐々に段階的に変わっていく。

スクラムは軽量である?

今回、1番の勉強になったポイントでした。

スクラムとは以下のようなものである。
軽量
• 理解が容易
• 習得は困難

スクラムガイドに記載されている「軽量」について、以前チームメンバーとともに読み合わせをしたことがあった。その際に「18ページもあるのに軽量ってどういうことですか?とても軽量とは思えません・・・」というコメントをいただいた。

当時、回答できず困った。

今回の勉強会でそれが分かってとてもすっきりした。

軽量とはドキュメントのページ数ではない。歴史的背景がある。

1990年代〜2000年代後半まで要件定義隆盛の時代があったそうだ。(要件定義大事だよねとなってきていた。)

要件定義によって、「何を作ればいいのか確実にはっきりさせる。」

事前にあらゆる事項を考慮していくわけだから、要件定義が重量級になる。結果的に重たい開発になる。

当時?ラショナル社がUnified Processというものを作ったそうだ。RUPがまとめるときにUMLが出てきたらしい。

Unified Software Development Process もしくはUnified Processは一般的な反復型ソフトウェア開発工程フレームワークである. もっともよく知られていて、広範囲にドキュメント化された洗練されたUnified Process はラショナル統一プロセス (RUP)である
https://ja.wikipedia.org/wiki/Unified_Process

その重たくなる開発プロセスを変えようという流れがXP。

当時は、こんなので本当につくれるの?!と著者は思ったらしい

ちなみに最近盛り上がってきているRADRAはいい感じらしい。

ユーザーストーリーは要求

要求・要件・仕様の要求。

ユーザーストーリーは要求にあたる。
ユーザーストーリーは以下のようなものです。

ユーザーとして、XXXしたい。なぜならYYYだからだ。

ところで、ユーザーストーリーだけで作っていけるチームはかなり練度が高いそうだ。

現職では、ユーザーストーリーを起点にして対話でリファインメントをしている。結果として受入条件やらデモ手順、制約など様々な事項について話し合われて、プロダクトバックログアイテムに追記されていく。

このやり方で機能するようになったのはつい数ヶ月前のこと。それまでは、事前にPOが上記の内容を事前に記載していた上で、詳細の振る舞いやデザインについて話し合われていたが、最近は開発チームにより一任してくれる領域が増えてきた。

ちなみに、これよりも前はPOが仕様レベルをガッツリ書いていた時期もあった。

時間を経て徐々に軽量化してきている。

スプリント期間

最近2週間スプリントが増えてきたらしい。
間違えている期間をなるべく短くするために、1週間スプリントがお勧め。

プロダクトバックログの粒度

プロダクトバックログがどういった解像度か、スクラムガイドに具体的に書かれていない。

みんなの悩みどころ。現職のチームでもスクラムガイドを読み合わせした際に同様のコメントが出ていたことを思い出した。

チームの置かれた状況によって異なる。
チームの練度が低い時は硬めにしていく。受入条件をしっかりめにつくっておく。
ウォータースクラムフォールは段階の中ではありうる。

チームの練度などによって異なるし、置かれている状況によっても異なるわけだ。つまり、他のチームでうまくいった方法をそのまま持ってきて導入しようとしてもうまくいくとは限らない。むしろ混乱する可能性すらある。

フィードバックを取り入れる余地がない開発

なんのために反復的な開発を行っているのか。

早く開発するためだ。

フィードバックを取り入れる余地がないなら反復的に開発する意味はあるのだろうか
予算・期間的にギチギチになっていると、フィードバックによる改善ができない。

スプリントに余白を持たせる

ギチギチにしたら、アジャイル開発をする意味がなくなる。

思い当たる節があって胸が痛かった。リリースまでに期日が決められてしまっている状況ではフィードバックがあっても反映できない。

何度がこういう状況は目にしてきた。現職の現場では期間バッファを持たせることがになっており、バッファを組み込みにくい環境が作り出されている。バッファが何日あるとは口が裂けても言えないのだ。

どうにかしたい。

この記事が気に入ったらサポートをしてみませんか?