各トピックについて天使の助言と悪魔の囁きが対比で書かれているため、解説と合わせて読むことで実践すべき行動や考え方とその反対にやってはいけないことが整理されやすいと感じました。

再読、実体験が増えていくと納得感が増す。キーセンテンス並べるだけで、自問自答するのに役立つ。バランス大事。

光栄なことに翻訳の査読をやらせていただいたので、本書に関しては発売前に一通り読むことができた。しかし、献本していただいたものを改めて通読してみた。一言で言えば、グッジョブすぐる。 そして、本書を読み始めてすぐ、「コレハ！」と思ったところに付箋を付けていく、という方法は早々に破綻しそう（付箋がいっぱいですごいことになりそう！）なことに気づき、アンダーラインを引いていくことに切り替えた。 最初のプラクティス「成果をあげるのが仕事」に従えば、監訳者の角谷さんと木下さんは、これを十分にクリアした。この本はただの翻訳書ではない。見事なローカライズがなされている。原著をあたる方がいい翻訳書はたくさんあるけれど、この本に限っては違う。 成果（アウトプット）について触れたけれど、この本ができていく過程に一部関わらせてもらった感想として、そのプロセスもまた素晴らしかったことを付しておく。この過程も含めて本書の評価に反映せざるを得ない。 本書は「プラクティス」という名前を関している。このプラクティスが指しているのは「心構え」であったり「習慣」であったりするのだけど、本書にはその具体的なインプリメンテーションは書かれていない。それでいてなお、実践的だ。 アジャイルプラクティスを実装するのはあなたのチームであり、本書はそのためのテストコードになると思う。本書を読み終えた段階はテストコードが揃った状態であり、最終ページに書いてあるように、「これからが本番」と言える。 監訳者紹介文に倣って、私もプラクティスベスト3を挙げておく（3つに絞るのはとても大変だった）。 5.「変化に付いていく」 34.「警告をエラーとみなす」 41.「メンターになる」 咀嚼して、飲み込んで、そしてまた反芻していきたい、そんな本に出合えた僥倖を素直に喜びたい。 本書を通じて、自分の中にメタファーを持つことの意義にあらためて気づいたけれど、それはまた別の機会に。

[備考] https://www.amazon.co.jp/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B9-%E9%81%94%E4%BA%BA%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%81%AB%E5%AD%A6%E3%81%B6%E7%8F%BE%E5%A0%B4%E9%96%8B%E7%99%BA%E8%80%85%E3%81%AE%E7%BF%92%E6%85%A3-Venkat-Subramaniam/dp/4274066940/ref=pd_sim_14_4?_encoding=UTF8&pd_rd_i=4274066940&pd_rd_r=285a40d9-e24e-11e8-a9bf-17b1a941fca2&pd_rd_w=IF6PG&pd_rd_wg=suwCM&pf_rd_i=desktop-dp-sims&pf_rd_m=AN1VRQENFRJN5&pf_rd_p=68cfebef-f8b4-4691-9d72-a10f0956615a&pf_rd_r=EN6MCF3N3A8SMTDE6R54&pf_rd_s=desktop-dp-sims&pf_rd_t=40701&psc=1&refRID=EN6MCF3N3A8SMTDE6R54

いくつかアジャイル本を読んでいるので内容は既知で、重なる部分が多かった。それでも、いくつかは意識してないプラクティスがありメモしました。 メモしたいプラクティス ・設計は指針であって、指図ではない。 　設計は実装を始められるだけ詳細であればいい ・受け入れテストを自動化する 　受け入れ評価する担当がSeleniumかければよいのかなぁ ・アーキテクトもコードを書くべき 　PowerPointでコードはかけない ・答えを見つけられるように力を貸す 　メンターになってチームを育てる。 　いじめっ子(Tormentor)にならないように。

