/note/tech
PMBOK的プロジェクトマネジメントの問題点（W/F開発の問題点）
- 機動性に乏しい
- 誤りの修正コストが大きい
- 線表管理専任者が現れたりする
- プロジェクトに価値を生まない人間を抱え込むことになる
PMBOKの前提
- 基本的に物理的な要素を扱うプロジェクトをベースに作られた知識体系
- 建築、物流、重工業
- ソフトウェア開発とは相性が悪い
- 19-20世紀はそういう時代だった
何故ソフトウェア開発と相性が悪いのか
- ソフトウェア開発は柔軟
- やりようは幾らでもある
- 問題は「可能であることが最善であるとは限らない」
- 不確定要素が多い
- 担当者によって工期/品質が変化する
- コミュニケーションコストが巨大
- チームがスケールしない
- 要求が変化しがち
- 出来上がったものを見て始めて欲しいものが分かることもある
ソフトウェア開発の性質
- 物理的なサムシングでは無いので定量的見積もりが困難
- 建築や工業よりも育児や介護に近い性質を持つ
- 手を抜けば確実な死
- 正解が無い
- 外野ほどわちゃわちゃ言う
PMの問題
- 素人のまま年数だけを重ねる
- 火地を増やす/減らすか、部下/取引先を詰めるしか能がない人間になりがち
- えてして論理的な思考能力に乏しい
- 結果的にプロジェクトのコントロールが不可能
スケジュール
- 変化しやすいので長期スケジュールを立てることがとても困難
- スケジュールに間に合わせることだけを目的にした場合、品質・コスト面で火を吹く確率が跳ね上がる
エンジニアの問題
- プロジェクトの生産の要となるエンジニアでさえ工業的な均一性が無い（家内制手工業レベル）
- なので正確な見積もりが困難
アジャイル開発（スクラム）の解決策
- スケジュールを短期間のタイムボックスで区切る（1-2週間）
- 短期で区切ったスケジュールで必要最低限の成果を出す（成果物の妥協あるいは漸進的発展）
- 短期スパンのマイルストーンと全体計画の逐次アップデート
- プロダクトの責任者と開発の責任者という二頭体制（POとスクラムマスター）
スクラム開発の方法論
- PO（プロダクトオーナー）
- タイムボックス開発
- 段階的リリース
- リリースプレゼン
- プロダクトバックログ
- 朝会/夕会
- スプリントごとの振り返り
スクラム開発の進め方
- (1)作るものを決める
- (2)短期間のマイルストーン毎に開発
- (3)POからフィードバック（可能ならユーザーテストも）
- (4)振り返り
スクラムのメリット
- 計画が立てやすい＆変更しやすい
- とりあえず最小限の製品を作ってフィードバックを受ける方がよい
スクラムのデメリット
- 仕様が決まったものを納期きっちりで欲しいプロジェクトとは相性が悪い
- とはいえ人類は完全な要求を作ることはできない（c.f. 顧客が本当に欲しかったもの）
- 期間指定で外注に発注するようなプロジェクト
(2019/06/17)