複雑なアジャイル環境での依存関係の管理

記事「大規模アジャイル環境での依存関係管理」の翻訳。

短いレビュー

Salesforce.comの開発部門には、同じバージョン管理ブランチの共通コードで共同作業する30以上のスクラムチームが含まれています。 この記事では、セールスフォース・ドットコムがスクラムアプローチを拡張し、チームの相互作用を管理するために使用する方法について説明します。

1はじめに

2006年10月、salesforce.comの開発および開発（R＆D）部門は、ウォーターフォールモデルからスクラムベースのアジャイル手法への大規模な移行を開始しました。 その時点で、以前のメジャーリリースから10か月が経過し、新しいリリースのリリース日はすでに5回延期されました。 製品がめったに生産されず、深刻な遅延を伴うことに多くの人が怒っていました。 リリースが完了するのを待たずに、既存のチームをスクラムチームに再編成し、スクラムプロセスを使用して、2007年2月にリリースをリリースしました。 それ以来、新しい柔軟なアプローチを使用して、SaaSアプリケーションのセットとForce.comプラットフォームの5つのメジャーリリース（3〜4か月間継続）をすでにリリースしています。 それらのそれぞれは、スケジュールされた日に正確に行われました。



再編成中、私たちは個々のチームのスクラムの推奨事項に従いましたが、チーム間の相互作用にはあまり注意を払いませんでした。 チームを編成して、チーム間の依存関係を最小限に抑えようとしましたが、コードは一晩で変更されなかったため、多くの関係が残っていました。 すぐに、スクラムオブスクラムミーティングを導入しました。 これらの会議は、問題や状況を議論するのに役立ちましたが、会議だけでは十分ではありませんでした。 最後の5つのリリースに取り組んで、チームの相互作用を改善する追加のアプローチを試し、洗練しました。 この記事の後半では、依存関係管理のいくつかの問題と、これらの問題をどのように克服するかについて説明します。

2チーム構造

salesforce.comの製品開発は、アプリケーション、プラットフォーム、コアインフラストラクチャの3つの部門で構成されています。 これらの3つのユニットには、合計30を超えるスクラムコマンドが含まれています。 各スクラムチームには、開発者、テスター、プロダクトオーナー、およびスクラムマスター（通常は開発者、テスター、またはプログラムマネージャーの頭）がいます。 複雑な機能の場合、スクラムチームは他の機能チームの代表者も引き付けます。たとえば、システムテスト、ドキュメント、UIデザイン、ユーザビリティ、テクノロジーオペレーション、リリースエンジニアリングなどです。

通常、すべてのスクラムチームは、同じコードブランチの同じリリースで作業します。 当社の製品は相互に接続されているため、異なるチームの機能は、機能的にも技術的にも非常に密接に絡み合っています。 技術的な実装の観点から、多くのチームは共通のコードを使用します。 機能面では、同じエンドユーザーの機能に取り組んでいるチームは、調和のとれた一貫したユーザーエクスペリエンスを作成するために密接に連携する必要があります。

3依存関係管理が難しいのはなぜですか？

非常に多くのチームが1つのリリースに取り組み、共通の機能を導入し、一般的なコードを変更すると、開発プロセス中に遭遇するすべての問題、驚き、変更、失敗、成功を予測することは不可能です。 この予測不可能性は、依存関係管理が非常に難しい理由の1つです。 このセクションの後半では、さらにいくつかの理由に注意します。 すべての決定は、これらの基本的な対立と課題に向けられるべきです。

3.1システムの複雑さ

