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