ストーリー詳細化を交えた agent bank 開発チームの現在の開発手法

こんにちはみなさん ROXXのagent bank開発チームのniisan-tokyoです。

開発手法は、それこそ各チームで千差万別でだと思います。そこには、メンバーのスキルの特性や事業・プロダクトの性格など様々な事情が入り込んでいます。 メジャーなフレームワークであるスクラムも、スクラムガイドとセレモニーはあれど、細かい進め方は各チームによって変わるのではないかと思います。 今回は我々のチームの現在の開発手法を解説しますので、皆様の参考になればと思います。

現在の開発の流れ

現在の我々は一週間をスプリントの単位としており、その流れは以下のようになっています。

f:id:niikura23:20201014151453p:plain
1スプリント(一週間)の開発の流れ

ある程度はスクラムの流れを踏襲しているのですが、割と特徴的なやり方がふくまれているので、その点を解説します。

ストーリー詳細化

これはバックログにあるユーザストーリーをタスク分解できる状態に持っていく作業となります。 ここで詳細度を上げたストーリーを金曜日のプロダクトバックログリファインメントで扱うようにします。

ストーリー詳細化の詳しい説明はあとに回しますが、基本的には月曜日と火曜日に実施し、水曜日と木曜日は予備日に当てます。 担当者はスプリントごとに変わりますが、月曜・火曜で完了したのであれば、スプリントタスクに合流します。

スプリントのタスク

基本的には実装のタスクとなります。 ここで実現されたユーザーストーリーを、インクリメントとしてスプリントレビューに持ち込みます。

スプリントレビュー

実現できたストーリーをステークホルダに見せて、出来た機能と運用のイメージを解説し、フィードバックをもらいながらリリースのタイミングについて相談します。

振り返り

スプリントを振り返り、次のスプリントをより良くするために取るべきアクションを決めます。 我々のチームでは、オーソドックスな KPTA(Keep, Problem, Try, Action) を採用しています。

リファインメント

プロダクトバックログリファインメントのことですが、我々のチームではユーザーストーリーの詳細度を上げ、プランニングレディな状態に持ち込むためのイベントになっています。 我々のチームではマルチチームリファインメントというやり方を導入しており、この手法は以下のようなタイムボックスを設定して進められます。

  • 15min: ストーリーごとに小チームに別れ、ストーリーについての質問事項と、ストーリーを実現するためにやるべきことのリストを作成する
  • 20min: すべての小チームが集まり、各小チームごとに質問をPOに行い、やることを解説して他のチームからの質問・指摘を受け付ける
  • 15min: 再び小チームに別れ、ストーリーに対するやるべき事の追加・修正を実施し、新しい質問事項を集める。また、可能であればこの時点でストーリーポイントをつける
  • 20min: 再びすべての小チームが集まり、各小チームごとに質問をPOに行い、やることを解説して他のチームからの質問・指摘を受け付ける
  • 10min: やるべきことの修正を行い、まだであればストーリーポイントを付け、ストーリーを実現するためのタスクを作成する

プランニング

次のスプリントで、どのくらいストーリーを実現できるか、どの程度のタスクを実行できるかを見積もり、どのように進めるかを議論します。 これは、以下のように進めています。

  • POによる優先度に基づく並べ替え ( ざっくりストーリーごと単位 )
  • ストーリーに紐付かないタスクにポイントを付ける ( ストーリーから分割したタスクはポイントを付けない )
  • タスクをより効率に進めるために、優先度を壊さないレベルでの並べ替えと進め方の議論
  • 各日にちごとのチェックポイントを作成

チェックポイントは実際のタスクとして作っておいて、各日毎の進捗の様子を可視化できるようにします。

f:id:niikura23:20201014155952p:plain
Jira上でチェックポイントの作成

ユーザーストーリーの詳細化

我々の開発で大きな特徴があるところとすると、スプリント内にこのユーザーストーリーの詳細化を入れているところです。 これは設計のような作業で、なにをやればいいかの、どうなったら完了になるかを定義し、ユーザーストーリーをリファインメント可能な状態にする作業になります。