依存関係を識別することは、それらを管理する最初のステップです。 多くの成熟した製品と同様に、salesforce.comシステムは複雑すぎて、1人の個人またはチームがすべての関係を把握して記憶することができません。 中毒を特定し、認識するために、私たちはますます多くの人々の集合的な知識に頼らなければなりません。 そのような知識を組み合わせて、人々と情報をそれを必要とする人々と結びつけることが不可欠です。 提案された変更の依存関係と結果を決定する重要な役割は、システムを広く理解している専門家によって果たされます。 ただし、システムが成長し、より複雑になると、知識の専門化と断片化を避けることは困難です。 さらに、現在の変更数では、各新機能の詳細を専門家に確認するよう依頼することは実用的ではありません。 このような変更に特別な注意を払うために、他のチームの作業に影響を与える（または依存する）可能性が高い変更を識別する方法が必要です。 もちろん、これはそれほど簡単ではありません。比較的小さな変更がシステム全体に深刻な影響を与える場合があるためです。

3.2優先順位の競合

依存関係は、チーム間の競合につながる可能性があります。 あるチームが他のチームに何かをしたい場合は、これらのチームのプロダクトオーナーがこの作業について話し合い、優先順位を付けます。 議論の結果に基づいて、期限に同意することが可能であれば、将来、この依存関係を管理することは非常に簡単です。 明確な合意に達していない場合、または作業の優先度がまだ低い場合、この関係に関する不確実性とリスクのレベルが高まります。



あるチームが別のチームに作業を追加する変更を加えた場合にも、競合が発生します。 たとえば、あるチームがアーキテクチャを変更した場合、残りのチームはこれらの変更に適応する必要があります。 変更が他のチームに明らかなメリットをもたらすとは限らないため、特に突然現れた場合、人々は気分を害し、追加の作業の外観に腹を立てることがあります。 私たちは初期段階でそのような依存関係を特定しようとしますが、すでに行われた変更のため、または優先順位のレビュー後に、それらのいくつかは必然的に後で現れるようになります。

3.3計画の変更

スクラムの利点の1つは、スプリントごとにチームの優先順位を変更できることです。 ただし、これにより依存関係の作業が複雑になります。 リリースサイクルの最初の段階で、すべての依存関係を特定して検討することはできません。 関係分析は、継続的で継続的なプロセスに似ています。 作業が進むにつれて、依存関係が現れたり消えたりしますが、チームは何をする必要があるかを詳細に調整します。 したがって、このような依存関係を管理するプロセスは動的でアクティブでなければなりません。

3.4リリースサイクルが短く重複している

リリースサイクルが短いと、チーム間の調整時間が短くなるため、関係とその影響を早期に特定する必要があります。 salesforce.comでは、新しいリリースの計画は前のリリースが完了する前に開始されるという意味で、リリースサイクルが重複しています。 これは意図的に行われました。一部のチームは既に解放されており、新しいリリースの作業を開始する可能性があるためです。 ただし、残りのチームは計画が遅れ、次のリリースの依存関係の説明をスキップする場合があります。 これは、関係を明確にするための集団的知識の重要性を考えると、深刻な問題です。

4特別なアプローチ

このセクションでは、依存関係を管理し、上記の問題に対処するために使用する特定のアプローチについて説明します。 これらのアプローチで使用される一般的な戦略：

• リリース計画、関係、プロジェクト、ビルドステータスなどを周知します。
• チーム間の議論と知識共有のためのプラットフォームを編成するため。
• 自己組織化と分散型の関係管理を奨励します。
• 自動化、自動化、そして自動化。

4.1リリースの開始

現在のメジャーリリースのリリースの約1か月前に、次のリリースのキックオフミーティングを手配します。 会議には会社の全従業員が参加します。 ビジネスユニットの副社長は、各チームが新しいリリースで取り組む予定の機能を一般的な用語で概説します。 この会議は、関係を管理するのに役立ちます。 まず第一に、それはチームが意図された日付の最初のリリース計画を準備することを奨励します。 チームが現在のリリースからの作業が不完全な場合、このチームは次のリリースの計画を遅らせ始めます。 この場合、会議は予定より早く計画するのに役立ちます。 依存関係を特定し、それが何をするのかわからないチームと義務について議論することは困難です。 キックオフミーティングは、チームの同期ポイントとして機能し、チームインタラクションの生産的な議論を確実にします。



