見積りとかアジャイル開発、スクラムについて諸々調べたので、その雑多なメモ。
見積もりについて
見積もり自体について調べたのでメモる。
ボトムアップ見積もり
作業を分解して構成要素ごとの工数を見積もって積み上げる方法らしい。
見積もりにかなり時間がかかるのがデメリットで、見積もりの精度の高さがメリット。しかし、初期フェーズだと不確実性コーンの通り、見積もり精度は低くなりがち。
不確実性が比較的低くなってくる、中期・後期のフェーズにより精密な見積もりのため導入するのが吉っぽい。
アフィニティ見積もり
作業を相対的なポイントで見積もる方法らしい。ポイント付けは、プランニングポーカーとかやる感じ。
仕様の細かいケースまで考慮した見積もりではなく、開発要件をある程度の粒度でまとめて、規模を算出する方法であり、プロジェクト全体の作業の完了目途を出すのに向いている。
初期フェーズでの見積もりに向いている。
見積もりの精度は下がるので、それを踏まえた上でバッファを確保しておくと吉。ちなみに、開発要件をMustとWantに分けておくと、スケジュールが押してきた時に助かる。
ちなみに、この見積もりについては、プロジェクトの進め方の手法に関係なく役立ちそう。
プロジェクトマネジメントの手法にはウォーターフォールやアジャイルのようないろいろな手法がありますが、どんな手法でも計画の遅延につながるリスクに対応しようという考え方は共通です。
この記事を参考にした。
記事内では、数百名規模のチームで、プロジェクト開始からリリースまで数年かかるような大規模プロジェクトを想定しているそう。しかし、数人のチームで数ヶ月で新機能を作る場合でも最初はアフィニティ見積り、途中でボトムアップ見積もりを行うのは、アリな気がした。
スクラムを行なっている場合は、バックログリファインメントがいわゆるアフィニティ見積りで、スプリントプランニングがボトムアップ見積もりになって自然と良い感じになりそう。
スクラム
スクラムにはいくつかのイベントがあるが、とくにバックログリファインメントとスプリントプランニングについてメモる。
とくに、初心者スクラムチームが陥っていた間違ったスクラムの見積もり方法とそれに対するカイゼンを参照している。
バックログリファインメント
SPでざっくりPBIを見積もって、その規模感と顧客価値を元にPOが優先度判断をする
-
PBI（プロダクトバックログアイテム）は、プロダクトの価値を向上させるためのユーザーストーリであり、プロダクトオーナーがチケットを切る。
-
やること単位（Aのフロントエンドの実装をする等）でチケット（PBI）を切るのはNG
- 作業レイヤーで上記のようにチケットを切るのはウォーターフォール的らしい
スプリントプランニング
スプリント期間中にやりきりたいこと（PBI）を作業単位にして見積り、本当にスプリントに収まるか計画するイベント。
スクラムガイドによると、PBIを1日以内の小さな作業アイテムに分けるべしと言っているが、細かな分け方は開発者の裁量としている。
開発者は、選択したプロダクトバックログアイテムごとに、完成の定義を満たすインクリメントを作成するために必要な作業を計画する。これは多くの場合、プロダクトバックログアイテムを1⽇以内の⼩さな作業アイテムに分解することによって⾏われる。これをどのように⾏うかは、開発者だけの裁量とする。プロダクトバックログアイテムを価値のインクリメントに変換する⽅法は誰も教えてくれない。
開発者としては、バックログリファインメントでは以下に貢献する必要がありそう。
- PBIの適切な見積り
- ストーリーポイントが大きすぎたら適切な単位にPBIを分割すること
また、スプリントプランニングにおける、以下3つにはとくに開発者として責任を負うべしな気がする。（追記：というか、スクラムガイドにも書いていた。）
- 作業アイテムへの切り出し
- 作業アイテムの見積り
- 成果物に対する責任
作業アイテムへの切り出し
先ほど、作業アイテムへの切り出しは開発者が裁量を持つとあったが、とはいえ何か指針が欲しい。
以下2つの記事を読んでみた。
まずチーム全員でタスクを切ることが大事らしい。
個々人が自分の担当するタスクを切る、あるいは事前に誰かが仮でタスクを切っておくと、効率良いのではと思っていた。確かにこうすることでMTGの時間は削減するかもしれないが、スプリント内でチームで最高の成果物を作れるかというとダメそうだ。
また、作業アイテムは誰が読んでも完了条件が明確であるように、タスクが完了したときの状態を明らかにするような言葉で書くと良さそう。
たとえば、「画面を実装する」ではなく、「ユーザーが商品の数量を選べるようにする」「ユーザーが商品の色を選べるようにする」と書く感じ。
アンチパターンの例。
- スプリントプランニングのときにはすでに誰かが詳細化・分割したタスクが存在している（ときには何故か作業時間の見積りが入っていることすらある）
- プロダクトバックログアイテムがすでにタスクになっている
- テックリードや技術的に優秀な人が、スプリントプランニングのときに「みんなのため」（と称して）タスクを分解してあげる
- スプリントプランニングのときにプロダクトバックログが個人にアサインされ、担当する個々人がタスクに分解する
ストーリーポイント
ストーリーポイントやら、ベロシティやらは、スクラムガイドには定義されていないので、ルールではなく実装の1つ。使うも使わないも自由。
この記事がとても分かりやすかった。
記事によるとストーリーポイントは以下のようなもの。
ストーリーポイントとは対象の規模や大きさを表す相対的な数値であり、複雑さやリスクを踏まえたものである
スクラムに限らず、たとえばウォーターフォール開発でアフィニティ見積もりをする時に使っても良いはず。
そして、ベロシティは1つのスプリントのなかで完成したプロダクトバックログアイテムのストーリーポイントを合計したもの。 提供したい機能の総ポイント数をベロシティで割ると、プロジェクトの完了にどのくらいの期間が必要か予想することができるので便利。
ストーリーポイント vs 理想日
見積もりの基礎知識と「ストーリーポイント vs 理想日」の考察について読んだのでメモ。
規模の見積りのために理想日というのが使われることもある。理想日は「その機能の開発だけに取り組んだとしてかかる日数」のこと。 説明コストが低い（誰でもパッと理解できる）のがメリットの1つだが、デメリットは多いらしい。
「アジャイルな見積もりと計画」8章によれば、理想日には次のようなデメリットがあるとされています。
- 議論が職能別の詳細に入り込んでしまいチームとしての働き方を阻害する
- メンバーの能力が向上するにつれて見積もりが変化し、ベロシティが信頼できなくなる
- 理想日を現実時間と比べてしまって規模の見積もりができない
- 具体的な作業による見積もりになり、見積もり自体に時間がかかる傾向がある
- 人によって理想日は違う
ストーリーポイントを使うにしても、理想日を使うにしても「期間ではなく規模を見積もること」には変わりはない。これすごく大事。
記事によると、理想日のデメリットを解消できるような以下の状態であれば、理想日を使うのもありかもとのこと。
- ロールが細分化されておらず、全員がDBからフロントエンドまで一気通貫で作業すること
- 継続的にベロシティを計測する必要のない、ウォーターフォール的な開発であること
- 能力が似ている人が集まっているチームであること
スクラムが上手くいかない
スクラムが上手くいかない（適さない）事例も読んでおきたいなと思ったので、「こうしてスクラムが終わってしまう」前にすべきことを読んでみる。
たとえば以下のような状態のスクラムチーム。
- 開発チームがユーザーと直接話をする機会はない
- スプリント期間より長期の計画をたてることはできない（代わりに開発計画とかマイルストーンとかロードマップがある）
このような状態のスクラムチームは以下のように表されていた。なかなか厳しい..
古典的なウォーターフォール脳に基づいて動く「ガワだけアジャイル」となり、そして大規模組織と古典的なウォーターフォールがもたらす弊害と闘病する
具体的にどういうところが本来のスクラムと異なるのかメモ。
上位計画を与えられ、それを遂行するチームの場合、本来のスプリントゴールは立てられない。代わりに「スプリントゴールと呼ばれる進捗目標」をスクラムチームは目標とせざるを得ない。
今進んでいる方向を維持するか、あるいはやめるかを判断する重要な指標であるフィードバックも得られない。固定的な上位計画がある場合は、フィードバックとして得られるものは「現在計画より進捗がどれだけ遅れているか？」だけになる。
段階的にリリースと修正をし、ユーザーと対話しながら探索的にプロダクトを作り上げていくために必須のリリースゴールもない。計画が固定で決まっているので、細かくリリースしようが最後の段階で一気にまとめてリリースしようが大きな違いがないため。
会社として、中間組織に権限移譲して自律的に動く開発組織にしたい場合はスクラムが本領を発揮するが、それ以外の場合では悲しいことになりそうだというのは分かった。
権限移譲してもらった場合は、プロダクトオーナーとスクラムマスターを中心に頑張るって感じだな〜。