プロジェクトにおける7つの問いを元にアジャイル開発しているおはなし。

2016年12月2日 Off By saya

こんにちは。ランサーズエンジニアの@sayaです。

ふだんはランサーズの機能追加や改善を担当しています。

いきなり本題で恐縮ですが、ランサーズには、先日弊社CTOが提唱した『プロジェクトにおける7つの問い』があります。

# 詳細に関してはこちらからどうぞ。(当初6つでしたが、いまはひとつ増えて『7つの問い』になっています)

『プロジェクトにおける7つの問い』

ステークホルダーと合意したものがまとめられているか？

受け入れテストは作成されているか？

進捗が感覚ではなく、ストーリポイント+ベロシティ+バーンダウンチャートによって語られているか？

難しいところを後回しにしていないか？

いつでも人に見せられますか？

ユーザのことは想像しましたか？

細部のUI/インタラクションについて考慮する時間を取れているか？

今回、ちょうど新しいプロジェクトが開始するタイミングでこの問いが投げかけられたので、この問いを意識してチームとしてアジャイルでやっていくことにしました。

今日は、こんな流れでやっていますよ、というところと
課題解決のためにこれやってよかった！というところをお伝えします。

全体的な流れ

今回のプロジェクトはこのような流れですすめてきました。

ステークホルダーと要件を洗い出す
要件をもとにユーザーストーリーを作成する
要件の優先順位を加味したユーザーストーリーマッピングを作成する
規模感を見積もるためにユーザーストーリーマッピングにポイントをつける(プランニングポーカー)
Phase分け、どこまでやるかのラインを決めてステークホルダーに同意をとる
モデリング、DB設計(ざっくり)
スクラム開発 ← イマココ

スクラム開発では、スプリントのサイクルを1週間とし、スプリントの終わりに毎週KPT形式の振返りと次回スプリントのプランニングをすることにしました。

タスク管理に関してはGitHubとカンバンの連携まわりをwaffle.io、バーンダウンチャートをGoogleスプレッドシートという感じで併用しています。

振返りをやっているといくつか課題がでてきますよね。

この課題に対し、毎スプリント終わりの振返りでTryとして対策を講じています。

今回はその中でも特にこれやってよかった！と思うところをお伝えします。

難しいところを後回しにしないためにスパイクをうつ

難しそうなところ、ある程度規模感があるもの、ゴールは決まっているけどどう実装するか探りながらやっていくものは先にスパイクを打つことにしました。

スパイクとはイテレーション計画に含めるタスクの1種で、何らかの知見を得たり、疑問を解消することを目的に取り組む作業のことです(「アジャイルな見積りと計画づくり」より引用)。

スパイクを打つことで曖昧だったものを明確にしてから実装にとりかかることができるようになりました。結果として、後半に向けてベロシティをあげられるポイントにもなっています。

また、全体感の把握やタスクの細分化ができ、担当割り振りや実際の作業もしやすくなるというメリットもあります。

なお、スピード感を優先するためスパイク自体には多くても半日ほどしか時間をかけないようにしています。

作業はしているが成果、パフォーマンスにつながっていない

バーンダウンチャートを見ながら振り返っていると、作業はしているのにパフォーマンスにつながっていないという課題がでてきました。

整理すると、おおまかに2タイプにわかれたので、それぞれの対応方法を以下の通りパターン化しました。

想定外の実装が追加で必要な場合

ISSUEに起票しバックログに積み、次回以降のスプリントにまわす

見積もりよりボリュームがあり時間がかかる場合（かつ後続タスクに影響のある場合）

わかり次第メンバーと相談

そのスプリント内で解決できるようであれば継続

難しそうであればとりあえず動く状態までもっていく

そのスプリントにおいて何が発生したのか、どう収拾をつけていったかをきちんと残しておくと振返りの時にも役立ちます。