各スプリントの開始時の早期サブタスク

アジャイル/スクラムを使用している新しいチームに参加しました。開発プロセスは次のとおりです。

1）開発者は各スプリントの前に各ストーリーを確認し、重要なことを見逃さないようにします。ワークフローにはそのための正式な状態があります。

2）スプリントのキックオフ中に、チーム全体が各ストーリーにかかるストーリーポイント数の見積もり（ポーカープランニング）を行います。

3）最後に、各スプリントが開始された直後に、各開発者は割り当てられたすべてのストーリーを、各ストーリーを開始する前のサブタスクとは対照的に、時間の見積もりとともにサブタスクに熱心に分解する必要があります。

最後のステップの主な論点は、ストーリーの実装に予想よりも時間がかかるかどうかを発見し、スクラムマスターにスプリント期限の欠落の潜在的なリスクについて警告することです。

しかし、主に次の理由により、この逆効果になります。

• 目的が大まかな見積もりを提供することである場合、ストーリーポイント（ステップ＃2）は仕事をするものです。それ以外の場合、なぜストーリーポイントに悩まされるのでしょうか？-早めにサブタスクを実行します。
• 目的が正確な推定値を提供することである場合、これは有害と見なされるヒューマンタスクスイッチで説明されている内容の明確な例です。これは、特に、大規模プロジェクトで既存のチームに参加し、何をする必要があるかを理解するのに最大50％の時間がかかる新​​しい開発者の場合に当てはまると思います。ストーリー＃1、次にストーリー＃2、＃3などの詳細を取得する必要があります。これにより、大量の情報が大量に生成されます。

また、そのような慣行は「本による」と言われていますが、これについて議論するつもりはありません。誰でもそのような実践への参照を提供できますか？これがスクラム聖書で明確に定義されているかどうか、および/または多分余分な洞察を提供しますか？

これは、スクラムプロセスの一部を実行する方法と似ています。私達

1. 「ストーリーポイント」のバックログの上部にあるストーリーを推定する
2. スプリントを「補う」と思われるストーリーポイントに基づいてストーリーを選択/説明する
3. ストーリーをより詳細な技術的タスクに分解する
4. 技術的なタスクを見積もり、元のストーリーポイントの見積もりと比較します（ストーリーポイントが通常どれくらいの開発時間に相当するかを知っています）

しかし、あなたが知りたいのは、なぜ2回見積もるのかです！

• 私たちが何について予測作ることができるようにしたいので、我々は（物語に基づいて）粗い見積もりを行う可能性があるにも次のスプリント、そしておそらくそれ以降も、ものを。最終的に経営陣は、可能性のある時間スケールについて顧客と通信できる必要があるため、この粗いスケールの推定値がない場合、長期計画は事実上不可能です。
• 明らかに、これは現在のスプリント以上のものについて粗い推定を行うことを意味します。バックログの順序が次のスプリントで変更されないという保証はないため、必要になるまでタスクの内訳と詳細な見積もりを行うために時間を費やしたくありません。
• タスクを分解して、すべてのタスクが列挙され、ストーリーをより簡単に並行して処理できるようにします。
• （特に、大規模なストーリーを実行可能な「機能」に分解する簡単な方法がない場合）これによりはるかに滑らかなバーンダウングラフが得られるため、（タスクに基づいて）細かいスケールの推定を行います。
• 私たちは両方を行うので、それらはお互いの健全性チェックとして機能します-激しい矛盾は、私たちが特定する必要があるどこかに間違いが必要であることを示します。これは有用な副産物ですが、それ自体が「2回」と推定する理由ではありません。

あなたの質問とコメントを読み直して、私たちのワークフローとあなたのワークフローにはいくつかの違いがあると思います。

• チームとしてブレークダウンを行いますが、オーバーヘッドは大きくなりますが、これから得られる技術的な議論は非常に価値があり、ストーリーの欠点を検出できることがよくあります。経験、知識、または能力の格差がある場合、この議論は、より多くの人がより少ない人を助けることができる場所でもあります（新規採用に非常に役立ちます）。
• チームとしてタスクレベルで見積もりを行います。「ポーカーの計画」が機能する理由の1つは、「群衆の知恵」現象によるものです。コメントで述べたように、この時点で、タスクの見積もりには30秒未満が必要です、したがってオーバーヘッドは無視できます。

