Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
スプリントバーンダウンチャート虎の巻 #scrumdo
Search
Ryutaro YOSHIBA
April 13, 2012
Technology
1
500
スプリントバーンダウンチャート虎の巻 #scrumdo
スクラム道でしゃべったスプリントバーンダウンに関する資料。
質問は@ryuzeeか
http://www.ryuzee.com/
まで
Ryutaro YOSHIBA
April 13, 2012
Tweet
Share
More Decks by Ryutaro YOSHIBA
See All by Ryutaro YOSHIBA
Vagrant (+Amazon EC2)
ryuzee
16
6.3k
CakePHP+Jenkinsによるアジャイル開発 #phpmatsuri
ryuzee
34
15k
自動テストvs手動テスト
ryuzee
1
2k
Agileってなんだっけ?
ryuzee
2
160
20110127_devloveテストの話.pdf
ryuzee
0
120
Doneの定義虎の巻
ryuzee
2
2.7k
アジャイルコーチで学んだ30+αのこと
ryuzee
2
230
Agile Japan '12 Agileな開発からAgileな組織へ
ryuzee
3
400
ワンクリックデプロイ101
ryuzee
2
330
Other Decks in Technology
See All in Technology
Riverpod & Riverpod Generatorを利用して状態管理部分の処理を書き換えてみる簡単な事例紹介
fumiyasac0921
0
100
年末調整プロダクトの内部品質改善活動について
kaomi_wombat
0
200
30代エンジニアが考える、エンジニア生存戦略~~セキュリティを添えて~~
masakiokuda
4
2k
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
20k
移行できそうでやりきれなかった 10年超えのシステムを葬るための戦略
ryu955
2
240
Why Go?
xpmatteo
0
130
DevinはクラウドエンジニアAIになれるのか!? 実践的なガードレール設計/devin-can-become-a-cloud-engineer-ai-practical-guardrail-design
tomoki10
3
1.3k
ソフトウェア開発におけるインターフェイスという考え方 / PHPerKaigi 2025
k1low
9
3.9k
Go の analysis パッケージで自作するリファクタリングツール
kworkdev
PRO
1
410
Dapr For Java Developers SouJava 25
salaboy
1
130
チームの性質によって変わる ADR との向き合い方と、生成 AI 時代のこれから / How to deal with ADR depends on the characteristics of the team
mh4gf
4
330
SaaSプロダクト開発におけるバグの早期検出のためのAcceptance testの取り組み
kworkdev
PRO
0
420
Featured
See All Featured
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
GraphQLの誤解/rethinking-graphql
sonatard
70
10k
Product Roadmaps are Hard
iamctodd
PRO
52
11k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
How STYLIGHT went responsive
nonsquared
99
5.4k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
177
52k
Git: the NoSQL Database
bkeepers
PRO
429
65k
Speed Design
sergeychernyshev
28
860
Building Your Own Lightsaber
phodgson
104
6.3k
Making Projects Easy
brettharned
116
6.1k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Transcript
スプリント バーンダウンチャート ⻁虎の巻 2010/12/22 スクラム道.02 #scrumdo Ryutaro “Ryuzee” YOSHIBA
http://www.flickr.com/photos/27682549@N06/
⾃自⼰己紹介 Ryuzee
@ryuzee http://www.ryuzee.com/ http://www.flickr.com/photos/adforce1/2539903964/
アジャイルコーチ 認定スクラムマスター オープンソース開発者、翻訳者 Shibuya.trac(#shibutra)のスタッフ スクラム道(#scrumdo)のスタッフ TIS,野村総合研究所を経てベンチャーのCTO http://www.flickr.com/photos/royskeane/413103429/
告知 CSPO 2011/1/11,12に認定ス クラムプロダクトオー ナー研修開催! 講師はジェフ・サザー ランド⽒氏! みんなでCSP 国内のスクラム熟練者 みんなで認定スクラム
プロフェッショナル資 格とろうよ計画あり! http://www.flickr.com/photos/epha/4388625060/
はじめに • この資料料内では、「バーンダウン」はスプリ ントバーンダウンを指します。 • 対象となるチームはアジャイル開発の経験が 多くはないチームや外圧が多いチームです。 • ソフトウェア開発はコンテキスト依存性が⾼高 いので、この資料料の中の項⽬目を単純にあては
めないでください。考えるヒントとして扱う こと。 http://www.flickr.com/photos/hckyso/2828981813/
バーンダウンとは何か 復復習! http://www.flickr.com/photos/frinthy/4680321558/
スプリント計画会議 スプリント優先付け • プロダクトバックログを分析・評価 する • スプリントのゴールを選択する スプリント計画 • どのようにスプリントゴールを達成す
るか決める (計画) • プロダクトバックログアイテム(ユー ザーストーリーやフィーチャー)から スプリントバックログの作成 (タスク) • スプリントバックログを時間で⾒見見積る スプリン トゴール スプリン トバック ログ ビジネス の状況 チームの キャパシ ティ プロダク トバック ログ 技術要素 現在のプ ロダクト スプリント計画 マイクコーン⽒氏のAn overview of Scrum (⽇日本語訳@ryuzee)より引⽤用 ※スプリント計画会議は通常2部構成で⾏行行う
スプリントバックログ① • プロダクトバックログアイテムをタスクに細 分化する • タスクは時間単位でチームで⾒見見積もる • 1タスクの最⼤大時間は8時間までとする(=⼤大 きくなればなるほど⾒見見積もり精度度は下がる) •
このタスクを⼀一覧化したものがスプリント バックログ
バーンダウンチャート http://www.flickr.com/photos/kakutani/2761992149/
バーンダウンチャート • 全タスクの残り時間の⾒見見積もりの合計を⽇日次 で折れ線グラフにしたもの • 縦軸に残り時間、横軸に経過スプリント⽇日数 を設定 http://www.flickr.com/photos/96dpi/2377535637/
バーンダウンから分かること • チームの計画づくりがどのくらいうまくいっ ているか • スプリント内で対応するストーリーにどのく らい対応できているか • チームが⾃自⼰己組織化されていて、チームとし て活動できているか
• チームとして改善できることは何か
パターンリーディング バーンダウン http://www.flickr.com/photos/nolifebeforecoffee/124659356/
基本3パターン http://www.practiceagile.com/2010/02/sprint-‐‑‒burndown-‐‑‒says-‐‑‒lot-‐‑‒about-‐‑‒your.html
Line1 ⻘青⾊色のラインから何を考える? http://www.practiceagile.com/2010/02/sprint-‐‑‒burndown-‐‑‒says-‐‑‒lot-‐‑‒about-‐‑‒your.html
Line1パターンの考察 • 多くのストーリーを実装しようとしすぎた • 開始してから分からないことが沢⼭山でてきた • コードの品質が悪くてバグが沢⼭山出た • 技術的負債が増えてしまったために追加タス クが増えた
• 過去のスプリントがずっとこのパターンなら チームのキャパシティはもっと低い
Line2 紫⾊色のラインから何を考える? http://www.practiceagile.com/2010/02/sprint-‐‑‒burndown-‐‑‒says-‐‑‒lot-‐‑‒about-‐‑‒your.html
Line2パターンの考察 • 理理想線とは乖離離しており、スプリント最後に 追い込みしている • チームが正しく毎⽇日タスク残時間を更更新して いない可能性 • 終っていないストーリーを他のスプリントに 移動した可能性
• リファクタリングやテストで⼿手を抜いた可能 性
Line3 緑⾊色のラインから何を考える? http://www.practiceagile.com/2010/02/sprint-‐‑‒burndown-‐‑‒says-‐‑‒lot-‐‑‒about-‐‑‒your.html
Line3パターンの背景と考察 • チャートだけならうまく⾏行行っている • 実際にうまく⾏行行っていることも多い • ただしLine2パターンの内容が含まれている 可能性は否定できない • 特に外部からバーンダウンの残時間0が強く
要求されてしまう環境は注意
ソフトウェアの複雑性 • 通常、スプリント計画ミーティングでは、ス プリントバックログの60〜~70%しか出て来 ないことが多い。残りはあとで対応する。あ るいは、とりあえず⼤大きな⾒見見積もりをしてお いて、あとで分解する。 • 従ってスプリント開始からしばらくの間は残 時間が減らない、もしくは増えてしまうとい
う事象は必ず発⽣生するし、⾃自然なことである。
早期学習パターン スプリント早期に残り時間が増えている。⾒見見積もり切切れなかった 項⽬目の存在や⾒見見積もり精度度の問題が顕在化。早期なら健全
学習遅延パターン(1) 中期まで残り時間が増え続ける。早期に学習できなかった可能性 や、優先度度やリスクの⾼高い項⽬目に早期着⼿手しなかった可能性
学習遅延パターン(2) スプリント失敗パターン。このような線が最後まで継続しないよ うに中期の段階で対応が必要だったのにそれを怠った可能性。
異異常検知 スプリント中盤で残り時間の⾒見見積もりが急激に増えている。重⼤大 な⾒見見落落としや、外部からの変更更要求を受け⼊入れた可能性
新たな指標の追加 http://www.flickr.com/photos/ljpixie75/374728063/
指標追加の意義とポイント • バーンダウンだけでは分からないことを即時 把握することができるようにする • バーンダウンから想定した問題点の裏裏付けに 使う • データ収集の⾃自動化は必要 – そもそもデータが集められないのであれば、その
点はプロセス改善のポイントである。 • どんな指標を使うかという問には正解はない
追加する指標 • ソースコード⾏行行数 • ユニットテスト件数 • ⾃自動結合テスト件数 • ビルド失敗数 •
コミット回数・時間 • 完了了分ストーリーポイント • 完了了済みタスク数 • 割り込み作業数や延べ時間
ソースコード⾏行行数を追加 ソースコードが線形に増加していることから、コピーペーストに よる間に合わせや、リファクタリングがされていない可能性
ユニットテスト件数を追加 テストの件数がスプリント後半で増えていない。残時間を0にす るためにテストを端折った可能性も。
コミット時間を追加 最終コミット時間がスプリント後半になるにつれて遅くなってい る。持続可能なペースでない
完了了分ストーリーポイントを追加 ストーリー単位での完了了がなかなかしていない。まとめて◯◯病。 最終的にどのストーリーも完了了しないリスクがあるかも。
割り込み作業時間を追加 割り込み作業時間と残作業時間の関連性を検証。割り込みが⼀一定 量量ある場合はキャパシティプランニングの⾒見見直しが必要
その他の活⽤用⽅方法 http://www.flickr.com/photos/jnicho02/2635228821/
Retrospectiveに活⽤用する バーンダウン上に、スプリント内で発⽣生したイベント等をプロッ トし、改善点がないか確認する。 11/19にマイクが病 気で休んじゃったよ
複数スプリント間で分析する • 発⽣生している問題が⼀一過性の問題なのか、 チームの問題なのかを明らかにする。 • 複数スプリントのバーンダウンを並べて⽐比較 する。 • 特に問題とすべきは、以下の項⽬目 – 毎回0に収束していない
– スプリント開始後⼀一定期間たっても残り時間が増 加し続けている – 後半追い込み癖 – まとめて◯◯癖
アンチパターン バーンダウン http://www.flickr.com/photos/rizzato/2663036655/
バーンダウンアンチパターン • バーンダウンだけを⾒見見て全てを判断する • →現場百編。数値だけでなくチームの雰囲気 やメンバーの顔⾊色を⾒見見る http://www.flickr.com/photos/pooniesphotos/4249354280/
バーンダウンアンチパターン • 0に収束させることだけに拘る • →本質的な問題の把握と解決なしに闇雲に0 にすることを求めるとチームが燃え尽きる http://www.flickr.com/photos/thetruthabout/2665403018/
バーンダウンアンチパターン • バーンダウンの結果を⼈人事考課に使う • →評価されることしかしなくなったり、タス クの⾒見見積もり時間を過⼤大に設定しやすくなる。 http://www.flickr.com/photos/ninefish/176563515/
バーンダウンアンチパターン • DONEの定義を決めていない • →作業完了了の基準が⼈人によって異異なるため作 業時間の⾒見見積もりの意味をなさない
バーンダウンアンチパターン • タスクの⾒見見積もりを誰かが1⼈人で⾏行行う • →この時点でアジャイルのメリットをほとん ど捨ててしまっている。 http://www.flickr.com/photos/juank_̲madrigal/3184407841/
バーンダウンアンチパターン • スプリントバックログとバーンダウンが⾒見見え ない場所においてある • →チーム全体で仕事を進める上での⽣生命線な ので常時閲覧可能にすること。 http://www.flickr.com/photos/chongchiang/3112794771/
バーンダウンアンチパターン • スプリントバックログに載っていないタスク が⼀一杯ある http://www.flickr.com/photos/miskan/7240060/
バーンダウンアンチパターン • バーンダウンに理理想線が引かれていない、も しくは理理想線がチームのキャパシティを超え ている http://www.flickr.com/photos/hwat/43562167/
バーンダウンアンチパターン • 複数スプリントを経た後でもバーンダウンが 乱⾼高下する • →過去のスプリントの経験がチームに蓄積さ れておらず、改善する意欲がチームに⾜足りな いか、外圧を受けている http://www.flickr.com/photos/wazdog/1669981/
http://www.flickr.com/photos/oberazzi/318947873/