Readingagilesamuraiinsapporo20120131

第13回読書会

• 2012年01月31日 19:00-21:00
• エスプランニング開発室
• 参加者 5人
• 8.5 ～ 8.7

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

8.5 バーンダウンチャート

• みんな、どういう形でバーンダウンチャート使っている？
• IssueTrackingツールの1ページだとあんまり使わないよね
• 模造紙に書いてみんなに見えるような形にしたほうが良い
  • 全員で共有しておく、常に目に触れておくことが大事
  • そこそこの大きさ(A3)で目に付く事が大事
• みんなバーンダウンチャートを日常的に使っている？
  • あんまり使ってないなぁ
    • 振り返りの時に見たりするけれど、日常的にチャートを目にしてはいないかな
      • pivotal trackerのチャートを見せてもらいました
  • アジャイルな開発の場合はベロシティを出すことが目的で使う事があるのかな
    • ベロシティの根拠にするためにはある程度正確にポイントを見積もれるようになってないといけないよね
  • 「ゴール」を明確にすることを目的で使っていたことがあるよ
• 「合わせ技」のチャートの別の書き方
  • 水平ラインの上に残りストーリを書くが、追加されたストーリーは水平ラインの下にのばしていく書き方
  • 追加作業の可視化がしやすい
    • 現実問題、追加作業がどのくらい発生するかを予測できることが重要なんだよね
• 追加作業を予測すること
  • みんなどうやっているの？
  • ベロシティと同じようにどのくらい作業が増えたのかを計算して見込みとして出したりしているよ
  • 「追加であったほうがいいよね」と「これ考えていなかったよね」というのは同じ追加でもちょっと違うから判断が難しい
• 縦軸の元になるものがストーリーポイントかチケット数かで追加の考え方がかなり異なるね
  • チャートの動き方が異なってくるね
  • バグがあった場合チケットなら追加になるけれど、ストーリーポイントだと未完成(0pt)となって追加にならない
• 何らかの形で作業が見えるのはいいね！
  • 実際減って行ったら気持ちがいいしね
• どうやってうまくメトリクスをとってますか？
  • 説明はできるけどそれを元に先の予測をすることは難しいので数値の使いどころが難しいと思っている
  • 他の人に見積もりの精度を高めてもらうためにメトリクスをとっていたよ
    • 今後のフィードバックのために
    • 自分が見積もった結果がどうであったかを知る事で見積もった本人がいろいろな事を考えられると思うよ
  • 本気で計測して使えばすごく有効に使える数値だと思う
    • 客観的な材料として仕事の速度を予測できる
    • 説得するのに有効な値となる時もある
  • ところで「メトリクスを取る」って何？
    • 作業時間や作業規模、どのくらいストーリーが追加されているかを計測して予測値と実績値を測定することだよ
• 同じストーリーでもOSやバックグラウンドによってかなりポイントが変わるよね
  • 言語でサポートされているかどうかの違いとか、フレームワークとか

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

• インセプションデッキを書くことは大事だなあと思った
  • 質問に答えられないことはかなり問題だと思う
  • 実際にやってみたこともある、いいきっかけになったと思う
• この章は「ナシ」だと思うよ
  • なぜ？
  • 「うまくいってない」が曖昧、分析をしていない。なぜかわからないのに対策を講じることはできないはず
  • いくべき方向を見失っている人はこの章のことを実践すれば改善できると思うよ、そういう人を対象にして語りかけているんじゃないかな
    • そもそも方向がわからない場合って場合はどうなるの？
      • その時はきっとインセプションデッキもかけていない -> 見直すべきプロジェクトとなるんじゃないかな
• b(とにかく早く何らかの成果をあげなきゃいけない)ってどういう状況？
  • お客さんから成果だけを催促される場合
    • 目に見える形でわかるように早く何かを出して、とプレッシャーをかけられたり
    • 売り上げに貢献するものを出して、と言われたり
  • プロジェクトのはじめの頃、成果を成果と受け取ってもらえないとき
    • この場合、今すぐできることを「完了」させることは重要になるね
    • 「完了」とは「完了」の事だが大事になってくる
    • 小さな事を完了していくようにする事の大切さを伝えているね
    • お客さんを待たせないことが大事だよなあ
• aかb、どちらかじゃなくて、「aだったらb」だし、「bだったらa」のことも多いよね
• 「完了」そして「信頼貯金」->「作業量を踏まえた計画でリリースを定義」という流れ
  • 小さな「完了」を繰り返す事が、計画のテーブルにつくための信頼貯金になるんだね
  • 最初に「完了」を見せる事で信頼関係を構築していくことができるんだね
• そもそもアジャイルじゃない現場をいきなりアジャイルにすることは危険だと思うよ
  • 確かに、たいていの場合、「不確実性があります」ということにコミットメントがとれていない状態だと思う
  • ぐちゃぐちゃなところからアジャイルな方向に変換するにはメンバーのスキルなども必要になるね
    • そうじゃないと、もっとぐちゃぐちゃになってしまう事もあり得ると思うよ
  • 経験とスキルがあるチームメンバーが前提だね
