アジャイルプロジェクトマネジメント

最近、アジャイル開発が多いというのも、仕様なども変わることが前提で、プロジェクトを始めることが多いからだ。

ただ、仕様を最初から明らかにすることは大切だが、目に見えないS/Wの仕様を仕様書というドキュメントだけで定義するのはやはり難しいだろうということは理解はできる。

そこで、そういう製品のゴールが決まっていないプロジェクトをどのようにマネージすればよいかを学ぶのに加えて、PMBOKとの違いを意識して読んでみた。

そもそも、アジャイルとは。

・激変するビジネス環境から利益を生み出すために、変化に対応すると同時に、変化を作り出す能力

・柔軟性と安定性のバランスを取る能力

そこで出されたアジャイル宣言が実にわかりやすい。

　プロセスやツールよりも、個人との対話を優先する

　包括的なドキュメントよりも、動作する製品を優先する

　契約の交渉よりも、顧客との協調を優先する

　計画に従うよりも、変化への対応を優先する

　PMBOKと正反対ですね。

　アジャイルプロジェクトマネジメント（APM)の原則は、大きく２つ

　●製品提供と顧客価値

　　・顧客価値の提供～顧客が使えるもの

　　・反復型で機能ベースの提供～よりよい製品を顧客と協力してつくる

　　・技術的優位性の重視

　●リーダーシップ－コラボレーション

　　・探索の激励

　　・適用方チームの構築～適切な人材を選らび、自発的規律で動いてもらう

　　・シンプルにする～ルールや目標をシンプルに。

　アジャイルフレームワークは、

１．構想（Envision）

　製品ビジョンやプロジェクトスコープ、コミュニティ、作業の方法を決定する

　　⇒　プロジェクト憲章（PMBOK)

２．思索（Speculate）

　ビジョンに沿った機能ベースのリリース・マイルストン、イテレーション計画を作成する

　　⇒　プロジェクトマネジメント計画書（PMBOK)

３．探索（Explore）

　テスト完了済みの機能を小出しで提供し、リスクや不確実性を軽減

　　⇒　リスクの監視コントロール（PMBOK）

４．適応（Adapt）

　提供された成果や現在の状況、チームのパフォーマンスをレビュー

　⇒　スコープ検証、実績報告（PMBOK)

５．終結（Close）

　プロジェクトを締めくくり、学習内容を伝達し、打ち上げをする

　⇒　プロジェクト終結（PMBOK)

本の中で、印象的な言葉を引用します。

You cannot manage men into battle. You mnage things. You lead people.

目的を持って刃を研ぐ