「フィードバック」の重要性ふたたび（思考実験：フィードバックのないイテレーションが続くとどうなる？）。一方「期待をマネジメントする」という視点は個人的には今まであまり意識していなかった。要注意。

事前のJIT分析の結果等を元にし、このイテレーションで最適な成果を出せる様に着手前の相談・確認、という感覚かな

イテレーション計画ミーティング内に含めてもいいのではないかと思いました。別ミーティングとして分けているのはなぜでしょう。

• 着手前の最終確認かと思いました。ですが著者の言うように好みの問題でもあるかなと思いました。（okapon_pon）
• ビジネス寄りな部分はイテレーション計画ミーティングの前に行われる現場もあるとの事

p207コラム 一部抜粋「それまで7週間のあいだ、毎週しっかりと成果を届け続けていなかったらお客さまの答えは違っていたかもしれない。しっかり仕事をこなしている姿を毎週見せていれば、時々へまをやらかしたとしても大目に見てくれるはずだ。」 ウォーターフォールでは成果を届けるのは最後の一発勝負なので、このあたりもアジャイルの良いところなのかな？と思いました。

• リベンジの機会があるという側面でもあり、逆に続けて期待に応えられなかった場合は取り戻すのに苦労するだろう

実際に本物の完成品を使ってもらうっていうのは色々な情報を引き出せそうですね

• 内製の場合などはショーケースを行っても成果(意味合い)がそれ程得られない場合が多い印象
• 定期的にまとめて、ではなく、やれる時にやった方が良い(フィードバックを得る機会は早い方がよい)
• 沢山のショーケースを順々に見せられても集中力が続かない

次のイテレーションについてもそうだけど、全体の進捗の定期的な共有にも適したタイミングという事ですね

JIT分析に相当する作業がこのミーティングの後に生じると思うのですが、どのようなタイミングで始めますか？特に、短いタイムボックスで運用しているチーム。コーディング中は「今」に集中した方が良いだろうし

• 金曜日は次のイテレーションの計画の日としてコーディングはしない等、予め想定してスケジュールする等で工夫
• 不慣れなチームだと４０分〜１時間、慣れてくれば１５分程度で終わる事も、全員が当事者意識で臨むようになると早い
• 自分から仕事を取っていく様な臨み方をしないと本当に仕事がなくなるよ、という様な運用例も

成長のチャンスの場ですね、「うまくやれたこと」は誰かにとっての「どうすればもっとうまくやれるか？」の答えかも

ふりかえり優先事項の「魔女狩りじゃない」というところが大切だと思いました。吊るし上げしてしまうケースがあるので。（たぶんソフトウェア開発だけに限らず）

「うまくやれたことは？」で褒めてもらうとやっぱりうれしいです。

• 振り返りはアジャイルにおいて２番目に重要だ(１番目はプラン二ング)
• プロジェクト単位の振り返りではフィードバックが生きる機会がない、イテレーション単位で価値が出る様にやるのが大事
• ミニ振り返りをなくすっていうのはやめた方がいい、チームが効果を感じられる様になるまで数回かかるのが普通

朝会のパターン：立ってるだけじゃないよ

• とても参考になりました

「昨日世界をどう変えたのか？」という宣言をする意図がちょっと分からないです……。

• 「こうやったらうまく問題を解決できたよ」とかですかね？（okapon_pon）
• 実際に試してみたら、自分の周りも含めて広く視点が変わる印象を受けた(少し恥ずかしくもある)

「今日は何をぶちかますつもりなのか」という表現が好きです。（ホント感想だけです。）

「JIT分析」→「ストーリー計画ミーティング」→ イテレーション →「ショーケース」→「イテレーション計画ミーティング」→「ミニふりかえり」という流れが一般的なのでしょうか？

• 振り返ってのフィードバックを以降に活かすのが大事なので、ショーケース・ミニ振り返り → イテレーション計画ミーティングの感覚が良い

「価値につながらないものが何かあったら、やめてしまおう」この考え方、好きです。逆によりチームにマッチしたアイディアがあればやってみれば、一般的なプラクティスに拘らずにやれば良いと