ユーザーストーリー

ユーザーストーリーとは、プロダクトに追加したい機能を、「〇〇が□□する」というユーザーの行動で記述したものになります。 例えば、プロダクトにメモ機能を導入したい場合は「ユーザーはプロダクト上でメモを残す」のようなストーリーが作られます。

我々のプロダクトにおいて、ユーザーストーリーは述語だけでなく主語もとても大事です。 というのも、我々のプロダクトである agent bank は、求人DBという性格上、主語となりうる人物が、エージェント様、求人企業の人事様、そして弊社の運営事務局と、少なくとも3者以上いるわけです。 そして、主語が誰になるかで作るものもガラリと変わります。 例えば、通知機能一つとっても、エージェント様であればメールでの通知になりますが、運営事務局だとslackになるなどですね。

なぜユーザーストーリーの詳細化の時間をとるのか

本当に大雑把なストーリーはPOが作ります。 しかし、現在POはほとんどコードをさわらないのと、圧倒的に時間が足りないということから、ある程度実装イメージが付いて、どこまで詳細化すればリファインメントできるかがわかる開発チームが、詳細化を担当することになります。 この作業にはまとまった時間が必要になりますので、開発チームから数人選出して、ストーリーの詳細化を集中的に実行するようになりました。

ユーザーストーリーの詳細化の作業内容

ユーザーストーリーの詳細化の方法は、ストーリーによって大きく変わりますが、リファインメントするのに必要な作業としては以下のようなものになります。

  • 背景の整理
  • 受け入れ要件の作成 ( 完了条件の定義 )
  • 画面イメージの作成
  • 指標の策定
  • ステークホルダとの事前共有

背景の整理

ストーリーを実現すると、何がいいのかというのを整理します。これをやっておかないと、どういった戦略に基づくものなのか、どのようなことができればよいのか、誰がステークホルダなのかが何もわからないです。 あらゆる作業の土台になるため、凄まじく重要です。

受け入れ要件作成、画面イメージの作成

受け入れ要件は、ユースケースのリストで定義され、これがすべて満たされれば、ストーリーを実現できたとみなせるものです。 例えば、「ユーザーはメモを残せる」というストーリーの受け入れ要件を考えると、

  • ユーザーはメモ作成画面でメモを入力し送信する
  • ユーザーはメモ閲覧画面でメモを閲覧できる
  • ユーザーはメモ閲覧画面からメモ編集画面に移動できる
  • ユーザーはメモ編集画面でメモを編集できる

といった感じです。 また、これらとともに画面イメージも作成し、実際にユーザがどのように使うかをシミュレートできるようにします。

指標の作成

ストーリーが実現できても、ちゃんとユーザーが使って価値を届けられているかわからないといけないので、上手く行ったかどうかを評価するための指標を作成する必要があります。 先のメモを残すであれば、メモを残しているユーザーが全体の何%いるか、などですね。

ステークホルダとの事前共有

これからこんな物を作りますよ、というのをステークホルダの方々に共有します。 作ったはいいが、いざレビューで「なにこれ?」ってなったら大変なので、実装する前段階でステークホルダと共有し、フィードバックをもらっておきます。

現在の所感とまとめ

というわけで、現在我々が開発の流れを、大雑把に解説しました。

今のところはいい感じにワークしているようにも思いますが、これがベストかと言われると全くそういうわけでもなく、なにか新しいトライがでてくればどんどん試していきたいと思っています。

とはいえ、ベストの手法なんて、本当にあるのでしょうかね?私としては、各チームごとの特性に従って、改善を繰り返して限りなくベストに近づけていくというのが、やはり常道だなって思っています。

今回はそんなところです。

おまけ

今の状況下でも弊社はエンジニアの採用もやってます。 リモートでカジュアル面談出来ますので、興味ある方は私のtwitterにDMなりメンションつけてコメントしてくれれば、つなぎますので、お気軽にどうぞ。

twitter.com