サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

Agile Scrum 旧館より 開発プロセス

バーンダウンチャートの疑問を聞いてみた

投稿日:2012年4月5日 更新日:


先日社内勉強会で「バーンダウンチャート」について説明する機会がありました。

その際の資料として@ryuzeeさんの「[Agile]バーンダウンチャート虎の巻(資料公開)」を使わせてもらいました。
#@ryuzeeさん、ありがとうございました!

その資料で自分なりに疑問に思ったことを@ryuzeeさんとやり取りした内容を「誰かの役に立てば」と思いまとめておきます。

質問1:バーンダウンと自己組織化の関連

※スライド11枚目:「バーンダウンから分かること」
「チームが自己組織化されていて~」とは具体的にどのようなことでしょうか?バーンダウンの進み方と「自己組織化」の紐付けがイメージできませんでした。

質問1に対する@ryuzeeさんのお話

チームがスプリントを主体的に行なっているかどうかが分かります。
他人からの指示を欲してしまうチームは、一般的には問題が発生してもすぐ対応しないので、スコープ調整が行われず完了しないスプリントになったりスコープ調整が後半になったり、そもそも経験から学ばずに、毎回似たようなバーンダウンを描いたりします。

質問2:理想線の引き方について

スプリントの見積総時間とスプリント終了日を結んだ場合、チームの1日辺りの理想時間と乖離すること(※1)もあると思います。
この場合は「詰め込みすぎ」なので「スコープを見直す」アクションにつながると思っていますが、この理解にコメントあればお願いします。
(※1)3人チームで、1人の開発時間は6時間/日の場合、18時間/日のパワーです。一方、理想線の傾き(1日の時間)は24時間とした場合、毎日6時間のオーバータスクになってしまいます。

質問2に対する@ryuzeeさんのお話

その理解であってます。
ただし、チームにはキャパシティというのがあります。これはチームメンバーの稼働可能時間の合計値ですが、それは一般的には就業時間の6割程度です。

したがってスプリント計画第二部が終わって計画ができた時点で、まずチームの総キャパシティの中に合計タスク時間数が収まっているかは確認すべきポイントです。
既にこれを超えているようであればプロダクトオーナーと議論して順位の一番低いストーリーから順に外します。
またチームがタスク出しになれていない場合は、2割くらいの追加タスクが出るのが普通なので、これも見込んだほうがよいです。

結果として、理想線のスタート地点はキャパシティの下側になければいけません。

質問3:残時間の傾きが大きくなった場合の原因

※スライド21枚目:早期学習パターン
残時間が44→26のように(スコープの調整等がなく)ガクッと下がった場合、以下のことが考えられます。
A:チームがレベルアップして当初見積より早くそのタスクが終わった
B:チームが残業した

前者であれば良いのですが、後者であればそれは持続可能でないと思います。
そういう場合に「最終コミット時間」を別にプロットすることで「原因を明らかにする」のが良いと思っています。
この理解にコメントあればお願いします。

質問3に対する@ryuzeeさんのお話

本当は最終コミット時間プロットしなくたって振り返りで分かりますけどね。
本質的な原因を明らかにしなければいけないのはその通りです。
往々にして成果達成に対する強いプレッシャーがかかってたりします。

質問 4:複数スプリント間での比較

※スライド35枚目:複数スプリント間で分析する
スプリントで作る機能の難易度の違いを考慮する良いアイデアはあるでしょうか?
「ふりかえり」でチームでディスカッションして明らかにするのが1つの方法と思っています。

質問4に対する@ryuzeeさんのお話

難易度の違いはストーリーポイントと、ばらしたタスクに明確に現れるはずだと思います。
そのためにチームで見積るので。
それが着手してみて初めて難易度がわかるようであれば、そのバックログ項目はまだReadyではないです。

最後に

バーンダウンチャートを始めることは割と簡単にできます(おそらくガントチャートと並行してもできるはずです)。

実際にやってみるとガントチャートだけでは見えなかったチームやプロジェクトの色々なことが見えて来ます。
もし何も見えなかったらそれはそれで無茶苦茶素晴らしいチームか、何か隠しているかです。
それらの分かった情報をもとに改善のきっかけにしていくこともできると思うのでまずはやってみてはいかがでしょうか?

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

-Agile, Scrum, 旧館より, 開発プロセス

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

愚痴を言うよりも何か行動を起こす方が精神衛生上良いと思う

 飲み会の席で上司や会社の愚痴を言う人がいます。  愚痴はストレス発散の効果もあるでしょうから全面的に悪いとは思いません。  ただ改善の見られない愚痴(それは既に愚痴では無いかもしれませんが)を聞いて …

difference-of-the-elements-required-for-development

新規開発と保守開発に求められる要素の違い

システム開発の要素の1:新規開発(スクラッチ)と2:保守開発(機能追加)があります。 #保守開発は派生開発とも呼んだりするようですが、ここでは保守開発とします。 新規開発はその名前の通り「一から」シス …

初めて勉強会で発表する人に伝えたいこと

同僚がチームが直面した課題、その課題へ工夫したことを事例紹介として、勉強会で発表することになりました。 この同僚は社外の勉強会では初めて発表するというこもあってか「ほとんどの聴き手が『そんなん知ってる …

プロジェクト完了報告書の問題

プロジェクト完了報告書 昔のいたある会社に「プロジェクト完了報告書」というドキュメントがありました。 「そのプロジェクトで得られた教訓を(自分も含めた)組織の別のプロジェクトの改善につなげる」ために作 …

自分のTwitterアイコンの変遷

Twitterアカウントのアイコンは干支をモチーフにしたものですが、元ネタはヨメさんが年賀状用に描いていたものです。 #コミュニティなどで使う個人名刺にも使っていて、名刺の作成は前川企画印刷さんのブロ …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。