僕らのスクラム開発1

Fumiya Goto
10 min readFeb 9, 2020
Photo by bonneval sebastien on Unsplash

僕の所属チームが実際に行っているスクラム開発についてです。

今度研修を受けるにあたって、Scrum Primer (Version1.2)の日本語版を読みました。(最新版はVersion 2.0みたいです)
それを踏まえて、僕らのチームが実際に行っているスクラム開発について現状や課題を整理しておきます。

今日は2020年2月9日

🌛 前提

  • 結構大きな会社(従業員1000人以上)の割と大きな事業部(100人以上)の1プロダクトチーム(10人程度)の1スクラムチームのお話
  • 1週間のスプリント
  • 1年ほど前に発足したチーム
  • 3,4ヶ月前に僕が開発チームに参加

🐷 スクラムチーム

  • プロダクトオーナー 1人
  • スクラムマスター 1人
  • チーム 4人

🐔 スクラムチーム外の人

結構大きな会社の割と大きな事業部内のスクラムチームなのもあり
スクラムチーム外にもプロダクトに興味を持っている人や力を貸してくれる人がたくさんいます

プロダクトチームの人

  • CS/Sales 1人
  • デザイナー 1人

プロダクトチーム外の人

  • QAチーム
  • 事業部の他チーム
  • 社内の他部署

📆1週間

スプリントは木曜始まりの水曜終わりでやっています。
(実際は木曜の10:30終わりです。 スプリントレビューギリギリにDoneの定義を満たせることがまだ多くて😱)

月曜日

13:30~13:40 デイリースクラム

火曜日

10:00~12:00 リファインメント
13:30~13:40 デイリースクラム

水曜日

12:00~13:00 チームランチ
13:30~13:40 デイリースクラム

木曜日

10:30~11:00 スプリントレビュー
11:00~12:00 レトロスペクティブ
13:30~13:40 デイリースクラム
13:40~😕 😖 プランニング

金曜日

(プランニング)
13:30~13:40 デイリースクラム

プランニングはすごく丁寧にやるようにしはじめており、現在は木曜に収まらないことがあります。
なんとか木曜日中に終わるようにしていきたいところです。

⏲ セレモニー

Photo by Scott Webb on Unsplash

リファインメントとプランニングは特に色々と試行錯誤しながらやっています。

リファインメント

次回移行のスプリントで着手するプロダクトバックログアイテム(PBI)を見積もりできる状態にした上でストーリーポイント(SP)をつけることを行っています。
この「見積もりできる状態」というのがすごく難しい。
見積もりに影響を与える要素をチームみんなでリストアップしたりしました。

ちなみに、SPは極力5pt以上のPBIは作らないように意識しています(今の僕らのチームでは1週間に15~20ptを消化できると順調です)
5ptを超える見積もりになる場合は、単独でリリースしても価値がある単位で分割できないかを検討したりします。

見積もりできる状態にするためにリファインメントで行っていることがPBIの受け入れ条件(AC)の確認です。
PBI自体はリファインメントまでにPOが追加や並び替えをしています。
そのタイトルは課題ベースで「XXXはYYYができない(ので解決したい)」のような形式で書かれていることが多いです。
PBIによってはこのタイミングでHOW(実装方法ではなく実現方法)の検討を行うものもあります。スクラムチームで検討を行いPOが最終判断をします。

リファインメントの段階でHOWが決まっているものはACの確認を行います。
POが事前に書いた概要やデザイナーが作ったデザインをもとに「Given, When, Then」の形式での簡易なシナリオをチーム主導で描いていきます。
この「Given, When, Then」の形式でACを書くのは最近に試しにやり始めたことです。以前は箇条書きの列挙を行っていましたがそれと比較して以下のようなメリットを感じています。

  • テストケース出しに近いため抜け漏れが減り異常系も探しやすい
  • プランニングでタスクを出しやすい
  • CucmberとCypressでe2eテストを描いているがそれが楽になる

ちなみにこの段階では実装方法は明確に意識はしません。
思いついた注意点はメモとして残しておきます。

この流れで見積もりできる状態にしたPBIの例がこんな感じです。

タイトル: 
ユーザーは保存した検索条件を削除できない」
POが事前に書いた概要:
使わなくなった検索条件や保存ミスした検索条件をノイズなのでリスト表示させなくしたい
xdのURL
POが事前に記載した完了条件:
検索条件を削除できること
リファインメントで出した「Given, When, Then」の形式のシナリオ:
Given 一覧閲覧権限を持っている人
And 一覧画面にいる
And "検索条件A"が存在している
When 保存した検索条件をクリックする
And "検索条件A"にホバーする
And ゴミ箱をクリックする
And モーダルが表示されて、削除をクリックする
Then 検索条件を削除しましたという成功トーストがでる
And 検索条件一覧のメニューは閉じる
And 保存した検索条件をクリックしても、"検索条件A"がないこと
開発メモ:
- ゴミ箱をクリックしたときに検索が適用されないように

プランニング