ソフト開発プロセスは、ヘビー級なもとのライト級なものに二分される。大抵のまともなプログラマーはヘビー級を嫌う。なぜなら、ヘビー級は、「ユーザに提供されるもの意外を沢山つくることを強制する」、「硬直的で、官僚的」、「チームの社会的側面を軽視する」、「聞いたこともないようないろいろな職種を定義する」などの非効率的アプローチであるからだ。本書は、この対極であるライト級プロセスの一般名称アジャイルプロセスのベストプラクティス集である。昨今、ヘビー級の失敗のおかげでアジャイルが注目されているため、「アジャイルＸＸＸ」なる本は偽物が多く出回っており、名前だけでプラクティスを選ぶとだまされることになる。だまされないためには、著者や監修者、コメンテータの欄に"Kent Beck"、"Andy Hunt"、"Dave Hunt"ら著名且つ有能なプログラマーの名前を探すことである。という意味で、本書は読む前から良書であることが約束された書籍である。従って、プログラマーなら内容を問わず取り合えず読むことをお勧めする。とは言え、折角私のコメントを読んでくれている人のために、少しだけ本書の内容に触れよう。　本書は４５の厳選されたプラクティスから成る。各プラクティスは、それぞれについて　・最初に、そのプラクティスを皮肉るような「悪魔の囁き」が来る。　・その後、そのプラクティスの詳細な説明があり、　・続いて、「悪魔の囁き」に対する「天使の助言」が来る　・そして、このプラクティスが引き起こすであろう感情を「こんな気分」で説明し、　・とは言え、「バランスが肝心」で、やりすぎは良くないと戒めるというような構成になっている。　本書が第一に紹介しているプラクティス「成果をあげるのが仕事」を、著者自体が忠実に守っているため、アジャイル・プロセスの解説書としての出来はすばらしい。また、リファレンスして便利に使えるような工夫も随所に見られるため、上級者の再学習用としても秀逸。ということで、繰り返しになるが、あなたがプログラマーなら取り合えず読むことをお勧めする。

とても良い本でした。 ソフトウェア開発にたずさわる読者に、「アジャイルであること」とは何なのかを理解させ、アジャイルプラクティスの試行を大いに助けてくれる本です。 アジャイル(Agile)とは、直訳すると「機敏である」ということ。 ソフトウェア開発において、最終的な製品の仕様が開発段階であらかじめ完璧に決まっているなんてことはあり得ないんだから、当然完璧な要求仕様やスケジュールなんか最初から組めるわけない。エクセルで開発スケジュールを作り、スケジュールが変化するたびに(スケジュールは当然変化する)エクセルのスケジュールをちまちま編集する、そんな馬鹿げたことに無駄な時間と労力を費やすよりも、とにかく作ろうとするソフトウェアをモジュール単位に分割して、何かしら設計してみて、コーディングして、コンパイルして、テストして・・・のサイクルを機敏に繰り返して素敵な製品を作って進化させていこうよ、という設計姿勢が「アジャイルであること」らしいです。 開発段階では仕様が確定していないので、素敵な製品の定義というのもこの時点では曖昧です。アジャイル開発は、その曖昧さを解消するために、ソフトウェア開発者にユーザーと常に接することを求めます。作った(あるいはテスト中の)ソフトウェアをユーザーに見せ、ユーザーからのフィードバックを反映し、より良いアイデアを能動的にユーザーに提案し、再テストする。この繰り返しが、ユーザーにとっての素敵な製品とは何かを定義づけていくプロセスであり、この繰り返しのプロセスを設計者がアジャイルに(機敏に)できる環境を構築することが、アジャイル開発の肝であるようです。それは例えば、分割したモジュールのコンパイルが容易であるとか、自宅からでもモジュールのチェックイン/アウトができてどこにいてもソフトウェアが作れる環境にあるとか、競合(同モジュールをチームの複数人が同時に編集しようとする)が発生しにくい仕組みやチームワークを構築する、といったことです。 チームワークの重要さもよく述べられていました。現代のアプリケーションの規模を見たときに、そのソフトウェア開発をひとりで行うケースというのは現実的でなく、ソフトウェア開発は常にチームで進められるものであるから、そのチームワークは大切であるとのことです。その有効な方法として例えば、短いスタンドアップミーティングをチーム内で毎日実施して開発者同士の進捗を確認するとともに交流を深めたり、ひとりひとりがチームにとってのメンターになる意識を持って自分の知識をチームと共有する機会を設けたり、といったことです。自分の知識は思わぬところで他人の役に立つことがあるから、とにかくメモ書きでもブログでもなんでもいいから残して共有しておくと良く、またそれを継続するためには自分自身が常に勉強する意欲と他人から教えを請う姿勢が常に求められるので、結果として自分もチームメンバーも互いに向上し合える、というのが「メンターになる」ことのメリットだそうです。(実際、「アジャイル開発」という言葉を全く知らなかった僕がこの本を読むことになったのも、チームの先輩から教えてもらったことがきっかけでした。) 最後に、ソフトウェア開発における「設計」について述べられた文章が印象的でしたので、ご紹介します。 『設計とは、直面している問題それぞれに固有の解決策である。現場でそのまま使えるほど詳細に事前設計することは難しい。最初の段階では、まだ問題の背景も十分わかっていないし、フィードバックもほとんどない。設計は時とともに進化するのだ。アプリケーションの実態(そして実装)を無視して、新しい機能や機能の強化を設計することはできない。(著書より抜粋)』