また、会議の後、チームのリリース計画が周知されます。 私たちはすべてのチームが何をしているのかについて高い意識を獲得するよう努めています。 すべてのR＆Dリーダーがキックオフミーティングに参加し、人々を惹きつけ、リリース計画に集中するのを助けます。 高レベルの参加は、期待を調整し、リリース計画について取締役会に通知するのに役立ちます。



もちろん、計画はプロセス内で変更および変更できます。 少し前に、毎月のスプリントレビューの間に、打ち上げミーティングの更新されたプレゼンテーションのレビューを開始しました。 更新されたプレゼンテーションには、どの機能が除外または追加されたかが示され、リリース中の計画の明確さと宣伝を維持するのに役立ちます。

4.2関係セッション

初期リリース計画を準備しておくと、チームは関係をより密接に議論でき、そのような議論の多くは自然発生的に起こります。 これに加えて、すべてのチームの代表者が協力して作業する場合、関係を特定するためにより正式なセッションを実施することは非常に価値があると考えました。 この会議で発表された計画の質を向上させるために、リリースの打ち上げ会議の直前にそのようなセッションを実施することが最も有用です。



関係識別セッションは非常に簡単です。 すべてのスクラムチームの代表者（ほとんどの場合、スクラムマスターまたはプロダクトオーナー）は、大きなボードのある部屋に集まります。 セッションの最初の部分では、すべての参加者がボード上のチーム間の依存関係の2つの図を同時に描きます。 1つの図は、別のチームが何かをする必要があるチームを示しています。 2番目の図は、他のチームの作業に影響を与える何かをしているチームを示しています。 これらの図には、いくつかの簡単なルールを使用します。

• 円はチームを示します。
• 円の間の矢印は関係を示します。 最初の図では、作業を実行するチームからこの作業の結果を必要とするチームに矢印が描かれています。 2番目の矢印は、他の作業の影響を受けるチームを示しています。
• 矢印のラベルは、依存関係の本質を説明しています。
• 依存関係が合意された場合（つまり、他のチームがその役割を行うことに同意した場合）、ラベルの周りにフレームを描画します。

最初は混乱が支配しますが、誰もが自分の関係を引き出し、オブザーバーは質問をして追加の依存関係を指摘します。 約20分後、チャートが安定し、コメントがなくなります。 その後、各チームの代表者に依存関係について簡単に話してもらいます。



非常に短い時間で、リリースの関係の全体像を作成します。 図 図1は、読みやすくした後の典型的なセッション結果を示しています。 ホットスポットはすぐに識別されます（つまり、多数の依存関係を持つチーム）。 一貫性のない依存関係を持つチームも表示されます。 そのようなチームは、関係が合意されるまで計画を達成しないリスクが最も高くなります。





図1 相互依存関係チャートの例

4.3公開討議

最近、キックオフミーティングから1週間以内に、オープンミーティングを開催しました。その主な目的は、チームのリリース計画に関連する問題を議論するためのプラットフォームを作成することです。 これらの会議には、各スクラムチームから少なくとも1人の代表者が参加する必要があります。そうでない場合、参加する必要はありません。 通常、公開会議の開始時に、参加者はディスカッションのトピックを提案します。 その後、45分以内にグループのトピックについてディスカッションが行われ、グループはディスカッションの結果について残りの部分を話します。 ほとんどの場合、参加者は、他のチームに影響を与える変更についてだけでなく、新しい便利な機能の詳細を学びたいと考えています。 開かれた会議の参加者は、このような議論の有益性に留意し、さらに、通常の仕事ではやり取りしない他のチームの同僚とコミュニケーションを取ることは興味深いと感じました。 オープンミーティングはまだ新しい形式であるため、次のようなさまざまなオプションを試して、何がより効果的に機能するかを理解します。

• 会議の前にアイデアを提案する。
• 高い権限を含む。
• ディスカッションの数と期間を変更します。

4.4設計の概要

機能設計レビュー会議の主な目標は、製品の品質と使いやすさの全体的なレベルを向上させることです。

