○Process -プロセス-
(No book on ...)
ソフトウェア開発において、筆者のお気に入りの開発の方法論のプレゼンテーションなしに完成出来る本はなく、それは異なっていない。
（So we humbly ...）
なので、私たちは謙遜して、トレーサーバレットディベロップメントと私たちが呼んでいるもののためにプラグを追加する。
（When you use ...）
トレーサーバレットディベロップメントを使う時、あなたは、始めから終わりまで働くシステムを作り、それは大抵もみ消される。そしてその時、それを現実のものにするための失われた部分を埋めるのである。
（It's good for ...）
それは、大きなプロジェクトの部署の分割と、チームに部分的な仕事を並行的にさせることには良い。そしてそれはまた、自動化されたテストを自身が適切に援助する。
○Common Problems and How to Fix Team -一般的な問題と、チームの決め方-
（Finally, we present ...）
最後に、私たちは、道具や、技術や、そして本書の残りで記述しているプロセスを用いてどのように解決するかのアドバイスを提供し、発生しうる一般的な問題（そして、危険な信号）を述べる。
（A lot of ...）
私たちが自身で遭遇したこれらの問題の多くは、年間に渡っている。
（Some we solved ...）
いくつかは解決され、その他はどのようにこの事実（結局、20/20が後知恵である、）の後、どのように解決するかを理解した。
（We hope our ...）
我々の経験が、あなたを、私たちが昔犯したものと同じ間違いから救ってくれるであろうと願っています。
○What's Missing? -何を失ったか？-
（People and requirements ...）
人々と要求を集めることは、私たちが含んでいない二つの領域である。
（Good people trump ...）
優れた人々は、道具や、技術や、そして最も重要なプロジェクトの一部分としてのプロセスといった切り札を出す。すなわち、しかしながら、巨大なチームを招集したり維持することは、自身の本の主な価値である。
（Instead, we focus ...）
その代わり、私たちはあなたのチームが既に持っている技術に影響を与え、成長させるための方法に焦点を当てる。
（Similarly, leaning about ...）
同じように、製品の要求について学習することは、もうひとつの深い主題である。
（There are many ...）
ノートカードから、チェックがいっぱいでバランスのとれた複雑なシステムに及ぶ要求を収集するためのたくさんの方法がある。
（Rather than attempt ...）
私たちがひとつのチャプターにおいて公平化することが出来ないもう一つの大きな発行物を提出することを試みるというよりは、例えあなたがどこから要求を得ているとしても、私たちは、要求の変更を操作するには十分なほど適応性があるアイディアを提供する。
（The ideas in ...）
本書のこのアイディアは、要求が断続的に変わるプロジェクトと同じように、要求が変わらないプロジェクトを適応させることが出来る。
（So you can ...）
なので、３×５のカードの小さなスタックや、１００００ページの小さな契約書から、あなたの要求のリストを得ることが出来ようとも、あなたはこれらのアイディアを使うことが出来る。
（We've tried to ...）
私たちは、どの店舗でも、そしてどの技術でも、あなたがそれらを使うには十分なほど一般的なディスカッションを続けることを試みてきた。
（That's why we ...）
それが、技術のインストーラーや、道具を最適化するコードにおけるセクションを追加することが出来ない理由である。
1.4 Moving On -前進-
私たちの願望は、あなたがこのアイディアと習慣を使ってくれることを願っています。これを読んで、そして試してみたください。あなたの環境でこの仕事をやり続け、そして残りは捨ててください。
あなたがこのアイディアを使っても使わなくても、決心するためのそれぞれのセクションの後は停止してください。もしあなたがそれを使わないなら、「How Do I Get Started?」を読んでください。もしあなたがそれを使うなら、あなたが正しい進路にいることを確かにするために、「Am I Doing This Right?」あるいは、「Warning Signs」を読んでください。
1.5 How Should I Read This Book?
あなたがどのようにこの本を応用するかは、プロジェクト内の役割に依存する。不自然に、あなたが開発者や試験官として働いている時、この本は、あなたのチームが導くよりも異なった方法を取る。しかし、あなたはそのどちらの役割において働く時も、この本からたくさんの価値を得ることが出来る。
- You Are a Developer or Tester
もしあなたが前線の実践者、あるいは実装者ならば、この本を前から後ろまでよんでください。それぞれのセクションは、個人の提供者やチームリーダーとしてあなたが日々を使うことの出来る実践的な内容を含んでいる。しばしば開発者は、もし彼らがチームのリーダーでなければ、チームへの焦点によるセクションをスキップしてしまう。これは本当に悪い考えである。ほとんどのチームの環境は、リクエストされた、あるいは直接経験をしたことのあるメンバーの集合である。何のツールや、技術や、そしてプロセスが、あなたの店舗における積極的な衝撃を作り、そしてあなたが作るそれぞれの要求のための実質的な理由を提供することが出来る立場をあなた自身に確立しなさい。私たちが開発者に聞いてきたたくさんの時間は、与えられた道具や技術のための議論をした。なぜなら、それが『正しい方法』だからである。この議論は、管理者を統治することはなく、そして事実、逆効果である。あなたがアイディアを提供する前に、チームに与える利益を理解していることを確かにしなさい。
どの要求があなたを統治するでしょうか？ 「私たちは全盛期のコードシステムからのマネジメントシステムのソースコードを必要としている。なぜなら、それは良いもので、全ての人がそれを使っているからである。これがベストな実践なんだ！」あるいは、「私たちはマネジメントのシステムのコードを持っているべきだ。なぜなら、それは私たちを過去の製品に利用させてくれて、特殊なコードの変更に引き下げ、そして、私たちの製品が平行なコード木で安全に働くことを可能にする。それは、私たちの会社の製品への投資を安全なものにするための最も簡単な方法である。全盛期のコードシステムは、私たちが注目すべき偉大な製品を造った。ジョーと私は、それを数カ月の間使い続け、そして生産性における現実での違和感を造った。それがどのように私たちを助けてくれたのかのリストならここにある」
- You Are a Project Team Lead
この本を、あなたのチームの環境と仕事の流れの監査を紹介するために使ってください。（あなたは既にこの方法を使っているかもしれませんね？）あなたのチームがどのように仕事をするのかを再度試験するための機会を得てください。あなたは、汎用性のある要求をカバーしている道具の標準的なセットを持っていますか？ あなたのチームの技術は、実質的な製品と開発者を構築していますか？ あなたは、綺麗で、よく定義されたプロセスを持っていますか？
あなたが、どのようにあなたのチームが動いているかを再考する時、それぞれの道具の関係性を考えることを確かにしてください。あなたは、一度に適応する、しかしもはや効果的ではない道具や実践を使えるだろうか？
あなたは、いつも最初にハムの３分の１を切り落として処分することで調理する女性の物語を聞いたことがあるだろうか？ どうしてかを聞くと、彼女は、彼女の母がいつもハムをこうして調理したと言った。それを聞いた時、彼女の母は、彼女のお母さんがいつもこうして調理したと言った。彼らは結局、祖母と向かい合い、彼女は、若い時、ハム全体を調理できるほど大きな平皿は持っておらず、そのため、彼女はいつもただハムの端を切り落とし、それが習慣になっていたと認めた。
あなたの習慣があなたの今日の要求（去年のプロジェクトや祖母の奇抜な行動ではなく）を形成していることを明らかにしてください。
また、あなたのチームが、今日必要な道具や技術やプロセスを利用していることを明らかにしてください。何が働いて、何故それがあなたがチームを効果的に導くことの出来る唯一の方法なのかを知ってください。それぞれのセクションは、あなたのセクションの開始を助ける情報と、問題の発生を警告してくれる危険信号を持っている。
- You Are a Manager(or Involved Customer)
より上位のレベルのマネジメントは、単純に正しい情報を聞くことによって、どのようにチームが動くか影響を与える大きな計画を実行することができる。この本は、あなたがチームが使うべき鍵となる要素のいくつかと、あなたが聞くべき質問の種類を示す。例えば、あなたが最後の制作における処理のリストを聞く時、あなたは追跡された情報が欲しいと言う。あなたがそれぞれのセクションを読むとき、あなたが働いてほしい目的においてそれらを導くことの出来ることを提示するためにチームを導いて下さいと頼むことの出来る提出物に注目してください。それらの要求には特に注意してください。しかし、あなたはチームのための官僚的な忙しい仕事を造りたくはない。あなたは、注意深く配置された要求を用いてチームを導きたい。
あなたが日々の仕事から除外された時、あなたはおそらく、How Do I Get Started?のセクションを拾い読みするだろう。しかし、あなたはそれぞれのトピックの内容と理由を理解したいとは思わないだろう。
この本の全ての概念が、チームのメンバーや、チーム全体や、マネージャーに使われている。チームメンバーはしばしば、最初にその実践を使い、その価値を証明する。そしてその時、チームでその価値を共有する。私たちはそれを自分自身で何回も実践し、見てきた。そしてあなたも同じことが出来る。ここに、それを行った者の物語がある。
The Rapid growth of Agillity Support Systems at CafePress.com
私たちがカフェプレスドットコムで去年の始めに働き始めた時、マネジメントはアジャイルの実践の採用に情熱を注いでいた。しかし、その開発の環境は、要求された基本的なサポートシステムが欠けていた。制作の開始とプロジェクトの買収－カフェプレスの中核の提供は、簡単に設計を行い、カスタマイズされた商品を買うことを可能にした。このプロジェクトは最初に、明確なビジネスと、ウェブのプレゼンテーションの層に加え、開発者の根強い層を紹介することを試みた。ビジネスと頑固な層のほとんどは、テストの最初にNUnitのフレームワークを使ってデザインされている。私たちは、NAntを編集と開発のためのものとして紹介している。
Subversion, CruiseControl.NET, NAntそしてNUnitの間の相互作用性は、私たちを手厚く支援してくれる。さらに、これらのサポートシステムは、開発者が始めたものであり、明確なマネジメントの要求のおかげではない。
私たちがそれらの作業をオートメーションで始める時、チームは成長していった。最新のアップグレードは、開発の環境の構築で記述された１００％が実装された。
これらのツールの出現の前に、私たちの日々のコミュニケーションのほとんどは、失敗を造り、APIの変更の通知についての放送の問題によって成り立っている。
私たちの初期の努力は、テストされたコードや私の初期の投資の直接の提供を手助けした。
私たちはこれがベストな方法だと感じた。
だから私たちは言う。「この本を使いなさい」と。あなたが、マネージャーや、開発者や、試験官や、テクニカルリーダーのどれであろうとも。そうすればあなたの人生は少し、今日より簡単なものになるでしょう。
アジャイリティとは、状況を素早く変更して、ソフトウェア開発のチームの能力に採用する手法である。一般的に、アジャイルのチームはより密接な関係にある。詳しくは以下のアドレスを参照。
下に、そのサイトに掲載されているアジャイルのポイントを記載した。
「私たちは、ソフトウェアの開発のよりよい方法を、自分と他者を互いに助け合うことによって明らかにしている。この仕事を通して、我々は以下の価値を持っている。
・個人と相互作用はプロセスとツールを超える。
・ソフトウェアの仕事は、包括的な文章を超える
・変化のための応答は、プランに従うことを超える。
これは、右に価値がある道具がある時、私たちは左の道具に価値を見出すということなのである。
」
最終更新：2011年07月01日 14:45
