チュートリアル - Agile チームの作業の計画と見積もり

作業の計画

バックログとは

For the purpose of this article, a backlog is the list of tasks which are yet to be allocated for completion. Any large project will end up with lots of things people want; as a team you can use GreenHopper to manage this long list of tasks by ranking, prioritising, and scheduling the work.

In this guide, we are viewing issues on a GreenHopper board. Navigate to this board from anywhere in JIRA by clicking the 'Agile' drop down and selecting your preferred board.

My backlog has thousands of issues — can GreenHopper help?

はい。ただし、チームが達成可能なことを現実的に考えてください。バックログは優先順位がすべてです。最も重要なことを最初に実行するのです。バックログとは、短期間先立って課題を引き出し、作業を計画する大きなプールのようなものです。数千の課題を引き出し、今後数年間の作業を計画するような予定は立てないでください。そのような行為は失敗につながります。代わりに、前もって数バージョンのみ (最大でも数週間または数カ月分) を計画してください。短期間の作業が終了してもバックログは待機しています。

フィルターで整理する

GreenHopper will help you by allowing you to filter options. So for instance you can filter out all the issues in your backlog which are not high priority. You may also want to filter on things such as cards with a high business value.

また、バックログの管理は、データのエントリポイントとしても、計画ステージでも優れています。課題を作成するユーザーに正しい質問を尋ね、重要な課題を素早く見つけ、最も重要な課題にフラグが付けられるようにしてください。重複した課題や類似した課題をリンクさせると、バックログ内の他の課題を解決したときに課題の終了タイミングを確認できて便利です。

You will most likely want to drill down into the backlog so important issues are more prominent. You can drill down into this backlog from the GreenHopper board using your board's Filter (and, optionally, Quick Filters).

1. Your board is based on a JIRA issue filter. This filter can include issues from multiple JIRA projects.
2. ボード上部の大きなテキストはボード名です。その下には、クイックフィルターを選択できるリンクが多数あります 「自分の課題のみ」または「最近の更新」などが表示される場合があります)。クイックフィルターは表示される課題を変更するのに便利です -- クイックフィルターを使用し、特定の優先度、特定のユーザーによって報告された、またはその他の仕様の課題のみを表示できます。
3. ドロップダウンからツール > 設定を選択します。
4. クイックフィルタータブをクリックします。
5. ダイアログが表示され、新しいクイックフィルターの名前と JQL クエリを入力できます。
6. 仕様を選択し、追加をクリックします。次に、ボードの使用をクリックします。
7. ボードには、設定したクイックフィルターに基づいてバックログのサブセットが表示されます。

ランク付けの整理

GreenHopper allows you to set up rankings for your issues to help you organise tasks in your product/sprint backlog more effectively. Rankings allow you to prioritise issues at a more granular level than issue priorities in JIRA, as rankings are a dynamic number — meaning, there is a number 1 issue, a number 2 issue....a number 335 issue, and so on to the end of your backlog. This is helpful for both short and long term planning, and brings important issues to the top of your backlog.

ランク付けを設定したら、カードをつかみ (課題の左側をクリックしてそのままにします)、上/下にドラッグして表示される他の課題の上/下に移動させます。「ランク」番号は自動的に更新されます。

ボードのランク付けの設定方法については、ランク付けを有効にするを参照してください。

スプリントを使用した整理

You can use the sprint marker in Plan mode to help you see how much work can be assigned to a particular sprint. You can estimate your work in Story Points, hours, or any other numeric field of your choice — see Configuring Estimation and Tracking.

一般的に、課題ランキングおよびチームのベロシティ (スプリントあたりの作業容量) に基づいてバックログからスプリントへ課題を割り当てる必要が出てきます。

スプリントマーカーは、バックログの中央に青いバーとして表示されます。

Screenshot: a Scrum board in 'Plan' mode (click to enlarge)

In Plan mode you can:

• Prioritise the Backlog — Create issues for your backlog, rank and estimate them, and drag-and-drop to add them to a sprint.
  Right-click selected issues (in GreenHopper 6.1.2 and later)  to add them to a sprint, send them to the top/bottom of the backlog, view them in the JIRA Issue Navigator or perform Bulk Operations.
• Estimate Stories — You can use the 'J' and 'K' keys to move through issues in the backlog and get details on the right-hand side of the screen. Plug in your estimates or story points as you go.
  Note that, by default, the Story Points field is only available to issues of type 'Story' or 'Epic' — you can change this as described in GreenHopper JIRA Configuration.
• Create Sub-Tasks — To break a story (issue) down into implementable chunks, go to the sub-task tab (click the folder icon) to view and create sub-tasks.
• Organise via Epics — Group related stories into an epic. Click an epic (in the leftmost panel) to view only the stories that belong to that epic.
• Plan Versions — Assign issues to upcoming versions. (To do this, you need your administrator to enable Release Planning in GreenHopper Labs.)
• Plan, and Plan Again — When you're happy with the stories for the iteration, start a sprint and the stories will move into Work mode. While a sprint is active in Work mode, you can still plan subsequent iterations in Plan mode (click Add Sprint), but you won't be able to start them until the active iteration is completed. (You can, however, drag and drop an issue in Plan mode onto the active sprint.) Note that you can only start (or complete) a sprint if you have 'Administer Projects' permission for all projects that match the board's filter.