プランニングはプランニング1とプランニング2の2部構成で行っています。

現在プランニング1で行っていることはほとんどPBIをスプリントに積むだけです。
今回のスプリントのチーム稼働可能な時間を確認して、平均ベロシティをもとに今回のスプリントで行うPBIを確定します。
この時間までにPOがPBIの並び替えを終えているため大体の場合、上から積んで終了となります。

プランニング2 は僕らのチームにとってとても難しく時間がかかっていて改善の余地があるところです(毎週成長を感じています)

ここではPBIを30分単位のタスク(スプリントバックログアイテム)に分割することを行っています。

大体以下のような流れで行っています。

1. AC再確認
2. タスク出し
3. 1 min AC Check
4. 3 min Cooking

AC再確認 🉑
大体2、3分程度で、考慮もれや未確定な箇所がないかなどPBIのACに関して、タスクを出せる状態になっているか再確認します。

この段階で実装方法について未知な部分が多いことが判明したらSpikeタスクとします(リファインメントの段階でSpikeとすることもあります)。

タスク出し 💛
SPあたり8分を目安にして時間を測りながらタスク出しを行っています。
しかし現状は時間内に収らないことの方が多いです。
その場合はタスクを出し切ることに重きを置いて時間を延長しています。

タスク出しの際には特に以下のようなことを意識しています。

  • 1つのタスクが30分に収まる粒度であること
  • 実際に行うタスクのイメージの差異がメンバー間で少なくなること
  • スプリント中のタスク漏れが発生しないこと

これらを行うためにタスク出しの際はみんなで実際にコードを見ながら実装箇所の特定と実装イメージの共有を行っています。
またここで必要があればリファクタリングのタスクも同時に作成します。リファクタリングについても同様に共通の実装イメージを持てる状態とします。

タスク出しの流れは以下のように行っています。
実際のシナリオベースで順番に出すことで漏れが減ってきている実感があります。

  1. 「Given, When, Then」の形式のシナリオをもとにテストのタスクを作成
  2. 1をもとにフロントのタスクを作成
  3. 2のフロントタスクのために必要なサーバータスクの検討(GETの追加や修正など)
  4. フロントからAPIを叩くタスクを作成
  5. 4で叩かれるサーバーのタスクを作成
  6. 2〜5の繰り返し

1 min AC Check 💯
タスクを出し終えたら達成感と疲労感で次のPBIに進みたくなってしまいます。
しかしACの漏れがあると困るためアジェンダとしてACの最終確認を1分間用意しています。

出したタスクをすべて行えば本当にACを満たせるよねという目線でACとタスクの付箋を照らし合わせます。
ここでタスクの漏れが判明すれば儲け物です。
再度タイマーをセットしてタスク出しに戻ります。

3 min Cooking 👩‍🍳
これは僕らのチームのとてもアジャイルなプロセスです。
今回のタスク出しについて3分間で振り返りを行います。

良かった点や悪かった点を列挙し、直後のタスク出しをより良いものにするよう努めます。

スプリントレビュー

ここでは、スクラムチームだけでなくCSやSalesも交えて行っています。

デモが目的ではなく、Scrum Primerにも記載のように
チームやその他のメンバーが互いに状況把握やアドバイス等を得ることを目的として行われています。

なお僕らのチームではスプリントレビューとリリースは関係がなく、スプリント中でもDONEの定義を満たしたものは即座にリリースをしています。

レトロスペクティブ

スクラムをさらに良いものにするため前回のスプリントで良かったことや問題だったことを炙り出します。
問題に対しては分析とTryを考えます。

Tryを考えて、実際に誰が何をするかまでまとまることが多いです。
Working Agreementの内容が変わったりもします。

良かったことや問題だったことをレトロスペクティブの時間まで覚えていないことが多いので、スプリント中に共通のノートにメモするようにしています。

デイリースクラムと作業時間

毎日13:30からデイリースクラムを行います。

普通のデイリースクラムです。
やったこと、やること、困っていることなどを言って最後にみんなでプロダクト名を言って 💁 1日の開始です。
メンバーが肝油ドロップをくれるのもこのタイミングです 💨

タスクは付箋を壁に貼っています。
デイリースクラムで自分が翌日までに着手するタスクにマーキングして、着手中のタスクを自席に持っていきます。
タスク1枚が30分の単位となっているので何枚取れば良いかが単純にわかります。
タスク着手中はタイマーで時間を測っていて、完了したタスクには実際にかけた時間を付箋に書き壁に戻します。

最後に

軽い気持ちで僕らのスクラム開発の現状について描こうと思ったら長くて書ききれませんでした。濃厚な1週間を送っています。

背景や詳細など書ききれなかったことや雑になってしまった箇所や消した箇所もありますのでまた別で書けたらと思います。

そのうち「僕らのスクラム開発2」として、僕らの進化したスクラム開発について書きます。

--

--

Fumiya Goto

Japanese🇯🇵 Software engineer working at Shibuya Tokyo🗼🐶