1 [本] リーン開発の本質 ソフトウエア開発に活かす7つの原則(メアリー・ポッペンディーク/トム・ポッペンディーク/高嶋 優子/天野 勝/平鍋 健児)

散文的でいい話をまとめました形式なのでリズムよく読めないなあ。 でも、ポイントポイントではいいことを言ってる。

ただ、範囲が広い分、底が浅いので、参考文献から別の場所へ飛ぶべき（あ、bliki_jaが載ってる!!）。

メモ

「すばらしいじゃないか！問題を早期発見したぞ」

W・エドワーズ・デミングの「深遠なる知識の体系」と「14項目」。

• 8. 恐怖感を持たせない。
• 10.スローガンや説教、到達目標の使用をやめる。人ではなくシステムを変える。それはマネジメント側の責任。
• 11.作業者への数値的ノルマをなくす。（システムを提供するということか？）
• 12.固定給の作業謝意は、毎年の査定をやめる。

決定論的なスケジュールは間違った手法。次の3つのいずれかの手法を使うほうがいい。

1. モンテカルロ・シミュレーションを使って確実性を上げる
2. CCPMを使用してプロジェクトバッファを用意
3. 責任をベースとした計画と制御にする

情報共有と協力が不可欠な場合には、 個人の管理範囲よりも影響範囲に基づいて報酬が与えられるべき。

関係的契約は、製品仕様を契約でうまく記述することはできない、という想定に立っている。そのため、契約内容は、「各社がどのように協業するか、何を提供していくか」に重点を置いている。良好な協力関係ができれば、ドラッカーが言うように、コストは30%程度抑えられる。

関係的契約の例は http://www.leanconstruction.org/ に載っている。

CCPMは「依存関係が事前に計画できる」ものに対する解決策に過ぎない。←それ、もうアジャイルで解決できてるよ。『Agile Estimating and Planning』の17章読め。

| | | | | | Permalink

2 [本] Agile Estimating and Planning (Robert C. Martin Series)(Mike Cohn)

先ほど「17章読め」とあったので、読んでみたけど、うーん。

プロジェクトバッファの算出

いきなり公式が出てきてるけど、こういうこと（だと思う）。

前提として、

w: 最遅値(90%)
a: 平均値(50&)
σ: 標準偏差(SD)

と表す。

正規分布時には、95%の値(w)は平均値(a)から2SD(2σ)の距離にあるので（ここでは90%と言ってるけど、無視して）、σは、

2σ = (w - a)
σ = (w - a) / 2

となる。ref - 20080325#p02

また、

σ = √分散

なので、各ストーリーの分散は、

分散 = ((w - a) / 2 ) ^ 2

と表せる。

で、ストーリー全体のプロジェクトバッファも2SDにしたいので、

プロジェクトバッファ
= 2σ
= 2√（ストーリー1の分散）+（ストーリー2の分散）+...+ (ストーリーNの分散)

つまり、

2σ = 2 √((w1 -a1 ) / 2 )^2 + ((w2 -a2 ) / 2 )^2 + ... + ((wN -aN ) / 2 )^2

となる。これを簡略化して、

2σ = √(w1 -a1 )^2 + (w2 -a2 )^2 + ... + (wN -aN)^2

となる。これが、p.195の公式。

| | | | | | Permalink