リスト：ソフトウェア・エンジニアリング(開発) を表示しています。（全 24 件）

ピーター・コードは昨年のJavaOneのBoFで、開発プロセスを不断にみがいていくことが重要と言っていた。では、何か教科書を選んで、開発手法を採り入れて、その教科書への忠実さを徐々にあげていけば良いのだろうか?しかし、ここで少し冷静になってみると、教科書に忠実なプロセス＝磨きのかかったプロセスという論理には無理があることに気づく。二の間には様々な要因があり、ケースバイケースというのが実状ではないだろうか。アジャイルソフトウェア開発では教科書的な視点より、「みがきをかける」ために必要な視点を提供することが重視されている。そのため、教科書本やHow to本のように、一度読んで、その後は辞書的に使うといった類の本ではない。何度も時間があれば読み返し、自分の現状と照らし合わせ、考えるための本だと思う。そのためカルい気持ちで読むよりは、しっとり読みたい。開発に携わる人間なら、その価値は充分にある。最後に急いで訳出したためだろうか、「ユニーク」でよいところをあえて「愉快な」と訳してみたり、利己的な遺伝子で知られるドーキンスの「ミーム」を「メメ」(太文字強調付き)と訳していたりする。コーバーンの引用は実に幅広い分野から取られており、訳出するのは大変だとは思う。しかし、日本語訳が良ければ、5つ星に相当する射程を持っていることは間違いない。シリーズの今後の訳には期待したい。（angelic / 2002-09-06）

アジャイルとかXPとかは、普段なにげなくやっていることを体系的に記述したものだと思います。
本書の付録に、武蔵の五輪書についての記述があります。
古くからやっていたことを、新しい道具でやるとどうなるかということの一面が、アジャイルでありXPではないかと思います。
それが再確認できるよい本だと思います。（kaizen / 2008-01-17）

「方法論」って何か？という根本的な問題から始まり、方法論を考えるための視点、そして活用しよう！という内容がメインだと思います。
方法論と言えば、手順（プロセス）、成果物というキーワードで語るもの、と思ってましたが、この本で目が覚めました。
今まで、ＸＰとかアジャイル等の本を読んでも、「ピンとこない」ことが多かったんですが、この本を読んで、その原因がわかりました。方法論の捉えかたが違ったんでした。ＸＰやアジャイルの根本にある考え方が、わかった気がします。
結構、読むのにパワーがいりましたが、その分の価値を得られた本でした。
実際、この本を読んだから、「方法論が身につく」ことは、ないかもしれませんが、今後の情報システム開発を行う上では、役に立つ考えかた、視点が身についた気がします。（lemonerika / 2004-03-03）

RUPといった方法論は基本的に開発の流れを定義していますが、
ことアジャイルに関しては特に決まった定義はないようです。
スタンスとしてはうまくいけばそれでいいのでは？と言った感じでしょうか。
ただ、プロジェクトをうまくいかせるにはどうすればよいか？といった
事例については適当な数紹介されています。
個人的にはこの本をよんだことで開発が劇的にうまく行くとは思えませんが、
プロジェクトを円滑に進める上で参考になると思います。
読み物としても面白いですよ。ただ、ＸＰのこと（例えばペアプログラミング）が良く出てきますね。
「開発環境構築」＋ＸＰ＋コラム（実例）といった感じでしょうか（むにゃ / 2003-04-23）

→アジャイルという開発方法論を
　発想の原点から実践例まで説明してくれます
　５Ｗ１Ｈを余すことなく．．
→すなわち、ソフトウェア開発というものは
　そもそもどういった人たちが（ＷＨＯ）
　どんな時間的制限下で（ＷＨＥＮ）
　どんな環境で（ＷＨＥＲＥ）
　どんなソフトウェアを（ＷＨＡＴ）作るのか
　．．そして、それをうまくやるためには
　どうやったらいいのか（ＨＯＷ）
　それはなぜか（ＷＨＹ）．．
→この本の中で著者は、
　対象とする開発量の大きさを
　「軽量級」と「重量級」という言葉を使い
　それぞれに対応する方法論を提示してくれています
　その分析の明快なこと　明快なこと！
　
→さらには、
　ソフトウェア開発が人で行われているということをふまえ
　その「人の行動特性」、特に「失敗する」ということに
　着目した分析は見事！
　「間違える」「保守的な失敗を好む」「調べるよりも作る」
　「習慣の生物である」「一貫していない」
　の５つの解説は、忘れがちな人間の行動を本質から捉えており
　秀逸です！
→付録で
　剣豪、武蔵の論文が紹介されています
　また、この解説がすばらしい！
　時間がない方は、ここだけでも！（よこはま　こうたろう / 2007-10-13）

タイトルには”アジャイルプロジェクト管理”とりますが、内容は、原題の "Surving Ojbect-Oriented Projects" の示す通り、オブジェクト指向を開発技術のベースとしたプロジェクト事例から成功／失敗要因を導出し、その考察を記述をしたもので、邦題にわざわざ”アジャイル”と銘打った理由が判りませんでした。（監訳者あとがきに、それらしい理由は書いてありますが・・）
序文の日付をみると1997年10月となっており、この事でも示されるとおり、記載内容の情報が少し古い様に感じられます。1997年時点で完了または進行中のプロジェクトからのヒントとトピックで本の内容が構成されており、もう一冊のシリース本である『アジャイルソフトウェア開発』のような具体的なプロセスの説明を期待して読んだので、期待外れの感がありました。『人月の神話　著：フレデリック・Ｐ・ブルックス，Jr.』で代表されるプロジェクト管理の古典本に分類される本と考えて読むと良いと思います。（fuuchan2 / 2004-06-10）

