エクストリームプログラミング-価値と原則

XPは、基本的な価値、原則、および慣行を導入することにより、変更のコストを削減することを目指しています。 XPを適用することにより、システム開発プロジェクトは変更に関してより柔軟になります。

極端なプログラミング値

エクストリームプログラミング（XP）は、5つの値に基づいています-

コミュニケーション
単純さ
フィードバック
勇気
尊敬

コミュニケーション

コミュニケーションは、プロジェクトの成功に大きな役割を果たします。プロジェクトの問題は、しばしばコミュニケーション不足のために発生します。多くの状況がコミュニケーションの崩壊につながる可能性があります。一般的な問題のいくつかは-

開発者は、設計の重大な変更について他の人に話さないかもしれません。
開発者は顧客に正しい質問をしないかもしれません。そのため、重要なドメインの決定が吹き飛ばされます。
マネージャーが開発者に正しい質問をすることはできず、プロジェクトの進捗状況が誤って報告されます。
開発者は、顧客から伝えられた重要な何かを無視する場合があります。

エクストリームプログラミングは、チームメンバー、マネージャー、顧客間の継続的かつ継続的なコミュニケーションを重視しています。単体テスト、ペアプログラミング、シンプルなデザイン、一般的なメタファー、共同所有権、顧客フィードバックなどのエクストリームプログラミングの実践は、コミュニケーションの価値に焦点を当てています。

XPは、人々がコミュニケーションを取っていないときに気付き、再紹介することを仕事とするコーチを採用しています。対面のコミュニケーションが優先され、ペアプログラミングで実現され、顧客の担当者は常に現場にいます。

単純さ

エクストリームプログラミングは、「今日は簡単なことをして、明日はそれを変えるにはもう少しお金を払う方が、とにかく使われないかもしれないより複雑なことをする」よりも信じています。

必要なことと求められていることを行いますが、それ以上は行いません。
「機能する可能性のある最も単純なことを実行する」DTSTTCPWの原則。
新しい機能を可能な限り簡単な方法で実装します。 KISSの原則「Keep It Simple、Stupid！」としても知られています。
エクストリームプログラミングの開発者が不必要に複雑なことをしているのを見ると、コーチはDTSTTCPWと言うかもしれません。
システムをリファクタリングして、現在の機能セットを備えた最も単純なコードにします。これにより、これまでに行われた投資に対して作成された価値が最大化されます。
目標に向けて小さな簡単な手順を実行し、発生した障害を軽減します。
誇りに思うものを作成し、合理的なコストで長期間維持します。
今必要のない機能、つまり「あなたはそれを必要としない」（YAGNI）原則。

コミュニケーションとシンプルさはお互いをサポートします。

コミュニケーションをすればするほど、何をする必要があるかを正確に把握でき、実際に何をする必要がないかについて自信がつきます。

システムが単純であればあるほど、必要な開発者が少ないことについてコミュニケーションする必要が少なくなります。これにより、コミュニケーションが向上します。

フィードバック

反復するすべてのコミットメントは、機能するソフトウェアを提供することによって真剣に受け止められます。ソフトウェアは顧客に早期に配信され、必要に応じて必要な変更を加えることができるようにフィードバックが行われます。システムの現在の状態に関する具体的なフィードバックは貴重です。フィードバックの価値は、信頼できる方法でそれ自体に関する情報を提供する継続的に実行されるシステムです。

エクストリームプログラミングでは、さまざまな時間スケールですべてのレベルでフィードバックが保証されます-

お客様は、開発者が興味のある機能を伝え、開発者がそれらの機能にのみ集中できるようにします。
単体テストは、開発者にシステムのステータスを伝えます。
システムとコードは、開発状況に関するフィードバックをマネージャー、利害関係者、および顧客に提供します。
頻繁なリリースにより、顧客は受け入れテストを実行し、フィードバックを提供し、開発者はそのフィードバックに基づいて作業することができます。
顧客が新しい機能/ユーザーストーリーを作成するとき、開発者は、変更を提供するために必要な時間を見積もり、顧客とマネージャーに期待を設定します。

したがって、極端なプログラミングでは、フィードバック-

変化の触媒として働く
進行状況を示します
開発者が正しい軌道に乗っているという自信を与えます

勇気

極端なプログラミングは、次の方法で開発者に勇気を提供します-

