アジャイルプロジェクトマネジメント
アジャイル開発とは
対比して語られる開発手法 - ウォーターフォール手法 - アジャイル
アジャイル手法は、対象を小さな機能に分割（イテレーション or スプリント）して開発する
成果物を短期間で完成させ、機能を少しずつ拡張させていく
成功するアジャイルプロジェクトとは
- スプリントが4~12週間
- 対面でのコミュニケーションに重点を置く
- 業務部門と技術部門が緊密に連携している
- アジャイルを全面的に支持するスポンサーの存在
- ニーズの変化を先読みして取り入れる
アジャイルプロジェクトの成功に必要な条件
- （目的）ゴールへのビジョン
- 基本的なプロジェクトのライフサイクルに従う
- 要件の理解
- スケジュールの共有・管理
- 専任チームが作業に専念できること
- 関係者全員が緊密にコミュニケーションできること
アジャイルのフェーズ
[構想]→[思索]→[探索]→[適応]→[思索]に戻るを繰り返す
最後に[集結]を実施
構想
プロジェクト憲章を作成する - 開発するものを顧客と決める - チームに必要な人材、価値観・規範を確認 - プロジェクトのスコープ、目標、関係者を定める - チームのコラボレーションツールのセットアップ
プロダクトのビジョン（概要の記載）、ターゲットの顧客、メリット、プロジェクトの目的
プロジェクトのスポンサーとマネージャーの責任・権限を明記
チームの規範の例（1日8時間、〇日間作業、〇曜日に休日をとる、毎日〇時にミーティングを行う等）
思索フェーズ
計画を立てるフェーズ - フィーチャー単位の提供計画（分類、優先順位付け） - 見積り - リスク
スプリントの要件、要件に基づいて開発するフィーチャーの一覧を作成
開発するフィーチャーの作業量を見積り、リスクを特定・更新（新規、未処理、未完成のフィーチャー）
※ フィーチャーとは - 特定のビジネスニーズに絞った機能 - 顧客によって重要な小さな業務を行為と結果で表したもの
- イテレーション
- マイルストーン
- リリース計画
探索フェーズ
- フィーチャーの実装
- 毎日のスタンドアップミーティング（15~30分程度）
- 内部でフィーチャーをレビュー
スタンドアップミーティングでは、前日の成果・今日の予定・必要なサポート等を共有
フィーチャーを課題登録簿で管理
適応フェーズ
フィーチャーを開発したら、イテレーションの終わりに振り返りを行う - 顧客によるフィーチャーのレビュー - チームによる振り返りのミーティング・記録（成果と計画を比較し、良かった点・悪かった点等を話し合う） - 前回の適応フェーズの教訓と同じ傾向が見られないかを確認 - 問題解決のためのブレインストーミングを行う
これによって、頻繁にフィードバックが得られる（アジャイルの利点）
適応によって得られた教訓を共有、次のスプリントの計画を見直して調整する
終結フェーズ
- 成果物が完成
- 学んだ教訓が記録されていることを確認
- 人員を他のプロジェクトや業務に割り当てる
- プロジェクト全体の成果を伝える
- 開発したフィーチャーが業務で成果を上げているかを監視
PDS（プロダクトデータシート）
- 計画書、プロジェクトの概要をまとめたもの
- 構想フェーズで作成される
制約の種類
- 環境
- 安全
- 経済
- 技術
- 政治
- スケジュール
- チームまたは開発するプロダクト
スプリント計画
スプリントの期間と開発するフィーチャー数を決定する
スプリントの期間を短くして焦点を絞るのが効率的
フィーチャーの分類基準 - 業務部門における優先順位 - 対応可能な技術者 - 利用可能な資源 - 事業分野
リスク管理
最初のスプリントはフィーチャーの難易度を下げて、後のスプリントで徐々に上げていく
アジャイル開発に慣れた段階で、難易度の高いフィーチャーに着手
思索：アジャイルプロジェクトの進め方
要件定義
- ビジネス部門が開発部門に先行してアジャイルで要件を定義する
- 新しいフィーチャーを定義（ユースケース、パフォーマンス要件カード等を活用）
- ニーズの変化に伴い不要になった既存のフィーチャーを特定
スタンドアップミーティング
- 重要な情報の共有
- 15分程度、毎日同じ時刻
- 立ったまま行うことで頭が冴え、楽観的でアクティブな状態を維持
- プロジェクトマネージャーは会議の進行役はせず、メンバーにタイムキーパーを割り当てる
- 必ず前向きな雰囲気で終わらせる（成功体験を共有する等）
ベロシティで生産率を把握する
ベロシティとは - 平均的なスプリントでチームが完了する機能の数 - ベロシティが低下している場合、その原因を調査する
探索：開発プロセスを管理する
プロジェクトマネージャーの役割
チームがプロダクトの開発に専念できるような動き - 観察して相談に乗る - コントロールするのではなく、コーチングで導く - 障害を取り除く - スタンドアップミーティングでしっかりと耳を傾ける - フォローアップを行う
問題とリスク管理
互いに信頼を築き、問題が発生したときに誠実に話し合える場を建設する - 人ではなく、問題を非難する - 対立に真正面から取り組む - 事実ベースで伝える - 賛否両方のシナリオを示す
決定を行う必要がある場合 - 明確にする - 根拠を示す - 支援を要請する
適応・終結：納品前に微調整する
スプリントで学んだ教訓を確認する
適応フェーズを待たずにフィードバックが得られるように、いつでもメンバー間で感じた点をメモできる場を設ける
問題を解決できずとも、フィードバックを書き留めるだけでOK
変化するビジネスニーズに対応する
優先順位が低いとされていても、後で開発すると開発効率が悪くなる（コストアップする）場合、業務部門に相談して判断を促す
フィーチャーの再構築 - 計画が必要、変更があれば見直す - 新しい順序があれば確認する（必須な機能を先行して開発する等） - 正確な見積りを可能にする
振り返りとは
プロジェクト（またはスプリント）の教訓を文書化すること
終結フェーズ - フィーチャーを全て実装した - 時間が残っていない - 資金が残っていない
プロジェクトを終結する場合の検討事項 - バックログリストの見直し - 未処理リストから残りのフィーチャーの重要性を判断 - 新しいフィーチャーが必要かどうかを考える
アジャイルのヒント・コツ
トラブルシューティング
トラブルの兆候 - 未処理のフィーチャー - 優先度の低いフィーチャーの開発 - 不適切なフィーチャー - 修正が必要なフィーチャー - その他（チームの出席率、プロジェクトバッファを使い切っている）
スノープラウイング手法
完了した作業をチェックし、計画と相違ないことを確認する作業
スプリント終了時にフィーチャーを次に持ち越さない
問題の根本的な原因 - 適切な質問をしなかった - 何を開発しているか顧客が理解していない - ビジネスニーズを正確に把握できていない
プロダクトレビューを行い、バックログリストを修正する