no one came up with any better ideas than what was on the initial list of requirements

Agile Estimating And Planning (Robert C. Martin)Agile Estimating And Planning (Robert C. Martin)
Mike Cohn

by G-Tools

    <p>
      全部読み終わるのは当分先になりそうなので、ちょっとずつまとめていきましょう。
    </p>
    <p>
      ということで、IntroductionからChapter2まで。
    </p>
    <p>
      Introductionでは、「アジャイルプロジェクトを見積る・計画する」ということと「アジャイルに見積る・計画する」という言葉は違うんだよと言っています。アジャイルに見積る・計画することができなければ、アジャイルなプロジェクトを実施することはできないということです。
    </p>
    <p>
      Chapter1~3までがPart1なのですが、Part1のタイトルは「The Problem and the Goal」。この導入の仕方はどこでも使えますね。
    </p>
    <p>
      Chapter1では、計画を立てることの必要性・重要性について述べられています。<br />ここで、しびれる言葉に出会いました。「失敗プロジェクトを定義するとして、その一つの尺度は『誰も、最初の要求リスト以上の良いアイデアを出さないプロジェクト』だ」。まさにそうなんです。これを否定しようとするから、終ったと思った後にどんでん返しが待っているのです。これを制度として(すなわち建前としても)表現できたらその組織は強いと思います。
    </p>
    <p>
      Chapter2では、計画が失敗する理由ということで、全体的にはTOC的な、クリティカルチェーン的な考えが述べられます。それはよいとして、最初にActivityベースの計画は失敗するよ、機能ベースにしなさい、という表現が出てきます。WBS信奉の強いこの業界では、ややアレルギーが出そうな表現です。機能ベースの計画についてはまだ詳しく述べられていないので、いったんスルーしておきます。ただ、章の最後に述べられる、見積と義務は違うんだよというところは、重要だと思います。見積(しかもしばしば概算見積)が義務になってしまうために、コントロールの幅が狭まっているのではないかと思う訳です。
    </p>
    <p>
      余談ですが、criteriaはcriterionの複数形だということを知りました。へぇ。
    </p>