ランサーズ（Lancers）エンジニアブログ

ランサーズ等のサービスを開発・運用する中で得た知識やノウハウを紹介しています。

thumbnail

Labels:  DevOps, 開発よもやま 投稿者：saya

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

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

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

 

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

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

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

  1. ステークホルダーと合意したものがまとめられているか？
  2. 受け入れテストは作成されているか？
  3. 進捗が感覚ではなく、ストーリポイント+ベロシティ+バーンダウンチャートによって語られているか？
  4. 難しいところを後回しにしていないか？
  5. いつでも人に見せられますか？
  6. ユーザのことは想像しましたか？
  7. 細部のUI/インタラクションについて考慮する時間を取れているか？

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

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

全体的な流れ

今回のプロジェクトはこのような流れですすめてきました。
  1. ステークホルダーと要件を洗い出す
  2. 要件をもとにユーザーストーリーを作成する
  3. 要件の優先順位を加味したユーザーストーリーマッピングを作成する
  4. 規模感を見積もるためにユーザーストーリーマッピングにポイントをつける(プランニングポーカー)
  5. Phase分け、どこまでやるかのラインを決めてステークホルダーに同意をとる
  6. モデリング、DB設計(ざっくり)
  7. スクラム開発 ← イマココ
スクラム開発では、スプリントのサイクルを1週間とし、スプリントの終わりに毎週KPT形式の振返りと次回スプリントのプランニングをすることにしました。
タスク管理に関してはGitHubとカンバンの連携まわりをwaffle.io、バーンダウンチャートをGoogleスプレッドシートという感じで併用しています。
burndown
振返りをやっているといくつか課題がでてきますよね。
この課題に対し、毎スプリント終わりの振返りでTryとして対策を講じています。
今回はその中でも特にこれやってよかった！と思うところをお伝えします。

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

難しそうなところ、ある程度規模感があるもの、ゴールは決まっているけどどう実装するか探りながらやっていくものは先にスパイクを打つことにしました。
スパイクとはイテレーション計画に含めるタスクの1種で、何らかの知見を得たり、疑問を解消することを目的に取り組む作業のことです(「アジャイルな見積りと計画づくり」より引用)。
スパイクを打つことで曖昧だったものを明確にしてから実装にとりかかることができるようになりました。結果として、後半に向けてベロシティをあげられるポイントにもなっています。
また、全体感の把握やタスクの細分化ができ、担当割り振りや実際の作業もしやすくなるというメリットもあります。
なお、スピード感を優先するためスパイク自体には多くても半日ほどしか時間をかけないようにしています。

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

バーンダウンチャートを見ながら振り返っていると、作業はしているのにパフォーマンスにつながっていないという課題がでてきました。
整理すると、おおまかに2タイプにわかれたので、それぞれの対応方法を以下の通りパターン化しました。
  • 想定外の実装が追加で必要な場合
    • ISSUEに起票しバックログに積み、次回以降のスプリントにまわす
  • 見積もりよりボリュームがあり時間がかかる場合（かつ後続タスクに影響のある場合）
    •  わかり次第メンバーと相談
      • そのスプリント内で解決できるようであれば継続
      • 難しそうであればとりあえず動く状態までもっていく
そのスプリントにおいて何が発生したのか、どう収拾をつけていったかをきちんと残しておくと振返りの時にも役立ちます。

ひとりで悩まない、悩ませない。ウナー

ひとりで悩みはじめるとあっというまに時間が過ぎていきますよね。
今はメンバーが唸ったタイミングで声をかけることで、悩みを共有し相談しながらすすめる方法をとっています。
(唸ったことを勝手に「ウナー」と呼んでいますが全然流行りません)
ひとりでは解決できないこともメンバーと話すことで整理され、解決策がみつかることが多々あります。
もちろん、悩むことは自体はとても大事だと思います。が、今回はどれだけスピーディーにチームとして解決に向かえるかを意識しました。
また、チームビルディングの段階でお互いの得意分野など話しておくことで解決の糸口につながることもあります
IMG_9221

終わりに

まだプロジェクトの途中ですし、「こんなの当たり前だよ〜」という点もあるとは思いますがやりかたもふくめてまるっとアジャイルでPDCAをまわしていければいいなと思っています。

そういえば、、弊社某メンバーに「エンジニアが毎週ババ抜きして遊んでる」と言われたのでここで訂正を。はたからみたらトランプのように見えますが、プランニングポーカーという、れっきとした見積り手法です。

トランプで遊んでいるわけではないですよ！プランニングポーカーですよ！という点を以後お見知りおきくださいませ.

ランサーズではサービスを成長させてくれるエンジニア、デザイナーを募集しています！
ご興味がある方は、以下URLよりご応募ください。


【中途採用】
フロントエンドエンジニア
サーバーサイドエンジニア
コーポレートエンジニア
SREエンジニア

【新卒採用・その他】
21・22新卒
その他採用情報

関連記事

GASとRoboticCrowd APIで業務効率化したお話

この記事は Lancers（ランサーズ） Advent Calendar 2020 3日目のエントリーです。 ランサーズ新卒エンジニアの太田有紀(@ifuriito09R)です。 今回の記事では、GASとRoboticCrowd APIを使って、業務を効率化し …

PHP、CakePHPバージョンアップの決断

インフラエンジニアの金澤です。 この度、ランサーズ稼働環境（PHP + CakePHP）のバージョンアップを決断しました。 まずは私から、その経緯と計画についてお話いたします。 バージョンアップ決断の理由 ランサーズは、2008年にサービスを開始しました。 現 …

ランサーズというサービスが大切にしていることとメンバーのこと

エンジニアブログに投稿するのは 2年ぶりの上野 です。 ランサーズ Advent Calendar 2019 16日目を担当させていただきます 入社してから4年エンジニアとして ランサーズ や各種サービスの開発を携わり、現在は ランサーズ の事業部長として事業 …