Edited at

Redmineのプロジェクト分割とチケットの書き方

More than 1 year has passed since last update.


この文書について

ITSを使うにあたり、プロジェクトやタスクをどのように階層化しているかをまとめたもの。

チケット管理システムを使っていると、どんどんチケットが増えていって、

どのタスクがどこまで進んでいるかを一覧するのが大変になります。

そのため、以下のようにプロジェクトやチケットをツリー構造にして各タスクの見通しをよくします。

* プロジェクト

* 開発のサブプロジェクト
* 親チケット
* 子チケット
* 子チケット
* 運用のサブプロジェクト
* 親チケット
* 子チケット
* 子チケット

上記のような構造を実現するために、以下の項目について説明します。


  • サブプロジェクト分割

  • チケット分割 (親子チケット)

  • チケットの中身


利用ツール

この記事では、ITSとしてRedmineを例に

とある開発プロジェクトに対して、どのようにチケットを作っているかを說明します。

Redmineにはプラグインという機能拡張の仕組みがあり、

この記事の手法を使うには以下の機能・プラグインを使います。


  • マークダウンプラグイン

  • サブプロジェクト機能

  • 子チケット機能


サブプロジェクト分割


  • システムごとにプロジェクトを作る

  • リリース (= マイルストーン)ごとサブプロジェクトを作る

  • 保守稼働は追加改修とは別にサブプロジェクトを作る

  • タスクごとに親チケットを切り、複数人数で分担する場合は子チケットを切る

とあるO2Oアプリケーションの開発保守の場合以下のような構成になります


* {アプリケーション名} プロジェクト
* 初期リリース サブプロジェクト
* 追加開発 サブプロジェクト
* 運用・保守 サブプロジェクト

今回は追加開発のサブプロジェクトを例にどんなチケットを書いていくか、説明します。


チケット分割 (親子チケット)

大まかに以下の親チケットを切ります。


  • 設計

  • 開発・単体テスト

  • 結合テスト

  • 受入テスト

  • リリースリハーサル

  • リリース

その後、担当者ごとに子チケットを切って具体的なタスクを実施してもらいます。

例えば、ある追加開発リリースのチケット(とその子チケット)は以下のような感じになります。

* 設計

* 改修方針決定・内部レビュー・顧客合意
* DB設計・レビュー
* 開発・単体テスト
* API開発・単体テスト
* CMS開発・単体テスト
* iOSアプリ開発・単体テスト
* Androidアプリ開発・単体テスト
* 結合テスト
* 結合テスト項目作成・レビュー
* 社内試験環境でのテスト実施・修正
* (テストでバグが見つかったら、ここに子チケットが登録される)
* 受入テスト
* 顧客受入試験環境へのリリース手順書作成・レビュー・リリース
* (受入テストで修正があったら、ここに子チケットが登録される)
* リリースリハーサル
* 顧客Staging環境へのリリース手順書作成・レビュー・リリース
* リリース
* 顧客Production環境へのリリース手順書作成・レビュー・リリース

字下げになっている = 子チケットになっている


チケットの中身

チケットによって、記載する内容は異なり、大きく分けると以下の3パターンに分かれます


  • 設計・開発の実施

  • バグ修正

  • リリース手順

以降は各パターンについて説明します。


設計・開発の実施

設計・開発タスクのチケットは以下の2ないし3要素を書きます。


  • 背景

  • ゴール

  • 具体的な手順・備考

ポイントはゴール(成果物 ないし 完了条件)を明確に書くこと。

具体的な手順・備考は 入って日が浅いメンバーに対して書くことが多いです。


バグ修正

バグチケットは以下の3つを必ず書きます。


  • 所望の結果

  • 実際の結果

  • 再現手順

修正するエンジニアがどう直せばよいかを明確に示します。


リリース手順

サーバー側だと以下の順序になることが多いです。


  • リリース内容

  • 前提条件・事前準備

  • リリース手順

  • 動作確認手順

  • (もしものときの)切り戻し手順

  • 事後作業手順

ポイントは上から下に流せるように書くこと。

また、各種手順は曖昧さを極力排除します。


