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

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

エクストリームプログラミング XP)は、ソフトウェアプロジェクトの実装に使用されるアジャイルソフトウェア開発手法です。この記事では、この方法論で使用される方法について詳しく説明します。エクストリームプログラミングには、ソフトウェアエンジニアリングのベストプラクティスから導き出された、4つの領域にグループ化された12のプラクティス[1]

ファインスケールフィードバック

ペアプログラミング

ペアプログラミングとは、すべてのコードが、1つのワークステーションで1つのタスクをプログラミングする2人の人間によって生成されることを意味します。1人のプログラマーがワークステーションを制御し、主にコーディングについて詳細に考えています。他のプログラマーは全体像に焦点を合わせており、最初のプログラマーによって作成されているコードを継続的にレビューしています。プログラマーは、分から時間の期間の後に役割を交換します。

ペアは固定されていません。プログラマーは頻繁にパートナーを切り替えるので、誰もが何をしているのかを知ることができ、スキルセット以外の部分も含めて、システム全体に精通していることができます。このように、ペアプログラミングはチーム全体のコミュニケーションを強化することもできます。(これは、集団所有権の概念とも密接に関連しています)。

企画ゲーム

エクストリームプログラミング内の主な計画プロセスは、計画ゲームと呼ばれます。ゲームは、反復ごとに1回、通常は週に1回行われる会議です。計画プロセスは2つの部分に分かれています。

  • リリース計画:これは、どの要件がどの短期リリースに含まれるか、およびそれらをいつ配信する必要があるかを決定することに焦点を当てています。顧客と開発者の両方がこの一部です。リリース計画は、次の3つのフェーズで構成されます。
    • 調査フェーズ:このフェーズでは、お客様はシステムの価値の高い要件の候補リストを提供します。これらはユーザーストーリーカードに書き留められます。
    • コミットメントフェーズ:コミットメントフェーズ内で、ビジネスと開発者は、含まれる機能と次のリリースの日付にコミットします。
    • ステアリングフェーズ:ステアリングフェーズでは、計画を調整したり、新しい要件を追加したり、既存の要件を変更または削除したりできます。
  • 反復計画:これは、開発者の活動とタスクを計画します。このプロセスでは、顧客は関与しません。反復計画も3つのフェーズで構成されます。
    • 探索フェーズ:このフェーズでは、要件がさまざまなタスクに変換されます。タスクはタスクカードに記録されます。
    • コミットメントフェーズ:タスクはプログラマーに割り当てられ、完了するまでにかかる時間が見積もられます。
    • ステアリングフェーズ:タスクが実行され、最終結果が元のユーザーストーリーと一致します。

計画ゲームの目的は、製品を納品に導くことです。成果物が必要になり、作成される正確な日付を予測するのではなく、簡単なアプローチを使用して「プロジェクトを誘導」して配信することを目的としています。[2]計画ゲームのアプローチは、ビジネスの俊敏性の観点から、ソフトウェア以外のプロジェクトやチームでも採用されています。[3]

リリース計画

探索フェーズ

これは、要件を収集し、それらの各要件の作業への影響を見積もる反復プロセスです。

  • ストーリーを書く:ビジネスには問題があります。会議中に、開発者はこの問題を定義し、要件を取得しようとします。ビジネス上の問題に基づいて、ストーリー(ユーザーストーリー)を作成する必要があります。これはビジネスによって行われ、システムの一部に何をさせたいかを指摘します。開発がこのストーリーに影響を与えないことが重要です。ストーリーはユーザーストーリーカードに書かれています。
  • ストーリーの見積もり:開発では、ストーリーカードによって示される作業を実装するのにかかる時間を見積もります。開発は、問題を分析または解決するためのスパイクソリューションを作成することもできます。これらのソリューションは見積もりに使用され、問題が明確に視覚化されると破棄されます。繰り返しますが、これはビジネス要件に影響を与えない場合があります。
  • ストーリーの分割:反復計画を開始する前に、すべての設計上の重要な複雑さに対処する必要があります。開発者がストーリーを見積もることができない場合は、ストーリーを分割して書き直す必要があります。

ビジネスがこれ以上要件を考え出すことができない場合、コミットメントフェーズに進みます。

コミットメントフェーズ

このフェーズには、コスト、メリット、およびスケジュールへの影響の決定が含まれます。これには4つのコンポーネントがあります。

  • 値で並べ替え:ビジネスは、ユーザーストーリーをビジネス値で並べ替えます。
  • リスクで並べ替え:開発では、ストーリーをリスクで並べ替えます。
  • Set Velocity:開発は、プロジェクトを実行できる速度を決定します。
  • スコープの選択:次のリリースで終了するユーザーストーリーが選択されます。ユーザーストーリーに基づいて、リリース日が決定されます。
