6

私は 10 人のチームで大規模なレガシー コード ベースに取り組んでおり、プロダクト オーナーは理想的とは言えません。私たちのバックログはかなり悪い形であり、大規模なエピックが頻繁にスプリントを破っています。チームはまた、done の定義にも苦労しています。時間に応じて、熱心にユニット テストを作成するメンバーもいれば、作成しないメンバーもいます。

それで、私はいくつかの興味深いバーンダウン パターンを見てきました。他の人が見ているパターンとその意味を知りたいと思っています。

パターン 1:

#
# # 
# # #  
# # # #     
# # # # #   
# # # # # #
# # # # # # #
  • 肯定的な説明: 「大丈夫です。」
  • 否定的な説明: 「うますぎる。本当はどうなっているんだ?」

パターン 2:

#
#
# #
# #     
# # #   # 
# # #   # #
# # # # # # #
  • 肯定的な説明: 「これは思ったよりもずっと簡単でした。もっと多くのストーリーを取り込みましょう。」
  • 否定的な説明: ??

パターン 3:

#
# # # #
# # # #  
# # # #     
# # # # #   
# # # # # #
# # # # # # #
  • 肯定的な説明: 「この作業について最初はよくわからなかったが、後で思ったより簡単になった」
  • 否定的な説明: 「進捗が不十分です。ユニット テストを書くのをやめて、時間どおりに「完了」させましょう。」
4

6 に答える 6

2

これは、社内では「あ、クソ！忘れてた」と認識されています。全焼：

    # # #
    # # # #
    # # # # #
    # # # # # #
#   # # # # # #
# # # # # # # #
# # # # # # # #
于 2008-10-17T18:27:10.913 に答える
2

マイナス側のパターン 2 は「よく見積もっていない」です。

ここに私が使用したいくつかのバーンダウン チャートがあります。背景の写真は無視してください。それらは私が一緒に仕事をしている人々を楽しませるためにあるだけで、それ以外の場合は私たちの仕事とは何の関係もありません。 代替テキスト http://www.atalasoft.com/cs/photos/techtalkgallery/images/16157/425x285.aspx

私はこのチャートが大好きです。他のタスクを放り出し、作業に取り掛かり、他のことに割り込まれ、最後までやり遂げるために、少しゆっくりと開始するのは、優れたチャートの非常に典型的な例です。

代替テキスト http://www.atalasoft.com/cs/photos/techtalkgallery/images/16155/425x262.aspx

このチャートでは、私たちは非常に着実にスタートし、離陸して実際に予定より早く終了しました。

代替テキスト http://www.atalasoft.com/cs/photos/techtalkgallery/images/16156/425x264.aspx

このグラフでは、非常に一般的な方法で開始した後、簡単に見えたタスクが非常に難しいことが判明したことがわかります。このスプリントを中止し、新しいスプリントを構築することになったと思います。

于 2008-10-17T18:30:54.133 に答える
1

私の見解は、バーンダウンチャートをあまり真剣に受け止めないことです。それらは指標です。結局、それはあなたが物語を完成させたかどうかについてです。

スプリントの最後に効果的な回顧展がありますか？

遡及的措置はフォローアップされていますか？

人々がユニットテストを書かないことがわかった場合は、宗教的にそれを行わせます（それがあなたのチームの標準である場合）。完了の一般的な定義に同意し、それに固執します。完了の定義を参照してください

SCRUMのようなアジャイルプロセスを実現するには、継続的な検査と適応が必要です。

私には問題があるように見えますが、あなたのチームはそれらの問題に取り組んでいません。プロダクトオーナーが理想的とは言えない場合は、次のスプリントで回避できるように、これに関連する問題を回顧展で取り上げる必要があります。

叙事詩がある場合は、いつでもそれらを分解し、優先順位を付け直して、計画を立て直すことができます。

于 2008-10-21T15:33:16.707 に答える
1

バーンダウンの問題の 1 つは、スコープの変更がスコープに対する進行状況と混ざり合うことです。

あなたの例2では、​​考えられる説明は...聖なる煙です。おそらく、この危険なストーリー/タスクを開始するために反復の終わりまで待つべきではありませんでした...それは私が予想したよりもはるかに多くの労力です!

例 3 では、早い段階でスコープを追加したか、作業が予想よりも手間がかかることに気付いた可能性があります (たとえば、タスクは 1 日 4 時間と見積もられ、8 時間の作業の後、次のタスクは 4 時間と見積もられ、そのタスクがはるかに困難であることがわかりました)。

この理由から、私はバーンダウンよりもバーンアップを好みます... スコープの変更を進行状況から 2 つの行 (1 つのスコープと 1 つの残りの作業) に関連付けないため、スコープの変更の影響をより明確に確認できます。

于 2008-10-19T01:12:59.140 に答える
0

ここでまだ見たことのないものがあります。それは最後のスプリントで起こりました。 

#
##
###
#####
#############
##################
###################
####################

それは、「最初のタスクで予想以上の進歩を遂げた後、先を行っていると考えられていたが、緩み、最後に懸命に追いつく必要がありました。そうしないと、機能を失うリスクがありました。」

得られた教訓: バーンダウンは過去の取り組みを追跡するのに最適ですが、必ずしも将来の進捗状況を表すものではありません。

于 2008-11-25T20:38:28.290 に答える
0

ここでは、しばしば次のようになります。

#####
#######
########
#########
#########
#########
##########

肯定的: 時間通りに配達されます。

マイナス: バックログ項目が大きすぎるか、最初から同時に開始されたバックログ項目が多すぎます。

于 2008-10-21T14:42:06.623 に答える