アジャイルソフトウェア要求(株式会社オージス総研 藤井拓 Dean Leffingwell)|翔泳社の本
  1. ホーム >
  2. 書籍 >
  3. アジャイルソフトウェア要求

アジャイルソフトウェア要求


監訳

形式:
書籍
発売日:
ISBN:
9784798135328
価格:
本体5,200円+税
仕様:
B5変・472ページ
分類:
開発管理

本書籍の他の形式を確認する

  • このエントリーをはてなブックマークに追加

高度化・大規模化が進む問題解決に対する回答の決定版



・- アジャイルソフトウェア開発では、ソフトウェアに対する要求をどのように定義すればよいか
・- アジャイルソフトウェア開発では、要求を定義する役割をどのように担えばよいか
・- 1つのプロジェクトを超えた大規模プロジェクトへのスケールアップや企業全体のポートフォリオ管理との関係はどうなるのか
・- アジャイルソフトウェア開発ではアーキテクチャを先に考えなくてよいのか

こうした「従来のソフトウェア要求技法」では解決できない課題が増加するなか、「ソフトウェア要求」に関する第一人者である著者が多くの著名人の協力のもとに書き上げた詳細な技法書です。「アジャイル開発技法」と「ソフトウェア要求技法」の基本的な概要解説から、上記のさまざまな課題に関する高度で詳細な解決手法まで幅広く網羅し、まさしく専門分野の定番としてふさわしい内容構成になっています。


第I部概観:全体像1

第1章 ソフトウェア要求手法の短い歴史

1.1ソフトウェア要求が置かれた状況:何十年間ものソフトウェアプロセスモデルの進歩
1.2予測に基く、滝のようなプロセス
 1.2.1このモデルの問題点
 1.2.2ウォーターフォールモデルにおける要求:鉄の三角形
 1.2.3それでも、ウォーターフォールモデルは依然として我々の間に存在する
1.3反復的に追加するプロセス
 1.3.1スパイラルモデル
 1.3.2ラピッドアプリケーション開発
 1.3.3ラショナル統一プロセス
 1.3.4反復開発における要求
1.4適応(アジャイル)プロセス
 1.4.1アジャイル宣言
 1.4.2エクストリーム・プログラミング(XP)
 1.4.3スクラム
 1.4.4アジャイルにおける要求は根本的に違う
1.5企業規模の適応プロセス
1.6リーンソフトウェア入門
 1.6.1リーンソフトウェアの殿堂
 1.6.2ソフトウェア要求のシステム的観点
 1.6.3カンバン:もう一つのソフトウェア手法の出現
1.7まとめ

第2章 アジャイル要求の全体像

2.1全体像の説明
 2.1.1全体像のハイライト
2.2全体像の要素:チームレベル
 2.2.1アジャイルチーム
 2.2.2アジャイルチームにおける役割
 2.2.3反復
 2.2.4ユーザーストーリーとチームバックログ
2.3全体像の要素:プログラムレベル
 2.3.1リリースと潜在的に出荷可能なインクリメント
 2.3.2ビジョン、フィーチャー、プログラムバックログ
 2.3.3リリース計画
 2.3.4ロードマップ
 2.3.5プロダクト管理
2.4全体像の要素:ポートフォリオレベル
 2.4.1投資テーマ
 2.4.2エピックとポートフォリオバックログ
 2.4.3アーキテクチャー滑走路
2.5まとめ

第3章 チームのためのアジャイル要求

3.1チームレベルへの導入
 3.1.1なぜチームについて論じるのか?
 3.1.2機能サイロを取り除く
3.2アジャイルチームの役割と責任
 3.2.1プロダクトオーナー
 3.2.2スクラムマスター/アジャイルマスター
 3.2.3開発者
 3.2.4テスト担当者
 3.2.5他のチーム/プログラムの役割
3.3ユーザーストーリーとチームバックログ
 3.3.1バックログ
 3.3.2ユーザーストーリー
 3.3.3ユーザーストーリーの基本
 3.3.4タスク
3.4受け入れテスト
3.5単体テスト
 3.5.1リアルタイムに本当の品質を