期待して購入したが訳があまりに拙く，途中で読む気を無くした．
全体に訳がこなれていないだけでなく，以下のように意味不明な文章が目立つ．
34ページ「アーキテクトはメインフレームのオブジェクト指向でないコードの，
以前とは別の方法による開発を推奨するかもしれない」
256ページ「専門分野で華やかにする」
同じページ「経営陣はしっかりとサポートし，常に激励し，
モラルの低い期間も自由に抜け出させるようにした」
監訳者の経歴を見ると非常に立派なのだが，
もう少し内容に責任を持って欲しいと思う．（KN / 2004-06-27）

アジャイルなプロジェクトを管理するためのポイントを説明した本です。失敗したプロジェクト、成功したプロジェクトの例、そこから教訓を引き出されるプロジェクトのポイント、プロジェクトの組織化（メンバの役割）、計画、見積等のポイント、インクリメンタルな開発方法の説明とポイント等です。全体的にプロジェクト管理の技法というより、プロジェクト（管理）を成功させるためのポイントの説明、という印象の本です。
事例、教訓、そしてポイントも、オブジェクト指向を利用したプロジェクトが対象となってます。
「アジャイルソフトウエア開発」等のアジャイル開発の内容を知ってから読んだ方がよいです。
珍しく、付録が、かなり役に立ちそうな本です。「リスク削減のためには、何をするべきか」が端的に、わかりやすくまとまってます。
もう一つ、付録として本書の内容を要約した（？）１ページ程の「プロジェクト管理虎の巻」がついてます。（lemonerika / 2004-04-16）

アジャイルな開発の必要性、「エコシステム」という方法論の原則や価値観・考え方、XPやFDDIなどアジャイル開発方法論の各論の説明、そして「エコシステム」を実際に組織に適用するには、という内容です。
ボリューム的には、「エコシステム」の原則や価値観・考え方を述べた部分が多いです。半分ぐらいあった印象です。事例、有名人とのインタビューなど、多彩な書き方がしてあります。
アジャイルの各論の説明、アジャイルの歴史も充実していて、アジャイル開発方法論の勉強になります。方法論設計の考え方などもあり、方法論者には、読んでおいて損のない本であると思います。
明日からすぐ役立つか、はちょっと難しいかですが、示唆に富んだ奥深い本であった印象です。ボリュームもあり、内容の濃いので、じっくりと取り組みたい本です。
アジャイル方法論について、ある程度知識があってから読んだ方が良い本であると思います。（lemonerika / 2006-06-30）

SCRUMは、ソフトウェア開発のアクティビティや成果物を定義しないものなので、UMLによるモデリングやテスト・ファーストなどの話は全くありません。（読み進めるのにオブジェクト指向の知識は特に必要ありません）逆にプロジェクトマネジメントのスコープ管理、リスク管理、スケジュール管理のコンパクトな管理システムとプラクティスを示しており、反復型のソフトウェア開発のプロジェクトマネジメントを実践する上でとても参考になりました。この本を読む前に、背景にあるマネジメント哲学および基本プラクティスとして、本書が参考文献にあげているセンゲの"The Fifth Discipline"のラーニング・オーガニゼーション（学習する組織）を理解しておくとよいと思います。残念ながら和訳は絶版ですが、姉妹書籍の"The Fifth Discipline Fieldbook"の和訳が"フィールドブック 学習する組織「5つの能力」"日本経済新聞社 ISBN 453231075Xが入手可能です。（neu-neu / 2004-01-04）

スクラムという方法論の、手順、プラクティス、有効性の説明、既存の方法論の問題とスクラムでの解決策、スクラムの導入方法、そしてスクラムを利用したプロジェクトの管理手法の紹介です。
プロジェクト管理手法のボリュームが、他の方法論の本より、詳しく、具体的に書いてある印象です。
最初にこの本を読んだ時は、よく理解できませんでした。が、アジャイルの入門書を読み、スクラムの概要を掴んでから読むと、理解できた部分が多かったです。
スクラムに関する知識だけでなく、ウォーターフォール等、今までの方法論・プロジェクト管理手法の問題点等もしっかり分析してあり、知識が深まりました。スクラムの導入の如何によらず、方法論やプロジェクト管理に興味があれば、読んで損はない、印象です。
個人的には、読みやすい本ではなかったですが、しっかり読むと「なるほどー！」と思う点が多々ありました。（lemonerika / 2005-08-25）

　３、４章の説明はよくまとまっており、ＦＤＤの概要を把握できます。
　課題を細かく分割し、役に立つ機能を小刻みにリリースしていく。さらに柔軟性を損なうことなく質を維持して進捗管理もきちんとやろうというところがいいと思います。なるほど守備範囲が広いと納得しました。
　しかし訳文は今ひとつで、読み難いところが結構あります。（ヒラです / 2003-07-14）

ＦＤＤは Peter coad がCEO兼社長の TogetherSoft社の開発プロセス標準だそうです。　本書の内容は、著者が開発管理者を務めた
シンガポールの銀行のシステムの大規模開発の事例をベースにＦＤＤのKnowHowを説明してあります。
ＸＰと従来のプロジェクト管理の手法を足して２で割ったような感じですので、実際の現場には適用しやすいと思います。
『ＸＰ開発の理念には感動を覚えるが、実際の適用には漠然と不安を感じる』という方には、特に本書は参考になる１冊だと思います。
訳については、他のレビューの指摘でもありますが、こなれていない個所が散見されイマイチだと思いましたが、たいした問題でもありません。（fuuchan2 / 2004-06-11）

ＸＰじゃ、荒っぽすぎる。伝統的な方法論じゃ重すぎる。そんな問題を解決するのが、ＦＤＤっという方法論です。
本は３部構成です。１部目は、ＦＤＤの考え方、代表的な手法・成果物の説明、進捗管理の具体的な方法、プロジェクトの組織（役割）のしかた、などです。２部目は、開発プロセスを１つ１つ順に、その目的、内容、成果物、誰が何をやるのか、そのプロセスのポイント、終了条件などが、詳しく説明されています。３部目は、テスト、変更管理の概要が簡単に書いてあるレベルです。１部目、２部目が中心です。
ＦＤＤを使う／使わないに関わらず、読んでおけば、これからのシステム開発のヒントになることがある、印象の本です。
チャレンジする場合、プロセスが丁寧に説明されているため、手元において置きたい１冊です。参考文献も充実しています。（lemonerika / 2004-05-01）

