Extreme-programming-additional-features
エクストリームプログラミング-追加機能
この章では、Extreme Programmingの追加機能について学習します。
フィードバックループ
エクストリームプログラミングの魅力は、誰もが集中し続けることができる継続的なフィードバックであり、開発は遅れることなく正しい方向に進みます。
エクストリームプログラミングでは、さまざまなレベルで、必要かつ十分な詳細までフィードバックが行われます。 これは、反復およびリリース全体にわたって継続的かつ継続的に行われます。
次の表に、フィードバックイベントとフィードバック期間を示します。
Feedback Event | Feedback Duration |
---|---|
Pair Programming | Seconds |
Unit Testing | Minutes |
Clarifications among Team and with the Customer | Hours |
Progress | In a Day |
Acceptance Testing | Days |
Iteration Planning | Weeks |
Release Planning | Months |
プロジェクト管理
エクストリームプログラミングでは、プロジェクト管理は重視されておらず、マネージャーの役割は最小限で最も重要な管理アクティビティを実行します。
ただし、これらのアクティビティにはプロジェクト管理要件が組み込まれています。
- リリース計画
- スコープは、ストーリーカードのユーザーストーリーによって定義されます。
- 見積もりはストーリーの見積もりであり、ストーリーポイントに含めることができます。
- 配信のマイルストーンは、リリース計画によってキャプチャされます。
- リリースは反復に分割されます。
- 反復計画
- ストーリーはタスクカードのタスクに吹き込まれます。
- 見積もりはタスクの見積もりです。
- チーム全体で負荷率のバランスをとることによって行われるタスクの割り当て。
- タスクの受け入れは、チームのコミットメントと説明責任です。
- 追跡
- プロジェクトレベルでの実装の実際の時間からのストーリーポイントの観点からの速度。
- 開発者レベルで行われた実装の実際の時間からのタスク見積もりに関する生産性。
- 欠陥追跡
エクストリームプログラミング–業界の経験
業界全体で実行されるエクストリームプログラミングプロジェクトから、チームに役立つ特定の学習があります。
XPプラクティスからの学習
次のセクションでは、これらの学習について理解します。
- シンプルなデザイン-シンプルなデザインは効率的で、構築と保守が簡単です。
- *比phor *-比phorを使用する主な目的は、開発全体でドメイン固有の名前を使用することであり、それにより顧客が開発に積極的に参加することも可能になります。
- 集団所有権-各自がそれぞれの優れたコードを誇りに思っています。 協力することで、各自が全員のコードを誇りに思っています。
- 計画-チームが反復で多くのユーザーストーリーを完了する場合、反復を小さくします。 計画を変更するチームのコンセンサスを持っています。
極端なプログラミングのスケーリング
当初、エクストリームプログラミングは小規模なチームで効果的であると認識されていました。チームの規模は最大12〜16人です。
その後、エクストリームプログラミングを40〜50人のチームにスケールアップできることが確認されました。 ただし、再帰的なチームを構築してスケーリングを行うことをお勧めします。 最初に小さなチームを構築し、漸進的にチームを成長させ、最初のチームを使用して再帰的なチームをシードします。
ドキュメンテーション
エクストリームプログラミングはドキュメントに反するものではありません。 必要な場合、必要な場合、必要かつ十分な詳細のみを文書化することをお勧めします。 これはプロジェクトによって異なる場合があり、ドキュメントの範囲をプロジェクトが決定するためのものです。 ただし、ドキュメントをスキップすることは、エクストリームプログラミングプラクティスでは許可されていません。
XPを適用する利点
極端なプログラミングは、で適用された場合に有利であることがわかっています-
- 非常に不確実な環境
- 内部プロジェクト
- 合弁事業
XPを適用することの欠点
極端なプログラミングは、次の場合に不利であることがわかっています-
- 環境は大きく複雑です。
- 要件はよく理解されています。
- 顧客が遠くにいる、または利用できない。
XPの誤解
Extreme Programmingにはいくつかの誤解があります。 次の表に、存在する誤解の説明を示します。
Misconception | Clarification |
---|---|
No written documentation | Minimal and sufficient documentation needs to be there. However, there are no formal standards for how much or what kind of documents are needed. |
No design | Minimal explicit and up-front design needs to be there that evolves as the development progresses. |
Extreme Programming is just pair programming and easy | Pair Programming is just one of the Extreme Programming practices. It requires great discipline and consistency that is achieved in conjunction with the other Extreme Programming practices. |
Extreme Programming is the one, true way to build software | Extreme Programming is effective only in certain type of projects. |