プロジェクトとチームについて少し。
説明したプロジェクトは、スクラムを完全に適用することにした最初のプロジェクトです。
これに先立ち、彼らはイテレーションに取り組みましたが、スタンドアップラリー、レトロスペクティブ、デモはありませんでした。
2つのチームがプロジェクトに取り組んでいます。
チーム1は、チーム2が開発している特定のアプリケーションのデータが準備されるワークフローシステムを作成します。
このため、特定の反復では交差し、互いに非常に依存しています
だから。
1.チーム全体が計画に参加する必要があります
練習から：
プロジェクトの最初のイテレーションを計画するとき、彼は2人の開発者（VasyaとPetya）を招待しませんでした。
その結果、反復の最初の週の半ばに、作業の一部が考慮されず、取締役会で修正されなかったことが明らかになりました。
結果：
作業の不正確な評価と下請業者へのデータ送信の遅延 この繰り返しで、隣接するチームは私たちに大きく依存していました。
2. 1つのチーム内のタスク間の依存関係の制御
練習から：
開発は、2つのテクノロジーの接合部で実行されます。 反復の開始時に、開発者は反復の終わりに向かって「収束」することに同意し、時間が来た時点で、まだ準備ができていません。
結果：
計画されたストーリーは時間通りに完了しません。 2番目の開発者は、アイドル状態か、より低い優先度でタスクを実行するよう強制されます。
対処方法：
各スタンドアップラリーでは、チーム内の開発者が「クロックをチェック」する必要があります。 全員がバトンデータの転送予定日を表明する必要があります。
誰かに時間がないことが判明した場合、対策を講じる必要があります-支援するために別の開発者を追加するか、他のタスクからアンロードするか、または... チームおよび状況に応じたソリューションが常にあります
また、視覚化と制御のために、識別されたすべての依存関係をボードに配置する必要があります。
ボードには、「Vasya must Pete」、「Petya must Masha」などのステッカーが貼られた別の領域があります。
主な依存関係は、計画時に特定して記録する必要があります。
さらに、反復中に、各チームメンバーはタスクの依存関係を決定し、計画中に考慮されなかった場合はボード上でそれらを修正する必要があります。
私たちの現実における詳細なスプリント計画は神話なので、これは頻繁に起こります。
3.チーム内の取り決めを修正する
練習から：
開発は、2つのテクノロジーの接合部で実行されます。 1つのテクノロジーと別のテクノロジーを使用して、まったく同じ要件を満たすことができます。 小規模なタスク（一部は大規模）について説明します（フィールド検証など）。
チームメンバーは、タスクがテクノロジーNで実行されることに口頭で同意するか、このタスクはテクノロジーNで簡単に実行でき、一方でテクノロジーJでも簡単に実行できると積極的に主張しますが、最終的に誰がタスクを実行するかを決定することなく同意します。
一般的に、私たちはチャットして解散しました。
それは深刻に見えないかもしれませんが、私たちの場合、それは反復の1つで起こりました。
結果：
タスクは完了しませんでした。 大きなタスクの完了期限が来たとき、フィールドの形式は隣接するチームに適さず、すぐに行う場合よりも多くのやり直しが必要でした。
対処方法：
すべての口頭での合意は、すぐに特定のパフォーマーのタスクに変換する必要があります。
これは、すべてのチームメンバーが監視する必要があります。
4.依存関係のあるタスクに関する関連チームとの対話
練習から：
チーム1は、チーム2のデータのリターンを実装し、他のタスクについて設定しました。 3日後、チーム2はチーム1に移行しました-データは注入されません/データは無効です。
結果：
チーム2は、チーム1が既に提供したデータを待機しています。
このシンプルなものは、今でもみんなに戻ってきました。
対処方法：
1.チーム2では、データを「受け取る」開発者が決定されます。
2.タスクの作業を完了した後、チーム1の開発者はチーム2の開発者に「完了、確認」を通知します
3.依存関係タスクがテストに入ったスタンドアップミーティングの後、チーム1のスクラムマスターはチーム2のスクラムマスターに通知します。
4.チーム2がデータの受信を確認した後、タスクはボード上の準備完了に転送されます。
5.タスクの評価を正しく行うか、スプリント中にそれらを過大評価することを恐れないでください。
練習から：
「進行中」のボード上で数日は、数時間と推定されるタスクをハングさせます。
その理由は、開発者が何らかのバグに遭遇し、すぐにそれを把握できないからです。
意見：そのようなタスクが頻繁に「進行中」にハングする場合、ボードは「フロー」の効果を失います
対処方法：
- そのようなタスクを強調する必要があります
- 古い評価を取り消して新しい評価を付けます。
- タスクが他のユーザーと接続されており、テールを引っ張っている場合、可能であれば関連するタスクを再配布する必要があります（別の開発者に割り当てます）
- タスクの価値を再評価します-おそらくこの段階で延期すべきです
6.責任は、スクラムマスターだけでなく、チームが負うべきです。
練習から：
いくつかのスタンドアップラリー中に、スクラムマスターは下請業者に必要なデータを提供することが義務付けられましたが、最終的には、さまざまな理由でこれが行われませんでした。
結果：
隣接するチームは、1つまたは別のチームを信頼できないという意見を形成します。 チームはお互いに依存しているため、これは悪いことです。
チームが責任を負わない限り、行われていない作業に責任を感じません。
出力の代わりに
最初の繰り返しに失敗しました。
振り返って状況を調べた後、ここでの主なことは、開発者に責任を委ねることではなく、開発者自身が責任を引き継ぐようにすることです。
自信を持って余裕を持って時間通りに次の反復を完了しました。
そして、チーム内で明らかな、そうではない状況が反復の失敗につながったのは何ですか？