XP以外のアジャイル開発手法について書かれた数少ない本です。
実践的な内容が書かれており、ためになるのですが、何故かXPと比較した場合のFDDについて書かれている内容が多いです。
監翻者のコメントとして、XPを批判する内容が書かれていますが、そもそもXPもFDDもその基本理念はおなじはずですし、この監翻者の方はXP関連の翻訳本の監翻もされている方なので、なぜこのようなコメントを書くのか理解できません。
最後に、翻訳の質についてはあまり良いとはいえませず、読みづらいところが多々あります。英語が苦にならない方は、原書を読むことをおすすめします。（ / 2003-08-24）

日本XPユーザグループとして様々な言語の xUnit を紹介したいのは理解できるのですが、結局ツールの紹介記事になってしまっています。私が読みたかったのは「テスト技法」だったんですが．．．、中身をよく見ずに買った私も悪いのですが、そのあたりの突っ込みが薄いのにがっかりしてしまいました。
XPユニットテストの概要と各種テストツールの概要をすばやく頭に入れたいならこの本はぴったりだと思います。（中村拓男 / 2002-11-16）

XPでは
試験
コーディング標準
短期出荷
単純な設計
週４０時間労働
共同所有
継続した結合
は、XPを知る前から、本当はあたりまえのことだと思っていました。
しかし、いくつかの事項は、過去からの習慣により、実現することが難しい面がありました。
試験については、理論だけ書いてあるより、試験の枠組みの解説がしてあるので嬉しいです。ようやく試験が最初ということが現実のものにすることができます。
Junit, Ant, CVS, HttpUnit, RubyUnit+WebUnit, VBUnit, CPPUnitについて書かれているので、これらの言語で開発されている方には必須だと思われます。
ps.
私はC言語で開発しているのでCUnitの説明もあると嬉しかった。（kaizen / 2008-01-22）

Javaのテスト技法を読みたくて購入しましたが、RubyやVBも同様に
扱われているため、必要のない人には無駄なだけになってしまう。
ひとつの言語に絞ったほうがよかったと思う。（thinkmore / 2002-02-03）

そう、まさしくツールの紹介本です。「本書はXPの重要な要素である
「テスト」について解説したものである」とありますが、正しくはテス
ティングフレームワークとそれに基づいたテストツールの使い方概要が
書かれている本です。どちらかというと初心者向けの本だと思います。（エパメイノンダス / 2006-05-31）