値で並べ替え

ビジネス側は、ユーザーストーリーをビジネス価値で並べ替えます。彼らはそれらを3つの山に配置します:

  • 重要:システムが機能できない、または意味がないストーリー。
  • 重要なビジネス価値:重要なビジネス価値を持つ重要ではないユーザーストーリー。
  • ありがたいこと:重要なビジネス価値を持たないユーザーストーリー。
リスクで並べ替え

開発者は、リスク別にユーザーストーリーを並べ替えます。また、低リスク、中リスク、高リスクのユーザーストーリーの3つの山に分類されます。以下は、これに対するアプローチの例です。

  • リスクインデックスの決定:各ユーザーストーリーに、次の各要素について0から2までのインデックスを付けます。
    • 完全性(ストーリーの詳細をすべて知っていますか?)
      • 完了(0)
      • 不完全(1)
      • 不明(2)
    • ボラティリティ(変化する可能性がありますか?)
      • 低(0)
      • ミディアム(1)
      • 高(2)
    • 複雑さ(構築するのはどれくらい難しいですか?)
      • シンプル(0)
      • 標準(1)
      • 複雑な(2)

ユーザーストーリーのすべてのインデックスが追加され、ユーザーストーリーに低(0–1)、中(2–4)、または高(5–6)のリスクインデックスが割り当てられます。

ステアリングフェーズ

ステアリングフェーズ内で、プログラマーとビジネスマンはプロセスを「ステアリング」できます。つまり、彼らは変更を加えることができます。個々のユーザーストーリー、またはさまざまなユーザーストーリーの相対的な優先順位が変わる可能性があります。見積もりが間違っている可能性があります。これは、それに応じて計画を調整するチャンスです。

反復計画

計画するチーム速度のストーリーポイントを検討します。反復期間は1〜3週間です。

探索フェーズ

反復計画の調査フェーズは、タスクを作成し、それらの実装時間を見積もることです。

  • 要件をタスクに変換します。タスクカードに配置します。
  • タスクの結合/分割:タスクが小さすぎるか大きすぎるためにプログラマーがタスクを見積もることができない場合、プログラマーはタスクを結合または分割する必要があります。
  • タスクの見積もり:タスクの実装にかかる時間を見積もります。
コミットメントフェーズ

反復計画のコミットメントフェーズ内で、プログラマーにはさまざまなユーザーストーリーを参照するタスクが割り当てられます。

  • プログラマーはタスクを受け入れます。各プログラマーは、自分が責任を負うタスクを選択します。
  • プログラマーはタスクを見積もります:プログラマーは現在タスクに責任があるので、彼または彼女はタスクの最終的な見積もりを与える必要があります。
  • 負荷率の設定:負荷率は、1回の反復内でのプログラマーごとの実践的な開発時間の理想的な量を表します。たとえば、週40時間で、5時間が会議に費やされている場合、これは35時間以内になります。
  • バランシング:チーム内のすべてのプログラマーにタスクが割り当てられると、タスクの推定時間と負荷率が比較されます。次に、タスクはプログラマー間でバランスが取られます。プログラマーが過剰にコミットされている場合、他のプログラマーが自分のタスクの一部を引き継ぐ必要があり、その逆も同様です。
ステアリングフェーズ

タスクの実装は、反復のステアリングフェーズ中に実行されます。

  • タスクカードを取得する:プログラマーは、自分がコミットしたタスクの1つに対応するタスクカードを取得します。
  • パートナーを見つける:プログラマーは、別のプログラマーと一緒にこのタスクを実装します。これについては、ペアプログラミングの練習で詳しく説明します。
  • タスクの設計:必要に応じて、プログラマーはタスクの機能を設計します。
  • テスト駆動開発(TDD)を使用してタスクを実装します(以下を参照)
  • 機能テストの実行:機能テスト(関連するユーザーストーリーとタスクカードの要件に基づく)が実行されます。

テスト駆動開発

単体テストは、コードの一部(クラス、メソッドなど)の機能をテストする自動テストです。XP内では、単体テストは、最終的なコードがコーディングされる前に記述されます。このアプローチは、プログラマーが自分のコードが失敗する可能性のある条件について考えるように刺激することを目的としています。XPによると、プログラマーは、コードが失敗する可能性のあるそれ以上の条件を思い付くことができないときに、特定のコードを完成させるとのことです。

