19

FogBugz の「エビデンスに基づくスケジューリング」は興味深いですが、アジャイル手法でどのように使用すればよいですか?

4

4 に答える 4

12

eed3si9nが言ったように、EBS の見積もりに一貫性がある場合は、FogBugz がこれを処理します。

より一般的に言えば、FogBugz がアジャイル方法論にどのように適合するかについては、ミニリリースとしてスプリントを行うのが最善の策です。スプリントを作成し、そのスプリントで達成したいケースをそのリリース (またはマイルストーン) に追加します。1 週間のスプリントを行う場合は、たとえば 1 週間後に終了日を指定します。その後、EBS はそれを追跡し、予定どおりかどうかを通知します。

レポート セクションのグラフには、バーンダウン チャートも表示されます。FogBugz はアジャイル専用ではないため、用語は少し異なりますが、情報はそこにあります。

スプリントを終了する予想時間が安定しているか、それとも進んでいるかを確認したいと考えています。安定している場合は順調であり、バーンダウン率は目標どおりです。それが忍び寄っている場合は、地面を失い、スプリントが遅れています. 物事を次のスプリントに移すか、見積もりを台無しにした理由を理解する時が来ました :)

基本的に、これはバーンダウン チャートではなくバーンアップ チャートだと思いますが、同じ質問に対して同じ答えが得られます。私は時間通りに終わりますか？私は何をしなければなりませんか？

Atalasoft のLou Francoも、これについて優れた記事を書いています。 Patrick Altmanにも記事があります。

更新: Altman の記事へのリンクを修正

于 2008-09-11T18:56:10.020 に答える
4

計画にストーリー ポイントを含めるためのいくつかの提案を次に示します。

ストーリーを FB7 に入力するとき、それをケースとして行い、作成した「ストーリー ポイント」と呼ばれる新しいカスタム フィールドに計画ポーカーからのストーリー ポイントの数を含めることができます (方法は以下を参照)。次に、そのストーリーの作業に取り掛かるとき、必要に応じてさらにサブケースに分割し、各サブケースを完了するための推定時間を入力することもできます (推定時間はストーリー (上部) に追加されます)。 ) ケースの「見積もり」フィールド、および証拠に基づくスケジューリング/バーンダウン チャートのフィード)

Agile 命名法を反映するために、FogBugz インストールで変更を検討する必要がある 2 つの点を次に示します。

(1) 箱から出してすぐに、FB カテゴリの「機能」は「ストーリー」に最も似ています。ただし、カテゴリ名を変更したり、[管理] > [ワークフロー] > [カテゴリをカスタマイズ] で新しい名前を追加したりできます。これに関する追加情報は次のとおりです。

http://www.fogcreek.com/FogBugz/docs/70/topics/plugins/CustomWorkflow.html?isl=174457

(2) ストーリー ポイントを取得するには、ケース ダイアログでカスタム フィールドを作成することをお勧めします。これは、付属のカスタム フィールド プラグインで実現されます。これに関する追加情報は、isl=174461 で入手できます。

カスタム フィールドを使用すると、ケース ダイアログ ヘッダーに常に表示されるストーリー用のテキスト編集ボックスを追加することもできます (その下のケース アクティビティ履歴がどれだけ長くても)。

于 2009-12-17T15:35:04.847 に答える
4

たとえばXPでは、IET（理想的なエンジニアリング時間）で見積もりを提供するため、FogBugzの人たちにも同じことを尋ねました。彼らの答えは、見積もりを提供する方法に一貫性を持たせることでした。

于 2008-09-11T02:32:38.557 に答える
4

技術チーム内のほぼすべての目的で FogBugz を使用し始めました: ドキュメント、バグ報告、タスクの管理。時間が経つにつれて、私たちは次第にアジャイル性を高めてきました。

私が行ったことは、プロダクト バックログと呼ばれるリリースを作成することであり、これには将来の任意のリリース日が与えられます。優先度でソートできるように、FogBugz フィールドの「バージョン」を「優先度」に変更しました。製品のバックログを管理するために、私はエリアを多用してユーザー ストーリーを分類しています。エリアは、テーマまたはエピックである可能性があります。各イテレーションは、FogBugz のリリースです。

さて、私たちが最近使い始めたのは、製品バックログを見積もるための理想的なタスク日数ではなく、ストーリー ポイントです。FogBugz はストーリー ポイントの測定単位を理解していないため、紛らわしいことに、製品バックログの 1 SP は FogBugz では 1 日として報告されます。混乱がある場合、これは危険な場合があります。しかし、私たちのチームは小さいです。私は FogBugz に組み込まれているレポート ツールを使用していませんが、使用できれば素晴らしいと思います。

したがって、ストーリー ポイントとベロシティの計算はすべて Excel の FogBugz の外部で行われます。これで今のところ大丈夫そうです。ユーザー ストーリーのインデックス カードを使用してタスクを追跡し、ポストイット ノートをオフィスのボードのタスクとして使用しています。私の決定に影響を与えた Kniberg の本「Scrum and XP from the Trenches」をご覧ください。実際、私たちが朝のスクラムで見つめているすべてのものを載せた大きなボードを持つことは本当に役に立ちます。

FogBugz の過去の推定履歴とレポートは優れていると思います。これはプランニング ポーカーの世界で機能しますか? 少なくともチームの見積もり履歴からはそうだと思います。

プロダクト バックログのユーザー ストーリーは、反復的な計画セッション (アジャイル プランニング) によって進化することが多いため、説明のスレッドとは対照的に、ケースの wiki スタイルの編集があれば素晴らしいでしょう。

次のメジャー バージョンではアジャイル プロセスがよりサポートされるという話があるので、これが提供されることを非常に楽しみにしています。

編集: FogBugz 7 がリリースされ、製品「プロジェクト」バックログの管理が大幅に改善されました。見てください！

http://www.fogcreek.com/FogBugz/blog/post/Scrum-Friendly-Features.aspx

于 2009-01-20T09:46:35.457 に答える