Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
26 lines (18 sloc) 2.96 KB
title tags
大規模アジャイルプロジェクト
agile
agile adoption
team organization
project planning

http://martinfowler.com/bliki/LargeAgileProjects.html

大規模プロジェクトでアジャイル手法が使えるかどうかというのはよくある質問である。そもそも多くのアジャイル手法は小規模プロジェクト向けに設計されているため、大規模なプロジェクトでは、アジャイル手法と対抗する重量級の発想・構想(idea)のほうが必要となっている。

これが質問となっているという主な理由は、我々がまだ知らないからだ。 新技術は最初に小さなプロジェクトで広がる傾向にある。 小規模で成功した場合のみ、より大きな規模で使われるようになるが、それでも、広がるには時間がかかる。どんな技術手法(technique)や技術(technology)も、 すでにそれを使って成功したプロジェクトよりも2倍以上の規模のプロジェクトで使うことはおすすめしない。

にもかかわらず、アジャイルに関する多くのことは、あんた何を大規模と言うか次第だが、大規模システムの背景を持っている。ソフトウェアプロジェクトにとって、大規模が何であるかの第一の指針は、人月であると思う。人々がいれば、コミュニケーションの問題が浮き上がる。XPの適用範囲は20人のチームまでだ。FDDはもう少し多くて、数十人までいける。RUPの設計を統括する Phillipe Kruchten と話したら、RUPの本質的な部分はアジャイル手法であるし、Phillipe は最初、200人規模のプロジェクトで働いたこともある。

アジャイル手法を拡張するのは最後にすべきこと

最近、Canadian Agile Networkでこのフレーズを使った。文字通りの意味である。私は大規模プロジェクトを行うべきではない、とは言っていない。アジャイル手法を大規模プロジェクトに適応させようとすることは(しばしば必要にせまられるが)最初に行うものではないと言っているのだ。

プロジェクトの規模を小さくするほうが良いやり方だ。 そのワークショップにおける非科学的調査で明らかになったことだが、 プロジェクトの速度を落とさずにメンバを半分に削減することは可能なのだ。 チームのメンバが著しく削減されてもなお成功したという話を何度も何度も聞いている。 大規模チームはコミュニケーションとマネージメントに多大なるオーバーヘッドを抱えている。たいてい、有能な人々で構成された小さなチームを使ったほど、速くて安く済むものだ。例え全員の個人としての値段が高かったとしても。

You can’t perform that action at this time.