初めてのアジャイル開発

読んだり読まなかったりを繰り返していたが最近読了。

第2章 反復型と進化型

イテレーションの終了日を固定することをイテレーションのタイムボックス化という。

1年ほど前、イテレーション1のときの失敗談。
スコープ定義で決めたとおりにイテレーションが進捗しなかったので
イテレーション2を進行しながらイテレーション1で終わらなかったものを
実装するイテレーション1.1という意味のないイテレーションを作って
チームを混乱させたことがある。イテレーションはタイムボックス化した
ほうがよい。スコープ定義どおりに進捗しなかったとしたら振り返って、
次のイテレーションに含めれば良いだけ。

あとイテレーションの進行中に（スコープ定義の後に）新規で
タスクを追加しないほうが良い。

第3章 アジャイル

アジャイル宣言と原則が書かれている章。当たり前のことだが非常に大切な事が書かれている。
以下コピペ。

アジャイルソフトウェア開発宣言

• プロセスやツールよりも個人と相互作用
• 包括的なドキュメントよりも動くソフトウェア
• 契約交渉よりも顧客との協調
• 計画に従うことよりも変化に対応すること

アジャイル原則

1. 最も重要なことは、価値あるソフトウェアを早い段階から継続的に納品し、顧客を満足させることである
2. たとえ開発が進んだ後であっても要求の変更を歓迎する。アジャイルなプロセスとは、顧客の競争優位のために変化を生かすものである
3. 動くソフトウェアを頻繁に納品する、その感覚は2,3週間から2,3ヶ月で、短いほど良い
4. ビジネスサイドの人間と開発者が、プロジェクト全体を通じて毎日一緒に仕事をしなければならない
5. やる気のある個人を中心にプロジェクトを構築する。環境を整え、必要なものを提供し、仕事をやり遂げてくれると信用することである
6. 開発チームに対して、あるいは開発チーム内で情報を伝えるために最も効率的かつ有効な手段は、直接の対話である
7. 動くソフトウェアこそが進捗を測る一番の尺度である
8. アジャイルなプロセスは、開発の持続可能性を促進するものである。スポンサー、開発者、ユーザーが一定のペースを無期限に保てなければならない
9. 技術的卓越性と優れた設計に常に注意をはらうことが、アジャイルさを向上させる
10. 簡潔さ（できるかぎり作業をしないですませる術）こそ本質である
11. 最も優れたアーキテクチャ、要求、設計は、自己組織化チームから創発されるものである
12. チームは定期的に、より効果的な方法を検討し、自分たちのやり方を調整し適合させる

第7章 スクラム

ブタとニワトリが新しく開くレストランの名前について話し合った。ニワトリは「ハムエッグ」を提案したが、ブタは「それはごめんだね」と言った。「君は生むだけだけど、僕は切り刻まれるんだよ」

スクラムミーティングの際、チーム外のメンバー（ニワトリ）は輪の外に出る。

定義されたプロセスよりも経験的プロセスを重視することがスクラムの重要なテーマである。

これは良きこと。

第11章

既に多くの書籍で書かれているがテスト駆動開発の効果は大きい。
テスト駆動開発だけでも即実践できるプラクティスだ。

総評

変化を受け入れる。コミュニケーションを重視する。フィードバックを受け入れる。
基本原則さえ守れているならどんなプラクティスでも良い。

P169 にすごく好きになった言葉があった。

複雑に考えることは簡単である。
単純に考えることは非常に難しい。
ー カーバー・ミード

初めてのアジャイル開発　?スクラム、XP、UP、Evoで学ぶ反復型開発の進め方?