Redmine Gitlab 連携メリットの検索結果はこちら
関連情報：
チケット管理ならJIRAやRedmineより良さそうです。開発者のタスク管理をGitHubで行ったらうまくいった話 Octocat 2015年07月07日 荒川靖久（39）
はじめに
こんにちは、6月からAndroidの開発を担当している荒川です。
この記事は以下の方を対象にしています。
- リモートリポジトリにGitHubを使っている
- タスクや課題の管理を小〜中規模のプロジェクトで行っている
- 複数の開発タスクが並行して進むプロジェクトにアサインされている
- 開発者のみのタスク管理を主体的に行いたい
- タスク管理ツールを使っているがイマイチうまくいっていない
この記事では、私が実践して良かった経験則を紹介します。誰でも真似すれば必ずうまく行くという保証はありません。この記事の読者の方が、担当しているプロジェクトに合わせてアレンジを加えるとより効果が増すかと思います。
開発者のタスク管理
モバイルアプリサービス部では、コミュニケーションツールにBacklogやTrello、Pivotal Trackerを用いている事を突撃！隣の開発環境 パート3【クラスメソッド編】の記事にて、以前紹介しました。 リモートリポジトリにはGitHubを使う機会が最も多くなりました。また、その運用は大半のプロジェクトがgit-flow形式で行う事が多いです。
多くのコミュニケーションツールの採用と弊害
コミュニケーションツールはどれも便利なサービスが多いですが、1つのプロジェクトでいくつものサービスを取り入れると、タスクをどこに書いたのか、探す時間が出来てしまいます。一般的な開発フローではその規模に応じて、課題（チケット）の管理にRedmineやJIRA、Backlogやスプレッドシート（Excel）などのサービスを選定していることでしょう。マネージャーやお客様が現在のプロジェクトの状態を一覧したい時には、これらのサービスは非常に適しているかと思います。しかし、開発者の細々とした作業タスクをこちらのサービスに課題として含めてしまうと、途端に見づらくなってしまいます。その原因としては、以下のことが考えられます。
- 担当者が課題のステータスを最新の状態に更新していない
- 課題が登録時の想定よりも多くの工程を含んでいて、1日以上ステータスが処理中から更新されない
- 複数のサービスに同じ課題が登録されていて、片方の更新を忘れる
- そもそも課題が登録されていることに担当者が気づいていない
- 1つの課題に多数のステークホルダーがいて、担当範囲が明確ではない
- 課題の担当者が次々と変更される
上記の確認を日々の朝会や夕会で行っていても、いつか抜け漏れは起こるかと思います。
では、細々とした開発者のタスクをどのように管理したら抜け漏れが減るのでしょうか。人が管理している限り、100%抜け漏れを起こさないことはできませんが、私が意識して行っていることがあります。それは、 開発者のタスクを出来る限りGitHubに集約すること です。集約する情報は、 リポジトリを参照する権限のある者がその情報を見て、何をするべきか、何をもって完了か、何故そのタスクが存在するのか、をわかるようにする事 が重要です。まずはIssueの登録から始めます。
Issueの登録
GitHubでの課題管理はIssueを使って行うことができます。Issueには作られた順番にそれぞれ番号が振られていて、GitHub内では「#課題番号」と記述することで、対象番号のIssueへリンクが自動的に付与されます。また、Pull Requestにも1つの課題番号が振られます。複数のPull Requestを1つのIssueにリンクすることで、確認が容易に行えます。
Issueの書式例
Issueを登録する時には What と Why を付けるルールを設けているプロジェクトもあります。以下の記事が参考になります。
GitHubではMarkdown書式が使えるので、上記参考のように整ったIssueを簡単に作成することができます。Markdown記法はMarkdown Cheatsheetを参考にするとどなたでも使えるかと思います。リポジトリのREADMEやChangeLogにも使えので、非常に便利です。
私がIssueを登録する時はプロジェクトのルールにもよりますが、以下のような書式を用います。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
| ## 概要ここにIssueの概要を書くWhat・Whyもここに書くと良いと思う## 変更点- [ ] - [ ] - [ ]- [ ]## 追加タスク- [ ]- [ ]- [ ]### 関連課題---関連する課題があればここにリンク形式で載せる（Backlog）### 親課題---親の課題があればここにリンク形式で載せる（Backlog）#### 備考---別途記載する必要があれば書く |
※見出し文字はプロジェクトに合わせて変えて下さい。 e.g.)「変更点」→「TODO」
タスクリストで未完了 / 完了の変更を行う
GitHubのタスクリスト記法を使う事で、マウス操作のみで未完了 / 完了の更新が行えます。
開発途中で追加されたタスクは、別の見出しで区切っておくことで、何故課題の実装が遅れたのかなども伝わりやすくなります。タスクリストには、それぞれエビデンスとなるリンクを付けておくと、後から見た担当者が助かることがあります。
Issueは細々と登録するよりも、担当別で1マイルストーン（最長でも担当者数人で数人月以内）でこなせる課題群を、1つのIssueとする方が経験上見やすかったです。差し込みで発生したタスクも、関連のあるものであれば途中から追加して構いません。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
| ## 概要このIssueは、ABCアプリiOS版（Ver 1.2.3）実装タスクの一覧です。クライアントからの新機能追加の要望によって、ABCユーザーが他の複数ABCユーザーと交流するための機能を実装します。既に #120, #123 で 1 : 1 （アプリユーザー：フレンド）のユーザー交流が出来る機能が実装されています。今回の対応で、新たに 1 : n のユーザー交流が実現できるようにする予定です。## 変更点- [x] [ABC-543](http://backlog/view/abc-543) 複数ユーザー交流機能の実装 - [x] フレンド選択UIの改修 - [x] UISpecとレイアウトを合わせる #130 #131 - [x] ダミー画像を正規の画像に差し替える #132 - [x] フレンド選択 / 非選択の状態管理を追加 #133 - [x] 選択済みのフレンドが退会済みだった時のエラーを追加 - [x] 表示するエラー文言を先方に確認 [ABC-543](http://backlog/view/abc-543) - [x] エラーアラートの共通クラスに退会エラーを実装 #134- [x] [ABC-544](http://backlog/view/abc-544) 各スタート画面でのフレンド選択UIを新UIに変更 #135## 追加タスク- [x] [ABC-545](http://backlog/view/abc-545) お気に入りフレンドのソート順変更- [ ] [ABC-547](http://backlog/view/abc-547) ~~iOS 9対応~~- [x] [ABC-548](http://backlog/view/abc-548) A端末でのバグを修正### 親課題---[ABC-539 iOSアプリ Version 2.1 アップデート 要望一覧](http://backlog/view/abc-539)### 関連課題---[ABC-540 iOSアプリ Version 2.1 アップデート 改修要望案](http://backlog/view/abc-540)[ABC-541 iOSアプリ Version 2.1 アップデート 改修要望スケジュール](http://backlog/view/abc-541)[ABC-542 iOSアプリ Version 2.1 アップデート 納品物一覧](http://backlog/view/abc-542)#### 備考---[ABC-547](http://backlog/view/abc-547) iOS 9対応 については、修正コストが当初の予想以上にかかるため、次期バージョンで対応することになりました。[ABC-560 iOS 9対応時の不具合について](http://backlog/view/abc-560) |
GitHubのPreviewでは以下のように表示されます。
実装内容を確認したい時は、Pull Requestへのリンクである「#課題番号」をクリックすれば確認できます。どういった経緯でその実装が必要になったかを確認したい時は、ABC-XXX形式で記載されたコミュニケーションツールへのリンクを確認することで、仕様やお客様とのやりとりのログが確認できます。何か理由があって実装を行わなかったタスクについても、タスクリストから削除せずに残しておいた方が良いです。
実際に私が担当した案件では、担当者2人・マイルストーンまでの期限は開始から1週間で以下のように作成しました。
このように書くことで、後から見た人がこのプロジェクトではどのように実装を行っていたのかが、理解しやすくなると思います。このIssueではRC3が進行中で、不具合の発生報告ベースでプロジェクトが進んでいる事が確認できます。既に大きなバグは取り除いていて、端末ごとの細かいバグを修正し続けることがRC3の課題でした。全ての課題には、BacklogへのリンクとPull Requestへのリンクが付いています。
アプリ開発ではリリースやアップデートがマイルストーンであることが多いです。このIssueをコピペして体裁を整えれば、GitHubのRelease機能を簡単に利用することができます。
次にIssueに紐付いたPull Requestを作成します。
Pull Requestの作成
GitHubではPull Requestも1つのIssueとして扱われます。Pull Request作成時には「#課題番号」の連番が自動的に付与されます。
コミュニケーションツールには、コミットコメントに課題（チケット）番号を付けることで、自動的にコミットログを表示してくれる機能があります。なので、コミットコメントの先頭に「ABC-543」などの課題番号を付与する文化は、広く浸透しているかと思われます。
GitHubのPull Requestにも似たような機能があります。Pull Requestを作成した時のコメントに、 #Issue番号 と書くことで、対象Issueのコメント欄上部に、タイムライン形式でコミットが表示されるようになります。上記「Issueの登録」で紹介したIssue番号をPull Requestのコメントに追加することで、 Pull Request（小さなIssue）を束ねたIssue が作成できます。これをうまく利用することで、細かいタスクが各所に散らばる問題を防ぐことが出来ます。Pull Requestの作成頻度は、最低でも1日に1つ以上作成できれば良いと思います。無理であれば、Work In Progress の Pull Request を作成しましょう。
Pull Request のコメント書式例
基本的にIssueと同じですが、参考にしたサイトのURLなどを記載しておくとレビュアーも楽に確認が行えると思います。Pull Request画面右側にあるLabels・Milestone・Assigneeはプロジェクトのルールに則って付けるようにしています。
実際に私が担当した案件では、以下のように作成しました。
レビュー忘れの対策
Pull Requestはレビュアーを指定しないと、レビュー忘れや誰もレビューをしない問題が発生することがあります。私は以下の方法でレビューを催促しています。
- Pull Request 作成画面右側の Assignee にレビューしてもらいたい人を指定する。（GitHubから通知が飛ぶ）
- 同じオフィスで作業していたら、少し時間を置いて直接お願いする。
- チャットツールでメンションを付けてお願いする。
- 朝会などで直接お願いする。
レビュー後、マージが終わった後にリンク先のIssueに戻ってタスクリストにチェックしています。これらをマイルストーン内で繰り返し行います。
実践してみた感想
技術は一人で身につけられますが、良いコミュニケーション方法はチームで行わない限り培われません。上記方法を実践して、今までにはなかったPull RequestやIssueを見ながらの対面（リモートも含む）でのコミュニケーションが生まれました。
私はこの方法を試すまでは、開発者の多くのタスクは受動的に割り振られて、期限だけが迫っているテトリスのようなものだと考えていました。
最後に、「もっとこうした方がいいよ！」や、「同じ事を実践したけど、うちはこうだった。」などのアドバイスやコメントを下さると筆者が喜びます。
0 件のコメント:
コメントを投稿