imageプラグインエラー : 画像を取得できませんでした。しばらく時間を置いてから再度お試しください。
プロジェクトがだめになるのはなぜか
チームメンバーが誰もいないところで合意したことを前提にしているから
インセプションデッキ
プロジェクトのはじめの段階で手強い質問をする
| 我々はなぜここにいるのか |
プロジェクトの始まった理由 |
| エレベーターピッチ |
30秒以内にプロジェクトをアピールする |
| パッケージデザイン |
プロジェクトの広告を作る |
| やらないことリスト |
プロジェクトでやらないことをはっきりさせる |
| 「ご近所さん」を探せ |
プロジェクトの関係者 |
| 解決策を描く |
概要レベルのアーキテクチャ設計図 |
| 夜も眠れない問題 |
プロジェクトのリスク |
| 期間を見極める |
プロジェクトの期間 |
| 何を諦めるのか |
期間、スコープ、予算、品質の優先順位をつける |
| 何がどれだけ必要か |
期間、コスト、必要なメンバ |
よく書けているユーザーストーリー
ユーザーストーリー：顧客がソフトウェアで実現したいと思っているフィーチャを完結に表現したもの
「要件」ではない、顧客が欲しがっているものの本質
- ビジネスの観点から評価できる
- エンドツーエンド アーキテクチャのすべてのレイヤを貫いている
- 独立している
- 交渉の余地がある
- テストできる
- 小さい、見積もれる
見積り
概算見積りなんてあてずっぽうだ（本当にテキトウだし、しかも楽観的すぎる）
計画づくり
| マスターストーリーリスト |
プロジェクトでやるべきことを重要なものから順にリストにする |
| バーンダウンチャート |
残作業量を時系列に並べる |
| バーンアップチャート |
完了作業量を時系列に並べる |
イテレーションの運営
- 分析と設計：作業の段取りをする 「必要な分だけを、必要なときに」
- 開発：作業する
- テスト：作業の結果を確認する
最終更新：2012年03月27日 19:56
