PD-S開発・運用の方法論 · 開発の手法・方法論

インセプションデッキ

Inception Deck

いんせぷしょんでっき

アジャイル開発のプロジェクトの開始時に、目的、範囲、優先順位、リスク、体制などを「我々はなぜここにいるのか」などの10の問いに答える形で整理し、関係者の認識をそろえるための資料。プロジェクトの途中でも見直して、目的や前提のずれを確かめるのに使う。

#アジャイル開発 #プロジェクト立上げ #合意形成

共有:

他の資格での定義

APインセプションデッキ

プロジェクトの目的、範囲、優先順位、リスクなどを10項目の問いで整理し、関係者の認識を揃える資料。

A-1インセプションデッキ

プロジェクトの開始時に、関係者が目的、範囲、優先順位などの認識をそろえるための10個の問いからなる資料。「我々はなぜここにいるのか」「やらないことリスト」「トレードオフスライダー」などに答えて作り、プロジェクトの途中でも見直す。

Past Exams

過去問での出題

過去問で 2 回出題（応用情報技術者試験 1・システムアーキテクト試験 1）

出典: 独立行政法人情報処理推進機構（IPA）の過去問題。問題文は IPA のサイトの PDF で確認できます。「選択肢」は、問題文ではなく選択肢に出たものです。用語名で照合しているため、関係の薄い問題が含まれることがあります。

関連キーワードの用語

PD-Sウォーターフォールモデル

システム開発を要件定義、設計、実装、テスト、運用などの工程に分け、上流の工程から下流の工程へ順に進める開発モデル。各工程の成果物を確定させてから次の工程に進むので、進捗と品質を管理しやすいが、後の工程で要件の誤りや変更が分かると手戻りが大きい。要件が明確で変更の少ない開発に向く。

PD-Sアジャイルソフトウェア開発宣言

2001年に軽量な開発手法の提唱者たちがまとめた、アジャイル開発の価値観を示す宣言。プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を価値とする。あわせて12の原則が示されている。

PD-S自己組織化

チームが外部から細かく指示されるのではなく、目標の達成に向けて作業の進め方や分担を自分たちで決めて進めること。アジャイルソフトウェア開発宣言の背後にある原則では、最良のアーキテクチャ、要求、設計は自己組織的なチームから生み出されるとされる。

PD-Sユーザー機能駆動開発（FDD）

利用者にとって価値のある小さな機能（フィーチャー）を単位として、短い周期で設計と実装を繰り返すアジャイル開発の手法。全体のモデルの作成、フィーチャーの一覧の作成、フィーチャーごとの計画、設計、実装の5つの活動で進め、進捗をフィーチャーの完成の度合いで管理する。

PD-SINVEST

良いユーザーストーリーが満たすべき6つの性質の頭文字。独立している（Independent）、交渉可能である（Negotiable）、価値がある（Valuable）、見積り可能である（Estimable）、小さい（Small）、テスト可能である（Testable）を指し、ストーリーの書き方や分割の目安にする。

PD-S共同のプラクティス

エクストリームプログラミング（XP）のプラクティスのうち、開発者、管理者、顧客を含むチーム全体が共通して実践する事項。短い周期での反復、共通の用語（メタファ）、オープンな作業空間、ふりかえりなどが含まれる。