Readingagilesamuraiinhde20130820 - agile-samurai-ja/support GitHub Wiki

範囲：P.73-98

第5章 具現化させる

失敗そうなあらゆることを書き出す(P.78)

• 問題の整理・再認識につながる
• 解決策が自分で見つからなかった時に、人に説明することによって何か見つかることもある
• 「書きだしたものを破り捨てる」 ** 課題が解決したことがわかりやすい（倒した！）
• 「その理屈はおかしい」と話せる場は大事

時間・予算・品質を固定する (P.87)

• 理屈はわかるが、現実的には難しいことが多い
• 現実的にはスコープはからわず他が変化することが多い ** 予算が増えるならいいのに・・・
• 時間がかかるような場合は、細かく分割して、それぞれは時間固定 ** Phase を分けて個別にリリース ** 各Phase で使えるものができるならいいのでは？

お客様の人事異動 (P.79)

• 避けられないリスクだが、実際にはよくありそうだ
• 取り組む値打ちがない！と切り捨ててしまうのはひどい！
• 回避できるものではないが、起きた時の対策を考えておくのは有用
• 「低スペックのPC」は確かにリスク→変えてもらって進めた

６ヶ月以内・・・

• 仕様書を作ること？
• ドキュメントの代わりになるものを数日でさっくりざっくり作る
• アジャイルサムライの日本グループがテンプレを公開している

開発サイクルは６ヶ月を超えない

• 規模は大きくても小さくても関係ないのでは？ ** どんなプロジェクトでもこの期間に当てはめたほうがよい？ ** 経験則？ ** 7章で納期の決め方について記載している（乞うご期待！）

何を諦めるのかをはっきりさせる (P.84)

• 人によって意識が違うので、可視化することによって、方向性が揃えられるのではと思った
• 何を最も優先するかをチームで意識を揃える
• 全部MAXにはするな！

「とらえどころのないもの」を忘れるな (P.91)

• 「こういったところが楽しい」などの部分も大事

顧客の役割が文化として根付いていない (P.93)

• もとはアメリカの話だが、日本では？

解決案を描く (P.74)

• どういうこと？ ** アーキテクチャを図に書くこと？ ** 新しくシステムを作る場合はアーキテクチャの図 ** Webサイトの場合はその遷移図、などのように場合により色々ある

プロジェクトへの長さへの期待をマネジメントする (P.83)

• 計画はあてずっぽうであることを、顧客に理解してもらう
• 信頼性のある計画は検証などして決める
• 期日を固定する、との整合性は？ ** 最初は固定せずに、後で固定する？

開発チームに語りかける声はひとつにしたい (P.94)

• 営業とマネージャーからの指示が違って困った事があった！（←ふざけるな！） ** 解決しなかった・・・orz
• 最終判断を下す人を決めておくのは重要