スプリントバーンダウンチャート虎の巻 #scrumdo

Transcript

1. スプリント バーンダウンチャート ⻁虎の巻 2010/12/22  スクラム道.02   #scrumdo Ryutaro  “Ryuzee”  YOSHIBA

   http://www.flickr.com/photos/27682549@N06/

2. ⾃自⼰己紹介  　 　 　 　 　 　 　 　 　 　  　  　 Ryuzee  　 　 　 　 　 　 　  　  　  　  　

    　 @ryuzee http://www.ryuzee.com/ http://www.flickr.com/photos/adforce1/2539903964/

3. アジャイルコーチ 認定スクラムマスター オープンソース開発者、翻訳者 Shibuya.trac(#shibutra)のスタッフ スクラム道(#scrumdo)のスタッフ TIS,野村総合研究所を経てベンチャーのCTO http://www.flickr.com/photos/royskeane/413103429/

4. 告知 CSPO 2011/1/11,12に認定ス クラムプロダクトオー ナー研修開催！ 講師はジェフ・サザー ランド⽒氏！ みんなでCSP 国内のスクラム熟練者 みんなで認定スクラム

   プロフェッショナル資 格とろうよ計画あり！ http://www.flickr.com/photos/epha/4388625060/

5. はじめに •  この資料料内では、「バーンダウン」はスプリ ントバーンダウンを指します。 •  対象となるチームはアジャイル開発の経験が 多くはないチームや外圧が多いチームです。 •  ソフトウェア開発はコンテキスト依存性が⾼高 いので、この資料料の中の項⽬目を単純にあては

   めないでください。考えるヒントとして扱う こと。 http://www.flickr.com/photos/hckyso/2828981813/

6. バーンダウンとは何か 復復習！ http://www.flickr.com/photos/frinthy/4680321558/

7. スプリント計画会議 スプリント優先付け •  プロダクトバックログを分析・評価 する •  スプリントのゴールを選択する スプリント計画 •  どのようにスプリントゴールを達成す

   るか決める  (計画) •  プロダクトバックログアイテム(ユー ザーストーリーやフィーチャー)から スプリントバックログの作成  (タスク) •  スプリントバックログを時間で⾒見見積る スプリン トゴール スプリン トバック ログ ビジネス の状況 チームの キャパシ ティ プロダク トバック ログ 技術要素 現在のプ ロダクト スプリント計画 マイクコーン⽒氏のAn  overview  of  Scrum  (⽇日本語訳@ryuzee)より引⽤用 ※スプリント計画会議は通常２部構成で⾏行行う

8. スプリントバックログ① •  プロダクトバックログアイテムをタスクに細 分化する •  タスクは時間単位でチームで⾒見見積もる •  1タスクの最⼤大時間は8時間までとする(=⼤大 きくなればなるほど⾒見見積もり精度度は下がる) • 

   このタスクを⼀一覧化したものがスプリント バックログ

9. バーンダウンチャート http://www.flickr.com/photos/kakutani/2761992149/

10. バーンダウンチャート •  全タスクの残り時間の⾒見見積もりの合計を⽇日次 で折れ線グラフにしたもの •  縦軸に残り時間、横軸に経過スプリント⽇日数 を設定 http://www.flickr.com/photos/96dpi/2377535637/

11. バーンダウンから分かること •  チームの計画づくりがどのくらいうまくいっ ているか •  スプリント内で対応するストーリーにどのく らい対応できているか •  チームが⾃自⼰己組織化されていて、チームとし て活動できているか

    •  チームとして改善できることは何か

12. パターンリーディング バーンダウン http://www.flickr.com/photos/nolifebeforecoffee/124659356/

13. 基本３パターン http://www.practiceagile.com/2010/02/sprint-‐‑‒burndown-‐‑‒says-‐‑‒lot-‐‑‒about-‐‑‒your.html

14. Line1  ⻘青⾊色のラインから何を考える？ http://www.practiceagile.com/2010/02/sprint-‐‑‒burndown-‐‑‒says-‐‑‒lot-‐‑‒about-‐‑‒your.html

15. Line1パターンの考察 •  多くのストーリーを実装しようとしすぎた •  開始してから分からないことが沢⼭山でてきた •  コードの品質が悪くてバグが沢⼭山出た •  技術的負債が増えてしまったために追加タス クが増えた

    •  過去のスプリントがずっとこのパターンなら チームのキャパシティはもっと低い

16. Line2  紫⾊色のラインから何を考える？ http://www.practiceagile.com/2010/02/sprint-‐‑‒burndown-‐‑‒says-‐‑‒lot-‐‑‒about-‐‑‒your.html

17. Line2パターンの考察 •  理理想線とは乖離離しており、スプリント最後に 追い込みしている •  チームが正しく毎⽇日タスク残時間を更更新して いない可能性 •  終っていないストーリーを他のスプリントに 移動した可能性

    •  リファクタリングやテストで⼿手を抜いた可能 性

18. Line3  緑⾊色のラインから何を考える？ http://www.practiceagile.com/2010/02/sprint-‐‑‒burndown-‐‑‒says-‐‑‒lot-‐‑‒about-‐‑‒your.html

19. Line3パターンの背景と考察 •  チャートだけならうまく⾏行行っている •  実際にうまく⾏行行っていることも多い •  ただしLine2パターンの内容が含まれている 可能性は否定できない •  特に外部からバーンダウンの残時間０が強く

    要求されてしまう環境は注意

20. ソフトウェアの複雑性 •  通常、スプリント計画ミーティングでは、ス プリントバックログの60〜～70%しか出て来 ないことが多い。残りはあとで対応する。あ るいは、とりあえず⼤大きな⾒見見積もりをしてお いて、あとで分解する。 •  従ってスプリント開始からしばらくの間は残 時間が減らない、もしくは増えてしまうとい

    う事象は必ず発⽣生するし、⾃自然なことである。

21. 早期学習パターン スプリント早期に残り時間が増えている。⾒見見積もり切切れなかった 項⽬目の存在や⾒見見積もり精度度の問題が顕在化。早期なら健全

22. 学習遅延パターン(1) 中期まで残り時間が増え続ける。早期に学習できなかった可能性 や、優先度度やリスクの⾼高い項⽬目に早期着⼿手しなかった可能性

23. 学習遅延パターン(2) スプリント失敗パターン。このような線が最後まで継続しないよ うに中期の段階で対応が必要だったのにそれを怠った可能性。

24. 異異常検知 スプリント中盤で残り時間の⾒見見積もりが急激に増えている。重⼤大 な⾒見見落落としや、外部からの変更更要求を受け⼊入れた可能性

25. 新たな指標の追加 http://www.flickr.com/photos/ljpixie75/374728063/

26. 指標追加の意義とポイント •  バーンダウンだけでは分からないことを即時 把握することができるようにする •  バーンダウンから想定した問題点の裏裏付けに 使う •  データ収集の⾃自動化は必要 – そもそもデータが集められないのであれば、その

    点はプロセス改善のポイントである。 •  どんな指標を使うかという問には正解はない

27. 追加する指標 •  ソースコード⾏行行数 •  ユニットテスト件数 •  ⾃自動結合テスト件数 •  ビルド失敗数 • 

    コミット回数・時間 •  完了了分ストーリーポイント •  完了了済みタスク数 •  割り込み作業数や延べ時間

28. ソースコード⾏行行数を追加 ソースコードが線形に増加していることから、コピーペーストに よる間に合わせや、リファクタリングがされていない可能性

29. ユニットテスト件数を追加 テストの件数がスプリント後半で増えていない。残時間を０にす るためにテストを端折った可能性も。

30. コミット時間を追加 最終コミット時間がスプリント後半になるにつれて遅くなってい る。持続可能なペースでない

31. 完了了分ストーリーポイントを追加 ストーリー単位での完了了がなかなかしていない。まとめて◯◯病。 最終的にどのストーリーも完了了しないリスクがあるかも。

32. 割り込み作業時間を追加 割り込み作業時間と残作業時間の関連性を検証。割り込みが⼀一定 量量ある場合はキャパシティプランニングの⾒見見直しが必要

33. その他の活⽤用⽅方法 http://www.flickr.com/photos/jnicho02/2635228821/

34. Retrospectiveに活⽤用する バーンダウン上に、スプリント内で発⽣生したイベント等をプロッ トし、改善点がないか確認する。 11/19にマイクが病 気で休んじゃったよ

35. 複数スプリント間で分析する •  発⽣生している問題が⼀一過性の問題なのか、 チームの問題なのかを明らかにする。 •  複数スプリントのバーンダウンを並べて⽐比較 する。 •  特に問題とすべきは、以下の項⽬目 – 毎回０に収束していない

    – スプリント開始後⼀一定期間たっても残り時間が増 加し続けている – 後半追い込み癖 – まとめて◯◯癖

36. アンチパターン バーンダウン http://www.flickr.com/photos/rizzato/2663036655/

37. バーンダウンアンチパターン •  バーンダウンだけを⾒見見て全てを判断する •  →現場百編。数値だけでなくチームの雰囲気 やメンバーの顔⾊色を⾒見見る http://www.flickr.com/photos/pooniesphotos/4249354280/

38. バーンダウンアンチパターン •  ０に収束させることだけに拘る •  →本質的な問題の把握と解決なしに闇雲に０ にすることを求めるとチームが燃え尽きる http://www.flickr.com/photos/thetruthabout/2665403018/

39. バーンダウンアンチパターン •  バーンダウンの結果を⼈人事考課に使う •  →評価されることしかしなくなったり、タス クの⾒見見積もり時間を過⼤大に設定しやすくなる。 http://www.flickr.com/photos/ninefish/176563515/

40. バーンダウンアンチパターン •  DONEの定義を決めていない •  →作業完了了の基準が⼈人によって異異なるため作 業時間の⾒見見積もりの意味をなさない

41. バーンダウンアンチパターン •  タスクの⾒見見積もりを誰かが１⼈人で⾏行行う •  →この時点でアジャイルのメリットをほとん ど捨ててしまっている。 http://www.flickr.com/photos/juank_̲madrigal/3184407841/

42. バーンダウンアンチパターン •  スプリントバックログとバーンダウンが⾒見見え ない場所においてある •  →チーム全体で仕事を進める上での⽣生命線な ので常時閲覧可能にすること。 http://www.flickr.com/photos/chongchiang/3112794771/

43. バーンダウンアンチパターン •  スプリントバックログに載っていないタスク が⼀一杯ある http://www.flickr.com/photos/miskan/7240060/

44. バーンダウンアンチパターン •  バーンダウンに理理想線が引かれていない、も しくは理理想線がチームのキャパシティを超え ている http://www.flickr.com/photos/hwat/43562167/

45. バーンダウンアンチパターン •  複数スプリントを経た後でもバーンダウンが 乱⾼高下する •  →過去のスプリントの経験がチームに蓄積さ れておらず、改善する意欲がチームに⾜足りな いか、外圧を受けている http://www.flickr.com/photos/wazdog/1669981/

46. http://www.flickr.com/photos/oberazzi/318947873/