XP/アジャイル手法の規模拡大に関するカナダワークショップ

提起された質問

会議の準備として、参加者は大規模チーム向けにXPおよびアジャイル手法を規模拡大する方法に関する意見を提出するように求められました。誰に尋ねるかによって、大規模の定義は20人から200人以上の開発者までさまざまです。

会議参加者に提起された具体的な質問は次のとおりです。

• アジャイル手法はどの程度スケーラブルですか？
• 初期導入者の経験はどうでしたか？
• これらの手法の使用を拡大するために、どのような実験を実施できますか？

私たちはいくつかのXPプロジェクトに参加した経験から、他の人がXPの規模拡大をどのように考えているかを聞き、大規模チームでのXPに関する私たち自身の経験を共有することに熱心でした。

ケン・シュエイバー

最初の基調講演者はケン・シュエイバーでした。ケンとジェフ・サザーランドは、Scrumアジャイル手法の創始者であり著者です。ケンは、大規模プロジェクトでのScrumの経験と、プロジェクトライフサイクルの初期段階で成功裏に使用したいくつかの手法について説明することから始めました。

ケンは、あるプロジェクトで、チームが開発の初期段階でシステム全体のアーキテクチャを証明することに非常に懸念していたことを説明しました。初期のプロジェクトイテレーション（Scrum用語ではスプリント）には、いくつかの実際のビジネスケースが散りばめられた、システムアーキテクチャを証明することに焦点を当てたストーリーが含まれていました。アーキテクチャが継続的に洗練されテストされたいくつかのイテレーションの後、チームはアーキテクチャがビジネスの要求に十分であるかどうかをよく理解できました。

規模拡大は、元のアーキテクチャチームの創設者とともに新しいチームを開始することによって達成されました。ほとんどのアーキテクチャの問題が解決されたため、新しいチームは、当時安定していたアーキテクチャの上にビジネスロジックを実装することに集中できました。

ケンはまた、チームを管理しないScrumマスターを持つことの重要性を強調しました。むしろ、チームが自己管理することが非常に重要でした。ケンは、チームが自己組織化し、与えられた仕事をどのように完了するのが最善かを自分で決定できる場合に、チームがはるかに効果的であることを発見しました。これは、指揮統制型のリーダーシップに慣れていた管理者にとっては困難であり、最初は非常に直感的ではありませんでした。

ケンが触れた興味深い点は、外部の人が最初にアジャイル手法をどのように認識するかということでした。成功の要素を達成したすべての新しいものと同様に、人々は当然、これが彼らにどのように役立つかを尋ねます。これは彼らが探していた「銀の弾丸」でしょうか？ケンは、XPとアジャイルがCMM（Capability Maturity Model）と同様の運命をたどるのではないかと考えました。

CMMには、ソフトウェアプロジェクトでの成功の可能性を高め、ソフトウェアプロセスの成熟度を示すために企業が実行できることを明確にする、多くの偉大な人々がいました。しかし、CMMは、著者が当初意図していた程度に受け入れられ、成功裏に実装されたことはありません。CMMプロジェクトの実装の3分の2が失敗したと報告されています。さらに、業界の多くの人は、企業が達成できる認証レベルが、認証を実行するために雇用した人に依存することが多かったため、CMMに対して皮肉な見方をしました。

アジャイル手法は同様の運命をたどるでしょうか？確かに、初期導入者は成功を収めていますが、これらのチームは多くの場合、ソフトウェアの作成に情熱を注ぐ、高度なスキルと意欲を持った人々で構成されています。おそらく、これらのタイプの人々で構成されたチームは、名前や実践で使用された方法論に関係なく成功していたでしょう。

私たちの意見では、これはアジャイルとはあまり関係がなく、プロジェクトに人が一番影響を与えるという避けられない事実と関係があります。これは、これらのタイプのチームを構築することの逆（スキルが低く、意欲がなく、ソフトウェアの作成に情熱を注がない人々）を見ると明らかになります。これらのチームにとって、名前や実践で使用された方法論は、彼らを成功させることはありません。

ケンは、優れた開発者がプロセスを円滑に進めるのに役立つことに同意しましたが、彼自身の経験では、平均的、さらには貧弱と分類された人々が、アジャイルが提供する協力的で創造的なチーム指向の環境を与えられた場合に、しばしば卓越性に昇華することも同様に真実です。彼は、以前は異質だった平均的な専門家のグループが、以前はトップレベルの人々だけが実行できると思っていた素晴らしいことを成し遂げたのを見てきました。

現場からの報告

会議の中盤は、他の実践者や研究者が、大規模プロジェクトでの考えや経験を共有するために確保されました。

