uecklab @ ウィキ

トップページ

2011-07-09T12:16:56+09:00

**連絡事項 * -B4各位へ --上のメニューの「このwikiに参加」からメンバー登録をしてログインしておくと、ページ編集時の画像認証が回避できます。 **コメントフォーム #pcomment(title_name=名前,top_comment_wiki,reply) テスト

matsu

2011-07-07T21:53:22+09:00

2011-07-06の発表資料 matsu pass:klab http://www1.axfc.net/uploader/He/so/331113

メニュー

2011-07-07T21:46:31+09:00

**メニュー -[[トップページ]] -[[プラグイン紹介>プラグイン]] -[[まとめサイト作成支援ツール]] -輪講 --[[第4章]] --[[第5章-1]] --[[第5章-2]] --[[第5章-3]] --[[第6章]] --[[第7章]] -輪講その2 --[[割当]] --[[7/1end]] --[[7/1yas]] --[[7/1hagi]] --[[7/1haru]] --[[7/1matsu]] --[[7/1mik]] --[[7/1mishi]] -ProjectBBS --[[クライアント]] --[[サーバー]] -統計ゼミ --[[matsu]] ---- **リンク -[[@wiki>>http://atwiki.jp]] -[[@wikiご利用ガイド>>http://atwiki.jp/guide/]] // リンクを張るには "[" 2つで文字列を括ります。 // ">" の左側に文字、右側にURLを記述するとリンクになります //**更新履歴 //#recent(20) &link_editmenu(text=ここを編集)

クライアント

2011-07-05T12:07:20+09:00

クライアントの情報はここへ (2011.07.05 [[matsu]]) 一応新しいの上げておきます。かなり途中です。値の取得方法が変更されました。ごめんね? ☆値を返す・int型 public int getInt(int key) ・String型 public String getString(int key) ・Color型 public Color getColor(int key) ・Font型 public Font getFont(int key) ☆keyに使用できるint型定数は現在下記のものが用意されています必要な定数があったら用意するので、matsuまで！基本設定・接続先 final public int DESTINATION ・ポート番号 final public int PORT ・ユーザ名 final public int USERNAME あんまり使わないであろう全般設定・背景色 final public int BACKGROUND_COLOR ・文字色 final public int FOREGROUND_COLOR ・フォント final public int FONT タブの設定・タブ背景色 final public int TAB_BACKGROUND_COLOR ・タブ文字色 final public int TAB_FOREGROUND_COLOR ・タブフォント final public int TAB_FONT 下部バーの設定・下部背景色 final public int BOTTOM_BACKGROUND_COLOR ・下部文字色 final public int BOTTOM_FOREGROUND_COLOR ・下部フォント final public int BOTTOM_FONT パネルごとの設定・設定パネル背景色 final public int SETTING_BACKGROUND_COLOR ・設定パネル文字色 final public int SETTING_FOREGROUND_COLOR ・設定パネルフォント final public int SETTING_FONT ・設定パネル文字入力欄背景色 final public int SETTING_TEXT_FIELD_BACKGROUND_COLOR ・設定パネル文字入力欄文字色 final public int SETTING_TEXT_FIELD_FOREGROUND_COLOR ・設定パネル文字入力欄フォント final public int SETTING_TEXT_FIELD_FONT pass:klab http://www1.axfc.net/uploader/Sc/so/252047 (2011.07.05 matsu) ☆受信の方法・ReceiveMessageクラスの receive(String command)メソッドを使う・引数のcommandは下記の様式に従うこと・commandに対応した返り値が、下記の様式で返ります（サーバ側から引用） BBS&1;[C要求レス数|D日付エポック]（←commandの引数） return一覧 [レスID&1;日時&1;ユーザー名&1;文の内容[&0;...]] QandA&1;[C要求質問数|D日付エポック]（←commandの引数） return一覧 [&1;日時&1;ユーザー名&1;文の内容[&0;...]] TASK&1;[C要求タスク数|D日付エポック]（←commandの引数） return一覧 [タスクID&1;日時&1;UserName&1;taskName&1;進捗率の数字[&0;...]] ☆送信方法・SendMessageクラスの send(String tosend)メソッドを使う・引数のtosendは下記の様式に従うこと・tosendの内容をサーバ側に送ります・それぞれの担当によって、様式が違うので、tosendはそれぞれ下記の「例」のように記述して下さい・send(String tosend)メソッドは引数tosendの内容を送信するだけなので、様式を付ける部分が必要です　様式を付ける作業は　public abstract void sendMessage(String message) メソッドで実装してくれることを期待しています　このメソッドでは引数messageをもとに様式に合わせたStringに変形し、send(String tosend)メソッドの呼び出しまでまとめて行うとよいでしょう BBS ~~BBS&1;ユーザー名&1;文の内容~~ 例： action=BBS&username=346yuki&contents=これはBBSのテストです QandA ~~QA&1;ユーザー名&1;Subject&1;&1;文章~~ 例： action=QA&subject=題名テスト&qora=question|answer1&contents=これはQorAのテストですタスク ~~TASK&1;&1;UserName&1;taskName&1;進捗率の数字~~ 例： action=TASK&taskchk=New|taskid1&username=346yuki&taskname=タスクテスト&prograte=50.0 mastu (2011.06.12) 　必要な定数があったら、Settingsのなかで保持するようにつくりますので、言ってください。　　例えば、表示するメッセージ数とか、初回起動時に取得するメッセージの数とか、各種色定数とか。。。いると思うので言ってください。 matsu (2011.06.11) 　とりあえずアップロードしました。試行錯誤中だからソースが汚いけど、許して。　各担当カ所のパッケージのファイルを書き換えてください。　　・各パネルは空になっていますが、インスタンスは生成され、Frameに貼りつけられていますので、内容を記述すれば描画されるはず。　　・Settingsのインスタンスは Settings.getInstance() で取得してください。定数の取得はgetXXXX()で取得してください。（eclipseなら候補がでるはず）　　・必ずJPanelクラスを継承してね。　Settingのパネルはつくってあるけど、表示が微妙なのと、値の変更ができないのは仕様。 pass : klab http://www1.axfc.net/uploader/Sc/so/243735 -mishi発言 BBS&1;ユーザー名&1;文の内容例： action=BBS&username=346yuki&contents=これはBBSのテストです QandA QA&1;ユーザー名&1;Subject&1;&1;文章例： action=QA&subject=題名テスト&qora=question|answer1&contents=これはQorAのテストですタスク TASK&1;&1;UserName&1;taskName&1;進捗率の数字例： action=TASK&taskchk=New|taskid1&username=346yuki&taskname=タスクテスト&prograte=50.0 ↑こんな感じにしたいんだけどどうかね？

サーバー

2011-07-04T15:32:58+09:00

*&bold(){サーバーの情報はここへ} -mishi発言 BBS&1;ユーザー名&1;文の内容例： action=BBS&username=346yuki&contents=これはBBSのテストです QandA QA&1;ユーザー名&1;Subject&1;&1;文章例： action=QA&subject=題名テスト&qora=question|answer1&contents=これはQorAのテストですタスク TASK&1;&1;UserName&1;taskName&1;進捗率の数字例： action=TASK&taskchk=New|taskid1&username=346yuki&taskname=タスクテスト&prograte=50.0 ↑こんな感じにしたいんだけどどうかね？あと＜N｜タスクID＞のNって何？ -mik 送信側掲示板 BBS&1;ユーザー名&1;文の内容 QandA QA&1;ユーザー名&1;Subject&1;&1;文章タスク TASK&1;&1;UserName&1;taskName&1;進捗率の数字受信側 BBS&1;[C要求レス数|D日付エポック] return一覧 [レスID&1;日時&1;ユーザー名&1;文の内容[&0;...]] QandA&1;[C要求質問数|D日付エポック] return一覧 [&1;日時&1;ユーザー名&1;文の内容[&0;...]] タスク TASK&1;[C要求タスク数|D日付エポック] return一覧 [タスクID&1;日時&1;UserName&1;taskName&1;進捗率の数字[&0;...]]

7/1haru

2011-07-01T14:54:11+09:00

どのようしてチームメイトとコードをシェアするでしょうか驚くべきことに、多くのチームはこの問題にはっきりと答えられず、かわりにただ大きく古い共有ドライブすべてのソースコードとそこらじゅうに横たわったその他のファイルをえるだけである。あくとの数だけ開発者がいるーそれは単純に編集しているファイルをコードにコンパイルするーはチームのほかのすべての開発者にすぐに影響を与える彼らの人生は今では断続的で、うれしくない驚きでいっぱいである。それはまさに感謝祭のキッチンの混雑に似ていて、みんな混雑の中に何かを投げていて、それは働く環境にとてつもない欲求不満をもたらしている。このようにして多くのチームが動作を続けているあいだ、あなたは安全でより専門的な立場を得ることができるでしょう。これは、あなたの道具やインフラに重大な影響を与えるでしょう、なので最初から右ストレートを取得する必要がある。そこには、たった一つの基本的なルールを頭の中にとどめておいてほしい。：他の仕事はあなたの準備ができるまであなたの仕事の影響から隔離されますそういうわけで私たちはこのサンドボックス開発と呼ぶ。すべての開発者は他の開発者の詳細なしでする彼ら自身のサンドボックス開発を持っている。それは、簡単そうに聞こえるかもしれません、特に中期的にソースコードが隔離されているときは、しかし、実際の策略ではすべての資源があらわれることを覚えておいてほしい。：ソースコードやデータベース、インスタンス、依頼したウェブサービス等等。あなた自身の開発の機械はあなた自身の生産に貢献するデザインにするべきである。世界のビルドのプロセスの貢献すべきでない何か-それは、他のだれかが何かのために直接頼りにすべきではないしかし、どのようにして他の開発者はあなたのコードを得ますか？コードは倉庫（レポジトリ）を経由して共有されます。レポジトリは大きな机を共有すると考えられます、しかし、それは司書によって管理されます。その司書は、全員のバージョンのファイル（または他の資源）が彼らが必要とし、全員がお互いを追い払わずに仕事ができるように正しいか確認するすべての開発者はソフトウェアツールをチェックインとチェックアウトし（まるで実際の図書室のように）使う、なので彼らはローカルで仕事をすることができる自分自身の開発マシーン上で、ソースコードファイルのローカルコピーの編集やコンパイルやビルドやテストをチームメイトからすばらしく分離する。もし、開発の最中にデータベースやウェブサーバやその他の資源を使う必要があるとき、念のため１つだけ使うでしょう。コードの一部を作り終え、それに満足しているとき、レスポンスにより確認する。しかしそのとき、どうのようにして、カスタマーは完成した製品を得るのでしょう。開発の機械やレポジトリに加えて、ビルドマシーンも持つ。ビルドマシーンはレポジトリやビルド、テストしたものから単純に最新のソースコードを繰り返し得る無人のサーバです。そのビルドの結果製品はリリースされます。たいていの時間は、リリースはどのビルドの後でもただ投げられるだけである。しかし、時々山積みのかけらであるカスタマーやエンドユーザに送るでしょう。苦労と汗の一ヶ月のあとの普通午前１０時のビルドまたは最終リリースのどちらかと同じにビルドされる。それはいつも一貫している。なぜならビルドマシーンは独立した存在だからだ。：それは、どんな理由でも個人の開発のマシーンを見ることはできない。ビルドにインプットすることは、レポジトリや全体のプロセスからのアウトプットはビルドマシーンの指定になる。このシステムの仕事は開発者がカンニングをしない限り偉大である。 /* job ask ビルドマシーンがビルドされリリースされるボックスだろうとそうでないだろうと。 -コードはあなたの消費者に送られる。しかしながら、ビルドボックスそして送られた商品のビルドボックスの両方は同じスクリプトで使われ、かれらのソースとして同じレポジトリで使われるなどなど。いくつかの違いとして、マークをつけると知られているレポジトリ内の出荷ビルドの作成の新しい分野またはタグかもしれな、コードのリリースのセット、またはたぶん出荷ビルドをさまざまなプラットフォームのインストーラーのコードで包む。 */ 時々「サンドボックス内に留まる」のは難しい、特にもしデータベースの使用許可やウェブサーバのポートが少ししか供給されない場合ではである。たぶんひとつのデータベースを用いるでしょう、しかし、どの開発者もインスタンスを分けて作るでしょう。もしくは、ひとつのデータベースをひとつのインスタンスで使うことを強制されるとき、たぶんデータのスペースを区切るでしょう（例えばジョーはテストデータの記録の割り当てを1000-1999にして、スーは2000-2999にする）。これは、まだあなたに干渉のリスクを残しています、しかし、無いよりはましである。ウェブサービスのようなほかの資源で、すべての開発者は彼ら自身のインスタンスで明確なショットを持っている（彼らはこれに対抗するテストかサービスの供給）この頭の中に隔離された基礎のアイディアで、いくつかのツールやサンドボックスの効果を達成するために必要とするであろうインフラのほかのかけらを見つけましょう。

7/1end

2011-07-01T14:53:39+09:00

多くのソフトウェア開発者は、今日フラストレーションを感じている。彼らは長く、厳しい時間を働くが、彼らのチームは現在のプロジェクトを終えることはできないようです。それは、努力や意欲が無いためではない; チームに所属する誰でもきれいにプロジェクトを仕上げたいです、しかし、誰もそのための方法を知らない。あなたの操作で何が動作し、どのようにそれを作るのか、を見つけるために読書や実験をする時間を見つけることは、非常に難しい。大部分の人々は、この種の研究に乗り出すには、働くのに忙しすぎる。そこで、Ship It!　の出番である。この本は、フィールドで、複数のプロジェクトに関して、すべてのサイズの会社で証明された、基本的な、実際的なアドバイスのコレクションである。それは、我々が遭遇したものだ。我々は、数週間で出たり入ったりしたコンサルタントではない; 我々は、明けても暮れても、これらの会社で働いた。我々は、良く聞こえて、次の約束へいどうするという考えの中に落ちたりしなかった。物事がうまくいかなかったとき、我々はそれらが倒れるのを見るためにまだそこにいた。一方、我々も、物事が本当にうまく行った時に見ることができた。これらの考えの一部は有名なソフトウェア方法論から露骨に持ち上げられました、そして、我々はそれが信用を与えるべきであるとした。他の考えは、血と汗と涙から創り出されました。我々は多くのツール、技術、最高のプラクティスで実験しました、そして、何かが働いたとき、我々はそれを保ちました。それがパタパタしたとき、我々はそれを投げました。あなたがここで見るほとんどは際立って独創的でない（これはいいことである）。その代わりに、我々は、業界で最良の知性から考えを選んで、「巨人の肩の上に立っていた」と、彼らをあなたがここで見るものに変えました。ソフトウェア・チームの50～70パーセントが今日の基本的な、有名なソフトウェアの実践（［CusO3］）を使わない。まだしばしば、彼らがどうすべきかわからないからではなく、彼らが単に実行を現時点で始めさせる方法を知らないから、これは使われない。よく、各々の考えに関して管理を販売する方法をあなたに教えてください、あなたを始めさせるために、実用的なステップを配置してください、そして、あなたが競馬場外に変わらないように、探す警告標識を提供してください。 Ship It!　は、「溝の中」にいた開発者によって書かれました。この本は我々の経験（理論でない）です。そして、小さなスタートアップから世界最大の非公開ソフトウェア会社にわたります。それは、プロジェクトをうまくいかせるための方法論を選ばない、現実的なガイドです。我々は、人気があるPragmatic Bookshelf titles にならって本を作ろうとしました：実際的な、小さい、簡単な読むこと。我々の見込みは、他のPragmaticタイトルが開始した基盤を基にしていることである。 1.1 習慣的優秀さそれで、どのように、アリストテレスの引用は、ここで合いますか？「我々は繰り返しそうするものです。優秀さは、それから、行為でなく、習慣です。」優秀さは、1つのすばらしい製品（またはいくつかのすばらしい製品）を生産することによって定義されません。それは、我々が毎日することから出てきます：我々の習慣。驚異的な製品は、単に良い習慣の副作用だけです。この引用を我々自身（両方とも専門的に、そして、個人的には）に適用することは我々が命が我々の習慣の副作用であると認めることを義務づけるので、我々は慎重に習慣を選んだ方がよいです。いろいろな理由で、大部分の人々は、彼らの仕事ルーチンにちょうどランダムに落ちます：これはあなたがそれを学んだ方法です、それはあなたのボスがそれ、その他をしたものである方法です。我々はよりうまくやることができます。故意に、良い習慣を捜してください。そして、彼らをあなたの日課に加えてください。この実験をためしてください。研究に開発方法論を見つけてください、そして、あなた（そして、それが単独で使われることができます）に親切に、見える1つの衣服を引き抜いてください。 1週間使用に迫ってください。それとそれのようなあなたが有益なようであるならば、1ヵ月それを使い続けてください。それがあなたのルーチンの自然の一部になるまで、新しい習慣を行ってください、そして、はじめからもう一度プロセスを始めてください。まさにあなたがレンガによって基盤レンガを積んで、このプロセスを繰り返して、一度に優秀な基盤に1つの新しい習慣を建ててやる通りです。決してあなたの状況で働かない何かを取り出すのを恐れないでください、そして、それが有名であるか人気があるから、実行を保たないでください。あなたのために働くこととそうしないことに基づいて、あなたなりに外に進出してください。 “How we spend our days is, of course， how we spend our lives." If that's so, then we must be careful how we spend our days. Don't fall into habits by accident. Choose your habits deliberately. 「我々が時代を過ごす方法は、もちろん、我々が命を費やす方法です。」それがそうであるならば、我々はどのように時代を過ごすかについて注意しなければなりません。偶然に習慣を始めないでください。故意にあなたの習慣を選んでください。 1.2 実際的な見解この本は何かが働かなければならないか、働いてはならない理由のアカデミックな分析でありません、そして、それは利用できる実行のカタログとあなたが選ぶことができる方法論でありません。その代わりに、この本は、現実のソフトウェア・プロジェクトに関して我々のために働いたことを提示します。それが働いたかどうかにかかわらずそれが明白であるまで、我々は新しいツールまたは実行を導入して、それを使います。我々は、ソフトウェア開発ツールボックスで働いて、我々と彼らを運んだものを保ちました。結局、我々が何をしているかについてわかっているように実は見えました！これらのツールと実行があなたのためにもよく働くことを、我々は望みます。単にそれが「目的のもの」であったので、方法論を使用する贅沢を持たなかったスタートアップに、我々は時間を費やしました。我々の状況は、我々に我々が説明することができた問題を解決した考えがすぐに働くとわかることを強制しました。彼らの自由で重要な資源とテクノロジーがあったより大きな会社で、我々も働きました。それがエレガントであるから、あるいは、一部の導師がそれを支持するので、大企業さえツールを使用することを望まないと、我々はわかりました。彼らは、迅速かつ経済的に今日の問題を解決する解釈を望みます。それで、ツールキットが持ち歩けるのに一般的な十分であるが、効果的にまだ問題を解決するまで、我々は習慣にここで気付いて、習慣をそこでやめました。この本は我々が意志が同様にあなたの店で違いを生じることを使った良い習慣のコレクションです-結果は驚くべきものでありえます。以下を例示します：あなたにTale ofTwo Software Shops（謝罪がチャールズ・ディケンズへにある）を話しましょう最初の店は、失敗でした。彼らは、むしろ高価なソースコード管理ソフトウェアを購入したが、それをこれまでインストールしませんでした。その結果、彼らは、潜在的な顧客に示していたデモのために、ソースコードを失いました。どんな特徴が製品に含まれると思われるか誰にもよくわかりませんでした、しかし、それにもかかわらず、全開発チームはそれに取り組んでいました。コードは不安定で、約5分（通常最悪でもデモの間に）おきにクラッシュします。この失敗は、士気に大きく影響しませんでした; 会社会議は、定期的に下方への螺旋でした－どなり合いへ一部の開発者は、一日中彼らのオフィスに隠れることによって、状況を避けました。全般的に見て、それは、働くための悪い場所でした。誰でも、大きな問題があるということを知っていました。しかし、誰もそれらを修正することができませんでした。第2の店は、非常により良い形でした。同じ数の開発者についてで、彼らは、同時に3つの主要な製品に取り組んでいました。これらのプロジェクトには、ソースコード管理システムで彼らのコードがありました; それが変わったときはいつでも、コードは自動的に立て直されて、テストされました。全チームは、短く、職業的で、効果的な毎日の会議を催しました。各々のプロジェクトにはマスタープランがあったので、どんな特徴に取り組むべきかについて、開発者全員がわかっていました。彼らは、採石場の労働者の信条に従いました; 単なる石を切る我々は、常に大聖堂［HTOO］を心に描いていなければなりません。つまり、誰でもより大きな、調整フレームワークの前後関係の範囲内で彼ら自身の専門知識と技術を使用することができました。それらが巧みに作られたので、それらの製品は最小限の手間ひまで、安定して時間通りに出荷されました。これらの2社についての最も驚くべきことは、彼らが同じ店で、この本によって6ヵ月未満で主義の適用により切り離される、ということです。（でも、あなたはそれをすでに推測したね？）転換の後、CEOは「よい雰囲気」を導入し、「場所さえ認めなかった」と、言いました。この会社は我々が最近働いた場所の1つです、そして、それらを提出して、我々はほぼ同級で支えるためにこの本に主義をもたらしました。我々がそこで経験した変化は、あなたのためにこの本を書くことを決めた理由の1つです。我々は、4人のベンチャーからからSAS（世界最大の私有ソフトウェア会社）まで、すべての会社で、これらの考えを発見して、適用しました。率直に言って、これらの主義がすべての会社でどれほどよく働いたかについて、我々は驚きました。これらの考えをすばらしい製品への基盤とみなしてください。前金で基盤をきちんと建てさせることに投資する気があるならば、あなたは製品のライフサイクルの残りの間利益を得ます。もちろん、プロジェクトをこれらの全ての実行と場所で始めることは、より簡単です。家の壊れた基盤のように、他が深く構造的で、多くの仕事で振り返って固定する必要がある間、いくつかは簡単に修復されることができます。あなたが現在プロジェクトの最中である場合、良い習慣を始めるのに遅すぎるということはありません。あなたはこれらの考えの多くを既存のプロジェクトに導入することができ、即座に利益を得ることができます、そして、最後の章でそうする方法を説明します。 1,3ロードマップ我々は、3つの主な地域にアイデアを準備しました：基盤。技術とプロセス（図1.1参照）。一貫してあなたの顧客が望む製品を届けることは、さっきの３つはあなたのチームの能力に直接影響を及ぼします。基盤ツールと基盤を用いて、我々は、あなたの人生とあなたのチームの一生をより安楽にするソフトウェア・ツールをカバーします。たとえば、良いソースコード管理システムは、あなたのプロジェクトの「クラウンジュエル」―我々のソースコード―を無事に保ちます自動化されたシステムは、あなたの好きな場所、時間で与えられます。そして、バグ・レポート、特集要請とあなたが残りの世界を何であったかについて見させた瞬間、やって来る他の問題の経過を追う方法を、我々は検討します発達すること。そして、あなたが何かを開発しているときに見つけたバグのレポートや特殊な要望、他の問題の経過を追う方法を我々は議論します。最後に、良いテスト・ハーネスは、あなたのコードがあなたの思った通りのことをするという確信をどのように与えるかについて教えます。技術実用的なプロジェクトのテクニック（Pragmatic Project Techniques）では、あなたとあなたのチームが「よりスマートである。ハードでない」ものへの毎日使うことができる具体的なプラクティス（実践）を、我々はカバーします。我々は、あなたを外界から遮断し、あなたが知る必要がある情報だけを得るためにあなたのチームに技術的なリードを与える方法を話します。グループを順調にしておくために、あなた自身の仕事とチームを組織するのに、一人でリストを使ってください。あなたのチームは、コミュニケーションしていますか？誰が何をしているか、話せませんか？チームメイトの心を汲み取る機会なので、全員が同じモチベーションを保つためにデイリー会議を始めてください。短いコード・レビューは、あなたの同僚の専門知識に影響を及ぼして、あなたにあなたの専門知識の少しも共有させるのを助けます。そして、一旦チェックが終わっているならば、あなたのしたコードチェンジについて、あなたのチームの残りに教えてください。

7/1hagi

2011-07-01T14:51:55+09:00

P13 家を作りたかった2人の男(マイクとジョー)がいた。マイクは最初に多くの時間と道具を買い使い方を学ぶ十分なお金を費やした。ジョーは、すでに持っている道具(ハンマーとドライバー)をとって作業し始めた。驚くほどではないが、ジョーの家は早く建ち始めた。一方マイクはコンプレッサーとネイルガン(タッカー?)の使い方を勉強しているあいだに、ジョーはハンマーで指を打っていた。しかし、一度マイクが曲線を勉強・会得し、建築を始めると、彼はすぐジョーに追いついた。マイクは時間をかけて道具の使い方を勉強したため、短い時間でいい家を作ることができた。誰もが、誰が彼らの隣の家を早く作り終えられるのか、について驚くのか? マイクのように、私たちは、処理における多くのツールを持つ。私たちはジョーのようになって、既知のツールを使って作り、今すぐ働く必要を隠ぺいすることができる。しかし、このチャプターのいくつかの道具はあなたが働くショップで扱えなかった。さもなくば、あなたは貧乏な道具を使うショップで働いたかもしれない。そして、あなたの口で悪い味を回避できるかもしれない。私たちはあなたがこのチャプターを繰り返し、毎日のルーチンでポジティブインパクトを与えないと議論したかどうかを見てほしい。フレッドな、典型的開発者は生活で毎日を見てみましょう。彼らのワークエクスペリエンスは環境(道具とインフラ)に影響された。 >誰もフレッドが見たトラブルを知らないフレッドが朝仕事場につくと、ウイルマが昼に書いたコードの変更のメールを確認した。その後その変更を求め、フレッドはネットワークからコードを落としてきてた。 1時間後、彼はウイルマの仕事のコンパイルを始めた。彼は数分間で何度も変更をチェックし、作業を行った。その時フレッドは思い出すために昨日のノートをみた。彼はほとんど新機能のコーディングを終えていた。 3日後、彼は昼食までに終わるだろうと示した。仕事の開始を熱望して、フレッドはコードエディタを立ち上げたが、彼の変更は消えていた。悪い予感が彼をよぎった。 3日の仕事が30秒で消えて、元に戻せなかった。「そんな…！」とフレッドはおもった。「最初は起こらなかったのに、終わらないのか…仕事での危険だな。」その時営業帰りのリチャードが先週の要求されたバグフィックスの進捗の確認に立ち寄った。フレッドはひるんだ。機能追加のラッシュで、彼はバグ修正を忘れていた。リチャードは遅れに対して不満そうだった。しかしフレッドは今日中に終わらせると約束した。フレッドは最後には夕方に遅れてバグ修正をした。彼は客にアップデートを送る準備を始め、問題の客は製品の修正版でなく、現在のバージョンを使っていることに気付いた。パッケージングを開始した結果、フレッドは、妻に晩飯の計画をキャンセルと言って、古いコードをネットワークドライブから探し始めたので、彼は製品のそのバージョンを直すことができる。 1時間経過後やコードの正しいバージョンを配置して、1時間マシンを動かしっぱなしにして、その後、古いコードベースの修正に向けて動き出した。長い1日だったが、彼の誇りは時間に入った(?)。フレッドは、成功するために会社に貢献するためによく働くことを望んでいる。彼の家族はそれを全体的にあまり理解していない。次の日、顧客は、フレッドが突然製品へ古いバグを再混入させ、さらに新しいバグが出たことに気付いた。 >あなたの1日の違いは? フレッドの場面へあなたを登場させてみましょう。あなたは朝会社につき、ベッキーからのコードの変更についてのメールを見つける。あなたのショップは、リポジトリに全変更を記録するソースコードパッケージ管理を使い、必要に応じて変ダウンロードが変更される。だから、あなたはベティのアップデートのためにただSCMに問い合わせるだけ。そして、彼らは既にあなたのマシンにあるコードへ変更をマージしてしまう。もしそこに衝突や上書きがあると、SCMはあなたが変更を失う前に警告を行う。次に、あなたはオンラインビルドコマンドを発行する。そしてベティの変更のコンパイルはあなたの変更に並んで表示される。あなたのショップが基本的ビルドシステムを使って以降、ベティはあなたと同じ方法でコードをビルドする。フレッドと違って、あなたは自分のマシンで時間をかけてコンパイルする必要はないのだ。作業開始と同時に、先週のバグフィックスの進捗の確認に立ち寄った。フレッドのようにあなたはそこで作業することを忘れていた。しかし、あなたはチームのバク追跡ソフトで毎週のレポートを読む習慣があり、月曜に思い出せた。あなたはバグを直し、客にアップデートをする準備ができた。リチャードは喜んで、あなたがすごいと思った。あなたがバグを直した時、客が現在のバージョンを使っていなかったため、あなたはソースコードの対応を発見できた。あなたはSCMに旧バージョンを要求し、受け取った。コードを探す時間は特に必要とせず、古いコードツリーからはバグは見つからなかった。あなたがバグだらけのコードツリーを使っていたとしても、あなたのビルドのプロセスの一部はテストスイートを自動的に含んでいる。このスイートはよくあるバグを見つけるための軽量のテストのセットを実行する。もしバグが再発見されたら、あなたは客がそれを見る前にそれを感知できる。 1日のおわりに、あなたは定時に退社し、家族と晩飯を楽しめる。フレッドは遅くまで働き、彼の妻を何度もいらいらさせた。あなたは3日の機能追加を終わらせ、次の日に会社に行ったときはほかのタスクを始めることができる。あなたはフレッドより生産的で、しかしあなたは素早くも傾倒してもない。あなたはとても献身的で賢い開発者だ。あなたとフレッドの唯一の違いはあなたのショップがあなたにキーツールを与え、フレッドのショップはそれがなかった。ツールを配置し、問題ないところでの多くの慢性頭痛が出る状態を変えるような、あなたは形のある開発インフラを持つことになる。 >フレッドのトラップを避けるフレッドはとても忙しいので、よい方法に気付けない。毎回の成功プロジェクトは強力な基本フレームワーク(インフラ)を持っている。ツールと製品を組み立てるためにチームが使う練習がある。ソースコードや管理システムやビルドツールのような。あなたが使う明確なツールは違うかもしれない。しかし、カテゴリはどのプロジェクトでも共通である。このチャプターはあなたが毎プロジェクトで使うべき基礎的ツールを記していく。このチャプターのいくつかのトピックはくどくどしている。しかし、私たちはそれらも含めた。ただくどくどしているというのは、幅広く使われていたり、幅広く使われているのを意味しない。いくつかのチームはほとんどの場所できちんと装備しているかもしれない。しかし巨大なまだ知られていない機能が存在する。彼らは完全にメジャーツールのカテゴリをなくすことができる。にもかかわらず、巨額なお金を他のエリアに費やす。ベンダーの「スーパーツール」という主張に頼ることは、彼らに何でもやってあげることになる。毎セクションが終わったときに、心の中でそれを我慢して、あなたが現在やっているのかをただ読んでいるのを止めて比較する。もしあなたがツールやアイデアを使っていない場合は、なぜそうしないのかと問いなさい。聞いたことがないものなのか、使ったことがないものなのか、それともあなたの役に立たないのか? もしあなたがツールやアイデアを使うと、あなたは正しいスプリントでそれを使うのか? そうでなければ、そのツールは・アイデアはどんな良い効果をもたらすのか。 P16

7/1matsu

2011-07-01T14:49:08+09:00

// 2-2 Manage Assets 資産を管理しろほとんどの会社は、資産を管理することに打ち込む、大きなシステムやスタッフをもつそれらは会社の価値ある物理的な資産のすべてを保持する会社の価値ある物理的な資産ーコンピュータ、車、建物、オフィスでの成果物、などソフトウェアプロジェクトでは、あなたはいくつかのシンプルなタスクをもつシンプルなタスク：あなたが保持する必要があるすべてのものは、ファイルであるしかし、あなたはすべてのバージョンのビルドに用いる、すべてのファイルを保持する必要がある、プロジェクトが前進するはじめからのこの恐ろしいタスクのために、あなたはソース・コード・マネジメント（SCM）システムを必要とするこれはまた、バージョン・コントロール（VC）システムとも呼ばれるこれらのシステムは有能な司書として動作し、保管場所（またはデータベース）にあるあなたの資産（ファイル）を保持したり、あなたのファイルへの安全なアクセスをコーディネートしたりするこれらシステムはあなたのソースコードの貯蔵はもちろん行う、しかも、他のすべてのサポートファイルも保管する。すべてのサポートファイル：全員がリリースする、グラフィック、ビルドスクリプト、XMLドロッピング、ドキュメンテーション、小さな（しかし重要な）パールスクリプトきちんとセットアップしたSCMシステムと、あなたができること・あなたのチームにプロジェクト全体にわたるアンドゥボタンを与える：ファイナルはない。間違いは簡単にロールバックされる。・ひとりより多くの人が与えられたファイルを同時に編集する（または編集したい）ときは、そのぶつかり合いに対処する・複数のバージョンのあなたのソフトウェアに跡をつける：他の人が古いリリースのバグを修正している間に、あなたは次のリリースへの特徴を追加することができる・どのファイルが（いつ、誰によって）変更されたのか記録しなさい。・歴史的ピークを取り出す：あなたは任意の与えられた日にちからあなたの仕事をとりだせるもし、あなたの開発ショップの全体が炎に焼かれても、あなたはあなたの保管場所のバックアップから、ただリカバリーすることができるはずだあなたはあなたが製品全体でビルドに必要なすべてのものを持つはずだ：もしあなたがしないなら、そのときひょっとすると、あなたはそのツールをきちんと使っていない Tip 3 あなたがそれを必要とするなら、それをチェックインしなさい Javaランタイム（Sunが作った無償利用可能なもの）または、他の特定の製品のような、サードパーティのアイテムを免除する（保存しない）人がいる彼らは、それらのアイテムを彼らのSCMシステムに貯蔵しないそれはおそらくよいことだろう、もしあなたの製品が複数のバージョンのサードパーティ製品で動作することができるなら。しかしながら、もしあなたが特定のバージョンの製品に依存するなら、あなたは他の会社がその製品バージョンをあなたのために、提供やサポートを続けることに賭けていることに気づけ「あなたの製品のビルドにあなたが必要なすべてをSCMに保持しなさい。」という警告への唯一の例外は、あなたが生み出すことのできるファイルであるもしあなたが１５０のライブラリ（JARやDLLファイルで出力された）のセットを持っているなら、それはそれらのライブラリをあなたのSCMに書きだすのは愚かだろうあなたはそれらをリビルドできる、もし必要なら。なぜならあなたはあなたのSCMにオリジナルのコードを持っているからであるしかしながら、もしあなたの１５０のライブラリがすべて他社からのもの、あるいはあなたがあなたの製品をそれらなしでビルドできないなら、それらをあなたのSCMに含めなさい他の考えるポイントは製品（それと会社全体の、問題のために）がしばしばなくなることであるもしあなたのベンダーがビジネスをやめるまたは、あなたのオープンソースツールのサポートをやめることを決めるなら、あなたは生き残れるか？あなたのあなたの製品をまだ発売できるか、もし主要なベンダーがビジネスをやめるあるいは、もしオープンソースプロジェクトがなくなったならオープンソースでも商業用でも、製品はしばしば予期せずなくなるものである必ずあなたのビルド、展開、あなたの製品の動作に必要なものは、あなたのSCMシステムにすべて保持しなさいもししなかったら、あなたは長い期間のあなたの開発プロジェクトの実行可能性をリスクにおく　// ディスク空間に保存するためにそれは愚かである、あなたがそれをそのように言うなら。違いますか？あなたがSCMを使うとき、あなたは特定のバージョンのあなたの製品（または現在のバージョン、問題のために）を得ることができるあなたは特定の変更をロールバックできるあなたがこの方法で働いたとき、あなたの開発時間はアクシデントによる浪費をしないでしょうあなたの仕事は大変価値があって、上書きやぬぐい去ることができない；それを、あなたにロールバックの変更やあなたのコードの知っている良いバージョンにもどすことを可能にする、ソースコードシステムに書き込め The Dog Ate my Source Code 犬があなたのソースコードを食べたあなたはあなたの製品のソースコードがどこにあるか知っているか？すべてのそれの？すべてのバージョンの？本当か？そして、残りのあなたのチームも同様なのは確かか？ポイントにおけるケース：私たちが加わった小さなdot-comスタートアップはstate-of-the-artのソースコードコントロールシステム（ああ、ベンチャー投資家の歓びの種）で６つの図式を使ってきた。しかし彼らはそれをインストールした環境には達していなかった３つ（そう、たった３つ）のそれぞれは開発者はそ製品コードのはっきり違うバージョンを持っていた、彼らの独特なバグの集まりと共にそれらのどのバージョンもその会社がカスタマーに将来のものとして見せたデモとは一致しない大きな努力の後に異なるバージョンが調和される、私たちは結局ただ諦めるて、先に進むために１つのバージョンを選んで使うしかない私たちはSCMをインストールした、このバージョンのコードをこれに入れた、そしてそのときからこれをコツコツと使った。全員がどのコードが「実際の」製品コードであるか知っていた、そして開発者は平和な心（また製品の品質）は劇的に改善された How Do I Get Started? どのように私は始めたかもしあなたがどんなタイプのソースコード・コントロールもあなたのプロジェクトに使っていないのなら、それをあなたの優先順位の一番上にしなさいこれまでの調査によると、４０％ほどのアメリカにあるITショップは、どんなソースコード、バージョンコントロール製品もまったく使っていない、だから私たちは知っている１．いくつかのSCMシステム（p165の付録Bをごらんなさい）の価値を見極めなさい私たちは心からCVSまたはSubversionを推奨する（例として、先行しているページの図2.3をごらんなさい）どちらもフリーかつ世界中の最大級のソフトウェア会社に使われているもしあなたが商業的ソリューションを選んだのなら、これら製品は彼らの目玉商品との比較のために、あなたにベースラインのシステムを与えるであろう２．あなたのSCMの使い方を学びなさい３．１枚のページで、そのシステムへの共通操作のための使い方を教える、クイックスタートガイドを生成しなさい（留意点などについてp35のリストをチェックしなさい）４．あなたのチームにそのシステムを見せなさいそのシステムでみんなが必ず快適を感じるはずだ５．あなたのコードやサポートファイルをインポートしなさい６．あなたのすべてのファイルをSCMで保持することを始めなさい Am I Doing This Right?　これを本当にやるのか？まず、あなたはそのシステムを積極的に使いますか？もしあなたが週に１度から数日に１度と答えるなら、あなたはシステムを積極的に使っていないこれは目的（あなたの仕事をバックアップする、性格できめ細かな履歴を保持する）の全てを失敗させるあなたのコードが製品ツリーへの準備が出来ていなくても、それはシステムのプライベートまたは個人用の領域に置かれるとこができるもしあなたのワークステーションのHDDがまさに今クラッシュしたら、どれほどの仕事をあなたは失う？それは１、２日より多い、あなたの仕事の仕方を変えることを検討しなさいまた、新しいマシンを開発用にセットアップするのにどのくらいかかる？あなたの全てのビルドスクリプトや開発リソースのすべてはチェックが済んでいるか？あなたはSCM操作を素早く行えるか？コードチェックアウトには２０分、コードのバックアップには他に１５分かかるだろう、あなたはコードチェックインを頻繁にしたくはなくなるだろう差異のフェッチングのような操作はCPUとHDDを酷使するといえる多くの会社ではSCMソフトウェアを時代遅れのコンピュータに置くだろう、すべてのインタラクションが辛いものになるハードウェアは安い、しかし開発者の時間は高価であるどんなそれ（訓練、ハードウェア、または新たなSCMソフトウェア）でも、必ずあなたのSCMはあなた保つのに十分早いべきであるあなたはSCMの保管場所をバックアップしていますか？もし建物が今夜炎上して倒壊したら、あなたは他のコンピュータにリストアできるoff-siteのバックアップを持っているか？素晴らしいSCMはあなたに良くないことをする、もしそのデータが喪失の運命を持っているなら最低でも、必ずあなたは完全で週１度のoff-siteバックアップを行うべきである最後に、あなたはあなたのシステムがこれらの操作に十分によい振る舞いを簡単にするか知っているか？これは操作におけるあなたが知っておくべき最小限のリストである：・あなたのプロジェクト全体をチェックする・SCMの最新のコードとあなたの編集との違いを見る・特定のファイルの履歴を見るー誰がいつファイルを変更したか・あなたのローカルのコピーを他の開発者が変更した物にアップデートする・あなたの変更をSCMにプッシュ（あるいはコミット）する・あなたがSCMに最後にプッシュした変更を削除（またはバックアウト）する・先週の火曜日のコードツリーのコピーを復元する Warning Sings　留意点・保存場所に活動性がない使われない保存場所は役に立たない保存場所だあなたは積極的に毎時間一日を通して、個々の開発者が規則正しくチェックインやチェックアウトを行っているか監視すべきである・完全でない保存場所もし保存場所にあなたの製品のビルドに必要なファイルのみしか入っていないなら、それは自分の役割を果たしていない「実験的な」リリースあるいはテストツリーは保存場所、クリティカルXMLファイルあるいは、データベースにストアされないことに、用心しなさい・遅いアクセスファイルのチェックインやチェックアウトに長い時間がかかるなら、人々は結局それを使わなくなるでしょうーもし今は使っていたとしても・失われたファイル、破損したファイルいくつかのバージョンコントロールシステム（信頼ある大きな会社、名もない会社によって作られた）は通常の基礎のものでは、ファイルを「食べる」と知られている無償で使うことができるCVSまたはSubversionのような、本物のシステムにアップグレードしなさい

7/1yas

2011-07-01T14:45:45+09:00

○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?のセクションを拾い読みするだろう。しかし、あなたはそれぞれのトピックの内容と理由を理解したいとは思わないだろう。・Individuals Make a Team 　この本の全ての概念が、チームのメンバーや、チーム全体や、マネージャーに使われている。チームメンバーはしばしば、最初にその実践を使い、その価値を証明する。そしてその時、チームでその価値を共有する。私たちはそれを自分自身で何回も実践し、見てきた。そしてあなたも同じことが出来る。ここに、それを行った者の物語がある。　The Rapid growth of Agillity Support Systems at CafePress.com 　私たちがカフェプレスドットコムで去年の始めに働き始めた時、マネジメントはアジャイルの実践の採用に情熱を注いでいた。しかし、その開発の環境は、要求された基本的なサポートシステムが欠けていた。制作の開始とプロジェクトの買収－カフェプレスの中核の提供は、簡単に設計を行い、カスタマイズされた商品を買うことを可能にした。このプロジェクトは最初に、明確なビジネスと、ウェブのプレゼンテーションの層に加え、開発者の根強い層を紹介することを試みた。ビジネスと頑固な層のほとんどは、テストの最初にNUnitのフレームワークを使ってデザインされている。私たちは、NAntを編集と開発のためのものとして紹介している。　Subversion, CruiseControl.NET, NAntそしてNUnitの間の相互作用性は、私たちを手厚く支援してくれる。さらに、これらのサポートシステムは、開発者が始めたものであり、明確なマネジメントの要求のおかげではない。　私たちがそれらの作業をオートメーションで始める時、チームは成長していった。最新のアップグレードは、開発の環境の構築で記述された１００％が実装された。　これらのツールの出現の前に、私たちの日々のコミュニケーションのほとんどは、失敗を造り、APIの変更の通知についての放送の問題によって成り立っている。　私たちの初期の努力は、テストされたコードや私の初期の投資の直接の提供を手助けした。　私たちはこれがベストな方法だと感じた。　だから私たちは言う。「この本を使いなさい」と。あなたが、マネージャーや、開発者や、試験官や、テクニカルリーダーのどれであろうとも。そうすればあなたの人生は少し、今日より簡単なものになるでしょう。・アジャイリティとはなにか？　アジャイリティとは、状況を素早く変更して、ソフトウェア開発のチームの能力に採用する手法である。一般的に、アジャイルのチームはより密接な関係にある。詳しくは以下のアドレスを参照。　下に、そのサイトに掲載されているアジャイルのポイントを記載した。　「私たちは、ソフトウェアの開発のよりよい方法を、自分と他者を互いに助け合うことによって明らかにしている。この仕事を通して、我々は以下の価値を持っている。　・個人と相互作用はプロセスとツールを超える。　・ソフトウェアの仕事は、包括的な文章を超える　・変化のための応答は、プランに従うことを超える。　これは、右に価値がある道具がある時、私たちは左の道具に価値を見出すということなのである。」