アジャイルサムライ
目次
原則
・２週間に１回成果を出す。
(テスト済みのプログラムを納品する)
進捗報告、顧客満足向上、要件定義の再確認、またはその修正を促す効果がある。
・暗黙的な期待⇒明示的な期待に変換しなければならない。
3つの真実
(1)プロジェクトの開始時点で要求が揃う事はない。
(2)プロジェクトの途中で要求が変わらない事はない。
(3)やるべき事は与えられた予算・時間よりも必ず多い。
アジャイル開発に適したチーム・メンバー
・権限、役割をチームが持つ。個人ではない。
・顧客が協力的
・メンバーと頻繁にコミュニケーションが取れる
・メンバーがジェネラリストである事
メンバーをバスに乗せる(プロジェクト開始時点)
・最初が肝心。
最初がダメで途中から上手く行く事はない。
・顧客を含めて認識を共通化する。
・インセプションデッキを作成する(以下をメンバーが説明できる様にする)
・目的は？期間は？
・エレベーターピッチ
30秒以内にプロジェクトの目的を説明する？
・パッケージデザイン
雑誌の1Pに広告を載せると仮定して簡潔に効果的にメリットを提示する
・やらない事リスト
・問題点、解決策
・何を諦めるか？
・何が必要か？
やる事、やらない事、後で決める事、現在の課題等を顧客を含めたメンバーと話し合った後、
・予算
・期日
・スコープ(開発範囲)
いずれかを変更しなければならない時。
多くの場合削るのはスコープ
やる事⇒やらない事
へ変更する。
ユーザーストーリーを作る
要件定義書の代わりにINVESTなユーザーストーリーを作る。
Independent(機能が独立している)
Negotiable(交渉できる)
Valuable(顧客に取って価値がある)
Estimatable(見積もれる)
Small(小さい)
Testable(テストできる)
小さく、顧客に取っての機能ごとに、カードに書き出す。
顧客の要求を素早く短く書き出す事が目的。
要件定義書の様に作成する事が目的になり、それに時間を掛けてはいけない。
あくまで顧客の要求は変わり続ける事を前提にする事。
見積もり
見積もりは約束ではなく、
極めて楽観的で当てずっぽうな目標でしかない事を顧客にも理解してもらう。
見積もりの原則
・相対サイズで
例
①クッキー１枚食べるのに１分掛かる。
②では１０枚食べるのには１０分掛かる。
この時、②の工数は相対的に正確に見積もれる。
・絶対サイズの機能は、相対測定可能な機能にまで細かく分割する
※なお、①の工数を正確に算出する作業も必要
・ポイントを使用する
例：数字以外の入力を認めないチェック機能の追加に0.5人日⇒5pt
・日数を使用する場合は日⇒理想日と置き換える
プロジェクトが開始され、開発速度を計測できる様になると見積もりを修正する事
例：数字以外の入力を認めないチェック機能の追加：5pt⇒7pt
計画
・(繰り返しになるが)スコープを柔軟に、期日はまだ約束ではない(現時点で当てずっぽうだから)事を顧客に認めさせる。
・一般に機能の50%は使われていない事実を念頭において、ストーリーリストに優先順位を付ける。
・ベロシティ(チームの開発速度)を仮決めする(当てずっぽう)
・仮決めしたベロシティを元に期日を仮決めする(当てずっぽう×2)
・バーンダウンチャートを作成する
※開発開始前。ベロシティは当てずっぽうで期日も仮。
※ベロシティは予想より遅くこのままでは期日に間に合わないので、
イテレーションを削除してもらう。
※イテレーションを追加した事により予定の期日に終わらない事が確実に。
期日を延ばすか？ イテレーションを削除するか？を決める必要がある。
これらを全て顧客と情報共有する事。
(ベロシティが遅いのは怠慢でなく開発側が悪い訳ではない事を理解してもらう)
イテレーションはチームが責任を持つ事。
(誰か個人が悪い訳ではない。見栄も隠し立てもする必要はない)
イテレーションを追加せざるを得ない状況になったのも誰かが悪い訳ではない。
顧客、開発側、皆で問題に当たる。
その結果、計画は現実的な予定表となる。
プロジェクト運営
(再)要件定義
・開発直前に要件定義・分析を行う。
(数か月前にやると要件が変わる。下手するとなくなる。またそれを忘れる)
・↑の際にはペーパープロトタイプでデザイン。顧客と情報共有。
・フローチャート作成(開発側視点)
・ペルソナ作成(システムの擬人化)
・受け入れテスト作成(顧客と一緒に)
開発
・イテレーションゼロ(CI環境構築)
・ペアプログラミング
・受け入れテスト(テストが自動化されていても)
・カンバン(同時に仕掛れる数の上限を決めておく)
コミュニケーション
今回のイテレーションに備える
今回のイテレーションのフィードバックを得る
次回のイテレーションの計画を立てる
次回のイテレーションで改善できる余地を探す
見える化
前述したものも含め、以下の様なものを壁に張り出しておく事で、
仕様(要件)の理解、仕様を理解した上での開発、全体のスケジュールを理解した上での現イテレーションで為すべき事等が常に分かった上で開発を進められる。
当然上司や顧客にすぐに説明できるし、急な仕事が割り込んできた時の影響等も分かる。
・インセプションデッキ
・リリースボード
・ストーリーボード
・バーンダウンチャート
・チームの約束事、大切にしている事
プログラミング
CIツールを用いて以下を行う。
・ユニットテストの自動化
・リファクタリング
リファクタリングは小まめに。
大がかりなリファクタリングはイテレーション化する。
・テスト駆動開発
(テストファースト)
テストコード記述⇒コーディング⇒テスト⇒リファクタリング⇒テスト を1セットとする。
・継続的インテグレーション
CIツールを用いて、ソース管理、ビルド、テストを自動化する。
「常」に、「すぐ」に、リリースできる状態にしておく為に。
開発環境で動作したものを顧客に渡すのではなく、
顧客に渡されたものを変更する、という意識で開発を行う事で、
要求が満たされた、バグのない(テスト済みの)ソフトウェアになる。
(「継続的インテグレーション」参照)
アジャイルサムライ用語解説
・マスターストーリーリスト
＝スクラム開発におけるプロダクトバックログ
・ユーザーストーリー
＝フィーチャ
・フィーチャ
＝ユーザー視点での機能
≒スクラム開発におけるバックログ
・イテレーション
＝フィーチャ毎の開発サイクル(設計～開発～テスト～納品)
１～２週間が望ましい。
それより大きくなると分割して別のフィーチャとする
・ベロシティ
＝チームの開発速度
・インセプションデッキ
・バーンダウンチャート
・スクラム開発
デイリースクラム / バックログ / プロダクトバックログ / スプリントバックログ
・エクストリーム・プログラミング
１週間でできる会員サイト「Limited」
必要最小限。だから分かりやすい。始めやすい。続けやすい。
限定① 安⼼・安全の会員制
限定② 必要最⼩限の機能
限定③ 独⾃機能を追加可能