フィリップ・クルーテン（Rational）は、RUPを使用した大規模チーム（200人以上）が、過去に大規模プロジェクトを成功裏に納品した方法について説明しました。プロジェクトの初期段階では、シニアプラクティショナーで構成されたチームが、初期の高レベルアーキテクチャを完了し、開発プラクティスを設定するために使用されます。

プロジェクトが構築段階に進むにつれて、より多くのチームが（精緻化チームの創設者とともに）追加されます。適切に分割すると、各チームはかなり自律的に（反復サイクルで）作業できます。あるチームが別のチームから構築されたコンポーネントを必要とする場合、2つの間で同期ポイントとマイルストーンを調整できます。この方法で大規模プロジェクトを処理することで、チームは、小規模なアジャイルチームの利点を得るのに十分なほど分離されているという錯覚を持ちました。

クリアストリームコンサルティングのジェラード・メサロスは、大手通信会社でデジタルスイッチを構築する大規模チームとの仕事の経験を共有しました。彼らは頻繁なリリースを使用し、プロジェクトのライフサイクル全体を通して大きなアーキテクチャ変更がありました。ただし、システムはこれが可能になる前に臨界質量に達していました。

ジェラードはまた、XPとアジャイルの実践に関する現在の業界文献に関して興味深い点を提起しました。彼の意見では、今日の文献のほとんどは、すでにソフトウェアを開発する方法を知っている人々を対象としています。XPが初期導入者の範囲を超えるには、非常に異なる文献が必要になります。使用されたアナロジーを繰り返すと、「今日、私たちは料理ができる人のための料理本を持っています。今日、私たちが持っていないのは、料理ができない人のための料理本です。」

カナダの大手エネルギー会社は、社内でのアジャイル導入に関する経験を共有しました。ScrumとXPの組み合わせを使用して、彼らはプロジェクトの管理に大きな成功を収めてきました。経営陣の支援により、彼らは現在、社内の他のグループにアジャイルが成功の可能性を高めるためにどのように使用できるかを示すことに専念するチームを持っています。XPとScrumに関するさらなるコメントは、各チームのニーズに合わせてプラクティスを適合および変更する機能をチームに提供したことでした。彼らは、以前使用していたワンサイズフィットオールの形式のプロジェクト管理よりもこれを好みました。

著者（ジョナサン・ラスムッソンとジム・マクドナルド）も、XPと大規模チームに関する私たち自身の経験を共有する機会を与えられました。私たちは主にXPで作業していたため、コアプラクティスを見て、それらを2つのグループに分けました。拡張できると思われるプラクティスと、そうでないプラクティスです。

私たちは、コーディングのメカニズムに関連するXPプラクティスは規模拡大できると考えています。大規模な開発者チームがテストを書いたり、リファクタリングしたり、ペアプログラミングしたりするのを妨げるものはほとんどないと考えています。人々は、大規模および小規模の両方のプロジェクトで、これらの手法を長年にわたって（XPまたはアジャイルよりも前に）実践してきました。これらは単に良いプラクティスです。

ただし、コミュニケーションを中心としたプラクティスは、規模拡大が困難になります。たとえば、20人以上のチームとの毎日のスタンドアップミーティングはぎこちなくなります。すべての開発者とアナリストが集まって今後のイテレーションを計画するイテレーション計画ミーティングは、非常に多くの人を調整することによる組織的およびコミュニケーションのオーバーヘッドのために管理が難しいでしょう。XPの規模拡大で私たちが見る最大の課題は、すべての大規模プロジェクトが直面するのと同じ課題です。それは、多数の人々を効果的にコミュニケーションして調整する方法です。

私たちはまた、質問自体にも疑問を持ち始めています。なぜ人々はXPをスケールさせたいのでしょうか？小規模チームでの成功により、スケールさせたいと思うのは私たちにとって非常に直感に反しているように思えます。むしろ、XPがうまく機能することがわかっているサイズまで大規模プロジェクトを縮小する方法の代替案を最初に探すことをお勧めします。

マーティン・ファウラー

会議の最終日は、「アジャイルをスケールすることがあなたが最後にやりたいことである理由」というタイトルのマーティン・ファウラーからの基調講演で始まりました。彼の基調講演のタイトルは、会議のトーンを変えました。それまで、会議の多くは、XPをどのように規模拡大するかという質問に答えようとすることに費やされていました。しかし、マーティンの基調講演は、その質問を覆し、これが本当にやりたいことなのかと聴衆に尋ねました。

彼の講演は2つの部分に分かれていました。最初の部分は、複雑なリースアプリケーションでXPタイプのプロセスを使用する大規模チームが関与するThoughtworksプロジェクトに関する経験レポートでした。2番目の部分では、XPを規模拡大する前に代替案を探すべき理由を説明するタイトルについてさらに詳しく説明しました。

