極端なプログラミング技術と原則

Extreme Programming（XP）は、柔軟なソフトウェア開発手法の1つです。 方法論の著者は、ケントベック、ワードカニンガム、マーティンファウラーなどです。

計画のゲーム

私たちの世界は不安定で予測不可能であり、状況の不変に頼ることはできません。 ソフトウェアの開発でも同じことが起こります。まれなシステムについては、開発の最初の段階で最終的な形式が詳細に知られていました。 通常、顧客の食欲は食事に付随します。彼は常に何かを変え、何かを改善し、システムから何かを捨てることを常に望んでいます。 これは、誰もが恐れている要件のばらつきです。 幸いなことに、人には可能な選択肢を予測する能力が与えられているため、状況をコントロールできます。

極端なプログラミングでは、計画は開発の不可欠な部分であり、計画を変更できるという事実は最初から考慮されています。 支点は、状況を予測し、痛みを伴わずに変化に耐えることができる技術であり、計画のゲームです。 このようなゲーム中に、既知のシステム要件をすばやく収集し、優先度に従って開発を評価および計画できます。

他のゲームと同様に、計画には参加者とその目標があります。 キー数値は、もちろん顧客です。 特定の機能の必要性を報告するのは彼です。 プログラマーは各機能の評価を示します。 計画のゲームの美しさは、開発者と顧客の間の目的と連帯の一致にあります。勝利の場合、誰もが勝ち、敗北の場合、誰もが負けます。 しかし、同時に、各参加者はそれぞれ独自の方法で勝利します。顧客は予算に従って最も重要なタスクを選択し、プログラマは実装の能力に従ってタスクを評価します。

極端なプログラミングでは、開発者が自分のタスクにどれだけの時間を費やし、そのうちの1つと他の問題を解決する意思があるかを自分で決定できると想定しています。

理想的な状況では、次の開発イテレーションが始まる前に、3〜6週間ごとに顧客とプログラマーが関与する計画ゲームを開催する必要があります。 これにより、前回の反復の成功と失敗に応じて簡単に調整できます。

リリース計画

リリース計画では、リリース日と、それぞれに具体化されるユーザーの文言を定義します。 これに基づいて、次の反復の文言を選択できます。 反復中に、プログラムの正しい動作を確認するために、この反復および後続のすべてで実行される受け入れテストが行​​われます。 いずれかの反復の前に大幅な遅れやリードがある場合、計画を修正できます。

繰り返し。 反復は、開発プロセスにダイナミズムを追加します。 ソフトウェアタスクを長期間計画する必要はありません。 代わりに、各反復の開始時に計画会議を手配してください。 計画されていないことを理解しようとさえしないでください。 リリース計画に沿ったアイデアになると、これらのアイデアを実装する時間があります。

事前に機能を追加しないことに慣れていて、直接計画を使用すると、顧客の変化する要件に簡単に適応できます。

反復計画

反復計画は、プログラムの問題を解決するためのステップの計画を作成するために、各反復の開始時に会議から始まります。 各反復は1〜3週間続きます。 反復内のステートメントは、顧客にとって重要な順にソートされます。 さらに、受け入れテストに合格できず、改善が必要なタスクが追加されます。 処方とテスト結果はソフトウェアタスクに変換されます。 タスクは、詳細な反復計画を形成するカードに書き込まれます。 各タスクを解決するには、1〜3日かかります。 1日未満しか必要としないタスクをグループ化し、大きなタスクをいくつかの小さなタスクに分割できます。 開発者は、実装のタスクと期限を評価します。 開発者がタスクを完了する時間を正確に設定することは非常に重要です。 3〜5回の反復ごとに、文言の一部を再評価し、リリース計画を改訂する必要がある場合があります-これは完全に受け入れられます。 主に最も重要な作業領域を実装している場合、顧客に最大限の時間をかけるための時間を常に確保できます。 一連の反復に基づく開発スタイルは、開発プロセスを改善します。

常設会議

問題とその解決策について話し合い、チームの集中力を高めるために、毎朝会議が開催されます。 この会議は、すべてのチームメンバーにとって面白くない長々とした議論を避けるために立って開催されます。

一般的な会議では、ほとんどの参加者は何も寄付せず、他の人の発言を聞くために参加します。 人々が少量のコミュニケーションを得るために費やす大きな時間。 したがって、会議へのすべての人々の参加は、プロジェクトからリソースを奪い、計画に混乱をもたらします。

この種のコミュニケーションには、定例会議が必要です。 ほとんどの開発者が出席する必要のある多くの長い会議よりも、短い強制会議を1回開催する方がはるかに優れています。

毎日定例会議を開催する場合、他のすべての会議には、必要で何かをもたらす人々のみが参加する必要があります。 さらに、いくつかの会議を回避することも可能です。 参加者が限られているため、ほとんどの会議はモニターの前で自発的に開催することができ、そこでは意見交換がより激しくなります。

毎日の朝の会議は時間の無駄ではありません。 これにより、他の多くの会議を避け、必要以上の時間を節約できます。

シンプルさ