必要なものだけに集中する
フィードバックを伝えて受け入れるには
進捗と推定について真実を伝えるため
コードをリファクタリングするには
変化するたびに適応する
コードを破棄するには（プロトタイプ）

これは、誰も一人で作業しておらず、コーチがチームを継続的に指導するために可能です。

尊敬

尊敬は深い値であり、他の4つの値の表面の下にあります。エクストリームプログラミングでは、

誰もが大切なチームメンバーとしてお互いを尊重します。
誰もが熱意などの価値を提供します。
開発者は顧客の専門知識を尊重し、その逆も同様です。
経営者は、開発者が責任を受け入れ、自分の仕事に対する権限を受け取る権利を尊重します。

コミュニケーション、シンプルさ、具体的なフィードバックと組み合わせることで、勇気は非常に貴重になります。

コミュニケーションは勇気を支えます。なぜなら、それはよりリスクの高い、報酬の多い実験の可能性を開くからです。
シンプルさは勇気をサポートします。シンプルなシステムでもっと勇気を出す余裕があるからです。無意識のうちにそれを破る可能性ははるかに低くなります。
勇気がシンプルさをサポートしているのは、システムをシンプルにする可能性がわかったらすぐに試すからです。
最後にテストが緑色に変わるのを見ることができれば、具体的なフィードバックは勇気をサポートします。なぜなら、コードに根本的な修正を試みた方がはるかに安全だと感じるからです。テストのいずれかが緑色にならない場合、コードを捨てることができることがわかります。

極端なプログラミングの原則

値は重要ですが、何か価値があるかどうかを判断できないという意味で、あいまいです。たとえば、誰かの観点からは単純なものでも、他の誰かの観点からは複雑な場合があります。

したがって、エクストリームプログラミングでは、基本的な原則が値から導出されるため、これらの原則に対して開発プラクティスをチェックできます。各原則は価値を具体化し、より具体的です。迅速なフィードバック-あなたはそれを持っているか、持っていないかのどちらかです。

極端なプログラミングの基本原則は次のとおりです-

迅速なフィードバック
シンプルさを想定
漸進的な変化
変化を受け入れる
質の高い仕事

迅速なフィードバック

迅速なフィードバックとは、フィードバックを取得して理解し、できるだけ早くシステムに学習を戻すことです。

開発者はシステムを設計、実装、テストし、数日、数週間、または数か月ではなく、数秒または数分でそのフィードバックを使用します。
顧客はシステムをレビューして、システムの貢献度を確認し、数か月または数年ではなく数日または数週間でフィードバックを提供します。

シンプルさを仮定

単純さを前提とすることは、すべての問題を単純さで解決できるかのように扱うことです。

伝統的に、あなたは将来のために計画し、再利用のために設計するように言われます。このアプローチの結果は、「顧客が今日必要としているものが満たされておらず、最終的に提供されるものが時代遅れで変更が難しい場合があります」に変わる可能性があります。

「シンプルさを前提とする」とは、「今日の仕事をうまく解決し、必要なときに将来的に複雑さを加える能力を信頼すること」を意味します。）今日重要なことに焦点を当てます。

優れた単体テストを使用すると、コードを簡単にリファクタリングして追加のテストを実行できます。
YAGNIに従ってください（あなたはそれを必要としません）。
DRY（Do n’t Repeat Yourself）原則に従います。例えば、
同一（または非常に類似した）コードの複数のコピーを持たないでください。
情報の冗長コピーを持たないでください。
必要でないかもしれないものについて、時間とリソースの浪費はありません。

増分変化

どんな状況でも、一度に行われた大きな変更は機能しません。すべての問題は、違いを生む一連の最小の変更で解決されます。

エクストリームプログラミングでは、インクリメンタルチェンジがさまざまな方法で適用されます。

設計は少しずつ変わります。
計画は少しずつ変わります。
チームは少しずつ変わります。

エクストリームプログラミングの採用でさえ、わずかな手順で実行する必要があります。

変化を受け入れる

最善の戦略は、最も差し迫った問題を実際に解決しながら、ほとんどのオプションを保持する戦略です。

質の高い仕事

誰もが良い仕事をするのが好きです。彼らは誇りに思っている品質を生み出そうとします。チーム

うまくいく
仕事を楽しんでいます
価値のある製品を生産するのに満足

Extreme-programming-values-principles

目次