ソフトウェア開発をアジャイルに行うための習慣が45書かれている。 今まさにアジャイルにプロジェクトを進めている自分にとって、実に納得の内容だったり、頭ではわかっていても全然できていないことがあったりで、もやもやしていたところがある程度スッキリできてとてもよかった。 各プラクティスの冒頭には「悪魔の囁き」があり、よくありがちなアンチパターンがあり、終わりにはアンチパターンに対応する「天使の助言」がある。これらもよくまとまっててとても参考になった。 アジャイルな開発は個々の相乗効果を高めることを常に意識しておかないとダメだな、ということを再認識できた。変なプライド(がもしあれば)は捨てて謙虚にいかないとね。 タイトルは「アジャイルプラクティス」となっているけど、アジャイルでないプロジェクトでも実践すべきプラクティスがいくつか書かれているので、ソフトウェアエンジニアは必読の一冊だと思う。

読みやすくてためになった プログラミングの会社に勤めている人なら部分的に取り入れるだけでもいいと思う

まだアジャイルの概要以外何にも知らない状態から読んだ。 易しい言葉で書かれているので読みやすいし、すんなり理解できて良かった。 実際の現場と比較しながら読めたのも面白かった。

2015/03/09 08:00 アジャイルを実践しようという感じの本だということで、読んでみた。 そんなに新しい本ではないからか、あまり目新しさはなかった。 アジャイルってなんか原理主義の宗教くさい感じがしていて、避けていたんだけど、この本ではそういう印象は全くなかった。 開発手法に関わらず取り入れることができそうなことが多かったので、今後役に立てたい。

金言の宝庫です。 オブジェクト指向やアジャイルといった単語に馴染みがなくても得るものは非常に多い良書と思います。

タイトルにあるように、現場開発者にとって有用なアジャイル・プラクティスを紹介する本。 変化に対応するために色々な本・雑誌を読め、など、アジャイル・プロジェクトとは直接関係がなく、要は「職業人としてアジャイルであるためのプラクティス」といった事柄にまで言及している点に特徴。 ただ、他のアジャイル本をいくつか読んだ人間からすると、特に新鮮味のない提言が並んでいるようにしか見えなかった。 ☆３つ。

ソフトウェア開発における一種の態度である「アジャイル」のバイブルとでも呼べる一冊．経験豊富なプログラマである著者たちの実体験から引き出された，往々にしてプログラマたちの手から離れ怪物と化してしまうソフトウェア開発をいかに制御するかというノウハウ，心構えが述べられている． 一読した上での最初の印象は，こういったソフトウェア開発の新しい態度を導入するための最大の障害は，同じプログラマの同僚やマネージャであろうということ．アジャイルなソフトウェアの本質は，「変化を恐れない」という態度にあるが，この変化を恐れないという態度を受け入れるのは人間にとって容易なことではないと思われる．アジャイルな態度に出発するには，そういった頑迷固陋な同僚を啓蒙するような力が必要になってくるが，それはもう本書のスコープとは異なったものであろう． そんな職場はさっさと辞めろ，というのが本書にはある．よりよい環境のためにリスクを取って今の環境から抜け出るのもアジャイルな態度なのだろう．

凄く良くまとまっていて、アジャイル開発何も知らない人が読むなら良いと思う。自分にとっては見聞きしたことのある話が多かったかなぁ。

アジャイルの考え方が、具体例を交えながら書かれてて、とても分かり易くよい入門書。 アジャイルの考え方は、システム開発だけでなく、小規模のチームで何かをやる時にも当てはまる。そういう人たちが読んでも気づきがあると思う。

アジャイルな考え方。 変化に臨機応変に対応した考え方のもと、テスト駆動や自動化を扱った開発手法はとてもためになり、力になる。 あとはユーザー主体でプロジェクトを動かしていくのは正しすぎる考え。 でもアジャイルって呼び方が自体をややこしくしている気はする。

テスト駆動開発、継続的インテグレーションといったいわゆるアジャイル手法についてひと通り書いてある本。（良書だと体系的にまとめてあると表現するところだが、別に体系的になっているわけではない）。ブログとかで色々散見したものが1冊にまとまっているので考えを改めて整理するにはいいと思います。これからエンジニアとして一歩を踏み出す人におススメです。すでにアジャイル関連のブログとかで知識がある人は改めて読むこともないかなと。

