イケてる開発チームを作るために、アジャイル開発プロセスを導入した話

Reactでは高速でプロダクトを生み出すため、強い開発チームを作るため、アジャイル開発を取り入れています。この記事ではReactで大事にしているポイントと具体的なフローに関して説明します。

アジャイル導入の目的

まずアジャイルやることが目的ではない。

インタビューとかを重ねていって何を作るべきかが結構流動的に変わる
エンジニアのリソースも流動的（月ごとに人数が変わる）

という外も中も流動的な状況でアウトプットを最大化する、なおかつ

製品の各機能はできているけど全然動かない状態でメンバーが離脱するといったリスク
最後に各メンバーのつなげて何とか完成したけど、イメージと違って作り直しじゃんというリスク

を避けるためのベストな開発手法がアジャイル開発だったというだけ。
製品の段階によって、局所的にウォーターフォール型を取り入れることも全然ありえる。

なおかつ仕様、デザインが決まるのを待つのではなく、開発チーム内でユーザーの問題から「何を作るか」を考えられる、スケジュール立てられるようになるためにもアジャイル開発は適している（＝自立した開発組織）

自ら目的を立てて自律的に行動--アジャイル開発で必要な「自己組織化」の進め方
https://japan.zdnet.com/article/35071411/

アジャイル開発での根本的な改善活動--KPTから考える「ふりかえり」の重要性
https://japan.zdnet.com/article/35085467/

納品のない受託開発（切り口は違うが本質的）
https://www.sonicgarden.jp/32

アジャイル導入で目的ではないもの

たくさんコードを書くこと
この分野しかやらないというこだわり
開発に必要な仕様、デザインが完璧に記載されたドキュメントを作ること
きれいに細分化されたタスクが並んだかんばんを作ること
バーンダウンチャート、インセプションデッキといった何か良さそうに見えるドキュメントを、目的なくたくさん作ること

導入にあたっての必要な前知識

アジャイルサムライ 2800円
とりあえず第６章、第７章だけ読めばOK
※SIerの受託開発をベースにしているので、プロダクト開発の場合は顧客という言葉は全てプロダクトマネージャーに置き換える

（参考）
アジャイル開発時におけるプロジェクトの進め方
https://qiita.com/sinaku-developer/items/bd74bde161b640b75b70

ユーザーストーリーに関して
https://www.slideshare.net/papanda/ss-41638116

アジャイルとウォーターフォールの違いは知っていて欲しい

方針

リソースが流動的なので、細かく分担して最後につなげるは危険。環境を用意し製品が常に動く状態を維持する
開発期間は３週間で絶対に動かさない。そこに間に合わなければ機能をドロップする。
「見積もりを積み上げて、期日を決めるという思考ではなく、期日は動かさない。スコープ（リリースする機能）を変える思考」
デザイン、仕様が決まってないからできません。。。はNG。最終責任はPOにあるが、全員ゼネラリストのマインドで開発する
ユーザーストーリー、タスクはざっくり。完璧なドキュメントに残して「そこを見てよ」ではなく会話で解決する。いいユーザーストーリーは会話を促す
アジャイルの全てを最初からやる必要はない。少しづつ取り入れてチームに合わせていく

基本的なタームとルール

sprint : 開発期間。イテレーションとか呼んだりもする。1サイクルは水曜日から開始し、1週後の水曜日までとする
KPT : 運用の振り返りをsprint終了日の水曜日に実施する
UserStory : ユーザーが〜できるという観点で書かれたissue。いわゆるINVESTを満たすように注意。開発初期でのメインのタスクリスト
estimate : ストーリーポイントとも呼ばれる、相対的な見積もり。S,M,Lの３つ。MがSの３倍のような相関関係というわけではない
Backlog : プロダクトへ対する実施リスト。機能だけでなくCIや環境も含む
Daily scrum : スクラム。毎日夕方やります。
Velocity: 1sprintでこなせたUserStoryのサイズと数

一般的なアジャイルと違うところ、Reactカスタム