XP(eXtreme Programing)に痺れた。XPは「あっ、これいいね」と思ったことを究極までに、とことんやり抜くプロセスだ。特にテストファースト(テストありきで、まずテストからソフトウェアを書く）は、今までのソフトウェアの作り方を逆転させる。そのやり方の入門書がこの本だ。この通りの実践と多少のテストの仕方のアイデアで、今後Java、Webアプリ、Ruby,VB,C++での開発成果物に自信を持つことができる。TestFirstを含むXPの浸透がIT業界を救う起爆剤になるかも知れない。（a-hashimoto / 2001-12-31）

XPを有名にさせた最初の本です。書いてある内容は良いし、構成や内容もよくまとまっているので、そういう意味で星を5個にしました。
しかし翻訳レベルは星1つです。私は原書で読んだことがあり、同僚と勉強会をするために邦訳にも目を通したのですが、原書の雰囲気は完全に失われています。誤訳、迷訳があちこちに散りばめられています。せっかく本の内容が優れているのだから、翻訳者の選択と出版社のチェックがもう少しまともだった良かったのですが。（ / ）

原書はXP哲学の源流を理解するために読む価値のある本です。XPに関するある程度の知識と好奇心を持った人をターゲットにしているのことに注意して下さい。XPに関して全く何も知らない読者向けではありません。
この訳書に関しては、他の方々からのレビューにもあるように、翻訳のレベルに問題がります。訳者の方の苦労・努力がいかに大変なものであるのかよく理解しているつもりですし、翻訳者に対して個人的な攻撃をするつもりは毛頭ありませんが、自腹でこの本を購入したいち読者の立場で正直に言わせていただくと、かなり読者に負荷をかける訳になっています。残念です。かなり訳文の解読に苦労した挙句、結局、原著を購入することにしました。（ / ）

技術用語の間違い、英語の文法の間違い、日本語として精練されていない文章。ほんの１ページ読むだけで、イライラします。いったい翻訳者は何をやっているのでしょう。機械翻訳の結果を安易に修正しただけのように思えます。確かに、技術書というには「文学的」な原書なので、翻訳に苦労するのも無理もありません。しかし、それだけに、安易な翻訳が残念でなりません。
内容的は確かに「あたりまえ」のことばかりです。「エクストリーム・プログラミング」という手法の是非はここで議論すべきことではありませんが、その「あたりまえ」の経験則を整理し、系統立てて説明したということに、この本の大きな価値があると思います。
エクストリーム・プログラミングについての書籍が少ない現状では、翻訳のレ!ベルが低いことを差し引いても、買って損はしません。値段がちょっと高いですが。（えせ / 2001-06-14）

日本語がわかりにくい箇所があるので、薄いけど読むのは大変です。内容はややもすると宗教書のような開発の心構えが書いてあって、「で、結局どうやって作ればいいんだよー」と思ってしまいますが、それについては、この続編の「実行計画」「導入計画」とかで明らかになってます。これだけ読んで理解しようとするとくじけるので、とりあえずやってみてやりながら理解するといいことがあると思います。（ / 2001-08-28）

実際にXPを実践してみて、この本の価値がわかりました。
最初に読んだときは、具体的にどうすればいいのかが、正直、わかりませんでした。実際の進めるにあたっては、「プログラミング導入編」「プログラミング実践記」が役に立ちました。ただ、プラクティスを行っていくと、うまく進まなかったり、メンバーが徐々に従来のやり方に戻ったりし始めました。そんな時、もう一度この本を読み直し、各プラクティスを行っていく意味をいうものを再認識しました。
書いてあることは、もしかすると当たり前のことかも知れません。しかし、実際の開発において、その当たり前のこと続けることは、案外難しいと思います。この本は、XPを続けるための拠り所になるような本だと思います。最初読んだときは、少し日本語にわかりづらいところがありましたが、２度目以降は、気になりませんでした。
実際にXPを行いながら、何度か読み直してこそ、価値のある本だと思いました。（ / 2002-02-24）

序文に、DEMARCOが機動性について述べている。
「SEIやCMM同様XPは今の世の中に欠くことができない」
この言葉にピンと来る人は、この本を最初に読んでもよいと思います。
そうでない人は、同じシリーズの入門から読まれることをお勧めします。
ps.
ケントベックが日本に来た際のXPユーザ会の会合は、
ネクタイ半分、ラフな格好半分と、プログラマのコミュニティとしては、
現状を反映していたような記憶があります。
XPのコミュニティの反映にとっては、大事な１冊だと思います。（kaizen / 2008-01-17）

日本語として成り立っていない、ロジックが変わってしまっている、など、出版物としてのレベルに達していないと感じた。
これだけXPに関する情報(しかも日本語の)が巷にあふれている今となっては、わざわざ読む必要性は低い。（ / ）

薄い本のため読みやすいのだが、内容的には抽象部分が多いような感じがした。
あと、訳本のためか少々日本語的にも読みづらい箇所がいくつかある。
「XPって何？」というような初心者の方には簡単に読めていいかもしれない。
ただ、どうせ読むならこちらより「導入編」の方がいいかも。（XPについて具体的に触れているため内容が濃いから）（みふぃ / 2001-09-10）

「XPとは何か？」「イテレーションをどう繰り返していくのか？」というという疑問については、答えていると思う。導入編より一歩進んだとは思うが、まだXPの全貌を説明しきっていない。
しかし、「ストーリーをどの様式で、どのレベルまでどう書くか？」「テストをするにはどんなツールを使うのか？」のような具体的な疑問については答えがない。
これらの疑問の答えは、XPシリーズの別な本を読まないといけないようだ。（motofji / 2003-02-17）

これまでいくつかでたXP本の不満を解消してくれる一品です。（ / ）

これまで出版されたXPシリーズを読んで、「実際にはどうしたらいいのだろうか？」と感じていた疑問がすべて解けました。特に衝撃を受けたのは、どうせ途中で要求が変わってくるのだから、最初からシステム全体にわたる完璧な設計をしてもムダである、という点です。設計に要する時間は、10分が理想。直ちにペアを組んでコーディングに向かうべし。コメントは、最小限にして、コードにすべてを語らせるべし。プロジェクト管理ツールを使うな、など、従来の開発手法からすると、「だいじょうぶなの？」と思わせるような提案が満載ですが、全体を読むと、さまざまな手法が効果的に組み合わせられていて、うまく行きそうな気がしてきます。おそらく、最大のポイントは、コミュニケーションの強化なのでしょう。<P!>これからXPを試してみようと思っている開発者にとっては、バイブルになると思います。
翻訳については、特に問題を感じませんでした。読みやすかったと思います。（XXXYYZZZ / 2001-09-03）

英語の文献は英語でよむプログラマが増えて欲しい。ただし、英語が読めるプログラマが偉い訳ではない。C言語ならC言語が読めればよい。
本書は、受入テストや小さなリリース、単体試験、テストファーストなど、あたりまえのことがあたりまえに書かれています。
おかしなプロセスモデルには、やらなくてもよい管理事項ばかり書かれていて、肝心のやらなくてはいけない技術的な事項がすっぽり抜けていることがあります。
原著の事例はSmallTalkだそうです。ただし、訳者らがJAVAに書き換えたものを付録につけているのでC言語系のプログラマでも理解できると思います。
エクストリームプログラミングって、普通にやっていることを少し誇張して極端に（extremely)書いただけのものだと思います。
そう感じない人がいたら、その人の仕事で大切なことが抜けているかもしれません。
ps.
ＸＰ関連のイベントで、ペアプログラミングについて、スピナッチパワーの土屋さんから、刑事が２人で捜査するようなものだと教えていただきました。これまで、ペアプログラミングに関する誤解が一気に解消しました。ありがとうございました。（kaizen / 2008-02-26）

　XP自体は画期的で注目していたのですが、まだ日本には書籍も情報も少なく、出版されるとすぐにこの本を購入しました。読んですぐに感じたのですが、日本語訳が変です。内容的には（日本語的には）間違ってないのですが、 なんというか受験英語的訳というか、何度か読み返して
その日本語が理解できるという感じで、読むのに苦労します。あんまりお勧めできる本ではないですね。（ / ）

カタカナ語が多いので読みにくいかもしれない。
日本語に翻訳しながら読むと、内容がよく分かる。
イテレーションは、繰り返し。
最初のイテレーションプランは、初回計画。
ストーリーは筋書き。
リリースプランは出荷計画。
日本語に直すと、文章が短くなって、内容が浮き出てくる。
JAVAの実例があるので、プログラムだけを追っかけるのもよいかもしれない。
（kaizen / 2008-07-08）

この本は実際に２人のプロジェクトでXPを行った場合にどんなことが問題となり、どのような利点があり、結果としてどういう収穫があったかを示しています。開発者が自分の言葉で書いているところが何より良い点で、とても読みやすいです。XPの実践は、２人（顧客を入れると３人）という小さな単位でも十分可能で（というより、むしろ向いている？）、重要なのはコミュニケーションだということがはっきりわかります。厚くなく、薄くなく、ソースコードも豊富で、XPシリーズの中では今のところ、これが一番さらっと読めました。（ / ）

