多くのスクラムチームの完了の定義
最近、スクラムフレームワークの使用を開始し、徐々に1チームから5チームに移行しました。私はスクラムマスターの役割を担っています。この数か月間、各開発チームは、製品所有者との定義の完了（DoD）に取り組みました。各チームは独自のDoDを取り決めました。各DoDにはいくつかの違いがあります。
現在、1人のプロダクトオーナーと5人のスクラムマスターがいるため、すべてのチームに独自のDoDを使用したいと考えています。国防総省を調和させるために何をすべきかを提案しますか？
私たちの議論から出てきた提案：
- 各スクラムマスターはプロダクトオーナーと協力して、チームに提示する新しいDoDを構築します。
- 各チームは、製品所有者と協力してチームに提示する新しいDoDを構築する代表（開発者）を選出します。
どちらの場合も、これは反復プロセスであり、各チームがフィードバックを提供して調整できます。
前もって感謝します！
共通のコアを共有する
完了の定義にコアアイテムの共通セットがあることは妥当だと思いますが、柔軟である必要があります。これらの共通の項目は、すべてのチームにとって明確に必要であり、それらを含める必要があるという議論がまったくないところまでです。
たとえば、すべてのチームが1つのアイテムとして「ユニットテストに合格しています」を持っている必要があります。もう1つの良い候補は、「バージョン管理にチェックインする必要がある」、「すべての受け入れ基準に合格する」ことです。
チームのエンパワーメント
各チームは、委員会の承認を必要とせずに、自由に変更できます彼ら自身の完了の定義。スクラムは約teamエンパワーメントです。チームに別の人またはチームが設計した「完了の定義」を強制することは、エンパワーメントではありません。
たとえば、一部のチームはピアレビューを必要とする場合がありますが、それがすべてのチームに適切であるとは限りません。一部のチームは、ユーザビリティの専門家からの購入を必要とする場合がありますが、これは通常、バックエンドで作業しているチームには関係ありません。チームによっては、コードカバレッジ要件が他のチームよりも厳しい場合があります。
スクラムはチームのすべてです
スクラムでは、焦点はteamです。それが製品所有者またはスクラムマスターによるもう少し多くの作業を必要とすることを意味する場合は、そうしてください。スクラムマスターの役割は、削除ロードブロッキングを追加することではなく、追加することです。
システムまたは製品のリリースに取り組んでいる複数のスクラムチームがある場合、すべてのスクラムチームの開発チームは、「完了」の定義を相互に定義する必要があります。
増分の「完了」が開発組織の規則ではない場合、スクラムチームの開発チームは、製品に適した「完了」の定義を定義する必要があります。
製品の「完了」の一般的な定義がないと、品質とその透明性に悪影響が生じます。 Doneの組織レベルの定義は最小限で技術的なものである必要があり、組織によって提供されることもあるため、普遍的に適用できます。組織はコーディング標準を提供する場合があります。組織は、製品ごとにそれを作成および保守するためのリソースを提供しながら、自動ビルドを必要とする場合があります。組織によって作成されたものでも、個々の開発チームによって作成されたものでも、「完了」の定義のどの部分でも価値をもたらす必要があります。
チームに固定プロセスを課すことを主張することは、アジャイルな方法で作業するという考えに反します。各チームは、最高に機能するように自由に編成できます。それが各チームに完了の独自の定義があることを意味する場合、それは最良の解決策として受け入れられるべきです。時間が経てば、チームが互いに話し合い、単一の定義で解決できれば、すばらしいことです。異なる定義が引き続き機能する場合は、そのままにします。
各チームは、独自のDoDについて交渉しました。各DoDにはいくつかの違いがあります。
整合性はその場所にありますが、それがないと発生する問題を特定するまで、解決策を見つけるのは困難です。
スクラム/アジャイルの利点は、チームが自分で管理できるようにすることです。チームが問題について合意に達することができない場合は、焦点を絞るのに役立つ可能性のあるいくつかの管理ルールを用意するとよいでしょう。また、メンバーが1つのチームから別のチームに移動するとき、すぐに適合することを期待して何を期待するかを知るのは素晴らしいことです。ここで修正または回避しようとしている問題はありますか？
だからあなたの質問に答えるには、あなたは皆の意見を得ようとするのにあなたは正しい道を進んでいると思います、しかしあなたは単一のDoDを忘れてそして各チームに調整させるべきであるような同意の欠如があることを発見する準備ができているべきですそして、彼らが適切であると思うように、このプロジェクトの過程で彼ら自身の意味を進化させます。
全員を巻き込んでいるにもかかわらず、ここではトップダウン/階層管理の領域に入ります。あらゆる状況ですべての人に厳格なルールを適用する際は、十分に注意してください。例外が発生するたびに5つの個別チームがDoDを継続的に改訂することは非常に困難です。