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

スプリントバーンダウンチャートの読み解き方・扱い方に関する資料です

Tidy First? ―個人で実践する経験主義的ソフトウェア設計
  • 著者／訳者：Kent Beck、 吉羽 龍太郎、 永瀬 美穂、 細澤 あゆみ
  • 出版社：オライリー・ジャパン
  • 発売日：2024-12-25
  • 単行本（ソフトカバー）：164ページ
  • ISBN-13：9784814400911
  • ASIN：4814400918
脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック
  • 著者／訳者：Mark Seemann、 吉羽 龍太郎、 原田 騎郎、 Robert C. Martin
  • 出版社：オライリー・ジャパン
  • 発売日：2024-06-18
  • 単行本（ソフトカバー）：312ページ
  • ISBN-13：9784814400799
  • ASIN：4814400799

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/

Comment

No comments...