• 製品チームの集合的な知恵と創造性。
• 製品間の設計の一貫性の向上。
• チーム間の知識の交換から生じる相乗効果。

これらのクロスチーム会議は、重要、最も複雑、または特にリスクがあると考えられる機能の機能設計とユーザーインタラクションに焦点を当てています。 このような会議では、以前に検出されなかった不整合および依存関係を分析および特定するよう努めています。



このような会議には、主に2つのタイプがあります。 リリースサイクルの初期段階では、参加者は設計概念に焦点を当て、既存の機能と新しい機能の間の一貫性と効果的な相互作用を達成するよう努めます。 この段階では、通常、製品所有者とユーザーインターフェイスデザイナー（UI）が会議に参加し、場合によっては開発やQAなどの他の機能チームの代表者も参加します。



リリースサイクルの途中で、参加者の構成は変化しています。現在は主にQAと部分的な開発の代表者であり、実装の詳細に焦点が当てられています。 これらの会議は、以下に関する理解と明確さを提供します。

• チーム間の追加の関係。
• 計画に含める必要がある追加の統合テスト。
• 個々の機能のリスク、および場合によっては-機能へのアクセスを制限する必要性。
• 展開の特定のタスク。

4.5仮想アーキテクチャチーム

Virtual Architecture Team（VAT）は、すべてのスクラムチームの開発者が含まれているため、「仮想」です。 チームメンバーは、アプリケーション、プラットフォーム、またはコアインフラストラクチャビジネスユニットのスクラムチームの一部として、コアの責任から中断することなくVATで作業します。



VATは、ソフトウェアのアーキテクチャのサポートと開発を担当しています。 チームは、アーキテクチャ開発のロードマップを定義し、アーキテクチャの観点から主要な変更をレビューし、コードの互換性とサポートを確保するためのコーディング標準を決定します。



VATは、重要な建築プロジェクトのバックログと必要なリファクタリングを管理します。 製品の開発に伴い、機能を再設計し、古い最適でないコードを削除する必要があります。 開発者は、プログラムのコードが多くを残していることを理解している場合でも、既に実行中のプログラムを変更したくない場合があります。 プロダクトオーナーは、すでに機能しているものをどのように作り直すかよりも、新しい機能がどのように開発されるかを見るのを好みます。 このようなムードに対処するには、各ビジネスユニットは、VATが推奨する変更について、各リリースで少なくとも20％の時間を計画する必要があります。



VATは、スクラムチームによって作成された製品と機能の技術的な実装を確認するために、週に2回、2時間収集されます。 最も複雑なリリース機能に取り組んでいるチームは、VATを提出する必要があります。 VATは、技術的な決定が他のチームにどのように影響するか、他のチームの開発が機能にどのような影響を与えるかについて、スクラムチームにフィードバックを提供します。 VATは、主に技術的な実装、特にスケーラビリティとパフォーマンスの側面に焦点を当てています。 機能の設計に大きな変更が必要な場合、スクラムチームは同じリリースサイクルで機能を再送信し、VATに設計の変更方法を示す義務があります。

4.6継続的インテグレーション

自動化されたアセンブリ、テスト、およびソート（トリアージ）のためのWebベースのインフラストラクチャにより、ビルドシステムが継続的に統合され、コードの各行のステータスを監視できます。 このインフラストラクチャは、すべての開発者とQAエンジニアが共通のコードベースで作業できるようにする重要な側面です。



JUnit拡張機能上に構築されたメインテストスイートを使用すると、Force.com APIを使用して機能テストを作成できます。 さらに、Seleniumを使用してUIを介して実行する必要があるテストケースを自動化するユーザーインターフェイステストフレームワークがあります。



自動化へのアプローチを定義するいくつかの基本原則を以下に示します。