プロジェクトを進める手法として、とても参考になりました。ソフトウェアプロジェクトだけでなく、いろんな場面で応用できそうです。

アジャイル開発手法における、多くのプラクティスを紹介した本。 最近、アジャイル開発についていろいろな本を読みたいと思っていたところ、同僚が貸してくれたの読んでみた。 本の分量は、がんばれば1日から2日で読める程度なので、読み飽きることはないと思う。自分は、電車に乗っている時間を使って読んだので、一週間程度で読了した。 内容としては、多くの開発者が陥ったり、日々やってしまいがちなアンチプラクティスを取り上げ、それに対するアジャイル的な改善を実践してみるといった感じ（たしかそんな感じ）。気軽に読めるので、ぜひともいろんな開発者に読んでもらいたい。そして、個人レベルからでもいいので、掲載されているプラクティスを実践して欲しいと思った。 特におすすめしたい層は、日々、漫然とプロジェクトに携わっている開発者かな。これを読むことで、なにか感じて欲しいし、仕事への向き合い方を考えて欲しいと思う。

会社に置いてあったので、読んでみました。 私はソースとにらめっこして開発する業務は出来ませんが、 読んでみました。 サービスを企画開発販売するうえで、アジャイルって手法は 無視できないのかなーと思って手に取ってみました。 無視できない理由としてはアジャイルを採用して ビジネススピードが速くなるのかなと。 まあ、アジャイルに切り替えるとかって、みんなの共通理解が ないと難しいよね。 書かれていたのは、こんなことのような気がします。 ・各プロセスにおけるプログラムの書き方 ・各プロセスにおけるバランスの取り方 　－スピードのバランス 　－品質のバランス 　－メンバとの共有のバランス 朝会とスタンディングの打ち合わせが、有効だってことも納得。 ところどころプログラムの書き方については、飛ばして読みました。

まだ読んでないけどたのしみ。 http://booklook.jp まだ読み途中なので特定のページを。 変化に付いていく。 分かっているつもりだったけど、技術者として生き残って行くためには、今の仕事で必要な技術だけを習得して行ってもだめ、世の中や時代が必要としている物を察知して学んで行かないとまずいんだな。 勉強会でも読書会でもいいから、まず何かやってみるべきだな。 とりあえず、 ・Human Interface Guide Line(Vista/７用ってのものあるんだ）とか ・HTML5の詳細とか。 読み切ったら、また何か書きます。 http://booklook.jp

[○11/09/25完読]遅ればせながら読んでみた。間違いなく良書です。個人的な経験から重厚長大なプロセスに力点を置いている開発組織よりも、アジャイル（本書にあるような事にしっかり取り組んでいるアジャイルで現場・現物・現実主義）開発に力点を置いている組織のほうが、うまくいっていると感じる。作っているものの特性によっても違うと思うのですが、これを勘違いして他人のふんどしで相撲をとろうとしてしまっているチームも多いのも大間違いではないかと。巻末にまとめられている「天使の助言」の意味が腑に落ちるように自らのものとし、着実に現場に入れていくことが肝要と思いました。本書もJolt Awardsを受賞しているようで、他の受賞作もやはり読むべきかもしれない・・。

Agile入門書。読むに当たってオブジクト指向への理解があることが好ましい。 HOW-TOより心構えに多くの紙面が割かれている。そしてそれらはAgileに限らずエンジニア全般に有効な意識だと感じた。 しばらく寝かせて、何度か読み返す（レトロスペクティブ！）必要がありそうだ。

・継続的な開発。イテレーティブな開発。 ・アジャイルツールキット 　Wiki 　バージョン管理 　ユニットテスト 　ビルドの自動化 ・大きな失敗は学習の機会。 ・魔女狩りをしない。 ・テストコードを率先して書く。 ・クラス、コンポーネントは出来る限り小さく。 ・メンターになる。知っている知識を共有しあう。 ・凝集度の高いコードを作る。なんでもできまっせなクラスは作らない。目的は一つだけにする。 ・プロジェクト用語集をつくる。全員で用語の共有を行う。 ・頻繁なデモでフィードバックを得る。

アジャイル開発をするうえで必要な習慣や心構えが紹介されている。アジャイルの入門書なんだろうけど、開発に携わっている人なら別にアジャイルでなくても、十分役に立つ内容だと思う。内容は短くまとまってるし、文章も硬くないので、読みやすかった。 私としては以下のプラクティスが印象的だった。 ・批判するなら人ではなく、アイディアに ・作る前から使う ・時が来たら習慣を捨てる ・ソリューションログをつける ・シンプルにする

