[本]アジャイルな見積りと計画づくり 1日たって

まだ、はてな記法がわからない、昨日書いたの見直したら汚いな〜
昨日は読み終わって勢いで書いたけど、1日たって実際のプロジェクトを見ながら考えてみた。あと、岡島さんのエントリーを読んでなんとなく考えたことを書いてみる。トラックバックってこうやったらいいんですかね?

自社の受託開発のプロジェクトでは、お客さんが遠い。お客さんの窓口はお客さんの子会社であったり。ステークホルダーが一堂に会することが難しい。こういった場合、ストーリの選択はできるんだろうか?

窓口の子会社の方は、親会社にコミットメントをしてしまっている。親会社のほうでも部門間でのコミットメントがあったりする(企画、営業、開発)。自社内でも営業はお客さんにコミットしているし、営業は開発にコミットを求めてくる。

もちろん、開発側ではストーリ毎に見積もって、イテレーションで開発していくことはできるし、それはすべきだと思う。リリースを最後の一回だけにしたら、外から見たら今までのプロジェクトと同じように見える。

さて、最初のストーリの優先度は誰が集まってどう決めよう?、ストーリが溢れそうになったらどうしよう?
優先度はよくわからない・・・、ただストーリが溢れそうになるのは、今までのやりかたでも同じはず。
機能削減をお願いする、納期を調整していただく、交渉が困難なのでデスマーチに突入する・・・

そういった事態になることが、最初に予測できる、プロジェクトの早い段階で予測できる。それが一番大事なんだろう。あとはストーリバッファは難しいかもしれないけど、スケジュールのバッファを取れるか?取れなければ重大なリスクとしてどう管理していくかの問題になる。

と考えながら書いていくと・・・、ケーススタディのようにハッピーエンドに必ずなるとは限らないが、受託開発でも、できない理由は無いのかもしれない。

少なくとも、今よりは良くなっていけるかな?

#この本の中身をチームや社内で理解してもらうのが難しいとかいう問題は今回は考えていない。
#そもそも業界構造がとか言い出すと何も変えられないので、これも考えていない。
#あ〜、また整理せずに頭の中を吐き出している・・・・