敏捷開発方法-エクストリームプログラミングXP
2025-02-10 15:35:59 45 0 報告 0
0
ログインして完全な内容を表示
著者の他の作品
概要/内容
エクストリーム・プログラミングの4つの価値
コミュニケーション
ソフトウェアシステムの基本的なタスクの一つ
システムの開発者とコミュニケーションを取って、システムの具体的な要件を明確にする
目標は全ての開発者に対してシステムに対する共有の視点を提供することであり、
その視点はシステムの最終ユーザーの視点と一致していることである。
その視点はシステムの最終ユーザーの視点と一致していることである。
定期的な口頭でのコミュニケーションとフィードバックを奨励する
簡単
最も簡単な解決方法から始めましょう
絶え間ないリファクタリングによってより良い結果を得る
現在のニーズにのみ焦点を当ててデザインやコーディングを行い、
明日、来週、または来月に現れる可能性のあるニーズについては考慮しない。
明日、来週、または来月に現れる可能性のあるニーズについては考慮しない。
将来のニーズは彼らがまだ提案する前に変化する可能性が高いです。
デザインとコードの簡素化は、コミュニケーションの質を向上させることができます。
フィードバック
フィードバックはできるだけ早くしていただけると助かります。
「フィードバック」とシステム開発の
多くの異なる方面に関連している
多くの異なる方面に関連している
システムからのフィードバック
単体テスト
修正後のシステムの状態を直感的に把握する
お客様からのフィードバック
機能テスト
お客様とテスト担当者が記述
現在のシステムの状態を知る
2、3週間に1度の計画
お客様は開発の進捗を非常に容易に理解し、管理することができます。
グループからのフィードバック
お客様が新しい要件を持ってプロジェクト計画会議に参加する
小组は新規要件の実現に必要な時間を直接評価し、その後顧客にフィードバックすることができます。
フィードバックは「コミュニケーション」と「シンプル」の二つの価値と密接に関連しています。
コミュニケーションシステムにおける欠陥
単体テストを記述する
単純にあるコードの問題を証明する
ユーザーは定義された機能要件に基づいて、システムに対して周期的なテストを行います。
プログラミングにおける楽観主義は危険であり、タイムリーなフィードバックがそれを解決する方法です。
ケント・ベック
勇気
今日のニーズのためにデザインし、コーディングする、
明日のことは考えないでください。
明日のことは考えないでください。
デザインの泥沼に陥ることを避け、
他の問題に不必要に多くのエネルギーを費やすのを防ぐ
他の問題に不必要に多くのエネルギーを費やすのを防ぐ
彼らがコードをリファクタリングする必要があるときに快適に感じられる
既存システムを再検討し、それを改善してください。
将来発生する変化の要件がより容易に実現できるようになります。
いつ完全に既存のコードを捨て去るべきかを理解する
一日中を費やして、自分でデザインした複雑な問題とコードに絡み合っていたが、何も得られなかった。
翌日、新たな清々しい視点から考える
30分以内に簡単に解決できます
エクストリーム・プログラミングの5つの原則
迅速なフィードバック
フィードバックがタイムリーで迅速です。
お客様
開発の全過程中でタイムリーにフィードバックを提供する
必要な時にシステムの開発方向をコントロールすることができる
単体テスト
同様にフィードバックの原則を実行するのに役立ちます。
仮定が単純
どんな問題も「極めて簡単」に解決することができます。
伝統的なシステム開発方法
将来の変化を考える
コードの再利用性を考慮する
エクストリーム・プログラミングはこれを拒否します
増分変化
ローマは一日にしてならず
たとえば
3週間に1回、小さな変更を含む新しいバージョンをリリースします。
一歩一歩前進する
変化を受け入れる
変化に対して反抗的な態度を取るのではなく、それらを受け入れるべきです。
例えば、ある段階的な会議で顧客がいくつかの劇的な要求変更を提起した。
プログラマーとして、これらの変化を受け入れる必要があり、
次の段階の製品が新しい要求を満たすことができるように計画を立てなければならない。
プログラマーとして、これらの変化を受け入れる必要があり、
次の段階の製品が新しい要求を満たすことができるように計画を立てなければならない。
高品質な仕事
四つのソフトウェア開発の変数
範囲
時間
コスト
品質
品質だけは妥協できない
エクストリーム・プログラミング
エクストリーム・プログラミング
エクストリーム・プログラミング
XPに短縮されます
ソフトウェア工学の方法論
異なります
より適応性を強調し、予測可能性よりも重視する
創始者
ケント・ベッカー、ウォード・キャニングハム
ロオン・ジェファリス
エクストリーム・プログラミングの目標
要件変更によるコストを低減する
システム要件はプロジェクト開発の初期段階で決定されます。
プロジェクト開発が後期の段階に入ったときに発生する要件の変更は、開発コストを急速に増加させる可能性があります。このような要件の変更は、非常に速いペースで発展している分野においては避けられないことがあります。
基本的な価値、原則、方法などの概念を導入することにより
変更コストを下げる目的
エクストリーム・プログラミングの12の核心実践
短い納期
スクラムと同じようにイテレーションによる納品方法を採用する
各イテレーションは1〜3週間の時間です。
イテレーション終了
チームが動作する、テスト済みの機能を納品する
これらの機能はすぐに使用できます。
計画ゲーム
二つの問題
納期前にどれだけの仕事が完了できるかを予測する
今何をすべきか、次に何をすべきか
この二つの質問に絶えず答える
二つの問題に対する二つの対応プロセス
ソフトウェアリリース計画（Release Planning）
開発コスト、リスク、および各要件の重要性に基づいて、大まかなプロジェクト計画を策定する。
最初のプロジェクト計画は、正確である必要も可能性もない。
周期開発計画（イテレーションプランニング）
開発過程中
多くの段階的な計画があります
例えば、3週間に1つの計画
ある周期において、システム内部の再編成と最適化（コードとデザイン）を行います。
ある周期に新機能が追加されました
一つの周期内で両方面の仕事を同時に行います。
利点と欠点がある
利点
お客様はすぐにわかります。
どのくらい完了しましたか
作った物が役に立つかどうか
他に何をしなければならないか、または何を改善する必要があるか等
デメリット
出来上がったものを見て、非常に不満足で、場合によっては契約を中止するかもしれません。
問題を早期に発見し、解決するために
ペアプログラミング
二人が一台のパソコンの前で一緒に作業をしています。
プログラマーがパソコンを制御し、主にコーディングの細部に焦点を当てています。
もう一人の人は全体的な構造に主に注目しています。
最初のプログラマーが書いたコードに対して、継続的にレビューを行う。
ペアは固定的ではありません。
持続可能なリズム
長期間にわたって維持される速度で努力して働く
エネルギーを保存する
プロジェクトをマラソンに見立てて取り組む
ではなく、全力疾走
コードの共同所有
誰もが全てのコードに対して責任を負う。
誰でもコードの任意の部分を変更できます
チームプログラミングはこの実践に対して多大な貢献をしています。
異なるチームで働く
全てのプログラマーは完全なコードを見ることができます。
コーディング規約
全ての人が統一されたプログラミングの基準に従います。
全てのコードは一人が書いたように見える
シンプルなデザイン
一回性的、全てのニーズに対する全体的な設計が、そのような伝統的な開発モデルには存在しない。
デザインプロセスは、プロジェクト開発全体にほぼ一貫して貫かれています。
プロジェクト計画の策定から
各開発周期（イテレーション）の計画を策定する
各ニーズモジュールに向けた簡潔なデザイン
デザインの再検討
そして、絶え間ないデザインの再構築と最適化を続けています。
全体的なデザインプロセスは、らせん状の、絶えず前進し発展し続けるプロセスです。
テスト駆動開発
リファクタリング
システムメタファー
継続的インテグレーション
XP開発チームは、システムや機能モジュールがどのように動作するかを、多くの具体的な比喩で説明します。
現地顧客
お客様
システムの支払いをする人ではない
実際にそのシステムを使っている人です
お客様
常に現場で問題を解決する
物語を書く
受け入れテスト
より頻繁な交流と議論
集める
集める
集める
集める
集める
0 コメント
次のページ
