Readingagilesamuraiinhde20130820
Akira Kusumoto edited this page Aug 20, 2013
·
1 revision
範囲：P.73-98
- 問題の整理・再認識につながる
- 解決策が自分で見つからなかった時に、人に説明することによって何か見つかることもある
- 「書きだしたものを破り捨てる」 ** 課題が解決したことがわかりやすい（倒した！）
- 「その理屈はおかしい」と話せる場は大事
- 理屈はわかるが、現実的には難しいことが多い
- 現実的にはスコープはからわず他が変化することが多い ** 予算が増えるならいいのに・・・
- 時間がかかるような場合は、細かく分割して、それぞれは時間固定 ** Phase を分けて個別にリリース ** 各Phase で使えるものができるならいいのでは？
- 避けられないリスクだが、実際にはよくありそうだ
- 取り組む値打ちがない！と切り捨ててしまうのはひどい！
- 回避できるものではないが、起きた時の対策を考えておくのは有用
- 「低スペックのPC」は確かにリスク→変えてもらって進めた
- 仕様書を作ること？
- ドキュメントの代わりになるものを数日でさっくりざっくり作る
- アジャイルサムライの日本グループがテンプレを公開している
- 規模は大きくても小さくても関係ないのでは？ ** どんなプロジェクトでもこの期間に当てはめたほうがよい？ ** 経験則？ ** 7章で納期の決め方について記載している（乞うご期待！）
- 人によって意識が違うので、可視化することによって、方向性が揃えられるのではと思った
- 何を最も優先するかをチームで意識を揃える
- 全部MAXにはするな！
- 「こういったところが楽しい」などの部分も大事
- もとはアメリカの話だが、日本では？
- どういうこと？ ** アーキテクチャを図に書くこと？ ** 新しくシステムを作る場合はアーキテクチャの図 ** Webサイトの場合はその遷移図、などのように場合により色々ある
- 計画はあてずっぽうであることを、顧客に理解してもらう
- 信頼性のある計画は検証などして決める
- 期日を固定する、との整合性は？ ** 最初は固定せずに、後で固定する？
- 営業とマネージャーからの指示が違って困った事があった！（←ふざけるな！） ** 解決しなかった・・・orz
- 最終判断を下す人を決めておくのは重要