1. 開発者が迅速にフィードバックして、変更の結果を確認できるようにします。 各コミットは、ビルドの構築と一連のテストの実行を開始します。 エラーが発生した場合、責任あるエンジニアはすぐにエラーメッセージを受け取ります。 基本的な一連のテストは30分で完了し、開発者は自分が行った変更の検証結果を受け取ります。 1日を通して定期的に、一連の拡張テストが実行されます。
2. ビルドをすばやく修復し、障害をテストします。 これを行うには、所有者を毎週変更する「アセンブリウィザード」の役割があります。 通常、この役割は、密接に相互作用する2人の人々、つまり開発マネージャーとシニア開発者によって果たされます。 ビルドウィザードは、ビルド結果の確認、さまざまなコード行のテスト履歴とエラーの追跡、および修正のために特定の開発者にバグを割り当てる役割を担います。 データベースに収集されたテスト結果（テストの成功率、ビルド時間、失敗数など）に基づいてさまざまなメトリックを表示する特別なパネルがあります。 アセンブリウィザードはこのデータを使用して、アセンブリステータスレポートを準備します。
3. 自動テストで高レベルのカバレッジを維持します 。 通常、スクラムチームは、自動テストでコードの70〜80％をカバーする傾向があります。 当社の最も重要な資産の1つは、3〜4か月ごとに高品質のリリースを提供する上で重要な役割を果たす一連の自動テストです。

4.7スクラムオブスクラム

すべてのビジネスユニットは、Scrum-of-Scrumsの毎週の会議を開催し、Scrum-of-Scrum-of-Scrumsがあります。 時々、共通の目標で密接に連携するチームのグループのために追加のスクラムオブスクラムを編成します。 いくつかの異なるScrum-of-Scrums形式を試しました。 チームは、標準の「4質問」形式から始めました。チームが何をしたか、何をしようとしているのか、何をブロックしているのか、他のチームの作業に影響を及ぼす何かをしているのかを報告するときです。 最初はうまくいきましたが、チームの数が多いためすぐに退屈で退屈になりました。 その後、参加者が議論のためにトピックを提案し、会議の最初にボードにそれらを書き出すとき、私たちはよりオープンな形式の自己組織化に進みました。 これにより、参加者は集会の内容に責任を負わされ、より生産的な議論につながりました。 クロスコマンド依存関係の問題は、特に開発の初期段階で、スクラムオブスクラム中に頻繁に発生します。 スクラムオブスクラム中に関係認識セッションが開催され、今後2週間から3週間にわたって、この会議ではコマンド間の依存関係の変更について頻繁に議論されます。

4.8ステータスレポート

チームがスクラムに切り替えると、書面によるレポートが不要になることがよくあります。これは、他の事項（スプリントレビュー、バーンダウンチャート、毎日のスタンドアップミーティング）によって状態が明確になったためです。 スクラムに切り替えたとき、すべてのスクラムマスターが準備する軽量の週次ステータスレポートを保持することにしました。 Scrum-of-Scrumsに「4問」形式を使用している間は冗長に見えました。 ただし、現在開かれているスクラムオブスクラム形式では、週次レポートがこの会議に重要な追加となっています。 Scrum-of-Scrumsの各チームのステータスについては、個別の問題として提出されない限り、説明しませんが、このステータスは週次レポートで常に確認できます。 レポートは、すべての依存関係、ブロッカー、リスクを特定します。 もちろん、このようなレポートにはスクラムマスターの多少の余分な労力が必要ですが、レポートを提供することでレポートを作成するコストが正当化されます。

5結論

Salesforce.comは、Scrumの拡張性が実現可能であることを証明しており、会社の成長に合わせて拡張を続けることができると確信しています。 チームの数が増えるにつれて、関係管理とチームの調整は困難なタスクになります。 堅牢なビルドと自動化されたテストインフラストラクチャが重要です。 キックオフミーティング、リレーションシップディスカバリセッション、スクラムオブスクラム、および軽量ステータスレポートにより、認識と同期が非常に役立ちます。 最終的に、これはチーム間の効果的なコミュニケーション、相互作用、知識の交換につながります。 仮想アーキテクチャチーム、オープンディスカッション、スクラムオブスクラムなどのアプローチは、コミュニケーションを支援し、コラボレーションをサポートするように設計されています。