理論面を書いたXPの書籍は多くありますが,実際の現場でのレポート例は
少なかったのではないでしょうか?
そういった意味で貴重です.
ただ,やはり日本と海外の文化の違いや,時代の違いを意識して読まないと
いけない点も多々あるように見受けられました.（IT侍 / 2006-09-28）

　XPのお話を大まかに掴むのにちょうどよいかもしれない。
書籍だとどうしても内容が古くなってしまったり、現実にそぐわない事例になってしまう感じがする。この本ではとあるネット関連の体験談を載せているが、生きた体験談を欲するならネットの方が豊富に落ちているし、自分の環境に近い実施例を見つけられると思う。（リーパー / 2002-07-23）

XP とは何だったかの復習から始めて、各プラクティスを適用するときの注意・実践を踏まえた意見など、厚い分だけ内容もしっかりしている。
今までのシリーズの中でもっともお勧めの本と言って良いであろう。（mft / 2002-09-14）

ＸＰとは何か？
ＸＰとは開発手法の一つである。
今までの古い考え方のソフト開発の手法に変わり
無駄なくシンプルに開発を行える手法である。
概要としてはペアでプログラミングを行う。
コードを書く前にテスト用のプログラムを作成する。
開発者と顧客の二つの役割を作る。
コードを共有する。
といったような方法が書かれている。
この他にも様々なＸＰの手法が書かれている。
比較的内容自体はわかりやすくかつ深い知識を習得できる本である。
今後ＸＰを開発手法として用いる事が多くなると予想されるので
開発者のかたは一度読んでみたほうがいいと思う。（みず / 2003-10-07）

プロセス擁護は宗教の勧誘のようだ。熱病を伴い、門に入り行為
することを求める。けれど変化に躊躇う人々が居るのも事実だろう
。プロセスの導入は一人だけのものじゃないし、コストはかかる
し、リスクもある。また、変化を起こすには、現状維持を否定
するため理由が必要である。僕は個人レベルで、うつむき加減に
同僚をマシンの横に座らせ、ペアプログラミングもどきを試みたり、
テスト主導開発を習慣づけたりするかたわら、スケジュール、
リスク管理を基礎から学びなおしつつ、CMM、RUP、Agile開発
プロセスを比較してきた。どうやったら組織に対し投資を促せるか
探っている状態である（もちろんXPはプラクティスの切り売りは
非推奨であるから、僕はXPを"実践"はしていないことを意識している。
あくまで、作業効率改善の実験に過ぎない）。その動機付けは
導入編によって与えられた。導入編を読み、開発プロセスに関心を
抱きつつ、しかし、熱病にうかされるには、まだリスクが大きい、
判断材料が必要であると感じている方は次にこれを読むとよいかも
しれない。著者は、XPのプラクティスを分解して吟味する。
（計画は？テストは？何故XPのプロセスがそもそもこのような
配置になっているのか？その力加減をカスタマイズすると
どのような影響が出るのか？）入り口で戸惑う入門者と同じ視線で。
特に「XPは何を恐れているか」についての考察は非常に客観的である。
（重量度の異なるプロセスは、それぞれに恐れを抱く対象があり、
それを包み隠すようにプロセスを組んでいる。よって、よしとする
結果はそもそも異質なものであり、各プロセス擁護者の相互批判は
意味をなさない、、という趣旨で良いか？？）
批判も積極的に受け入れるXPの懐の深さは賞賛に値するし、Kent
Beckの推薦の辞「けど僕は著者の結論に賛同しているわけじゃな
いよ」のあたりは、このプロセスを生んだSmalltalkコミュニティ
のユーモアとプライドを伺わせ、心地よい。私見だが、これはXP
シリーズの最終巻？と感じた。（takulog / 2003-01-14）

XPを銀の弾丸ととらえている人向けの本。（XPの精神は重要な価値があるが、チームにXPの精神をもたらすのは自分の英知なのだ）
実際にXPを導入する際のリスクの大きさを取り上げている。XPを導入するよりは既存のプロセスをカスタマイズしていくことのほうが有益というのが本書の主張だ。
ただし、既存のプロセスがXP から学べることを網羅している。それは著者が XPがもたらす価値を尊重している証拠だ。
実際にソフトウェア開発を改善する際、見落としているポイントがないかチェックするためにも、本書は読む価値あるといえる。
とりわけ「あなたのプロジェクトにとって重要なものは？」という問いかけは重要だ。（それはあなたにしか分からない）
人月計算でやって、少しでも開発期間を延長して開発費をいただくこと、予算ありきで帳尻を合わせるため単価の高いプロダクトを提供することが重要だったら、XPのプロセスは導入しないほうがいいに違いない。（narucy / 2003-05-03）

Ｗｅｂデザイナーやプログラマーなど多様な人が携わる、グラフィックデザインが重視されるなどの点が特徴的なＷｅｂ開発。そのＷｅｂ開発にＸＰを適用しようとした本です。Ｗｅｂプロジェクト特有の失敗の原因やリスクを解決するために、ＸＰ的な進め方、ＸＰのプラクティス、チームの構成をどう適用していくか？が主に説明されています。開発の進め方に従って、説明されていて、分かりやすいです。
ＸＰの考え方も、説明されているので、（応用編とはいえ）ＸＰについて、聞いたことがある、レベルでも、理解できました。
ただ、ＸＰに詳しければ、自分で考えても、思つくような内容なのかもしれません。（lemonerika / 2004-02-28）

XPはあたりまえのことを極端に表現しているだけかもしれません。
つまり、eXtreme Presentation。
そんなことはどっちでもよく、自分達のやっていることが本に書かれているので共感できる。
ソフトウェア工学という名目の本に、抽象論ばかり書いてあったり、特定の場合しか成立しないようなウォータフォールモデルの例が書いてあっても嬉しくない。
自分が実際にやっていることと同じことが１０分の１でも書かれていれば、安心して読めます。
ps.
ＸＰ関連のイベントで、ペアプログラミングについて、スピナッチパワーの土屋さんから、刑事が２人で捜査するようなものだと教えていただきました。これまで、ペアプログラミングに関する誤解が一気に解消しました。ありがとうございました。 （kaizen / 2008-05-12）

