Extreme-programming-practices
エクストリームプログラミング-プラクティス
エクストリームプログラミングには4つの基本的なアクティビティがあります。 彼らは-
- コーディング
- テスト
- 聞いている
- 設計中
これらの4つの基本的なアクティビティは、エクストリームプログラミングの原則に照らして構成する必要があります。 これを達成するために、エクストリームプログラミングのプラクティスが定義されています。
これらの12のエクストリームプログラミングプラクティスは、エクストリームプログラミングの目的を達成し、プラクティスの1つが弱い場合でも、他のプラクティスの長所がそれを補います。
「Extreme Programming Explained」の著者であるKent Beckは、次のように12のExtreme Programmingプラクティスを定義しました-
- 計画ゲーム
- ショートリリース
- 比phor
- シンプルなデザイン
- テスト
- リファクタリング
- ペアプログラミング
- 集団所有権
- 継続的インテグレーション
- 週40時間
- オンサイト顧客
- コーディング標準
極端なプログラミングの4つの領域
エクストリームプログラミングの実践は、4つの領域に分類することができます-
- 迅速で細かいフィードバック-
- テスト
- オンサイト顧客
- ペアプログラミング
- 連続プロセス-
- 継続的インテグレーション
- リファクタリング
- ショートリリース
- 共有理解-
- 計画ゲーム
- シンプルなデザイン
- 比phor
- 集団所有権
- コーディング標準
- 開発者の福祉-
- 40時間の週
この章では、エクストリームプログラミングプラクティスの詳細と、これらの各プラクティスの利点を理解します。
エクストリームプログラミングプラクティスの概要
次の図は、エクストリームプログラミングのプラクティスにエクストリームプログラミングが織り込まれている様子を示しています-
計画ゲーム
極端なプログラミングにおける主な計画プロセスは、計画ゲームと呼ばれます。 ゲームは、反復ごとに1回、通常は1週間に1回開催される会議です。 プランニングゲームでは、ビジネスの優先順位と技術的な見積もりを組み合わせて、次のリリースの範囲をすばやく決定します。 現実が計画を追い越すように、計画を更新します。
ビジネスと開発は、同時に決定を下す必要があります。 ビジネス上の決定と開発の技術的な決定は、互いに整合する必要があります。
ビジネスの人々は約決定する必要があります-
- 範囲-システムが本番で価値があるためにはどの程度の問題を解決する必要がありますか？ ビジネスマンは、どれだけが十分ではないか、どれだけが多すぎるかを理解する立場にあります。
- 優先度-オプションが与えられた場合、どのオプションが必要ですか？ ビジネスパーソンは、顧客からのインプットを持つ開発者以上に、これを決定する立場にあります。
- リリースの構成-ソフトウェアを使用しない場合よりも、ソフトウェアを使用した場合の方がビジネスを改善するために必要な作業はどれくらいですか。 この質問に関する開発者の直感は、非常に間違っている可能性があります。
- リリースの日付-ソフトウェア（またはソフトウェアの一部）の存在が大きな違いを生む重要な日付は何ですか？
技術者は約決定する必要があります-
- 見積もり-機能の実装にはどれくらい時間がかかりますか？
- 結果-技術的な結果について通知された場合にのみ行うべき戦略的ビジネス決定があります。 開発は結果を説明する必要があります。
- プロセス-仕事とチームはどのように編成されますか？ チームは、運営する文化に適合する必要があります。 ソフトウェアは、包囲する文化の非合理性を保持するのではなく、適切に作成する必要があります。
- 詳細なスケジューリング-リリース内で、どのストーリーを最初に行うべきですか？ 開発者は、プロジェクトの全体的なリスクを軽減するために、開発の最もリスクの高いセグメントを最初にスケジュールする自由が必要です。 その制約内で、彼らはまだ開発の早い段階でビジネスの優先順位を移動する傾向があり、時間の制約のためにリリースの開発の終わりに向かって重要なストーリーを落とさなければならない可能性を減らします。
したがって、計画は、顧客、ビジネスマン、開発者の間のコラボレーションの結果です。
プランニングゲーム-利点
計画ゲームには次の利点があります-
- 時間の短縮、無駄な機能の無駄遣い
- 機能のコストに対する顧客の評価の向上
- 計画の当て推量が少ない
ショートリリース
簡単なシステムを本稼働に迅速に投入し、非常に短いサイクルで新しいバージョンをリリースする必要があります。 すべてのリリースはできるだけ小さくする必要がありますので、
- 短いサイクルで達成可能
- 最も価値のある即時のビジネス要件が含まれています
- 稼働中のシステム
短いサイクルの期間は、構築する必要のあるソフトウェアによって異なる場合があります。 ただし、可能な最小の期間が選択されていることを確認する必要があります。
短期リリース–利点
ショートリリースの利点は次のとおりです-
- 頻繁なフィードバック
- 追跡
- プロジェクト全体のずれの可能性を減らす
比phor
ケンブリッジのオンライン辞書によると、メタファーは、人や物に似た特徴があると考えられる何かを参照することで、その人や物を説明する文献でよく見られる表現です。 たとえば、「心は海」と「都市はジャングル」はどちらも比Metaです。
システム全体がどのように機能するかについての簡単な共有ストーリーで開発全体をガイドする必要があります。 メタファーは、開発に関わるすべての人が簡単に理解できるように構築されるシステムのアーキテクチャと考えることができます。
比phorは、ドメイン固有の要素で構成され、それらの相互接続性を示しています。 使用される言語はドメイン言語です。 技術的実体を識別するには、比metaで使用される単語を一貫して使用する必要があります。
開発が進み、メタファーが成熟するにつれて、チーム全体がメタファーを調べることから新しいインスピレーションを見つけます。
優れたアーキテクチャの目標は、働く全員に一貫したストーリーを提供することであり、ビジネスと技術の両方のメンバーが簡単に共有できるストーリーです。簡単にコミュニケーションをとることができるアーキテクチャを手に入れましょう。
比phor –利点
メタファーの利点は-
- システムの共通の用語セットを奨励する
- バズワードと専門用語の削減
- システムをすばやく簡単に説明する方法
シンプルなデザイン
システムは、可能な限り単純に設計する必要があります。 余分な複雑さは、発見されるとすぐに削除されます。
いつでもソフトウェアの適切な設計は、それが-
- すべてのテストを実行します
- 並列クラス階層のような重複したロジックはありません
- 開発者にとって重要なあらゆる意図を述べる
- 可能な限り少ないクラスとメソッドを持っています
シンプルなデザインを取得するには、最初の3つのルールに違反することなく、できる限りデザイン要素を削除します。 これは、今日の実装、明日の設計というアドバイスとは正反対です。 将来が不確実であり、設計を迅速に強化できると思われる場合は、推測に機能を追加しないでください。
シンプルなデザイン-利点
シンプルなデザインの利点は-
- 余分な機能を追加することで時間を無駄にしない
- 何が起こっているかを理解しやすい
- リファクタリングと集団所有権が可能になります
- プログラマーを軌道に乗せるのに役立ちます
テスト
開発者は継続的に単体テストを作成しますが、開発を継続するには合格する必要があります。 顧客は、機能が実装されていることを確認するテストを作成します。 テストは自動化されているため、システムの一部となり、システムの動作を保証するために継続的に実行できます。 結果は、変更を受け入れることができるシステムです。
テスト–利点
テストの利点は-
- 単体テストはテストの完全性を促進します
- テストファーストは開発者に目標を与えます
- 自動化は一連の回帰テストを提供します
リファクタリング
機能を実装するとき、開発者は常に、既存のコードを変更して機能の追加を簡単にする方法があるかどうかを尋ねます。 機能を追加した後、開発者は、すべてのテストを実行しながらコードを簡単にする方法を確認できるかどうかを尋ねます。 動作を変更せずにシステムを再構築して、重複の除去、通信の改善、単純化、または柔軟性の追加を行います。 これはリファクタリングと呼ばれます。
リファクタリング-利点
リファクタリングの利点は次のとおりです-
- 開発者に、製品全体を積極的に改善するよう促します
- システムの開発者の知識を増やします
ペアプログラミング
ペアプログラミングでは、1つのマシンで2人の開発者と1つのキーボードと1つのマウスでコード全体が記述されます。
各ペアには2つの役割があります-
- 最初の開発者（キーボードとマウスを使用する開発者）は、このメソッドをここで実装する最良の方法を考えています。
- 他の開発者はより戦略的に考えています
- このアプローチ全体が機能しますか？
- まだ機能しない可能性のある他のテストケースは何ですか？
- システム全体を単純化して、現在の問題を解消する方法はありますか？
ペアリングは動的です。 これは、2つのロールAとBが場所を交換したり、他のチームメンバーとペアになったりすることを意味します。 多くの場合、チームの誰もがパートナーとして行います。 たとえば、あなたが不慣れなエリアのタスクに責任がある場合、最近の経験のある人にあなたとペアリングするように頼むかもしれません。
ペアプログラミング-利点
ペアプログラミングの利点は次のとおりです-
- 2つのヘッドは1つよりも優れています
- フォーカス
- 二人は、次の質問に答える可能性が高くなります-
- このアプローチ全体が機能しますか？
- まだ機能しない可能性のあるテストケースは何ですか？
- これを簡素化する方法はありますか？
集団所有権
Extreme Programmingでは、チーム全体がシステム全体の責任を負います。 誰もがすべての部分について同じようによく知っているわけではありませんが、誰もがすべての部分について何かを知っています。
ペアが機能していて、コードを改善する機会を見つけた場合、先に進んで改善します。
集団所有権–利点
集団所有権の利点は-
- 退出するチームメンバーの損失を軽減するのに役立ちます。
- システムの一部ではなく、システム全体の責任を取るように開発者を促進します。
継続的インテグレーション
コードは1日に何度も統合およびテストされ、一度に1セットの変更が行われます。 これを行う簡単な方法は、統合専用のマシンを用意することです。 統合する準備ができているコードとのペア-
- マシンが空いているときに座っています。
- 現在のリリースをロードします。
- 変更をロードします（衝突をチェックして解決します）。
- 合格するまでテストを実行します（100％正しい）。
一度に1セットの変更を統合すると、失敗したテストを誰が修正すべきかを知るのに役立ちます。 最後のペアはテストを100％のままにしていたため、答えは現在のペアです。 彼らは、その機能をコーディングするのに十分なことを知らなかったかもしれないので、彼らがしたことを捨てて、最初からやり直さなければならないかもしれません。
継続的インテグレーション–利点
継続的インテグレーションの利点は次のとおりです-
- 期間を短縮します。それ以外の場合は長くなります。
- リリース前に必要な時間が最小限であるため、短いリリースのプラクティスを有効にします。
40時間の週
エクストリームプログラミングは、持続可能性に基づいて、週に最大45時間まで、チームメンバー全員の週あたりの作業時間が限られていることを強調しています。 誰かがそれよりも長い時間働く場合、それは残業と見なされます。 残業は最大1週間許可されます。 このプラクティスは、すべてのチームメンバーが新鮮で、創造的で、慎重かつ自信を持てるようにすることです。
40時間の週–利点
週40時間の利点は-
- ほとんどの開発者は、40時間で有効性を失います。
- 開発者の幸福に価値が置かれます。
- 管理者は実際のソリューションを見つけることを余儀なくされています。
オンサイトのお客様
チームの実在のライブユーザーを含め、質問に答え、紛争を解決し、小規模な優先順位を設定するためにフルタイムで利用できます。 このユーザーは、この役割だけに40時間を費やす必要はなく、他の作業にも集中できます。
オンサイトのお客様–利点
オンサイトの顧客を持つことの利点は-
- 開発に関する実際の質問にすばやく知識豊富な回答を提供できます。
- 開発されたものが必要なものであることを確認します。
- 機能が正しく優先順位付けされます。
コーディング標準
開発者は、ルールを重視してすべてのコードを記述し、
- コードを介した通信。
- 最小限の作業。
- 「1回だけ」ルールと一致（重複コードなし）。
- チーム全体による自発的な採用。
これらのルールは、すべての開発者がエクストリームプログラミングで必要です-
- システムのある部分からシステムの別の部分に変更できます。
- パートナーを1日に数回交換します。
- 互いのコードを常にリファクタリングします。
ルールに従わない場合、開発者はさまざまなコーディング手法を使用する傾向があり、時間の経過とともにコードの一貫性が失われ、チームの誰がどのコードを書いたかを言うことができなくなります。
コーディング標準–利点
コーディング標準の利点は-
- 開発者が他の人のコードの再フォーマットに費やす時間を削減します。
- 内部コメントの必要性を減らします。
- 明確で明確なコードを要求します。
