アジャイルサムライ読書会(湯島道場) 第三回 火の巻に参加してきた #agilesamurai #湯島道場

勉強会 読書会 Agile


(写真：読書会の途中で出されたスイーツの説明文。実は当読書会に縁の深い『キーワード』が。詳細は後述。)


回を重ねて第3回。書籍『アジャイルサムライ』読書会in湯島道場が行われましたので三度湯島へ詣で、参戦してきました。会場は株式会社アルティネット様会議室。直近で3回(毎週水曜日)湯島に来ており、最近たまにしか(2か月に一遍位)顔出して無い本社よりも明らかに来訪頻度は多いです(笑)

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

The Agile Samurai: How Agile Masters Deliver Great Software (Pragmatic Programmers)

The Agile Samurai: How Agile Masters Deliver Great Software (Pragmatic Programmers)

『アジャイルサムライ』読書会公式＆ポータルサイトはこちら。

また、『アジャイルサムライ』読書会湯島道場に関するページは以下。前回第2回から諸々新しい動きが出始めています。その辺については後述。

今回も前回同様、直前のキャンセル等が幾つかありましたが、その分キャンセル待ちで登録された方にスムーズな連絡が行き、ほぼ満席の状態で会を始める事が出来ていました。

読書会第3回の範囲は第2部(6章〜8章)。目次レベルの内容がこちら。

第III部 アジャイルな計画づくり
  第6章 ユーザーストーリーを集める
    6.1 文書化の難しさ
    6.2 そこでユーザーストーリーですよ
    6.3 よく書けているユーザーストーリーとは
    6.4 ストーリー収集ワークショップを開催しよう
  第7章 見積り：当てずっぽうの奥義
    7.1 概算見積りの問題
    7.2 ピンチをチャンスに
    7.3 見積り技法
  第8章 アジャイルな計画づくり：現実と向きあう
    8.1 固定された計画の問題
    8.2 アジャイルな計画づくり
    8.3 スコープを柔軟に
    8.4 初回の計画づくり
    8.5 バーンダウンチャート
    8.6 プロジェクトを途中からアジャイルにしていく
    8.7 現場で実践する

アイスブレイク

本日が湯島道場初参戦という方は4名いらっしゃいました。

@akipii さんは言わずと知れた書籍『Redmineによるタスクマネジメント実践技法』の著者！であります。今回東京に来られた(しばらく東京方面におられるようです)事でご縁があってとアジャイルサムライ読書会湯島道場へのご参加と相成りました。この後のLTもご担当されています。

Redmineによるタスクマネジメント実践技法

Redmineによるタスクマネジメント実践技法

@uedayo さんは最近担当されたプロジェクトで幾つかリリースを完了させた、という事でサービスの紹介も。

皆さん！ぜひアクセスしてみて、触ってみると良いですよ！ それとなく告知しときました(笑)＞@uedayoさん

また、今回は第1回に引き続き、Ryutaro YOSHIBA(TwitterID:ryuzee) さんが第3回読書会の用心棒として参戦し、状況を見守っておられました。

LT

アイスブレイクに引き続きのLTも@akipiiさんがご担当。先日(2011/07/30)行われたイベント『RxTstudy』のスライド資料を用いて、今回の読書会テーマにまつわるLTを展開。(ページ数で言うと17〜18ページの部分になります)

  • ベロシティのお話
    • テーマ的にはむずかしい場所でもある。
    • ちょうど今日は吉羽さん(@Ryuzee)もいるので、是非お聞きしてみたい。
      • @Ryuzeeさん『高いですよ〜』
    • チケット駆動開発：タスクカードで上げて管理する方法。
      • チケット放置の場合もある…
      • 解決方法
        • 1.定期的に朝会等で棚卸し
        • 2.イテレーション毎に順次リリース（定期的な期間で順次リリース）　XPで言う適切な開発ペース
        • 3.リリース未定のチケットはバックログで一旦保留
        • 4.ベロシティを超えたチケットは後回し
      • ベロシティについて･･･個人で調査してみた。
      • イメージ
        • 【参考】棚卸しとベロシティ
        • 一定すべきものである
        • 生産能力はあがらない
        • 上手く調整しよう。作業負荷が高くならないように
        • 予定工数＝理想日
        • 運用、保守などであれば1ヶ月単位の要望で進めて行く/やりやすいかも？
          • 定期的に要求がやってくる･･･未完了チケットの量が一定。

