アクトインディ開発者ブログ

子供とお出かけ情報「いこーよ」を運営する、アクトインディ株式会社の開発者ブログです

Scrum導入してプロダクトローンチしました

ohataです。

ちょうど、2019年1月から新規のプロダクトがはじまる事もあり、Scrum現場未経験ながらも チャンスだと思い実践してみました。
リリース時や導入時の苦労話は色々なところで綴られているので 具体的にどのような方法で運用しているかを紹介したいと思います。 (記載しないのは、苦労点がほぼ一般的だったので)

Scrumイベント

優先度は都度変わっていくと思うので、Sprintの期間は1週間で行なっています。

スケジュール

1週間のざっくりした、イベントスケジュールです 。
全体的にイベントにかける時間が少ないと思うので、ここは改善の余地があると思います。
今の状態で、効率の良さを感じているのですが、もっと効率良くなるかな。。。

f:id:k-ohata:20190606175636p:plain

[Backlog Refinement]、[Sprint Review]、[Sprint Planning]、[Retrospective] は木曜日に集中して行うようにしています。
木曜日に設定した理由は以下の通りです。

  • 月金は休みになる確率が多い & 休みたい人もいると思う
  • メンバーの予定が割とフリーな時間が多い

個人的には、木曜レビュー終わった後にやる事を整理して週末を迎えた方が
休み前に来週も頑張ろうってリフレッシュできるので、良いサイクルだと思います。

Daily Scrum (毎日)

[Sprint Board]の前にメンバーが集まって行なっています。 開発者のイベントとScrum的には定義されていますが、チームメンバーがいた方が その場で解決しやすいのでそうしています。
ただ、そこで優先度高めでやりたいという事象が出たとしても、障害等以外は 次Sprintにするようにします。

ここで大事なのは、[Sprint Board] の前で行う事です。
Sprint Reviewにどこまでいけるのか?誰か困ってないか?などがわかるためです。
視覚的な認識っていうのはかなり大事です。(何について話しているのか認識するまでの時間)

今回のプロダクトでは共有をすることによって優先度の高いチケットが終わらなそうな時に、 優先度の低いチケットを捨てる宣言をして[specは他の人が書けばReviewに出せそう]など意見が出るようになりました。
個人の成果ではなく、チームの成果を共通で重視する事ができたのは大きいと思います。
これがReview直前に発覚した場合はフォローできない事もあるので、日々の確認はすごい大事だと思います。

参加者は

  • 昨日やったこと
  • 今日やる事がいつ終わるか
  • 問題点

を必ず共有する事が大事だと思います。

Backlog Refinement (週1)

[Product Backlog]の前で行なっています。 参加者はプロダクトオーナー(PO),ディレクター,スクラムマスター(SM)でやっています。
プロダクト的な優先度の再確認を行い、午後の[Sprint Planning] でチームに話す内容を整理しています

定期以外でも、気づいたり検討したい事があれば [Product Backlog]前に集まってやっています。

Sprint Review (週1)

Sprintでの成果物をチームにレビューするイベントです。
なるべく開発者や担当者以外の人に操作してもらったり、確認を行う事によって 認識合わせを行います。

開発者以外の視点によって、イレギュラー対応が不足している所などをレビュー中にいくつも発見する事ができました。 実際、リリース後にイレギュラー対応していた事によってユーザー側にきちんとしたアナウンスを行う事ができました。

ここで注意しているのは、レビューはゴール達成できていれば[Done]にして、 新たな問題が発見された場合は、別のチケットとして別途見積もりをする事です。
そうしないと、終わらないチケットが永遠に続くのと、他のチケットとの優先度が決められなくなってしまいます。

Retrospective (週1)

ここは正直あまりできていません。定型的にやっていたのですがあまり効率が良くなかったからです。 どちらかというとレビュー中やプランニング中に、よかった点や悪かった点が自然に出てるようだったので、そちらの方でキャッチアップするようにしています。
ここは自分が学んでいかなければいけない所ですね。

