この章では、エクストリームプログラミングの概要

アジャイルとは何ですか？

“アジャイル”という言葉は−

• 素早く簡単に体を動かすことができます。

• すばやくはっきりと考えることができます。,

ビジネスでは、”アジャイル”は、必要に応じて変更を加えることが仕事の重要な部分であることが理解されている作業を計画し、行う方法を記述するために使用されます。 ビジネス’agililty’は会社が市場の変更を考慮に入れる位置に常にあることを意味する。

Ref：ケンブリッジ辞書オンライン。

ソフトウェア開発において、”アジャイル”という用語は、”変化に対応する能力−要件、技術、人からの変化-“を意味するように適応されています。,’

Agile Manifesto

ソフトウェア開発者のチームが2001年にAgile Manifestoを発表し、開発チームの重要性を強調し、変化する要件と顧客の関与に対応しました。

アジャイルマニフェストは、−

私たちはソフトウェアを開発し、他の人がそれを行うのを助けることによって、より良い方法を明らかにしています。 この仕事を通じて、私たちはプロセスやツールに対する個人や相互作用を価値付けるようになりました。

• 包括的なドキュメント上のソフトウェアを動作させます。,

• 契約交渉よりも顧客のコラボレーション。

• 計画に従って変更に対応します。

つまり、右側の項目には価値がありますが、左側の項目にはもっと価値があります。

アジリティの特徴

以下はアジリティの特徴です−

• アジャイルソフトウェア開発におけるアジリティは、権限を与えられ、自己化されている多規律、クロスファンクションチームを持つチーム全体の文化に焦点を当てています。

• それは共有された責任と説明責任を促進します。,

• 効果的なコミュニケーションと継続的なコラボレーションを容易にします。

• チーム全体のアプローチは、遅延と待ち時間を回避します。

• 頻繁かつ継続的な配信は、順番にチームが要件に合わせることができるように迅速なフィードバックを確保します。

• コラボレーションは、実装、欠陥の修正、変更への対応にタイムリーに異なる視点を組み合わせることを容易にします。

• 進歩は、透明性を強調し、一定で持続可能で予測可能です。,

ソフトウェアエンジニアリングの動向

ソフトウェアエンジニアリングでは、次の傾向が見られます。

• 開発開始前に要件を収集します。 ただし、後で要件を変更する場合は、通常、開発の後の段階での変更に対する

  • 抵抗性に注意してください。

  • それ以降のリリースに変更をプッシュすることさえできる変更管理ボードを含む厳格な変更プロセスの要件があります。,

  • 顧客の期待を満たしていない、時代遅れの要件を持つ製品の配信。

  • 予算内で避けられないドメインの変更や技術の変更に対応することができません。

• 欠陥修正コストを削減するために、開発ライフサイクルの早い段階で欠陥を見つけて排除します。

  • テストはコーディングが完了した後にのみ開始され、テストはテスターの責任とみなされますが、テスターは開発に関与していません。

  • プロセス自体を測定および追跡します。, これは、タスクレベルおよびリソースレベルでの−

  • 監視および追跡のために高価になります。

  • 開発を導き、開発のすべての活動を測定するための測定を定義します。

  • 管理介入。

• 開発前にモデルを詳しく説明し、分析し、検証します。

  • モデルはフレームワークとして使用されることになっています。 しかし、重要な開発ではなく、モデルに焦点を当てることは、期待される結果をもたらすことはありません。,

• 開発の中心であるコーディングは、十分な重点を与えられていません。 その理由は−

  • 生産を担当する開発者は、通常、顧客と絶え間ないコミュニケーションをとっていません。

  • コーディングはデザインの翻訳と見なされ、コード内の効果的な実装はほとんどデザインにループバックされません。

テストは、出荷前に欠陥をチェックするためのゲートウェイであると考えられています。,

• 開発の初期段階のスケジュールオーバーランは、タイムリーな配信を確実にするために、テスト要件を見落とすことによって補償されます。

• これにより、納入後の欠陥を修正するコストオーバーランが発生します。

• テスターは、開発の全過程で関与していませんでしたが、製品の品質について責任を負い、責任を負います。

予算に対応するためにリソース（主にチーム）を制限すると、

• 割り当てを超えるリソース

• チームのバーンアウトにつながります。,

• チームコンピテンシーの有効活用における損失。

• 消耗します。

エクストリームプログラミング−共通の欠点を処理する方法

ソフトウェアエンジニアリングには、

• 創造性

• 試行錯誤による学習と改善

• 反復

エクストリームプログラミングは、これらのアクティビティとコーディングに基づいています。 その詳細なもののみ）デザイン活動を複数のタフィードバックループを通じて効果的な実施、試験およびリファクタリングします。,

エクストリームプログラミングは、次の値に基づいています−

• 通信

• シンプルさ

• フィードバック

• 勇気

• 尊敬

エクストリームプログラミングとは何ですか？

XPは、ソフトウェアを開発するための軽量、効率的、低リスク、柔軟、予測可能、科学的、そして楽しい方法です。