シンプルなデザインは、常に複雑なデザインよりも時間がかかりません。 したがって、常に機能する最も単純なことを実行してください。 多くの時間を費やす前に、すぐに複雑なコードをすぐに置き換える方が常に速くて安価です。 計画する前に機能を追加せずに、できる限りシンプルに保ちます。 留意してください：デザインをシンプルに保つことは大変な作業です。

メタファーシステム

クラスとメソッドに名前を付けるときに、チームを同じフレームワーク内に維持するには、メタファーシステムの選択が必要です。 オブジェクトに名前を付ける方法は、システム全体の設計を理解し、コードを再利用するために非常に重要です。 開発者が既存のオブジェクトにどのように名前を付けることができるかを正しく予測できる場合、これにより時間を節約できます。 システムの特定の知識がなくても誰もが理解できるオブジェクトのネームシステムを使用します。

現場の顧客

ソフトウェア開発の主な問題は、開発された主題分野のプログラマーの知識の欠如です。 極端なプログラミングは、この状況から抜け出す方法を見つけました。 いいえ、これは顧客の企業での研修生のインターンシップではありません。その場合、彼はプログラムしたくないでしょう。 それどころか、これは開発プロセスへの顧客の参加です。

プログラマーは、問題の本質を完全に理解せずに、テレパシストでなくても、顧客が何を望んでいるかを推測できますか？ 答えは明らかです。 この不便さを克服する最も簡単な方法-そして極端なプログラミングは、最も簡単な解決策を見つけることを教えてくれます-顧客に直接質問をします。 より厳密なアプローチでは、開発エリアの包括的な予備分析が必要です。 特定のケースでは、これは正当化されますが、より高価です。 ありふれたプロジェクトを実施した実際の経験は、すべての要件を事前に収集することは不可能であることを示しています。 さらに、すべての要件が現在収集されていると仮定しても、1つのボトルネックが依然として存在します。プログラムは、自然界のあらゆるものと同様に、すぐには作成されません。 これを考慮する必要があります。

多くの人は、顧客を開発プロセスに引き付ける可能性を疑っています。 実際、顧客は異なります。 顧客またはその代理人を引き付けることができない場合は、開発された分野の専門家を一時的に雇うことをお勧めします。 このようなステップは、作業の不確実性を減らし、開発の速度を上げ、プロジェクトを顧客が望むものに近づけます。 これは財政的な観点から有益です。結局のところ、プログラマーの報酬は他の業界の専門家の給与を大幅に上回ることがあります。

ユーザーストーリー。 ユーザーストーリー（ユーザーストーリーのようなもの）は、システムの動作方法の説明です。 各ユーザーストーリーはカードに書き込まれ、顧客の観点から論理的に意味のあるシステム機能の一部を表します。 フォームは、ユーザーが理解できるテキストの1つまたは2つの段落です（あまり技術的ではありません）。

ユーザーストーリーはお客様が作成します。 これらはシステム使用シナリオに似ていますが、ユーザーインターフェイスに限定されません。 機能テストはストーリーごとに作成され、ストーリーが正しく実装されていることを確認します-受け入れテストとも呼ばれます。

開発前のテスト

テストは、その古典的な意味では、かなり退屈な手順です。 通常、彼らは定期的に同じアクションを実行し、彼が最終的に別のポジションに移されるか、仕事を変える機会がある日を待つテスターを雇います。

極端なプログラミングでは、テストの役割はより興味深いものになります。テストが最初になり、次にコードが始まります。 まだ何がテストされていないのですか？ 答えはシンプルでありふれたものです。自分の考えをテストします-将来のプログラムや機能に期待すること。 これにより、プログラマーが何をする必要があるかをよりよく理解し、コードが書かれてすぐに機能することを確認することができます。

しかし、テストも機能しない場合があります。 さて、テスト用のテストを作成しますか？ そして、テストなどのテストは無限に続きますか？ まったくありません。 テストをテストすると、コードが置き換えられます。 どうして？ しかし、見てください：ナットが回らないように、ボルトの真ん中にナットを固定する必要があると想像してください。 彼らはこれのために何をしていますか？ 2番目のナットを最初のナットの近くにねじ込み、各ナットが隣のナットを回転させないようにします。 プログラミングでは、テストはコードをテストし、コードはテストをテストします。

経験から、このアプローチは速度を落とすだけでなく、開発を加速することもわかっています。 実際、何をする必要があるか、および必要な作業量を知ることで、現時点では主張されていない部品の実装を放棄することで時間を節約できます。

ペアプログラミング

実動システムのすべてのコードはペアで作成されます。 2人の開発者が並んで座っています。 1つは入力、もう1つは探しています。 それらは時々変わります。 一人で働くことはできません。 何らかの理由で2番目のカップルが何かを見逃した場合（彼は病気であった、立ち去ったなど）、彼は最初のカップルによって行われたすべての変更を確認する義務があります。

それは異常に聞こえますが、適応の短い期間の後、ほとんどの人はペアで素晴らしい仕事をします。 作業がはるかに高速に行われるため、彼らも気に入っています。 「1つの頭は良いが、2つの頭は良い」という原則。 カップルは通常、より良い解決策を見つけます。 さらに、コードの品質が大幅に向上し、エラーの数が減少し、開発者間の知識の交換が加速されます。 1人がオブジェクトの戦略的アイデアに焦点を当てている間、2人目はそのプロパティとメソッドを実装します。

