スクラムで疎結合サブプロジェクトを処理するにはどうすればよいですか？
私たちは、外部の理由でスクラムっぽいやり方で実行しなければならないプロジェクトです。私たちは2つのサブプロジェクトで構成されています。私が参加しているバックエンドデータおよびサービスプロバイダーと、それとやり取りするUI + BPMレイヤーです。
バックエンドは他のいくつかのコンシューマーにも対応し、両方の部分が（異なるベンダーによって）2つの完全に異なるスタックに実装されます。どちらの開発者も、ベンダーのツールセットの専門家であり、他のそれぞれのテクノロジーや機能設計についての知識はありません。それは私たちが毎日のスタンドアップミーティングで他の人たちが何について話しているのかを少しも理解していないところまでであり、私たちは通路の反対側からストーリーを推定することは完全に不可能です。
もう1つは、まだ一緒にリリースしなければならないことです。同じ部屋に座って対話する多くのポイントがあります。 PM、PO、SMは同じで、一部のテスターは両側で作業します。合計で、毎朝のミーティングでは、7-9人の開発者と3-4人のテスターと他のいくつかの役割があります。予算、ライセンス、時間の理由から、他のスタックまたは機能設計について簡単にトレーニングすることはできません。したがって、予算とプロジェクトスポンサーシップの観点からは、これは1つの大きなプロジェクトですが、内部から見ると2つのプロジェクトになる可能性が高くなります。
最初は、スタンドアップ、レビュー、レトロ、プランニングを1つのチームとして行いましたが、個別の改良を行いました。しばらくして、スプリントの変更における退屈への不満がレビューにつながりました。レトロと計画は2つの異なる予定に分割され、スプリントは1週間離れて終了しています。
この設定でスクラムのようなものをどのように実装しますかインクルーシブを毎日実行し続けることに価値はありますか、それとも分割する必要がありますか？それをまとめると、どうすれば改善できるでしょうか。それを分割した場合、チーム間の重要な質問に確実に対処するにはどうすればよいですか？
私は実際に一歩下がって質問をします-あなた自身の満足のために-チームと同様に-「問題はありますか？」そして、最初の答えが「はい」の場合、「問題は何ですか？」.
次に、質問-「なぜスクラムなのか？」外部の理由がある場合でも、チームにとってより効果的なものを確認することは価値があります。直面している特定の問題に対処するためにプロセスをどのように変更すれば、「スクラムをより適切に実装するにはどうすればよいですか」という観点から見るのではなく、「ソフトウェアをより良く/より速く配信するにはどうすればよいですか？」そして、チームはより幸せで、退屈が少なく、より熱心で生産的ですか？」 -その問題を解決するためにチームに協力してもらいます。
これが理にかなっている場合、私が提案するアプローチの1つは、カンバンの原則を適用して（作業/ワークフローを視覚化し、プルとWIP制限を実装し、フローを管理/最適化して）、スクラムチームのパフォーマンスを改善することです。すべてのソフトウェアネイルに「かんばんハンマー」を使用していると非難される可能性がありますが、「スクラムをより良くする」ことはより良い場所に到達するのに役立つと結論する前に、状況をより深く分析して理解する必要があると思います。
カンバンの原則の適用があなたのためにするいくつかの特定のこと-
カンバンボード上の別々のスイムレーンで2つのチームの作業を管理し、他のチームが何をしているか、どのように負荷がかかっているか、ボトルネックがどこにあるかなどを、両方のチームに簡単に視覚的に理解できるようにします。
配信は分離されているため、同期する複数のオプションを確認できます。技術的な債務削減などの「無形の」作業を行う機会を両方のチームに提供しながら、顧客リリースをまとまり、統合し、一貫した方法で作成します。その過程で、任意のプロセス定義によって課される2週間または3週間の人為的なタイムバケットを変更または削除することを決定する場合があります。
以下に示す例では、各チームが独自のケイデンスで統合用のコードをドロップし、ビジネスに必要なケイデンスで統合後のプロセスを実行できます。チームのいずれかがリリースイベントの間に余裕を持っていた場合、無形のレーン（技術的負債）で作業を拾い、他のチームが作業を完了するのを待っている間にそれらを実行できます。
しばらくの間、この方法でリリースを続けるか、リリースを行うコスト（努力）が待機コスト（機会コスト/市場投入までの時間）よりも低い場合は、より継続的なデリバリーモデルに移行します。 ）。 （このアプローチ（スクラムバン/カンバン）にまだ出会っていない場合は、ここで詳細を読むことに興味があるかもしれません-" スクラムバンとは ？"
状況
あなたはプロジェクトを非常に疎結合であると説明し、それらが2つの異なるプロジェクトであった場合：
- さまざまなチームメンバー。各チームは非常にまとまりがあります（私たちとそのチーム）
- 異なる技術スタック
- 終了するスプリント
- 要件への別の焦点
一方で、これらのプロジェクトは相互に関連しています。
- バックエンドのユーザーストーリーは、フロントエンドを完全に切り離して考えることはできません。これが両方に1つのPOしかない理由です
- テストを統合する必要があります。これが、一部のテスターが両方で機能する理由です。
- 一方が他方なしに存在する可能性はありますか？
実際、それらは相互に関連しているため、PM、PO、SMが1つだけ存在し、プロジェクトの外部の誰もがそれを1つと見なしているようです。火がなければ煙はありません...
改善する方法？
経験上、異なるチームが互いに話さないことは、最終的に 悪いアーキテクチャの問題 になることを示しています。統合されたコンポーネントには、統合された設計と相互理解が必要です。
もちろん、退屈でリソースの浪費は避けなければなりません。
毎日のスクラムから始めましょう。毎日のスクラムは 15分 で、これ以上はありません。それはせいぜい7'30 "で、チームの半分が退屈する可能性があります。チームの規模により、1人のチームメートが話すのに1分かかります。ここでどのように退屈することができますか？また、1つのチームに変更または遅延がある場合、他の人は知らないのですか？
したがって、一般的な毎日のスタンドアップを維持します。しかし、それが15分以上であることを確認してください。これが達成できない場合は、合同会議のトピックを選択する毎日のサブチームスタンドアップを編成し、10分ごとに行います。これは、1日あたり効率的に使用される20分です。
これで、スプリント計画は密接に関係するはずであり、そうすることで、フロントエンドが必要なものを必要なときにバックエンドから取得できるようになります。しかし、各サブチームは自分の作業の見積もりを提供する必要があります。反対側の作業を見積もるのはばかげています。これはデータの信頼性を損ない、誤った決定を引き起こし、それゆえトラブルを引き起こすだけです。そして、それぞれの計画には、あまりにも詳細すぎて一般的には興味のない部分があります。これはサブチームでも実行できます。
レビューとレトロは、サブチーム内で最初のディスカッションを行った後、エスカレーションする対象を決定できるため、プロジェクト全体で共通の理解が必要です。
それがまだ長すぎる場合
私は、通常4〜7個のサブチームを抱える大規模な機能横断型プロジェクトに深く関わっていました。この場合、誰とでも頻繁に会うことは難しい。したがって、代替案はカスケードアプローチです。すべてのチームが会議を行い、チームの代表がグローバルミーティングに参加します（期待と異なる場合はグローバルな結果をフィードバックします）。ただし、これは現在のコンテキストではやり過ぎかもしれません。
これが長時間実行プロジェクトの場合は、チームを分割します。はい、それはかなり抜本的です。ただし、あなた自身は基本的に2つのチームを扱っていることをすでに認めています。
重要なinterteam質問に確実に対処する方法
関係する人の数を見て...
私たちは7-9人の開発者と3-4人のテスターといくつかの他の役割です
... 2つのチームを作成しても問題ありません。スクラムは、1つのチームで9人以下を提唱しています。はい、あなたはスクラムっぽいですが、それでも。
分割後、各チームはそれぞれの製品に完全に集中できます。両方のチームの製品所有者とスクラムマスターが同じであってもかまいません。要件のソースが1つしかないため、同じPOを持つことで、利害関係者の期待に沿うことが容易になります。
これで2つの部分を統合します。はい、多少の労力が必要になります。技術的な観点からは、2つの部分を統合する継続的ビルドシステムが優れています。さらに重要なのは、チームがコミュニケーションを取り、互いに話し合い、定期的に再調整する必要があることです。チームごとのメンバーを他のチームの統合アンバサダーとして任命することもオプションの1つです。権限を与えられたチームは、自分の作業を他の人が行った作業と効率的に統合する方法を見つけます。彼らはすでにそうしていますよね？
これが難しい場合は、 Scrum Nexusガイド をお勧めします。これは、大規模なマルチチームセットアップを目的としており、やり過ぎのように見えるかもしれませんが、2つのチームの場合でも、ガイドには統合を合理化するための多数の優れたコンセプトが含まれています。いつでもいくつかのアイデアを選んで、チームに役立つものを試すことができます。