saino.me

都内でひっそりと生きる IT エンジニアの個人ブログです

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

はじめに

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

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

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

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

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

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

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

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

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

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

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

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

f:id:kaishuu0123:20191223124932p:plain

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

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

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

ラフな設計フェーズ

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

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

...

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

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

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

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

上記の箇条書きを元に Story を追加していきます。 f:id:kaishuu0123:20191223125319p:plain

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

f:id:kaishuu0123:20191223125332p:plain

Story のカテゴリ

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

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

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

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

f:id:kaishuu0123:20191223125645p:plain

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

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

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

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

f:id:kaishuu0123:20191223131355p:plain

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

f:id:kaishuu0123:20191223132254p:plain

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

Task のステータス

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

Sprint を閉じる

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

f:id:kaishuu0123:20191223133746p:plain

繰り返し

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

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

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

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

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

重要なことは

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

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

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

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

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

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

最後に

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

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