Readingagilesamuraiinsapporo20120117

第12回読書会

• 2012年01月17日 19:00-21:00
• エスプランニング開発室
• 参加者 9人
• 8.1 ～

8章 アジャイルな計画づくり：現実と向き合う

8.1 固定された計画の問題

前回の復習。

• 間違ったマネジメントとアジャイルな計画作りと対比しているけど、正しいマネジメントとアジャイルな計画作りを対比したほうがよいと思う
• そもそも「固定化された計画」はよくないマネジメントなのでそこは気をつけて読んだほうがよいよ

8.2 アジャイルな計画作り

• 個人の力量はあるけれど「チームで」全体量をやるという形（できる人が自ら仕事を引き受ける形）は双方のモチベーションが保たれると思う -> これは「アジャイルな計画」だから？

  • 小さなプロジェクトで特性に合わせてタスクを取っていくと同じようなやり方になるよ
    • マネージメントの問題
  • 縦割りだと仕事分散ができない
  • 余裕がないと手が早い人がどんどん片付けていく(ボードからカードをはがしていく）ことになる
    • スキル差があるとおいてけぼりになる
    • 早い段階でのコードの共有

• 最大の問題は「プロジェクト計画は厳格なコミットメントじゃなくて予想」ということを相手（お客さん）は求めていない。相手はコミットメントを求める。

  • コミットメントを求めるところとアジャイル開発をするのは無理？
    • 契約をカチっとする（期間、お金、工数）ことを求めているところとは難しいかも
  • コミットメントの意味は広いね
    • チームを買ってくれるという形だと違うけど、通常は成果物に対しての約束
  • そうすると、契約でバッファを取るということが解決策になるのかな
    • あんまりお互いに得しないけど
    • 保険料（失敗できないから）、自分のお金じゃないから、失敗するよりも常にバッファをつんでおくほうが幸せだったり
    • 3倍のバッファを予算に入れて大手に頼むのであれば、3分の1の価格で3社に頼む方が成功する確率が上がったりして…
  • 「はじめの方に全てを決めないほうがお互い得ですよ」というのを納得してもらうとか
    • 「あまったら返します」も納得しやすいのかもしれないね
      • どういう契約になるんだろう？ -> 現実「お金を返す」契約って見たことがない
      • やれないことはないと思う（追加費用の申請とか）
    • 英和さんの価値創造契約ってどんなのだろう
  • どちらにせよ信頼関係が大切
  • 発注側の気持ちを変える事が難しいよね
  • 対お客さんだけでもなく対社内（営業の人とか）についても考えなければいけないね
  • あとは圧倒的な生産性でカバーできるようにという考え方もあるかも

8.3 スコープを柔軟に

• アジャイルサムライの道が簡単だなんて言った覚えはない
  • お客さんとの関係が作れていなくても後者であるべき
    • 判断してもらえるまで待つ、正直に言う
    • 気まずくなる -> 打ち切られることもあるかもしれないけど、そのくらいの覚悟を持って悪循環を断つ必要がある
• 自社開発の場合はどうすればいいだろう(お客さん＝会社との関係を崩せない）
  • 「説明」することに力を入れる（根拠を示す）
  • 解決案もあわせて提案する
  • アラートを上げ続ける
  • 同じ会社＝味方だと思うこと
    • 同じ方向から「一緒に問題を考える」
  • 社内だからわかりやすいこともあると思う（どうすれば嬉しいか、目的が何か、というのが見えやすい）
  • 仲間を見つける、バディを見つける
  • まだできることはありそうだから、いろんなことを実践してみたい！
• 「共犯者になろうとしちゃだめだ」はすごくよい言葉
  • できないことを「できます」というのも共犯
  • 敵じゃないことと共犯者になるというのは違うところが難しいね
    • 正しいことを一緒にやれるかどうかだよね
• 「前の担当者がひどかった」などのマイナス要因からのスタートはつらい
• タイポは#19 に載っていた

8.4 初回の計画作り

1. マスターストーリーリストを作る

• スタンディッシュグループの調査結果
  • 資料が古い、新しいのってあるのかな
  • 機能をどう数えるかによっても割合って変わるよね
• ソフトウェアは「よく使う」以外は後から追加することができる
  • ソフトウェアの特徴だよね
• 「MMF」
  • リーンだと？
  • 市場価値「M」は誰がどう作るのか
    • 顧客目線でどのような価値を生み出すか
• 文章の誤り #2

2. プロジェクト規模を見極める

3. 優先順位をつける

• 顧客に優先順位をつけてもらうというところが難しいよね
• これができてないとこれができない、というので決まる順位は結構ある
• そう考えていくと、ファーストリリースで市場価値のあるものを届けようとすると大きくなるよね
  • ケーキを1ピースだけ作るとすると最初の数個のコストは上がる
  • ファーストリリースでとりあえず出しても動かしてもらえなかったり
  • フィードバックもお客さんの価値にできるよね
• 最初のころは市場価値のないもの（基盤）をたくさん作っていかないといけないので進んでいないように見えたり
• 技術的リスクだけじゃなく、仕様や使用感のリスクの高いものも前に持っていきたい
  • 早めに触ってほしいものは先に出したい

4. チームのベロシティを見積もる

• マスターストーリーに入らないもの（環境構築、学習コスト）をどう取り込んでいけばいいか * 前半のベロシティは伸びない前提でやっていくのがいいのかな * 「慣れ」「加速」までの時間はあるものとしたほうがよい * ずっと先のことはある程度見積もりの精度が出てから出したほうがいい（出せるなら）
• 完了とは完了のことだ
  • ストーリーの終わりを定義する
  • 完了条件を意識することは大事
• はじめられる状態になっていることが大事
  • お客さんとの間やチーム間でも最初に意識をあわせておくこと大事
• 「できる状態になっているか」の見せ方が難しい
  • 打ち合わせ、慣れ・経験、複雑だとアローダイアグラムとか
    • それを計画に落としていく感じ（経験則）

5. 期日を仮決めする

• 期日の調整の方法はマネジメントのごく一般的な方法、アジャイル的な方法ではないよ

---

次回は1/31（火） 8.5- になります