【第5回】Scrum Boot Camp Premiumに参加してきました

先日2/14木に開催されたScrum Boot Camp Premiumに参加してきました。
Codezine Academy

イントロ

昨年10月頃から参加しているPJで「アジャイルやってみよーぜー」とやってたこともあり、社内のアジャイル推進担当な方から「ひと通り(素人ながらも)アジャイルやってみたんだから、ちょっとこれで知見を深めてきなさいな」と紹介頂いたのでした。
※年度末近くだったけど、会社の外部研修予算もギリギリ残ってたようで。

リンク先の通りセミナーは2コースからの選択式だったのですが、Aコース(講師・西村直人さん)に参加しました。
(某社内アジャイル推進担当の方が「西村さんは俺の師匠」と仰ってたのもありました)
Aコース講師は他に原田さん(超絶マルチタスク)、松本さん(バンナムで社としてスクラムに取り組んでいる)、有野さん(SIとしてのスクラム)がいらっしゃいました。

先に感想

  • このセミナーで得た知見は全社レベルで展開したい。社内研修とかやれないかな。
  • スクラム道にもちょいちょい参加してみる(`・ω・´)シャキーン
  • スクラムブートキャンプ本と、セミナー予習用に電車で読んでたアジャイルサムライにサインを頂きました。ありがとうございます!


  • 自分のPJに照らしてみると「何をもって完了とするか」「どうやったらそれを確認できるのか」を曖昧にしたまま走ってしまったのが失敗だった。
  • 見積りにあたって開発チームから「まだ課題が解決できるかどうか分からなくて見積もれない」という場面が毎回あったのも、前スプリント中に次スプリントのおおよそ見積り対象範囲を提示して「スプリントレビューまでには見積もれるように準備してね」を徹底すべきだったと気づけた。「準備しておいてね」は伝えてはいたんだけど、それができないとこんな大変なことになるよ!という影響まではうまく認識してもらえてなかったんだろうな…。
  • オフショアメンバをPJ初期にちゃんと日本に呼べたのはよかったけれど、リリーススプリント前帰国にあたり、遠隔コミュニケーションの相談をよくよくよーく相談すべきだった…。
  • スクラムチームの能力は「チームの"年齢"」に比例する。なるほどなぁ。
  • トランプワークショップで学んだこと。先入観ダメゼッタイ。
  • 気になったポイントを好きなタイミングでポストイットに書いて、ホワイトボードに貼っておくと合間に講師が拾って話題にしてくれる仕組みはすごくいい。自分でも使いたい。
  • 講師の方々がつけてるバッジはスクラムhttp://www.taoofscrum.org/contents/の「守破離バッジ」。てっきり写輪眼か何かかと…だってバンナムの方もいたし…

質疑応答とか

  • Q.受託Scrumってできるの?言い方悪いけど「出来高勝負」みたいに考えてるんだけど
    • A.もちろん可能。最初の見積り(10機能1万円で作って欲しい)の段階で「勝てるかどうか」の勝算を踏むのはScrumとか何とかは関係ないよね?問題なのは今までのやり方だと「20機能になったけど1万円でやってね」を交渉できる余地がないんだけど、プロダクトバックログを最初に合意しておけばそこまで酷いことにはならないようコントロールできるはず。
    • A.お客さんの要求をバックログに入れてやれば、その代わりに何かを落とす必要がありますよね?の交渉ができるッ!
  • Q.Scrumを初めて導入するにあたり、えらい人とか協力会社さんにはどうやって説明しよう。拒絶されちゃったことがあるんだけど
    • A.(ブラック)黙ってやる。
    • A.(ホワイト)カタカナ語を極力排除して説明すると、結構アレルギー反応なしでいけた経験あり。「プロダクトバックログ」=「顧客要望一覧(優先度順に並び替えております)」とか。
  • Q.オフショアでやれる?
    • A.やれる…が…オススメはしない。というかオフショアで安くできる分と本気でScrum回せたときのパフォーマンスは、十分オフショアやめようぜの根拠になり得るレベルよ?特に大連はここ数年で外資が入って人がすぐに離れるというリスクがげふんげふん
    • A.24時間TV会議をつなぎっぱなしにしていた現場もある。それくらコミュニケーション重要。POが現地に行くのも1つの手だけど。少なくとも「1回も合ったこともない、初めて一緒に開発するチームです」レベルでの導入は自殺行為。
  • Q.Scrum初挑戦のチームがこなれてくるのは何スプリント目くらい?
    • A.3〜4スプリント目くらいかなぁ…。守破離=1〜2、3〜4、5〜、なイメージ。
  • Q.人事評価とScrumってどう結びつけたらいいんだろう。チームでの成果と個人評価ってどうしたらいいんだろうか。
    • A.正直悩ましい。日本で出来てるところなんて、まだほとんどないんじゃないだろうか。
  • Q.スクラムマスタってどう育成したらいいの
    • A.正直悩ましい。若くて活きのいいやつが適切。あえて聞きにくい質問をする必要があるので、社内の暗黙的なルールとかの思い込みに対しガツンと言える/知らないから言える人。
    • A.社外のスクラムマスタを雇うのもひとつの答えだと思う。
  • Q.1スプリントあたりのストーリ数ってどんなもん?
    • A.まったく根拠はないけど、2週間1スプリントで2、3ストーリがしっくりくる。タスク数は30〜40くらいが好き。

やったこと(資料と記憶の限り)

大きな流れは以下のとおり。

  1. Scrumの基本
    1. スクラムガイドをななめ読み
      1. スクラムとは「複雑なプロダクトを開発・維持するためのフレームワークである」
        1. フレームワーク=自分の組織・現場にあった解決方法や技法を取り入れる」
      2. 理解が容易、軽量である、習得が"非常に"困難である
        1. 「習得ではなくつくりあげていくものなんだ」
      3. スクラムチームの各ロール(プロダクトオーナー、開発チーム、スクラムマスター)とその役目
      4. スクラムイベントと成果物
      5. 3本の柱「透明性、検査、適応」、そのためのコミュニケーション「関心、共通認識、自主性」
  2. 見積もりと計画づくり
    1. 計画づくり。「ちゃんと成果を届けられ、わかりやすくありのままを伝えられ、必要に応じて変更でき、約束したことを守り続ける」計画にしたい。
      1. ★プロダクトバックログ、順序付けると「ちゃんと成果を届ける」計画に効いてくる
    2. 内容をうまく書く「みんなが理解でき、あとで調整しやすく、手軽に書ける」
      1. みんな=計画に関わる人達(スクラムチームだけじゃない)、えらい人、要求を出す人、営業の人…
        1. ユーザーストーリーのテンプレ「"(ユーザーの種類)"として、"(達成したいこと)"をしたい、なぜなら"(理由)"だからだ」
      2. 調整できる前提「よく書けているストーリーであること」=「INVEST」、よくない例「機能〜できる」とだけ書いている
        1. I=独立していること、それをやらないと決めても、そこだけまるっと削ればOK(エンドツーエンドで一式揃っているようなストーリー)
        2. N=交渉の余地があること、目的達成のためにしょぼく安く作れるよ!とか
        3. V=価値があること、ビジネス観点で評価できること
        4. E=見積もりができること
        5. S=小さいこと
        6. T=テストできること
      3. 手軽にかける=短く書くことで後で対話を促す、会話の約束
        1. とは言っても短さは状況による
          1. 何度も開発をこなしてきた見知ったメンバーで構成されたチームなら、テンプレほどもいらないかも
          2. 初めての顔合わせチームならテンプレに則って作成しよう
          3. オフショアならストーリーの詳細な説明、画面レイアウト、受け入れテストまで必要
      4. ★ユーザーストーリーは「わかりやすくありのままを伝えられ、必要に応じて変更でき」る計画に効いてくる
    3. アジャイルな見積もり
      1. 見積もりはあてずっぽう、そんな状況でもベストを尽くすのが"アジャイルサムライ"
      2. アジャイルな見積もりの秘訣
        1. 一人でやらない、思い込み、誰がチェック?、集合知
        2. 実際に作業するひとがみつもる
        3. 相対サイズで見積もる
      3. 見積の主目的はプロジェクトの結果を予測することではなく、プロジェクトのターゲットがコントロールによって達成可能な程度に現実的なものかどうかを判断することにある
        1. ★「自分たちが信頼でき扱える事」が大事で、それが「約束したことを守り続ける」計画に効いてくる
      4. プランニングポーカー、ポイント、対話と合意
        1. ストーリーに対し質問する(情報を伝え、認識を揃える)
        2. 見積もる
        3. 議論する(ここでゴールの認識違いとかがわかったりする)
        4. 合意する(なにを持って完了とする等、合意内容は記録しておくと後々便利)
    4. いつ終わるの?
      1. ベロシティ、スプリントを重ねるごとに正確になっていく、リリース日が予想できるようになる
        1. ベロシティが安定していることが前提
        2. 必要な作業を安定してこなしていくチームが大事、そのためにも阻害するものからのガードが必要
      2. リリーススプリントは用意しておいた方がいい(納品準備とか、引き継ぎとか)
  1. 現場が実践すること、スプリントの上手な過ごし方
    1. イベントをこなす、まるで短期プロジェクトのように(重要)。定期的なチェックポイントとしてのイベント
      1. スプリント計画ミーティング
        1. スプリントで何をどう実現するかを決定する、ゴール、何を実現するか、どう実現するか
        2. 第1部「何を実現するか」を合意する。参加者全員。
          1. 何を実現したいかをPOから伝え、どう実現するかを合意し、どう確認するかまで合意する
        3. 第2部「合意した項目を期間中にどう実現するか」を計画する。参加者PO以外。
          1. スプリントバックログ、タスクの洗い出しと見積り
          2. 「その計画は自信をもって達成できると約束できますか?」
            1. YES!→終了
            2. NO…→タイムボックスに収まるまで調整(分割、交換、変更)する
      2. デイリースクラム
        1. 昨日何しましたか、今日は何しますか、困ってることは?
        2. 進捗報告じゃない、短時間(15分)で終える、決まった時間・場所で、必要な会議のみ別途設定
      3. スプリントレビュー
        1. 成果物と進め方に問題がないかを点検、計画を見直す場
        2. 成果物デモ、疑問点等の解消および完了の判断、進め方の確認
        3. 完了の定義は満たしているか(最終的にはPO判断)、未完了のものは"未着手"として扱う
        4. 問題が見つかったら全員で最善策を考える、スコープ調整、作業無駄排除、課題解消…etc
        5. プロダクトバックログも最新化しましょう
      4. スプリントレトロスペクティブ(ふりかえり)
        1. 進め方を点検し、よりうまくいくアイディアを考えて計画する。全員参加。
        2. 課題報告・対策の場ではない、前向きな対話を!良くなるアイディアは"必ず実現できるように"計画に組み込む。
    2. 他にやるべき事
      1. 透明性の維持、準備重要(明確に要求を伝えられるか、必要な資料は準備できたか、大きな疑問は解消しているか、実現可能か判断できているか、見積もれるだけの情報はあるのか)
    3. 約束を守る、コミットメント
      1. 約束する場「スプリント計画ミーティング、デイリースクラム、スプリントレトロスペクティブ」
      2. 約束を守れない時はどうしてもある、ただしベストは尽くせ
      3. 約束を守れるように"チームで"作業を終わらせていく
        1. そのための「関心、共通認識、自主性」