プランニングゲーム
XP planningは、ソフトウェア開発における二つの重要な問題に取り組んでいます。 プロジェクトのステアリングに重点を置いています–これは非常に簡単です–むしろ必要とされるものとそれがかかる時間の正確な予測ではなく、–これは非常に難しいです。, XPには二つの重要な計画ステップがあり、これら二つの質問に対処しています。
リリース計画は、顧客がプログラマに望ましい機能を提示し、プログラマがその難しさを見積もる練習です。 手の費用の見積もりと特徴の重要性の知識によって、顧客はプロジェクトのための計画を置く。 優先順位も見積もりも本当に堅実ではなく、チームが作業を開始するまで、彼らがどれだけ速く進むかわかりません。, ただし、最初のリリース計画であっても意思決定には十分に正確であり、XPチームは定期的にリリース計画を改訂します。
イテレーション計画は、チームが数週間ごとに方向性を与えられる練習です。 XPチームは、各反復の最後に便利なソフトウェアを実行して提供し、二週間の”反復”でソフトウェアを構築します。 イテレーション計画中に、顧客は次の二週間に必要な機能を提示します。 プログラマはそれらをタスクに分割し、コストを見積もります（リリース計画よりも詳細なレベルで）。, 前のイテレーションで達成された作業量に基づいて、チームは現在のイテレーションで実行される作業にサインアップします。
これらの計画ステップは非常に簡単ですが、非常に優れた情報と優れたステアリング制御を顧客の手に提供します。 数週間ごとに、進歩の量は完全に目に見えます。 XPには”九十パーセント完了”はありません：長編ストーリーが完了したか、そうではありませんでした。, 可視性のこの焦点は素晴らしく小さいパラドックスで起因する:一方では、そんなに可視性と、顧客は進歩が十分でなければプロジェクトを取り消す 一方、進歩はとても目に見え、次に何をするかを決定する能力はとても完全であり、XPプロジェクトはより少ない圧力とストレスで必要なものをより多く提供する傾向があります。
顧客テスト
目的の各機能を提示する一環として、XPの顧客は、機能が動作していることを示すために、一つ以上の自動受け入れテストを定, チームはこれらのテストを構築し、機能が正しく実装されていることを自分自身と顧客に証明するためにそれらを使用します。 時間のプレスでは、手動テストはスキップされるため、自動化が重要です。 それは夜が最も暗くなるときあなたのライトを消すようなものです。
最高のXPチームは、顧客テストをプログラマテストと同じ方法で扱います。 このシステムの向上は、ノッチングを進、後退に不安を感.,
スモールリリース
XPチームは、二つの重要な方法でスモールリリースを練習します。
まず、チームは、顧客によって選択されたビジネス価値を提供し、テスト済みのソフトウェアをリリースします。 当社は、お客様に本ソフトウェアの使用を目的に、どの評価もリリースにエンドユーザーの高いお勧めします。 最も重要な側面は、ソフトウェアがすべてのイテレーションの最後に表示され、顧客に与えられるということです。 これはすべてを開いて有形に保ちます。
第二に、XPチームはエンドユーザーにも頻繁にリリースします。, XP Webプロジェクトは、毎日、社内プロジェクトで毎月またはより頻繁にリリースされます。 シュリンク包装された製品でさえ、四半期ごとに頻繁に出荷されます。
これはしばしば良いバージョンを作成することは不可能に思えるかもしれませんが、XPチームはいつもそれをやっています。 これらの頻繁なリリースは、顧客テストとテスト駆動開発で説明されているように、XPのテストへの執着によって信頼性が保たれていることに注意し
シンプルなデザイン
XPチームは、シンプルだが常に適切なデザインにソフトウェアを構築します。, それらは簡単に始まり、プログラマーのテストおよび設計改善によって、それをそう保つ。 XPのチームはシステムの現在の機能性に丁度適する設計を保つ。 無駄な動きはなく、ソフトウェアは常に次の準備ができています。
XPのデザインは一度だけのものではなく、前もって行われるものではなく、常に行われるものです。 リリース計画とイテレーション計画には設計ステップがあり、チームはプロジェクト全体の過程を通じて、リファクタリングを通じて迅速な設計セッショ, 極端なプログラミングのような増分、反復的なプロセスでは、良い設計が不可欠です。 だからこそ、開発全体の過程を通してデザインに非常に焦点が当てられています。
ペアプログラミング
XPのすべての生産ソフトウェアは、同じマシンで、並んで座って、二人のプログラマによって構築されています。 この実践がすべての生産コードの見直しによる少なくとも一つのその他のプログラマー、その結果、設計、試験、およびより良いコードです。
二人のプログラマが”一人のプログラマの仕事”をしているのは非効率的に見えるかもしれませんが、その逆は真です。, 研究のペアをプロによるとペアリングの生産より良いコードのプログラマーとして働く重. そうです：二つの頭は本当に一つよりも優れています！
一部のプログラマは、ペアプログラミングを試すことなく拒否します。 それはうまくやるためにいくつかの練習を取るんし、結果を見るために数週間のためにうまくやる必要があります。 九％のプログラマを学習ペアングを好むので、いまは強く推薦していますすべてのチームあります。
ペアリングは、より良いコードとテストを提供することに加えて、チーム全体で知識を伝えるのにも役立ちます。, 組が転換すると同時に、皆は皆の専門にされた知識の利点を得る。 プログラマーは学び、スキルが向上し、チームと会社にとってより価値が高くなります。 ペアリングは、XPの外部であっても、誰にとっても大きな勝利です。
テスト駆動開発
エクストリームプログラミングはフィードバックに取りつかれており、ソフトウェア開発では、良いフィードバックは良いテスト トップXPチームは”テスト駆動開発”を実践し、テストを追加してから動作させる非常に短いサイクルで作業します。, ほぼ簡単に、チームはほぼ100パーセントのテストカバレッジでコードを生成します。 使用した場合は、プログラマーの間ですでに実施しているものより高度な試験にあたります。 それを維持、それだけで助けることができます！)
テストを書くだけでは十分ではありません。 ここでも、極端なプログラミングは極端です。 これらの”プログラマテスト”、または”単体テスト”はすべて一緒に収集され、プログラマがリポジトリにコードをリリースするたびに（そしてペアは通常、一日二回, 百パーセント、すべての時間！ このプログラマの取得の直接的な指導やアドバイスがどのよういしています。 また、これらの試験に有益な支援を提供し、ソフトウェアの設計が向上します。
設計改善(リファクタリング)
エクストリームプログラミングは、すべての反復でビジネス価値を提供することに焦点を当てています。 プロジェクト全体の過程でこれを達成するには、ソフトウェアが適切に設計されている必要があります。 代わりは減速し、最終的に動けなくなることである。, したがって、XPはMartin Fowlerの著書”Refactoring:Improving the Design of Existing Code”のタイトルから、リファクタリングと呼ばれる継続的な設計改善のプロセスを使用しています。
リファクタリングプロセスは、重複の除去（貧弱な設計の確かな兆候）、および”結合”を低下させながらコードの”結合”を増加させることに焦点を当ててい 高い凝集性と低い結合は、少なくとも三十年間、うまく設計されたコードの特徴として認識されています。 その結果、XPチームは良い、シンプルな設計から始め、常にソフトウェアのための良い、シンプルな設計を持っていることです。, これらの維持発展速度が一般的に増加速度のプロジェクトです。
リファクタリングは、もちろん、設計が進化するにつれて何も壊れていないことを確認するための包括的なテストによって強くサポートされています。 従って顧客テストおよびプログラマーテストは重大な可能にする要因であ XPのプラクティスはお互いをサポートしています。
継続的統合
エクストリームプログラミングチームは、システムを常に完全に統合し続けます。 私たちは、毎日のビルドは弱虫のためのものであると言います。, （四十人の一つのXPチームは、一日あたり少なくとも八、十回を構築します！このプラクティスの利点は、ビルドプロセスが毎週またはそれほど頻繁ではなく、通常はすべてが壊れ、誰も理由を知らない”統合地獄”につながった場所について聞いたことがある（あるいはその一部であった）プロジェクトを考え直すことによって見ることができます。
まれな統合は、ソフトウェアプロジェクト上の深刻な問題につながります。, まず第一に、良い作業コードを出荷するためには統合が重要ですが、チームはそれを実践しておらず、システム全体に精通していない人々に委任されること 第二に、ごく稀に統合コードが多い通常–バギーコードです。 統合されていないシステムで行われるテストのいずれによっても検出されない問題は、統合時にクリープします。 第三に、弱い統合プロセスは、長いコードフリーズにつなが, コードがフリーズするということは、プログラマが重要な出荷可能な機能に取り組むことができる長い期間があることを意味しますが、それらの機能は これは市場の、またはあなたのエンドユーザーとのあなたの位置を弱める。
集団コード所有権
極端なプログラミングプロジェクトでは、プログラマの任意のペアは、いつでも任意のコードを改善することができます。 これは、すべてのコードが多くの人々の注意の恩恵を受け、コード品質を向上させ、欠陥を減少させることを意味します。, コードが個人によって所有されている場合、あるプログラマが所有していないコードのどこかに機能が必要であることを発見すると、必要な機能が間違った場所に置かれることがよくあります。 所有者はそれを行うにはあまりにも忙しいので、プログラマはそれが属していない自分のコードに機能を置きます。 これは、醜い、保守が難しいコード、重複がいっぱい、低い（悪い）結束につながります。
人々が理解していないコードに盲目的に取り組んだ場合、集団的所有権は問題になる可能性があります。, ペアプログラミングは、不慣れなコードで作業する最良の方法は、専門家とペアリングすることであることを意味します。 必要に応じて適切な変更を確実にすることに加えて、この練習はチーム全体に知識を広げます。
Coding Standard
XPチームは共通のコーディング標準に従っているため、システム内のすべてのコードは、非常に有能な個人によって書かれたかのように見え, 標準の詳細は重要ではありません：重要なのは、集団的所有権をサポートするために、すべてのコードが馴染み深く見えることです。
メタファー
エクストリームプログラミングチームは、プログラムがどのように動作するかについての共通のビジョンを開発します。 その最高の状態で、メタファーは、エージェントベースの情報検索システムの説明として、”このプログラムは、花粉のために出て、ハイブにそれをもたらす、ミツバチの巣のように動作します”など、プログラムがどのように動作するかの単純な刺激的な説明です。
時には十分に詩的なメタファーが発生しないことがあります。, いずれにしても、鮮やかな画像の有無にかかわらず、XPチームは共通の名前システムを使用して、システムの仕組みと、探している機能を見つけるために、または追加しようとしている機能を置くための適切な場所を見つけるために、誰もがシステムの動作を理解していることを確認します。
持続可能なペース
極端なプログラミングチームは、長期的にそれにあります。 彼らは一生懸命働き、無期限に持続することができるペースで働きます。 これは、彼らが効果的であるときに残業をすることを意味し、彼らは通常、生産性を週間最大限にするような方法で働くことを意味します。, かもわからこちらをクリックすると期プロジェクトでも生産でも高品質なソフトウェアです。 XPチームは死ぬのではなく、勝つためにそれにあります。
結論
極端なプログラミングは、シンプルさ、コミュニケーション、フィードバック、および勇気の値に基づいて、ソフトウェア開発の規律です。 これは、チームがどこにいるかを確認し、独自の状況に合わせてプラクティスを調整できるようにするのに十分なフィードバックを持って、簡単なプラクティスの存在下でチーム全体