3.6まとめ

第4章 プログラムのためのアジャイル要求

4.1プログラムレベルの導入
4.2アジャイルチームを大きな規模で組織化する
 4.2.1フィーチャーチームとコンポーネントチーム
 4.2.2システムチーム
 4.2.3リリース管理チーム
 4.2.4プロダクト管理
4.3ビジョン
4.4フィーチャー
 4.4.1新たなフィーチャーがプログラムバックログを作る
 4.4.2フィーチャーをテストする
4.5非機能要求
 4.5.1バックログの制約としての非機能要求
 4.5.2非機能要求をテストする
4.6アジャイルリリース列車
 4.6.1リリースと潜在的に出荷可能なインクリメント
 4.6.2リリース計画
4.7ロードマップ
4.8まとめ

第5章 ポートフォリオのためのアジャイル要求

5.1ポートフォリオレベルの導入
5.2投資テーマ
5.3ポートフォリオ管理チーム
5.4エピックとポートフォリオバックログ
 5.4.1ポートフォリオバックログ
5.5エピック、フィーチャー、そしてストーリー
5.6アーキテクチャー滑走路とアーキテクチャーエピック
 5.6.1アーキテクチャーエピックを実装する
 5.6.2アーキテクチャー滑走路:ポートフォリオ、プログラム、チーム
5.7まとめ
5.8企業要求情報モデル全体のまとめ
事例:テンドリル・プラットホーム81

第II部チームのためのアジャイル要求

第6章 ユーザーストーリー

6.1導入
 6.1.1ユーザーストーリーの概要
 6.1.2ユーザーストーリーは開発者と顧客のコミュニケーションギャップを橋渡しする
 6.1.3ユーザーストーリーは要求ではない
6.2ユーザーストーリーの形式
 6.2.1カード、会話、そして確認
 6.2.2ユーザーストーリーの声
 6.2.3ユーザーストーリーの詳細
 6.2.4ユーザーストーリー受け入れ基準
6.3良いユーザーストーリーにおけるINVEST
 6.3.1独立している
 6.3.2交渉でき…そして交渉される
 6.3.3価値がある
 6.3.4見積もりができる
 6.3.5小さい
 6.3.6テストできる
6.4ユーザーストーリーを分割する
6.5スパイク
 6.5.1技術的なスパイクと機能的なスパイク
 6.5.2スパイクのガイドライン
6.6索引カードによるストーリーモデリング
6.7まとめ

第7章 利害関係者、ユーザーペルソナ、ユーザーエクスペリエンス

7.1利害関係者
 7.1.1システム利害関係者
 7.1.2プロジェクト利害関係者
 7.1.3利害関係者の声:プロダクトオーナー
 7.1.4利害関係者の関与のレベル
 7.1.5利害関係者の信頼を築く
 7.1.6利害関係者とのやり取り
7.2利害関係者を識別する
 7.2.1プロジェクト利害関係者を識別する
 7.2.2システム利害関係者を識別する
 7.2.3システム利害関係者を分類する
 7.2.4システム利害関係者のニーズを理解する
 7.2.5利害関係者/プロダクトオーナーチーム?
7.3ユーザーペルソナ
 7.3.1主と副ユーザーペルソナ
 7.3.2ユーザーストーリーモデリングによりペルソナを見つける
7.4アジャイルとユーザーエクスペリエンス開発
 7.4.1ユーザーエクスペリエンスの問題
 7.4.2ユーザーインターフェース開発のための忠実度が低い選択肢
 7.4.3UXストーリースパイク
 7.4.4集中したUX開発
 7.4.5分散され、統制されたUX開発モデル
7.5まとめ

第8章 アジャイルな見積もりとベロシティー

8.1導入
 8.1.1この狂気には筋が通っている
 8.1.2ゴールは同じである:より信頼できる見積もり
