Because We Love Happy Coding

フリーライターからエンジニア × 講師。発信力だけあり余ってる感じ

ClickupとGithubEnterpriseで顧客要望含め管理する運用案

今日もまたコーディング。だって僕らはHappy Codingが大好きだから。

顧客の要望をシステム改修に実装する、という事をしていたんだけど、回を重ねるうちに管理が煩雑になってきた。

  • 顧客の要望は、機能単位で来るわけではない_ - 顧客の要望は変化する
  • 要望がもれなく実装されたか、確認する必要がある
  • 実装スケジュールや実装順に紐づけて管理したい

私が普段から使っているタスク管理アプリ「Clickup」で運用を考えてみた。ClickupはGithubとの連携には対応しているが、Github Enterprise(オンプレミス版)には非対応。弊社ではGithubEnterpriseを使用しているので、連携は手動になる。

なお以下の要件は記事には登場しないのであしからず。

  • 複数ユーザーでのタスク共有
  • togglなどの時間管理

管理の要件

顧客の要望は割とカオスな感じで出現する。

  • 機能単位になっていない。
  • 時間差で発生するし、前後の要望に影響する可能性もある。
  • ソースコードのあちこちに影響範囲が散らばっている。
  • 完了したら消し込みをする必要がある。

つまり、一覧で管理する必要がある。

一方、実装作業の方も管理する。 - 機能単位で管理する必要がある - 最新版の要望と紐づけてあってほしい - ソースコードのどの部分か、紐づけてあってほしい - 完了したら消し込みをする必要がある - 完了したら、関連する要望も消し込みしなくてはならない - ガントチャートでスケジュール管理する

これらの要望を満たしたい。

設計

  • プロジェクトフォルダ
    • List「Requests」
    • List 機能単位
    • List 「Test」
  • Github Enterprise

手順

顧客の要望をRequestに入れる

保全の意味もあるのでできるだけそのまま入れたい。

  • 長文の場合はタイトルを「2020年1月20日要望」にしてDescriptionに入れてチェックボックス付き箇条書きにする
  • 短いものならそのままタイトルに入れる

タスクに落とし込む

  • 要望を機能単位のタスクに分解する。
  • Github Enterpriseでissueを作成し、そのIDまたはURLをタスクのdescriptionにペーストする。
  • タスクを作ったら、Dependencies 機能のLinkで要望へ紐付ける。
  • 作業に分解してサブタスクを作成し、「ファイル名: 行番号」で修正すべき箇所を特定する。工数計算が必要ならEstimatedTimeで所要時間をつけておく。
  • 修正すべき箇所に「//TODO: 」のアノテーションコメントをつけて、必要になる修正事項をメモしておく。
     TODO: 以外のアノテーションコメントをまとめた@Qiita 
  • 必要に応じて、タスク同士のdependencies(Blocking/Waiting)を設定する

実装

  • タスク(機能単位)を一つ選ぶ(Blockingがついているものから)
  • Github Enterpriseでbranchを作成する。ブランチ名は「update7_」のように、update+issueID|_で始める。
  • サブタスクを開いて一つずつ実装する。
  • 実装が終わったらアノテーションコメントを削除する(私は//DONEに変えている)。
  • アノテーションコメントを削除したら、サブタスクをcloseする。
  • すべてのサブタスクがcloseできたら、タスクをcloseする前にリンク先の要望を確認して、要望の達成状況を確認する。
  • タスクをcloseする
  • タスクをcloseしたら、masterへプルリクを出す。マージされたらブランチを削除。
  • すべての関連タスクをcloseしたら、要望をcloseする。

効用

こうすると、以下の効用が得られる。

  • 顧客要望を一覧できる
  • 顧客要望を開くと、リンクされたタスクを一覧できる。クリックしてタスクに移動することができる。
  • 機能単位でタスクを一覧できる。
  • 修正箇所をサブタスクとして一覧できる。工数管理もしやすい。
  • サブタスクに書いた行数アノテーションコメントとの対比でコードとの対応がわかりやすい。
  • タスク完了時に要望との関連がわかりやすい。進捗もわかる
  • タスクとissue、ブランチが1:1:1対応になるため、管理しやすい。
  • Clickupのガントチャートを使って期限管理、工程管理ができる

GithubEnterpriseでなければissueを直接Clickupと連携できて、もっと簡単になるはずだが、まあ現状はこれでいけそう。

テストはどうする?

テストについては、顧客要望からdependenciesをつけておくのがいいのではないかと思っているけれど、まだ試していない。顧客要望closeしてからテストなのか、テストが終わってから顧客要望closeなのか、その辺の思想によってBlockingかWaitingか変わりそう。