$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
スプリントバーンダウンチャート虎の巻 #scrumdo
Search
Ryutaro YOSHIBA
April 13, 2012
Technology
1
450
スプリントバーンダウンチャート虎の巻 #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
14k
自動テストvs手動テスト
ryuzee
1
2k
Agileってなんだっけ?
ryuzee
2
160
20110127_devloveテストの話.pdf
ryuzee
0
120
Doneの定義虎の巻
ryuzee
2
2.6k
アジャイルコーチで学んだ30+αのこと
ryuzee
2
210
Agile Japan '12 Agileな開発からAgileな組織へ
ryuzee
3
400
ワンクリックデプロイ101
ryuzee
2
310
Other Decks in Technology
See All in Technology
乗っ取れKubernetes!!~リスクから学ぶKubernetesセキュリティの考え方~/k8s-risk-and-security
mochizuki875
3
430
EthernetベースのGPUクラスタ導入による学びと展望
lycorptech_jp
PRO
0
440
B11-SharePoint サイトのストレージ管理を考えよう
maekawa123
0
120
iOS 18 から追加された SwiftUI の傾向について調べてみる
swiftty
2
110
PFN Company Deck
pfn
PRO
2
140
Bytebaseで実現する データベース管理の効率化
shogo452
1
290
sre本読んだ感想
pisakun
0
160
リモートだからこそ 懸念だし1on1
jimpei
1
350
Kubernetes だけじゃない!Amazon ECS で実現するクラウドネイティブな GitHub Actions セルフホストランナー / CNDW2024
ponkio_o
PRO
6
420
Hyperledger Fabric(再)入門
gakumura
3
6.7k
Raspberry Pi 秋の新製品をチェックしてみよう / 20231202-rpi-jam-tokyo
akkiesoft
0
180
Yahoo! JAPANトップページにおけるマイクロフロントエンド - 大規模組織におけるFE開発を加速させるには
lycorptech_jp
PRO
0
1.7k
Featured
See All Featured
XXLCSS - How to scale CSS and keep your sanity
sugarenia
247
1.3M
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
400
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
The Cult of Friendly URLs
andyhume
78
6.1k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.8k
The Language of Interfaces
destraynor
154
24k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7k
Git: the NoSQL Database
bkeepers
PRO
427
64k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
42
9.3k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Become a Pro
speakerdeck
PRO
25
5k
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/