テスト駆動開発は、次のステップをすばやく循環することによって進行します。各ステップの所要時間は最大で数分、できればはるかに短くなります。各ユーザーストーリーは通常1〜2日の作業を必要とするため、ストーリーごとに非常に多くのそのようなサイクルが必要になります。

  • 単体テストの記述:プログラマーは、機能が実稼働コードに完全に実装されていないために失敗するはずの最小限のテストを記述します。
  • 新しいテストが失敗するのを監視します。プログラマーは、テストが実際に失敗することを確認します。時間の無駄に思えるかもしれませんが、この手順は、実動コードの状態に関する信念が正しいことを確認するために重要です。テストが失敗しない場合、プログラマーは、テストコードにバグがあるかどうか、または本番コードが新しいテストで記述された機能をサポートしているかどうかを判断する必要があります。
  • コードを書く:プログラマーは、新しいテストに合格するのに十分な本番コードを書きます。
  • テストの実行:単体テストを実行して、新しい製品コードが新しいテストに合格し、他のテストが失敗していないことを確認します。
  • リファクタリング:本番コードとテストコードの両方からコードの臭いを取り除きます。

上記のプロセスのより強力なバージョンについては、ボブおじさんのTDDの3つのルールを参照してください。[4]

チーム全体

XP内では、「顧客」は請求書を支払う人ではなく、実際にシステムを使用する人です。XPは、顧客は常に手元にいて、質問に対応できるようにする必要があると述べています。たとえば、財務管理システムを開発するチームには、財務管理者を含める必要があります。

連続処理

継続的インテグレーション

開発チームは、常に最新バージョンのソフトウェアに取り組んでいる必要があります。さまざまなチームメンバーがさまざまな変更や改善を加えてバージョンをローカルに保存している可能性があるため、数時間ごと、または重大な中断が発生したときに、現在のバージョンをコードリポジトリにアップロードするようにしてください。 継続的インテグレーションは、統合の問題によって引き起こされる、プロジェクトサイクルの後半での遅延を回避します。

デザインの改善

XPの教義は、今日必要なものだけをプログラミングし、それを可能な限り単純に実装することを提唱しているため、システムが動かなくなることがあります。この症状の1つは、デュアル(または複数)のメンテナンスの必要性です。機能の変更により、同じ(または類似の)コードの複数のコピーへの変更が必要になります。もう1つの症状は、コードの一部の変更が他の多くの部分に影響を与えることです。XPの教義によると、これが発生すると、システムはアーキテクチャを変更してコードをリファクタリングし、コードをよりシンプルで一般的なものにするように指示します。

小さなリリース

ソフトウェアの配信は、具体的な価値を生み出すライブ機能の頻繁なリリースを介して行われます。小さなリリースは、顧客がプロジェクトの進捗に自信を持てるようにするのに役立ちます。これにより、顧客は実際の経験に基づいてプロジェクトに関する提案を思い付くことができるため、チーム全体の概念を維持するのに役立ちます。

理解の共有

コーディング標準

コーディング標準は、開発チーム全体がプロジェクト全体で順守することに同意する一連の合意されたルールです。この規格では、選択したプログラミング言語内でのソースコードの一貫したスタイルと形式、および欠陥の可能性を減らすために回避する必要のあるさまざまなプログラミング構造とパターンが指定されています。[5] コーディング標準は、言語ベンダーによって指定された標準規則(たとえば、Sunが推奨するJavaプログラミング言語のコード規則)、または開発チームによって定義されたカスタムの場合があります。

エクストリームプログラミングの支持者は、可能な限り自己文書化するコードを提唱しています。これにより、コード自体と同期しなくなる可能性のあるコードコメントの必要性が減ります。[6]

集合的なコードの所有権

集合的なコード所有権(「チームコード所有権」および「共有コード」とも呼ばれます)は、すべてのコードに対して全員が責任を負うことを意味します。したがって、誰でもコードの任意の部分を変更できます。集合的なコードの所有権は、組織のポリシーであるだけでなく、感情でもあります。「開発者は、システムコンテキストを理解し、問題のコードに貢献し、コードの品質を高く認識し、製品がユーザーのニーズを満たし、チームの結束力が高いと感じたときに、チームコードの所有権をより感じます。」[7]ペアプログラミング、特にオーバーラップペアローテーションは、このプラクティスに貢献します。異なるペアで作業することにより、プログラマーはシステムコンテキストをよりよく理解し、コードベースのより多くの領域に貢献します。