マーティンは、複雑なビジネスアプリケーションを構築することがなぜ困難なのかを思い出させることから始めました。ビジネスロジックは矛盾です。ビジネス（特にリース）のほとんどの側面について論理的なものは何もありません。ビジネスルール、隠れた前提、特別なケースをキャプチャし、これらを堅実な、戦い抜かれたドメインモデルに抽象化することは、ソフトウェア設計の最も困難な部分の1つです。

要件の収集も、大規模プロジェクトでは非常に困難です。マーティンは、要件ドキュメントの作成と書籍の作成の間の興味深い比較を提供しました。本を書くには、非常に多くの時間とエネルギーの投資が必要です。専門の編集者からの査読やフィードバックの後でも、著者は常に聴衆に意図したメッセージを伝えることに成功するとは限りません。彼のポイントは、著者が本でこれを行うのが難しいのであれば、はるかに少ないリソースで複雑なビジネスアプリケーションに関する要件をキャプチャするのがどれほど大変かを想像してみてくださいということでした。

このプロジェクトで非常にうまくいったプラクティスの1つは、担当者をアプリケーションの異なる部分にローテーションすることでした。当初、プロジェクトアナリストにとっては、開発者が問題領域を理解し始めたばかりのときにシステムの別の部分に移動してしまうため、不満を感じていました。しかし、プロジェクトが進むにつれて、担当者をアプリケーションの別の部分に移動させることのメリットが現れ始めました。最終的には、ほとんどの開発者がアプリケーションの多くの部分を知っており、多くの役割を果たすことができるようになりました。アプリケーションの特定の部分での作業を少数の人に依存することが少なくなりました。開発者自身も、技術的にもビジネスドメイン的にも強化されました。アプリケーションのよりグローバルな視点を持つことで、全体的なシステムアーキテクチャを維持しながら、新機能を実装する最適な方法を洞察することができました。

マーティンの基調講演の後半では、アジャイルのスケーリングの代替案を検討すべき理由に焦点が当てられました。一部のプロジェクトでは、大規模なチームが必要になります。完了に必要な作業量は、小規模なチームが妥当な期間内に処理するには大きすぎる場合があります。この例としては、通信業界のプロジェクトや大規模な軍事アプリケーションがあります。これらのチームにとって、アジャイルをどのようにスケーリングするかという問題は非常に現実的なものです。

しかし、マーティンの経験では、多くのチームが不必要に大規模でした。これらのチームは、アジャイルをスケーリングしようとする前に、代替案（チームサイズの縮小など）を探すべきです。マーティンは、チームの最下位半分を取り除いた後も、ほぼ同じレベルの生産性を維持できたプロジェクトに参加したことがある人は手を挙げてほしいと聴衆に求めました。会場の大部分が手を挙げました。これは、聴衆の多くが同様の経験をしており、チームが必要以上に大きくなっていたプロジェクトで働いていたことを反映しているようでした。したがって、XPとアジャイルをスケーリングする方法を最初に検討するのではなく、マーティンは、不必要に大規模なプロジェクトを縮小する方法を最初に検討することをチームに勧めました。

証拠はどこに？

参加者が答えるのに苦労しているようだった質問の1つは、XP/アジャイルを大規模プロジェクトで利用できるという経験的証拠を提供する実験は何であるかということでした。学術/研究コミュニティは、アジャイル手法が大規模チームに拡張できるという実験と経験的証拠を出すという困難な課題に取り組んでいます。

アジャイルが機能することを証明したいという研究者の願望には共感しますが、それを証明するにはいくつかの課題があると考えています。ジョナサンは、この課題をソフトウェアの品質と生産性を客観的に測定しようとすることだと見ています。品質と生産性に関する明確で定量的な測定基準がなければ、ソフトウェアエンジニアリングプラクティスに関する実験をどのように実施できるでしょうか。ジムは、アジャイルを真に理解するための道は、社会学の研究と、人間がどのように相互作用するかを定量化し記述することの難しさを研究することにあると考えています。コミュニケーションがアジャイルプロジェクトで非常に重要な役割を果たしているため、これらの分野での研究は、アジャイルが機能する理由についての理解を深めると彼は感じています。

まとめ

会議自体は大成功であり、すべての参加者は、研究コミュニティによって提示された困難な問題にどのように最善に対処するかについて、自分の考えやアイデアを共有する機会を楽しみました。XPやその他のアジャイルプロセスは、学術界の注目を集め始め、真剣に受け止められ始めているようです。初期導入者が提供するアドバイスに関係なく、新しいツールと同様に、XPは今後数年間で適用されたり、誤用されたりすることが明確になっているようです。