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

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

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

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

関連記事

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

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

業務の引継ぎや情報の伝達で思ったこと

今のチームで仕事をやり始めて2ヶ月半が過ぎました。 その2ヶ月半で、業務の引継ぎや情報の伝達について、ふと思ったことがあったのでつらつらと書いてみます。 自分の立場 中途入社でしたので、チームが携わっ …

SCRUM BOOT CAMP THE BOOKを読みました

「SCRUM BOOT CAMP THE BOOKはいい本です!マネージャーも開発者もみんな読んでみてください!」で終わらせようと思ったら・・・ @yohhatu それでもいいけどw もうちょっとww …

見える化

「可視化」と「見える化」

先日「プロジェクトファシリテーションパーティ2012」に参加してきました。 #参加した皆さん、お話していただいた皆さん、スタッフの皆さん、ありがとうございました! 参加したセッション マルチセッション …

変更履歴を論理的に見ておかしいと思わないのは…

仕事での行動基準…うまく言えないのですが「これを気をつけて欲しいなぁ」的な内容…を考えることがありました。 SEが作成するドキュメント(堅く言うと「成果物」)にはたいがい「変更履歴」を記入する欄があり …

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