An issue will only be visible in Plan mode if:

• 課題がボードの保存済みフィルターに一致していること（フィルターの設定を参照 ）
• the issue's status maps to one of the board's columns (but not the 'Done' column).

Kanban チームはどのようにしてバージョンを使用しているのでしょうか。

カードを計画スプリントまたはバージョンへ割り当てる概念は Scrum 固有です。Kanban チームは全く異なる方法論を使用します。バックログ内のカードをトリアージし、優先度に従って行動します。 完了済みタスクの数が十分溜まって大きな値になると、バージョンが作成およびリリースされます。

作業の見積もり

ジョブの所要期間はどのくらいかかりますか。

Even the best engineers have great difficulty predicting the future. There are a huge number of variables involved in predicting how long a job will take; some of the big ones are:

• 誰がタスクを実行するか
• タスクのサインオフを達成することはどのくらい困難か
• コードベースには多数のバグがあるか

これらの未知の要素をすべて組み合わせ、プロジェクトの所要期間を予測することはどのくらい可能でしょうか?現実規模のプロジェクトでは、たとえ概算の見積もりであってもリスクを伴います。

チャートは優れたチームリーダーに何を提供すべきか

チャートを使用することで、過去に遭遇した問題から学ぶことができます。全く違うものを比較したり、ビルがタスクを完了にかかる時間をボブが見積もるのではなく、自分たちの完了済みタスクを基にした見積もりを使用することで、残りの見積もりの正確性を推測できます。

From the charts you can ascertain a teams' "velocity" — that is, the speed at which the team is able to complete the tasks estimated in units of difficulty (hours/complexity/score out of 10). Once you know a team's velocity you can then calculate, based on the current team performance, how long the remaining tasks should take to complete. GreenHopper helps this with by providing a chart.

Understanding the functionality of the GreenHopper Charts

For all the nitty gritty details about accessing the GreenHopper charts, see Using Report Mode (or Using the Classic Chart Board for classic charts).

動作中のアクションと、クライアントへの説明方法

スクリーンショット：バーンダウンチャート (クリックで拡大）

Click Non Working Days (in version 6.1.1 or later) to highlight days when your team won't be working.

このグラフは非常に見栄えが良く、見た人に良い印象を与えるでしょう。内容やポイントを説明できる必要はありますか?

灰色の線は残り作業量です。見積統計に時間を使用している場合、ほとんどの人は 1 時間の開発時間に対し、1 時開のマッピングとなることを予想しているため、これは非常に分かりにくいと思われるかもしれません。これは、作業時間の見積もりのため、開発時間の単位は 20 分または 20 日となります。これらの単位はベロシティポイントに関するものだと考え、ベロシティ計算は所要時間の見積もりに使用するのが最適です。一番下にはカレンダー時間があります。したがって、灰色の線を見るとプロジェクトの進捗状況がわかり、残りのタスクがすべて完了したときに、灰色の線と x 軸が交差します。

見積もりの後の赤い線はプロジェクトが収まるおよその時間単位 (時間) です。あくまでも希望であり、完了日を満たすために信用できるラインではありません。

Screenshot: Velocity Chart (click to enlarge)

ベロシティは、スプリントごとにチームが完了する作業量の見積もり合計に対する、複数の最近のスプリントの平均として見積もることができます。したがって、上記の表でベロシティは = (37 + 47 + 50 +57) / 4 = 48 となります。チームのベロシティは、将来のスプリントでチームが完了できるタスクの量を予測するのに便利です。

これが非常に優れている点です。平均によってチームが同じ結果を継続的に生み出すことができる場合を示し、見積もりに対する実際の信頼性を構築できるのです。

The velocity chart will show you on a daily basis if the project is slipping or not. You can consider changing your resource if you need to alter this but don't forget that adding more people to a project won't give a proportional increase in the velocity points, that's a bug in people not GreenHopper, so no bugs filed for that please.

期待値の推測と管理

チャートは予測を提供するだけにすぎません。それらを使用して、非現実的な期待値ではなく、ポイントを描き、根拠を示す必要があります。また、予測が次のような推測に基づいていることを伝える必要があります。

• チームは同じエンジニアを保持します。
• できればプロジェクトに携わるチームと同じメンバーが見積を作成するとよいでしょう。
• チームをこき使うというわけではありません — 開発は 1 日あたり開発者ごとに 7～8 時間の開発という安定したペースで実行されています。
• あなたは完全にジョブを完了しようとしています。たとえば、隠れた不完全なタスクを膨大に構築するのではなく、作業しながらドキュンメントを構築し、テストを行っています。
• Team motivation remains contant, hopefully with good morale.
• 見積におけるエラー数は一定です。

もちろん、他の推測も同様に実行しているでしょうが、期待値を設定する際にはこれらも織り込む必要があります。

見積

見積も引き続き重要です。次のリンクがプロセスの一部として役立つかもしれません：

• http://www.slideshare.net/pcalcado/agile-estimation-and-planning

また、優れた Agile コーチも推奨されます。