FLINTERS Engineer's Blog

FLINTERSのエンジニアによる技術ブログ

GANMA!チームのScrumについて

GANMA!開発エンジニアの盛岡(@morizooo)です。
3月からScrumへの取り組み方を変えており、形になってきたので、
どのような変化があったかを共有したいと思います。

背景

今までの開発手法としてはSCRUM BOOT CAMPを読んだ後に独自で考えた手法で、
以下のように行っていました。

既存の開発で大きな問題はないように感じてはいたのですが、
チームリーダーがScrum AllianceのCSM研修を受講する機会があり、
Scrum Allianceが提唱するScrumについての説明を受け、フィードバックを受ける機会がありました。
そのフィードバックを踏まえて現在の問題点を考えて、
良くなるかもしれないなら新しい手法にTryしてみる価値があるんじゃないかということで挑戦しています。

f:id:morizo999:20170609162552j:plain

現在の開発の流れ

  • 1週間Sprint
  • タスクのアサインはしない
  • タスクの詳細をチームで考えて30min/60minの粒度に分割する

スケジュール

1週間Sprintを下記のスケジュールでセレモニーを行っています

  • 毎日 17:00~17:15 Daily Scrum
  • 火曜 16:00~17:00 Product Backlog Refinement
  • 木曜 13:00~13:30 Sprint Review
    　　 13:30~14:30 Sprint Retrospective
    　　 15:00~18:00 Sprint Planning
  • 金曜 10:00~13:00 Sprint Planning 予備時間(木曜で終わらない場合の延長時間) 　　

Sprint Planning

一番大きく変わった部分がSprint Planningなので、このセレモニーを自分たちのやり方と合うように、
どのように実行しているかを説明します。

  1. POともに次スプリントの開発するタスクを決める(この段階では詳細検討は行われていない)
  2. 次スプリント中にやらなくてはならない技術タスク(開発チーム管理のタスク)を次スプリントのタスクに追加する
  3. ポイント振りはProduct Backlog Refinementで終わっているはずだが、
    
緊急対応などの何らかの理由で見積もっていない物があればこの場で見積る
  4. チーム全員でDDDをやっているので、
    ドメイン設計・テーブル設計等全体で考慮するタスクがないか確認する。
    全体で考慮するタスクが存在する場合は全員で検討する
  5. 詳細検討を行いチーム全員でタスクの分割を行う
  6. 詳細検討が終わり次第、POに確認をしてもらい作業開始。1人1日4時間を予定時間として計算する。
    詳細見積もりで予定時間を超過しているようであれば、スプリントの開発タスク量を減らす相談をPOと行う。

詳細検討について

詳細検討後は30min/60minのタスクしか存在せず、チーム誰でもできるような作業に分解します。
(現状は、Android/iOSのプラットフォームの違いがあるので全員が出来る状態ではありませんが、誰でもできる状態を目指しています)
開発優先度の高いタスクから以下の作業を、一番そのタスクに一番詳しい人から行っています。

  1. タスクの内容を確認する
  2. 空コミットでチケット番号をいれてブランチを作成する(Bambooでコミットログでトラッキングできるため)
  3. 必要なタスクをチーム全員でソースコードを見ながら30min/60minで出来るチケットを作成する
  4. 変更が必要な所にTODOコメントをつけてプッシュ
  5. 一通り切り終わった後に、全員が出来るように曖昧な点がないか確認し実装イメージを共有する

方針が立たないようなタスクの場合には、以下の方法を使う場合もあります。

  1. 各々が自分で思う作業順を付箋に書き出す
  2. 説明しながら付箋をホワイトボードに貼る
  3. 全員が貼り終わったら、分類分けをする
  4. タイトルを付け、30min/60minかを相談する

www.ted.com

所感

現在もまだまだ完成しておらず、Sprint Retrospective毎にルールが進化しています。
最初はSprint RetrospectiveやSprint Planningだけで一日が終わる日があり、
エンジニアなのにコード全然かけてないぞ〜？という日々を過ごしていたのですが、
現在はある程度高速化が進んでおり、上記のスケジュール感で回るようになってきました。 30min/60minの詳細に分割するのは大変なのですが、体調不良等で急に休むことになってしまった時や、
思うように進まなくてハマっている場合でもタスクの渡しやすくなったので、チームとして助け合いできる環境になったと思います。　　

今後もScurmをやっていくぞー！というわけではなく(Scrum Slavesにならない)、
チームとして最適な手法を模索していきたいと考えています。

というわけで、開発手法含めて一緒に考えて開発する人を募集していますので、よろしくお願いします！ www.septeni-holdings.co.jp