※ このブログはヌーラバー Advent Calendar 2020 9日目の記事です。

スプリント開発してます

こんにちは。Backlog開発チームの藤田です。

ヌーラボでは、プロジェクトをどう進めるかは各チームの裁量に任されています。Backlog開発チームはたくさんの小さいチームに分かれていますが、ウォーターフォール的な進め方をしているチームはなくて、多くはScrum、もしくはScrumを元にした1〜2週間単位のスプリント開発を採用しているようです。

ヌーラボはプロジェクト管理ツールを提供していることもあり、開発者も開発者以外も「どう進めれば効率的かつ自分たちが気分良く仕事できるか」に対する関心が高い人が多いように思います。常にいろんなチームが上手いやり方を模索していて、良さそうな方法があればパクリ参考にしあっています。

楽にやりたい

私自身はこの一年、いくつかの機能開発プロジェクトでメンバーになったりリーダーになったりしました。極度の面倒くさがりで記憶力が壊滅的なので、どの立場にいる時でも、記憶しなければいけないルールや手順を可能な限り少なくしたいと強く願い続けています。

幸いヌーラボには「怠惰」で「短気」な良いプログラマが多く、楽をするためなら苦労を厭わない人が何人もいてくれるので、「楽にやる」手法がかなり洗練されてきたように思います。この記事では現時点で私が気に入っているスプリント開発の方法をご紹介します。

こんなことを以前書いたことがあるなと思ったら去年のJBUGさん主催アドベントカレンダーで書いてました。……この記事は2020年最新版ということでよろしくおねがいします。

プロジェクトの準備

プロジェクトを開始する時、Backlog上に新しいプロジェクトを作ったらまず最初にメンバーで話し合い、道具立てを作り進行ルールを決めます。

課題種別

Backlogの課題種別はデフォルトで「タスク」「バグ」「リクエスト」「その他」ですが、プロジェクトに応じて変更します【種別の概要 – Backlogヘルプセンター】。定義の基準は

• プロジェクトで登録する全ての課題がどれかにきちんと当てはまる
• 完了条件や進め方が違う作業は別の種別にする
• 「タスク」とか「その他」といった”なんでもあり”な種別を作らない

というものです。

例えば、ある開発プロジェクトでは以下のような種別を用意しました。

状態

課題の状態もプロジェクトに応じて追加します【状態の概要 – Backlogヘルプセンター】。このプロジェクトでは以下のようにしました。

状態の進入条件

そして、次がキモなのですが、種別ごとに状態の進入条件を定義したWikiページを作成します。

「PBIの課題を未対応からReadyに進めていい条件は見積もり、デモ手順が課題に記載されていること」のように読みます。

この一連の手法はこのチームで一緒になった川上さん（【Backlogのスクラムでうまくいっている取り組み2選。】という記事の筆者でもあります）の発案なのですが、私の中では最近一番の「Backlogの上手い使い方」の発明だと思っています。もうみんな真似すればいいのに。

この定義を合意しておくことで、いちいち「これは完了していいのかなあ」など迷わず、朝会などで課題の状態をさっと変更できます。とても楽です。

課題テンプレート

課題種別ごとのテンプレートも便利です【課題のテンプレート – Backlog ヘルプセンター】。

たとえば「PBI」種別のテンプレートはMarkdown書式で以下のようにしています。

# 概要
## 誰が

## 何をできる

# 受け入れ条件

* ...

# デモ
## 事前準備

* ...

## 手順

1. https://test-env.example.com/
2. ....

# 備考

* ...

これで、テンプレートを埋めて作業量を見積もれば自然に「Ready」状態に進入でき、デモまでスムーズに進めることができます。何も覚える必要がなくて楽です。

具体、具体、具体！

基本的に話し合ったことや決めたことはその場でGoogle docsなりBacklogなりに書き込みますが、全てにおいて具体的に記述します。

例えば、デモ手順は

デモ手順

1. ログイン画面にアクセスする
2. ログインする

ではなく、

デモ手順

1. https://test-server.example.com/login にアクセスする
2. ユーザー名 “tester” パスワード “testpassword” でログインする

のように、スプリントレビューのときに誰でも機械的に実行できるぐらい具体的にしています。これにより、たとえば「テスト環境にはまだ反映してないけどローカルPC上では動くのでレビュー」のようなことはできなくなります。

結果、タスクの完了条件が厳密になり、その都度考えたり判断することがなくなって楽になりますし、スプリントレビューの日に誰が有給を取っても他の人がデモできるので気兼ねなく休めます。

Backlog課題のタイトルや詳細も可能な限り具体的にします。例えばユーザーストーリーの書き方は

ログイン後メニュー画面を表示する

ではなく、

全ユーザーがログイン後メニュー画面に『一覧』『追加』『設定』を表示する

とします。「誰が」「いつ」「どこに」「何を」ですね。特に私たち日本人が日本語を書く時、なぜか「誰が」が抜けやすいので注意します。

もちろんこれも、課題を作った人以外が作業する時、考えることが減って楽になります。

