モブプロを始めてから一度なくなったけど戻ってきたプラクティス達

この記事は、モブプログラミングAdvent Calendar 2018 8日目の記事です。

Photo by Daniel Jensen on Unsplash

私が所属しているチームは、B2Bのサービスの開発と運用、加えてちょこっとコンサルティングっぽいこともモブでやっています。モブプログラミングを開発だけにとどまらず、働き方として実施しています。この働き方を始めてから消えていったものがあります。

うちのマネージャーの@TAKAKING22 が色々なところで出しているのでみたことあるかもしれません。これらは確かになくなりました。しかし、最近になって形を変えてやり始めたものがあります。

経緯

一度なくなり、そして再び戻ってきたプラクティスの話をする前に、その背景にあるプロダクトやチームのおかれていた状況について説明します。細かな経緯については、先日発表してきたのでそちらをご参照ください。

PoC

今私が所属しているチームは、もともとスクラム開発の経験を持つ人たちで構成されています。ですので、モブプロを始めた頃は、日々の開発はスクラムが起点となっていました。その頃、新しいプロダクトの開発が始まったばかりでもあり、まだお客さんは付いていませんでした。そのため、チームメンバーの繋がりなどを頼りに、お客さん候補のところへチームで訪問していました。プロダクトのデモをして、反応や最近抱えている悩みなどを聞いてまわっていました。それを毎週のように行っていたので、スプリントのサイズは自然と1週間となっていました。毎週の往訪でデモと、それを受けてお客さんと一緒に次週までに作るものを決めていたので、これがスプリントレビューとプランニングに相当していました。

この頃に、上に挙げたものが一度なくなりました。メンバー全員が常に最新のプロダクトを前に、変更も全員の眼の前で実施していたので、経緯説明など同期作業がいらなかったからです。

サービスイン

色々なご縁の関係で、実際に利用していただけるお客さんが見つかり、そのお客さんに向けてプロダクトを形作っていきました。サービスインしてからも、それまでと同じようにお客さんの元へ赴き、次にどのようにプロダクトを変更していくか、いつリリースするかを話合い進めていました。つまり、PoCの頃のように直接デプロイするようなことはできなくなりました(当たり前ですねw)。

GitHub Flowとプルリクエスト

PoCの頃、ブランチはほぼmasterのみでしたので、直接コミットし、それをpushしていました。そして、眼の前でコードが変更されるのでレビューが必要なくなり、プルリクエストを作成する必要がなくなりました。

サービスインした後は、開発中のものやリリースを控えているものを実際の本番稼働しているコードから分ける必要があります。リリースした時点でタグを付けて、masterにコミットしつづけることも考えたのですが、事故の原因になると思ったのでやっていません。そこでGitHub Flowに採用し、プルリクエストを作成するようにしました。プルリクエストを作成した後、レビュー(?)をしています。

ですが、ここでのレビューはこれまでのレビューとは異なる目的です。これまで通り眼の前で変更とコミットがされているのでやっていることはお互いに分かっている状態ですので、変更内容の共有や知識を伝えることは目的ではありません。ここでは、個々のコミットではわからない、最終的な変更の全体を見返し、ヌケモレの確認や過去の自分たちが気づかなかったことは無いか確認をしています。「チーム全員で見ているからヌケモレなんてない」とかありません。やはり人なので忘れたりするのは当然です。また、変更の全体を見直しした時に気づくことも多々あります。

カンバン

スクラムで開発していた時、スプリントバックログはカンバン方式で管理していました。個人ごとにレーンを持っていましたが、モブを始めると、一つのレーンになり、ステータスもToDo、Doing、Doneのみでした。

サービスイン以降は、スプリントバックログから着手可能な機能開発から手をつけ、スプリントレビュー時にリリース日を調整するので、すぐには完了にいきません。そのような状況を踏まえて、カンバンは下のようになりました。

我々のカンバン。使ってないディスプレイにスチレンボードをテープで貼り付けて立てている。

ToDo、Doing、Doneはこれまで通りですが、新たにTestとReadyが加わりました。先述の通り、GitHub Flowで開発しているので、各タスクごとにブランチを作成し、開発を始めます。開発が終了し、テストできる状態のものがTestに移します。そして、Testが完了したものが、リリース可能を意味するReadyへ移します。Readyのうち、リリースが終わったものがDoneに移します。

おわりに

モブをやることでメンバー間の同期のための作業はなくなりました。しかし、モブといえども、稼働しているプロダクトを維持しつつ変更を加えていくためには、その状態を管理するための方法が必要になります。「モブだから必要ない」ではなく、プロダクトの開発の状況に応じて、どのように進めていくのかをチームメンバー全員で作っていかなければんりません。

というごく普通で当たり前な話でした。

参考