Sprint Planning (週1)

優先度を確認して、次のSprintでやる事を確認します。
やる事が決まったら、それを[Sprint Board]-[ToDo]に反映します。
この時 [In Progress]状態のチケットがあったとしても、優先度が低くなった場合は [Sprint Board]から外すようにしています。 (ちょっと勇気が必要)

ツール

初めはWebで出来るツールを使っていたのですが、Webを開かなければいけないという所と、 大きく映せるモニターがなかったので、アナログな紙ベースで運用しています。
壁に貼ってあるので、普通に集まって話したり情報共有はしやすくなりました。

Sprint Board

f:id:k-ohata:20190606175703j:plain

Selected

[Product Backlog]単位のチケットを配置したり、 制作以外で動いている、共有事項を配置しています。 あと Readyのチケットはどうする?など、どこに配置して良いかわからないチケットや 気になる事項や懸念点は [Selected] に配置しています。 (何でもOK)

ここに貼っておく事で [Sprint Plannning] で対応優先度を決めたり 具体的なチケットに落としたりします。

[今気になること]という意味合いが強いかもです。 全員の[気になること]が可視化できていると思います。

e.g.

  • ユーザー管理機能 (チケットより大きい単位)
  • 運用フローを各部署と調整中など (全体の動きに関係のあるもの)
  • 規約の見直し必要だっけ?など

Sprint

現 Sprintのチケット単位の進捗状況を把握するためのスペースです。 主に制作担当(エンジニア、デザイナー)のチケットがメインです。

e.g.

  • ユーザー一覧
  • ユーザー登録
  • 検索UIの作成

Sprint - ToDo

Sprint内でやる事をチケット化したものです Velocityをベースに優先度が高い順に配置しています。

Sprint - In Progress

制作に着手したチケットをこちらに移動しています。

Sprint - In Review

制作側で確認出来るフェーズになったチケットです。 - エンジニアレビュー中のもの - ディレクター動作確認中のもの

Review

制作側の確認(In Review)が終わったチケットがこちらに移動されます。 [Sprint Review]で確認するチケットは、ここには貼られているチケットのみになります。

Product Backlog (ショートバージョン)

通常の Product Backog にSprintの線を引くと縦長になってしまい、わかりにくいという意見があったので 直近の優先度チケットだけ、Sprint単位に管理するようにしました。
実際やってみて、プロダクト側のスケジュールとリンクして検討できたのでよかったと思います。

f:id:k-ohata:20190606175726j:plain

各Sprintには、Velocity分だけのチケットを配置するようにしています。

Product Backlog (全体) & Story Board

ちょっと大きめなので、省略します。 基本的に一般的なやつです.

導入する際の心構え

メンバーに経験者がいない場合は、すぐに結果は出ないと思います。
なんとなく上手くいきだしたのが、導入後2ヶ月半くらいからでした。
みんなが、[なるほどねー]と効果を実感してきたのが、3ヶ月後 自然に回るようになってきたのが4ヶ月後かなという印象です。
初めの 3ヶ月はひたすらやりきるという[覚悟]が必要ですね。

初めの2ヶ月は結構ツライです。(本当に)
チーム全員が成果出ない間も協力してくれたので、やり切れたと思います!

導入した結果

リリース後も不具合もなく順調に運営されています。 また理論上出る確率は低いと思われていたエラー処理も、 優先度を上げて対応した事で、実際発生しても問題にはなりませんでした。

それぞれの観点を持ち寄った成果だと思います。
(本番運用は想定外も多いので、想定出来ることはやっておくべきですね!)

小さな野望として [Sprint Board] を、もう少しオシャレにしていきたいです。

まとめ

サービスや戦略などを一緒に共有して、サービスを開発したい エンジニアの方、お待ちしています!

あとScrumで情報交換してくれる方いましたら、よろしくお願いします!