マイルストーン＆バーンダウンチャート

プロジェクトにおいてスケジュールと進捗状況の把握が非常に重要なのはいうまでもありません。去年の記事でも書きましたが、相変わらずマイルストーンとバーンダウンチャートのセットは欠かせません。

自分たちが順調なのかそうでないのかが的確に把握できるし、バーンダウンチャートのURLをどこかに貼っておけば自動的に進捗報告になるのでとても楽です。

2種類を併用するパターン

このプロジェクトでは、プロジェクトの各フェーズごとにPBIとそれ以外で2種類のマイルストーンを併用しています。

同じ期間をPBIとそれ以外に分けた別々のマイルストーン（データはフェイクです）

種別「PBI」のユーザーストーリーは、プランニングのときに「他のストーリーと比べてどの程度大変そうか」という相対的な値で見積もりをしています。そのため、PBIだけを集めたバーンダウンチャートの傾きはこのプロジェクトのゴールに向かうベロシティ（進捗速度）を表しています。

しかし、当然ながらストーリー外の作業もたくさん発生します。そのため、PBI以外の課題を集めるため、同じ期間で「OTHER」という別のマイルストーンを作っていました。

これは結構良くて、PBIは順調でもOTHERのバーンダウンチャートが下がってないときは何かブロックしてる問題があるし、OTHERばかり下がってPBIが下がってないときはみんなが楽しい生産性改善活動にリソースかけすぎか、計画時点でのタスクの作り方に問題があることがわかります。

両方とも下がっていることがプロジェクトの健全性を示すわけです。

面倒くさがりのパターン

別の小さなプロジェクトではもっと面倒くさがりな運用を試してみました。「PBI」だけストーリーポイントで見積もるというところまでは同じなのですが、マイルストーンを分けませんでした。PBIに子課題を登録する時にマイルストーンを変えたり、ボードの運用のひと手間が省かれました。

PBIとそれ以外が混ざったバーンダウンチャート（データは願望まじりのフェイク）

当然、バーンダウンチャートの縦軸の単位はなんだかわからなくなります。しかしこれでも「期間内に終わりそうか、ダメそうか」は大体わかるので、短めの期間で終わるプロジェクトではこういうやり方もアリかもしれません。ストーリーの数が多く期間が長い場合はバーンダウンチャートの信頼性が下がると思います。

スプリントの進め方

Scrumなどのスプリント開発で、リズムを生み出す原動力になるのは毎日毎週のミーティングです。最近関わっているいくつかのプロジェクトではどれも、Scrumで定義されている以下のミーティングを行っています。（余談ですがスクラムガイド2020年版は短くて読みやすくとてもいいですね！）

スプリントプランニング（計画）（1〜2時間）

スプリントの最初に、スプリントでやることの詳細を詰めます。予め「未処理」にリストアップしてある課題の中から今週やるものを選び、課題テンプレートに従って必要な情報を書き込み、状態をReadyにします。結果、今スプリントではボードでReady以降の列にある課題だけをやる形になります。

Readyより右のものがこのスプリントで取り組む課題。

デイリースクラム（朝会）（15分）

毎朝決まった時間に15分ほど行います。ボード上で今スプリントの作業をみんなで見ながら進捗と今日やることの予定、もし何か問題があればその共有を行います。

スプリントレビュー（デモ）（30分〜1時間）

スプリントの最後に、今週作業してテスト環境あるいは本番環境にどういう機能をリリースしたのか、関係者にデモを行います。ボード上で「処理済み」になっているPBIを順番にデモして、終わったら次の状態に変更します。

スプリントレトロスペクティブ（ふりかえり）（30分〜1時間）

スプリントレビューの後に、このスプリントでこなした作業量、起こった出来事をメンバーで振り返り、プロセスの改善点について話し合います。この記事で紹介している方法論は、このふりかえりの中で少しずつ改善されてきたものです。

デジタル、アナログすべての手段の中でふりかえりに世界一向いてるのはCacooだと思っているのですが、毎週ミーティングの時間になってからCacooのシートを一枚作り、みんなで書き込みながら話をします。先週と今週のバーンダウンチャートの比較もふりかえりのいい材料になります。

フレームワークはwww.funretrospectives.comから気に入ったものを選ぶ。週替りにしても楽しい

どのフレームワークを使う時でも、コメントのテンプレートを用意しておくことでコメントを書きやすくなるのでおすすめです。

人、プロセス、技術、スコープというテンプレートを用意すると書きやすい

何より大事なこと

ここまで、様々な方法論を書いてきましたが、実はそれよりも、どういうやり方で進めるかを最初にチームみんなで話し合って決めておくことが何より大事です。自分たちで考えて決めた「良いやり方」だからすんなり遵守できるし、覚えるストレスもなく、ひいては楽しい気持ちで仕事をすることにつながります。

以上、皆さんの参考になれば幸いです。皆さんの「ぼくの考えたさいきょうのスプリント開発」も是非教えてください！