8.2なぜ見積もるか?見積もりのビジネス価値
8.3ストーリーポイントでスコープを見積もる
8.4ストーリーポイントを理解する:演習
 8.4.1演習パート1:相対見積もり
 8.4.2演習パート2:プランニングポーカーで実作業を見積もる
 8.4.3見積もりにどのぐらいの時間を費やすべきか?
 8.4.4見積もりに対する注意のたとえ話:ストーリーの中のストーリー
 8.4.5オンラインプランニングポーカーによる分散見積もり
8.5代わりのテクニック:机上での相対見積もり
8.6スコープの見積もりからチームベロシティーへ
 8.6.1演習パート3:ベロシティーを確立する
8.7相対見積もりモデルに対する警告
 8.7.1もう一つのたとえ話:ベロシティーを増やす、求めることに気をつけよう
8.8ベロシティーから期間と費用へ
 8.8.1期間を見積もる
 8.8.2費用を見積もる
8.9理想開発者日で見積もりする
8.10ハイブリッドモデル
 8.10.1ベロシティーを正規化する
8.11まとめ

第9章 反復、バックログ、スループット、そしてカンバン

9.1反復する:アジャイルさの鼓動
 9.1.1反復の長さ
 9.1.2反復のパターン:計画、実行、レビューと振り返り
 9.1.3チームバックログ
 9.1.4反復を計画する
 9.1.5反復の確約
 9.1.6反復を実行する
 9.1.7追跡し、調整する
 9.1.8レビューと振り返り
 9.1.9フィーチャーの下見
9.2バックログ、リーン、そしてスループット
 9.2.1バックログの成熟度、リーン、そしてリトルの法則
 9.2.2ブログの話:形式が整ったプロダクトバックログはチームのアジャイルさを低下させるか?
 9.2.3リトルの法則とアジャイルチームのバックログ
 9.2.4リトルの法則を適用してアジャイルさを増し、市場への投入時間を減らす
 9.2.5読者の反応
 9.2.6バックログの待ち行列長を制御することでスループットを管理する
9.3ソフトウェアカンバンシステム
 9.3.1カンバンシステムの特性
 9.3.2カンバンにおけるサービスの種別
9.4まとめ

第10章 受け入れテスティング

10.1なぜアジャイル要求の本でテスティングについて書くのか?
10.2アジャイルテスティングの概要
10.3受け入れテストとは何か?
 10.3.1ストーリー受け入れテスト
10.4良いストーリー受け入れテストの特徴
 10.4.1それらは良いユーザーストーリーをテストする
 10.4.2あまりあいまいでなく、すべてのシナリオをテストする
 10.4.3それらは存続する
10.5受け入れテスト駆動開発
10.6受け入れテストのひな形
10.7自動化された受け入れテスト
 10.7.1自動化された受け入れテスティングの例:FITアプローチ
10.8単体およびコンポーネントテスティング
 10.8.1単体テスティング
 10.8.2コンポーネントテスティング
10.9まとめ

第11章 プロダクトオーナーの役割

11.1これは新たな役割だろうか?
11.2プロダクトオーナーとプロダクト管理者の2つの役割の捉え方
 11.2.1名前ゲーム:プロダクトオーナーの役割/肩書で実験する
 11.2.2我々の結論:2つの役割を適用する
11.3企業におけるプロダクトオーナーの責任
 11.3.1バックログを管理する
 11.3.2ジャスト・イン・タイムのストーリーの詳細化
 11.3.3反復を推進する
 11.3.4技術的負債と価値のストリームの問題
 11.3.5リリースを一緒に計画する
11.4優れたプロダクトオーナーの5つの基本的な特質
11.5プロダクト管理者との連携
11.6プロダクトオーナーのボトルネック:パートタイムのプロダクトオーナー、プロダクトオーナーの代理、プロダクトオーナーチーム
 11.6.1プロダクトオーナーの代理
 11.6.2プロダクトオーナーチーム
11.7企業にプロダクトオーナーの役割の種をまく
 11.7.1トレードステーションテクノロジー社
 11.7.2CSGシステムズ社
 11.7.3ジョンディア・インテリジェントソリューショングループ
 11.7.4ディスカウントタイヤ社
11.8まとめ

第12章 要求発見ツールキット

