私の会社では、1人のユーザーが1つのタスクを完了することはできません。各タスクをQAおよびコードレビューする担当者が別々になります。これが意味することは、各個人がタスクごとに、完了するまでにかかる時間についての見積もりを提供することです。

問題は、どのようにすれば燃え尽きるのでしょうか？時間を一緒に集計する場合、次の推定を仮定します。

10時間-開発時間

4時間-QA

4時間-コードレビュー。

タスクの見積もり= 18時間

毎日の終わりに、タスクを「完了するまでの残り時間」で更新するようにお願いします。ただし、一般的に各人は自分の部分について考えます。彼らは残りの努力をマークし、それに努力の見積もりを追加する必要がありますか？どうやってこれをやってるの？

更新

いくつかのことを明確にするために、私の組織では、ストーリー内の各タスクに3人が必要です。

1. タスクを開発する誰か。（単体テストを行う、など...）
2. タスクをレビューするQAスペシャリスト（主に統合テストと回帰テストを行います）
3. コードレビューを行う技術リーダー。

間違った方法や正しい方法があるとは思いませんが、これは私たちの方法です...そしてそれは変わりません。私たちはチームとして働き、可能な限りストーリーの最小レベルでも完成させます。開発が完了するまで何かが機能するかどうかを実際にテストすることはできません。また、コードの品質を確認することもできません。そのため、できることは、最小限の機能をテストしてプロセスのできるだけ早い段階でレビューしました。

このように働く人々への私の質問は、彼らがこのようにセットアップされたときに「タスク」を焼き払う方法です。タスクにそれ自身のサブタスクがない限り（JIRAは許可しません）...毎日「残っているもの」を追跡するための最良の方法がわかりません。

それは3つのタスクであり、1つではありません。

1つの機能/ストーリーかもしれませんが、3つのタスクです。1人の人が1つのタスクを有限の時間で完了することができます。

TL; DR

いくつかの方法でバーンダウンを誤って使用しています。タスクとストーリーは完了または未完了です。バーンダウンで時間ベースの計画推定値からの偏差を追跡することにより、作業成果物の残りを推定するのではなく、実際にスケジュールを再推定します。

スクラムでは、スプリントのタイムボックスを測定するのではなく、スプリント目標に向けた進捗を測定する必要があります。これにより、継続的なスケジューリング調整ではなく、チームの能力と機能の提供に重点が置かれます。

タスクとストーリー

タスクとストーリーを統合しています。ストーリーは、チームの「完了した定義」ごとにストーリーを完了するために必要なすべてのタスクで構成されます。すべてのタスクが完了しない限り、ストーリーは100％不完全と見なされます。スクラムでは、ストーリーは常に何らかの方法で推定されます。最も頻繁には、ストーリーポイントで推定されます。

タスクは、ストーリーを完了するために必要なステップまたはマイルストーンです。各タスクには依存関係と前提条件がありますが、他のタスクとは関係なく、コードレビューが完了したかどうかは確かに言えます。

全焼

スクラムでは、バーンダウンチャートにスプリントまたはプロジェクトの残りの作業量が表示されます。実際のバーンダウンチャートには、多くの場合プラトーがあります。場合によっては、グラフが上昇することもあります。たとえば、3ポイントと5ポイントの価値がある2つのストーリーがある1週間のスプリントでは、データポイントは次のようになります。

Mon | Tue | Wed | Thu | Fri
--- | --- | --- | --- | ---
 8  |  5  |  5  |  5  |  0

この理想的なシナリオでは、8つのストーリーポイントから始めます。3ポイントのストーリーは火曜日の午後に完了し、5ポイントのストーリーは金曜日まで完了しませんでした。ストーリーのポイントは、ストーリーが完了の定義を満たすまでバーンダウンから差し引かれません。ストーリーポイントの代わりに理想的な時間を使用している場合、変化するのはスケールだけです。

タイムボクシング

一般的に受け入れられている方法は、タスクが1日半から2日で一口サイズのチャンクに分解されるようにすることです。1日以上の差異は、毎日のスタンドアップまたはスプリントバックログから明らかです。正式なステータスプルを実行する必要はありません。

バーンダウンチャートで統計分析を実行して、スプリントが正しく傾向を示しているかどうかを判断することもできます。わずかな逸脱やプラトーは正常ですが、毎日の立ち上がりで誰もブロッカーを上げていなくても、バーンダウンがスタックしているように見える場合、それは一般にスプリントバックログが誤って推定されているか、「目に見えない作業」があるという兆候ですプロセスで明示する必要があります。

QAが役割を果たす前に、devタスクを「完了」と定義できますか？開発が完了する前にコードレビューを「完了」と定義できますか？開発者とコードのレビューが行われていない場合、QAは「完了」できますか？

3つの項目を1つのタスクに集約し、3人で一緒に作業する必要があると思います。

スクラムは、アイテムがチームメンバーの責任であるとは言いません。ちょうど反対です-スプリントログアイテムはチームの責任です。タスクを実行するのに3人が必要な場合、それが必要です。

関係ありません。ストーリー全体で比較的一貫している限り、バーンダウンチャートはどちらの方法でも機能します。チームが報告するのに最も自然な方法を使用してください。

私のチームは実際には一種のハイブリッドを行っていますが、正式な合意によるものではありません。タスクに1人で2日かかると思われる場合は16時間を費やしますが、2人で一緒に作業する場合は変更しません。

最初の見積りの後、非公式には残りの1時間よりもチームの完了率が1パーセント以上になります。最初は2日間かかると思っていたが、1日後には25％しか完了していないと考えられるため、元の16時間のうち4時間をオフにします。おそらく残りの3日間で4時間を差し引くため、技術的には24時間と推定される12時間になります。

最初はスクラムマスターとして悩まされましたが、奇妙なことに、見積もりを出すのは非常に自然な方法です。バーンダウンを引き続き有用にするためにすべて平均化されますが、それが重要です。

タスクの残り時間は重要ではありません。ストーリー全体が完了するまで何も配信できません。

人々にタスクの残り時間を記入させることにより、ストーリーの残り時間（全体）を追跡する場合は、タスクを1人ごとに分割します。

それは言った：

• 大きなタスクは、ストーリーが大きすぎることを示している可能性があります。この場合、最善の解決策は、ストーリーの範囲とサイズを縮小することであり、それを減らすと、タスクの残り時間を追跡することはそれ以上重要ではなくなります十分な粒度です）。
• SCRUMは、誰もが行う必要のあることを取り上げることを奨励しています。（役割ではなく）人にタスクを割り当てている場合、QAがボトルネックになっているため、開発者が何もしていなくても、ストーリーを配信できない可能性があります。

タスクを複数のタスクに分割し、それぞれを異なる人が処理するタスクとして入力します。

元のタスク：何かを修正する

新しいタスク：（元のタスクの親の子）

• 開発者A-問題の修正
• 開発者B-問題の修正における開発者Aの支援（ペアプログラミング、コードレビュー）
• 開発者A-データセットXを使用して修正をテストする開発者
• 開発者B-データセットYを使用して修正をテストする開発者