この章はずしんと来ました。「もうね、これは慣れてもらうしかないんだよね。」の言葉が重い。

p148の挿絵で少し迷ったのですが、アジャイルな計画づくりでは「放たれた後も軌道を調整できる矢」という意味合いなのですね

• 「構え-撃て-狙え」の元ネタは確か「達人プログラマー」だったと思います。あそこで出ていたのは機関銃で使う「曳光弾」を例えに、撃ち始めてから狙いを修正する、というお話だったかな。

• なるほど、凄いわかりやすい！

達人プログラマー―システム開発の職人から名匠への道 [単行本] アンドリュー ハント￥ 3,990

曳光弾開発について記述されてます

Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック [単行本（ソフトカバー）] Jared Richardson￥ 2,730

p145の「いつもガントチャートがぐちゃぐちゃになってしまうのはなぜなんだぜ!?!」に禿同 はじめにガントチャート作るときスケジュールもですがタスクの洗い出しも含めていつも悩んでます。

『曳光弾というのもそうだけど、「まと」自体も変動したり大きさも変わったりということもあるかも』という指摘

※ムービングターゲット

最初の計画を厳格なコミットメントとして扱うと、プロジェクトは始まる前から死んだも同然だ。の所では、アジャイルの良さ(変化に柔軟に対応していく姿勢)が活きてこないとういう意味合いと解釈しました

• アジャイルに限らず一般論としても言えるかな、と思います。最初の計画にこだわって死屍累々ってのはよく見る気が。
• 確かにそうですね！

最初の計画に固執しない事によるクライアントさんにとってのメリットをちゃんと伝える事も大事

プロジェクト開始直後は、ひと通り動作する土台を用意する工数が発生するためにベロシティが低くなる気がするが、どう対応するのが良いのだろうか？

• イテレーションゼロでの下ごしらえが効いてくるのでしょうか

p153 まず、お客さんに要求の変更はいつでも受け付けられますということと、新しくストーリーを追加した場合には既存のストーリを削る必要があるというところに納得してもらうことが大切だと思いました。追加でこれもやって欲しいというケースは往々としてありうるので。

p154の「最後には何もかもよくなりますように」と祈ってもいいだろう（これは「奇跡によるマネジメント」という有名なマネジメント手法だ)は気持ちはわかるけどそのプロジェクトにはかかわりたくないな～ その後の事実をありのままがやはり一番ですかな

• 「どうしてもやれ」という顧客の場合は、もうやるしか無い。そしてやって失敗したところで、「ほらだめだったでしょ？最初に言ったよね？」とつきつける。というプロセスを経て顧客との信頼関係を築いていく方向。
• 「一度ぐらいは、率先して死ににいく」

なぜ個人の生産性を計測しようとすると、バグと手戻りが増えるのか？自分を良く見せようとしたくなるから？(P.161)

• 同じくその理由を知りたいな、と思います。ちなみに個人の生産性を計測し、改善することを目的とする手法として、Personal Software Process(PSP)[解説記事1][解説記事2]なんてのもあります。

• 評価者が個人の生産性を重視すると、チームで協調して進める事によるバグやリスクの早期発見などの機会が生まれにくいから、でしょうか？個人の生産性もひっくるめてチームへの関与として考えると良い様な気がします

• 個人が担当タスクの完遂を焦るあまり、独断による開発が進んでしまう傾向があるからかもしれません[angler_ishikoro]

• 「生産性」という言葉には罠がいっぱい。Martin Fowlerの「生産性は計測不能」も併せて読むと面白いかもしれません。

マスターストーリーリスト上に「重み」の逆三角形が見えた！

チャートには原因や結果や兆しが見え、今、自分達はどの辺りにどういう状況でいるのか、いつやり遂げられそうかを全員で合意した状態を保てる、便利

@ryuzeeさんの資料が参考になります

[Agile]バーンダウンチャート虎の巻(資料公開) http://www.ryuzee.com/contents/blog/3548

