Extreme-programming-introduction
エクストリームプログラミング-はじめに
この章では、エクストリームプログラミングの概要を説明します。
アジャイルとは何ですか？
「アジャイル」という言葉は-
- 素早く簡単に体を動かすことができます。
- 迅速かつ明確に考えることができる。
ビジネスでは、「アジャイル」は作業の計画と実行の方法を説明するために使用され、必要に応じて変更を加えることは仕事の重要な部分であると理解されています。 ビジネスの「アジリティ」とは、企業が常に市場の変化を考慮に入れる立場にあることを意味します。
Ref：Cambridge Dictionaries online。
ソフトウェア開発では、「アジャイル」という用語は、「変更に対応する能力-要件、技術、人からの変更」を意味するようになっています。
アジャイルマニフェスト
2001年にソフトウェア開発者のチームがアジャイルマニフェストを公開し、変化する要件と顧客の関与に対応する開発チームの重要性を強調しました。
アジャイル宣言は次のように述べています-
私たちは、ソフトウェアを開発し、他の人がそれを行うのを支援することにより、ソフトウェアを開発するより良い方法を発見しています。 この作業を通じて、私たちは価値になっています-
- プロセスとツールを介した*個人と相互作用。
- 包括的なドキュメント上の*作業ソフトウェア。
- 契約交渉を介した*顧客コラボレーション。
- 計画に従うことに対する変更への対応。
つまり、右側の項目には値がありますが、左側の項目にはさらに値を付けます。
敏ility性の特徴
アジリティの特徴は次のとおりです-
- アジャイルソフトウェア開発の俊敏性は、チーム全体の文化に焦点を当てており、権限が与えられ、自己組織化されている複数の専門分野にわたる機能横断型のチームです。
- 責任と説明責任を共有します。
- 効果的なコミュニケーションと継続的なコラボレーションを促進します。
- チーム全体のアプローチにより、遅延と待ち時間が回避されます。
- 頻繁かつ継続的な配信により、迅速なフィードバックが保証され、チームが要件に合わせて調整できるようになります。
- コラボレーションにより、実装、不具合の修正、変更への対応において、さまざまな視点をタイムリーに組み合わせることが容易になります。
- 進歩は、透明性を強調し、持続可能で、予測可能なものです。
ソフトウェア工学の動向
ソフトウェアエンジニアリングでは次の傾向が観察されます-
- 開発を開始する前に要件を収集します。 ただし、要件を後で変更する場合は、次のことに注意してください-
- 開発の後期段階での変更に対する抵抗。
- 変更を後のリリースにプッシュする可能性のある変更管理ボードを含む、厳密な変更プロセスの要件があります。
- 顧客の期待を満たしていない、時代遅れの要件を持つ製品の提供。
- 避けられないドメインの変更や予算内のテクノロジーの変更に対応できない。
- 欠陥修正コストを削減するために、開発ライフサイクルの早い段階で欠陥を見つけて排除します。
- テストはコーディングが完了した後にのみ開始され、テスターは開発に関与していませんが、テストはテスターの責任と見なされます。
- プロセス自体を測定および追跡します。 ので、これは高価になります-
- タスクレベルおよびリソースレベルでの監視と追跡。
- 開発の指針となる測定値を定義し、開発中のすべてのアクティビティを測定します。
- 管理介入。
- 開発の前に、モデルを作成、分析、および検証します。
- モデルはフレームワークとして使用されることになっています。 ただし、重要な開発ではなくモデルに焦点を当てると、期待される結果が得られません。
- 開発の中心であるコーディングは、十分に強調されていません。 理由は-
- 生産を担当する開発者は、通常、顧客と常に連絡を取り合っていません。
- コーディングは設計の翻訳と見なされ、コードの効果的な実装が設計にループバックされることはほとんどありません。
テストは、配信前に欠陥をチェックするためのゲートウェイと見なされます。
- 開発の初期段階のスケジュールのオーバーランは、テスト要件を無視してタイムリーな配信を保証することで補償されます。
- これにより、納入後に欠陥が修正され、コストが超過します。
- 開発者は、開発の全過程で関与していませんでしたが、製品の品質に対して責任と説明責任を負います。
予算に対応するためのリソース（主にチーム）の制限-
- リソースの過剰割り当て
- チームのバーンアウト。
- チームの能力の有効活用の損失。
- 消耗。
極端なプログラミング-一般的な欠点を処理する方法
ソフトウェアエンジニアリングには以下が含まれます−
- 創造性
- 試行錯誤による学習と改善
- 繰り返し
エクストリームプログラミングは、これらのアクティビティとコーディングに基づいています。 これは、効果的な実装、テスト、リファクタリングを継続的に行う複数のタイトフィードバックループを備えた詳細な（唯一の）設計活動ではありません。
極端なプログラミングは、次の値に基づいています-
- コミュニケーション
- 単純さ
- フィードバック
- 勇気 *尊敬
エクストリームプログラミングとは
XPは、ソフトウェアを開発するための軽量で効率的、低リスク、柔軟、予測可能、科学的で楽しい方法です。
e* X treme P * rogramming（XP）は、あいまいで変化する要件に直面した小さなチームによるソフトウェア開発の特定のニーズに対応するために考案および開発されました。
エクストリームプログラミングは、アジャイルソフトウェア開発手法の1つです。 チームの行動を導くための価値と原則を提供します。 チームは自己組織化することが期待されています。 エクストリームプログラミングは、特定のコアプラクティスを提供します。
- 各プラクティスはシンプルで自己完結型です。
- プラクティスの組み合わせにより、より複雑で緊急の動作が生成されます。
変化を受け入れる
エクストリームプログラミングの重要な前提は、プログラムを変更するコストが時間とともにほぼ一定に保たれることです。
これは次の方法で実現できます-
- 顧客からの継続的なフィードバックを重視
- 短い反復
- 設計と再設計
- 頻繁なコーディングとテスト
- 欠陥を早期に排除し、コストを削減
- 開発全体を通じて顧客を関与させ続ける
- 顧客への実用製品の提供
一言で言えば極端なプログラミング
エクストリームプログラミングには以下が含まれます−
- プログラミングの前に単体テストを作成し、すべてのテストを常に実行し続ける。 単体テストは自動化されており、欠陥を早期に排除するため、コストが削減されます。
- 手元の機能をコーディングするのに十分な単純な設計から開始し、必要に応じて再設計します。
- ペアでのプログラミング（ペアプログラミングと呼ばれる）。1つの画面に2人のプログラマーがいて、キーボードを交互に使用します。 それらの1つはキーボードにありますが、もう1つは常に入力を確認して提供します。
- システム全体を1日に数回統合およびテストします。
- 最小限の作業システムを本番環境にすばやく配置し、必要に応じてアップグレードします。
- 常に顧客を巻き込み、常にフィードバックを得る。
反復は、ソフトウェアが要件の変化に合わせて進化する際の変更への対応を容易にします。
なぜ「Extreme」と呼ばれるのですか？
エクストリームプログラミングは、効果的な原則と実践を極端なレベルに引き上げます。
- コードは常にレビューされるため、コードレビューは効果的です。
- 継続的な回帰とテストがあるため、テストは効果的です。
- 誰もが毎日リファクタリングを行う必要があるため、設計は効果的です。
- 統合テストは、1日に数回統合およびテストするため重要です。
- 短い反復は、リリース計画と反復計画の計画ゲームとして効果的です。
エクストリームプログラミングの歴史
Kent Beck、Ward Cunningham、Ron Jeffriesは1999年に極端なプログラミングを策定しました。 他の貢献者は、ロバート・マーティンとマーティン・ファウラーです。
80年代半ば、Kent BeckとWard Cunninghamはテクトロニクスでペアプログラミングを開始しました。 80年代および90年代に、Smalltalk Cultureはリファクタリング、継続的インテグレーション、継続的なテスト、および密接な顧客の関与を生み出しました。 この文化は後に他の環境に一般化されました。
90年代初期、コアバリューは、ヒルサイドグループのパターンコミュニティ内で開発されました。 1995年、KentはこれらをSmalltalk Best Practicesにまとめ、1996年にはWardをエピソードにまとめました。
1996年、ケントはヒューイットでユニットテストとメタファーを追加しました。 1996年、ケントはクライスラーC3プロジェクトを引き受け、それにロンジェフリーズがコーチとして追加されました。 プラクティスはC3で改良され、Wikiで公開されました。
スクラムのプラクティスが組み込まれ、計画ゲームとして採用されました。 1999年、Kentは彼の著書「Extreme Programming Explained」を出版しました。 同じ年に、ファウラーは彼の本「リファクタリング」を出版しました。
エクストリームプログラミングはそれ以来進化しており、進化は今日も続いています。
業界での成功
エクストリームプログラミングのプラクティスに従うプロジェクトの成功は、
- 急速な発展。
- 顧客の要件の変化に対する即時の対応。
- 低欠陥率に焦点を当てます。
- 一定の一貫した価値を顧客に返すシステム。
- 高い顧客満足度。
- コスト削減。
- チームの結束と従業員の満足度。
極端なプログラミングの利点
極端なプログラミングは、ソフトウェア開発プロジェクトでしばしば直面する次の問題を解決します-
- 省略されたスケジュール-および達成可能な開発サイクルにより、タイムリーな配信が保証されます。
- キャンセルされたプロジェクト-継続的な顧客の関与に焦点を当てることで、顧客との透明性と問題の即時解決が保証されます。
- 変更で発生するコスト-広範囲にわたる継続的なテストにより、変更によって既存の機能が損なわれないことが確認されます。 稼働中の稼働中のシステムは、現在の操作が影響を受けないように、常に変更に対応するのに十分な時間を確保します。
- 生産および出荷後の欠陥：強調はオンです-欠陥を早期に検出して修正するためのユニットテスト。
- ビジネスおよび/またはドメインの誤解-顧客をチームの一員にすることで、継続的なコミュニケーションと明確化が保証されます。
- ビジネスの変更-変更は避けられないと考えられ、いつでも受け入れられます。
- スタッフの売上高-集中的なチームコラボレーションにより、熱意と善意が保証されます。 多分野の団結がチームの精神を育みます。
