価値ある成果を毎週届ける
- 分析 必要なぶんだけ、必要なときに
- 開発 しっかり
- テスト はやめ こまめ
の3つをチームが実践できるようにする
アジャイルなイテレーション
分析、開発、テストその他ぜんぶを1つのイテレーションでやりつつ、フィードバックを行う。
予期せぬ事態が発生したらイテレーション終了時に軌道修正を行う
分析
必要な分とは、どのくらいなのか。
分析をやりすぎても、やらなさすぎてもNGで、
タスクやテスト条件を書き出す。
その際、図や文書を使うのは必須である。
分析のタイミングであるが、
ユーザーストーリーを実装するタイミングが近付いてから、突っ込んで分析するということである
万物は流転するから、実装するギリギリまで待ったほうが良い。
ストーリーが複雑になりそうなら、フローチャートを作る。
次にペルソナを作る。
ペルソナとは、ユーザー毎にどのような役割で、なにをしようとしている人達なのかを
決めるための目安である。
そしてペーパープロトタイプをたくさん作る。
分析のためのツールは他にも沢山あるので、使えるものはどんどん使っていくべし。
開発
- 自動化されたテストを書く
- 設計を継続的に発展させていき、改善し続ける
- ちゃんと動くソフトウェアであり続けるために、コードを継続的にインテグレーションする
- 顧客がシステムについて語る言葉に合わせてコードを書く
イテレーション・ゼロ
実装前にに済ませておきたい段取りのこと。
- ソースコード管理
- ビルドの自動化
- 開発環境やテスト環境
テスト
- だいたい動いていることを確認する
- できるかぎり自動化する
お客様の前でデモをやるのは良い方法である。
全てのテストが完了していてもなお正式な受入テストは必要である。
カンバン(組立ラインでのパーツ補充の工程を調整する仕組み)を利用する。
カンバンではWIP(Work In Progress)を利用し、
チームが同時に着手する作業の数に制限を設ける。
それも優先順位の高い作業から着手していく。これにより
イテレーションを使うか、カンバンみたいなのを使うかはあなた次第という気分だ。
分析→開発→テストの作業を繰りかえすわけだが、
その方法に唯一無二のベストは存在しない。
