大人数での開発でのプロジェクトマネージメントについて #GitHub

大人数で開発をするにあたってPMとしていくつかの学びと工夫があったのでROMっておきます。
管理人数が多すぎるとここの基礎知識力と運用力を育てる事とアウトプットの品質管理がものすごく大変です。
タスク粒度の統一化と事前調査の品質を高める事、個人のアウトプットの品質をレビュワーが確認しやすくするという事でQAからの手戻りを減らしコミュニケーションの負担を軽くするというのが目的です。
ポイントはチケット運用とGithubの運用に集約します。

ツール

・JIRA/Backlogなど
・Github

運用

チケットの運用はテンプレ化が基本

プロジェクトマネージャは親チケットを切り、サブラタスク分割をして小チケットを切ります。
エンジニアは要件と作業の内容を詰めるためにエンジニア自身でチケット内容を埋めていく事がベスト・プラクティスです。
無駄な仕様書を書かない開発においてはチケットの記載内容が全てになるのでシーケンス図やAPIのINPUT/OUTPUTも事前に細かく定義しておきます。
今回はRailsを利用した例をあげます。
あとでgitのプルリクにTODOと

# 要件
  このチケットで何を実現したいのかを明確にします。
  例: 顧客管理CMSの〇〇の機能を追加

# 対応内容
  実際に発生するタスクを箇条書きにします。
　例: 1. モデルの作成
　例: 2. コントローラーの作成
　例: 3. 設定項目をyml化

# 仕様
  例: 
  - ER図 (画像やファイルへのリンク)
  - シーケンス図 (画像やファイルへのリンク)

# テスト要件
  テストコードを記載するための定義をします。

# 影響のでるスコープ
  コードを洗いざらい調査して今回の修正にたいする影響範囲を記載します。
  例: 顧客管理CMSの〇〇画面: http://sss/hohoge
  例: 顧客管理CMSの〇〇画面: http://sss/hohoge

Githubの運用については2種類あります。

RM(リポジトリマスターという)役職を設定してすべてのブランチの管理とコードレビューやマージ、デプロイまでを管理します。
ずっとこのRMをオフショアでやっていたのですが前提としてRAILSの知識が豊富でないエンジニアやGITに慣れていない人を入れるとコンフリクトが発生しまくってレビューを突き返して終わるのでRAILSのアーキテクチャ理解がある、またはなくても調べられるという前提で進めるのが望ましいです。
レビューについてはRMの負担が大きくなるのでピアレビューなどで事前にある程度潰しておく事が前提です。

A.プロダクトごとの運用

　　master > develop > productname_base
                            └　TicketNO
　                            └TicketNO
　                            └TicketNO

1) masterからdevelopブランチの作成
2) developブランチからproductname_baseブランチの作成
3) productname_baseからチケットごとの機能ブランチの作成
4) プロダクト開発中はbaseブランチを常にPULLしてきてチケットブランチに反映します
5) Ticketを消化したところでbaseブランチにマージ
6) baseブランチをデプロイしてQA機能ごとにQAをしていきます

B.マイルストーンごとの運用

マイルストーンに機能を詰め込み過ぎない事がポイントで
主にバグ修正や簡易な修正などの保守開発に利用したほうがいいパターンです。

　　master > develop > v1.2_base
                     └　TicketNO
                     └　TicketNO
                     └　TicketNO

1) masterからdevelopブランチの作成
2) developブランチからv1.2_baseブランチの作成
3) v1.2_baseからチケットごとの機能ブランチの作成
4) プロダクト開発中はbaseブランチを常にPULLしてきてチケットブランチに反映します
5) Ticketを消化したところでbaseブランチにマージ
6) baseブランチをデプロイしてQA機能ごとにQAをしていきます

C.プルリクエスト

チケットに記載の内容についてプルリクに記載してレビュワーとQAの人が何をしたかわかるようにしましょう。

ユニットテスト方法(rspecの実行コマンドと結果などもきちんと書く)
エビデンスも残すというようにしていくと手元での品質を最大限に上げて行くことができます。

実際、上記のチケットを元に下記のプルリクを作成してもらいます。
InputとOutputの整合性が取れているのでレビューがしやすくなります。

## Original Ticket
https://app.asana.com/0/1135737104421279/1135753753843125

## 要件
- [ ] 1. モデルの作成
- [ ] 2. コントローラーの作成
- [ ] 3. 設定項目をyml化

## 対応内容
- [ ] 1. AaaModel,BbbModelを作成しアソシエーションの設定をしました
- [ ] 2. XXXコントローラーの作成、CCCヘルパーの追加と、Concernの追加
- [ ] 3. 表示項目AAをyml化

## テスト方法
- [ ] 1. 作成したModelのテスト結果
- [ ] 2. 画面のフィーチャーテストの結果

## テストエビデンス
スクリーンショット/APIレスポンスなど

## コメント
上記の対応方法で問題ないかご確認お願いします。

## 影響範囲
http://hoooogeg/page/index
http://hoooogeg/page/confirm