• bの場合「アジャイルと言う名のアジャイルじゃない開発」の渦中にいる人が本来のアジャイル的な開発にするための方法とも考えられるかも
• コラム
  • 隠す文化は一番ひどいと思う
  • 隠す事は信用問題に直結するね
    • 開発側を信じられない ->「本当にちゃんと作れるのか？」と不安になって無駄な大量のドキュメントを要求したり、とか
    • お客さんを信じられない ->「何か重大な追加があるかも」とバッファをたくさん用意して見積もってしまう、とか
    • 上司やチームを信じられない -> 「作るように言われた機能にどんどん仕様が追加されていくのではないか」と個人のバッファを増やす、とか
      • チームとして吸収できる事かもしれないのに信頼関係が築けない
    • 信じないことによって無駄なバッファが増えるのはみんな不幸せだね
  • 信頼貯金がベースにある開発をしたいですね

8.7 現場で実践する

• ケーススタディ

1. お客さんが新しい要求を発見したら

• スコープの調整はごくごく自然
• 「お客さんが」ではなく「お互いに」見落としていた機能があった時
  • どれを NiceToHaveにするか難しいよね

2. 思っていたほどは速く進んでいないとき

• 現実問題お客さんに「早く進まなかったので調整してください」というこちらの要望を飲んでもらうのは難しくないかな
  • お客さんに話をする前にどうにかするべきなんじゃないのかな
• 機能単位、画面単位で見積もり（お金）がついているのも計画を変更しにくい原因だよね
• 「見積もりは変わるもの」という合意があるのが前提
  • 上記の合意がとれていれば「思っていたほど進まなかったので次のイテレーションにまわしたい」と伝えることはできるよ
  • 実際そういうことができるの？「いいからやれよ」じゃないの？
  • 信頼が前提、信頼されている範囲で話はできると思う
  • 外部要因などの事情があってベロシティが下がっているのであればそれも話をするし、納得してもらえる
• 「最低保証ベロシティ」のようなものがないとお客さんは納得しないのではないかな
  • それは暗黙的にあるんじゃないかな
  • 実際にはお客さんから「最低ラインを下回ることはないよね」という信頼を得ていることが多いのだと思う
• 実際それでお客さんは納得するの？
  • 「完成できない」ことも許容されるのか
  • NicetoHaveリストをバッファとして使うという側面があるよ
    • ウォーターフォールのバッファは余れば企業のもの、アジャイルのバッファはお客さんの嬉しい機能のために使われる
• 「できなさそうです」というのを早めに伝えることが大事

3. 大切なチームメンバーがいなくなったら

• お客さんが納得いくのかどうか
  • いなくなった原因にもよると思う
  • 期間が長くなりますよというのが許容されればそういう方向で納得してもらえる場合もある
  • そのメンバーがいなくなることで、あまりにベロシティが下がるのであれば、価格を下げる話し合いもする
• 信頼貯金を貯めていた人がいなくなったらきついよね
  • 事情によってはお客さんとの信頼貯金がゼロになりそう
• 会社都合で信頼を失うようなメンバー移動は絶対やってはいけないよね
  • 致し方ない事情はあったとしても
  • 人は交換可能と思ってはいけない
• 失敗プロジェクトはどうしてなくならないんだろう => 特許庁の55億プロジェクトの話題と絡めながら
  • 失敗しても振り返らない
  • 失敗の原因がわからない
  • 成功の原因がわからない
  • 思考を停止しろ文化
    • この文化はなかなかなくならない
    • 今後もなかなかこの文化が消えるってことはないだろうなぁ
    • せめてその文化がちょっとでも少数派になるようにしていきたいなぁ

4. 時間が足りなくなったら

• スコープを調整する他の「もう一つの解決策」がここではじめてでできた
  • 1つのストーリーを入れるか入れないかだけではなく、ストーリーそのものを見直すという考え
  • 考え方によってはスコープを調整するの一環とも言えるね
  • 思い切った方向転換の提案
  • ストーリーの取捨選択だけじゃない一歩先の提案、短い期間でストーリーをどれだけ救えるか
    • 信頼関係の構築
  • 発想の転換や、長い期日であれば思いもしなかったことを思いつくかも
    • その状況で生まれるアイディアもあるかもしれない
  • 選択肢を示すことができるのが大事
    • ない袖はふれない
    • 手持ちのカードを増やすことが大切

マスターセンセイと熱心な弟子

• センセイ：まえはなさん

• 弟子：ながぬまさん

• ナレーター：しだらさん

• 変化を記録して、それをどうするんだろうか

  • 後で何か起きたときに良い材料になるんじゃないかな

• 固定じゃない「品質」が下がっていく

  • 使いにくいものができる
    • 「がちがちの公共系システムで使いやすいGUI標準」みたいなのってできないものかな -> 難しい
  • 納品できればオッケーになっていく（保守はしらない、逃げるが勝ち）

• 現実は変化を見ないようにして隠し通していることが多い

• 「もしも特許庁の基幹システムの担当者がアジャイルサムライを読んでいたら」

  • どうなっただろうね

---

次回は2/14（火）です。 9章から入ります。