エクストリームプログラミング(XP)を実践するための価値観・プラクティスが説明されている本。
だというのを4分の1程読んだあと,ネットで検索することによって理解した。
XPに関する知識が全くない状態からこの本を読むと,何の話をしているのか,どの方向に話が向かっているのかさっぱり分からなかった。
「XPとは何なのか？」という疑問を解決したくこの本にあたったが,正直この本だけで解答を得るのは不可能であろう。読了した今でも十分に理解しきれなかった箇所が何点かある。
ある程度基礎知識もしくはXPに近い開発形態を経験した方にのみこの本を真に理解することができるのかもしれない。
しかし「入門」とタイトルにある以上,まったくの予備知識がない者にも理解できるような構成にしていただきたかった。（tigerbird / 2009-05-31）

これ1冊ではXPの全容は理解できないが、XPの概要を大掴みにする、という目的は十分に果たしている。シリーズ本の第1巻なのだから、位置付け的には正しいはずだ。詳細を必要とする人は、適宜本シリーズの他の本を読めば良い。XPを始めるための第一歩として良書と思う。&#60;br /&#62;&#60;br /&#62;但し、翻訳の質があまりにひどいと感じた。第1版でも翻訳の質の悪さを指摘するレビューが多く見られたので、第2版では改善が見られるかと期待したが期待外れだったようだ。XPを使うか否かに関わらず基礎知識として多くの人に読んでもらいたい内容であるだけに、訳の悪さは非常に残念。（Yazin / 2006-06-04）

アメリカの貧弱なソフトウェア開発体制の暴露本。何故アメリカのソフトウェアの品質が悪いかよくわかる。日本のソフトウェア技術者は読む必要が全く無い。トヨタ生産方式を引き合いに出しているが、2,000年の歴史と文化を背景にして確立された日本人の人間性を基にして生まれた生産方式をアメリカ人には理解出来るとは思えない。（アメリカで仕事をしているので原版で読んだ。）
（Shin / 2009-05-04）

とにかく翻訳（日本語）のひどさに苦労させられました．もしかしたら元の英文を読んだ方が正確に理解できたかもしれないし，フラストレーションも少なかったかもしれない．社内の勉強会の準備のために訳書を読んだが，この翻訳の質なら原文をじっくり読んだ方が得られるものが多いと思う．せっかく原文がしっかりした内容なので，翻訳者にはもっと英語の分かっている人を選ぶべきではないでしょうか（技術的知識は当然のこととして）．（ / ）

TDDの手順が、プログラマの思考過程を含めてシナリオチックに、じつに事細かに書かれており、これだけでも本書の価値はある。アジャイルのような従来のプロセスからはかなり異質なものに初めて取り組む時、誰かの思考過程をそのままなぞることができれば、その第一歩としてはこれ以上のものはないだろう。あとは応用するだけだ。
ただし、言語も複数登場するし、特定のツールの使い方が説明されているわけではないので、ハウツー的な要素は薄い。実際に適用するときは、利用するxUnitの解説や、特有ツールの運用を含めた別のドキュメントが必要になるかもしれない。
それにしても、XP関連書籍の例に漏れず、翻訳の質がひどい。日本語のレベルでどうにかしてもらいたい箇所が無数にある。（ただただし / 2004-08-14）

非常にまわりくどい表現が多い。Kent Beckの性質だろうか。
例でもってテスト駆動開発を実演する部分の「くどさ」と「屈折」は置いておくとしても、パターンの部はで明快にはっきりといいたいことを表現してほしかった。
パターンの部は、デザインパターン・リファクタリングの基本的な知識があることを前提として書かかれているようである。
また、パターンの部は、デザインパターンの書式に準拠していない。
ある程度の設計・実装する力があると何か得るものがある書物と思う。
Kent Beckの表現に問題があるとしても、翻訳の質はひどい。（ / ）

ケントベックの文章は、回りくどい表現を多用するといった特徴から翻訳しにくいというのは自分も実感しているが、それを考慮しても本書の翻訳はひどい。
文法の整合性が取れていない箇所や、文と文のつながりを完全に無視して翻訳している箇所など、日本語としておかしい所がかなり目立つ。
翻訳者の長瀬嘉秀氏は、XPやagileの形を定義づける貴重な名著群の価値を、片っ端から劣悪な翻訳で貶めていることを自覚してほしい。（hirokawa / 2009-07-11）

本書は「こうすれば良い」といった啓蒙ではなく、具体例を挙げ「この場合はこうした」といった事が書かれているため、直ぐに読めてかつ身に付く実践の書。
例えば「完全に合理的な設計が結局は誤りだった」といった言葉で表されるように、TDDの効き目を実感できる。
従来の考え方をがらりと変えざるを得ない良書である。
ベテランも初心者(には少々難しいか...)もぜひ読んで実践しよう。
オススメ。（Tokyo Disney ... 関係ではありません / 2003-09-05）

トヨタの新車開発期間はライバルメーカーの2,3年に対して世界で最短の12ヶ月だそうだ。この桁違いのパフォーマンスの源泉となっている「トヨタ生産システム」の原則や思考ツールをソフトウエア開発に適用しようというのが本書の主題だ。しかも、単なるこじつけには陥らずに実践的な内容に昇華させることに成功している。
ソフトウエア開発とは決して量産品の製造などではなく、むしろ新製品の研究開発に近いというのがアジャイル派の主張のひとつだ。この主張に心底「うんうん」と頷けるソフトウエア開発エンジニアやマネジャーにとって本書の内容はまさに「我が意を得たり！」と納得できることだろう。
なお、ここに述べられた7つの原則や22の思考ツールをソフトウエア開発の現場に定着させ使いこなすには、組織のカルチャーを変えていく必要もあると思う。これについては本家本元の大野耐一さんの「トヨタ生産方式」や最近出版された「ザ・トヨタウェイ」などのテキストが参考になる。（河野 / 2004-08-21）