チームがタスクの内訳とタスクの見積もりを行う理由は、スムーズなバーンダウンのためであるように思われます-これは、スプリントの進行状況を監視し、スクラムマスターが問題を早期に検出して解決できるようにするためのすべての部分です。あなたは、この情報が必要な場合、あなたは持っている故障や見積もりを行うには、あなたが持っているそれらを最初に行うこと。

私の意見では、タスクスイッチングはここでは問題になりそうにありませんが、ある機能の開発から別の部分への切り替えはタスクスイッチングであるのと同じ意味で、異なるタスクを分解することは本当にタスクスイッチングであるとは思いません。スプリントの全体的な「アーキテクチャ」を理解することは、おそらく非常に役立つことだと思います。

ただし、検討できる問題は他にもあると思います。いつものように、アジャイルでは、抱えている問題を特定して解決策を提案し、その解決策が回顧的に機能したかどうかを判断する必要があります。これは、会社とチームに役立つアジャイルソリューションを構築するための重要なポイントです。だから、あなたが持っているかもしれないいくつかの問題：

• あなたは個別に故障をしている-あなたのジュニア/未熟なチームメンバーはあなたのシニアチームメンバーからどのように学んでいますか？確かに、彼らはおそらく自分ですべてを学ぶことができます-しかし、彼らが指導されれば、彼らはより速く学ぶでしょう。ジュニアチームのメンバーは物事を分解するのに長い時間をかけていますか？長い目で見れば、チームの時間を浪費するミスやミスを犯していますか？ここでチームとしての内訳が役立ちます。
• あなたは個別に見積もりをしています-最初のポイントと同じことが当てはまりますが、さらにこれらの見積もりは正確ではありませんか？
• スプリントの開始時にタスクが割り当てられているように聞こえますが、その場合、割り当てを変更する必要があるときに、どれだけ費用がかかりますか？誰かが遅れたり病気になったりした場合、他の誰かが自分の仕事を引き受けるのはどれくらい簡単ですか？彼らは、元の担当者を中断することなく、タスクの内訳を調べて理解する必要がありますか？チームとして内訳して見積もれば、誰もがすべてに取り組むことができるはずです！
• あなたの物語は大きすぎますか？内訳が50％の時間を要する場合、ストーリーは非常に複雑であるように聞こえます-おそらくより小さくすることができますか？私たちは仕事の1週間以内に話を続けます。
• タスクが小さすぎますか？タスクリストを作成するのに長い時間を費やしている場合、詳細に行き過ぎているかもしれません。1日から8時間の間に相当する仕事があるため、1日の間に次の日刊紙で報告するために全員がある程度進歩します。

それがあなたの会社が彼らの開発を実行したい方法であり、議論を閉鎖した場合、あなたの選択は制限されます。

アジャイルの究極の目標は価値のあるソフトウェアを動作させることであることを考えると、あなたのチームが提供する能力を評価することで支援を提供することを試みることができます（配信された/推定されたポイント、スプリントのバグ、テストの数、コードカバレッジ、アップタイム、生成された売上-なんでも）。すべての結果に備えてください-それはあなたにとって意味がなくても、この働き方が彼らのために働くかもしれません。あなたが正しい場合、無駄は自明になります。

プロセスのためにプロセスを追跡することには注意してください-これは時間を無駄にし、それでも質の悪い製品を提供します。優れたアジャイルチームが実験、測定、学習します。意見に陥ることなく行動を変える最良の方法は、証拠に基づいた決定をすることです。

これも私の意見です。自分で試して結果を測定することをお勧めします-私がそこで何をしたかを見てください:)

あなたのスプリントキックオフはスプリント計画会議を意味すると思います。あなたのスクラムマスターは、この会議の進め方を誤解していると思います。開発するストーリーを決定するだけでなく、チームにテストして、何も見逃さないことを確認する準備ができていることをテストします（通常はINVESTを使用します）。また、ストーリーをタスクに分割します。マイク・コーン（スクラム・アライアンスの創設者の一人）を引用すると、

スプリントバックログは、スプリント計画の他の出力です。スプリントバックログは、チームが提供することにコミットしている製品バックログアイテムのリストと、それらの製品バックログアイテムを提供するために必要なタスクのリストです。通常、スプリントバックログの各タスクも推定されます。

