サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

Redmine 旧館より 開発プロセス

Redmineのチームでの使い方を紹介

投稿日:2011年12月10日 更新日:


Redmine Advent Calendar jp 2011の10日目になります。

私は(プラグインをガリガリ作ったりしてないので)「自分達のチームでの使い方」をいくつか紹介します。

コンテキスト

・チーム:東京と大阪で別れて10人ちょっと
・作っているモノ:社内向けのFWや色々なツール群
・Redmine以外に使っている主なツール:Jenkins、SVN、youRoom

親子チケットの使い方

※これは「RxTstudy第2回でお話した内容」が元になっています。
「親チケット」を「機能(feature)」、「子チケット」を(そのfeatureを実現する)「タスク」として使っています。
親チケットは以下のテンプレートで書いています。

【背景】
※その機能の背景やなぜ作るようになったかの経緯などで要件定義の一部。
【ユーザーメリット】
【機能スペック】
【影響範囲】
【テスト時確認内容】

これくらい書いていると、設計や実装の方針に迷った時などに「そもそもこれが誰にとってどんな風に嬉しいのか?」がぶれることなく開発に集中できます。

またチームの進捗を見る場合、バーンダウンチャートと併用して親チケットの状態で見ています。
具体的には「親チケットのみを表示する」カスタムクエリを作っています。

親チケットの進捗率は、子チケットのステータスと進捗率に連動しているので、メンバーが親チケットを更新する手間なく確認できます。

レビューアの話

2つ目も第2回のRxTstudyでお話した内容ですが「レビュー」の話です。

「ステータス」にデフォルトでは“レビュー中である”ことを知らせるステータスがなく、これの表現方法を考えていました。

今のところ、チームでは以下のように運用しています。

【準備】

1:カスタムフィールド「レビューア」を(リスト形式で)設定
リスト内容はチームメンバー
2:ステータスに”レビュー待ち”を追加
3:カスタムクエリで「レビュー待ち一覧」(ステータスが”レビュー待ち”)を用意

【運用】

チケットの担当者が(コードレビューが可能になれば)ステータスを”レビュー待ち”にします。
「レビューア」にレビューして欲しいメンバーを選択します。

「担当者」を(レビューする際に)レビューアに変更して、レビューが終わったらまた元に戻す運用も考えました。
それでは自分のチケットの行き先が分からなくなり、「自分のチケット」へのコミット感が失われてしまうと考え、このような運用にしました。

「担当者」を変えないことで、担当者が自分のチケットを楽に追うことができ、レビューアに対して「滞留してるので、早くレビューしてくださいよ」を声をかけやすくなります。
※そんなことしなくてもレビューが消化できるのが良いのですが。

レビューアにとっても「自分のチケット」と混ざることはなく、分かりやすくなります。

プライベートチケットの話

3つ目は「プライベートチケット」に関した感想です。

「前略、private issue 使ってみました。あるいはITSの黒魔術とは何か」(@ハードコイルド・ワンダーランド)を読んで、(黒魔術的な面では同意の上で)「こういう時、プライベートチケットは有効かも?」と思いました。

それは親チケットなどで機能仕様などを書いている途中、何らかの理由で作業を中断する時にプライベートチケットとすることです。

途中かどうかメンバーには一見して分からないので、そのまま公開されているとそれを見たメンバーから意見やツッコミが入ったりします。それをプライベートチケットとして見せないことで、このムダな時間を防ぐことができると思いました。

RxTstudy

最後に宣伝です。「RxTstudy」というRedmineやタスク管理を考える勉強会が大阪にあります。
スタッフの1人としてお手伝いしています。
※過去2回の内容などはこちらで。

その第3回が2012年2月4日(土)にあります(ATND)。

充実した内容になるかと思いますので、この時期に関西に来る方は参加してみてはいかがでしょうか?

次のエントリは

次は@suerさんです。よろしくお願いします。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

-Redmine, 旧館より, 開発プロセス

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

チームへのRedmineの効果

Redmine Advent Calendar jp 2011の25日目になります。 #余談。本場のAdvent Calendarは「24日まで」を窓を開けていくことでクリスマスを祝うそうです。一方、 …

デブサミ2014でお話してきました!

もう2週間も前になるのですが、【Developers Summit 2014 (デブサミ2014)】に参加してお話してきました。 デブサミ2014、講演関連資料まとめとして資料などがまとめられています …

プロジェクト完了報告書の問題

プロジェクト完了報告書 昔のいたある会社に「プロジェクト完了報告書」というドキュメントがありました。 「そのプロジェクトで得られた教訓を(自分も含めた)組織の別のプロジェクトの改善につなげる」ために作 …

Share

インセプションデッキを書いてみた

社内で「アジャイルサムライ~達人開発者への道~」の読書会をやっています この読書会。色々な所(道場)があります。詳しくはGitHubにまとめられているWikiをご覧ください。 読書会で作ってみた その …

社内勉強会

社内勉強会の難しさ

これまで(セミナーや読書会などの)社内勉強会をやったり、他社さんで社内勉強会のお手伝いをした中で、難しいところや思うところがあったので書いてみます。 ※注意:この記事は旧サウスポーなエンジニアの独り言 …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。