■
「強く強張ったものは折れる。しなやかなものは生き残る。---- Tao Te Ching」
私もしなやかでありたい。Tao Te Ching を調べたら、「老子の道徳真経」のことだった。
第8章 方向付けフェーズから推敲フェーズへ(P111)
推敲フェーズでは、「中核のアーキテクチャを構築」し,「高リスクの要素を解決」し,
「ほとんどの要件を定義」し,「全体的なスケジュールと資源を見積もる」
8.2 推敲フェーズの始動(P113)
- 一連の反復の先頭に位置する（2〜6週間の反復期間が推奨）
- プログラミングに早く着手する
- 本番稼動システムの一部を作成する（推敲フェーズは設計フェーズでも、実装に備えてモデルを完全に作成するフェーズでもない）
- 早期から頻繁に現実的なテストを行う
- フェーズの反復ごとに、ワークショップを重ね、ユースケースと要件のほとんどを記述する。
8.2.1 推敲フェーズで大切なこと(P114)
- 「広く浅い」設計と実装を採用する。（インターフェイスを明確にするために部分的に実装してみる。モジュールの大部分が「スタブ化されたコード」からなる）
- モジュール相互のローカルおよびリモートのインターフェイスを洗練する
- 既存のコンポーネントを統合する
- 多数の主要コンポーネントにまたがる設計,実装,テストが必要となる,頭から最後までの単純化されたシナリオを実装する
テストがとにかく大事！
フィードバックを獲得して、調整して、中核部が堅牢であることを実証しなきゃいけないから
（テストをしなきゃいけないものの例：ユーザーインターフェイスの使いやすさのテスト,リモートサービスに障害が発生した場合の回復のテスト,リモートサービスに高負荷をかけるテスト）
※これ、こないだのプロジェクトで失敗してることばっかだ・・・（汗。POSで障害起きたけど復旧に時間かかったし、リモートのポイントシステムが高負荷で落ちたし・・・。こんな早い段階で作ってテストするものなんかー。ビックリ。
8.6 推敲フェーズを理解していない状況(P117)
- ほとんどの要件が、ここまでに定義済みだった
- 数ヶ月以上をかける
- 1回しか反復しない
- あくまでプロトタイプを作ってしまう（本番稼動システムには組み込めない）
- 完全な設計を行おうとする
- 要件を調整し、改良するということを行わない。（先に進むだけで戻らない）
※「理解してない状況」シリーズおもろいっっ！身につまされます。ホントに。