リーンのプラクティスは悪くないのだが、著者としての技量がいまいちなのか書籍として説得力に欠けるように思う。トヨタ生産方式をアジャイル開発に応用するという「ひらめき」が最初にあり、それが正しいものであることをいろいろな文献の「断片」を持ち出して正当化することに終始している。そのことは脚注の多さが物語っている。だが、読者にしてみれば「活字で世に出ていることがすべて正しい」とは思っていないので、単に誰々さんがこー書いているから正しいんだと何度も書かれても、疑問が晴れない。プロジェクトのレシピであるプロセスはいらないと書きながら、バリューストリームマップというリーン用語でプロセスが示されていたり、ケン・シュエイバーの「アジャイルソフトウェア開発スクラム」と比べて理解に苦しむところが多い。またSEIのCMMIとPMIのPMBOKがよほど嫌いなのか、書籍の序盤、中盤、終盤と３回も批判的なことを書いているのだが、はっきり言ってPMBOKを一度も読んだことがなさそうである。PMBOKは最初にすべての計画をしろとは書かれていないし、反復型にも適用できるプロジェクトライフサイクルモデルの例がPMBOKの冒頭にちゃんと示されているのだが、そのことを知らないようである。この本よりも引用されている大野 耐一「トヨタ生産方式」、ピーター・Ｍ・センゲ「最強組織の法則」「学習する組織 ５つの能力」をオススメします。（neu-neu / 2005-01-23）

アジャイル開発に関する豊富な実例、それもソフトウェアとは違う分かりやすい例が、多く書かれている。
そのため、アジャイルの概念が容易に理解できる。
また、具体的な例が多いため、退屈せず、非常に興味深く、読み進めることができる。
最近良く聞くアジャイルとは、どういうものか、どうすればよいかを知りたい人にお勧めの本。（Hat / 2004-08-06）

「イントロダクション」によりますと、ソフトウエア開発のリーダーが、アジャイルプラクティスを、自分で作り出すためのヒントやツールの紹介だそうです。
ですので、ＸＰ等のアジャイル開発の方法論が説明してある本ではありません。リーン生産方式や、過去のプロジェクトから、迅速な開発を進めるための考え方、進め方についての一般的なプラクティスの紹介、それを、自分のプロジェクトに適応するために、具体的に、どのようなツールで、何をやってみればよいか、の紹介です。
ボトルネックや問題点の発見の方法、改善方法をどのように考えていくか、素早いチームを作っていくには？などです。
ソフトウエア開発の改善に「何から手をつけよう？？」と思っている方には、参考になるのでは、ないでしょうか。
入門書で、「アジャイル開発って何？」というのを、知っておいてから読む方が、良い気がしました。（lemonerika / 2005-02-18）

リーン（無駄の無い）ソフトウェア開発というタイトルから推測して、ＣＭＭやＰＭＩなどに代表されるソフトウェア改善プロセスを想像される方も多いと思われる。しかし著者はこのようなプロセス改善の動きを「開発」と「製造」を混同した誤った認識の上に成り立つ開発手法であると述べ、それらの手法に批判的な立場から、現場の創造性を尊重するリーン開発手法を紹介している。
著者が述べている「無駄の無い」開発とは、権限の多くを管理者から現場にシフトし、変化に対してより柔軟で機動力のある開発方法を意味する。決してストップウォッチを片手に作業者の後ろで四六時中監視するような管理者を賞賛するものではない。
トヨタのカンバン方式からゼロックス、３Ｍに至るまで、さまざまな業界での取り組みをリーン型開発の具体例として取り上げており、ソフトウェア業界を問わず業務プロセスの改善に取り組まれている幅広い分野の方々にも興味を持って読んでもらえる一冊ではないだろうか。（ / 2005-01-18）

アジャイルも規律を重んじる計画駆動型も実際の開発プロジェクトでは必要となるので、それをどのように適用していくかがポイントであると考えます。特に、ビジネスとしてのシステム開発では、開発するシステムの特性を分析して、できるかぎりリスクを排除しながら、安全にやり遂げていくことが、顧客にとっても開発者にとっても重要と思います。
この本では、そのような現実にさらされた開発者にとって、開発を進めていくための指針になることが具体的な指標として示されており、非常に有益な本だと思います。開発方法論の論争に食傷気味で現実的な解を求めていた私にとっては重要な本の一つになりました。（ / 2004-09-14）

あたりまえのことだけど，アジャイルプロセスは，どんな企業にも，どんなプロジェクトにも，どんな顧客にも向いているわけじゃない．ベームはそこを，５つの軸で評価して，そのリスク分析に応じて，計画型とアジャイル型をバランスしよう，と言っている．当然のことなんだけど，このバランスという視点はいつでも大切なんだ，と再認識させてくれるし，５つの軸の具体性に説得させられる！（平鍋 / 2004-08-13）

　本書の内容は悪くないと思います。しかし、色々なプロセスや手法を解説しているものの、著者達自身が実際にどこまで理解できているかがはなはだ疑問の解説があることが残念。特にCMMの部分はかなり間違った解釈（要件が安定していないと適用は難しいとか重量で融通が利かない風な解説）が多い上に、実際にあまり著者自身が実戦経験がないとハッキリ分かってしまう部分がある。著者の一人はビッグネームであり、もう一人はCMMIの策定メンバーとあるが、名前や肩書きを鵜呑みにするのは危険であるという証明になるかもしれない。
　これからプロセスや手法及びプロジェクト管理を学ぼうと思う人は、あくまで１つの本として参考にすることが必要だ。（さすらいのスナフキン / 2004-10-15）

