OSSの自作ツールを開発するときにひとりスクラムをやってみた
OpenAPI YAML to CSV/Excel ConverterというOSSを開発しました。
最近、Scrum Inc.の認定スクラムマスターの資格を取得したこともあり、スクラムをより知ることを目的にとしてスクラム開発をひとりで実施しました。
スクラム開発はひとりでやるものではないとはもちろん理解しているのですが、スクラムイベントを定義通りにやってみることで発見や気付きがあるのではないかと思い実施しました。
参考：スクラムガイド
企画
スクラム開発であろうと何であろうと、まずは最初に何を作るかということを決める必要があります。
最近の業務の中で、OpenAPI仕様に沿って記述されたAPI仕様書(yam)をCSV形式のAPI一覧に変換したいという要望がありました。
そこでCLIで実行できる変換ツールを作成することとしました。
企画の経緯やプロダクトの内容はこちらの記事もご参照いただければと思います。
スクラム開発
スプリント0
企画とプロダクトゴールが決まったので開発に取り掛かりたいところですが、まずはプロダクトゴールやプロダクトバックログを準備します。
スプリント0として以下のようなバックログを作成し準備を実施しました。
プロダクトゴール
スクラムガイドを見るとプロダクトゴールの定義は以下のように記述されています。
プロダクトゴールは、プロダクトの将来の状態を表している。それがスクラムチームの計画のターゲットになる。プロダクトゴールはプロダクトバックログに含まれる。プロダクトバックログの残りの部分は、プロダクトゴールを達成する「何か（what）」を定義するものである。
そこで今回開発するOSSのプロダクトゴールとしては以下のようにしました。
Open APIで書かれたYAMLファイルをCSV/Excelに変換できる
プロダクトバックログ
次にプロダクトバックログを作成します。
今回初めてやるようなこともいくつかあったため、
- まずは仮でプロダクトバックログを作成
- 初めてやることを調査
- プロダクトバックログを更新
という流れで進めました。
詳細は割愛しますが、2の調査を実施するにあたって参考にしたページを掲載しておきます。
OSS開発の記事を見る
npmライブラリの公開方法を調査する
Node.jsのCLIの作成方法を調査する
プロダクトバックログをまとめるにあたってはユーザーストーリーマッピングという方法を活用しました。
Story mapping is a better way to work with Agile user stories
User Story Mapping is a dead simple idea. Talk about the user’s journey through your product by building a simple model that tells your user’s story as you do. It turns out this simple idea makes working with user stories in agile development a lot easier.
これによって作成したユーザーストーリーマップが以下になります。
ここで1つ重要なポイントとして、ユーザーストーリーマッピングで初回のリリースに含まれるものがどこまでか(Release1と書いてある線)を定義していることです。
ユーザーストーリーマップで俯瞰して確認することで、優先順にバックログに取り組みつつ、ユーザーストーリーに沿っての依存関係が確認ができます。これにより、ユーザーが実現したいこと抜け漏れがないかを確認できるようになります。
スプリント1
スプリントプランニング
プロダクトバックログと初期リリースの内容が決まりましたので早速開発を始めます。
スプリントの期間は1週間としました。
最初にまず、スプリント1のスプリントゴールを決めます。
スクラムガイドの定義には以下のように記述されています。
スプリントゴールはスプリントの唯⼀の⽬的である。スプリントゴールは開発者が確約するものだが、スプリントゴールを達成するために必要となる作業に対しては柔軟性をもたらす。スプリントゴールはまた、⼀貫性と集中を⽣み出し、スクラムチームに⼀致団結した作業を促すものでもある。
スプリントゴールは、スプリントプランニングで作成され、スプリントバックログに追加される。開発者がスプリントで作業するときには、スプリントゴールを念頭に置く。作業が予想と異なることが判明した場合は、スプリントゴールに影響を与えることがないように、プロダクトオーナーと交渉してスプリントバックログのスコープを調整する。
スプリント1のゴールは以下のように設定しました。
OSS開発が行えるような開発環境を整備する
これを踏まえてスプリント1のスプリントバックログは以下に設定しました。
スプリント実施
スプリントゴール、スプリント期間中の優先順位も決まったのであとは上から順にバックログに取り掛かっていきます。
毎日、デイリーミーティング(ミーティングといっても一人ですが)を実施して、その日に取り組むことやスプリントゴール達成に向けての進捗を確認しながら進めました。
スプリントレビュー
基本的には順調に進んでいき、スプリントプランニングで計画したスプリントバックログが完了したため、次のスプリントで実施予定だったことも先取りして取り組めました。
最終的にスプリント1で取り掛かったバックログは以下のようになりました。
スプリント計画時点
スプリント完了後
スプリント2
スプリント2でもスプリント1と同じようにスプリントゴールを設定して、スプリントプランニングを決めて取り組みました。
実施したことはスプリント1と同じため、スプリントバックログのみ掲載しておきます。
スプリント計画時点
スプリント完了後
スプリント2の途中でver1.0.0をリリースすることができ、さらに少しの機能を追加してver1.1.0のリリースまで行えました。
スプリントレトロスペクティブ
各スプリントの終わりにはスプリントレトロスペクティブも行っておりまして、その内容も簡単に記述しておきます。
スクラムガイドでは以下のように定義されています。
スクラムチームは、個⼈、相互作⽤、プロセス、ツール、完成の定義に関して、今回のスプリントがどのように進んだかを検査する。多くの場合、検査する要素は作業領域によって異なる。スクラムチームを迷わせた仮説があれば特定し、その真因を探求する。スクラムチームは、スプリント中に何がうまくいったか、どのような問題が発⽣したか、そしてそれらの問題がどのように解決されたか（または解決されなかったか）について話し合う。
スクラム開発で良かったこと
ひとりでもスクラムをやってみて以下のような点が良かったと思います。
- スクラムガイドをあらためて見直してみるきっかけになった
- 優先順位をつけることで何から取りかかればよいのかが明確になる
- 最初のリリースまでに取り組むことが漏れなく明確になる
- バックログの消化状況をみることであとどれぐらいで終わりそうかのざっくりとした見通しができ、スケジュールの予想がたつ
- 個人開発だとあまり時間が取れないためタスクが細切れになりがちだがバックログを細分化しておけば細切れにして進めても進捗がわかりやすい
イマイチだったこと
一方で以下のような課題もありました。
- 2スプリントでリリースまでできてしまったので、ベロシティを計測するということができなかった
- ベロシティが計測できなかったのでいろいろと改善に取り組んだことの効果が定量的にはわからなかった
- プロダクトオーナー、スクラムマスター、開発者という役割をすべてやることになるので、どの役割で今考えているかはもう少し意識してやれると良かった
まとめ
まずは予定していたものがきちんとリリースできたことは良かったです。
OSSを作るというのは初めてのことだったのですが、インターネット上にいろいろなノウハウや経験を共有してくださっている方がたくさんおりとても参考になりました。
ちょっとした気持ちですが、参考にさせていただいた方の記事やリポジトリにはいいねやStarをつけて感謝の気持ちを伝えておきます。
自分の業務用に作成したものではありますが、ご興味持っていただいた方はぜひお使いいただけると励みになります。
Discussion