はじめに
- 別にこうすべきとかじゃない。
- あくまでサンプルというか考え方みたいな話。
アジャイルな進捗管理とは
進捗として評価するもの
「動くもので進捗を評価する」ってのがよく言われています。
もう少し噛み砕きます。
- 必要なテストやレビューなどが行われその指摘対応も含めて完了している状態である
- デプロイされて動く状態である
その理由
- 顧客からすれば中間成果物の状態は何も進捗していないので最終成果物まで至ってようやく進捗を評価すべき
- 設計しただけではそもそも動くかどうか不明
- 完了の基準をずらさない
- 完了の定義が複数あると進捗評価を間違えることがある（担当の作業完了と、レビュー完了を誤解するなど
- 別の完了の定義と誤解した、などの言い訳を潰す
ウォーターフォールとの違い
「書き上がった設計書の数」（システム開発としての中間成果物）を進捗指標としてはあまり扱わない。
なお、保守のために必要なドキュメントの作成などは、進捗指標として取り扱っても良いと思う。
少なくとも、設計工程が終わったことを評価するためだけに設計書をカウントすることはなくなる。
進捗の立ち位置
スピードの測定
「スプリントと呼ばれる固定化された一定期間内でどれくらいの作業量をこなせるかを見極める」というのが立ち位置になります。
スプリントというメタファーに合わせるなら「走るスピード」を測定するイメージです。
測定したスピードの使い方
このスピードを元に計画を立てます。
スピードが先で、計画が後。
スピードに応じて計画を見直していくことになります。
ウォーターフォールとの違い
多くの場合計画を優先して、スピードをどうにかしようとします。
が、多くの場合作業効率は上がらないし、残業でカバーみたいなケースが多いんじゃないでしょうか。
アジャイルの文脈では、現場に負担を強いて作業を行わせても、品質が悪化するため、最終的なスピード向上には至らないとされています。
なので、スピードはそう劇的には変わらないという前提で計画を立てるというスタンスになります。
注意事項
なお、走るスピードを上げていくことは求められ続けます。
劇的に変わることは少ないかもしれませんが、一定で居続けて良い理由はありません。
調整弁をどこに持つか
『そうは言っても「mm/ddまでにxxxを実装しないといけない」という要求にどう答えるのか？』というのがあるかと思います。
アジャイルでは主に「納期」もしくは「スコープ」を調整弁に持ちます。
納期
シンプルにmm/dd予定を、mm+2/ddに変更するなど。
スコープ
「xxx」が必須なのであれば、「yyy」は落とすなど。
もしくは「xxx」が実現する要件を10個から5個に落とすなど。
調整できない
ツラい。
先の見通しが硬いのであれば、ここで悩むケースは少ないでしょうが、アジャイルを選択している以上、先の見通しがあまり立たないのかと思っています。
いざこの事態に見舞われてから調整しようとしても、かなり無理なので、事前に調整する必要があります。
そのためにPJ開始前に 納期ないしはスコープを調整する権限を持っている人を含めた状態で 「トレードオフスライダー」を会話しておくのが良いかと思います。
ここで揉めるだけ揉めておくしかない。
ここで収束できない・納得が得られないならアジャイルは始めないほうが良い。
受託開発の場合は、受託した場合のリスクが高すぎる。
それでもアジャイルじゃないと行けない
もう最終手段は「めっちゃバッファ持つ」しかない。
他に良いアイデアは思いつかない・・・
PJ終了時点で結局誰かしらには怒られる気がするので、もし自分が担当だと割と絶望してるかもしれん。
まとめ
- 進捗として評価するものは「動くもの」
- 「走るスピード」をインプットにして、「計画」を立てる。（逆ではない）
- 調整弁を「納期」もしくは「スコープ」で持つ（両方が望ましい）
次回予告
本記事は、2022アドベントカレンダー「受託アジャイル」の記事です！他にも興味あれば見てってください。
次回は、アジャイルな品質の考え方です。