よく一緒に購入されている商品
商品の説明
内容紹介
本書では、ディーン・レフィングウェルの顕著な功績を見ることができる。アジャイル関連には多数のプロセスがあるが(XP、スクラム、リーン、DSDM、FDD、統一プロセス、など)、それらのプロセスに関する議論を超えて、ディーンはまず何がそれらのプロセスに共通であるかをまとめた。そして、その後、この本の主目的である、いかにしてアジャイル開発をスケールアップするかを述べている。彼は、すでにたくさんあるアジャイルプロセスに新しいプロセスを加えることはせずに、むしろ、既存の確立されたアジャイルプラクティス(中には奇妙な名前を持ったものがあるが)を取り込み、統合していく。そして、一段上のレベルで、技術視点、マネージメント視点の両面から、新しいプラクティスのセットを加えることで既存のプロセスを拡張しようとしている。無数のメソッドに共通に存在するベストなエンジニアリングプラクティスを統合し拡張するだけでなく、大規模なアジャイルプロジェクトにおけるガバナンスを実現する方法を説明しているのだ。(本書の序文より)
著者について
・著者紹介
Dean Leffingwell(ディーン・レフィングウェル)
米国で非常に著名なコンサルタントであり、RequisiteProという要求管理ツールを作った会社を立ち上げたことでも有名です。元はRational(IBMに買収された)のVice Presidentであり、現在は違う会社を立ち上げました。
最近の5年ほどは、コンサルタントとして、多数の企業で活躍し、その経験をもとにこの本を書き上げています。
・監訳者紹介
玉川 憲(たまがわ けん)
IBMソフトウェアエバンジェリスト、IBM Rational 事業部テクニカルセールス部長。2000年にIBM Research Tokyo(当時、東京基礎研究所)に入所。超小型腕時計型Linux コンピュータWatchPad の研究開発に従事。2003年よりIBM Rational 事業部に所属。RUP ・要求管理・オブジェクト指向分析設計のコンサルティングなどを行う。2006年より米国在住。アジャイル方法論を用いたソフトウェア開発に従事。2009年から現職。2 歳の息子との建設機械見物が趣味。東京大学工学修士。カーネギーメロン大学経営学修士(MBA)。同ソフトウェア工学修士(MSE)。RUP認定講師。オブジェクト指向分析設計認定講師。ユースケース要求管理認定講師。認定スクラムマスター。
Dean Leffingwell(ディーン・レフィングウェル)
米国で非常に著名なコンサルタントであり、RequisiteProという要求管理ツールを作った会社を立ち上げたことでも有名です。元はRational(IBMに買収された)のVice Presidentであり、現在は違う会社を立ち上げました。
最近の5年ほどは、コンサルタントとして、多数の企業で活躍し、その経験をもとにこの本を書き上げています。
・監訳者紹介
玉川 憲(たまがわ けん)
IBMソフトウェアエバンジェリスト、IBM Rational 事業部テクニカルセールス部長。2000年にIBM Research Tokyo(当時、東京基礎研究所)に入所。超小型腕時計型Linux コンピュータWatchPad の研究開発に従事。2003年よりIBM Rational 事業部に所属。RUP ・要求管理・オブジェクト指向分析設計のコンサルティングなどを行う。2006年より米国在住。アジャイル方法論を用いたソフトウェア開発に従事。2009年から現職。2 歳の息子との建設機械見物が趣味。東京大学工学修士。カーネギーメロン大学経営学修士(MBA)。同ソフトウェア工学修士(MSE)。RUP認定講師。オブジェクト指向分析設計認定講師。ユースケース要求管理認定講師。認定スクラムマスター。
登録情報
|
この商品を見た後に買っているのは？
カスタマーレビュー
最も参考になったカスタマーレビュー
10 人中、10人の方が、｢このレビューが参考になった｣と投票しています。
形式:大型本
昨年のマイクコーンの本（アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~）といい、この本といい、最近のアジャイル開発の様変わりの様子が、やっと日本語で読めるようになってきた。アジャイル食わず嫌いの人にこそ、読んで欲しい本。
開発組織のリーダークラスの人にもおすすめ。アジャイルの本質から解きほぐしてくれるので、なぜアジャイルかという点で得心が行くし、具体的な規模拡大のアプローチが示されているので、アジャイルに安心して取り組める気になる。
ただ、内容的に今までのアジャイル開発とはかなり異質なので、普通のアジャイル本も併読した方がいいかも。そうすると逆にこの本の価値がわかるかもしれない。
開発組織のリーダークラスの人にもおすすめ。アジャイルの本質から解きほぐしてくれるので、なぜアジャイルかという点で得心が行くし、具体的な規模拡大のアプローチが示されているので、アジャイルに安心して取り組める気になる。
ただ、内容的に今までのアジャイル開発とはかなり異質なので、普通のアジャイル本も併読した方がいいかも。そうすると逆にこの本の価値がわかるかもしれない。
7 人中、7人の方が、｢このレビューが参考になった｣と投票しています。
形式:大型本
大変面白く、一気に読んでしまいました。
XP、スクラム、RUP、それぞれ名前は聞いたことがあったのですが、良く理解していませんでした。この本を読んで、これらのメソッドに共通な本質は何か、が良くわかりました。また、それがどうやら大規模なエンタープライズシステムにも適用できそうなのだ、ということがわかってきました。
QCDという言葉があります。品質(Q)、コスト(C)、納期(D)を守らなければならない、という意味です。ものづくりにおいては、特に重要でしょう。しかしながら、QCDを計画するためには、生産活動が事前に予測可能であることが必要です。ソフトウェアの開発は本質的に、今までに無い新しいものを創り上げる活動であり、また顧客の要件も時間とともに変化していきます。ですので、ソフトウェア開発においては、QCDを事前に決めることはできない、という前提からアジャイルの考え方が始まっています。
一定のQCDを事前に決めることができないとなれば、Q、C、Dのいずれか（あるいは複数）にしわ寄せがよってきます。ソフトウェア開発ではどれも起きることです。納期が延びて、そのためにたくさんの人を投入して（コストオーバーラン）、なおかつ品質が保てない、などという話を良く聞きます。
アジャイル開発では、与えられたコストの範囲で納期は絶対守る、その代わり仕様には妥協する、というのが今までのウォーターフォール開発とは大きく異なるコンセプトです。コードの品質には妥協しないのですが、顧客要件については優先順位をつけて、実装できるものだけを期限までに実装する、という考え方です。同時に、常に変化する顧客要件に対応するため、非常に短い反復で動くソフトウェアを作り、顧客に見せてフィードバックをもらいます。
このアジャイルの考え方は、ソフトウェア開発だけでなく、企業における知的活動の様々な局面において応用できるように思います。たとえば、3か月で何かの報告書を作るタスクの場合、完成度は低くても全体像がわかるドラフトを毎週提出してフィードバックをもらう、などのやり方です。
また、チームの構成、コミュニケーションのやり方などは、一般のマネジメントにすぐにでも応用が効きそうです。ソフト開発も組織のマネジメントも結局は人、メンバーのエンパワメントが大事なのだ、と改めて認識させられる本でした。
XP、スクラム、RUP、それぞれ名前は聞いたことがあったのですが、良く理解していませんでした。この本を読んで、これらのメソッドに共通な本質は何か、が良くわかりました。また、それがどうやら大規模なエンタープライズシステムにも適用できそうなのだ、ということがわかってきました。
QCDという言葉があります。品質(Q)、コスト(C)、納期(D)を守らなければならない、という意味です。ものづくりにおいては、特に重要でしょう。しかしながら、QCDを計画するためには、生産活動が事前に予測可能であることが必要です。ソフトウェアの開発は本質的に、今までに無い新しいものを創り上げる活動であり、また顧客の要件も時間とともに変化していきます。ですので、ソフトウェア開発においては、QCDを事前に決めることはできない、という前提からアジャイルの考え方が始まっています。
一定のQCDを事前に決めることができないとなれば、Q、C、Dのいずれか（あるいは複数）にしわ寄せがよってきます。ソフトウェア開発ではどれも起きることです。納期が延びて、そのためにたくさんの人を投入して（コストオーバーラン）、なおかつ品質が保てない、などという話を良く聞きます。
アジャイル開発では、与えられたコストの範囲で納期は絶対守る、その代わり仕様には妥協する、というのが今までのウォーターフォール開発とは大きく異なるコンセプトです。コードの品質には妥協しないのですが、顧客要件については優先順位をつけて、実装できるものだけを期限までに実装する、という考え方です。同時に、常に変化する顧客要件に対応するため、非常に短い反復で動くソフトウェアを作り、顧客に見せてフィードバックをもらいます。
このアジャイルの考え方は、ソフトウェア開発だけでなく、企業における知的活動の様々な局面において応用できるように思います。たとえば、3か月で何かの報告書を作るタスクの場合、完成度は低くても全体像がわかるドラフトを毎週提出してフィードバックをもらう、などのやり方です。
また、チームの構成、コミュニケーションのやり方などは、一般のマネジメントにすぐにでも応用が効きそうです。ソフト開発も組織のマネジメントも結局は人、メンバーのエンパワメントが大事なのだ、と改めて認識させられる本でした。
7 人中、7人の方が、｢このレビューが参考になった｣と投票しています。
形式:大型本
マイクロソフト Tech Fielders - Agile Day 2でこの本を知り、早速購入した。まだとばし読みであるが、新しい時代の到来を感じる。
自分はコンサルであるが、反復型と呼ばれる開発プロセスを、ユーザー企業の立場で推進し、反復型によるユーザー側のメリットも確認してきた。そのため、アジャイル開発が大規模システムで適用できるという考え方には全く違和感はない。しかし、XPやスクラムなど、具体的なプロセスのプラクティスには関わってこなかったため、それをアジャイル開発の経験と言って良いのかわからなかった。この本は、個々のプロセスの用語にとらわれることなく、アジャイルの本質的なメリットを理解してそれを引き出すことが大切と説く。この世界にアジャイルという統一的な言葉がうまれそうだ。ありがたいと思う。
アジャイル開発を大規模システムに適用することについては、アーキテクチャーの問題が気になっていた。システムの基本的な構造や仕組みを「後付け」で考えるプロセスでは、大規模開発において相当の不効率を生むことになると考えたからだ。
この点については、アジャイルプロセスそれぞれのスタンスがあるが、大規模システムへの適用については、アーキテクチャーが現れることを待つのではなく、意図的に作り出すことが必要だと書かれている。また、そのアーキテクチャーを作り出すチームや期間も必要であり、それをアーキテクチャー助走路と呼ぶということも書かれている。
アーキテクチャー助走路という概念が打ち出されていることで、今後の大規模におけるアーキテクチャーの事前検討の必要性とメリット、またそこに一定のコストが発生することを説明しやすくなった。これも、ありがたい。
目次にさっと目を通したところでは、この本は他にもじっくり読みたいところが満載で、しばらく楽しめそうだ。
自分はコンサルであるが、反復型と呼ばれる開発プロセスを、ユーザー企業の立場で推進し、反復型によるユーザー側のメリットも確認してきた。そのため、アジャイル開発が大規模システムで適用できるという考え方には全く違和感はない。しかし、XPやスクラムなど、具体的なプロセスのプラクティスには関わってこなかったため、それをアジャイル開発の経験と言って良いのかわからなかった。この本は、個々のプロセスの用語にとらわれることなく、アジャイルの本質的なメリットを理解してそれを引き出すことが大切と説く。この世界にアジャイルという統一的な言葉がうまれそうだ。ありがたいと思う。
アジャイル開発を大規模システムに適用することについては、アーキテクチャーの問題が気になっていた。システムの基本的な構造や仕組みを「後付け」で考えるプロセスでは、大規模開発において相当の不効率を生むことになると考えたからだ。
この点については、アジャイルプロセスそれぞれのスタンスがあるが、大規模システムへの適用については、アーキテクチャーが現れることを待つのではなく、意図的に作り出すことが必要だと書かれている。また、そのアーキテクチャーを作り出すチームや期間も必要であり、それをアーキテクチャー助走路と呼ぶということも書かれている。
アーキテクチャー助走路という概念が打ち出されていることで、今後の大規模におけるアーキテクチャーの事前検討の必要性とメリット、またそこに一定のコストが発生することを説明しやすくなった。これも、ありがたい。
目次にさっと目を通したところでは、この本は他にもじっくり読みたいところが満載で、しばらく楽しめそうだ。
リストマニア
|
|
同じキーワードの商品を探す
フィードバック
- カタログ情報、または画像について報告
- 著者からのコメント
- 出版社からのコメント
|
