あらすじ
※この商品はタブレットなど大きいディスプレイを備えた端末で読むことに適しています。また、文字だけを拡大することや、文字列のハイライト、検索、辞書の参照、引用などの機能が使用できません。
アジャイル（俊敏な、フットワークの軽い）開発の実践的な側面を解説した書籍。単なる開発手法の教科書ではなく、実際の開発現場から生まれたアドバイスや手引きを、具体例を用いて達人プログラマが伝える。
原書は、2007年Software Develompent誌Jolt Awardで一般書籍部門のProductivity Award を獲得。
感情タグBEST3
Posted by ブクログ
光栄なことに翻訳の査読をやらせていただいたので、本書に関しては発売前に一通り読むことができた。しかし、献本していただいたものを改めて通読してみた。一言で言えば、グッジョブすぐる。
そして、本書を読み始めてすぐ、「コレハ！」と思ったところに付箋を付けていく、という方法は早々に破綻しそう（付箋がいっぱいですごいことになりそう！）なことに気づき、アンダーラインを引いていくことに切り替えた。
最初のプラクティス「成果をあげるのが仕事」に従えば、監訳者の角谷さんと木下さんは、これを十分にクリアした。この本はただの翻訳書ではない。見事なローカライズがなされている。原著をあたる方がいい翻訳書はたくさんあるけれど、この本に限っては違う。
成果（アウトプット）について触れたけれど、この本ができていく過程に一部関わらせてもらった感想として、そのプロセスもまた素晴らしかったことを付しておく。この過程も含めて本書の評価に反映せざるを得ない。
本書は「プラクティス」という名前を関している。このプラクティスが指しているのは「心構え」であったり「習慣」であったりするのだけど、本書にはその具体的なインプリメンテーションは書かれていない。それでいてなお、実践的だ。
アジャイルプラクティスを実装するのはあなたのチームであり、本書はそのためのテストコードになると思う。本書を読み終えた段階はテストコードが揃った状態であり、最終ページに書いてあるように、「これからが本番」と言える。
監訳者紹介文に倣って、私もプラクティスベスト3を挙げておく（3つに絞るのはとても大変だった）。
5.「変化に付いていく」
34.「警告をエラーとみなす」
41.「メンターになる」
咀嚼して、飲み込んで、そしてまた反芻していきたい、そんな本に出合えた僥倖を素直に喜びたい。
本書を通じて、自分の中にメタファーを持つことの意義にあらためて気づいたけれど、それはまた別の機会に。
Posted by ブクログ
ソフト開発プロセスは、ヘビー級なもとのライト級なものに二分される。大抵のまともなプログラマーはヘビー級を嫌う。なぜなら、ヘビー級は、「ユーザに提供されるもの意外を沢山つくることを強制する」、「硬直的で、官僚的」、「チームの社会的側面を軽視する」、「聞いたこともないようないろいろな職種を定義する」などの非効率的アプローチであるからだ。本書は、この対極であるライト級プロセスの一般名称アジャイルプロセスのベストプラクティス集である。昨今、ヘビー級の失敗のおかげでアジャイルが注目されているため、「アジャイルＸＸＸ」なる本は偽物が多く出回っており、名前だけでプラクティスを選ぶとだまされることになる。だまされないためには、著者や監修者、コメンテータの欄に"Kent Beck"、"Andy Hunt"、"Dave Hunt"ら著名且つ有能なプログラマーの名前を探すことである。という意味で、本書は読む前から良書であることが約束された書籍である。従って、プログラマーなら内容を問わず取り合えず読むことをお勧めする。とは言え、折角私のコメントを読んでくれている人のために、少しだけ本書の内容に触れよう。 本書は４５の厳選されたプラクティスから成る。各プラクティスは、それぞれについて ・最初に、そのプラクティスを皮肉るような「悪魔の囁き」が来る。 ・その後、そのプラクティスの詳細な説明があり、 ・続いて、「悪魔の囁き」に対する「天使の助言」が来る ・そして、このプラクティスが引き起こすであろう感情を「こんな気分」で説明し、 ・とは言え、「バランスが肝心」で、やりすぎは良くないと戒めるというような構成になっている。 本書が第一に紹介しているプラクティス「成果をあげるのが仕事」を、著者自体が忠実に守っているため、アジャイル・プロセスの解説書としての出来はすばらしい。また、リファレンスして便利に使えるような工夫も随所に見られるため、上級者の再学習用としても秀逸。ということで、繰り返しになるが、あなたがプログラマーなら取り合えず読むことをお勧めする。
Posted by ブクログ
ソフトウェア開発をアジャイルに行うための習慣が45書かれている。 今まさにアジャイルにプロジェクトを進めている自分にとって、実に納得の内容だったり、頭ではわかっていても全然できていないことがあったりで、もやもやしていたところがある程度スッキリできてとてもよかった。 各プラクティスの冒頭には「悪魔の囁き」があり、よくありがちなアンチパターンがあり、終わりにはアンチパターンに対応する「天使の助言」がある。これらもよくまとまっててとても参考になった。 アジャイルな開発は個々の相乗効果を高めることを常に意識しておかないとダメだな、ということを再認識できた。変なプライド(がもしあれば)は捨てて謙虚にいかないとね。 タイトルは「アジャイルプラクティス」となっているけど、アジャイルでないプロジェクトでも実践すべきプラクティスがいくつか書かれているので、ソフトウェアエンジニアは必読の一冊だと思う。
Posted by ブクログ
ソフトウェア開発における一種の態度である「アジャイル」のバイブルとでも呼べる一冊．経験豊富なプログラマである著者たちの実体験から引き出された，往々にしてプログラマたちの手から離れ怪物と化してしまうソフトウェア開発をいかに制御するかというノウハウ，心構えが述べられている．
一読した上での最初の印象は，こういったソフトウェア開発の新しい態度を導入するための最大の障害は，同じプログラマの同僚やマネージャであろうということ．アジャイルなソフトウェアの本質は，「変化を恐れない」という態度にあるが，この変化を恐れないという態度を受け入れるのは人間にとって容易なことではないと思われる．アジャイルな態度に出発するには，そういった頑迷固陋な同僚を啓蒙するような力が必要になってくるが，それはもう本書のスコープとは異なったものであろう．
そんな職場はさっさと辞めろ，というのが本書にはある．よりよい環境のためにリスクを取って今の環境から抜け出るのもアジャイルな態度なのだろう．
Posted by ブクログ
面白かったのは「コードレビューのパターン」で、３つの模様を紹介している。コード見直し模様。
オールナイタ
お奨めしないそうだけど、年に１回はやりたい。ちょうど、昔のJUSE、今のSWESTみたい。徹夜とすればよかったかも。
ピックアップゲーム
SHIP ITを参照せよとのこと。日本語版の書名は「Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック」。読んでみます。
ペアプログラミング
ドライバとナビゲータだそうです。運転者と道案内とすればよかったかも。
ps.
安価な教材を探してみると，本書が候補になりました。
大事なことは漏れなくかいているし，具体的な方策についても提案がある。
Posted by ブクログ
[○11/09/25完読]遅ればせながら読んでみた。間違いなく良書です。個人的な経験から重厚長大なプロセスに力点を置いている開発組織よりも、アジャイル（本書にあるような事にしっかり取り組んでいるアジャイルで現場・現物・現実主義）開発に力点を置いている組織のほうが、うまくいっていると感じる。作っているものの特性によっても違うと思うのですが、これを勘違いして他人のふんどしで相撲をとろうとしてしまっているチームも多いのも大間違いではないかと。巻末にまとめられている「天使の助言」の意味が腑に落ちるように自らのものとし、着実に現場に入れていくことが肝要と思いました。本書もJolt Awardsを受賞しているようで、他の受賞作もやはり読むべきかもしれない・・。
Posted by ブクログ
・継続的な開発。イテレーティブな開発。
・アジャイルツールキット
Wiki
バージョン管理
ユニットテスト
ビルドの自動化
・大きな失敗は学習の機会。
・魔女狩りをしない。
・テストコードを率先して書く。
・クラス、コンポーネントは出来る限り小さく。
・メンターになる。知っている知識を共有しあう。
・凝集度の高いコードを作る。なんでもできまっせなクラスは作らない。目的は一つだけにする。
・プロジェクト用語集をつくる。全員で用語の共有を行う。
・頻繁なデモでフィードバックを得る。
Posted by ブクログ
つまみ食い可能なプラクティス集。
現場や状況に合わせてピックアップ、実践しながらブラッシュアップ、と地道にやっていくための足がかり。
相反するプラクティスなんかも普通に掲載されているので、結局は自分たちで実践して選んでいくしか正解はない。
Posted by ブクログ
ソフトウェアを開発する者にとっていつも側に置いておきたい一冊だと思う。
疲れた時、迷った時、沈んでいる時、困ったときにおもむろに開き、プラクティスに目を通すとその時自分に必要なプラクティスが飛び込んで来て、SEやプログラマのあるべき姿を提示してくれるような気がする。
Posted by ブクログ
アジャイルについてスッキリと理解できた。仕様は変わるものってのはホントそのとおり。いくら長い期間設計に費やしても変わる。その変化にどう対応（前向きに）していくかが問題。一掴みずつでも参考にして実践するべき。
Posted by ブクログ
これは面白かった。
こうしたらうまくいくよーってのが色々書いてる。
まぁ実践済みもあるけど。できてないのもある。ウチの環境じゃできないのもある（←
Posted by ブクログ
各トピックについて天使の助言と悪魔の囁きが対比で書かれているため、解説と合わせて読むことで実践すべき行動や考え方とその反対にやってはいけないことが整理されやすいと感じました。
Posted by ブクログ
とても良い本でした。
ソフトウェア開発にたずさわる読者に、「アジャイルであること」とは何なのかを理解させ、アジャイルプラクティスの試行を大いに助けてくれる本です。
アジャイル(Agile)とは、直訳すると「機敏である」ということ。
ソフトウェア開発において、最終的な製品の仕様が開発段階であらかじめ完璧に決まっているなんてことはあり得ないんだから、当然完璧な要求仕様やスケジュールなんか最初から組めるわけない。エクセルで開発スケジュールを作り、スケジュールが変化するたびに(スケジュールは当然変化する)エクセルのスケジュールをちまちま編集する、そんな馬鹿げたことに無駄な時間と労力を費やすよりも、とにかく作ろうとするソフトウェアをモジュール単位に分割して、何かしら設計してみて、コーディングして、コンパイルして、テストして・・・のサイクルを機敏に繰り返して素敵な製品を作って進化させていこうよ、という設計姿勢が「アジャイルであること」らしいです。
開発段階では仕様が確定していないので、素敵な製品の定義というのもこの時点では曖昧です。アジャイル開発は、その曖昧さを解消するために、ソフトウェア開発者にユーザーと常に接することを求めます。作った(あるいはテスト中の)ソフトウェアをユーザーに見せ、ユーザーからのフィードバックを反映し、より良いアイデアを能動的にユーザーに提案し、再テストする。この繰り返しが、ユーザーにとっての素敵な製品とは何かを定義づけていくプロセスであり、この繰り返しのプロセスを設計者がアジャイルに(機敏に)できる環境を構築することが、アジャイル開発の肝であるようです。それは例えば、分割したモジュールのコンパイルが容易であるとか、自宅からでもモジュールのチェックイン/アウトができてどこにいてもソフトウェアが作れる環境にあるとか、競合(同モジュールをチームの複数人が同時に編集しようとする)が発生しにくい仕組みやチームワークを構築する、といったことです。
チームワークの重要さもよく述べられていました。現代のアプリケーションの規模を見たときに、そのソフトウェア開発をひとりで行うケースというのは現実的でなく、ソフトウェア開発は常にチームで進められるものであるから、そのチームワークは大切であるとのことです。その有効な方法として例えば、短いスタンドアップミーティングをチーム内で毎日実施して開発者同士の進捗を確認するとともに交流を深めたり、ひとりひとりがチームにとってのメンターになる意識を持って自分の知識をチームと共有する機会を設けたり、といったことです。自分の知識は思わぬところで他人の役に立つことがあるから、とにかくメモ書きでもブログでもなんでもいいから残して共有しておくと良く、またそれを継続するためには自分自身が常に勉強する意欲と他人から教えを請う姿勢が常に求められるので、結果として自分もチームメンバーも互いに向上し合える、というのが「メンターになる」ことのメリットだそうです。(実際、「アジャイル開発」という言葉を全く知らなかった僕がこの本を読むことになったのも、チームの先輩から教えてもらったことがきっかけでした。)
最後に、ソフトウェア開発における「設計」について述べられた文章が印象的でしたので、ご紹介します。
『設計とは、直面している問題それぞれに固有の解決策である。現場でそのまま使えるほど詳細に事前設計することは難しい。最初の段階では、まだ問題の背景も十分わかっていないし、フィードバックもほとんどない。設計は時とともに進化するのだ。アプリケーションの実態(そして実装)を無視して、新しい機能や機能の強化を設計することはできない。(著書より抜粋)』
Posted by ブクログ
まだアジャイルの概要以外何にも知らない状態から読んだ。
易しい言葉で書かれているので読みやすいし、すんなり理解できて良かった。
実際の現場と比較しながら読めたのも面白かった。
Posted by ブクログ
テスト駆動開発、継続的インテグレーションといったいわゆるアジャイル手法についてひと通り書いてある本。（良書だと体系的にまとめてあると表現するところだが、別に体系的になっているわけではない）。ブログとかで色々散見したものが1冊にまとまっているので考えを改めて整理するにはいいと思います。これからエンジニアとして一歩を踏み出す人におススメです。すでにアジャイル関連のブログとかで知識がある人は改めて読むこともないかなと。
Posted by ブクログ
アジャイル開発をするうえで必要な習慣や心構えが紹介されている。アジャイルの入門書なんだろうけど、開発に携わっている人なら別にアジャイルでなくても、十分役に立つ内容だと思う。内容は短くまとまってるし、文章も硬くないので、読みやすかった。
私としては以下のプラクティスが印象的だった。
・批判するなら人ではなく、アイディアに
・作る前から使う
・時が来たら習慣を捨てる
・ソリューションログをつける
・シンプルにする
Posted by ブクログ
プログラマが意識していなくてはならないことが書いてある。
しかし、この手の本を読んでいる人には少し物足りないかもしれないが、再認識という意味でも有益な内容であった。
スタンドアップミーティングに関しての記述は面白いし、実際に一昨年は行っていたが、効率的にミーティングを行う事を考えていた当時を思い出した。
Posted by ブクログ
いくつかアジャイル本を読んでいるので内容は既知で、重なる部分が多かった。それでも、いくつかは意識してないプラクティスがありメモしました。
メモしたいプラクティス
・設計は指針であって、指図ではない。
設計は実装を始められるだけ詳細であればいい
・受け入れテストを自動化する
受け入れ評価する担当がSeleniumかければよいのかなぁ
・アーキテクトもコードを書くべき
PowerPointでコードはかけない
・答えを見つけられるように力を貸す
メンターになってチームを育てる。
いじめっ子(Tormentor)にならないように。
Posted by ブクログ
タイトルにあるように、現場開発者にとって有用なアジャイル・プラクティスを紹介する本。
変化に対応するために色々な本・雑誌を読め、など、アジャイル・プロジェクトとは直接関係がなく、要は「職業人としてアジャイルであるためのプラクティス」といった事柄にまで言及している点に特徴。
ただ、他のアジャイル本をいくつか読んだ人間からすると、特に新鮮味のない提言が並んでいるようにしか見えなかった。
☆３つ。
Posted by ブクログ
アジャイルの考え方が、具体例を交えながら書かれてて、とても分かり易くよい入門書。
アジャイルの考え方は、システム開発だけでなく、小規模のチームで何かをやる時にも当てはまる。そういう人たちが読んでも気づきがあると思う。
Posted by ブクログ
アジャイル開発のキーワードを45個にしぼり、１つずつでも実際に取り入れられるよう記載されている。
例えば、「顧客に決めてもらう」「デプロイを自動化する」とか。
一番興味深い一言は「ソフトウェアを仕事にするのは、ランニングマシンに乗っているようなもの」「イテレーティブかつインクリメントに学習する」「顧客は、実装された機能を使って初めて自分たちの出した要件の理解を深めていく」「メンターとはチームメイトの成長を助けると同時に自分自身も成長すること」「ブタとニワトリ。ベーコンエッグ。」
Posted by ブクログ
会社に置いてあったので、読んでみました。
私はソースとにらめっこして開発する業務は出来ませんが、
読んでみました。
サービスを企画開発販売するうえで、アジャイルって手法は
無視できないのかなーと思って手に取ってみました。
無視できない理由としてはアジャイルを採用して
ビジネススピードが速くなるのかなと。
まあ、アジャイルに切り替えるとかって、みんなの共通理解が
ないと難しいよね。
書かれていたのは、こんなことのような気がします。
・各プロセスにおけるプログラムの書き方
・各プロセスにおけるバランスの取り方
－スピードのバランス
－品質のバランス
－メンバとの共有のバランス
朝会とスタンディングの打ち合わせが、有効だってことも納得。
ところどころプログラムの書き方については、飛ばして読みました。
Posted by ブクログ
Agile入門書。読むに当たってオブジクト指向への理解があることが好ましい。
HOW-TOより心構えに多くの紙面が割かれている。そしてそれらはAgileに限らずエンジニア全般に有効な意識だと感じた。
しばらく寝かせて、何度か読み返す（レトロスペクティブ！）必要がありそうだ。
Posted by ブクログ
なんかよく覚えてないけど、そこそこ面白かった気がする。
とにかく、アジャイルってなにか良く分からないし。
とりあえず読んでおく分には刺激になるだろうってとこか。
