■ どうしてアジャイル開発が必要なのか？
・スペックレビューで要件がFIXしないことが多いから
・開発期間中、最終フェーズにおいても要件の追加、変更などが発生するから。
・製品をリリースしても、変化した市場のニーズにマッチしていないから
それにより、時間をかけて開発しても、ほとんどの機能がユーザーに利用されない事態となる。
・市場のニーズを確認する方法がない
⇒ これらを解決するために変化を許容し、容易に軌道修正できる仕組みが必要。
複雑なプロダクトを開発、維持するためのフレームワーク
要件が不定、規模が壮大であるなど。
枠組みであり、実際のやり方はチームごとにカスタマイズが必要である。
やらなければいけないことは同じである。
★最終目標：モノを作ること
① 何を作るか？
② どう実現するか？
③ いつまでに出来るか？
④ 作る
⑤ 確認する
⑥ 完成
★ウォーターフォールの場合
① 要件定義
② 設計
③ 見積と計画
④ 開発
⑤ テスト
★アジャイルの進め方
① インセプションデッキ
② ストーリー収集
③ スプリント０
④ スプリント
⑤ リリーススプリント
■ やり方の違い
★ＷＦでは、目標を最初に決めて１直線にすすむ。
したがって、準備、計画が最重要であった。一度進んだら後戻りできないので、開発に着手するまえにどう実現するかまできちんと決めておく必要があった。
したがって、目標が不明瞭な状態においてはうまくいかない方法であるとも言える。
★ アジャイルでは近くに的を設置して、確実にあて、その都度方向を確認する。そして、確認しながら最終的なゴールに向かって進めていく。
つまり、作るたびに「何が必要か？」「どう実現するか？」といったことを確認するフェーズを設けて作成していくのである。
逆を返せば、「無駄なものを作らない」ことと「無駄なことはしない」ということが重要である。
■ アジャイルマニュフェスト（ケントベック、マーティンファウラー、ケンシュウェイバーらによって採択された）
・プロセスやツールより人と人同士の相互作用を重視する
・包括的なドキュメントより動作するソフトウェアを重視する
・契約上の交渉よりも顧客との協調を重視する
・計画に従うことよりも変化に対応することを重視する
■ 登場人物
★ プロダクトオーナー
製品に対して責任を持ち機能に優先順位をつける人
★ スクラムマスター
スクラムプロセスがうまくいくように外部からチームを守る人
★ チーム
プロダクトの開発を行う。製品の成功に向けて最大限の努力をコミットする。
★ ステークホルダー
製品の利用者、出資者、管理職などの利害関係者。
■ イベント
★ プロダクトバックログ
製品の機能をストーリー形式で記載する。プロダクトオーナーが優先順位をつけ、プランニングポーカーで相対見積もり、項目の追加はいつでも自由だが、プロダクトオーナーが優先順位を決める。
★ Ｄｏｎｅの定義
何をもって「完了」とするかを定義したリスト
★ スプリントの計画会議
プロダクトバックログを再度分析・評価し、ログアイテムを選択する。たま選択した項目をタスクにばらす。
★ タスク
時間で見積もられたタスク
★ スプリントバックログ
そのスプリント期間中に行うタスクのリスト
★ スプリントレビュー
スプリント中の成果である動作するソフトウェアをデモする
★ デイリースクラム
毎日チームメンバーが以下の３つの質問に答える
・昨日やったこと
・今日やること
・困っていること
★ バーンダウンチャート
スプリントタスクの推定残り時間を更新してグラフにプロットする
★ スプリント
各スプリントの期間は固定でありスプリント実施中は外部からの変更要求を拒否する
★ ふりかえり
スプリントの中での改善事項を話し合い次に繋げる