極端なプログラミング（XP）は、漠然とした変化する要件に直面して小さなチームによってソフトウェア開発の特定のニーズに対処するために考案され、,

極端なプログラミングは、アジャイルソフトウェア開発手法の一つです。 それはチーム行動を導くために価値および主義を提供する。 チームは自己組織化することが期待されています。 エクストリームプログラミングは、特定のコアプラクティスを提供します−

• 各プラクティスは単純で自己完結です。

• プラクティスの組み合わせは、より複雑で創発的行動を生成します。

変更を受け入れる

極端なプログラミングの重要な仮定は、プログラムを変更するコストは、時間の経過とともにほとんど一定に保,これは、−

• 顧客からの継続的なフィードバックに重点を置く

• 短い反復

• 設計と再設計

• 頻繁にコーディングとテスト

• 欠陥を早期に排除し、コストを削減

• 開発を通じて顧客を関与させ続ける

• /li>

• 作業製品を顧客に提供する

エクストリームプログラミング一言で言えば

エクストリームプログラミングには、−

• すべてのテストを常に実行し続ける前に単体テストを書くことが含まれます。, 従って単体テストは自動化され、欠陥を早く除去し、コストを削減する。

• 手元の機能をコード化し、必要に応じて再設計するのに十分なシンプルなデザインから始めます。

• キーボードを使用するためにターンを取って、一つの画面で二人のプログラマで、（ペアプログラミングと呼ばれる）ペアでプログラミング。 そのうちの一つは、キーボードにあるが、他は常にレビューし、入力を提供します。

• システム全体を一日に数回統合し、テストします。,

• 最小限の作業システムを生産に迅速に導入し、必要に応じてアップグレードします。

• 顧客を常に関与させ、一定のフィードバックを得る。

反復処理は、ソフトウェアが変化する要件に伴って進化するにつれて、対応する変更を容易にします。

なぜそれは”極端”と呼ばれていますか？”

エクストリームプログラミングは、極端なレベルに効果的な原則と実践を取ります。

• コードレビューは、コードが常にレビューされるので効果的です。,

• テストは、連続回帰とテストがあるので効果的です。

• デザインは、誰もが毎日リファクタリングを行う必要があるため、効果的です。

• 統合テストは、一日に数回の統合とテストとして重要です。

• 短い反復は、リリース計画や反復計画の計画ゲームとして有効です。

エクストリームプログラミングの歴史

ケント-ベック、ウォード-カニンガム、ロン-ジェフリーズは1999年にエクストリームプログラミングを定式化した。 他の貢献者はロバート-マーティンとマーティン-ファウラ,

80年代半ば、ケント-ベックとウォード-カニンガムはテクトロニクスでペアプログラミングを開始しました。 80年代から90年代にかけて、Smalltalk文化はリファクタリング、継続的な統合、一定のテスト、および密接な顧客関与を生み出しました。 この文化は後に他の環境に一般化されました。

90年代初頭には、PatternsコミュニティHillside Group内でコアバリューが開発されました。 1995年、KentはSmalltalkのベストプラクティスでこれらを要約し、1996年にはwardはエピソードでそれを要約した。

1996年、KentはHewittで単体テストとメタファーを追加しました。, 1996年、ケントはクライスラー C3プロジェクトを引き継ぎ、ロン-ジェフリーズがコーチとして加わった。 プラクティスはC3で洗練され、Wikiに公開されました。

スクラムプラクティスが組み込まれ、計画ゲームとして適応されました。 1999年、ケントは著書”エクストリーム-プログラミングの説明”を出版した。 同年、ファウラーは著書”リファクタリング”を出版した。

エクストリームプログラミングはそれ以来進化しており、進化は今日まで続いています。

業界での成功

極端なプログラミングプラクティスに従うプロジェクトの成功は、

• 急速な発展によるものです。,

• お客様の変化する要件に即時対応します。

• 低い欠陥率に焦点を当てます。

• システムは、顧客に一定の一貫性のある値を返します。

• 高い顧客満足度。

• コストを削減しました。

• チームの結束と従業員の満足度。

エクストリームプログラミングの利点

エクストリームプログラミングは、ソフトウェア開発プロジェクトで頻繁に直面する次の問題を解決します。

• スケジュールを滑らせ、達成可能な開発サイクルはタイムリーな配信を保証します。,

• キャンセルされたプロジェクト−継続的な顧客の関与に焦点を当てることは、顧客との透明性とすべての問題の即時の解決を保証します。

• 変更で発生するコスト−広範かつ継続的なテストにより、変更が既存の機能を壊さないようにします。 実行中の作業システムは、現在の操作が影響を受けないように、変更に対応するのに十分な時間を常に確保します。

• 生産および配送後の欠陥：重点が置かれています−欠陥を早期に検出して修正するための単体テスト。,

• ビジネスおよび/またはドメインを誤解する−顧客をチームの一員にすることは、常にコミュニケーションと明確化を保証します。

• ビジネスの変更−変更は避けられないものとみなされ、任意の時点で対応されます。

• スタッフの離職率集約的なチームのコラボレーションは、熱意と善意を保証します。 多分野の結束は、チームの精神を促進します。