わすれっぽいきみえ

みらいのじぶんにやさしくしてやる

『第16回 Scrum Masters Night!』に参加した

smn.connpass.com

に参加してきた。スクラム関連の本は読んでたけど、これを実践・導入するのにはあまりにも知見がなさすぎたので勉強会で実践している先輩方からもっと話を聞いてこようと思った。

一旦参加者全員が話したいことをバーっと付箋に書いてホワイトボードに貼り付けて、自分が話したいテーマが書かれた付箋に1人2つまでシールを貼っていく。シールが多かった順に上から6つ選び、その中のどれかを自分で選んで、テーブル席で各自議論するという形式だった。

で、私が選んだテーマは『チームの生産性を上げるには?』。
生産性を上げるためにどんなことをスクラムでやってけばいいんだとか生産性が上がるってどういう状態なんだとかがよくわかんないなと思ったので、そのテーマの議論に参加することにした。

そのテーブル席ではファシリテーターの方が「『課題感』、『対策案』を付箋で各自出せるだけ出してみましょうか?」と言って開始したので、実際に付箋に書かれて出されたものを以下にざっと書く。

テーマ: チームの生産性を上げるには?

課題感

  • チームが成熟してくるとプロジェクト開始当初とストーリーポイントの内容が変わってくるはずだけど、その違いはどう測る?
    • どのタイミングでストーリーポイントの見直しを行うべきか
  • そもそも生産性って何?
    • ベロシティ/コスト = 生産性?
    • 生産性 = スピード?
    • ベロシティが上がったら生産性も上がったと言えるの?開発スピードが上がることだけが生産性向上と言えるの?
    • 数字にならない(なってない)ところで生産性が上がってたりもするのでは
    • 部署全体でKPIを改善すると言ってるけど、どんなKPIを設定すればいいの?
  • そもそも『生産性を上げましょう』ということがチームの命題となっている?

対策案

  • 生産性向上のKPIになりえるもの
    • story pointが特定スプリント内で計画的に消費されてく状態
    • デプロイ回数(頻度の方が正しそう)
    • pull request差し戻し回数
    • dev環境upから本番環境upまでのリードタイム
    • スクラムに充てる時間
      • 開発を進めたいのであってスクラム自体に時間を大量に充てるのは間違ってる
      • ある実働時間のうち、どのくらいの時間をスクラムに充てるのかは指標になりえる
  • 収益とコストとベロシティの関係を見える化する
  • スターマップの充実

目的

  • ベロシティ計測は計画性の担保
  • モチベーションアップ
  • ステークホルダーへの説明の材料

解あり?

  • 生産性を上げるために課題となっていることは何?
  • ベロシティ計測のツールに何を使ってる?

結論

  • そもそも生産性を上げるなら、生産性が上がった状態というのを定義してあげる必要があって、定義する役目はPOが負っている。POは生産性を上げるための定義をした上でチームと合意を取る必要がある
  • ベロシティは上げるものではなくて安定させるもの。ベロシティがずっと上がり続ける状態はそもそも異常な状態で、ベロシティは今の我々の実力で何がどのくらいの時間で終われるのかを示すための指標。その指標がブレブレだと見積もりが破綻していることを表してるので、まずは安定させることを第一に考える。
    • そのうえで成熟したチームになるとベロシティを測るために使用していたストーリーポイントの中身がプロジェクト開始時期よりも濃いものになっているはずで、ここは定期的に見直していく必要がある
  • トーリーポイントが振られてないチケットが存在すること自体は問題ではなくて、チームのベロシティを計測するのに値するチケットをスプリントに入れることが重要。もし混乱するのであれば、異なるスプリントを作るなりしてチケットをベロシティ計測のものと分離するのも一つの方法。
    • ただしその方法を取ると本来ユーザーに価値を届けるために進めているスプリントがチーム開発のやりやすさを優先させたスプリントに変容してしまう可能性があって、運用に注意が必要になる。
    • 勉強会が始まる前に社内の先輩とちょっと話した感じでは、ある期間にやろうとしていることを同一スプリント内で回す必要はないよねという話は出ていた。(単に見せ方の問題も含まれてるかも)
  • 一個のチケットに振られたストーリーポイントが異常に大きい場合はタスクを細分化するための調査チケットを別に切る運用をしている
    • これはすでにうちのチームでもやってる
    • あるチームでは8ポイント以上、あるチームでは5ポイント以上だと細分化が必要という感覚値らしい。この辺も結構うちのチームでの実感値と近かった。

大体こんな感じでお話が進んだ。

社内チームでやってきたことは間違ってなかったんだな!と思う瞬間があったのは良かった。一方で本当に悲しいことに、ここで議論する以前の問題がチーム開発で発生しているなーと思う部分もあった。

またこの日の勉強会で、アメリカではスクラム開発で戦闘機を半年で作るらしいことを聞いた。戦闘機を開発するプロセスをちゃんと知らないので内心それが本当に早いのか遅いのかよくわからないけど、なんかすごい気持ちにはなった。戦闘機を作るプロセスに必要なものがある程度わかっていて、熟練のスクラムマスターとかがいたら半年ってそんなに変な数字じゃない気がするけど、新しく研究開発した戦闘機を半年で作るって話なら相当に早い気がする。背景が知りたい。

f:id:kimikimi714:20170613004614j:plain