12.1要求ワークショップ
 12.1.1ワークショップの準備を行う
 12.1.2議題を設定する
 12.1.3ワークショップを運営する
12.2ブレーンストーミング
 12.2.1アイデア出し
 12.2.2アイデアの絞り込み
 12.2.3アイデアの優先順位付け
12.3インタビューとアンケート
 12.3.1文脈に依存しない質問
 12.3.2ソリューションの文脈に依存した質問
 12.3.3真実の瞬間:インタビュー
 12.3.4ニーズに関するデータを集める
 12.3.5アンケートに対する補足
12.4ユーザーエクスペリエンスモックアップ
12.5プロダクト審議会を結成する
12.6競合分析
12.7顧客変更依頼システム
 12.7.1欠陥のログ
12.8ユースケースモデリング
12.9まとめ

第III部プログラムのためのアジャイル要求

第13章 ビジョン、フィーチャー、ロードマップ

13.1ビジョン
13.2ビジョンを表現する
 13.2.1ビジョン文書
 13.2.2先行したデータシートアプローチ
 13.2.3予備的なプレスリリースアプローチ
 13.2.4「概要説明付きのフィーチャーバックログ」アプローチ
 13.2.5非機能要求(システム品質)を伝える
13.3フィーチャー
 13.3.1ユーザーの声形式でフィーチャーを表現する
13.4フィーチャーを見積もる
 13.4.1労力の見積もり
 13.4.2コストを見積もる
 13.4.3開発期間を見積もる
13.5フィーチャーをテストする
13.6フィーチャーの優先順位付けをする
 13.6.1ROIの代用としての価値/労力:第一近似
 13.6.2価値/労力によるROIの代用の何が間違っているのか?
 13.6.3遅延のコストに基いてフィーチャーを優先順位付けする
 13.6.4遅延のコスト(CoD)の導入
 13.6.5遅延のコストを見積もる
 13.6.6フィーチャー優先順位付け評価マトリックス
 13.6.7すべての優先順位付けは局所的で一時的である
 13.6.8差を生む価値を達成する:顧客満足の狩野モデル
13.7ロードマップ
 13.7.1次、次の次、その先のリリースに対する自信と確約
13.8まとめ

第14章 プロダクト管理者の役割

14.1プロダクト管理者、ビジネス分析者?
14.2プロダクト会社でのプロダクト管理者の責任
14.3この役割のIT/IS部門におけるビジネス上の責務
14.4責務のまとめ
14.5アジャイル以前の企業でのプロダクト管理への幻滅のフェーズ
 14.5.1フェーズ1:抑制されていない熱狂
 14.5.2フェーズ2:偽りの安心感
 14.5.3フェーズ3:突然の認識
 14.5.4フェーズ4:期待を再設定する
 14.5.5フェーズ5:持続的な不信の季節
 14.5.6持続的な不信の季節から抜け出す
14.6アジャイルな企業でプロダクト管理を進化させる
 14.6.1顧客のニーズを理解する
 14.6.2要求を文書化する
 14.6.3スケジュールを立案する
 14.6.4要求を優先順位付けする
 14.6.5要求の妥当性を確認する
 14.6.6変更を管理する
 14.6.7現状を評価する
14.7アジャイルなプロダクト管理者の責務
 14.7.1ビジョンとリリースバックログに責任を持つ
 14.7.2リリースの内容を管理する
 14.7.3ロードマップを維持する
 14.7.4効果的なプロダクト管理者/プロダクトオーナーチームを築く
14.8まとめ

第15章 アジャイルリリース列車

15.1アジャイルリリース列車入門
 15.1.1アジャイルリリース列車の論理的な根拠
 15.1.2アジャイルリリース列車の原則
15.2戦略的な方向性を揃える
15.3プロダクト開発フローを制度化する
15.4アジャイルリリース列車を設計する
15.5リリースを計画する
 15.5.1リリース目標
15.6リリースを追跡し、管理する
15.7リリースの振り返り
15.8リリースの予見性を測定する
 15.8.1リリース目標プロセス制御帯
