Original English language title: Practices of an Agile Developer by Venkat Subramaniam and Andy Hunt Copyright 2006 Venkat Subramaniam and Andy Hunt Translation Copyright 2007 Ohmsha, Ltd. All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher. E-mail kaihatu@ohmsha.co.jp FAX 03-3293-2825
Practices of an Agile Developer Nathaniel T. Schutta, Foundations of Ajax Pragmatic Bookshelf Forrest Chang, Guerry A. Semones,, Appistry Matthew Johnson, Pragmatic Bookshelf Scott Splavec, Marty Haught,, Razorstream
iv Practices of an Agile Developer David Lázaro Saz, Matthew Bass, Bil Kleb,, NASA
Practices of an Agile Developer iii xi 1 1 2 11 1... 13 2... 16 3... 19 4... 24 3 27 5... 29 6... 32 7... 35 8... 38 9... 41 4 45 10... 47 11... 50 12... 54 13... 57 14... 61 15... 64 16... 67 17... 72 18... 76 5 79 19... 81 20... 86 21... 91 22... 94
xii 23... 97 24... 100 6 103 25... 105 26... 110 27... 115 28... 118 29... 120 30... 122 31 Tell, Don t Ask... 126 32... 129 7 133 33... 134 34... 136 35... 140 36... 143 37... 145 8 151 38... 153 39... 157 40... 160 41... 162 42... 164 43... 166 44... 169 45... 172 9 175 9.1... 175 9.2... 176 9.3... 177 9.4... 179 9.5... 180
xiii A 181 A.1 Web... 181 A.2... 185 191 195 199
1 Agile Software Development
2 1 2001 2 17 Lightweight Processes 17 6 * 1 6 Copyright 2001, the Agile Manifesto authors 6 agilemanifesto.org 6 *1 E
3 plan-based
4 1 1 2. 10
5 6 6 Wiki Wiki WikiWikiWeb Web Web Wiki Wiki The Wiki Way [LC01] Pragmatic Version Control Using CVS [TH03] Pragmatic Version Control Using Subversion [Mas05] *2 Pragmatic Unit Testing in Java [HT03] Pragmatic Unit Testing in C# [HT04] JUnit Recipes [Rai04] *3 Pragmatic Project Automation [Cla04] Ship It! [RG05] 6 6 *2 CVS Subversion :-) *3 XFD extreme Feedback Device
6 1 1 2 3 4 5 6
7 7 8 1 *4 *4 Dilbert
第1章 8 アジャイルソフトウェア開発 難題から始めなさい どんなときも 最初に最大の難問へ取り組みなさい 簡単なものは後回しで よいのです そうはいっても現場では はっきりと白黒を付けられないことも多い そこで 紹介するプラクティスを実践したときの気持ちを説明したセクションと プラク ティスを効果的に実践しつつバランスを保つためのヒントを記したセクションも用 意してある 次の 2 つがそうだ こんな気分 こんな気分 のセクションでは 紹介したプラクティスが引き起こすはずの感情 を説明する ここで説明したような気持ちにならない場合は プラクティスの実践 方法を見直すべきかもしれない バランスが肝心 s プラクティスの実践が過剰だったり不足したりすることもありえる そこでこ の バランスが肝心 のセクションでは プラクティスのバランスをとるため のヒントや プラクティスを有効活用するための全般的なヒントを紹介する 結局のところ どんなに良いプラクティスであっても やりすぎたり 使い方を 誤ったりすれば 大きな危険を招くことになる 僕らは チームがプラクティスの バランスを保てなかったがために失敗してしまったアジャイルプロジェクト と呼 ばれていた何か の事例を幾度となく目にしてきた 僕らの願いは 本書で紹介す るプラクティスが あなたの現場の成果へとつながることだ 本書で紹介するプラクティスの教えを バランスを考えて効果的に現場へ適用す れば プロジェクトにもチームにも見通しの明るい変化の兆しをもたらすことがで きるだろう そしてあなたは アジャイル開発者としてのプラクティスに従うだけにとどまら ず プラクティスの背後にある原理原則をも理解できるようになるはずだ 謝辞 どんな書籍も 大きな苦労の末に生み出されている 出版の舞台裏には 不肖筆 者たちだけでなく とてもたくさんの人がかかわっている 本書の刊行に際しては 次に示す方々にご尽力いただいた ここに感謝の意を表 したい
9 *5 Jim Moore Kim Wimpsett Johannes Brodwall Chad Fowler Stephen Jenkins Bil Kleb Wes Reisz Marcus Ahnve Eldon Alameda Sergei Anikin Matthew Bass David Bock A. Lester Buck III Brandon Campbell Forrest Chang Mike Clark John Cook Ed Gibbs Dave Goodlad Ramamurthy Gopalakrishnan Marty Haught Jack Herrington Ron Jeffries Matthew Johnson Jason Hiltz Laforge Todd Little Ted Neward James Newkirk Jared Richardson Frédérick Ros Bill Rushmore David Lázaro Saz Nate Schutta Matt Secoske Guerry Semones Brian Sletten Mike Stok Stephen Viles Leif Wickland Joe Winter Dave Thomas Andy Hunt Pragmatic Programmers Marc Garbey Ben Galbraith Brian Sletten Bruce Tate Dave Thomas David Geary Dion Almaer Eitan Suez Erik Hatcher Glenn Vanderburg Howard Lewis Ship Jason Hunter Justin Gehtland Mark Richards Neal Ford Ramnivas Laddad Scott Davis Stu Halloway Ted Neward NFJS Jay Zimmerman *5
10 1 Kavitha 2 Karthik Krupakar Venkat Venkat
2 Beginning Agility *1 35 IDE 13 *1
12 2 16 19 24
1 1 13
14 2 6 6 ISO-9001 6 6
1 15 QA Quality Assurance API *2 [You99] *2
第2章 16 アジャイルの初心 I 応急処置は泥沼を招く 2 コードのそんなところまできちんと理解しなくても大丈夫さ そのまんま でちゃんと動くみたいだぜ ちょっとだけイジればいいんだよ 計算結果に 1 をプラス それでバッチリじゃないか さあ その修正を組み込んじまお うぜ 大丈夫だって たぶん 誰でも身に覚えがあるだろう バグが出た でも時間がない 応急処置でなんと かなりそうだ 1 をプラスしたり リストの最後の要素を無視したら とりあえず ちゃんと動いた さて この次に何をするかが優秀なプログラマと無粋なハッカー との分かれ目だ 無粋なハッカーは応急処置をそのままにして さっさと次の問題に取りかかる 優れたプログラマは いち段落したらなぜ +1 が必要なのかを調査する そし て というかこれが重要なのだが この修正の影響範囲を見極めるのだ この話をたわいない作り話だと思ったかもしれないが 本当にあった話だ それ も実際にはこんな小さな事例じゃなかった かつてのアンディの顧客が同じ問題を 抱えていた 開発者もアーキテクトも誰一人として自分たちのドメインを表現する データモデルに精通しないまま 長年にわたって保守を続けていたのだ その結果 コードベースのあちこちに +1 とか 1 といった修正が数え切れないほど散らばっ ていた そんなめちゃくちゃな状況の機能追加やバグ修正は 髪を掻きむしりたく なるような悪夢だった 実際に髪が薄くなった開発者が何人もいた 破滅的な状況が得てしてそうであるように その現場だってある日突然そんな状 態になったわけではなかった 全体にかかわる根本的な問題を直視することなく何 度も何度も応急処置を重ねた結果 プロジェクトは底なしの泥沼に足を取られてし まい だんだんと生気を失っていったのだ } } アンディ曰く プロセスも理解する ここではコードを理解するということ 特にコードをきちんと理解したうえで変更す ることを中心に説明している しかし同じことはコードに限らず チームが実践する方 法論や開発プロセスにも当てはまる チームが実践している開発方法論を理解する必要がある その方法論がどのように機 能しているのか なぜそのやり方なのか どういった経緯でそのやり方が採用されたの かを理解しなくてはならない こうした理解なしに 効果的に変化は引き起こせない } }