弊社の他のプロジェクトでスクラムを導入しているので、今期から、うちのプロジェクトでもスクラムやってみるか～と思って勉強中です。勉強中というかチケットの管理方法とかを本を読みながら模索してルールを作ったりしました。
元々ある課題
結論からいうと、開発チームがなかった。正確には、1人だからチームじゃなかった。
私が担当しているプロジェクトは、開発チームではなく、長いことほぼ1人で担当していたため、そもそもスクラムをやるというモチベーションがありませんでした。途中で開発に参加してくれる人もいたのですが、元々違うプロジェクトを任されていて兼任になるため、私的にもなんか気を遣ってしまっていました。兼務なので、そちらが忙しくなるとフェードアウトしていってそのまま…という感じ。で、ようやく昨年新卒の後輩さんが私の下についたので、徐々に教えている状態。まだ本格的にプロダクト開発には入ってないので、これから。
まぁ他にも色々と課題はあるのですが、それは一旦置いといて（書けない😛）、とりあえず2人体制になれたので、メイン開発を後輩さん、スクラムマスター兼開発サポート・裏方を私がやろうかなというところです。これがいい体制なのかどうかといえばよくはないのだが人数が足りないんだ！（スクラムの開発チームは3～9人とか…）
やったこと
本を読んだ
とりあえず、スクラムに関する知識が齧ってる程度だったので、指針になるものを仕入れようと思って本を読みました。参考にした本は、SCRUM BOOT CAMP THE BOOKです。
非常に面白くて読みやすいし、こういう時どうするの？っていうのが載っててよかったです。これを読んで、うちのプロダクトは月末リリースなので、スプリント期間を3週間、リリーススプリントを1週間にしようという考えになれました。また何度も読み返すことになりそう。
チケットを整理した
元々、顧客からの要望やアンケートの結果、運用の課題などについてはRedMineのチケットにして管理していたのですが、開発上の課題はそこには書かず、GitHubのissueで管理していました。まぁそれは当初は、開発上の課題は見せなくてもええやろという感じだったのですが、それだと要望と開発の課題のどちらが重要かという判断が難しいし（両方見えているのは私だけになるので私の判断になる）、全然RedMineのチケットの消化が進んでいないときは、「開発（というか私）は一体何やってるの？🤔」っていうのが関係者に見えないのが辛いなと思ってました。いや、前期はRails6にアップグレードしたり、webpackerに移行したり、やってるんやで…😭
スクラムでスプリントを回そうと思ったら、ベロシティの計測しなければ開発の予測が立てられませんし、開発の課題も関係者に認識してもらうためにRedMineのチケットとして登録しました。GitHubからはissueからRedMineのチケットにリンクを貼るようにしました。その際に、「RedMineのチケットへのリンクが面倒やなぁ～」と悩んでいたら、同僚がGitHubのAutolink referenceの記事を書いてたのでそれを参考にさせてもらいました！🙏
これを設定すると、例えばGitHubのissueでTICKET-12345と書くと、自動的にRedMineのチケット番号12345にリンクが貼られるようにできます。圧倒的に楽！見た目も綺麗！👍
チケットのルールを定義した
スクラムだと、課題はプロダクトバックログと呼び、プロダクトバックログに対するタスクはスプリントバックログと呼びます。
最初はRedMineのチケットの呼び方を「チケット」と変えずに、関係者には軟着陸しようかと考えていましたが、多分ごちゃごちゃしてくるなと思ったので、ルールをRedMineのWikiに書きました。その時に、チケットはプロダクトバックログとスプリントバックログの2種類になりますが、皆さんは今までのチケットの運用と同様にプロダクトバックログのみを意識してもらえばいいです、開発者が何しているかはスプリントバックログを見ればわかります、と言えるようにしました。
要は、「言葉の定義や呼び方は変わるけれど、皆さんのチケット運用方法はほぼ変わりませんよ～😀」ということで、大きな変化ではないと思ってもらえるようにしました。まぁ受け手がどう感じたかはわかりませんが…。
あとは、開発側はTiDD（チケット駆動開発）にしたいと思っていたので、スプリントバックログには必ず親チケットとしてプロダクトバックログのIDを付けるように！というルールにしました。これで、どのプロダクトバックログを実現するために何をやっているのかが明白になるはず。また、スプリントバックログに関しては、ステータスを簡潔にするために、
- 新規
- 対応中
- 終了
の3つだけにしました。
チケットのテンプレートを作った
今まではチケットのフォーマットが特に決まっていなかったので（こう書いてほしいという指針はあった）、書く人によっては情報が足りなかったり、以前に却下された要望が何度もゾンビのように復活してきたりということがありました。そこで、テンプレートを作りました。
テンプレートでは、ユーザーストーリー形式で書いてほしいことを伝え、フォーマットとサンプルを付けているのと、もう対応しないことになっている件をリスト表示しておきました。
後輩とプランニングポーカーした
した、と過去形にしていますが、正確には、している最中です。基本的に作業をしてもらうのは後輩さんだけれど、まだ実際に開発していないので、プロダクトバックログの内容を私が製品の画面のここの修正のこと、と説明して、それからプランニングポーカーでお互いに投票して、数値が違えば意見を聞いたりして、基本的には後輩さんの主張したストーリーポイントを設定していく、という感じ。
今は在宅勤務することが多いので、プランニングポーカーもオンラインでやっています。これもまた同僚が教えてくれたやつですが、hatjitsuというプランニングポーカーをするためのサービスがあって便利😁
これからどうするか？
現時点でも、後輩さんにメインをやってもらうと決めたので、開発の課題なのに後回しになっていたところ（ミドルウェアのアップデートとか、リファクタリングとか）に切り込んでいきやすくなったので、現時点でもちょっと効果は実感できてます。 とはいえ、色々あってまだ準備段階。まだちゃんとしたスプリントには入れてません…。とりあえずスプリントが開始できたら、関係者からフィードバックをもらって、修正していきたいと考えてます。