15.9リリースする
 15.9.1ARTと同じリズムでリリースする
 15.9.2ARTのリズムよりも少ない頻度でリリースする
 15.9.3ARTのリズムよりも多い頻度でリリースする
15.10まとめ

第16章 リリース計画

16.1リリース計画を準備する
 16.1.1リリース計画領域
 16.1.2計画策定への参加者
 16.1.3リリース計画ファシリテーター
 16.1.4リリース計画チェックリスト
16.2リリース計画物語、初日
 16.2.1オープニング
 16.2.2ビジネス背景
 16.2.3ソリューションのビジョン
 16.2.4アーキテクチャービジョン
 16.2.5チームに分かれての計画策定
 16.2.6計画の下書きのレビュー
 16.2.7管理者のレビューと問題解決打ち合わせ
16.3リリース計画物語、2日目
 16.3.1オープニング
 16.3.2計画の調整:共同戦線
 16.3.3計画策定の続き:チームに分かれての計画セッションII
 16.3.4リリース目標を確立する
 16.3.5最終的なリリース計画レビュー
 16.3.6リスクと障害に対応する
 16.3.7確約
 16.3.8計画策定振り返り
 16.3.9チームへの最後の指示
16.4背伸び目標
16.5まとめ

第17章 非機能要求

17.1非機能要求をモデリングする
 17.1.1非機能要求をユーザーストーリーとして表現する
17.2非機能要求を検討する
 17.2.1使いやすさ
 17.2.2信頼性
 17.2.3性能
 17.2.4サポートのしやすさ(保守性)
 17.2.5設計制約
17.3非機能要求を保管する
17.4非機能要求をテストする
 17.4.1使いやすさ
 17.4.2信頼性
 17.4.3セキュリティー
 17.4.4性能
 17.4.5サポートのしやすさと設計制約
17.5非機能要求のひな形
17.6まとめ

第18章 要求分析ツールキット

18.1アクティビティー図
18.2帳票の見本
18.3疑似コード
18.4決定表と決定木
18.5有限状態マシン
18.6メッセージシーケンス図
 18.6.1メッセージシーケンス図の限界
18.7実体関連図
18.8ユースケースモデリング
18.9まとめ

第19章 ユースケース

19.1ユーザーストーリーとバックログ項目の問題
19.2ユースケースを使い続ける5つのもっともな理由
19.3ユースケースの基本
 19.3.1ユースケースのアクター
 19.3.2ユースケースの構造
 19.3.3ユースケースモデルを構築するためのステップ・バイ・ステップガイド
19.4ユースケースの例
19.5ユースケースを適用する
 19.5.1アジャイルでユースケースを適用するためのコツ
19.6アジャイル要求情報モデルにおけるユースケース
19.7まとめ

第IV部ポートフォリオのためのアジャイル要求

第20章 アジャイルアーキテクチャー

20.1全体像のポートフォリオレベルの導入
20.2エンタープライズ級のシステムにおけるシステムアーキテクチャー
 20.2.1アジャイルですべてのアーキテクチャーが現れるか
 20.2.2意図的なアーキテクチャーの必要性
 20.2.3アーキテクチャーエピックを推進するビジネス要因
 20.2.4アジャイルな企業におけるシステムアーキテクトの役割
20.3アジャイルアーキテクチャーの8つの原則
 20.3.1原則1:システムのコーディングをするチームがシステムの設計もしなければならない345  20.3.2原則2:正しく動作し得る中で最もシンプルなアーキテクチャーを構築する
 20.3.3原則3:疑わしいときはコードを書くかモデルを作成して確認する
 20.3.4原則4:構築したらテストする
 20.3.5原則5:システムが大きいほど滑走路を長くとる
 20.3.6原則6:システムアーキテクチャーは役割間の協調である
 20.3.7原則7:イノベーションに独占はない
 20.3.8原則8:アーキテクチャーフローを実装する
20.4アーキテクチャーエピックを実装する
 20.4.1状況A:大規模だが段階的、システムは常時稼働
 20.4.2状況B:大規模だが完全に段階的ではなく、システムを時々止める必要がある
 20.4.3状況C:非常に大きくかつ段階的でなく、システムは必要なときに稼働、害を及ぼさない355 20.5アーキテクチャーエピックを分割する