眠たくなる打ち合わせってありますよね。無駄なのかな？

• 価値を感じないのであれば出ないのも選択か「価値につながらないものがなにかあったら、やめてしまおう」(p215)

インセプションデッキ、リリースボード、ストーリーボード、ベロシティー、バーンダウンチャート、いずれもパッと見て必要な情報が(部外者にも直感的に)伝わるって特性がこういった場面で機能的に働いてくれそう

• ツールに縛られないように、ツールの持つ制約に惑わされないように、自分達が一番使い易いものを

社訓などは自分達で作ったり改変したりする機会はそうそうないだろうけど、これは「自分達はこうしたい・こうします」ってものだから、キチっとみんなで合意すればモチベーションの拠り所にもなりそう

議事録毎に呼び名が違う新機能名…とかって結構あったりしました

定義した用語をプログラムに反映させる、というのがすごく大事ですね。

• 営業さんからの又聞きの又聞きみたいな伝言ゲームでカオス化…というような経験

###『エリック・エヴァンスのドメイン駆動設計』 http://www.amazon.co.jp/gp/product/4798121967

• 昨今のフレームワークやアーキテクチャを扱っている人は読んでおくべし！

• 積み残しをしないで片付けていこう、そうしないと後で大変だよ、というメッセージと捉えれると良い

• 悲観は感情から、楽観は意志から

付箋写真

• ファシリテータ
• 全員が発言した、まんべんなく発言の機会があった
• デベロッパが使うアジャイルを企画者へ応用させる
• 机の配置(テーブルがあった方がいい)
• 毎回発言する
• Wikiを書く
• クーラーが直った

付箋写真

• 時間帯
• 遅刻
• 現場のコメントができず申し訳ない
• PCもってくる

付箋写真

• ファシリテータ
• トークンを渡していくとか
• 他流試合に向けて完了しよう
• エリック・エバンスのドメイン駆動設計を読む
• よりよいMTGのあり方
• 社内でアジャイルサムライの購読者が倍増したので、啓蒙頑張ります
• ミニふりかえり

---

これ以降は次回以降に実施予定ですが、忘れないためにも書きたいことがある人は事前に書いておいてください。

p280 この図は大事な手順が足りない。1の最新のコードを取得したら、テストがオールグリーンであることを次に確かめなければならない。そうでないと、以後の変更によってテストが落ちたのかどうかがわからなくなる。 -- @HIROCAST

こういうことやる人はプログラマと名乗らないで欲しい。具体的な例（あるある -- @HIROCAST

• 手元でテスト通るの確認しないでpushしてくる
• ビルド、テストが落ちた状態で帰宅する
• ビルド、テストが落ちてるのに修正せずに他のコードをコミットする
• テストが遅いからコメントアウトする。だったら、早くしろよ。
• テストが通らないからコメントアウト（削除）する。もうプログラマ辞めた方が良いですよ。

いくつか具体的に書いておく -- @HIROCAST

• 代表的なビルドエージェントは Jenkins 大抵の環境、大抵の言語、大抵のことはできる
• リポジトリ(git,svn)を監視して変更があればビルドして、メール、IRC、Skype、Growlで通知
• デプロイの自動化は capistrano が王道 大抵の環境に適応できる
• push → ビルド（テスト）→ オールグリーン → Capistranoでステージングへデプロイ を自動化すれば非エンジニアがいつでも確認できてフィードバックしてもらえる

p285 これらの4つ(ユニットテスト、リファクタリング、テスト駆動開発、継続的インテグレーション)を実践することなしにアジャイル開発を成功させることはかなり難しい。本当に難しい。難しい。難しい。 -- @HIROCAST

P286 誰かにアジャイル開発をおしつけるのはだめだ。何をするべきか口で言うだけじゃいけない。具体的に行動して、君が模範を示すんだ。 -- @HIROCAST

カンフー・パンダ スペシャル・エディション [DVD] ジャック・ブラック￥ 980

カンフー・パンダ [Blu-ray] ジャック・ブラック￥ 1,200

p306 師を仰ぎ、師を追いかけ、師に歩調を合わせ、師の意図を組み、そして自らが師になるのだ -- @HIROCAST