Extreme-programming-activities-artifacts

エクストリームプログラミング-アクティビティとアーティファクト

この章では、エクストリームプログラミングアクティビティとアーティファクトについて理解します。

XP –アクティビティ

エクストリームプログラミングでは、4つの基本的な活動があります-

• コーディング
• テスト
• 聞いている
• 設計中

コーディング

ペアプログラミングでは、コーディングは開発の中心と見なされます。 コーディングしないのは、一日の終わりには何もしていないからです。

テスト

ペアプログラミングでは、コーディングが行われたことを確認するためにテストを行う必要があります。 テストしなければ、いつコーディングを終了したかわかりません。

聞いている

ペアプログラミングでは、何をコーディングするか、何をテストするかを聞きます。 耳を傾けなければ、何をコーディングするのか、何をテストするのかがわかりません。

設計中

ペアプログラミングでは、優れた設計によりシステムの拡張が可能になり、変更は1か所のみであるため、コーディングとテスト、リスニングを無期限に継続できるように設計します。

これらの活動は中に実行されます-

• リリース計画
• 反復計画
• 実装

リリース計画

リリース計画では、顧客と開発者の両方が共同で次のリリースの計画に到達し、リリースのユーザーストーリーと次のリリース日について合意します。

リリース計画には3つのフェーズがあります-

• 探索段階
• コミットメントフェーズ
• ステアリングフェーズ

リリース計画-調査フェーズ

探査段階-

• 顧客は、システムの重要な要件のリストを提供します。
• 開発者は要件を収集し、それらの各要件の作業への影響を推定します。

要件はユーザーストーリーカードに記載されています。 ストーリーを書くために、顧客は開発者とのミーティングで問題を抱えます。 開発者はこの問題を定義し、要件を取得しようとします。 この議論に基づいて、顧客がシステムの一部に何をして欲しいかを指摘するストーリーが書き込まれます。 開発者がこのストーリーに影響を与えないことが重要です。

アクティブリスニングは、このフェーズでは重要です。

• 開発者は、「顧客が求めているもの」と「価値の高い要件」を理解する必要があります。
• 顧客は、ストーリーを書くためにこれらの値にどのシナリオが寄与するかについて開発者と一緒に理解する必要があります。

顧客は要件をユーザーストーリーカードに記述しますが、耳を傾ける必要があります

• 明快さを得る
• あいまいさを避ける
• 理解にギャップがある可能性がある場合は、自分自身を表現する

これは言葉によるコミュニケーションでのみ可能です。

リリース計画-コミットフェーズ

コミットフェーズでは、顧客と開発者は含まれる機能と次のリリースの日付にコミットします。

このフェーズには、コスト、利点、およびスケジュールへの影響の決定が含まれます。 このフェーズでは、

• 顧客は、ビジネス価値によってユーザーストーリーを並べ替えます。
• 開発者はストーリーをリスクで分類します。
• 開発者は、ストーリーの実装に必要な労力と期間（見積もり）を決定します。
• 次のリリースで終了するユーザーストーリーが選択されます。
• ユーザーのストーリーと推定に基づいて、リリース日が決定されます。

アクティブリスニングは、このフェーズでは重要です。

• 開発者は、現在のリリースでコーディングする必要がある機能と、この機能を提供するために必要な作業と期間（見積もり）を理解する必要があります。
• 顧客と開発者は、次のリリース日にコミットメントの実現可能性を理解する必要があります。

リリース計画-ステアリングフェーズ

ステアリング段階では、顧客と開発者は「ステアリング」します-

• 個々のユーザーストーリーおよびさまざまなユーザーストーリーの相対的な優先順位を変更する。
• 計画を調整します。
• 見積もりが間違っていることが判明した場合。
• 変更に対応するため。

アクティブリスニングはこのフェーズでは重要です。

• 理解するために-
• 追加する新しい要件。
• 既存の要件に対して行う必要がある変更。
• 既存の要件のいずれかが削除された場合の既存のシステムへの影響。
• 計画を調整するために必要な見積もりに到着し、考慮します
• これまでの作業。
• 追加する新しい要件。
• 変更または削除する必要がある既存の要件。

反復計画

反復計画では、開発者が反復のアクティビティとタスクを計画します。 これには、顧客は関与しません。

