並列処理できないタスクをスクラムおよびスウォーミングする
私の現在のスクラムマスターは、公式のスクラムに屈することをいとわない真の信者です。私はこれが不確かに聞こえるようにしたくありません、私は過去に彼と一緒に問題を公式の用語でリキャストすることによって問題を解決することに成功しているので、私はこの問題の正統な解決策について本当に尋ねています。
現在発生している問題の現在の例は、一部のストーリーの間に順序付けの依存関係があることです。 （特に、開発の一部では、シングルシートライセンスしか持っていないサードパーティプログラムを使用しています。）これに関連するいくつかの必要なセットアップタスクがあり、「セットアップストーリー」にまとめられています。任意の順序で実行できるタスク。
問題は、現在のスプリントでセットアップストーリーと後続のストーリーの1つをプルしたことです。その時点で、スプリントが半分以下であっても、このグループではこれ以上のストーリーをとることはできません。このグループよりも優先度が低いバックログには無関係なストーリーがあり、スプリントに取り入れることをお勧めします。ただし、これらはすべて、このグループのストーリーの下で優先されました。この時点で、スクラムマスターは、「セットアップタスク」に集中し、それをより速く実行する必要があると述べました。これは、以前に発生した競合であり、彼は問題を抱えています。
したがって、このスプリントの前半では、2人の開発者と1つのテストリソースが、外部ベンダーの構成Webサイトでの作業、リソースのダウンロード、および証明書のシャッフルを監視しています。私は3つのスプリントでリリースされる予定であり、POが希望するバックログのほぼ全体を取得できることを知っていますが、誰もが座っている間はこれらのタスクで作業が行われていないため、そうなりません（er、群れ）最も優先度の高いストーリーのセットアップタスク。
私のスクラムマスターは、私たちの唯一の懸念は、スプリントに受け入れたストーリーを完成させることだと言っています。私は理解していますが、私たちは、製品の所有者から受け取った優先順位付けが引き起こしている「不良箱の梱包」を伝えないことによって、より大きな組織を失敗させているように感じます。
それでは、ストーリーと本質的に連続したストーリーとの間の依存関係の問題は、方法論によってどのように公式に処理されますか？
それでは、ストーリーと本質的に連続したストーリーとの間の依存関係の問題は、方法論によってどのように公式に処理されますか？
アジャイルの他のものと同様に：Individuals and interactions over processes and tools
プロセスが役立たない場合は、それを有用なものに成形します。このために、前提条件がクリアされるまで、優先度の低いストーリー（またはバックログには表示されない可能性がある技術的な負債/個人の成長）を引き込みます。もちろん、あなたがあなたのデューデリジェンスを実行したと仮定します本当にハードで速い前提条件です。多くの場合、インターフェースとモックは、本物の準備ができるまで作業のブロックを解除できます。
かんばんがスクラムに流れ込んだと私が思うかんばんの特徴の1つは、プロセス全体が個人ではなくteamに対して最適化されることです。言い換えれば、チームの誰かがスプリントの一部のために遊んでいるのは罪ではありません。
チームが全体としてXストーリーポイントを選択する場合、1人の担当者がすべての作業を行ったかどうか、または作業が均等に分割されたかどうかは、関係者にとって本当に重要ではありません。したがって、製品所有者がスプリントに持ち込まれるポイントの数に満足している場合（そして、これは製品所有者の呼び出しであり、スクラムマスターではありません！）、それが問題です。
もちろん、そうは言っても、チームメンバーの一部が最初のストーリーに直接関与していない場合、テストの作成や他のストーリーでできることを何でもすることに忙しい可能性があります。
最後の注意として、スクラムマスターは「かかとを掘り下げる」ことはほとんどありません。スクラムマスターは、バリアを設定するのではなく、生産性へのバリアを取り除くために機能している必要があります。チーム全体が優先度の低い別のストーリーを取り入れることができると感じた場合、それはチームの決定です。スクラムマスターはこの件に関して最終的な発言権はありません。
チームが若くてスクラムを習得している場合は例外がありますが、チームが成熟している場合は、スクラムの全体のポイントは、マネージャーではなくチームに力を与えることです。
私の見方では、2つの異なる問題があります。
- チームの生産性を最適化する方法。
- 依存関係に基づいて製品とスプリントバックログを注文する方法。
チームの生産性について、私はあなたのスクラムマスターに共感できます。人間の性質上、ほとんどの人はチーム全体を最適化するのではなく、全員を忙しく保ちたいと思っています。忙しいからといって生産性と同じではありません。アイドリングは、チームメンバーが特定の時間に行うのに最適な場合があります。
セットアップタスクの特定の問題について：これは自動化する必要があるように聞こえます。あなたの報告を踏まえて、私があなたのチームと一緒に働いていた場合、時間とブロックの両方があるこのセットアッププロセスで何が起こっているのかを理解するのに少し時間を費やしたいと思います。チームの有効性。
また、チーム内でこれを実行できるのはあなただけではないことを願っています。休暇があれば、このボトルネックプロセスを処理できる他の人がチームにいるといいのですが。群がることは、複数の人々がこれを行う方法を確実に学ぶチャンスであるかもしれません。
製品バックログアイテム（PBI）間に避けられない依存関係があると仮定すると、すべての依存PBIはblockedと見なされます。ブロッキング依存関係が解決されます。一般的に、これは、ブロックされたPBIをスプリントから除外することを意味します。ブロックする依存関係を制御できるため、依存するPBIをスプリントに組み込むことができますが、それは危険な動きのようです。スプリント計画では、通常、ブロックされていないPBIのみを検討することを期待します。
ただし、最終的に重要なのは、テスト済みの有用なソフトウェアを可能な限り効果的に提供するために最適な方法を見つけることです。
スプリントバックログを作成する（製品のバックログアイテム、つまりPBIを追加する）ための最大のルールは、基本的なINVESTの原則に従うことです。
- 独立：PBIは、他のPBIに固有の依存関係がないように、自己完結型である必要があります。
- 交渉可能：PBIは、反復の一部になるまで、いつでも変更および書き換えできます。
- 貴重：PBIは利害関係者に価値を提供する必要があります。
- Estimable：PBIのサイズを常に推定できる必要があります。
- 小：PBIは、特定のレベルの確実性で計画/タスク/優先順位付けが不可能になるほど大きくてはなりません。
- テスト可能：PBIまたはその関連説明は、テスト開発を可能にするために必要な情報を提供する必要があります
スクラムマスターがチームに最初のルールを強制するように思われるようですが、スプリント内のすべてのストーリーは独立している必要があります。他のストーリーを閉じるために完了する必要のある1つのストーリーでブロックされている場合はどうしますか？この場合、スプリントに失敗する可能性があります。
スワーミング/ペアプログラミングは、チーム内でコラボレーションして知識を共有するための良い方法であることに同意します。
ウィキペディアからコピー： https://en.wikipedia.org/wiki/INVEST_（mnemonic）