アジャイルサムライ購入リンク
概要
マスターセンセイと学ぶアジャイル開発の道
動くソフトウェアを素早く開発するための「アジャイルソフトウェア開発手法」を、実際に導入するにはどうすればよいかを、豊富な図を使い親しみやすい言葉で解説しています。
経験豊かな著者が具体的なノウハウをまとめた本書は、アジャイル開発を導入したいと考えている組織や人のための「現場のマニュアル」として役立ってくれることでしょう。
アジャイルソフトウェア開発宣言
- プロセスよやツールよりも、個人と対話を
- 包括的なドキュメントよりも動くソフトウェアを
- 契約交渉よりも顧客との協調を
- 経過雨に従うよりも変化への対応を
アジャイルソフトウェア開発の12の原則
- 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
- 要求の変化はたとえ開発の後期であっても歓迎します。変化を味方につけることのよって、お客様の競争力を引き上げます。
- 動くソフトウェアを、 2〜3週間から2〜3ヶ月というできるだけ短い時間間隔でリリースします。
- ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
- 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え、仕事が無事に終わるまで彼らを信頼します。
- 情報を伝える最も効果的な方法は、フェイス・トゥ・フェイスで話をすることです。
- 動くソフトウェアこそが進歩の最も重要な尺度です。
- アジャイルプロセスは持続可能は開発を推進します。一定ベースを継続的に維持できるようにしなければなりません。
- 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
- シンプルさ（無駄なく作れる量を最大限にすること）が本質です。
- 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
- チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいてやり方を最適化します。
１．アジャイル入門
-
価値ある成果を、毎週提供するには
- 大きな問題は小さくする
- 本当に大事なことにのみ集中する
- 動くソフトウェアを提供する（大事なのはドキュメントではない）
- フィードバックを求める
- 必要とあらば進路を変える
- 成果責任を果たす（質、期限、期待、予算）
顧客の信頼貯金をコツコツ貯めよう
ビジネス側の人と一緒に仕事しよう
-
自己組織化
- 自らのエゴを出しすぎないようにしながらチームで力を合わせること
- 自分達で計画を立てて、当事者意識を高める
- 自分から動く人を迎え入れよう
- 肩書を気にするのではなく、良いプロダクトづくりに着目しよう
-
成果責任と権限委譲
- 自分達で判断して自分達が正しいと思うことを実行できるだけの権限を与える
-
ゼネラリストの集まりが理想的
- スペシャリストが必要な場面でだけ、スペシャリストを呼べば良い（DBチューニングなど）
プロジェクトを成功させたいなら、専任のプロダクトオーナーがチームにジョインしたほうが良い
-
手順
- 何を作るべきか決める
- 優先順位を付ける
- スコープを決め、やらないことを決める
２．アジャイルな方向づけ
- インセプションデッキ；プロジェクトを理解するために、聞きづらいことは最初に聞いておく
- 我々は何故ここにいるのか；チームの目的についてチーム全員の認識が揃っていたほうが良い
- エレベータピッチ：２センテンスでプロジェクトを説明
- 解決したい課題やニーズ
- 誰向けか
- プロダクト名
- 何をするものか
- 利点・強み
- 既存手段より優れている点
- パッケージデザイン；このプロジェクトが雑誌の広告なるならどんな広告か
- やらないことリスト
- ご近所さんを探せ；関係者は思っているより多い、プロジェクトの終わりに急に関わるのではなく、事前に仲良くなろう
- 解決案を描く
- 夜も寝れない課題とは
- 期間を見極める
- 何を諦めるのか（期間、スコープ、予算、品質）
- 何がどれだけ必要か
３．アジャイルな計画づくり
リスク管理
- 失敗しそうなありとあらゆることを髪に書き出す
- それを未然に防ぐにはどうすべきか真剣に考える
- チームにとって取り組む価値のあるリスクを見極める
- 変えることができる物事
- 変えることが出来ない物事
ユーザーストーリー
-
要素
- 独立した
- 交渉の余地がある
- 価値をもたらす
- 見積もれる（１〜５人日が理想、数週間レベルでも可）
- 小さい
- テスト可能
-
テンプレート
- 誰のためのストーリー
- 何をしていのか
- 何故そうしたいのか
-
絵や図
- ペルソナ
- フローチャート
- シナリオ
- システム図
- プロセスフロー
- コンセントデザイン
- 絵コンテ
- ペーパープロトタイプ
初期の見積もりは、細かい日数ではなく小中大で良い（相対見積もり）
初回の計画づくり
-
１．マスターユーザーストーリーリストを作成
- リストの規模を見積もる
- 顧客が優先順位付け
- 長くとも6ヶ月に収める
-
２．初回リリースを定義する
- 最少かどうか
- 市場価値があるかどうか
-
３．リリース単位をイテレーション単位（１，２週間）に区切る
- 予想外のシナリオ
-
シナリオ追加
- 全体的な見積もりのあとにユーザーストーリーが追加されたら、顧客には別のユーザーストーリーを削除してもらう
- 何でも詰め込む、ということはしない
- 同じサイズのユーザーストーリーを削ってくれるわけではないので、その場合はスコープ調整（おすすめ）・期日延長
- 無茶に付き合う余裕はない、ありのままを顧客に伝え、勇気ある決断を促す
- こちらが感情的になる必要はなく、顧客には自分の下した決断の与える影響をきちんと自覚してもらう
- 顧客が決めあぐねていたら「あるといいなリストに追加しますね」
- ただしあるといいなリストは当面スコープ外
- スケジュールに余裕があったらやる、程度
-
思ったより開発速度が遅い
- 慌てず最初に立てた計画を過信しないように伝える
- ありのままを誠実に顧客に伝え、スコープ調整・リソース追加・期日延長を相談