まず、システム開発の方法論についての整理から始まります。ウォーターフォール型開発の批判、反復型、進化型の開発方法論の説明、いろいろなアジャイル開発の方法に共通する、考え方や特徴説明です。
そのあと～ここがメインか～、Evo、XP、スクラム、UPの４つについて、概要、そのプラクティス、成果物、進め方（手順）、適用するプロジェクトの性質、よくある間違った適応方法、Q&Aがあります。
最後に、プラクティスを実施する際のヒント～イテレーションの期間は何を考慮して、決定すべきか等～があります。
事例は、あまり、ありません。
アジャイルの本って、どこか「モヤモヤ」としたところが多いですが、この本は、明解です。
内容的には、概要レベルであると思います。しかし、うまくサマリーされているためか、分かりやすかったです。論点も明確です。
章や節の長さも、特に節の長さが適切（？）なためか、前読んだ所を参照するのが、非常に楽でした。参考文献、そして参考文献の案内も大変丁寧です。題名どおり、特に「アジャイル」関係の前提知識はなくても、OKです。（lemonerika / 2004-11-04）

ウォーターフォールで開発している企業は多いと思います。
そこで働くプログラマは、何らかの不満を感じているはずです。
プログラマは勿論、要求者、経営者、全てがハッピーになれる。
それがアジャイル開発です。
ウォーターフォールからアジャイルへの転身は大変なことだと思いますが、
きっと、この本が助けてくれます。
また、アジャイル開発を導入している場合も、
さらにハッピーな方法がこの本の中で見つかるかもしれません。（なか / 2007-09-19）

ウォーターフォール型開発の問題点や当初から問題があるにも関わらず適用された来た経緯など、
ウォーターフォールに関する分析は秀逸で説得力があります。
重量級のプロセスであるUPが取り上げられている通り、アジャイルというよりもウォーターフォールに
代わるインクリメンタルな反復型開発について取り上げられています。
本書により、読者は初めての本当のソフトウェア開発に取り組む準備が出来るでしょう。
（mktarkn / 2007-02-24）

アジャイル開発のことを知りたく、はじめに手にしたのがこの本です。
どのような形であれ開発マネジメントに参画し、
苦慮した事のある方にとっては、理解できる内容だと思います。
この本だけでは、実践レベルのスキルを習得することはできませんが、
自分のビジネス環境にあったセオリーを模索する基盤を得られました。
著者の考えにより租借された本ではなく、
論文や研究報告を元に情報がまとまっているこの本から入ってよかったと感じています。（ジョニー / 2009-07-11）

「最高のプレイヤーがいるチームが最高のチームだ」
「スキル不足をプロセスで穴埋めする事はできない」
「バスに乗っている一部の不適格者のために官僚的なプロセスを適用すると、適格者がバスから降りてしまう」
「問題に慌てて対応してしまうと、後で技術的な負債が増大していく」
プロジェクトマネジメントオフィスからではない、現場からのリアリズムあふれる直言。
近道なんてない。ただ当たり前の事を当たり前に地道にやっていこうという本。アジャイルとはかかれているが、アジャイルには限らないプロジェクト管理の基本。
あなたが抱えている問題に、あなたに代わって答えを出してくれるHow to本ではないが、あなたが自分で考える手助けをしてくれる筈。（0xdeadbeef / 2005-10-23）

自らが参画するプロジェクト、その成功は？
対場によって目指すゴールにギャップを感じ、プロジェクトマネジメントの難しさに直面された方も多いことと思います。
この本で語られる「アジャイルプロジェクトマネジメント(Agile Project Management)」とは、競争力のある製品により「変化を作り出す」こと
チームで「変化に対応する」ことこの両者が一体となり、「変化を味方につける」新しいマネジメントの考え方である
　と示されています。
実際に読まれて「なんだ。自分の判断は正しかった。」と感じる方も多いのではないでしょうか？
実は（生意気かもしれませんが）私も「やはり、間違っていなかった！」と感じた一人です。
もちろん、新たに学ぶことも多く、よい意味で考えさせられました。
ここで解説されるアプローチは、日本の現場にとても親和性のあるアプローチです。
チーム作りのポイント「や「毎日のミーティングでリズムを作る」効き目のある「意思決定の枠組み作り」など、
今すぐにでも実践できそうな考え方や行動のポイントがわかりやすく書かれています。
また、事例も多く盛り込まれています。
加えて、付録の「アジャイルプロジェクトマネジメント(APM)の体系」に本書籍内の関連ページが記載されて使いやすさを増しています。
プロジェクトのゴールに発注者、ユーザーの笑顔が見える。
チームのメンバーがプロジェクトを通して成長できる。
そんなゴールを目指す方々（ソフトウェアの開発者や、様々な業種のプロジェクトマネジャー）にお薦めの一冊です。
（ / 2005-08-23）

詳しく書かれているのでしょうが、内容からすると少し文章が長く辛かったです。
プロジェクトマネジャーの立場としてアジャイルを解説しているので、
顧客とのやり取りに重点をおいています。
特に参考になったのが、意志決定で「Win-Win」を重視するために、
激しい議論の中にも、お互いに信頼し合い、尊敬し合ったうえでの、
礼儀ある議論という言葉でした。
熱くなると、自分さえWinになればと考えてしまいますが、冷静になれる言葉でした。
（なか / 2008-09-17）

本書は、要求の導き出しから仕様化、要求の変更管理までを網羅している。
システム開発において、的確な要求を導き出すという永遠のテーマについて書かれた良書。
ＨｏｗＴｏ本と読み物としての二つの側面をもつ。
要求導き出しのテクニックなど、具体例をあげ解かり易く書かれているので、これから上流工程へ携わるビギナーの方にもお奨めできる。
また、訳本ではあるが、文章は平易で読みやすいのが大変良かった。（日本語訳、監修の方のご苦労が伺える仕上がりになっている）
本書では、要求の導き出しから仕様化の間に「要求のトリアージ」を行うことを推奨している。システム開発において、予算と納期、要求のバランスをとることは大変重要である。
この時点でボタンの掛け違いをすると、大抵の場合、納期遅延や予算超過などプロジェクトの失敗を招くことになる。
本書の第３章で取上げられている「要求のトリアージ」では、要求を選び出すための技術について触れられており、参考になった。（ＫＩＴＴＹ / 2007-01-08）