エクストリームプログラミング-進化するプラクティス

エクストリームプログラミングは、その始まりとエクストリームプログラミングの実践が他のアジャイル手法でも効果的であることが判明してから進化を続けています。

次の表は、エクストリームプログラミングのプラクティスがどのように進化しているかを示しています。

Extreme Programming Practice	Evolution
On-Site Customer	Whole Team
The Planning Game	Release Planning 反復計画
Testing	Acceptance Testing 単体テストテスト駆動開発
Refactoring	Design Improvement
40-Hour Week	Sustainable Pace

オンサイト顧客–チーム全体

Extreme Programmingは、チーム中心のアプローチに重点を置いたプロジェクトコミュニティに依存しています。顧客を含むエクストリームプログラミングプロジェクトへのすべての貢献者は1つのチームです。

顧客は要件を提供し、優先順位を設定し、プロジェクトを進めます。これにより、顧客は開発の実際の詳細を理解し、それに応じて優先順位と期待値を設定できます。これは、「顧客が開発を要求するとき」から「顧客が開発を理解し協力するとき」に変わります。

プロジェクトの目標は共同責任であり、開発はチーム全体で継続的に行われる会話です。それは発明とコミュニケーションの協力ゲームです。対面コミュニケーションは、開発の過程で最も効率的で最も効果的な方法であり、待ち時間と遅延を排除することがわかります。

計画ゲーム–リリースおよび反復計画

増分プロジェクト計画は、正確な計画を促進するため効果的であることがわかりました。開発が実際のパフォーマンスに基づいて進むにつれて、より多くのより良い情報が学習されます。最初に大まかな計画を作成し、それを徐々に改善します。

リリース計画では、全体的な全体像を把握しながら、長期的な目標を設定します。顧客は必要な機能を提示し、開発者は推定し、リリース日は相互に合意されコミットされます。リリース計画はリリースごとに改訂されるため、プロジェクトが進むにつれてより正確になります。

反復計画では、通常1週間から1か月の範囲の反復で短期的な時間枠を設定します。反復計画の主な目的は、各反復の最後に動作するソフトウェアです。開発者は、反復のために機能/ストーリーを選択し、それらをタスクに分解し、タスクを見積もり、割り当てられたタスクにコミットします。週40時間を考慮して、チーム全体で負荷係数のバランスを取ることにより、持続可能なペースが確保されます。

受け入れ試験

顧客は、システムが目的の機能を正しく実装していることを確認するために、機能の1つ以上の自動受け入れテストを作成します。受け入れテストは、ストーリーとともに書かれ、実装前に提供されます。

チームはこれらのテストを自動化し、機能が正しく実装されていることを確認します。テストが実行されると、チームは、それまでに実装されたすべての受け入れテストを実行することにより、回帰時にそれ以降も正しく実行し続けることを保証します。

受け入れテストは、機能要件の明確な仕様を提供します。さらに、合格した受入テストの割合はリリースの完了を測定するものであり、最後のサプライズはありません。

システムは常に改善され、決してバックスライドすることはありません。

単体テスト

開発者は、コードモジュールとメソッドの意図と使用法を取り入れて、十分なカバレッジで単体テストを作成します。ユニットテストは自動化され、合格/不合格が明確になります。ほとんどの言語にはxUnitフレームワークがあります（例：nUnit、jUnit）。

すべての単体テストは非常に頻繁に実行され、すべての単体テストに合格するまでコードをチェックインできません。単体テストの結果は、リファクタリングにも役立ちます。

テスト駆動開発

テスト駆動開発は、最も革新的なエクストリームプログラミングの実践と見なされています。

テスト駆動開発では、開発者はコードを書く前に単体テストを書きます。その目的は、単体テストを失敗させることです。コードはまだ実装されていないため、単体テストは失敗します。開発者はユニットテストに合格するのに十分なコードを記述し、開発者はリファクタリングを行って、コードがシンプルでクリーンなものになるようにします（重複や複雑さはありません）。

開発者は、コーディングが完了し、受け入れテストに合格するまで繰り返します。

ユニットテストはすべて一緒に収集され、ペアがリポジトリにコードを統合してリリースするたびに、ペアはすべてのテストが正しく実行されることを確認する必要があります。テストが失敗した場合、ペアは、以前の統合が問題なく合格したため、修正する必要があるのは自分のコードであることを認識します。

テスト駆動開発では、100％のユニットテストカバレッジが得られる傾向があり、コードがシンプルかつ最小限に抑えられます。

リファクタリング-設計の改善

リファクタリングにより、デザインを徐々に進化させて、シンプルに保ちながら、気付くにつれて重複や複雑さを取り除くことができます。リファクタリングにより機能を変更することなく、既存のコードの設計を改善します。

リファクタリングは、新しい実装から学習することで推進する必要があります。新しいコードを書いた直後にリファクタリングを行うことをお勧めします。リファクタリングは、コードをより高いレベルの設計パターンに導き、テストによってサポートされます。

40時間の週–持続可能なペース

無期限に維持できるペースで作業します。持続可能なペースは、次の事実を考慮して、プロジェクトの成功に対する人間の貢献を保証します-

疲労とストレスは生産性を低下させ、製品の品質も低下させます。それはスタッフの離職につながります。
開発はスプリントで止まることはなく、長期目標を目指すべきです
チームが期待に同意しない限り、コミットメントと説明責任はありません。
正確な時間は、実行する能力ほど重要ではありません。
必要に応じて可用性を確保しながら、マイクロ管理を回避する必要があります

Extreme-programming-evolving-practices

目次