納得したり、反省したりすることも多くて、読むペースが結構時間かかる本になってます。
さっき見た文面の一つにいかのものがありました。
それこそが大規模プロジェクトの人員配置での問題だ。このような体制になることって結構あります。 どきっ! とするところ。
プロジェクトに20人のメンバーがいるが、最初は5人分の作業しかないという場合、
チームの効率を上げるために、余った15人のための作業を見つけ出そうとする傾向が強い。
これはつまり、システムが、そのプロジェクトに合った境界ではなく、20人の開発者のスキルに沿って区切られるということである。
余った人に対して、「やってもらう事を見つけてその用意する」のを優先するようになって、本来優先するところが後回しになってしまう って･･･あります。
そんでもって、本来優先するところが疎かになるために、後戻りもあったりして。
「人を遊ばせておくことはできない！」 というのは当然の話なんですけども･･･それが、↑のようになってしまう理由にならないんですよね。
自分の仕事 の前のフェーズでは、ウォーターフォールでの開発はやめようよ。
と 自分では言っておきながら、
自分以降の仕事では、ついついウォーターフォールになっていたんかもなぁ。。。と。
とはいえ！
20人のプロジェクトで、最初からAgileで進むぞ！ というのは、やっぱり上手くいくようには思えないのは、正直な所です。
もし、その20人が まかせて大丈夫！って思える･･･よく知っている人･･･だったら、できるかも！って思いますが、そぅいぅメンバーが集まることってほぼ無いでしょうし。。全く同じメンバーで次のプロジェクトも行うって事もマレですし。。
Agileでの開発は大規模じゃー難しそうって漠然と思っている理由の一つは、コレなんかも。
5,6人くらいがベストかなぁー なんても漠然と思っていたりして。
でも、よく知っているチームメンバー同士であれば、いけるんかもしれないです。
案件によりその都度チーム編成するのではなく、
常にチームメンバーが決まっていて、案件にはチーム単位でアサインされる･･･
ってしたら、大規模もOK！なAgileチームが生まれるのかも。
Agileでぇーーなんて言わなくても、チーム内で自然とAgileな習慣をやるようにもなりそう。。
Blogged with the Flock Browser