• アジャイル的には、その日終わらなかったものは0 (ストーリー単位でDoneしたもののみ進捗として計上)。
• バーンダウンチャートは、デイリーで書くべき。2ヶ月のプロジェクトでも2日で遅れると判断できる。たとえば、1つのストーリーに対して、70%の進捗を達成できない日が続いた場合は、これはもう確実に遅れるといえる。

どれも動かせないプロジェクトで変化に対応しようとする場合、不要となったストーリーを発見して捨てる、というのは言われてみれば当たり前だけど、得心しました。しかし、P.173 シナリオ 2 のように、進みが予想より遅かった場合で、プロジェクトに変更がなく捨てられるユーザーストーリーが発見できないという場合は炎上するほかないのでしょうか。

• どうしようもないなら炎上するしかない、が、いち早く炎上する見通しが立つのがアジャイルの利点の一つなので、先に顧客に伝えるなど、できることをやれば解決の糸口が見つかるかもしれない。

ウォーターフォールモデルだと計画失敗のしわ寄せを下流工程がもろに食って不利益を被っていたが、 アジャイルだとそれが減ると感じた（悪く言えばフィーチャーを諦めることで顧客が我慢する）

悪い知らせは早めに伝えるのがアジャイル開発の流儀だ、とあり、完全な解決はできないかもしれないけど早期発見で対策が早いほど損失を小さくできるのかなと感じた

• アジャイルとWFに例えると、問題を先に出せるか、問題を後から出るか

挿絵の「ﾌｧｰﾝﾌｧｰﾝ ｳｨｰﾋｯﾀﾞｽﾃｰｯｽﾃｰ」とは…p178

なぜchoo choo trainなんだ　http://youtu.be/Rs1ynO9x0OA?t=1m29s

原書のセリフを検索すると出てきた動画。チューチュートレインって言ってますね。 YouTube: Chugga Chugga Choo Choo

• ７章８章を詳しく知りたい場合は、本書の角谷氏が監訳をつとめた下記の書籍がとても参考になる。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ [単行本（ソフトカバー）] Mike Cohn￥ 3,360

p.178 の絵に、荒ぶる四天王の一つ「品質」が入っていないのはなぜ？という疑問に対して、

• テストの品質を下げるとか、ソースが汚いとかは許せるってことかな、という意見
• 品質という言葉の定義が色々変わるから入っていないのかな、という意見

p.185のフィードバックループの絵重要。イテレーションをやりっ放しにして積み上げていってもろくなことにならない。ちなみにフィードバックループの重要性は「ワインバーグのシステム思考法」でも書かれている。

ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉 [単行本] G.M.ワインバーグ￥ 1,049

• ウォーターフォールのフィードバックが国防総省に採用された時点で削除されてしまった件は以下の動画参照。

YouTube:The Rise And Fall Of Waterfall

フィードバックはやる方も本当に真剣にやってもらわないと困る。週終わりとかでドカッと持ってこられてもムリ。

ジャストインタイム分析として次のイテレーションが始まるまでに突っ込んだ分析が完了するサイクルがテンポよくハマるとベストだが、予想以上に時間が掛かってイテレーションの前半に割り込んでしまったとしても「必要なとき、必要なだけ」でやれば平行して柔軟に対応もできるという事か

• このイテレーションでは着手しない方が良いのであればそうする、という判断ができる事も大事

ソフトウェア開発の三本柱「バージョン管理・テスティング・自動化」の準備をイテレーションゼロでしておくと良いという事ですね

ペーパープロトタイプって、、、

• HTML で提出を求められるのってなんでなの、という疑問 -> 見積もり提出時にそれがあると分かりやすいっていう、上の方の判断がある風潮が定着しちゃったのでは、という意見。
• 協力会社と HTML ではなくてペーパープロトタイプでやるようにした経験ありが、コミュニケーションで成り立っている信頼関係がキモだった、という経験談。

開発期はイテレーションが向き、運用時はカンバンが向くという事でしょうか？実際にどんな案件でカンバンをされた事がありますか？

P199 ・イテレーションのプレッシャーから解放される によると、運用を担当するチームでも本番環境で問題が発生した場合からも解放されるとある。なぜ解放されるのだろうか？

わざわざ明示的に見せているのは、管理する方も、聞かれる方もそれなりのコストがかかるから、という意見。