Readingagilesamuraiinhiroshima20120529 - agile-samurai-ja/support GitHub Wiki

アジャイルサムライ読書会 in 廣島道場（第七回）

記録

今回で七回目を迎えた廣島道場ですが、１２名の参加ということで参加者の皆さん有難うございました。人数もそうですがレベル（参加者のスキル、討論内容）も上がってきておりなんだか嬉しいです。（私も負けずについていきたいと思います）開始の前に、別の異業種交流会に参加し少しビールを頂いていたので、調子よく中身のないことをペラペラ喋ってしまったかもしれませんが（記憶には無いｗ）、参加者の方にはご迷惑をお掛けしました。次回は、会場予約の関係で３週間後の６月１９日に予約入れました。もう五人を割ることはないという判断で、その次の７月３日まで予約入れましたので、みなさんよろしくお願いします。第８章は、見積の最終章なのですが、より実践的な内容であり、討論も盛り上がって喧々諤々となりました。（違った印象ならwikiで書いてください^_^;）

ふりかえり（約５分）８章が35Pで長いのと、前回参加者が多かったので短くしました。

六回目の記録を元に、説明を行いました。
Reading Time（約30分）

##　8. アジャイルな計画作り：現実と向き合う

信頼の置ける計画の立て方と、チームがコミットメントしたことをやり遂げる為の方法　いつチームがコミットメントしたんだ！いままでは確定ではなかったのではないか！（参照8.2）　ベロシティをふまえた計画にはチームでコミットメントするとある（参照8.4）

##　8.1. 固定された計画の問題

お客さんが自分達の本当に欲しかったものに気付いた・・・構え→狙え→打て、ではなく、構え→打て→狙え→撃て→狙え→撃てはマーケティングや事業戦略でも同じことが言われている。とにかく撃つ（出荷する）ことが大事で、後に軌道修正する。
ベロシティ（速度）を二倍にしろという考え方は非常に危険だと思うぞ。
「よしテストをはぶこう！」は原文にもあるのかｗ→要確認（ペンディング）

##　8.2. アジャイルな計画づくり

ベロシティー＝速さ、SPEEDを格式ばって言うもの、音楽MIDIの音の大きさ
その時、普通はスコープを調整して対処する。→出来るのかー

##　8.3. スコープを柔軟に

「お客」と「対等」に「正直」に「ありのまま」を、これってアジャイルでなくても同じなのではないだろうか。
出来ないの？　と言われるとつい「出来なくは無いです」と言ってしまう、悪い癖があります。

##　8.4. 初回の計画づくり

製造上の部品化（例えば似通った帳票があったとして）から考えれば、それを連続して開発すると効率的である、それをユーザーストーリーの優先順位で開発すると非効率になるのは、どのように考えれば良いのか。
縦に1,2,3,4,5↑ｱ､ｲ､ｳ､ｴ､ｵ↑A,B,C,D,E　と書くのと、横に1､ｱ､A→2､ｲ､B→3､ｳ､C→4､ｴ､D→5､ｵ､E　と書くのでは効率が倍以上違う（それは違う）　　
ユーザーの価値、開発側の価値、一致しないだろうと感じる
個人の生産性を測るのは、プロジェクトマネジメントのダークサイドへの道だ　☆
イテレーション３～４会でチームのベロシティがわかるようになる
157P 「ここまでたどり着いた時に考える」には、そーなんだと思った。

##　8.5. バーンダウンチャート

バーンダウン（火消し）がバーンアップ（炎上）にならないように
バーンアップが機能が追加されたことがわかるので、好きだ
お客さん資料にも使って良い、

##　8.6. プロジェクトを途中からアジャイルにしていく

途中からなんて出来る分けがないと思ったが、プロジェクトリセットの段階を経たら出来るかもしれないと思うようになりました。お客も目先が変わるので受入安いかも（大変だけど・・）
基本設計でFIXせずにグルグル回る場合は、とりあえず作ってみましょうとアジャイルにすることはある。命名：無し崩しアジャイル

##　8.7. 現場で実践する

シナリオ立てのストーリーは良かったが、スコープ削減一辺倒はどうか、要員追加のケースもあるのではないか（そもそもそれが組み込まれているケースが多い）
二次開発とか保守開発とかだと、アジャイルはうまくいく。（渋谷道場出席者より）
パーキングロッドチャートは「アジャイルな見積と計画づくり」で説明されている。

その他出た話

ＯＳＣ広島は１０月２０日に開催の予定です

場所は、広島国際学院大学（瀬野キャンパス）ですので、興味ある方は参加をお願いします。