位置変更

次の反復では、すべてのワーカーを新しい作業エリアに移動する必要があります。 このような動きは、知識の孤立を避け、「ボトルネック」を排除するために必要です。 特に実り多いのは、開発者の1人をペアプログラミングに置き換えることです。

集団コードの所有権

集合的なコードの所有権により、開発者はモジュールだけでなくプロジェクトのすべての部分についてアイデアを提出することができます。 開発者は、コードを変更して機能を拡張し、バグを修正できます。

一見カオスのように見えます。 ただし、少なくとも任意のコードが数人の開発者によって作成されたこと、テストにより変更の正確性を確認できること、実際に他の誰かのコードを理解する必要があることを考慮すると、コードの集合的な所有権により大幅に変更が簡単になり、チームメンバーの高い専門性に関連するリスクを軽減します。

コーディング契約

あなたはこのプロジェクトに長い間取り組んでいるチームにいます。 人々は行き来します。 誰もが単独でエンコードすることはなく、コードは全員のものです。 他の人のコードを理解して修正する必要がある場合が常にあります。 開発者は、重複するコードを削除または変更し、他の人々のクラスを分析および改善します。 時間の経過とともに、特定のクラスの作成者が誰であるかを言うことはできなくなります。

したがって、誰もが一般的なコーディング標準（コードの書式設定、クラスの命名、変数、定数、コメントスタイル）に従う必要があります。 したがって、他の誰かのコードに変更を加えることは（積極的かつ極端な進歩に必要です）確実にバベルバベルに変えることはありません。

上記は、すべてのチームメンバーが共通のコーディング標準に同意する必要があることを意味します。 どんなに。 ルールは、誰もが従うことです。 彼らに従うことを望まない人々は、チームを去ります。

頻繁な統合

開発者は可能な限り、数時間ごとにコードを統合してリリースする必要があります。 いずれの場合でも、変更を1日より長く保持しないでください。 頻繁に統合することで、開発者がアイデアを交換したりコードを再利用したりするという意味でコミュニケーションをとることができない場合、開発における疎外と断片化を回避できます。 誰もが最新バージョンで作業する必要があります。

開発者の各ペアは、合理的な機会が生じたらすぐに独自のコードを提供する必要があります。 これは、すべてのUnitTestが100％に合格した場合です。 1日に数回変更を送信することにより、統合の問題をほぼゼロに減らすことができます。 統合は、「今すぐ支払う、または後で支払う」タイプのアクティビティです。 そのため、変更を毎日少しずつ統合することで、プロジェクトを実施する直前に1週間かけてシステムを1つの全体にバインドする必要がなくなります。 常に最新バージョンのシステムで作業してください。

週40時間労働

特にプログラマーである人は、仕事のために多くのことができます：仕事にとどまる、週末に仕事に行く、休暇をあきらめる、キーボードに座って数日間目を覚ます...一般的に、あなたが好きな職業のためにできないこと。 しかし、極端なプログラミングは、そのような自己犠牲と労働法の容認された規範の違反に断固として反対しています。

これは、合法性と人間性の考慮だけでなく、まず第一に、作業効率と厳格な組織を改善する必要性によって決定されます。 結局のところ、極端なプログラミングは個人向けではなく、グループ全体向けに設計された集合ゲームです。 そして、例えばペアプログラミングなどは、参加者のバイオリズムの同期によってのみ可能です。 そして、1人が9時に働き、2人目が12時に働き、土曜日と日曜日に働くほうが良いと判断し、もう1人が不快である場合は不可能です。

しかし、最も重要なことは、人が健康と作業能力を維持するために十分な休息をとる必要があるということです。 生産性を最大限に高めるため、8時間の稼働日と5日間の稼働日が正確に設定されています。 多くの欧米の企業では、仕事からの遅い出発は、劣悪な進歩または仕事時間を適切に管理できないとみなされています。 ほとんどの場合、これは事実です。 また、医療の観点から見ると、仕事の遅れは絶え間ない疲労、いらいら、脳活動の低下につながります。 本当に効果的ですか？ そして、そのようなチームの開発者間の絶え間ないオープンなコミュニケーションをどのように編成し、ペアプログラミングは可能ですか？ 答えはノーです。 規範は規範であり、遵守する必要があります。

おわりに

これらの手法は、理由のためにまとめられていません。 それらの一貫した組み合わせにより、開発プロセスを知的共鳴に導入し、製品の品質を大幅に向上させ、リリース時間を短縮することができます。 すべての極端なプログラミングの主な魅力は、予測可能性と開発コストの最小化です。 リリース時に受け取りたい製品を顧客に提供する。 そしてもちろん、実地でのコミュニケーションと開発者のトレーニング。



使用された文献のリスト：

• ウィキペディア
• エクストリームプログラミング/ C. Auer、R. Miller-サンクトペテルブルク：Peter、2004 .-- 368 pp。、Ill。