スクラムや他のアジャイルの手法で推奨されるのは、ソフトウェアが動く状態で小さくて頻繁な納品によって、要求するものが顧客に納品されることです。技術レイヤやアプリケーションコンポーネントに従うことを重視するチームで開発することに慣れたチームにとって、これは挑戦なのです。「Scaling Lean and Agile Development: Successful Large, Multisite and Offshore Products with Large-Scale Scrum」(リーンとアジャイル開発を拡大する: 大規模スクラムで大きなマルチサイトのオフショア製品を成功させる)(リンク)が、間もなく出版されます（編集部注：原文掲載時の情報）。この本からの引用で、Craig Larman氏とBas Vodde氏は、どのように、そして、なぜ機能チームがうまくいくのかを説明し、この主要な組織の変化が価値あるものであることを主張します。実際に、アジャイルの手法を拡大し、学習を増加し、アジャイルを行い、競争力と製品化に要する時間を改善するのに、これは非常に重要なことです。
機能チームという考え方は、新しいわけでも「アジャイル」というわけでもありません。何十年もの間、大きなソフトウエア開発に適用されてきました。それらは、機能上の枠を超えたチームの改良であり、開発の速度を上げ、改善するために、よく調査した上で証明されたプラクティスです。
完全なアジャイルチームは、顧客中心の機能に従って組織されます。通常、チームは最初に苦労して、数ヶ月後に広範囲の統合した機能のまとまりを納品するところから、数週間毎にアプリケーションを分けて小さくする移行の仕方を理解します。コンポーネントチームをアジャイルにすることで、これに関して妥協するチームもあります。他のチームに動くソフトウェアを納品するのです。他のチームもさらに他のチームに動くソフトウェアを納品します。しかし、彼らはそれでも頻繁に統合した動くソフトウェアを納品するのに苦労します。
49ページあるこの章で、Craig氏とBas氏は主にコンポーネントチームと単独の機能チームの問題と、これらの問題が機能チームの適切な導入を通してどのように軽減されるのかを考察します。この章は、また、伝統的チームから機能チームへの移行と実践コミュニティを支援する必要性を簡単に調べています。著者たちは、Nokia Networks、NSN、Xeroxのような会社の大規模なアジャイル導入の経験を引き合いに出します。
チームの構造を、他の構造に入れ替えるのは、一瞬ではありません。機能チームの利益を完全に得るために、導入する人たちはいくつかの新しい出来事に取り組む必要があるでしょう。この章はこれらの課題について考察しています。
- 開発者は、今、より広範囲のスキルと製品知識が必要である。
- コードへの同時アクセスをサポートするために要求される専門分野と技術
- 設計の共同責任への変更
- 製品の安定性を確実にする様々な構造
- 再利用とインフラ作業に関する質問
- 学ぶのが難しいスキルを導入する必要性
- 共通の機能的な(例えば、テスト)スキルを発達させて調整する。それは、多くの機能チームのメンバを助ける。
- 組織構造に関係する課題
- 不具合の扱い
完全な機能チームに再編成することは「難しすぎる」と断言されるかもしれませんが、実は障害はものの考え方と政治的な意志であることが多いと著者たちは言及しています。作業がこれらの側面を変化させる一方で、チームは、まだ一つの選択肢として、機能チームに向けてより小さな一歩を踏み出します。コンポーネントから「複数のコンポーネント」チーム、そして本当の機能チームへとチームの責任を徐々に拡大する一つの例が示されています。
Craig Larman氏とBas Vodde氏のScaling Lean and Agile Development (2008年後半に出版予定) から、InfoQで機能チームの章全体(PDF)を読んでみましょう。この本の目次全体は以下の通りです。
リーンとアジャイル開発を拡大する:
大規模スクラムで大きなマルチサイトのオフショア製品を成功させる
Craig Larman氏、Bas Vodde氏著
目次
| 1. 序文 考える道具 2. 誤った意見の相違 3. リーン思考 4. アジャイルであれ 5. システム思考 6. ダブルループ学習 背景 7. 証拠 8. ストーリー 9. 誤解 アクションツール 10. 大規模スクラム 11. 製品管理 12. ポートフォリオ管理 13. 要件領域 14. 要件 |
15. 設計 16. レガシーコード 17. 継続的統合 18. テスト 19. 機能チーム 20. チーム 21. 調整 22. 組織 23. 計画 24. 変化 25. ツール 26. ドキュメント 27. 契約 28. セールスマーケティング 29. 会計と予算 30. 大規模 31. マルチサイト 32. オフショア その他 33. リーンとアジャイルの死 34. 参考文献 |
著者について
Craig Larman氏(リンク)は、Valtech社のチーフサイエンティストです。大規模スクラム、そして、リーンとアジャイルの原則を導入しているマルチサイトの製品グループで、アジアからヨーロッパ、アメリカへと世界各地で働いています。彼は、数年間、企業変革と大規模な製品やアジャイルオフショア開発にリーン開発を導入することに重点的に取り組んでいます。大規模な製品 (通常、組み込みシステムで、遠距離通信やプリンタ製品を含む) とは、Nokia、Siemens、Xerox、NSN、HPの製品です。また、Valtechのバンガロールセンタでアジャイルオフショア開発を行っていました。Craig氏は、また有名なテキスト、Agile and Iterative Development: A Manager’s Guide and Applying UML and Patterns: Introduction to OOA/D & Iterative Development (アジャイルと反復開発: マネージャガイド UMLとパターンを導入する: OOA/Dと反復開発の手引き) の著者です。
Bas Vodde氏(リンク)は、もともとオランダ出身です。しかしながら、中国、フィンランド、そして再び中国に住んだことがあり、現在は、シンガポールに住んでいます。彼は、Nokia Networks、後にNokia Siemens Networksでアジャイル変革プロジェクトを率いて、現在はOdd-eという自分の会社で働いています。彼は、複数の大きな製品と複数の大きな会社の移行プロジェクトで働いています。彼は、まだ彼自身でソフトウェアの開発も行い、C++ユニットテストフレームワーク、CppUTestの作者の一人です。
原文はこちらです：http://www.infoq.com/articles/scaling-lean-agile-feature-teams
（このArticleは2008年7月15日に原文が掲載されました）