20.6まとめ

第21章 フローによるアーキテクチャーの再設計

21.1アーキテクチャーエピックのカンバン方式
 21.1.1カンバン方式の目的
21.2アーキテクチャーエピックのカンバン方式の概要
 21.2.1待ち行列の解説
 21.2.2アーキテクチャーエピックの状態の解説
21.3 1.じょうご:問題/ソリューションのニーズの特定
 21.3.1新しいアーキテクチャーエピックの情報源
 21.3.2作業:エピックの評価
 21.3.3仕掛かり作業制限
 21.3.4意思決定権限者
21.4 2.バックログ
 21.4.1作業:リズムベースのレビュー、議論、待ち行列内での評価
 21.4.2優先順位および評価方式
 21.4.3重み付けされた評価値と判断基準
 21.4.4バックログから分析へのプル
 21.4.5仕掛かり作業制限
21.5 3.分析
 21.5.1作業
 21.5.2開発チームとの連携
 21.5.3ビジネスとの連携:ソリューション管理、プロダクト管理、ビジネス分析者
 21.5.4仕掛かり作業制限
 21.5.5アーキテクチャーエピック用のビジネス企画テンプレート
 21.5.6意思決定権限者
21.6 4.実装
 21.6.1実装方針A:開発への移行
 21.6.2実装方針B:新チームの作成
 21.6.3実装方針C:開発のアウトソーシング
 21.6.4実装方針D:ソリューションの購入
 21.6.5仕掛かり作業制限
21.7まとめ

第22章 アジャイルポートフォリオ管理への移行

22.1ポートフォリオ管理
22.2アジャイルチームがPMOと出会うとき:暗闇ですれ違う2隻の船
22.3従来型の発想では企業はアジャイルになれない
 22.3.1「彼らの」問題ではなく「自分たちの」問題である
22.4ポートフォリオ管理における従来型の発想
22.5アジャイルポートフォリオ管理へ移行するための8つの提案
 22.5.1投資財源の見直し
 22.5.2変化の管理の見直し
 22.5.3ガバナンスと監視の見直し
22.6まとめ:アジャイルポートフォリオ計画へ

第23章 投資テーマ、エピック、ポートフォリオ計画

23.1投資テーマ
 23.1.1投資テーマの伝達
 23.1.2バックログの優先順位ではなく投資構成を使用する理由
23.2エピック
 23.2.1サブエピック
 23.2.2エピックの表現
 23.2.3エピック、フィーチャー、ストーリーの描写
 23.2.4エピックの種類
23.3ビジネスエピックの特定と評価:ポートフォリオ計画のカンバン方式
 23.3.1概要
 23.3.2状態図
 23.3.3じょうご:問題/ソリューションのニーズの特定
 23.3.4バックログ
 23.3.5分析
 23.3.6実装
23.4まとめ

第24章 終わりに

24.1これ以上の情報

付録

A文脈に依存しないインタビュー
Bビジョン文書テンプレート
Cリリース計画準備チェックリスト
Dアジャイル要求の企業バックログメタモデル
参考文献

本書は付属データの提供はございません。

書籍への問い合わせ

正誤表、追加情報をご確認の上、こちらよりお問い合わせください

書影の利用許諾について

本書籍に関する利用許諾申請はこちらになります

追加情報はありません。

ご購入いただいた書籍の種類を選択してください。

書籍の刷数を選択してください。

刷数は奥付(書籍の最終ページ)に記載されています。

現在表示されている正誤表の対象書籍

書籍の種類:

書籍の刷数:

本書に誤りまたは不十分な記述がありました。下記のとおり訂正し、お詫び申し上げます。

対象の書籍は正誤表がありません。

最終更新日:2014年03月13日
発生刷 ページ数 書籍改訂刷 電子書籍訂正 内容 登録日
1刷 039
7行目(「2.4.1 投資テーマ」の直前)
を作る。を作る。
を作る。
2014.03.13