Extreme-programming-supporting-practices
エクストリームプログラミング-サポートプラクティス
単独で実装された場合、エクストリームプログラミングプラクティスは脆弱になる可能性があり、したがって失敗する可能性があります。 エクストリームプログラミングでは、すべてのプラクティスが全体として考慮される必要があるため、それらは互いにサポートします。 1つの弱点は、他の強みによってカバーされます。
この章では、個別に実装した場合の各プラクティスの潜在的な弱点に焦点を当てます。 エクストリームプログラミングがこのプラクティスをサポートし、他のプラクティスと組み合わせて実装する場合の弱点を克服する方法を確認します。
プランニングゲーム-他のXPプラクティスからのサポート
このセクションでは、Planning Gameの弱点と、他のXPプラクティスがそれをどのようにサポートするかを説明します。
プランニングゲーム-欠点
計画ゲームの欠点は、大まかな計画だけでは開発を開始できないこと、および時間がかかりすぎて顧客を混乱させるため、計画を絶えず更新できないことです。
他のXPプラクティスと計画ゲーム
他のXPのプラクティスは、次の方法で計画ゲームをサポートしています-
- ゲームの計画では、顧客は開発者から提供された見積もりに基づいて計画の更新にも関与します。
- 計画の誤りがせいぜい数週間または数か月の影響を与えるように、短いリリースを作成します。
- 顧客はチームと一緒に座っているため、潜在的な変化や改善の機会をすばやく見つけることができます（オンライン顧客）。
- 継続的なテストは、開発者と顧客がすぐに必要なものを決定するのに役立ちます。
したがって、単純な計画で開発を開始し、進行に合わせて継続的に改善できます。
ショートリリース–他のXPプラクティスからのサポート
短リリース–短所
数か月後に本番環境に移行することはできません。 毎日から数か月ごとのサイクルでシステムの新しいリリースを作成することはできません。 これは、新しい要件、現在のコードへの変更を吸収するのに時間がかかるためです。
他のXPプラクティスとのショートリリース。
他のXPプラクティスは、次の方法でショートリリースをサポートしています-
- プランニングゲームを使用すると、最も価値のあるストーリーに取り組むことができるため、小さなシステムでもビジネス上の価値があります。
- 継続的な統合により、パッケージングのコストが最小限のリリースになります。
- テストにより欠陥率が十分に減少するため、リリース前に長いテストサイクルは必要ありません。
- 常にではなく、このリリースに十分なシンプルなデザインを作成できます。
したがって、開発の開始後すぐにショートリリースを作成できます。
比phor –他のXPプラクティスからのサポート
メタファーだけで開発を開始することはできません。 そこに十分な詳細がないかもしれず、あなたは間違っているかもしれません。
他のXPプラクティスとの比phor
他のXPのプラクティスは、次の方法でメタファーをサポートしています-
- ペアプログラミングを使用すると、実装されたコードから素早い具体的なフィードバックが得られ、メタファーが正常に機能しているかどうかがテストされます。
- 現場の顧客は、メタファーの観点からシステムについて話をするのは問題ありません。
- 継続的なリファクタリングにより、実装におけるメタファーの意味についての理解を深めることができます。
- シンプルなデザインは、比phorとのマッピングを支援します。
したがって、メタファーだけで開発を開始できます。
シンプルなデザイン–他のXPプラクティスからのサポート
シンプルなデザイン-欠点
現在のコードに対して十分な設計を行うことはできず、設計がシステムを進化させ続けることはできません。
他のXPプラクティスを使用したシンプルなデザイン。
他のXPプラクティスは、次の方法でシンプルデザインをサポートしています-
- リファクタリングにより、変更を加えることができます。
- 全体的な比phorを使用すると、将来の設計変更が収束パスに従う傾向があることを確信しています。
- ペアプログラミングは、動作するシンプルなデザインを作成していることを確信するのに役立ちます。
- 週40時間は、適切な設計に集中するのに役立ちます。
- 継続的な単体テストと顧客テストにより、シンプルな設計が軌道に乗っていることを確認します。
したがって、推測することなく、今日の最善の設計を行うことができます。
テスト–他のXPプラクティスからのサポート
テスト-欠点
あなたはそれを考えるかもしれません-
- これらのテストをすべて書くことはできません。
- テストの作成には時間がかかりすぎる場合があります。
- 開発者はテストを作成しません。
他のXPプラクティスを使用したテスト
他のXPプラクティスでは、次の方法でテストをサポートしています-
- シンプルな設計により、テストの記述が簡単になります。
- リファクタリングにより、必要なテストを決定できます。
- ペアプログラミングを使用すると、別のテストを考えることができなくても、パートナーはできます。 パートナーがキーボードを渡してテストを実行できるようにすることができ、すべてのテストが実行されていることを確信できます。
- 集合的な所有権により、必要なスキルを持つ開発者がコーディングとテストのために複雑な部分に取り組んでいることが保証されます。
- 継続的な統合と、ペアによって行われたすべての変更セットのテストの即時実行により、次のことが保証されます-
- 100％テストに合格した場合に新しいコードが機能すること、または
- テストが失敗した場合、そのペアのコードがシステムに失敗しているため、変更をすぐに元に戻し、実装している機能を明確にしたコーディングでペアを新たに開始できます。
- 短いリリースにより、顧客がテストを実行してフィードバックを提供するために、稼働中のシステムが使用可能になります。
- オンラインのお客様は、すべてのテストを実行し、稼働中のシステムですぐにフィードバックを提供する時間があります。
- プランニングゲームでは、テスト後に顧客からフィードバックを受け取り、次のリリースの計画を立てます。
したがって、開発者と顧客はテストを作成します。 さらに、残りのエクストリームプログラミングの動作を確認するために、テストが自動化されています。
リファクタリング-他のXPプラクティスからのサポート
リファクタリング-欠点
システムの設計を常に*リファクタリング*することはできません。 それだろう-
- 時間がかかりすぎる。
- コントロールするのが難しすぎる
- おそらくシステムを破壊します。
他のXPプラクティスによるリファクタリング
他のXPのプラクティスは、次の方法でリファクタリングをサポートしています-
- 集団所有権を使用すると、必要な場所に変更を加えることができます。
- コーディング標準を使用すると、リファクタリングする前に再フォーマットする必要がありません。
- ペアプログラミングを使用すると、困難なリファクタリングに取り組む勇気を持つことができます。
- シンプルなデザインで、リファクタリングは簡単です。
- 比phorを使用すると、簡単に通信できます。
- テストを行うと、知らないうちに何かを壊す可能性が低くなります。
- 継続的インテグレーションを使用すると、誤って何かを壊したり、リファクタリングが他の人の作業と競合したりした場合、数時間で知ることができます。
- 週40時間で休むことができるため、勇気が増し、間違いを犯す可能性が低くなります。
したがって、あなたは機会を見るたびに*リファクタリングすることができます-
- システムをシンプルにする
- 重複を減らす
- より明確にコミュニケーションする
ペアプログラミング–他のXPプラクティスからのサポート
ペアプログラミング-弱点
すべてのコードをペアで記述することはできません。 遅すぎるでしょう。 二人がうまくいかないと状況が難しくなります。
プログラミングを他のXPプラクティスと組み合わせます。
他のXPのプラクティスは、次の方法でペアプログラミングをサポートしています-
- コーディング標準は競合を減らします。
- 40時間の作業により、誰もが新鮮で集中力があり、不必要な議論の機会がさらに減ります。
- ペアは一緒にテストを記述し、実装部分に取り組む前に理解を調整する機会を与えます。
- メタファーは、ペアが命名と基本設計に関する決定を下すのに役立ちます
- シンプルなデザインにより、ペアは共通の理解を持つことができます。
- リファクタリングは、システムをシンプルにするために、ペアが話し合って決定を下すのに役立ちます。
- 継続的インテグレーションは、ペアに間違いがあった場合に修正する機会を提供するため、相手が何らかの実験を行っても相手は反対しません。
- 集団所有権により、チームは混合して一致させ、友好的な関係を維持することができます。
したがって、すべてのコードをペアで作成できます。 一方、チームが単独で作業している場合、彼らは間違いを犯しやすくなり、他のプラクティスを過剰設計し、見落とします。
集団所有権-他のXPプラクティスからのサポート
集団所有権-欠点
システム内のどこかで誰もが何かを変更することはできません。 なぜなら、システムを知らないうちに壊す可能性があり、統合のコストが劇的に上昇するからです。
他のXPプラクティスとの共同所有権
他のXPプラクティスは、以下の方法で集団所有権をサポートします-
- 継続的な統合により、競合の可能性が減少します。
- テストは、誤って物を壊す可能性を減らします。
- ペアプログラミングを使用すると、コードが破損する可能性が低くなり、開発者は収益性の高い変更をすばやく学習できます。
- コーディング標準を使用すると、コードで競合が発生しなくなります。
- リファクタリングを使用すると、誰もが理解できるようにシステムをシンプルに維持できます。
したがって、システム内の任意の場所でコードを変更する機会があれば、誰でもコードを変更できます。 一方、集合的な所有権がないと、設計の進化の速度は劇的に遅くなります。
継続的インテグレーション-他のXPプラクティスからのサポート
継続的インテグレーション-欠点
統合に時間がかかり、競合や偶然何かを壊す可能性が多すぎるため、わずか数時間の作業で統合することはできません。
他のXPプラクティスとの継続的な統合
他のXPプラクティスは、次の方法で継続的統合をサポートしています-
- テストをすばやく行うことで、何も破損していないことを知ることができます。
- ペアプログラミングでは、統合する変更のストリームが半分になります。
- リファクタリングでは、ピースが小さくなり、競合の可能性が減ります。
- コーディング標準を使用すると、コードの一貫性が保たれます。
- 短いリリースにより、システムに関する即時のフィードバックが保証されます。
- 集合的な所有権により、コードを変更して統合する人がシステム全体を見ることができます。
したがって、数時間後に統合できます。 一方、迅速に統合しないと、競合の可能性が高まり、統合のコストが急激に上昇します。
40時間の週–他のXPプラクティスからのサポート
40時間の週–欠点
あなたはおそらく40時間の週に働くことはできません。 40時間で十分なビジネス価値を生み出すことはできません。
他のXPプラクティスを含む40時間の週
他のXPプラクティスでは、次の方法で週40時間をサポートしています-
- 計画ゲームは、より価値のある作業を提供します。
- 計画ゲームとテストの組み合わせにより、考えていることだけに取り組む必要があります。
- シンプルな設計とリファクタリングにより、時間通りに集中して完了できます。
- ペアプログラミングは、他の作業をパートナーと共有して、できることを実行するのに役立ちます。
- 全体としてのプラクティスは、最高速度での開発に役立つため、これ以上速くなることはできません。
したがって、40時間の週で十分なビジネス価値を生み出すことができます。 一方、チームが新鮮でエネルギッシュなままでいなければ、残りのプラクティスを実行することはできません。
オンサイトのお客様–他のXPプラクティスからのサポート
オンサイトのお客様–欠点
チームに実際の顧客をフルタイムで配置することはできず、価値を生み出すことはできません。 彼らは、他の場所のビジネスにとってより大きな価値を生み出すことができます。
オンサイトのお客様と他のXPプラクティス
他のXPプラクティスは、次の方法でオンサイト顧客をサポートします。
彼らはプロジェクトの価値を生み出すことができます-
- Planning Gameで、開発者の優先度とスコープを決定します。
- Metaphorを使用すると、ドメインの開発者に明確さをもたらします。
- テストでは、受け入れテストを作成し、短いリリースごとに受け入れテストを実行します。
したがって、彼らはプロジェクトに貢献することにより、組織により多くの価値を生み出すことができます。
コーディング標準–他のXPプラクティスからのサポート
コーディング標準–欠点
開発者は通常個人主義的であるため、チームに共通の標準にコーディングするように依頼することはできません。
他のXPプラクティスとコーディング標準
他のXPプラクティスは、次の方法でコーディング標準をサポートしています-
- ペアプログラミングにより、必要なコーディング標準に簡単に適合させることができます。
- 継続的インテグレーションは、コードの一貫性を保つために標準に準拠するよう強制します。
- 集団所有権は、必要に応じて必要なときに変更を加えるために、標準に準拠することを奨励します。
