Extreme-programming-rules

エクストリームプログラミング-ルール

あなたがプレーするスポーツを考えてください。 そのスポーツやゲームのルールを順守する必要があります。 同様に、エクストリームプログラミングでは、プロジェクト全体がチームメンバーとビジネス（顧客を代表する）とのコラボレーションによって駆動されるため、プロジェクトの特定のルールを最初にレイアウトする必要があります。 これらのルールは、エクストリームプログラミングのプラクティスと同等でなければなりません。

ルールは、チームの全員に共通の参照を提供するため、物事がスムーズに進むときとうまくいかないとき、何をどのように行う必要があるかを全員に思い出させることができます。

Extreme Programmingで言及しているゲームは、Planning Gameです。

計画ゲームのルール

エクストリームプログラミングでは、計画ゲームは最初のリリースの計画会議で始まり、最終リリースで終わります。

最初のリリース計画会議の前に、エクストリームプログラミングのプラクティスに沿って計画ゲームのルールを定義し、ビジネスとチームにルールを理解する必要があります。 プロジェクトを管理して、ルールが遵守されていることを確認する必要があります。

ただし、ソフトウェア開発では、すべてのプロジェクトに単純なルールセットを適用する方法はありません。 エクストリームプログラミングの慣行に妥協することなく、ビジネスとチームに応じて変更する必要があります。 したがって、必要な目標を備えた一連のルールを最初に配置し、必要な場合にのみ開発の進行に合わせて変更できます。

ゲームの目標は、チームが作成したソフトウェアの価値を最大化することです。 ソフトウェアの価値から、開発のコストと開発中に発生したリスクを差し引く必要があります。

チームの戦略は、リスクを軽減するための設計およびコーディング戦略と組み合わせて、できるだけ貴重な機能をできるだけ早く本番に投入することです。

この最初の稼働システムのテクノロジーとビジネスレッスンを考慮すると、現在最も価値のある機能がビジネスであることが明らかになり、チームはこれをすぐに運用環境に投入します。

このプロセスは、開発全体が完了するまで反復およびリリースを続けます。

ゲームの計画の基本的なルールは、次の領域に分類することができます-

• 計画中
• 管理します
• 設計中
• コーディング
• テスト

計画中

計画は、リリース計画および反復計画時に行われます。 ルールは両方で同じです。

リリース計画では、

• ビジネスとチームがプレーヤーです。
• ストーリーカードが使用されます。
• ユーザーストーリーは、ストーリーカードに顧客によって書き込まれます。
• ユーザーストーリーは、ストーリーカードに顧客によって書き込まれます。
• ビジネスは、実装する機能の優先度に基づいて決定されます。
• 見積もりは、ストーリーカードに基づいてチームによって提供されます。
• 短い（頻繁な小さな）リリースを計画する
• http://www.extremeprogramming.org/rules/commitl [リリーススケジュール]は、相互の合意の下に作成されます。
• 次のリリースは、反復に分割される予定です。

反復計画は各反復を開始します。

反復計画では、

• チームメンバーはプレイヤーです。
• タスクカードが使用されます。
• 反復のために選択されたストーリーごとに、タスクカードが作成されます。
• チームメンバーは、タスクカードに基づいてタスクを見積もる必要があります。
• 各チームメンバーにはタスクカードが割り当てられます。
• 各チームメンバーは、自分の割り当てに基づいて再評価する必要があります。
• 仕事を受け入れます。
• 仕事の完了の責任を取る。
• 実際にかかった時間に関するフィードバックを取得します。
• 見積もりの​​改善。
• それらの見積もりを尊重します。

したがって、誰が見積もりを作成および変更できるかについてのルールは明確です。

• 最終割り当ては、週40時間と負荷率を想定して行われます。

管理します

• チームには、専用のオープンワークスペースが与えられます。
• 各ワークステーションは、2人の開発者が並んで座って、キーボードとマウスを簡単にスライドできるように配置する必要があります。
• 持続可能なペースを設定し（週40時間、1週間以上の残業なし）、管理します。
• 計画ゲームのルールを実施します。
• 極端なプログラミングの慣行が壊れた場合の修正。
• チーム間のコミュニケーションを確保します。
• コミュニケーションを落胆-
• 役に立たない
• 適切なタイミングではない
• 非常に詳細に行われた
• 人々を動かします。
• 実際の時間を測定し、定期的にチームに伝えて、各チームメンバーが予測に反してパフォーマンスを把握できるようにします。 これにより、チームメンバの推定が改善されます。
• 必要に応じて、チームが食べ物を利用できるようにします。

設計中

設計のルールは次のとおりです-

• システムのメタファーを選択し、開発の進行に合わせて進化させます。
• デザインをシンプルに保ちます。
• 機能は早期に追加されません。
• 現在のニーズを満たすのに必要なだけのアーキテクチャを今すぐ配置し、後でもっと多くのことができると信頼します
• いつでもどこでも可能な限りリファクタリングします。

コーディング

コーディングのルールは-

• ビジネス（顧客を表す）は常に利用可能である必要があります。
• 開発者は、コードを介したコミュニケーションを重視するルールに従って、すべてのコードを作成する必要があります。
• ペアプログラミングを保証する必要があります。
• コーディング標準に従う必要があります。
• すべてのコードには単体テストが必要です。
• システムの各部分に対してコードが書き込まれる前に、最初にユニットテストを記述します。これにより、コードの作成がはるかに簡単かつ迅速になります。 単体テストを作成し、合格するためのコードを作成するのにかかる合計時間は、すぐにコーディングするのとほぼ同じです。 回帰テストが容易になります。
• あなたがコーディングしているときは、次の4つの帽子のうちの1つだけを着用する必要があります-
• 新しい機能を追加しますが、実装を変更するだけです。
• 新しい機能を追加しますが、インターフェースを変更するだけです。
• コードのリファクタリング、ただし実装の変更のみ。
• コードをリファクタリングしますが、インターフェースのみを変更します。
• 専用の統合ワークステーションがチーム全体に提供されます。
• 一度に1つのペアのみがコードを統合し、すべてのテストに合格することを保証します。
• 統合は頻繁に行う必要があります。
• 集団所有権を使用する必要があります。

テスト

テストのルールは-

• すべてのコードは、リリースされる前にすべてのユニットテストに合格する必要があります。
• 欠陥が見つかったときにテストを作成します。
• 受け入れテストは頻繁に実行されます。