イテレーション

アジャイル開発における開発期間のこと。（≒スプリント） 1~2 週間でストーリーを動くソフトウェアに変換していく

イテレーションの進め方

Step1 分析と設計をする

• 「必要な分を、必要なときに」分析する。
  • 同じ場所で働いているならインデックスカードと会話で事足りることもある。
  • もう少し大きな規模なら、概要をまとめた文章・ストーリーをタスクに分解したリスト・テスト条件の一覧などがあればよい。
  • イテレーション(n)で分析して、イテレーション(n+1)で開発する

• 複雑なストーリーなら、それ相応に時間にかけるしか無い。
  • フローチャートを書いて、システムの動作・必要な手順を示す
  • ペルソナを作り、どんな人達がどうやって使うかを示す
  • ペーパープロトタイプで色々なデザインを試す
  • 受け入れテストを書く
    • インデックスカードの裏に「このストーリーが完成したことを確認できそうなこと」を3 つ書こう

Step2. 開発する

• 自動テスト・CI/CD・TDD などのプラクティスを徹底する
• イテレーション・ゼロ（はじめのイテレーション）に環境構築をする
  • ソース管理
  • 開発環境・テスト環境
  • ビルド自動化
  • アーキテクチャスパイク
    • ストーリーを 1 つ選んでアーキテクチャの土台にする

Step3. 作業の結果を確認する

• お客さんにデモをしながら、ストーリーの受け入れテスト条件を一つづつチェックする

イテレーションの長さ

チームによって適切なイテレーションの長さは変わる。 以下の項目を考慮してイテレーションの長さを決める。

• リリースまでの期間
  • 短期間ならイテレーションも短くするほうがいい。
• 不確実性の高さ
  • 不確実性が高いプロジェクトならイテレーションも短くするほうがいい。
    • ベロシティの計測頻度を増やしたり、ユーザからのフィードバックを得る機会を増やして不確実性を減らせるため。
• フィードバックの得やすさ
• 優先順位が安定している期間
  • イテレーション中に優先順位は変えないほうがいい。
• 外部からのフィードバックの必要性
  • チーム外にイテレーションの成果を見せて初めて作業が無駄になることがわかるケースが有る。
  • 外部からフィードバックを得る頻度が低くなればなるほど判断を謝る可能性が高まる。
• イテレーションのオーバーヘッド
  • リグレッションテストなど、イテレーションを繰り返すためのコストが高い場合は長めにする。
• 切迫感を感じ始めるまでの時間
  • 日々の作業で感じるプレッシャーが均一に感じられるような長さのイテレーションにする
  • 4週間にすると、最初の1週間はのんびりと仕事をしてしまう