フィールドバック ⇒ 工程の後戻り ⇒ 無駄工数
と私は考えていましたが、

ソフトウェア製品に対するお客さんの満足度を高める、ベストなプラクティスだとこの本を読んで思いました。

今後の開発アプローチの参考にしていきたいです。

冒頭にわかりやすい定義が示される。

　　　（ソフトウェア）開発がアジャイルであるということは、協調性を
　　　重んじる環境で、フィードバックに基づいた調整を行い続ける
　　　とである。（P4）

この定義に従えば、アジャイルであるということを重視すればするほど、
環境や継続（習慣）、つまり開発する「人そのもの」を重視する必要
が出てくることになる。なるほど確かに、本書は、その「人そのもの」
に対する実践例が豊富に掲載されていた。

　　　作業が完了したら、実際にかかった時間をありのままに記録し
　　　よう。たぶん最初の見積りより長くかかっているんじゃないだ
　　　ろうか。でも、それでいいんだ。（P97）

　　　通常、スタンドアップミーティングは一日の早い時間帯の、全
　　　員が出勤しているタイミングに行う。ただし、朝一番にはやら
　　　ないこと。出勤時刻の３０分から１時間後に始めるのが適切だ
　　　ろう。（P153）

　　　悪いニュースを最後まで伝えないでいるということは、マネー
　　　ジャや技術主任に「自分のことを事細かく管理してください」
　　　と頼んでいるようなものだ。（P172）


各実践例とともに、実践する際の気分が記述されている。人の行動は、
その時の気分に左右されるという本質を捉えた構成だ。

これは面白かった！

全編にわたって興味がある事柄ばかりで、本が蛍光ペンの線だらけに。
これは本当に、ソフトウェア開発に関わっている人なら読んだ方がいいです。
というか、読むべきです。

もう全部が興味深い内容だったため、これ、というのが絞れないのですが、
印象に残っている言葉の一例を下に。


「チームは一致団結する場だ」

「“自分のせいじゃない”というのが正しいことはまずない」

「選んだ道が正しくても、座り込んでたら轢かれてしまう」

「シンプルなコードには、挑むだけの価値がある」

「コードは、書かれることよりも読まれることのほうがずっと多い」

「開発者たるもの、自分が書くコードを“もっとわかりやすくできないか”と
自問し続けなければならない」

「システムの核心にある詳細を理解することなしに、
設計者として有能でいられるわけがない」

「良い設計者とは、腕まくりをして自分の手を汚し、
躊躇することなくコードを書く人のことだ」

「システムのどの部分であっても、担当することから逃げてはならない」

「あなたのアイデアを聞けば、私は知識を得る。
私が知識を得ても、あなたは何も失わない。
それは丁度、あなたの蝋燭で私の蝋燭に火を灯しても、
あなたの炎を暗くさせることなく私が光を得るのと同じだ」

「明らかに改善されたとわかる代替案を自分が出せるのでもない限り、
コードの批判はしないこと」

「仕事を引き受けたということは、期限までに終わらせると約束したということだ」


・・・などなど。
座右の銘になるような言葉が多く、読み物として大変面白かったです。

他、スタンドアップミーティングやユニットテスト、バージョン管理など、
興味深い項目がたくさんありました。

この本はもう本当に、折にふれて度々読んでいきたい本です。

全章を通じて具体的な技術にはあまり触れずに、客観的な視点からアジャイル開発者の「あり方（心構えや思考）」を導いてくれます。

アジャイルとう言葉を全く知らない人も含めて、この本はソフトウェア開発に関わる全ての人に読んでいただきたい。まさに教科書です。

私は仲間にもこの本を自信を持って紹介しています。

色々と他のアジャイル本を読みましたが、この本が一番、アジャイルソフトウェア開発をプロジェクトにどのように適用すればよいか具体的で分かりやすかったです。

全体の構成も各項目が短くまとめられていて読みやすかったです。
200ページの専門書ですが３日ほどで読めてしまいました。

プロジェクトが上手くいかないと嘆いている暇があったら、読む価値は絶対にあります。
ブタであるプログラマ（読んでもらうと意味が分かります）の生き残るためのバイブルです。

アジャイル開発初心者におすすめ。