具体例


設計・開発の実施

とあるネイティブアプリの店舗検索画面の改修に関するアプリ側の実装チケット

# 背景

ネイティブアプリの店舗検索機能について、当初リリースではkm単位で表示していたが、
海外での展開にあたりマイル表記が必要になった。

km単位とマイル表記はパラメータAPIが返す jsonの `distance_format`プロパティを参照し、
値が1のときはkm単位、 値が2のときはマイル単位で距離を表示したい。

# ゴール

* アプリの店舗検索機能について改修し、結合テスト可能となること
* gitリポジトリのdevelopブランチ宛にMergeRequestをし、featureブランチがマージされている
* マージ後のdevelopブランチをテスト担当者がJenkinsからビルドすればアプリが入手できる

# 具体的な手順・備考

今回の機能はサブモジュールなので、2リポジトリを修正する必要があります。

手順としては以下を踏んでください。

* 親リポジトリの の developブランチからfeatureブランチを切る
* サブモジュールも改修するので、featureブランチを切る
* `cd {サブモジュール}; git checkout -b feature/{チケット番号}
* ソース改修
* 単体テスト
* サブモジュール の developブランチにMergeRequestする
* このとき単体テスト結果のキャプチャを貼ってください
* サブモジュールを変更し、親リポジトリ の developブランチにMergeRequest


バグ修正

とあるネイティブアプリの店舗検索画面の回帰テストでバグが見つかった場合

# 現象

アプリの店舗検索結果で検索結果が0件のときに何も表示されない

# 所望の結果

検索結果が0件のときは 「店舗が見つかりませんでした」 と表示されること

# 対象アプリケーション

* 環境: 社内結合試験環境
* ビルド: iOSアプリ ビルド番号xxxx

# 再現手順

DB に 店舗マスタ A を反映し、以下を実施

* 店舗検索画面に遷移する
* 都道府県選択で xx県を指定
* 取扱商品区分で ~~取扱 を指定
* 検索ボタンを押下する


リリース手順

とあるWebサーバへのAPIのリリース


# リリース内容

* 店舗検索API でリクエストパラメータ に xxフラグ を追加する

# 前提条件

* 受入試験が完了し、Staging環境でのリハーサルも終わっていること
* リリース用Jenkinsへのアカウントを持っていること
* 納品用のgitリポジトリへのアクセス権があること

# 事前準備

* developブランチからreleaseブランチを作成し、リリースタグを付与
* 前回リリースタグとの差分を確認
* リリースタグを{顧客}のgitリポジトリにpush

コマンド

git checkout -b release/release-{yyyymmdd}-1
git tag -a release-{yyyymmdd}-1
git diff {前回リリースタグ} {今回リリースタグ}
git push {顧客リポジトリ} release/release-{yyyymmdd}-1
git push {顧客リポジトリ} tag {今回リリースタグ}

# リリース手順

* {顧客}にリリース開始の旨を連絡し、合意を得てから実施
* Jenkinsからビルドする
* {JenkinsJobのURL} にアクセス
* {今回リリースタグ} を指定し、ビルド・デプロイを実行

# 動作確認手順

* 以下のURLにリクエストし、〇〇店がレスポンスに含まれ、☓☓店が含まれないこと

curl -X GET 'http://{domain}/{path}?{xxフラグ}={value}

* ログサーバでログを確認し、CRITICALレベルのログが出ていないこと

もし所望の動作でなかったり、エラーが発生している場合は切り戻し手順を実行する

# 切り戻し手順

* {顧客}に問題が発覚し、切り戻しを行う旨を連絡する
* Jenkinsからビルド・デプロイする
* {JenkinsJobのURL} にアクセス
* {前回リリースタグ} を指定し、ビルド・デプロイを実行

# 事後作業手順

* 顧客にリリース完了を連絡する
* リリースブランチをmasterブランチにマージし、{顧客}のgitリポジトリにpush


テンプレート

Redmineにはチケットの作成時にテンプレートを使うことができます。

マークダウン形式にまとめたものをgithubに公開しました。

https://github.com/nave-m/ticket-template