はじめに
スクラム開発始めました
スクラム実践入門を読み、現場に導入した結果
改善されたこと、変化があったこと、気づき、用語を新しく入ってくるメンバーの為にまとめたものです。
スクラムとは
スクラムとは複雑で変化の激しい問題に対応するためのフレームワークであり、
可能な限り価値の高いプロダクトを生産的かつ創造的に届けるものである。
Ken Schwaber and Jeff Sutherland 「スクラムガイド」 p3
スクラム開発はアジャイルソフトウェア開発の中でも**“チームのコミュニケーションを重視した手法”**であることが特徴
詳しくは以下を
いまさら聞けない“スクラム開発”ってどんなもの？
スクラム開発 wikipedia
スクラムガイド
スクラムの大まかな流れ
チーム構成と作業依頼フロー
各部署からくる依頼の決まったルールもなく、手が空いている人が全力でタスクを消化するという体制だったので
誰がどのくらいのタスクを持っているか不透明かつ、**"この機能はこの人"**というありがちな属人化が発生していた。
開発メンバー4人+CTOの5人チームで多部署と社長から担当者に依頼がある
タスク量があまりに多く優先順位もわからない為、
モチベーションを失う人。さらには働きすぎて体調を崩し退職してしまった人も出てきてしまい
さらには技術的負債が膨大になり、単純な昨日追加や修正でさえも困難になってきた。
そこで、開発メンバーからの提案と、ほぼ同時期に外部ITコンサルの方が参加することになったので
以下6つを目標に、スクラム開発を試験的に導入することにした。
1. 開発目的の明確化（What）
2. 開発手法の明確化（How）
3. 自立的なチーム作り
4. 属人性の排除
5. 全体タスクの把握
6. 割り込み率の把握
そして、依頼フローもスクラムマスターに一本化した
スクラム用語と導入事例
プロダクトオーナー
スクラムチームが作ろうとしているプロダクトの最終責任者
スクラムマスター
プロダクトオーナーと開発チームによるスクラムの実行を支援し、スクラム導入の支援を行うスクラムの推進者
ステークホルダー
経営者・経営陣・顧客・他部署などの利害関係者
スプリント
スプリントとは開発期間の単位で
多くのスクラムチームでは１週間〜４週間の期間のいずれかを採用している。
僕らは１週間を採用した
（初めて導入する場合は試験的に１週間からやってみたほうが良いと思った。）
スプリントプランニング
スプリント開始時に**"スプリント期間内で何ができるか"** "どうやって達成させるか" の2点を明らかにするミーティング
だらだらやるとすごく時間がかかるのでタイムボックスを決めてからみんなで計画を立てる。
タイムボックスの例
| スプリント期間 | ミーティング時間 |
|---|---|
| 1週間 | 1〜2時間 |
| 2週間 | 2〜4時間 |
| 3週間 | 4〜6時間 |
| 4週間 | 6〜8時間 |
導入当時は１週間のスプリントに対して、スプリントプランニングが2時間弱かかっていたが、
スプリントを重ねるごとに1時間で終わるようになった。
デイリースクラム
デイリースクラムとは「朝会」です。
1日に1回15分間のタイムボックスで進捗や予定、問題の共有を行うミーティングで
昨日やったこと、今日やること、困っていることを話す。
15分以内に問題の解決策が見つからない場合は、関係者を絞り「二次会」を行うと良い。
スプリントレビュー
インクリメント(成果物)の確認を行い、フィードバックを得るためのミーティングです。
インクリメントの定義
インクリメントが完成した定義をチーム内で共有する
（リリースまで完了して完成なのか、PR作成して完成なのか）
スプリントレトロスペクティブ
スプリントレトロスペクティブとはスクラムチームが自分たちの現状を見直し、次回以降の仕事の進め方を改善するためのミィーティングです。
タイムボックスの時間内でKPTを行うと良い。
| スプリント期間 | ミーティング時間 |
|---|---|
| 1週間 | 30分〜1時間 |
| 2週間 | 1時間〜1時間30分 |
| 3週間 | 1時間30分〜2時間 |
| 4週間 | 2時間〜3時間 |
プロダクトバックログ
プロダクトバックログとは実現したいリストを優先順位を付けて一覧にしたもの。
機能の追加や修正、ユーザーの要望などが含まれる
ゲーム開発で例えると
① オンライン協力機能
② チャット機能(掲示板)
③ ムービー早送り・スキップ機能
のような一覧をGoogleスプレッドシートなどにまとめ、プロダクトオーナーが内容と優先順位付けに責任をもつ。
スプリントバックログ
スプリントバックログとは、スプリント期間内で行うと判断したプロダクトバックログアイテムと、それらプロダクトバックログアイテムを実現するためのタスクを俯瞰できるように表したもの。
スプリントバックログを可視化したものを「タスクボード」と呼ぶ。
ベロシティ
ベロシティとは１スプリントにスクラムチームが完成させることができる仕事量で
スプリントバックログのDoneにあるタスクのポイント合計値となる。
上記の画像だと 6回目のスプリントプランニングで決まったベロシティは
過去5回のスプリントの実績からスクラムチームが消化できるポイントが
８０ポイントでその内１７ポイントは割り込みポイントとして予定を立てているので
TODOにあるポイント合計、６３ポイントを目指してタスクを調整する。
タスク
タスクの書き方は以下通り
・タイトル #issue番号
・作業内容
・割り込みかどうか(赤斜線)
・誰が担当するか(Slackのアイコンを貼り付けたマグネット)
・ポイント
基本的にはスプリントプランニングにてタスクの洗い出しやプランニングポーカーを行いポイントを決定する。
割り込み作業として、**”AWSのインスタンスにセキュリティパッチを当てる”**などの作業が発生した場合
作業を分解して、他のメンバーがわかりやすい単位でタスクを作成することを心がける。
プランニングポーカー
①フィボナッチ数列(１、２、３、５、８、１３....)が書かれたカードを参加者に配布する
②基準となる数値を決めるため、簡単なタスクに１を割り当て、共通の基準とする
③タスクを一つ選び、仕様がわからない人がいればその場で説明する
④他のタスクは②のポイントを基準に、一斉にカードをだす
⑤最小値、最大値を出した人の意見を聞く
⑥全員が納得できるまで続ける
スパイク
スパイクとはインクリメントを(成果物)を作るために必要な技術課題を解決するための事前調査
[Dos攻撃への対応] などポイントが振りが難しいタスクは [攻撃元の調査] のように分解(スパイク)する。
チーム内であった、よくある質問と回答
Q.1日は何時間？
A. ミーティング、メールチェック、面接、雑務など様々な割り込みがあるため、6時間にしました。
Q.ポイントはなぜフィボナッチ数列なの？
A. 経験の有無があったとしても、完璧な見積もりを行うことは不可能。このタスクはあのタスクより倍くらい大変そう。というレベルでの曖昧な見積もりが良いとされているため。
Q.1ポイント1時間という計算でいいの？
A. ５人チームの１スプリントで８０ポイント消費できるベロシティが出ているので、１ポイント1時間にしてしまうと 週30時間×5人=１5０Pになってしまう。完璧に見積もることはできないし、時間で決めてしまうと終わらせなきゃいけない使命感が生まれ、心理的安全性も損なう。
Q.新人のAさんだと５ポイントくらいかかりそうだけど、Bさんだと2ポイントで終わるからそれでもいい？
A. NGです。ベロシティはチーム全体での値なので、早く終わった場合はベロシティが向上した(生産性が上がった)と考えた方が良い。もしくは、Aさん３ポイント、Bさん２ポイントにタスクを分割してペアプロを行った方が良い。
Q.終わらなかったものはどうしたらいい？
A. ３ポイントの2/3くらい完了させたのであれば、２ポイントをDoneとし残りの１ポイントのタスクを新たに作成して次回のスプリントに回す。
よかったこと
スプリントを走りきるために集中できるし、達成感がある。
割り込みをスクラムマスターが一旦吸収してくれるため、作業の中断がなくなったし
Doneになっているタスクの束を見ると達成感があって嬉しい。
ベロシティと割り込み数の可視化ができた
なんかよくわからないけど、忙しいという状況がなくなった。
また、プロダクトオーナーと経営層のやりとりがスムーズになった
多部署とのコミュニケーションがよくなった？
多部署からの依頼もあると予測して計画を立てているので、ある程度は対応してあげれるようになった。
以前は無意識に嫌な雰囲気を出していたと思う。
エンジニアは何してるかわからないし、怖い
タスクボードを設置しているので、誰でもエンジニアのタスクを把握できるようになったし、自分の依頼をやってくれているのがわかる。
よくなかったこと
スクラムマスターに割り込み依頼を吸収してもらうようにした
本当ならプロダクトオーナーが請け負うべきだが、週のほとんど社内にいないため
スクラムマスターにお願いするようにした。しかもスクラムマスターは開発と兼任。
このため、スクラムマスターに多大な負荷がかかった。
スクラムマスターの開発工数を半分くらいにすればよかったのだろうか...
属人化がなくならなかった
開発メンバー全員が一刻も早くなおさらなければならないバグや追加しなければならない機能のタスクを持っているため
スプリントプランニングで誰が何をやっているか把握できるものの、手伝うことができなかった。
まとめ
スクラムを導入してから1ヶ月半、僕らの事例ではガッチリハマったのでメリットが多かったと思う。
個人的には消化タスクを見渡した時の達成感があるのは仕事をしていて気持ち良いし
集中力もモチベーションも上がるので、作業がすごく捗るようになったので
スクラムがガッチリハマった事例ではないかと思いました。
もっと学んでいこうと思います。
さいごに
スクラムのお作法に外れているところもあるかと思いますが
もっとこうしたらいいよ、それはやめた方がいいよ などあればご教授下さいm(_ _)m