いきなり本題で恐縮ですが、ランサーズには、先日弊社CTOが提唱した『プロジェクトにおける7つの問い』があります。
# 詳細に関してはこちらからどうぞ。(当初6つでしたが、いまはひとつ増えて『7つの問い』になっています)
『プロジェクトにおける7つの問い』
- ステークホルダーと合意したものがまとめられているか？
- 受け入れテストは作成されているか？
- 進捗が感覚ではなく、ストーリポイント+ベロシティ+バーンダウンチャートによって語られているか？
- 難しいところを後回しにしていないか？
- いつでも人に見せられますか？
- ユーザのことは想像しましたか？
- 細部のUI/インタラクションについて考慮する時間を取れているか？
今回、ちょうど新しいプロジェクトが開始するタイミングでこの問いが投げかけられたので、この問いを意識してチームとしてアジャイルでやっていくことにしました。
今日は、こんな流れでやっていますよ、というところと
課題解決のためにこれやってよかった！というところをお伝えします。
課題解決のためにこれやってよかった！というところをお伝えします。
全体的な流れ
今回のプロジェクトはこのような流れですすめてきました。
- ステークホルダーと要件を洗い出す
- 要件をもとにユーザーストーリーを作成する
- 要件の優先順位を加味したユーザーストーリーマッピングを作成する
- 規模感を見積もるためにユーザーストーリーマッピングにポイントをつける(プランニングポーカー)
- Phase分け、どこまでやるかのラインを決めてステークホルダーに同意をとる
- モデリング、DB設計(ざっくり)
- スクラム開発 ← イマココ
スクラム開発では、スプリントのサイクルを1週間とし、スプリントの終わりに毎週KPT形式の振返りと次回スプリントのプランニングをすることにしました。
タスク管理に関してはGitHubとカンバンの連携まわりをwaffle.io、バーンダウンチャートをGoogleスプレッドシートという感じで併用しています。
振返りをやっているといくつか課題がでてきますよね。
この課題に対し、毎スプリント終わりの振返りでTryとして対策を講じています。
今回はその中でも特にこれやってよかった！と思うところをお伝えします。
難しいところを後回しにしないためにスパイクをうつ
難しそうなところ、ある程度規模感があるもの、ゴールは決まっているけどどう実装するか探りながらやっていくものは先にスパイクを打つことにしました。
スパイクとはイテレーション計画に含めるタスクの1種で、何らかの知見を得たり、疑問を解消することを目的に取り組む作業のことです(「アジャイルな見積りと計画づくり」より引用)。
スパイクを打つことで曖昧だったものを明確にしてから実装にとりかかることができるようになりました。結果として、後半に向けてベロシティをあげられるポイントにもなっています。
また、全体感の把握やタスクの細分化ができ、担当割り振りや実際の作業もしやすくなるというメリットもあります。
なお、スピード感を優先するためスパイク自体には多くても半日ほどしか時間をかけないようにしています。
作業はしているが成果、パフォーマンスにつながっていない
バーンダウンチャートを見ながら振り返っていると、作業はしているのにパフォーマンスにつながっていないという課題がでてきました。
整理すると、おおまかに2タイプにわかれたので、それぞれの対応方法を以下の通りパターン化しました。
- 想定外の実装が追加で必要な場合
- ISSUEに起票しバックログに積み、次回以降のスプリントにまわす
- 見積もりよりボリュームがあり時間がかかる場合（かつ後続タスクに影響のある場合）
- わかり次第メンバーと相談
- そのスプリント内で解決できるようであれば継続
- 難しそうであればとりあえず動く状態までもっていく
そのスプリントにおいて何が発生したのか、どう収拾をつけていったかをきちんと残しておくと振返りの時にも役立ちます。
ひとりで悩まない、悩ませない。ウナー
ひとりで悩みはじめるとあっというまに時間が過ぎていきますよね。
今はメンバーが唸ったタイミングで声をかけることで、悩みを共有し相談しながらすすめる方法をとっています。
(唸ったことを勝手に「ウナー」と呼んでいますが全然流行りません)
ひとりでは解決できないこともメンバーと話すことで整理され、解決策がみつかることが多々あります。
もちろん、悩むことは自体はとても大事だと思います。が、今回はどれだけスピーディーにチームとして解決に向かえるかを意識しました。
また、チームビルディングの段階でお互いの得意分野など話しておくことで解決の糸口につながることもあります
終わりに
まだプロジェクトの途中ですし、「こんなの当たり前だよ〜」という点もあるとは思いますがやりかたもふくめてまるっとアジャイルでPDCAをまわしていければいいなと思っています。
そういえば、、弊社某メンバーに「エンジニアが毎週ババ抜きして遊んでる」と言われたのでここで訂正を。はたからみたらトランプのように見えますが、プランニングポーカーという、れっきとした見積り手法です。
トランプで遊んでいるわけではないですよ！プランニングポーカーですよ！という点を以後お見知りおきくださいませ.