したがって、ストーリーの分類と推定はすべてスプリントプランニングセッションの一部です。計画セッションが終了した後ではなく、個別にではありません。

さらなる洞察を提供するために、スプリントプランニングミーティング中のワークフローは次のとおりです。

1. 製品バックログの上部からストーリーを取得し、タスクに分割します。経験則として、1つのタスクは通常1日よりも小さくする必要があります。

2. 差し引いたタスクを考慮して、ストーリーを推定します。ストーリーが大きくなった場合、ストーリーを小さなストーリーに分割しようとします。

3. すすぎ、推定ポイントの合計に達するまで繰り返します

Cohnの言うこととは反対に、タスクは1日よりも小さくなるように指定されているため、各タスクを個別に見積もる必要はまったくないことがわかりました。タスクが1日の作業よりも小さいことを考えると、特定のタスクに取り組んでいる人がまだ作業中であると言うので、タスクが予想よりも長くかかっていることを、デイリースタンドアップ中に簡単に確認できます。

スプリント中、チームはストーリー全体を処理し、最後にチームは実際に行われた作業量を反映する必要があります。これがスクラム回顧会議の目的です。テーブルにまだストーリーがある場合は、推定が楽観的すぎると推測し、次のスプリントのためにそれに基づいて行動することができます。または、発生した特定のインシデントが発生した可能性などがあります。それらを反映すると、時間の経過とともに見積もりが良くなることがわかります。

「本によって」-それはあなたの問題です。あなたは滝を働いていた場合よりも多くのプロセスでdrれています。

アジャイル向けの「本」はありません。「すべてのオーバーヘッドなしで物事を成し遂げる」というアジャイルマニフェストしかありません。したがって、サイズを推定し、ストーリーをタスクに分割して再評価する場合、それは無意味なプロセスのオーバーヘッドであり、より効率的にする必要があります-これがアジャイルの目的です。スクラムと他のすべては、アジャイルを開始する方法の実際の出発点ガイドラインです。その際、意味をなさない、またはチームの効率的な作業に役立たないこれらのポイントを特定し、それらを変更する必要があります。

ただし、一部の人々は、禁止された作業方法を石で書く必要があり、どのように愚かになっても逸脱することはないと考えています。スクラムミーティングの前に、ストーリーをタスクに分割してみます-開発者は各ストーリーをレビューする必要があるとおっしゃっていますが、レビューの一部として同時にスプリットを行う機会があります。次に、スクラムミーティングでストーリーを構成するタスクを宣言し（時間を割り当てないでください！）、含まれているこの追加情報に基づいて、ストーリーのワークパッケージの大きさを人々に決定させます（これは決して悪いことではありませんが、情報に基づいた意思決定は当て推量よりもはるかに優れており、意思決定に役立つ情報がある場合にのみ行うことができます）。

ミーティング後も、タスクに時間を割り当てることができます（この点はわかりませんが、スプリントは時間に基づいているのではなく、ストーリーポイントで測定される「どれだけのことを期待するか」に基づいていますこれはスクラムの一般的な問題であり、ポイントは時間を意味するものではありませんが、たとえば2週間に20ポイントを完了する必要があるため、2ポイント= 1日の作業になります。スプリントで、あなたは過負荷でも過労でもないので、実際に何が行われるかではありません。最良のスプリントは、いくつかのタスクが残っているもので、完全に推定されています。最後にそれらを完了するのを遅らせた-どちらも生産的ではありません）。

そのため、略して、アジャイル宣言のコピーと反アジャイル版を印刷してください。アジャイルよりもアンチをしているに違いない。スクラムはそのような傾向があります。それを修正する唯一の方法は、あなたのチームと関わり、変化に賛同することです。チームがどのように働くべきかを経営陣に教えてはいけません。それは機敏ではなく、それはThe Bookに書かれています。

各スプリントのある時点で、製品バックログ調整ミーティングを開催する必要があります。このミーティングでは、製品バックログの上部が十分に分解され、その部分のアイテムが次のスプリントバックログに追加されるようにします。

製品バックログの洗練がうまく管理されていれば、スプリントプランニングミーティングはより効率的になります。理想的には、これにより、開発者がスプリントの開始後にストーリーを「熱心に分解」する必要がなくなります。

製品のバックログアイテムが十分に分解される前にスプリントバックログに追加されて現実的に見積もられると、スプリントに何を追加するかを適切に決定することが難しくなります。