web-dev-qa-db-ja.com

リリースバーンダウンチャートをどのように描くべきですか?

私はさまざまなアジャイルプロジェクトに参加しており、多くのリリースバーンダウンチャートスタイルを目にしました。どういうわけか私が実行したすべてのツールは本当に有用なバーンダウンチャートを生成しないため、それらのほとんどは手動で処理されました。

実際には、推定されたすべてのストーリーを扱っているわけではなく、燃え続けています。多くの場合、スコープはリリース中に追加されます。

現在、私はバーンダウンチャートでこれらの問題に対処しており、次の点について質問があります。

  1. 追加されたスコープをリリースバーンダウンチャートでどのように表すのですか?
  2. 実行する可能性が高いが、まだ予測する時間がないという前提で、リリースバーンダウンチャートの予測されていないストーリーをどのように処理しますか?
  3. リリースの終わりをどのように予測しますか?

以下のバーンダウンチャートは、古典的なMike CohnのEstimating and Planingブックの付録にある架空のケーススタディからのものです。 Mike Cohn's burndown

6

私はさまざまなアジャイルプロジェクトに参加しており、多くのリリースバーンダウンチャートスタイルを目にしました。どういうわけか私が実行したすべてのツールは本当に有用なバーンダウンチャートを生成しないため、それらのほとんどは手動で処理されました。

多くの追跡システムは、妥当なバーンダウンチャートを生成します。たとえばRedmineには plugin があり、さまざまなグラフが表示されます。同様に、Jiraにも バーンダウンチャート があります。

実際には、推定されたすべてのストーリーを扱っているわけではなく、燃え続けています。多くの場合、スコープはリリース中に追加されます。

ここで重要なのは、「すべてのストーリー」を「ターゲットリリース」から分離することです。すべてのストーリーが特定のリリースの対象となるわけではありません。

Redmineの それ自体のロードマップ を見ると、次のリリースで取り組んでいることと将来のリリースの候補との違いがわかります。

現在、私はバーンダウンチャートでこれらの問題に対処しており、次の点について質問があります。

  1. 追加されたスコープをリリースバーンダウンチャートでどのように表すのですか?
  2. 実行する可能性は高いが、まだ予測する時間がないという前提で、リリースバーンダウンチャートの予測されていないストーリーにどのように対処しますか?
  3. リリースの終わりをどのように予測しますか?

バーンダウンチャートの一部は、プロジェクトの速度の可視性です。バーンダウンチャートにギザギザのピークアプローチがあると、追加されたスコープがチャート上で直線として調べたときに速度を台無しにすることを意味します(ある程度、予測されたターゲットを混乱させることもあります)。

代わりに、スコープを広げるには床を下ろし、スコープを下げるには床を上げることを検討してください。この例は、 Burndown chart 青い線のドロップはスコープの増加を示しています。

推定されていないストーリーの場合、2つのオプションがあります-推定を行い、後でそれを調整します(これは、不確実性のコーンと呼ばれる有効かつ適切な推定手法です)。 cone of uncertainty

(から http://www.construx.com/Page.aspx?cid=1648

または、最初は0と推定し、スコープの増加と見なします。

リリースの終わりは、残りの作業がスコープをインターセプトするときです。


私が好きなチャートは アーンドバリューチャート として知られています。 「ダウン」スタイルではなく、「アップ」スタイルのグラフです。数値はパーセントであるため、コスト(使用された合計時間/割り当てられた合計時間)とスコープ(初期見積もりの​​合計に対して行われた見積もりの​​パーセントとして)の両方が同じスケールになります。

enter image description here

http://www.agilekiwi.com/earnedvalue/agile-charts/ から)

この例では、これまでに使用された時間が当初の予算よりも多く、これまでに行われた時間が理想よりも少ないことがわかります。このプロジェクトは困っています。

このモデルでは、スコープの増加はパーセントの再計算として表示されます。

enter image description here

(から http://www.agilekiwi.com/earnedvalue/charting-change/

リリースは、完了率から推定できます。

enter image description here

(また http://www.agilekiwi.com/earnedvalue/agile-charts/ から)

このチャートを理解する領域は アーンドバリューマネジメント として知られています-多くの業界でこれらのチャートを理解するためにかなりの作業が行われています。

強くアジャイルWikiチャート変更シリーズを読むことをお勧めします- チャート変更 および アジャイルチャート -私画像のリンクは、サイト上の素材のかなりの部分に光沢があります。

11
user40980

これは現在、私の同僚と私が構築している アジャイルツール のバーンダウン問題を解決する方法です

enter image description here

  1. 追加されたスコープは、Mike Cohnのグラフと同じように縦線で表されます。また、ライトグレーのバーでこれを強調しています。
  2. 推定されていないストーリーは、(推定されたストーリーの)現在の平均速度に推定されていないストーリーの数を掛けて計算されます。濃い灰色のバーに表示されます。推定ストーリーは、最も暗い灰色のバーに表示されます。
  3. 投影は、最後の3回の反復の速度に基づいていますが、後の反復により多くの重みを与えます。

グラフは燃え尽きているようには見えませんが、途中でスコープが追加されており、推定されていないストーリーの数があるという現実を反映しています。これは、少なくとも社内プロジェクトにとって、本当に役立つバーンダウンチャートであると考えています。フィードバックを歓迎します:-)

4