座談会

@akipiiさんによる皆さんへの『ベロシティとは、(結局)何(なのだろうか)？』という問いからスタート。

  • ベロシティ：一定を保つ、というより安定してくるもの。
    • 最初は不安定。『誰かがコマンドコントロールしてくれた方が楽だよね〜』
      • 段々慣れてくると自分達のやり方が腑に落ちてくる
      • 将来予測としての『ベロシティ』の起点。
      • 直近2〜3スプリントが、現時点での能力。
        • ベロシティは成長するものである。一定のままなのであれば逆に問題。
    • 残っているチケットの量が一定。
      • 比例している場合…チケットの追加量、消化量が一定。
      • チケットが溜まり出す場合…客の要望が増えた、契約上の問題で…など。
  • 沢山イテレーションを回して、ある程度目安が見えてくれば部回せるんだけれども、そこ至るまでの間(目安が見えてくる・安定してくる)についてはどうする？
    • スクラムは経験主義。
      • 第1スプリント
      • 通常は『全然出来ない』もんだけど、そこは気にしない。
      • WFの何割引きかで見積もる
      • 不確実性コーンとの関連性の話。
      • ある意味『えいやっ』で始めてしまう。
    • この辺りの話、PO(プロダクトオーナー(的な立場の人)はどうやって説得させる？
      • 客は絶対コミットさせたがる『やるっていったよね？』
      • 絶対終わります、みたいなコミットは無理。『最大限努力しま〜す』としか言えない。
      • そのコミットは守れない約束です、
      • ただ、自分たちのペースは必ず報告します。見せますので、納得してくれと
      • 透明な姿勢を示すことが重要。
  • ベロシティを時間や生産力…お金に替わるものに変換させたくない。
    • 『塹壕よりXP』：フォーカスファクター等を初期段階では使わざるを得ない。
  • 最初はチームのベロシティを計りやすい、易しめのやつから着手？
    • 3スプリントくらいからは普通に･･･
  • スプリント0
    • 技術的なスパイクで。技術要素が似ているものを作らせる。
    • イテレーションをやっても意味が無い？
      • タイムボックスを斬って計ってみる。見積もってみる。
      • 来週辺り見積しようかなと思ってる。
    • ベロシティ：生産力は似てくる。
      • 諸要素：祭日がある/誰かの不幸/社長の気まぐれ/客が休みだから→影響でベロシティの制度は落ちる。
      • 上記条件を考慮に入れる必要があるのか？捨てるのか/受け入れるのか？(※次の計画を立てるときに影響として気になる。やっぱり見積もりは高い方が良いし。)
        • あまり深くは考えない。おこっちゃうのはしょうがない。
        • 直面したら、PO捕まえて話す。『急な事故が･･･』
        • 基本、(そういう状況は)無いものとして考える。
      • スプリントはそれでいい。でも次のベロシティに含める？
        • 前回、前々回でこれくらいだったから/次はこれ…という範疇では含めるかも？
        • GW等突発的なものは除くかな〜
  • 理想人日・理想時間について
    • あるタスクをやるときに『これ、4時間ありゃ終わるよね？』としたものの、何だかんだなでまる一日掛かるような場合がある。その場合どうしてる？
      • 1日8時間、フルに時間は使えない。
      • 一番高くても6時間？せいぜい4時間位か。
      • 理想時間8時間と有った場合→2日間と判断している。
    • (上記問いに回答された方々の反応)
      • ●人道的に『8時間で出来るよな？』押しつけるのはどうかな〜と。
        • 聞き直す『その見積もりはフルパワーで8時間なの？』→すると『もう少し掛かりますかね〜』と割と出てくる。
        • 具体的には分からないけど、過去上司は『1日5時間位で見積もっておけば』とも言っていた。
      • ●Redmineで管理しています。
        • @akipiiさんの本を買って配った。
        • 4人で1週間で13人日：6割5分の出力。
        • 実例でそれ位
        • 1日辺り5時間位？の見積もり。
      • ●プランニングの時点で
        • 誰がどんな会議、イベント等有るか全部洗い出し、その時間を除去。
        • 除去した中の時間を0.8掛けした上で見積もる。
        • 定時前提。
        • 1週間で24〜5時間/1人
        • ふりかえりなどもしている。
      • ●ストーリーポイント
        • 見積もるときに、そのスプリントに何を入れるかPBLから決める。
        • タスク分割してるときは時間で分割ししている。
        • あくまでもぶちこむのはポイント
        • 突っ込んだものは時間が多くなってもしょうがない。
        • あとはチーム平均でどれ位掛かるの？位の
        • ↓
        • 超えてるよね？しょうがないよね？
        • 始めから分かってる場合は初日でもPOに報告しに行く。
        • 綺麗な時間を報告しに行きたい。
        • 邪推が働かないような見積をしたい。

        • 残り時間は常に着けても、何時間かかったのかは言わない。
        • ふりかえり時に：
          • 多く掛かった分はあまりしつこく問い詰めない。
  • 予実の時間の差があると必ず文句を言いたくなる。そういう動物である。
    • 人事評価に使う。
      • チームが気付くとその辺を考慮にした対応を取りだし、チームに透明性が無くなる。
  • 終わるか終わらないかが知りたい。
  • スクラムのよい所は見積と実績をうまく分けているところ。
  • 『日』を出すとヤバイ。材料に使いたがる。
    • 日にち、時間という単位は人によって意味が違ったりする。危険かも。
    • ポイントは誤解を受けにくい。
  • 第7章、最後の部分『アジャイルサムライでは常に最前を尽くす』
    • 可能な限り正確な見積を出来るよう・・・
    • ジレンマ。答えは無い。
    • 一番心に残った文。
    • 『どこまで頑張れば･･･』〜
      • 部下の人には『ここでやめろ』：感覚的に『ダメかも』と思ったらそこで辞めて良いよ、と。
      • だいたい、ベテランのｊひと二は『この辺で』。
      • 若い人にはタスクをばらして、人によって変えている。
  • ベロシティの見積がわかりやすい、わかりにくいプロジェクトがある。
    • 熟練プロジェクトはやはり見積もりやすい。
    • 新しいプロジェクト
      • 安定しない。
      • 常にはじめての要素が出て来て、安定しない。
      • 計りやすい、安定しやすいのとそうでないのと。
    • 相対見積を真剣にやってくれ（byマスターセンセイ）
      • ちょっと立ち止まって深く考えるだけで違ってくるよ？
  • カンバンで回しているプロジェクト。
    • 正直時間だけで出している。
    • それはそれで良い。
    • デッドエンドが待っているので。
    • 実測値が大事。
    • お客さんに納得してもらう。早い段階から地道に話したりとかして。
  • アジャイルは早く希望を打ち砕く方法。
    • 『〜〜なら出来ます。』→『頑張ったけど、だめでした』と早い時点で判明→『そうか。』
  • 始めの段階で見積をださせて『それでよろしく』→後になって覆される。な形が多い。
    • 見積がそもそも相対的な人に、どう納得してもらえれば良いか。
      • 第2回：見積と契約は違う。
    • 盛る、盛られるのやり取り。
      • 稟議通す時、盛って出すと、流れちゃう。
      • 企画通ったら仕事になるから一緒に考えようぜ。
  • 『概算これで良いので！』って言われる。本当かどうかわからない。
    • 契約後、更に要件見積で･･･という形を取る。
    • ふわっとした返答
      • →モデルを決めて、『やらない事はこれですよ』と提示。
      • →こっちからざっくり投げ掛ける。
    • 『概算』の時は盛らないようにしている。今はユーザさんを巻き込んで行こうかなと思ってる。
      • 一緒に痛みを感じながらやろうよ。
    • そういうときの（見積をする前段階の、3日間とか）時間は取られる。
      • コンサルティングみたいな形でやってるの？
      • 合宿はしない。したことない。営業間接費から出ている？
      • 前居た部隊。
        • プロト版を作る、という契約を取った。
        • その後に出来るかどうか判断。
      • お客さんは合宿をやりたがらない。
        • 『さっ、早く一発ドンで見積出しちゃってよ〜』
      • 本当に良いもの作りたいのなら、一緒に考えたいね〜。
        • 20〜30万払ってでも『よし、やろう』という人とは一緒にやりたい。
        • 『あなた言った／言わなかったじゃない〜』のやり取りは正直疲れる。
          • 始める前に話し合った方が建設的では？
  • ベロシティ・相対見積の話
    • 上に、下に外すケースが良くある。
    • 期間短いとそうも言ってられない。外せない。
    • 次は6週間しか無い？
      • 短いケースでも『相対見積』は有効なのか？
      • 短いからこそWF？
        • いや、完全アウト。
    • 6週間だと、スプリントの長さがキーになる。
      • 1週間スプリントが妥当か。
      • スコープが固定だったら、第1スプリント終了段階で判別可能。
      • 進退判断には使えるかも。
      • 今の一言でやれそうな気がしてきました！
      • 期間もスコープも固定されてしまったら…『でもやるしか無いでしょ』
        • 毎週でもデモすべき。
        • 判断を早めにさせる。
        • 早く希望を打ち砕く/失敗は早く分かる方が良い。
  • 新しい技術を使って6週間
    • 技術判断が難しい。一回捨てて作り直す場合も。
    • 安定した技術を早く見つけられれば。
    • 毎週持って行くのであれば。
    • 捨てる時期は難しい。
    • 捨てるときは多い。IT系だと。
      • 捨てるけど、ノウハウは残る。
  • ユーザーストーリー。
    • 価値を伝えるんだけど、意図したモノが帰ってこない。良いユーザーストーリーを作るには。コツ。
      • →INVESTに行き着くのでは。
      • 受け入れ試験を想定。
      • 沢山書く。
        • チームが教える。
        • 一緒に書きましょうよ。と見本を見せながら、教えながら。
      • 自然言語で書かれている
        • 会社の経営に説明するモノを教えてくださいよ。
          • →簡単に書いてくれたりもする。
          • ※新入社員の女の子に分かるように。
        • デモで分かるようなケースを書く。
          • 何が出来たら受け入れDoneになりますか？
  • Webサービス系でPOをやってたとき、システムよりも野性的な嗅覚が冴えている人に『やってくれ』というのは難しい。
    • P.32『僕の事はキーボードを持った顧客と思いねぇ』
    • P.113『客の代わりにストーリーを書いたって構わないんだよ』
  • 受け入れ試験を意識してユーザーストーリーを書くと、何のために？の部分が入りにくくないか？
    • 管理者画面はなにがしたいかは書けるけど、お客さん系の画面は何をしたいかが書けない。
    • ドメイン知識を持って無くて、書けない。
      • 一応、受け入れ試験は書ける。→聞いてこいって話だね。


…というところで制限時間一杯となり終了。今回も様々なトピックに言及し、且つ名言、名フレーズが飛び出してました。@Ryuzeeさんと@akipiiさんの意見交換・応酬に関しては皆さん聴き入る一面もあったり。

ワールドカフェ＆まとめ

今回のテーマは『計画』について。これまで通り計2回、途中参加グループを変えつつ、思い思いの考えを発表しあい、模造紙にまとめました。

今回新しい試みとして提案されたのは『グループで議論された内容を120文字にまとめて発表』という作業。これまではワールドカフェで纏められた内容をその時の代表者が適宜模造紙を観ながら発表するという形式を取っていたのですが、それだと発表内容がふわっと曖昧なものになったりしてた面もあったと。

その点を考慮して主催者のKiichi Kajiura(TwitterID:@ShiroKappa)さん曰く『エレベーターピッチの要素を盛り込んだ』今回の試みを取り入れてみよう、と思い立ったそうです。実際にやってみて『これは面白い試みだ！』と思いました。

各グループの発表内容はこちら。同じ『荒ぶる四天王』について言及しつつも、全く正反対の意見にまとまってきた辺りが面白いですね。最初『何で120文字なんだ？Twitterなら140文字だろうに…』とも思っていたのですが、これは"ハッシュタグを差し引いた分の文字数"だという事が後にわかり、おお！そういう事ですか。と一同納得(笑)

そして今回も、休憩時間を利用してスイーツが参加者全員に振る舞われました。今回は書籍P.108の

よく書けているユーザーストーリーの2 つ目の特徴は、エンドツーエンドになっているということだ。
エンドツーエンドというのは、わかりやすく言うなら、ユーザーストーリーの切り口が「ケーキを切る」ようにスライスされているってことだ。

という文章の中で挿絵として上げられている以下のケーキにちなんで、

こちらのスイーツ。

こちらのスイーツで興味深い点が、箱の裏蓋に記載されている説明文。エントリ冒頭でもモザイク入りで載せた写真には、実は以下のようなキーワードでお菓子の紹介がなされていたのでした。

『侍Sweets』という、まさに今回の企画にうってつけのキーワード！よくぞこのスイーツを見つけられました。天晴！という感じで皆さん写真に収めておりました。美味しく頂きました♪


会も終盤を迎え、幾つかのお知らせが告知されました。

他流試合やります

前々からやるやると言われていた"道場が一同に会した他流試合イベント"。9月開催を目途に詳細が詰められている模様です。

他流試合のアイデアなど、上記ページから遷移可能なGoogle Moderatorで募集もしているようなので、皆さん是非ともご意見ご要望などをお寄せください！とのことです。

DevLOVE道場、開設。

第3回湯島道場のイベントが開催される前に突如として現れた『DevLOVE道場』。そこで開催される内容については謎のままでしたが、どうやらかな〜り面白そうなプロジェクトを企画されているようです。(^_^*) 『こういう感じで検討しているらしい』という感じでざっくりお話を伺うことが出来たのですが『何そのプラン、超面白そうなんだけど。』と思えるような内容。近々全容、詳細も明らかになると思われますので、公式発表が是非とも楽しみです♪

また、地域別の道場も秋田 (秋田寺子屋)や大井町道場等新たに開設されていたりします。

スクラムギャザリング東京2011 開催のお知らせ

2011/10/19、2011/10/22に開催が予定されているイベント『スクラムギャザリング東京2011』についてのお知らせ。
10/19開催のセッションについては、海外の超々有名講師を招いてのキーノートセッション(有料)。同時通訳も付くという事です。多少値は張りますがそれだけの価値がありそうな非常に貴重なセッション。興味のある方は是非ともご参加を検討してみてはいかがでしょうか。10/22開催の方は無料です。


その他、湯島道場に於ける第6回『かっぱ巻き』の構想や次回第4回湯島道場の告知など、水面下で動いているものも幾つかお話を伺うことが出来ました。いやぁ、ワクワクするような話ばかりです(笑)

懇親会

今回も10名近い参加。渋谷道場含め、他開催会場の様子や状況等も聴くことが出来たり、主催者であるKiichi Kajiura(TwitterID:@ShiroKappa)さんの"(ShiroKappaという)名前"の由来を聞くことが出来たりと、興味深いトピック満載の懇親会でした。終電の都合上今回も途中退出となってしまいましたが、もっと色々話を聞いていたかったですね〜。というか、@ShiroKappaさんの道場開催に関してのお話諸々を伺うにつけ、『すごいお方だ…』と感心する事しきりでした。この辺のお話を伺うだけでも、湯島道場に参加して良かったな〜と思えましたね。

次回開催は2週間後の8/24(水)。混戦が予想されますが是非とも枠を押さえ、参戦したいところです。開催が非常に楽しみですね♪(^o^)