Issueは厳密には管理しない
通常だとUserStoryが決まり、それを各開発者が分解して0,5~1.0人日の粒度にしてバックログに追加してバックログのタスクをベースに進捗管理する
これに対して今回のアジャイルではUserStoryだけを決めて、そこからのタスクは各開発者におまかせで特に管理しないスタンス。
開発人数が多い＆スキルが未熟なほど、これをやる優先度が上がるが、極論、開発者の自己管理でUserStoryベースでやれるならそっちのほうが効率いい（管理コストかからない）
KPT振り返り
通常はチーム全員で１時間とかやるが、フルコミットで自立させたい開発者と1on1形式でやる
振り返りの目的が開発組織内でどうやったら生産性あげれるか、どういうもの作るべきか考えられて自立するっていうところにあるので、
フルコミット以外にノウハウついてもあまり旨味がなく、発言する時間減るのももったいないから
スクラムの実施時間
普通は朝にやるが、夕方にやっている。理由はエンジニアの１人が夕方からオフィス来るのに合わせているだけ。あと皆朝弱いので

運用フロー

アジャイル開発スタート前

UserStoryをざっくりと書き出す
UserStoryに対してストーリーポイントをS,M,Lをつける。
付け方はプランニングポーカーのやり方で行う。まずスクラムマスターがS,M,Lの基準になるUserStoryを決める。
それをものさしにした上でエンジニア全員参加のMTGで、UserStoryを選んで説明していき、全員で自分が思うストーリーポイントを挙げていってもらって相談の上決める。見積もりの精度を上げるのと、開発者全員が何をどうやって作るのかのイメージを共有するため

スプリント開始後

1day
開発開始。一番ダレやすい日でもあるので、dailyScrumでは明日のscrumまでに何をやるのかを各自コミットして引き締めをする

2day
Mサイズ以下のものは開発完了してマージされ始める

3day
開発評価環境で動かし始める。conflict起きて動かなかったりするので、環境を安定させるのを優先
ここらへんからPOの実機レビューが始まっていく

4day
最後の追い込み。着地させるために機能のドロップも視野に入れる

5day
POの最終実機レビュー
velocityまとめる
KPG振り返りする
次イテレーションでやるUserStory,Backlogを決める

sprintに含まれず、随時行うこと

（PO,SM）実機を触って足りないと思った機能を見つけたらタスクを起票。
本当に細かい修正やユーザーメリットが表現しにくい、修正が明確なもの（デザイン修正など）
→バックログに追記

それ以外のタスク
→ユーザーストーリーに追記

今後、改善したいこと

ユーザーストーリーがもう少しあいまいでもいい。というよりはエンジニアがもっと早い段階から製品についての議論に入るべき
CIまわりをもっと安定＆自動化したい。エンジニアがビルド、デプロイを何も意識せず開発に集中できるようにする
デザインとフロントエンド開発をもっとごちゃまぜにしたい
エンジニアが自主的にバックログを起票していけるようにしたい

Q&A

KPTふりかえりとデイリースクラムの違いは？

デイリースクラムはスプリント内のタスクの共有と、起きている問題を暫定策でも解決して、とにかく終わらせることにフォーカスする場です。
それに対してKPTは開発組織がよりアウトプットを出すためにはどうすればいいか、を自立して考えれるようにすることが目的。起きた問題に対してもイテレーションとか関係なく、恒久的な再発防止、対応策を考える場。

会話で解決とありますが、メンバーの流動性が高いし、ドキュメントも大事だと思っているのですがどうでしょうか？

あくまで「会話で解決」というのは「ドキュメントに仕様として全て完璧に表現しよう。開発者はそれだけを見て開発して」という絶対に失敗するであろう状況を起こさせないがための表現で、ドキュメント化ももちろん必要です。
製品がどういうビジョン、問題を解決するものなのか、ざっくりどういった機能がどのversionで必要なのかはドキュメントとして残すべきだと思います。

ユーザーストーリーのINVESTって何？

ユーザーストーリーが満たしているべき条件のことで
Independent(独立している)
Negotiable(交渉可能である)
Valuable(価値がある)
Estimable(見積もり可能である)
Sized Right(適切な大きさである)
Testable(テスト可能である)

の頭文字をまとめたものです。

見積もりは何でS,M,Lの３つなの？誰がやった場合を基準に考えるの？

標準的なエンジニアがやった場合でS,M,Lを考えます。
なのでエースだったら１イテレーションでM４つ、新人だったら１イテレーションでM2つみたいになりますね。

「このタスクは２時間くらい、じゃあこのタスクはちょっと重いから2.4時間かな、こっちは3.2時間くらい」みたいな意味のない細かい見積もりをして、最後にそれを足し算して「じゃあこの製品は148.5時間かければ作れるよね」みたいな状況を防ぎたいので、あえてざっくりしか見積もれないようにしています。
なので、そこにピンが止まっているなら、別に４時間、８時間、１６時間とかでもいいと思います。