Re:Backlogs の使い方を Twitter もどきアプリの開発を例に紹介します

はじめに

先日、Re:Backlogs をリリースしました。

Re:Backlogs というプロジェクト管理(タスク管理)ツールを OSS としてリリースしました [Ruby] on @Qiita https://t.co/p8QETLgiU9

— kaishuu0123 (@kaishuu0123) 2019年12月20日

ですが、このツール、初めて使う方には「このツールがどう嬉しくて、どう使うのか？」というのが「分かりづらいかも ... ( >﹏<)」と思い、このエントリを書きました。

(とはいえ、redmine_backlogs と使い方は一緒でアジャイル開発に向いているのですが、それもそれで使い方の解説はあまり無く ...)

なので、一つの例として、「Twitter もどき(Web)アプリを作る」というシチュエーションで使い方を紹介していこうと思います。

そもそも Re:Backlogs は下記のような悩みをサポートすることを目的としています。

• 「やりたいことはあるけど、そこそこやることが多くて、上手く整理できない」
• 「継続的な開発、運用をしていくのが大変だし、そもそもどうやればいいの？ガチガチな体制ではやりたくない ...」
• 「複数人で分業したいけど、どう分業するのがいいか分からない」

これらの「思い浮かぶことは曖昧だけれども、基本的な項目はすぐに思いついて着手できる」ようなケースには向いていると思います。

また、Re:Backlogs を使う上で、下記のようなフェーズがあります。

1. プロジェクト自体の計画 (プロダクトバックログに Story を追加)
   • 実現したい機能、目的の追加
   • ここでは「できるかどうか」ということは考えずに、「実現したいこと」に集中します。
2. Sprint 計画 (プロダクトバックログから Sprint に Story を追加)
   • プロダクトバックログに列挙された目的がどの程度消化できるかを考えます。
3. Sprint 消化 (Kanban 画面で Task を追加して消化)
   • 偉そうに計画を立てるフェーズから実作業に入っていきます。

それぞれのフェーズは同じ人が担当したり、異なる人が担当することもできます。

それでは順を追って、アプリ開発の計画を立てていきましょう٩(ˊᗜˋ*)و

Re:Backlogs でプロジェクトを作成

まずは Re:Backlogs 上でプロジェクトを作成します。

• プロジェクト名: Twitter もどきアプリ
• 説明文: 適当
• チケットプレフィックス: TMDK

TMDK というのは (Twitter MoDoKi) の頭文字を取りました。

ラフな設計フェーズ

Twitter もどきアプリを作るときにはまずアプリの設計から始めます。そんな仰々しいことはせず、箇条書きで思いついた順に機能を書きます。

1. アプリにログインができる
   • この機能がないとユーザが識別できませんね
2. ログインしたユーザで Tweet ができる
   • Twitter における核の機能です
3. ユーザがほかのユーザをフォローできる
4. Tweet に対して「いいね！」できる
5. Tweet を Retweet できる

...

とこんな感じで核となる機能を列挙していきます。

「〜できる」という形式で書くと目標としてわかりやすくなると思います。

また、箇条書きの 1 項目が大きすぎると感じる場合には、複数の Story に分割すると達成しやすい目標になりやすいです。

設計を元にストーリーを起こす

上記の箇条書きを元に Story を追加していきます。

追加し終わると、下記のような形になると思います。

Story のカテゴリ

カテゴリ名	日本語別名	意味
Feature	機能	機能追加をする Story はこのカテゴリになります。開発目的である場合、大半の Story がこの Feature カテゴリに属します。
Improvement	改善	UI を良くしたり、処理速度を上げるためなど、アプリ自体の改善目的のために使います
Bugfix	バグフィックス	文字通り、アプリ内でバグが出たときのためのカテゴリです。不具合を修正するために使います
Support	サポート	アプリを開発する上でインフラ系の作業を行うときや、ドキュメントを執筆するなど、開発とは異なる Story に使います

起票したストーリーを元に sprint 計画を立てる

「Sprint を追加」から Sprint を追加して、2 週間程度で消化可能なストーリーをプロダクトバックログから Story をドラッグ & ドロップして追加していきます。

今回はログイン、Tweet、フォローあたりが消化可能という前提で Sprint に追加します。

ストーリーを消化していく

計画した Sprint を元に消化フェーズに入ります。

Story を消化する人は実作業者になります。

ここからは Kanban の画面に入ります。

Kanban の画面から「Task を追加」ボタンで Story を達成するためのタスクを追加していきます。

後は自分で追加した Task を消化していきます。

Task のステータス

ステータス名	日本語別名	意味
New	新規	タスクを何も着手していない
In Progress	進行中	タスクを進めている
Resolved	解決	タスクが解決した状態。誰かの確認(自分自身でも OK)によって Done に遷移します
Feedback	フィードバック	解決になったタスクで何らかのフィードバックがある場合、ここにタスクが移動します
Done	完了	タスクが確実に完了である状態です
Rejected	却下	タスクとして却下するケースです。ちゃんと却下理由を残しておきたい場合に活用します

Sprint を閉じる

Sprint 内の Story が全て完了( Task が全て Done )になると、Sprint を閉じることができます。

繰り返し

これ以降は先述したフェーズを繰り返していきます。

• プロダクトバックログから淡々と Story を消化してもよいですし、
• 足りない機能などがあれば、また Story を起こしたり、
• Sprint の計画を立ててみたり

と自由に使うことができます。

端的に言えば 「1. 実現したい目的を列挙する」「2. 計画を立てる」「3. 計画を消化する」というサイクルを回すイメージです。

Re:Backlogs を使うことによるメリット

重要なことは

「大きな目的を達成するために小さい目的をたくさん作って、段階的に大きな目的を柔軟に達成すること」

なので、あまり堅くやりすぎず、積み重ねていくことが大切だと思います。

完璧にやろうとしすぎて、せっかくのアイディアが実現できずに挫折してしまったら意味がありません。

それよりも手堅いところから進めながら、自分が起こした Story を後からみて、機能カタログを見るような気持ちで進めていく方が開発や作業は楽しいと思います。

また、Story を細かく分けて起票することにより、複数人での分業がしやすくなります。

また、Sprint の計画を 1ヶ月にすることによって、月次作業に適用することもできますし、Story のカテゴリを自由に編集できるので、運用作業や個人・複数人の ToDO に転用することもできるかもしれません。

最後に

自身でめっちゃ使っているにも関わらず、ほかの人に進め方を説明しようとすると結構難しいですね ( >﹏<)

ニュアンスが伝わって活用して頂ける方が少しでも増えたら光栄です✨