並列処理できないタスクをスクラムおよびスウォーミングする

私の現在のスクラムマスターは、公式のスクラムに屈することをいとわない真の信者です。私はこれが不確かに聞こえるようにしたくありません、私は過去に公式の用語で物事を再キャストすることによって彼と一緒に問題を解決することに成功しているので、この問題の正統な解決策について本当に尋ねています。

現在発生している問題の現在の例は、一部のストーリーの間に順序付けの依存関係があることです。（特に、開発の一部では、シングルシートライセンスしか持っていないサードパーティプログラムを使用しています。）これに関連するいくつかの必要なセットアップタスクがあり、「セットアップストーリー」にまとめられています。任意の順序で実行できるタスク。

問題は、現在のスプリントについて、セットアップストーリーと後続ストーリーの1つをプルしたことです。その時点で、スプリントが半分以下であっても、このグループでこれ以上のストーリーをとることはできないと述べました。このグループよりも優先度が低いバックログには無関係なストーリーがあり、スプリントに取り入れることをお勧めします。ただし、これらはすべて、このグループのストーリーの下で優先されました。この時点で、スクラムマスターは、「セットアップタスク」に群がってそれをより速く実行する必要があると述べました。これは、以前に発生した競合であり、彼は問題を抱えています。

したがって、このスプリントの前半では、2人の開発者と1つのテストリソースが、外部ベンダーの構成Webサイトでの作業、リソースのダウンロード、および証明書のシャッフルを監視しています。3つのスプリントでリリースされる予定で、POが希望するバックログのほぼ全体を取得できることはわかっていますが、誰もが座っている間はこれらのタスクで作業が行われていないので（er、群れ）最も優先度の高いストーリーのセットアップタスク。

私のスクラムマスターは、私たちの唯一の懸念は、スプリントに受け入れたストーリーを完成させることだと言っています。私は理解していますが、私たちは、製品の所有者から受け取った優先順位付けが引き起こしている「不良箱の梱包」を伝えないことによって、より大きな組織を失敗させているように感じます。

それでは、ストーリーと本質的に連続するストーリーとの間の依存関係の問題は、方法論によってどのように公式に処理されますか？

それでは、ストーリーと本質的に連続するストーリーとの間の依存関係の問題は、方法論によってどのように公式に処理されますか？

アジャイルの他のものと同様に： Individuals and interactions over processes and tools

プロセスが役立たない場合は、それを有用なものに成形します。このために、前提条件がクリアされるまで、優先度の低いストーリー（またはバックログには表示されない可能性がある技術的な負債/個人の成長）を引き込みます。もちろん、あなたがあなたのデューデリジェンスを行ったと仮定すると、それは本当に難しくて速い前提条件です。多くの場合、インターフェースとモックは、本物の準備ができるまで作業のブロックを解除できます。

私はスクラムにかけて出血を信じているかんばんの機能の一つは、そのための全体最適化しなどのプロセスであるチーム、個々のではありません。言い換えれば、チームの誰かがスプリントの一部のために遊んでいるのは罪ではありません。

チーム全体でXストーリーポイントを選択する場合、1人の担当者がすべての作業を行ったのか、または作業が均等に分割されたのかは（関係者にとって）重要ではありません。したがって、製品所有者がスプリントに持ち込まれるポイントの数に満足している場合（そして、これは製品所有者の呼び出しであり、スクラムマスターではありません！）、それが問題です。

もちろん、そうは言っても、一部のチームメンバーが最初のストーリーに直接関与していない場合、テストの作成や他のストーリーでできることは何でも忙しい可能性があります。

最後のメモとして、スクラムマスターは「かかとを掘り下げる」ことはほとんどありません。スクラムマスターは、バリアを設定するのではなく、生産性へのバリアを取り除くように機能しているはずです。チーム全体が優先度の低い別のストーリーを取り入れることができると感じた場合、それはチームの決定です。スクラムマスターはこの件に関して最終的な発言権はありません。

チームが若くてスクラムを習得している場合は例外ですが、チームが成熟している場合は、スクラムの目的はマネージャーではなくチームに力を与えることです。

私の見方では、2つの異なる問題があります。

1. チームの生産性を最適化する方法。
2. 依存関係に基づいて製品とスプリントバックログを注文する方法。

チームの生産性について、私はあなたのスクラムマスターに共感できます。人間の性質上、ほとんどの人はチーム全体を最適化するのではなく、全員を忙しく保ちたいと思っています。忙しいからといって生産性と同じではありません。チームメンバーが特定の時間に行うのは、アイドリングが最善の方法です。

セットアップタスクの特定の問題について：これは自動化する必要があるように聞こえます。あなたの報告を踏まえて、私があなたのチームと協力していた場合、このセットアッププロセスで何が起こっているのかを理解するのに時間をかけたいと思います。チームの有効性。

また、少なくともチームの中でこれを実行できるのはあなただけではないことを願っています。休暇がある場合は、このボトルネックプロセスを処理できる他の人がチームにいることを願っています。群がることは、複数の人々がこれを行う方法を確実に学ぶチャンスであるかもしれません。

プロダクトバックログアイテム（PBI）の間に避けられない依存関係があると想定すると、ブロッキングの依存関係が解消されるまで、依存しているすべてのPBIがブロックされていると見なします。一般的に、これはブロックされたPBIをスプリントの外に残すことを意味します。ブロックする依存関係を制御できるので、依存するPBIをスプリントに取り込むことができますが、それは危険な動きのようです。スプリント計画では、通常、ブロックされていないPBIのみを検討することを期待します。

ただし、最終的には、価値のあるテスト済みの実用的なソフトウェアを可能な限り効果的に提供するために最適な方法を見つけることが重要です。

スプリントバックログを作成する（製品のバックログアイテム、つまりPBIを追加する）ための最大のルールは、基本的なINVESTの原則に従うことです。

1. 独立： PBIは、他のPBIに固有の依存関係がないように、自己完結型である必要があります。
2. 交渉可能： PBIは、イテレーションの一部になるまで、いつでも変更および書き換えできます。
3. 貴重： PBIは利害関係者に価値を提供する必要があります。
4. 推定可能： PBIのサイズを常に推定できる必要があります。
5. 小： PBIは、特定のレベルの確実性で計画/タスク/優先順位付けを行うことが不可能になるほど大きくすべきではありません。
6. テスト可能： PBIまたはその関連説明は、テスト開発を可能にするために必要な情報を提供する必要があります

スクラムマスターがチームに最初のルールを破るように強制しているようですが、スプリント内のすべてのストーリーは独立している必要があります。他のストーリーを閉じるために完了する必要がある1つのストーリーでブロックされている場合はどうしますか？この場合、スプリントに失敗する可能性があります。

群がる/ペアプログラミングは、チーム内でコラボレーションして知識を共有する良い方法であることに同意します。ただし、このようなものに群がる必要がない場合、私はあなたの銃に固執し、INVESTを引用します:)

ウィキペディアからコピー：https : //en.wikipedia.org/wiki/INVEST_（ニーモニック）