バーンダウンチャートのパターン集
バーンダウンチャートを見れば、チームの進捗だけでなく、チームの成熟度やその後の予測もある程度可能だ。
良い記事があったのでメモ。
【元ネタ】
InfoQ: バーンダウンチャートを解読する
理想ラインが加わったredmine_version_burndown_charts画面: プログラマの思索
最初に、3パターンが紹介されている。
一つ目は、スプリント終了時に残作業量がゼロにならなかったケース。
例えば、スプリント後半にバグが頻発して、計画通りに作業が進まず、重大なバグを解決できずにリリースできなかった状況があるだろう。
二つ目は、スプリント前半は残作業がかなり残って遅延していたが、スプリント中盤からいきなり急角度で残作業が減っていき、最終的にゼロになったケース。
結果オーライかもしれないが、記事では次のように解説している。
「おそらく彼らは積極的に数字を更新することをしなかったことを示す。彼らが残った作業の量を更新するのを怠ったか、スプリントの終わりに近づくにつれてたくさんのユーザストーリーが放棄されたのだ。」
つまり、バーンダウンチャートの最新化を積極的に行わなかったという事実を見ると、チーム自身が今どれだけの作業が残っていたのか、を自覚できていなかったのではないか。
三つ目は、予想線と実績線があまり離れずに最終的にゼロになったケース。
当初の予定通りにスプリントが終了した状況になるだろう。
だが、僕の経験からしても、スプリント(イテレーション)計画通りにいつも開発が進むとは限らない。
むしろ、残作業量が暴走してしまわないように、必死にコントロールしようとしているのが普通だろう。
特に、初めてのWebフレームワークを使う開発、初めてのスマートフォンアプリの開発、新規顧客の業務システム開発などの場合は、当初の計画で全てが見通せるわけがない。
更に記事では下記のパターンが紹介されている。
(引用開始)
1. フェイキーーフェイキー(Fakey-Fakey) ・・・ 完成に向かう完璧な下り坂によって特徴づけられる。ソフトウェアプロジェクトがゴールに向かってまっすぐ進む程度に複雑である。多くの場合、このグラフは命令や統制の激しく、オープンなコミュニケーションは珍しいような環境において現れる。
2. 遅い学習者(Late-Learner) ・・・ これはグラフの後ろの方にあるこぶによって特徴づけられる。効率的にコミュニケーションをとり、スクラムを学ぼうとしているチームに一般的である。
3. 中間学習者(Middle-Learner) ・・・ これは中程にあるこぶによって特徴付けられ、遅い学習者に比べると成熟していることを示す。このチームは多くの作業や複雑さをスプリントの中頃に発見する。
4. 早期学習者(Early-Learner) ・・・ 早期のこぶとその後の緩やかなバーンダウン。このチームは早期の発見の重要性を理解しており、チームのゴールを達成するために効果的に動いている。
5. 高原(Plateau) ・・・ このチームは最初はよい進捗を見せるが、その後スプリントの後半で失速する。
6. ネバーーネバー(Never-Never) ・・・ これはバーンダウンがスプリントの終わりに向かって突然上昇し始め、下りてこないようなときのことである。この遅い変化は最初に起こす必要があり、また、レトロスペクティブの一部として扱う必要がある。
7. スコープの増大(Scope-Increase) ・・・ これはスプリントの間でいきなり作業量が増加することで特徴づけられる。これは普通、チームがスプリント計画会議中にコミットした作業のスコープを完全に理解していなかったサインである。
(引用終了)
興味を惹いたのは、「遅い学習者」「中間学習者」「早期学習者」。
いずれもScrumを学習してマスターしようとしているチームなので、最終的には成功裏に終わるのだが、微妙にニュアンスが違う。
「こぶ」は進捗の遅延から発生した残作業量だから、当初の計画と実際の開発のギャップを表す。
上記のパターンでは、スプリント前半でギャップが出るほど良いと評価している。
理由は、リスクを早期発見すればすぐに対処できるだけでなく、一つのリスク対策を学習したことになり、残りの期間で学習結果を実践できるからだろう。
バーンダウンチャートが理想通りのグラフになるためには、正確性の高い見積りと緻密な計画、そして常にその計画を最新化していくのが大切なのだろう。
バーンダウンチャートの事例を集めてみると面白いのかもしれない。
| 固定リンク
「Agile」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
コメント