エラーを見つけた開発者はすぐに修正できるため、コードの共同所有権によって開発が加速する可能性があります。これにより、全体的なバグを減らすことができます。ただし、プログラマーは、よく理解していないコードを変更するときにバグを導入することもあります。十分に明確に定義された単体テストは、この問題を軽減するはずです。予期しない依存関係によってエラーが発生した場合、単体テストを実行すると、失敗が表示されます。

集合的なコードの所有権は、メンバーのバックアップの改善、知識と学習の分散の向上、コードの責任の共有、コードの品質の向上、およびやり直しの削減につながる可能性があります。ただし、メンバーの競合の増加、バグの増加、開発者のメンタルフローの変更と推論の中断、開発時間の増加、またはコードの理解の低下につながる可能性もあります。[8]

シンプルなデザイン

プログラマーは、ソフトウェア設計に対して「シンプルが最善」のアプローチを取る必要があります。新しいコードを書くときはいつでも、作者は「同じ機能を導入するもっと簡単な方法はありますか?」と自問する必要があります。答えが「はい」の場合は、より単純なコースを選択する必要があります。複雑なコードを単純化するためにも、リファクタリングを使用する必要があります。

システムの比喩

システムの比喩は、顧客、プログラマー、マネージャーなど、誰もがシステムの仕組みについて語ることができる物語です。これはクラスとメソッドの命名概念であり、チームメンバーが特定のクラス/メソッドの機能をその名前だけから簡単に推測できるようにする必要があります。たとえば、ライブラリシステムはloan_records(class)forを作成しborrowers(class)、アイテムが期限切れになった場合は、に対してmake_overdue操作を実行できますcatalogue(class)クラスまたは操作ごとに、機能はチーム全体に明らかです。

プログラマー福祉

持続可能なペース

コンセプトは、プログラマーまたはソフトウェア開発者は週40時間以上働くべきではなく、1週間の残業がある場合、次の週にはそれ以上の残業を含めるべきではないということです。開発サイクルは継続的インテグレーションの短いサイクルであり、完全な開発(リリース)サイクルがより頻繁であるため、XPのプロジェクトは、他のプロジェクトが必要とする(残業が必要な)通常のクランチタイムに従いません。

また、この概念には、十分に休息している場合に人々が最高かつ最も創造的にパフォーマンスするというものが含まれています。

持続可能なペースを達成するための重要なイネーブラーは、頻繁なコードマージであり、常に実行可能でテスト対象の高品質コードです。常にリファクタリングを行う方法により、チームメンバーは新鮮で注意深い心を持ちます。チーム内での強力な共同作業方法により、週末に充電する必要が生じます。

十分にテストされ、継続的に統合され、頻繁にデプロイされるコードと環境は、予期しない本番環境の問題や停止の頻度を最小限に抑え、関連する営業時間外の夜間や週末の作業も最小限に抑えます。

も参照してください

参照

  1. ^ Beck、K. Extreme Programming Explained:EmbraceChange2nded。アディソン-ウェスリー、2000pp.54
  2. ^ Melnik、Grigori; マウラー、フランク(2004)。アジャイル手法の紹介:3年の経験第30回ユーロマイクロ会議の議事録。IEEE。pp。334–341。CiteSeerX10.1.1.296.4732 _ 土井10.1109/EURMIC.2004.1333388
  3. ^ Leybourn、E.(2013)。アジャイル組織の指揮:ビジネス管理への無駄のないアプローチ。ロンドン:ITガバナンスパブリッシング:146–150。
  4. ^ マーティン、ロバート。「TDDの3つのルール」
  5. ^ コラワ、アダム; Huizinga、Dorota(2007)。自動欠陥防止:ソフトウェア管理のベストプラクティスWiley-IEEE ComputerSocietyPress。p。75. ISBN 978-0-470-04212-0
  6. ^ http://guzdial.cc.gatech.edu/squeakbook/new-lecture-slides/xp.ppt
  7. ^ セダノ、トッド; ラルフ、ポール; Péraire、Cécile(2016)。「チームコードの所有権の実践と認識」ソフトウェア工学における評価と評価に関する第20回国際会議の議事録ACM。pp。1–6。土井10.1145/2915970.2916002ISBN 9781450336918S2CID10016345 _
  8. ^ Ribeiro、Danilo&Silva、Fabio&Valença、Diana&Freitas、Elyda&França、César。(2016)。開発者の観点から共有コードを使用することの長所と短所:定性的研究。

外部リンク