エンジニアののりすけです。以前このブログで紹介されたスクラム ( https://tech.curama.jp/entry/2018/05/18/140000 ) についてのその後のお話です。
導入した経緯などは過去の記事を見てもらえればと思いますが、私自身もどんな変化をもたらしたのか整理する意味も込めてまとめてみたいと思います。
記事時点から変わった点・継続している点
スプリント期間の変更
記事の時点ではスプリント期間を1週間としていましたが、あまりにも短いため、2週間のスプリントを試し、現在ではスプリント期間を2週間としています。
様々な書籍などでも2週間のスプリントを推奨されていますが、個人的には1週間のスプリントを以下の点から経験できてよかったと感じています。
KPTは継続して実施
スクラムのメリットとして上がっていたKPTですが継続して実施し、いろいろな問題点をチームで共有、解決してきました。これらの積み重ねがチームの経験として溜まってきているように感じています。
当初はKeepやProblemをどう書けばいいかなどもありましたが、現在では具体的な問題だけでなく、漠然と「なんとなくおかしい」など抽象的な意見があがってもその問題を具体化する動きや、意見の上がったことに対して何かしらの策を講じたりなどチーム自らで改善を促す動きができるようになってきました。
ツールの変更(Trello -> Zenhub)
当初ストーリーの管理をTrelloで管理していましたが、スクラムを継続しているうちに大きいユーザーストーリーの管理をどうするかという問題に突き当たってしまいました。そもそも大きすぎるストーリー自体を避けるべきなど、様々なやり方を考えては見ましたが、Epicというストーリーをまとめる機能をもつZenhubというGitHub上で動くツールに変更しています。
不満点を上げるとTrelloのサクサク動く感じから少しもっさりとした動作が個人的には気になりますが、機能面では事足りている状況です。
受入れ条件の記述が良くなった
オーナーが記述するユーザーストーリーには受け入れ条件が含まれています。我々エンジニアはこの条件を満たすように設計/実装を行うのですが、記述内容についても時間の経過に連れて変化してきました。
スクラムを始めた当初、受け入れ条件についてどう記述すべきかいろいろ分からない部分もあり単純な情報しか書かれていませんでした。スクラム運用を進めるうちに様々な失敗(受け入れ条件漏れなど)を経験し記述方法を少しずつ修正することでエンジニア視点からもわかりやすい受け入れ条件が書かれるようになりました。
ストーリーの規模も違うので一概には言えませんがスクラム運用をはじめた当初はほとんどのストーリーで数個しかなかった条件が、現在では十数個ないし30近く条件が設定されているストーリーも存在しています。
これらの修正はKPTの振り返りで「あのストーリーの受け入れはこう書くべきだった」などの意見がでたり、エンジニアからも「これを受け入れに含めてほしい」などオーナーとチームメンバー双方で受け入れ条件をちゃんと確認する習慣もできてきています。
スプリントプランニングの変化
当初の状態から大きく変化したものの1つがこのスプリントプランニングだと思っています。当初はとにかく口頭で「こんなことやる必要あるよね」などの会話を行いそこからプランニングポーカーでストーリーポイントを振っていました。
このやり方でも何度か試すうちにお互いの考えていることの理解が深まり、見積もりを行うポイントは近づいていったのですが、いざスプリントが始まるとプランニング時に想定していた事と異なるケースが発生したり、しまいにはプランニング時に何を話したか忘れるなど、どうしようもない事が発生したりしていました。
これらのことを踏まえてプランニング時に検討するべきストーリーについて設計面までチームで行った上で見積もりを行うようにしています。 設計といっても具体的には実際のストーリーを満たす実装を行うためのドメインモデルやDBモデルをプランニング時にホワイトボードに書き出すなどあくまでラフスケッチレベルの物ですが、これを行うことで見積もりの精度があがったり、プランニング時にチーム全員で一度設計を考えているため実装にスムーズに入れるなどのメリットを感じています。
また副次的な効果で設計に関するノウハウがチーム全員の学びになっているなど各メンバーのスキルアップにもつながる効果が出ていると思っています。
必要に応じたペア・モブプログラミングの実施
スクラムチーム内でのスキルのばらつきを解消するため率先してペア・モブプログラミングを行ってきました。こちらについては現時点でも行っていますが当初ほど頻繁には行っていません。特に言語化したルールのようなものはありませんが、初めて実施しようとすることだったり、実装に自身が無い場合などは今まで通り率先してペア・モブプログラミングを行っています。
頻繁に行われなくなった理由の1つは、前述の通りプランニングで大枠の設計もある程度決めているので実装時に不安に思わなくなってきているというのもあるのかもしれません。
なお、みんまでペアプロする場合はVSCode + Live Shareを組み合わせて行っています。
まとめ
まだスクラムを開始してから1年も経っておらず、改善すべき点はあるのかもしれませんが、途中段階としてアウトプットしたことで様々な変化があったことが改めてわかりました。最後に現時点状況を簡単にまとめます。
KPT
- Keep 75件
- Problem 101件
- Try 39件
スクラムを開始した4月から現時点で累計101件の問題点をチームで上げ、その中ですぐに解決すべきとして改善したものが39件という結果でした。
ベロシティの推移
改めて見ると安定しているとは言い難いですが、ベロシティが上がらなかったスプリントの振り返りで原因などはつかめているので良しとしましょう。
我々みんなのマーケットテックチームでは「くらしのマーケット」を一緒に作る仲間を募集しています！興味がある方はぜひ気軽に連絡ください （コーポレートサイト https://www.minma.jp/ ）