つまみ食い可能なプラクティス集。 現場や状況に合わせてピックアップ、実践しながらブラッシュアップ、と地道にやっていくための足がかり。 相反するプラクティスなんかも普通に掲載されているので、結局は自分たちで実践して選んでいくしか正解はない。

プログラマが意識していなくてはならないことが書いてある。 しかし、この手の本を読んでいる人には少し物足りないかもしれないが、再認識という意味でも有益な内容であった。 スタンドアップミーティングに関しての記述は面白いし、実際に一昨年は行っていたが、効率的にミーティングを行う事を考えていた当時を思い出した。

アジャイルについては、ある程度知っていたのでそれほど新しい発見がないように感じたが、 本格的に仕事で導入するようになったらもう１回読みたくなりそう。 個人的に一番よかったのが以下のプラクティス。 ■ソリューションログをつける 同じ問題が発生した時に素早く解決するようにログを残しておく。 そのログには、以下のような項目を入れるといい。 ・問題が起きた日時 ・問題の簡単な説明 ・解決策の詳細な説明 ・詳細情報や関連記事への参照やURL ・解決の糸口や理解の助けになりそうなコード片、設定、ダイアログの画面キャプチャ 他のレビュー記事 http://dain.cocolog-nifty.com/myblog/2008/02/post_918a.html

日曜日に本屋で見つけて購入した本。 最近、本を買う際の参考情報としてはほとんどtwitterかfacebookでフォローしている方々のコメントばかりだったので、本屋で見つけて買うという事は久しぶりだった。 なのでこの本の事前情報は全くなく、本屋で立ち読みしえ選んだ本だったのだが、とても良い本を見つけたと思う。 「アジャイル」というシステム開発における心構え、考え方について書かれている本なのだが、単なる教科書的なノウハウを書いているのではなく、多くの開発現場を経験しないとわからない経験値をベースに書かれているなと感じた。 そのため「そうそう、そういうことってあるなー」という共感ポイントが多々あり、自分の行動パターンとの照らし合わせが簡単にできてしまう。 まだまだ前半しか読めていないが今のところ「そういう考え方ってないよな」と感じる部分は全くなく、同意できる部分ばかり。 この本では「アジャイルに関するプラクティス」だけではなく、問題解決における考え方、チームで物事を達成するために必要な考え方、行動指針についても書かれているなと感じている。 オススメ。

ソフトウェアを開発する者にとっていつも側に置いておきたい一冊だと思う。 疲れた時、迷った時、沈んでいる時、困ったときにおもむろに開き、プラクティスに目を通すとその時自分に必要なプラクティスが飛び込んで来て、SEやプログラマのあるべき姿を提示してくれるような気がする。

アジャイルについてスッキリと理解できた。仕様は変わるものってのはホントそのとおり。いくら長い期間設計に費やしても変わる。その変化にどう対応（前向きに）していくかが問題。一掴みずつでも参考にして実践するべき。

なんかよく覚えてないけど、そこそこ面白かった気がする。 とにかく、アジャイルってなにか良く分からないし。 とりあえず読んでおく分には刺激になるだろうってとこか。

なんか、とても読みたかった本だという気がするのだけど、読んだかどうか忘れてしまった。例によって、会社の仲間が持っているので貸してもらおう。

これは面白かった。 こうしたらうまくいくよーってのが色々書いてる。 まぁ実践済みもあるけど。できてないのもある。ウチの環境じゃできないのもある（←

会社の本棚から借りた本。 あまり期待してませんでしたが、 結構面白い。 「こんな気分」とか悪魔のささやき、のとことか あー、あるあるとついつい思ってしまう。 うちも「アジャイル」な開発ができるようになりたいもんです。

http://blog.setunai.net/20080715/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B9-%E9%81%94%E4%BA%BA%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%81%AB%E5%AD%A6%E3%81%B6%E7%8F%BE/

アジャイル本やらプラグマティック・シェルフから読み漁っている人には、特に目新しい話はなく、そのエッセンスだけを抜き出して短いエッセイ風の読みものにまとめた感じ。逆にアジャイル本とかに馴染みの無い人には、入門書としては薄くて読み易く丁度良いかも。

凄腕のプログラマ達が日々行っている，アジャイルな開発方法についてまとめたもの．いくつか参考になるものもありました．スタンダップミーティングは今すぐにでも取り入れたいです．