反復計画には3つのフェーズがあります-

• 調査段階。
• コミットフェーズ。
• ステアリングフェーズ。

反復計画-調査フェーズ

探索段階では、

• 要件はさまざまなタスクに変換されます。
• タスクはタスクカードに記録されます。
• 開発者は、各タスクの実装にかかる時間を見積もります。
• 開発者が小さすぎるか大きすぎるためにタスクを見積もることができない場合、タスクを結合または分割する必要があります。

反復計画-コミットメントフェーズ

コミットメントフェーズでは、

• タスクは開発者に割り当てられます。
• 開発者は、責任を負うタスクを受け入れます。
• 開発者はタスクの責任を負っているため、開発者はタスクを完了するのにかかる時間を見積もり、最終的にタスクの見積もりを行う必要があります。
• 負荷分散は、チーム内のすべての開発者にタスクが割り当てられた後に行われます。
• タスクの推定時間と負荷率の間で比較が行われます。
• 負荷率は、週40時間を想定した1回の反復での開発者ごとの理想的な実践的な開発時間を表します。
• その後、開発者間でタスクのバランスが取れます。 開発者が過剰にコミットしている場合、他の開発者は自分のタスクの一部を引き継ぐ必要があり、その逆も同様です。

反復計画-ステアリングフェーズ

ステアリング段階では、

• 開発者は、自分がコミットしたタスクのいずれかのタスクカードを取得します。
• 開発者は、ペアプログラミングのプラクティスに従って、このタスクを別の開発者とともに実装します。

実装

タスクの実装が完了しました。 実装には、設計、単体テストの作成、コーディング、単体テスト、リファクタリング、コードベースへの継続的統合、統合テスト、タスクカードおよびユーザーストーリーカードに基づく受け入れテストが含まれます。

エクストリームプログラミングアーティファクト

極端なプログラミングは反文書化ではありませんが、実際に必要な最小限の作業を行うことをお勧めします。 分散共有、歴史的ニーズ、要約などに必要なときのドキュメント

不可欠なエクストリームプログラミングアーティファクトは次のとおりです-

• ユーザーストーリーカード
• 受入試験
• 見積り
• リリース計画
• 反復計画
• タスクカード
• 設計
• ユニットテストケース
• 顧客と開発者のコ​​ミュニケーション記録

ユーザーストーリーカード

ユーザーストーリーカードには、次の機能があります-

• ユーザーストーリーカード-
• 顧客の観点からのシステムの動作の簡単な説明が含まれています。
• 開発者ではなく、顧客が作成する必要があります。
• 専門用語なしで顧客の用語を使用します。
• ストーリーの実装にかかる時間を見積もるのに十分な詳細のみを提供する必要があります。
• システムの主要な機能ごとに1つ。
• リリース計画の時間見積もりを作成するために使用されます。
• 受け入れテストの作成を促進します。

受入試験

受け入れテストは、ストーリーが適切に実装されたことを確認するための1つ以上のテストである必要があります。

見積もり–リリース計画

リリース計画で使用されるストーリーの労力と期間の見積もり-

• 探索段階でリリース予定日に到着します。
• ステアリング段階で調整を計画します。

リリース計画

リリース計画に含まれるもの-

• リリース用に選択されたユーザーストーリー。
• 努力と期間の見積もり。
• コミットされるリリース予定日。

タスクカード

タスクカード-

• ユーザーストーリーを実装するために必要なタスクが含まれています。
• ユーザーストーリーごとに1つのタスクカード。
• タスクの見積もりとタスクの割り当ての基礎を形成します。

見積もり–反復計画

ユーザーストーリーに基づいたタスクの労力と期間の見積もりが評価され、コミットメントフェーズでのタスクの割り当てと負荷分散の反復計画で使用されます。

反復計画

反復計画に含まれるもの-

• 反復のために選択されたユーザーストーリー
• タスクの割り当て
• タスクの見積もり

設計

デザインには、ユーザーストーリーの実装に十分なシンプルなデザインが含まれます。

ユニットテストケース

これには、コーディングと単体テストを推進する単体テストケースが含まれます。

顧客と開発者のコ​​ミュニケーション記録

顧客と開発者は、詳細を詳しく説明するためにストーリーを議論します。 可能な場合は口頭ですが、必要に応じて文書化されます。