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

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

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

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

関連記事

フリカエリ

[仕事]「可視化」と「見える化」で書いた勉強会で、「朝会」と「見える化」ともう1つ「フリカエリ」について考えることがありました。 今のチーム(約2年)では原則、(Scrumの)イテレーション毎にフリカ …

継続的な受付窓口って必要

ふとあるミーティングで熱く議論した後に思ったことです。 色々な組織レベルで、「会社を活性化するには?」とか「売上を伸ばすにはどうしたら良いか?」という類のアイデア出しやブレーンストーミングを目的とする …

自分のテンションを維持する方法

コンピュータは基本的に調子の波がなく、いつでもいつまでも同じポテンシャルを発揮してくれます。 #CPU100%は「調子が悪くポテンシャルが低い」と表現できますが、ここではそんなことを言いたいのではなく …

できるだけ文字を打たないことでミスを少なくする

文章やプログラムを書く時に効率性や質の向上の為に自分なりのルールや注意していることがあります。 1つは前に書いた文章の揺らぎです。 もう1つは低レベルな話ですが「出来るだけ文字を打たない」ことです。 …

「感謝の言葉を伝える」アクティビティ

少し前、グループでフリカエリとこれからの活動について、半日時間を取って、しっかり議論しました。 夜は、(それまでの活動が一区切り付いたこともあって)打ち上げをしたのですが、そこでちょっとしたアクティビ …

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