最近関わっているプロジェクトは、本質的に機能の不確実性が高いということが多いプロジェクトです。ですので、不確実性、あるいは計測/制御でいうところの誤差、をコントロールするという視点で、プロジェクト管理できないかなぁと考えている今日この頃。
「アジャイルな見積りと計画づくり」を、誤差のコントロールの視点から読みました。実験的にやっていることや、今後、やっていきたいなと思うことのメモです。
従来からある計画手法の多くが犯している誤りは、フィーチャをプロジェクト開始時に固定 できると信じていることだ。そのため、いったん計画を立てたら、その後は変更を認めなかっ たり、複雑で手間のかかる変更管理プロセスを強制して計画の変更を阻害したりしている。 (p.261)
前提が間違っている、と。もちろん開始時に固定すべき/固定できるプロジェクトは存在する。けど、そうじゃないなら、そうじゃないなりのプロセスが必要で、ほかができなくて自分たちができるなら付加価値になる。
「2週間後には、今日よりも多くのことが明らかになっています。イテレーションでなにをすべきか決まっていないのに計画を立てる理由があ りますか?必要ないんです。大規模なプロジェクト、特に複数のチームから構成されている プロジェクトでは、作業の連携のために2イテレーションか3イテレーション先まで計画することがあります。ですが、いまの私たちには必要ありません」 (p.303)
ある程度の、おおざっぱに見積もりは、もちろん必要。でも、細かい見積もりは不要。「精度」という語彙は曖昧なので、確度と分解能と言えばいいかな。確度が高いことは大事だけれど、分解能は低くてよい。
1ポイントのストーリーよりも短い時間で完了できる2ポイントのストーリーがあるというのは、まったく理にかなったことであり、予想の範囲内でもある。(p.179)
誤差は含む。見積もりは期待値分布の代表値にすぎない。ひとつのタスク、ひとつのストーリーの誤差で一喜一憂していはいけない。もちろん傾向として、全体的に20%オーバーするとかであれば、見直しがひつようだけど。
スパイクとはイテレーション計画に含める タスクの一種で、何らかの知見を得たり、疑問を解消することを日的に取り組む作業のことだ。[...] スパイクを実施すれば2つ目のタスクヘの見通しが得られるので、 このタスクをより正確に見積もれるようになるのだ。 p. 170
まず、おおざっぱな見積もりをして、そのあとで実際のタスクを見積もり直す。もちろん誤差はある。でも、コントロール下に置くことができる。
大きなストーリーはストーリーでおこなう操作に沿って分割すること。 p.140
例として CRUD する場合には、Create でひとつのストーリーにする、というもの。Django の場合は、管理画面でDBテーブルの内容を見るのがカンタンなので、これはありだと思いす。実は今のプロジェクトで、この区切りを使っている。
大きなストーリーの機能要求と非機能要求とをそれぞれ個別のストーリーに分割すること を検討せよ。 (p.142)
今のプロジェクトで実験中。まして、パフォーマンスがどの程度かやってみないと分からないので、まずは正しく動く機能を実装しています。
