プラクティス一覧

ID	名前	説明
XP-1	リリース計画ゲーム	顧客にとってソフトウェアの価値が最大になるよう、次の運用リリースのスコープを定義。顧客が必要な機能を説明するためにストーリーカードを書き、開発者がその作業時間を見積もる。それから、顧客は次のリリースでどのカードを実装するのかを選択する。
XP-2	イテレーション計画ゲーム	顧客はイテレーションで実装するストーリーカードを選択する。そのストーリーカードごとに、プログラマがストーリを実現するためのタスクリストを（カードまたはホワイトボード上で）作成する。
XP-3	小規模で頻繁なリリース	可能なら1～3週間ごとにリリース。顧客はリリースごとにフィードバック。
XP-4	システムのメタファ	設計をうまく伝えるために、システム全体や各サブシステムを覚えやすいメタファで表現し、主要なアーキテクチャのテーマを描写。
XP-5	シンプルデザイン	将来の変更の可能性を推測して設計しない。今すぐ必要でない汎用のコンポーネントを作成しない。コードの重複をなくし、クラスやメソッドのが比較的少なく抑えられた、簡単に理解できる設計をすべき。
XP-6	テスト駆動開発	テスト対象のコードよりも先にプログラマが単体テストを書く。
XP-7	受け入れテスト	全ての機能は自動化された受け入れ（機能）テストに組み入れる。受け入れテストは顧客と協力して作成する。顧客はテストに使える内容の受け入れ基準定義書を作成する。
XP-8	頻繁なリファクタリング	全てのテストが通ることを確認しながら、きめ細かいコードや大規模な設計要素を単純化する。
XP-9	ペアプログラミング	アプリケーションコードは必ず、２人のプログラマが１台のコンピュータに向かって作成する。定期的に交代しながら交互のコーディングをする。ペアは、タスクが変われば頻繁に組みなおされる。見ている側の人は、リアルタイムコードレビューを行っていることになり、おそらくは入力している人よりも幅広い考えが出来る（テストなどについて考えられる）。メンバが相互に学習すること。もっと規律を持ってプラクティスを遵守し、だらだらせずにもっと多くの時間を実際のプログラミングに割くよう仲間同士でプレッシャーをかけ合うこと。リアルタイムのコードレビューによって欠陥を削除すること。そして、ペアの一人が行き詰まったときでも先に進み続けられる根気と洞察力を持つこと。
XP-10	共同所有権	チーム全体が共同で全てのコードに責任を持つ。変更要求を必要としないため、開発速度が向上する。単体テスト・受け入れテストが存在し、継続したインテグレーションによって、コードに問題が起きたときにはそれがわかる。また、共通のコーディング規約が守られていると、どのコードも似たようなものになっている。
XP-11	継続的インテグレーション	チェックインされたコードは全て、継続的に結合テストが繰り返される。
XP-12	持続可能なペース	時間外労働無しを勧める。
XP-13	チーム全体が一緒に	顧客にプロジェクト専任者を出してもらい、開発者と共通のプロジェクトルームに常駐してもらう。
XP-14	コーディング規約	コードの共同所有、頻繁なリファクタリング、ペアプログラミングのパートナーの頻繁な組み換えを行うためには、全員が同じコーディングスタイルに従う必要がある。
Scrum-1	ゲーム前計画	ゲーム前計画の期間中、利害関係者はだれでも、機能、ユースケース、機能拡張、欠陥などの一覧を作成し、「プロダクトバックログ」に記録することが出来る。プロダクトバックログの所有者として一人のプロダクトオーナが任命され、要求はプロダクトオーナを通じて取り決められる。
Scrum-2	スプリント計画	各イテレーション（スプリント）を開始する前に、２つのミーティングを続けて開催する。最初のミーティングでは、利害関係者があつまって、プロダクトバックログとリリースバックログの精度を上げ、優先順位を付け直し、今回のイテレーションの目標を決定する。優先順位は、通常最も高いビジネス上の価値やリスクによって決定される。２つ目のミーティグでは、スクラムチームとプロダクトオーナが集まって要求をどう実現するか熟考し、目標を達成するためのタスクを列挙した「スプリントバックログ」を作成する。イテレーションの作業が進むにつれ、スプリントバックログは更新される。
Scrum-3	原則30 日（カレンダー上)のイテレーション	作業は原則30 日（カレンダー上）のイテレーションに分割。それぞれをスプリントと呼ぶ。
Scrum-4	スプリントバックロググラフの作成	スプリントバックログのタスクの推定残り作業時間をグラフにまとめたもの（バーンダウンチャート）。毎日スクラムミーティングまでに、このグラフの更新版を壁に貼り出すことが推奨されている。
Scrum-5	自律的な組織化チーム	イテレーションの期間中、経営陣やスクラムマスターは、イテレーションの目標をどのようにして達成するか、問題をどのようにして解決するか、作業順序をどう計画するかについて、（判断を依頼されたり、報告された障害を取り除く必要がない限りは）チームに口出しをしない。
Scrum-6	スクラムミーティング	毎日、同じ時間、同じ場所で、チームメンバは輪になってミーティングを開き、特定の同じ質問をして、各チームメンバがそれぞれ答える。立ったまま行う。15～20分程度で終わらせる。ホワイトボードの前で行い、報告されたタスクや障害はすべて書き留める。書き留めた障害をスクラムマスターが消すのは、その障害が取り除かれた場合だけである。その場にいないメンバが参加できるように、スピーカーで会話できる電話機を使う（参加は必須である）。質問は次のとおり。1.前回のスクラム以降、何を行ったか？2.今から次回のスクラムまでに何を行うか？3.イテレーションの目的を達成する上での障害は何か？4.スプリントバックログに追加するタスクはあるか（新しい要求ではなく、忘れられていたタスク）5.チームメンバから刺激を得て（技術的なこと、業務知識などで）何か新しく学んだことはあったか？
Scrum-7	イテレーションに追加してはならない	イテレーション期間中、経営陣はチームや個人に対して作業を追加してはならない。中断されずに集中できるようにする。万が一何かを追加しなければならない場合は、代わりに他の作業をなくすのが理想である。
Scrum-8	スクラムマスターのファイアウォール	スクラムマスターは、チームが外部からの作業依頼によって作業を中断されないよう気を配る。中断された場合には、その原因を取り除いたり、政治的な問題や外部のマネジメントの問題に対応したりする。
Scrum-9	1時間以内の判断	スクラムミーティングで障害が報告され、スクラムマスターの判断が必要な場合には、即時に、あるいは１時間以内に判断を下すのが理想である。｢悪い判断でもないよりはましだし、後で破棄することもできる｣という価値が奨励されている。
Scrum-10	1日以内の障害除去	スクラムミーティングで報告された障害は、次のミーティグの前に取り除かれるのが理想である。
Scrum-11	ニワトリとブタ	スクラムミーティングの間はスクラムチーム（ブタ）だけが発言することが出来る。そのほかの人（ニワトリ）は、出席できるが黙っていなければならない。CEOも同様である。
Scrum-12	7人のチーム	1チームのメンバは最大7人にすることが推奨されている。大規模プロジェクトでは複数のチームを編成することになる。
Scrum-13	共通の部屋	チームは共通のプロジェクトルームで一緒に作業するのが理想である。
Scrum-14	日次ビルド	少なくとも1日1回、プロジェクトのチェックインされたコードをすべて統合し、回帰テストを行う。
Scrum-15	スプリントレビュー	各イテレーションの最後には、スクラムマスター主催でレビューミーティングを行う（最大４時間まで）。チーム、プロダクトオーナ、その他の利害関係者が参加する。このレビューでは製品のデモを実施する。レビューの目的の一つは、システムの機能、設計、長所/短所、チームの作業、今後の問題が置きそうな箇所について、利害関係者に知らせることである。
FDD-1	ドメイン・オブジェクト・モデリング	問題領域における重要なオブジェクトを記述するクラス図によって構成される。新しい機能や能力をシステムに追加することが容易になる。
FDD-2	feature毎の開発	ドメインオブジェクトモデルの中でクラスを特定できたら、それをそれぞれ設計し、実装を行う。ほとんどのfeatureが数時間から数日以内で実装されるように十分小さく分割する。
FDD-3	クラスの責任者	誰（人またはロール）がクラスの内容に責任を持つかを明らかにする。
FDD-4	featureチーム	熟練した開発者たちを各チームリーダに設定し、それぞれに複数のfeatureを割り当てる。
FDD-5	インスペクション	設計とコードを高品質に保つため、インスペクションを実施する。
FDD-6	構成管理	完成したfeatureのソースコードを特定することができ、クラスに対して行った変更履歴を保管できる機能を持つ構成管理システムが必要である。
FDD-7	定期ビルド完成したfeature	の全てのソースコードと、システムが依存するライブラリやコンポーネントを含めて、定期ビルドを実施する。
FDD-8	結果の申告と可視化	プロジェクトの現状を正しく認識し、開発チームが新しい機能を追加するのにどのくらい時間がかかるかを知ることによって、チームリーダや管理者が、プロジェクトを正しく進めるための情報を得ることができる。
Lean-1	無駄をなくす	無駄な機能を作らない。
Lean-2	品質を作りこむ	バグトラッキングシステムに欠陥情報を入力するようなことはしない。テスト駆動型開発や継続的統合によって、正しいコードしか存在しない状態にする。
Lean-3	知識を作り出す（顧客からのフィードバック）	最小の機能セットを早期に顧客にリリースし、評価とフィードバックを得る。
Lean-4	知識を作り出す（テストからのフィードバック）	毎日ビルドし、統合テストからすばやいフィードバックを得る。
Lean-5	知識を作り出す（適切な決定）	経験と直感を備えたチームやリーダに適切な決定を下させる。
Lean-6	知識を作り出す（追加容易なアーキテクチャ）	新規機能が追加しやすいモジュールアーキテクチャにする。
Lean-7	決定を遅らせる	手遅れにならずに決定を下せる最後のチャンスまで取っておく。
Lean-8	速く提供する	今しなければならないことだけして、速く提供する。
Lean-9	人を尊重する	人が頭を使い、自らそれを見つけ出すことのできる、自律管理能力を備えた組織を作る。
Lean-10	全体を最適化する（顧客ニーズを満たす）	顧客のニーズを満たすための注文を受けた時点から、ソフトウェアが導入され、ニーズが解決されるまでのバリューストリーム全体を最適化する。
Lean-11	全体を最適化する（インセンティブを備えた契約）	全員が確実に全体の最適化を重視するようになるインセンティブを備えた契約や外注契約や部門間の協力合意を結ぶ。
C.Clear-1	短くてリッチなコミュニケーションパスがある	全員が一つに部屋にいることが望ましい。
C.Clear-2	1~3か月以内に出荷する	ドキュメント整備のマイルストーンではなく、コードのマイルストーンを管理する。
C.Clear-3	真のユーザをプロジェクトに巻き込む	ユーザは開発者のスクリーンスケッチやバリデーションの手助けをする。
C.Clear-4	プロジェクトの要諦を把握する	プロジェクトの要諦を把握する何らかの要求記述フォーマットを利用し、何らかの記述言語を用いてシステムデザインを把握する。
C.Clear-5	作業成果物の所有者を決める	所有者は個人かサブチームかチーム全員かもしれないが、しっかり決めておくことが必要である。
C.Clear-11	頻繁なリリース	実行可能であり、テストされたコードを数か月ごとに真のユーザに引き渡す。
C.Clear-12	反省と改善	チームが一緒に、何がうまくいって何がうまくいっていないかをリストアップし、何をすればより良くなるかを議論し、次のイテレーションに生かす。
C.Clear-13	浸透したコミュニケーション	関連した情報をチームメンバに徐々に浸透させる。これはチームメンバが同じ部屋で作業することによって実現可能である。
C.Clear-14	個人の安全	報復を恐れることなく、問題点を指摘できるような環境を整える。
C.Clear-15	集中	まず何をすべきかを知り、それを実施するための時間と心の平穏を持つ。何をすべきかは、ゴールの方向性や優先順位についての議論から知ることができる。時間と心の平穏は、人々が作業に没頭できる環境を整えることによって得られる。
C.Clear-16	エキスパートユーザとのコミュニケーション	頻繁なリリース、成果物の品質に対する早いフィードバック、決定された設計についての早いフィードバック、要求の更新を行うことによって実現される。
C.Clear-17	自動テスト、構成管理、頻繁なインテグレーションにおける技術的な環境	自動化されたテストは必須ではないが、開発効率を向上させる。構成管理により、開発者が別々に、かつ、共同で開発を行うことができる。一日に複数回インテグレーションすることが望ましい。それが無理なら1日に1回、最低でも2日1回はインテグレーションを行うべきである。これら3つを併せた、テストを含めた継続的なインテグレーションを行うことが望ましい。
C.Clear-18	360度の探索	新しいプロジェクトを開始する際、数日から最大2週間かけて下記の点について考えなければならない。 ・ビジネス価値 ・要求 ・ドメインモデル ・技術計画 ・プロジェクト計画 ・チーム構成 ・プロセスや方法論
C.Clear-19	早期の成功体験	とりあえず一つ動くものを作成する。最初に小さな勝利を味わうことで、チームメンバが自信を持つようになる。
C.Clear-20	実行可能なスケルトン	小さな機能を持つシステムを作る。これは最終的なアーキテクチャを用いる必要はないが、おもなアーキテクチャコンポーネントとの関連を明らかにしておく必要がある。
C.Clear-21	インクリメンタルなアーキテクチャの再設計	システムアーキテクチャは、「実行可能なスケルトン」から徐々に進化していく必要がある。進化は、技術やビジネス要件が時間とともに変化するに従って行われる。
C.Clear-22	情報発信	メンバが作業中や歩いているときに見える場所に情報を置く。
C.Clear-23	方法論の改善	より良い経験についての情報を収集する。まずプロジェクトのインタビューを行い、それに基づいてワークショップを開催する。
C.Clear-24	反省ワークショップ	各リリース後、何がうまくいって、何を改善すべきで、次のイテレーションにおいて何をすべきかのワークショップを開催する。
C.Clear-25	集中的な計画	速くて協調的なプロジェクト計画を行う。たとえばXPの計画ゲームを利用できる。
C.Clear-26	デルファイ見積もり	デルファイ法を用いてプロジェクト全体の見積もりを行う。
C.Clear-27	毎日のスタンドアップミーティング	チームの情報共有を早く効率的に行う。
C.Clear-28	アジャイルインタラクション設計	ワークショップの開催、UIの抽出、ユーザビリティのインスペクション、QAテストとシステムのパーソナライズ化によってアジャイルインタラクション設計を実施する。
C.Clear-29	プロセスの簡易版	新しい開発プロセスを、長期のプロジェクトでいきなりそのまま適用することは難しい。まずは短い時間の中でプロセスを適用し、メンバに慣れさせる。
C.Clear-30	Side-by-sideプログラミング	ペアプログラミングに代わるものである。メンバはお互いのディスプレイが見える程度に近い場所に座り、別々に作業を行う。ときどき、メンバは隣の席の人のプログラミングを見ることが可能であり、必要に応じて共同作業を実施する。
C.Clear-31	バーンチャート	バーンチャートを用いてプロジェクトの進行を可視化し、管理する。
RUP-1	反復型開発	2週間から6週間のタイムボックス化されたイテレーションによって開発する。
RUP-2	要求管理	洗練された方法で「発見」「整理」「追跡」することで要求を管理する。事前に大規模な分析を行うのではなく、反復的、インクリメンタルに要求を発見・改良する。たとえば、開発の初期に1日というタイムボックスを設定した短い要求ワークショップを何回か（イテレーションごとに1回ずつ）行う等。ツールを使って、リスク、優先度といった属性や、他の要求との依存関係をもとに要求を整理し、分析しやすくする。ツールを使うことで、要求の状態を追跡でき、何が終了し、何が作業中かなどを知ることができる。
RUP-3	コンポーネント・アーキテクチャーの使用	ハイリスクまたは重要な要素から開発すること、中核アーキテクチャを初期のイテレーションで構築すること、規模の大小を問わず既存コンポーネントを再利用して新規のコードや欠陥を減らそうと努力する。
RUP-4	ビジュアル・モデリング	プログラミングを始める前に、少しでも視覚的なモデリングを行う必要がある。1時間ホワイトボードに向かって絵を描く等。UMLに完全に準拠する必要はない。
RUP-5	品質の継続的検証	早い段階から頻繁にテストを行う。実際には、イテレーションごとに全てのソフトウェアを統合しテストする（単体テスト、システムテスト、負荷テスト）。また、定期的にミーティングを行い、さまざまな作業について評価することで、使いやすさや、コード以外の成果物（要求など）の品質、プロセス自体についても早い段階で検証すべき。
RUP-6	変更管理	規律のある構成管理およびバージョン管理、変更依頼の手順、各イテレーションの最後にリリースをベースライン化するなどによって、変更を管理する。
OP-1	進化型プロトタイプの作成	要求が確定している部分についての進化型プロトタイプを作成する。
OP-2	プロトタイプ専門家の派遣	ユーザにプロトタイプを送り、また、プロトタイプの専門家を派遣。プロトタイプの専門家がソフトウェアを利用するユーザを観察。ユーザが問題に直面したり、新たな要求や機能を思いついたら、プロトタイプの専門家がそれを記録。これにより、ユーザが問題を記録する必要がなくなり、業務に専念できる。
OP-3	使い捨て型プロトタイプの作成	ユーザの利用が終わると、プロトタイプの専門家はベースのプロトタイプを改良し、使い捨て型のプロトタイプを作成する。ユーザはその新たなソフトウェアを使って評価する。変更が効果的でない場合は、プロトタイプの専門家はそれを削除する。
OP-4	新たな進化型プロトタイプの作成	ユーザが変更を気に入った場合、プロトタイプの専門家は機能改善要求を書いて開発チームに送る。開発チームはそれに基づき、新たな進化型プロトタイプを作成。
DSDM-1	タイムボックス	実施すること： ・プロジェクト終了日を固定し、その日までにすべてのビジネス要求が実現される ・プロジェクト内の各インクリメントの最終日を固定し、優先度の高いビジネス要求や技術的要求をその日までに満たす ・フェーズレベルのアクティビティの最終日を固定し、このプロジェクトのための目的を定義する ・ワークショップ、ミーティング、レビューの終了時刻を固定し、参加者はあらかじめ定義された優先度の高い目的のために働く 重要事項： ・Must Have は60%のエフォート、Should Have は20%のエフォート、Could Have は20%のエフォートで実現できるようにタイムボックスを固定する（Must Have を100%に設定すると、見積もりが誤っていたときに問題が発生する）。
DSDM-2	MoSCoW	要件に優先度を付ける方法。 必須(Must have): これがなければシステムが成り立たないような要件 必要(Shuold have): 重要な要件 要望(Could have): できればあった方がいい要件 次回(Want to have): 次回実現したい要件
DSDM-3	プロトタイピング	4種類のプロトタイプ。 ビジネス・プロトタイプ: システムの評価 ユーザビリティ・プロトタイプ: UI の確認 性能/容量プロトタイプ: 性能や容量の制約を満たすことの確認 機能/設計プロトタイプ: オプションの評価
DSDM-4	ワークショップ	さまざまな利害関係者を集め、話し合いの場を持たせる。
DSDM-5	積極的なユーザ関与が絶対に必要である。	DSDMはユーザを中心とした手法である。もしユーザが開発のライフサイクル中にあまり関与できないなら、意志決定の反映が遅れ、開発に遅延が発生するだろう。
DSDM-6	チームに引き渡しの権限が与えられなければならない。	DSDMチームは開発者とユーザから成り立つ。要求が洗練・変更されることに対応するため、彼らは意思決定を行う権限を持たなくてはならない。
DSDM-7	頻繁な引き渡しが鍵である。	製品ベース手法がアクティビティベース手法よりも柔軟である。DSDMチームの役割で重要なものは、同意した時間間隔において製品を引き渡すことである。要求される製品をより早く実現することが可能となる。引き渡しまでの期間を短く設定することにより、正しい製品をより効率よく作成することが可能となる。
DSDM-8	受け入れの主たる条件は現在のビジネスニーズを満たす機能の引き渡しである。	DSDMにおいて重要なことは、必要な時に必要な機能を提供することである。このアプローチが受け入れられれば、コンピュータシステムを後でより厳密に開発することができる。
DSDM-9	反復的で漸増的な引き渡しが不可欠である。	DSDMはインクリメンタルにシステムを開発する。したがって、開発者はユーザから常にフィードバックを得ることができる。また、部分的に完成した製品は、ビジネスニーズを即座にある程度満たすことができる。
DSDM-10	プロジェクトライフサイクル中に行われた変更はすべて元に戻せる。	全ての製品（ドキュメント、ソフトウェア、テストコードなど）の進化を管理するため、全ての製品の変更を保存しておかなければならない。
DSDM-11	要件は高いレベルで基準化される。	細かい部分を後で決めることを許容しながらも、システムの目的とスコープを高いレベルにおいては固定して同意することが必要である。高いレベルにおいて決定したスコープを後で変更する場合は、通常escalation（DSDMで定められている意志決定の変更プロセス）を要求する。
DSDM-12	プロジェクトライフサイクル全体で統合されたテストが期待される。	テストは分離したアクティビティではない。システム開発がビジネスの方向性として正しいことを保証するためだけではなく、技術的にも正しいことが保証されるように、システムがインクリメンタルに開発されるに従って、開発者とユーザによってテストとレビューが繰り返される。DSDMの初期段階では、テストはビジネスニーズと優先順位に対するバリデーションを中心に行われる。プロジェクト後期では、システム全体の機能が正しいかどうかを検証する。
DSDM-13	すべての利害関係者間の協力が不可欠である。	利害関係者はビジネススタッフと開発者のみではなく、サービス提供者やリソース管理者なども含める。
DSDM-14	プロジェクト計画	各フェーズにおいて計画を立てる。Feasibility Study フェーズではOutline Plan 、Business Study フェーズではDevelopment Plan、また、各タイムボックスではタイムボックスプランを立て、Funcational Model Iteration フェーズではImplementation Plan を立てる。
DSDM-15	リスク管理	リスクログに基づいてリスクを管理する。
DSDM-16	DSDM	プロジェクトの計測下記の目的のために計測する： ・将来何が起こるかを予測するための基準を確立する ・プロセスが成功して機能していることを証明する ・問題を明らかにするために、プロセス自体を調査する まず計測するものを決定する必要がある。プロジェクトごとに異なるだろう。計測するものの例として下記のものが挙げられる：・サイズ（LOC、ビジネス機能の数と複雑度、入力と出力の数と複雑度など） ・成果（人月ではなく、成果物とタイムボックスで計測する） ・欠陥（重要度とタイプ別に記録する。重要度は高中低の三段階がよく用いられる。タイプとしては、たとえば、機能・データ・内部インタフェース・外部インタフェース・非機能、が挙げられる。）
DSDM-17	見積もり	下記の目的のために見積もる： ・コストと利益を評価することにより、プロジェクトの意義を査定する ・プロジェクトの計画、スケジューリング、管理のために利用する
DSDM-18	品質管理	品質を保証するために奨励されていること：・ワークショップの開催 ・ユーザの継続的な関与 ・レビューの実施 ・テストの実施 ・構成管理 その他考慮すべきこと： ・ユーザに提供される成果物と、品質に関連した活動を特定する ・各成果物の品質をどのようにチェックすべきかを特定する（レビューやテストなど） ・品質チェックをいつ行うか、それが必須か任意か、ある成果物の全てをチェックすべきなのかサンプルで良いのか、開発中にチェックすべきか終了時のみで良いのかを特定する ・各成果物について誰がチェックするのか、欠陥が発見された際に誰が責任を持つのかを特定する ・品質チェックのために用いる指標を特定する ・どの標準を成果物に適用すべきかを特定する（コーディング基準やUIスタイル標準など）
DSDM-19	実現可能性調査	実施すること： ・ビジネス要件を技術的に実現可能かどうかを確認する ・DSDMを適用するのが良いかどうかを確認する ・技術的ソリューションの候補を洗い出す ・一番大まかな時間とコストの見積もりを行う 関係者： ・ビジネス分析者、エンドユーザ、技術者、ユーザ側の上級 管理者 成果物： ・実現可能性確認報告書、実現可能性確認プロトタイプ（オプション）、計画概要書
DSDM-20	ビジネス調査	実施すること： ・システムがサポートするビジネス・プロセスの範囲を確定する ・これからの開発の概要をどのようなプロトタイプを作るかによって確定する ・プロトタイピングにおけるユーザの代表を確定する ・要件に優先順位を付ける ・DSDMの適用の可否について再確認する ・今後の開発の技術的な基盤をもっと明確にする ・非機能的な要件を確定する 成果物： ・ビジネス分野定義書 ・優先度の付いた要件の一覧 ・システムアーキテクチャ定義書 ・プロトタイプ概要計画書
DSDM-21	機能モデルイテレーション	実施すること： ・実際に動作するプロトタイプと静的モデルを含む機能モデルを用いて,要求されている機能性をデモする ・このプロトタイプではデモされなかった非機能的要件を記録する. 成果物： ・機能モデル、機能プロトタイプ、非機能的要件の一覧、機能モデルのレビュー記録、実装戦略、開発リスク分析報告書
DSDM-22	設計・構築モデルイテレーション	実施すること： ・機能プロトタイプを洗練して,非機能的要件を満たすようにすること ・ユーザ要件を満たすデモができるようにアプリケーションを作ること 成果物： ・設計プロトタイプ、設計プロトタイプのレビュー記録、テストされたシステム、テスト記録
Evo-1	利害関係者を見つける	内部/外部の利害関係者、好意ある/敵対する利害関係者、システムのライフサイクル全体を通した利害関係者を見つける。
Evo-2	重点要求トップ10を定義する	早い段階で、概要レベルの要求を（Planguageで）定義する。Planguageは、システムの品質特性を明確に評価可能な形で定義するための記述方法。
Evo-3	機能仕様を定義する	少なくとも次のイテレーションで実現する機能については明確に定義する。必須ではないが、Planguageを使って機能要求仕様を記述しても良い。
Evo-4	パフォーマンス仕様を定義する	システムパフォーマンスとは、システムがどの程度うまく動くか、どんな利益があるか、環境にどう影響するか、などである。パフォーマンス仕様をインクリメンタルに記述し、改良していく。パフォーマンス属性は機能に付随する。具体的には次に3種類に分類される。 ・品質-どれだけうまく動くか（信頼性、使いやすさなど） ・作業能力 ・リソース節約
Evo-5	明確で（可能なら）測定可能な仕様を定義する	仕様を記述するときは、誤解や曖昧さをできるだけ排除できるやり方や言語を使う。要求の詳細が少なすぎたり多すぎたりしないようバランスを取ることが推奨される。次の短いイテレーションで実装する主な仕様は、明確で詳細に記述する必要がある。
Evo-6	Planguageで仕様を記述する	Planguageは、Evoで要求および設計の仕様を記述するための構造化言語。必須ではないが、使うよう勧められている。
Evo-7	進化型プロジェクトマネジメント	・利害関係者に対して進化型出荷を行い、実際に使ってもらってフィードバックを得る。 ・小刻みのイテレーション（理想的には隔週、あるいはプロジェクト全体の予算および期間の2-5％）。 ・単位コストあたりの品質要求が最も高いステップに、最も高い優先順位をつける。 ・既存システムを最初の基準として使うとよい。 ・フィードバックをもとに今後の計画と要求を修正する。適応型で計画を立て、仕様を進化させる。 ・システム全体としてのアプローチ。役立つことは何でもする。 ・早い段階で結果を出すことを重視する。
Evo-8	進化型出荷	早い段階で部分的なソリューションを出荷して実際に使ってもらう。出荷が行われる頻度は、一般的に週に1度であり、厳密には、期間および予算の2-5%ごとである。
Evo-9	出荷したソリューションの影響を測定する	出荷したソリューションの結果を記録、分析し、今後の計画の進め方を示す。
Evo-10	設計仕様を定義する	Planguageを使って設計仕様を記述し、要求仕様と共にインクリメンタルに進化。
Evo-11	影響評価	設計アイディアによる効果が、コストやパフォーマンス要求（品質、作業能力、リソース制約）に見合っているかどうかを、数値的に分析・比較する。
Evo-12	設計アイディアがどう要求を満たすかを記述する	設計により要求が実現される理由と実現割合を明確に定義する。
Evo-13	テスト測定基準を要求仕様に記述する	パフォーマンス分析時に、そのパフォーマンス属性に対する計器をパフォーマンス要求仕様中に定義。
Evo-14	早期のインスペクションによる仕様品質のコントロール	ルール集に記述された内容や「チェック担当者」が照らし合わせるチェックリストに反していないかを探す。 ・読み手にとってあいまいなものなく明確でなければならない。 ・パフォーマンス要求およびコスト要求には、測定基準を指定して概念を定義しなければならない。 ・インスペクションには2-5人のチェック担当者が参加する。 ・インスペクションは仕様中の数ページをサンプリングして行う。ドキュメント全体をチェックするのではない。 ・チェック担当者が作成者に対して修正方法を助言することはない。問題点を注意するだけである。
Evo-15	仕様の関連	Planguage仕様テンプレートには、要求の追跡可能性のサポートに関連するセクションが設けられている。
Evo-16	オープンエンドのアーキテクチャ	将来変更される可能性が高いと予想される部分に柔軟性を持たせるための施策を導入。施策とはたとえば、インタフェースと実装を分離して実装の変更がインタフェースに影響を与えないようにする、等。
Evo-17	安全係数	設計の影響見積りを算出するときは、定義された安全係数を推定の影響値に掛けるべきである。デフォルトの安全係数は2である。
Evo-18	クライアント駆動型計画	次にどのステップを実施すればよか判断できなければ、主要な利害関係者に尋ねるべき。
Evo-19	価値のあることは何でも	利害関係者のために何ができるか、に集中する。
Evo-20	迅速な学習	現実的な測定を行い、迅速に学習する。
Evo-21	頻繁な出荷	利害関係者に対して、早い段階から頻繁にステップごとに本当に価値のあるものを提供する。
Evo-22	問題の分割	複雑なシステムに対して謙虚になる。単純化し、一度に少しずつ問題に対処する。
Evo-23	ユーザの権限	最終的なユーザに権限を委譲する。手法にこだわったり変に官僚的になったりせず、最終結果に焦点を合わせる。
Evo-24	測定と褒賞	測定可能な結果、つまり利害関係者にとっての費用対効果のフローをベースにチームを賞賛し褒賞を与える。
Cell-1	シェフモードとコックモードの分離	シェフモードではメニュープロダクトの開発を行い、投資する。シェフモードで開発したプロダクトを初出荷後、システムアーキテクチャを管理しやすい構造に変換してプロダクトライン化し、コックモードへ移行する。
Cell-2	DSMを用いたアーキテクチャ変換	DSMにより設計依存性を可視化し、いくつかのインテグラルアーキテクチャを容認したモジュラアーキテクチャへ変換する。
Cell-3	資産の活用	プロダクト、プロセス、人の領域知識・スキルを系列化して、組織的に再利用する。
Cell-4	ビジネスとソフトウェア構築の直結	ビジネスモデルから直接コードを自動生成し、ビジネスイノベーションを計画する段階で、即時プロトタイピングを行い、ビジネスとプログラムの間を直結してシステム化する。
Cell-5	セルの構築と独立性	一つのセルの中では、与えられたモデルに関して、原則として、分析、設計実装、テスト、運用までの責務を負う。内部仕様や内部実装の変更は自由。セル間のインタフェースの変更は公式に行う。
Cell-6	専門技術者の育成	ある特定のセルライン（セルで必要となる知識・スキルおよびセル仕様を分類し、類型化したもの）を特定の技術者に担当させることによって技術者の専門性を育て、結果としてプロジェクトの生産性および品質を高めることができる。
Cell-7	セルのスキル割り当て	セルには必要とされるスキルを定義する。そのスキルを持った人材が動的に配置される。
Cell-8	セル内の平等責任	セルには責任者を置かない。セルのメンバは均等に責任を負い、均等に評価されるものとする。セル内部では頻繁な情報交換が求められる。
SWT-1	タイムボックス	1週間を単位とする小さなサイクルを繰り返す。フェーズの終わりには、バッファ用のタイムボックスを設ける。バーンダウンチャートと組み合わせることにより、開発の進み具合を把握する。
SWT-2	タイムボックス計画	ビジネス検討終了段階で、タイムボックスの繰り返し回数や各タイムボックスで対応する大まかなタスクを計画する。
SWT-3	80%ルール実装	スピードより意思決定スピードの方が、開発全体のスピードへ及ぼす影響が大きい。そのため、判断に必要な情報を完全にそろえて判断するのではなく、80%の精度で判断して前に進む。判断に誤りがあった場合、企画担当、システム担当、開発担当の三者が連携してフォローする。
SWT-4	要件確認会	動作するソフトウェアを見ながら、要件の実現方法や追加・修正等を判断する。定期的（毎週）に実施する。
SWT-5	ユーザ動作確認	企画担当者およびシステム担当者は、各タイムボックスの中で、開発されたソフトウェアの動作確認を随時実施する。
SWT-6	ピックアップレビュー	繰り返しが1、2度終了した段階で、ソースコードをいくつかピックアップしレビューを実施することにより、品質のバラつきをなくす。
ASD-1	ミッションを明らかにする	ミッションを構成する内容を理解する。
ASD-2	ミッションを文書化する	ミッションを具体的な文章として表現し、文書化する。
ASD-3	ミッションが表す価値を共有する	チームメンバ内でミッションについての共通の価値観を醸成する。
ASD-4	結果に焦点を合わせる	結果を定義し、結果を測定する品質基準を定義し、方向に関する共通の理解を作り上げる。さらに、結果を創発的に進化させる。
ASD-5	適応型サイクルの導入	適応型サイクルの特徴 ・ミッション駆動 ・コンポーネントベース ・イテレーション型 ・タイムボックス ・リスク駆動での変化の受入れ
ASD-6	JAD開発	短期間で高品質の成果物を作成するためのクライアントの意思決定担当者とITスタッフからなる組織的で効率を高める。
ASD-7	顧客のフォーカスグループレビュー	製品/システムそのものに対して、顧客からレビューを受けることにより、顧客の変更要求を明らかにする。
ASD-8	ソフトウェアインスペクション	インスペクションによって欠陥を発見するとともに、チームとしてのコラボレーション能力を高める。
ASD-9	プロジェクトの事後評価	実施したプロジェクトの結果を振り返り、その内容を次のプロジェクトに活かすために学習する。
EUP-1	反復的に開発する	反復による開発を行うことで、プロジェクトは優先順位をもとにリスクに対処することができる。また、反復は期間が固定され、具体的な目標が決められているため、進捗を絶えず測定することができる。反復それぞれの最後にはプロジェクトの進み具合が知らされるため、利害関係者は、動くコードの実際の進捗をもとに、プロジェクトの残りの部分に対する現実的な予想を立てることができる。
EUP-2	要求を管理する	利害関係者のニーズを満たすシステムを納品するための鍵となるのは、システムに対する要求を明らかにし、管理することである。そのためには、要求を収集・文書化・保守し、変更を系統的に組み込み、場合によっては要求から設計へと追跡する必要がある。要求管理のプロセスの中には、非常にきっちりと定義されていて、たいていはかなりの工数や費用がかかるけれども、決定事項について正確かつ詳細な文書を作成できる、といったものもあれば、インデックスカードを使ったXPの計画ゲームのようにシンプルなものもある。この2つは両極端であるが、その間に位置するものもあります。RUPはプロジェクトの厳密なニーズに合わせて仕立てることが可能である。
EUP-3	実証されたアーキテクチャ	構築対象のシステムに適したアーキテクチャを洗い出し、それからプロトタイプを作って実証する。
EUP-4	モデリング	モデリングをすることで、概念を描いてじっくり考えることができ、それを他の人と共有することができる。モデリングは、高性能なGUIベースのソフトウェアアプリケーションを使って行うこともできれば、単にホワイトボードに絵を描いて行うこともできる。
EUP-5	継続的に品質を検証する	品質を保証するとは、ソフトウェアが要求を満たしていると確認するためにテストすることだけではない。利害関係者と一緒に、要求や設計やモックアップ(mockup)をレビューすることも、継続的な品質の検証に含まれる。早い段階でテストをして不具合を見つける方が、最後の段階で広範囲のテストをするより、ずっと効率的である。
EUP-6	変更を管理する	ソフトウェア開発において変更は当然起きることである。プロジェクトを円滑に進め、競合に対して優位に立てる可能性のある変更を利用するには、変更を予期し、適切に対処しなければならない。変更が起きると、文書、モデル、計画、テスト、コードなど、さまざまな成果物に影響が及びかねない。アジャイル主義者が言うように、影響を最低限に抑えるには、できるだけ身軽な旅をするとよいであろう。
EUP-7	協調的な開発	システムは人がチームとして開発するものであり、参加する人が効率的に協力しなければプロジェクト全体が失敗する危険がある。アジャイルソフトウェア開発コミュニティでは、協調的な開発をするための手法を明らかにし、促進するために、大きな努力をしてきている。主な手法には、ペアプログラミング(2人のメンバが一緒にコードを作成する)、他の人と一緒にモデリングする(複数の人が別々に作業をするより、一緒にモデリングをした方が効果的だという考え方を促進する)、利害関係者の積極的な参加(プロジェクトの利害関係者は、タイミングよく情報の提供や決断を行ったり、開発作業自体に参加するべきだという考え方を促進する)
EUP-8	開発後のことを考慮する	システムは、構築して稼動状態に導入するだけでなく、導入した後で運用やサポートをする必要がある。優れた開発者はこれを分かっていて、運用やサポートの専門家のニーズが満たされるよう、協調して仕事を進める必要があることを理解している。さらに、システムが組織全体の中にうまく納まること、つまり、システムが全社共通の標準を反映していることを確認する必要があることを十分に理解している。そのため、彼らの作るシステムは、既存のアーキテクチャやインフラストラクチャを利用し、決められた全社的なガイダンス(標準や指針)に沿ったものになる。
EUP-9	動くソフトウェアを定期的に納品する	ソフトウェア開発プロジェクトが成功したかどうかを判断する第1の基準は、ユーザのニーズを満たす動くソフトウェアの納品であるべきである。効果的に開発を行うには、動くソフトウェアを少しずつ納品すること、残っている機能の中でもっとも優先順位の高いものを反復ごとに納品することである。
EUP-10	リスクを管理する	効果的なプロジェクトチームは、リスクを明らかにし、発生したものを管理しようと努力する。必要に応じて、リスクを完全に軽減する場合もあれば、考え得る影響を少なくする場合もある。
Uni-1	ユーザ一体型開発	業務とシステムは表裏一体であり、業務を理解している人はシステムを語り、コンピュータを理解するように努め、開発者は、企業の言葉を身につけ、業務とシステムを理解するように努める。
Uni-2	ペアプログラミング	先輩と後輩、修行型で仕事を進める。
Uni-3	コミュニケーション技術	報告は、簡潔に、指示者にまっすぐに、会えば必ず、結論→理由→経緯の順に実施。連絡は誰に知らせるべきかを考え、10分考えて分からないことは必ず人に聞く。最後に、確認では自分の言葉で言いなおし、相手の了解を得る。
Uni-4	非分業の原則	自分ですべてできるセル開発方式。メンバ全員が自律的に仕事をして、チームワークと分業を体感。自分でやり失敗することで学ぶ。
Uni-5	作り捨てとコピーライト	自分が作ったものへのこだわりを捨てる一方、自分が作ったものの責任は取る（諦観と責任）。人の書いたプログラムをコピーしたら、すべての責任はコピーした人にある（新コピーライト）。
Uni-6	ワンプログラム・ワンフロー	データはファイルでわけ、IFやフラグ、区分を使わないようにする。インクルード処理を禁止し、各スクリプト内にすべて記述する。
Uni-7	ドキュメンテーション	①ネットワークやハードウェア全体図は必須。②タイミングチャート、データ配置図、バッチ処理概要等は必要に応じて書く。③システム全体を理解するための資料は必須ではない。④その仕様書さえ見ればプログラムが書けるような「詳細仕様書」は不要。
RAD-1	コミュニケーション	構造化手法やプロトタイピングを活用し、ビジネス問題とソフトウェアで扱う情報の特徴を理解する。
RAD-2	計画立案	複数のソフトウェアチームが異なるシステム機能に対して並行して作業を行う計画を立案。最も重要なプラクティス。
RAD-3	モデリング	３つの主要な側面（①ビジネスモデリング、②データモデリング、③プロセスモデリング）からなり、RADの構築アクティビティの土台となる設計表現を確立。
RAD-4	構築	既存のソフトウェアコンポーネント、及び自動コード生成アプリケーションの利用を重視。
RAD-5	展開	必要に応じて次回以降の反復の基礎を確立。