GitHub Issueまとめ

##概要
GitHub Issueについて調べたことをまとめる
実際の開発において、GitHubを利用した開発では

1. Issueを作成し

2. それをもとにトピックブランチを切って

3. 開発し

4. プルリクして

5. 承認され

6. マージする

みたいな基本的な流れがある
この時に重要なのがIssueであり、開発の起源となるイベントである
これを雑に管理していると

• なぜその機能が開発されたのか

• その機能で達成したい目標は何なのか

• どんな成果物をもってIssueを閉じるのか

を最初に規定されていないがために

• 実装上の(本来は必要のない)相談

• 実装の範囲

• 成果物

の相談やコミュニケーションコストが増大することになる
本来はこれらはIssue作成の過程でディスカッションされるべき内容であると思う
今回は

• それらのロスを少しでもなくせるよう調べたこと

• Issue作成のポイントなどについて調べたのでまとめる

(まだチーム開発に使用したことはないが、これらの知識はチーム開発にGitHubを適用するうえでの必要な知識であると思うので)

###以降まとめの参考記事：チーム開発を変える「GitHub」とは？〜Issuesの使い方〜【連載第3回】
##Issueとは

• GitHubに備わっている機能の一つ

• プロジェクトやリポジトリの課題を管理することを目的として作られた

##Issueの機能
###基本機能

• タイトルと内容を最初に設定して保存することで作成することができる

• (リポジトリにアクセス権限のある人であれば)Issueについてコメントをすることができる

• 結果、Issueの中で仕様を詰めたりディスカッションを行うことができる

• プルリクへのリンクやほかのIssueへのリンクを貼ることができる

###Assignee機能

• 対象のIssueに対応する担当者を割り当てることができる機能

• 一つのIssueに対して一人しか担当者を振ることはできないため、Issueの粒度が重要になってくる

###MileStone機能

• 対象のIssueに対して期限を設定することができる機能

• MileStoneを設定し、Issueを紐づけることでMileStoneのタスクを何％消化しているかという進捗を確認できる

###Label機能

• Issueにラベルを貼ることができる機能

• Issueを分類できると一覧画面でのIssueの分類の視認性が向上する

##Issueの書き方
Issueもチーム開発でそれぞれスタイルがあるかもしれないが
(おそらく一般的には)それほど内容としては変わらないと思うので
(代表として)この記事を参考にしてIssueの書き方と必要性について理解する
###①タイトルについて

• タイトルだけで概要を把握できるようにする

例）○○機能の実装、○○の△△化
例２）ユーザーストーリー風に記述する→ユーザーは○○がしたい。それは△△だからだ。
###②内容について
以下３点で記載する
####WHY(なぜこのIssueを立てたのか)
これがないと解決したい問題や課題が不明瞭ということになる
####WHAT(このIssueで何を決めたいのか)
具体的にどうすることでIssueを解決しようとしているのかを記載する
####OUTPUT(IssueのClose条件(作成する成果物))
IssueをCloseするための成果物を定義する

##Issue作成のポイント
####以降参考記事：【イベントレポ】GitHub-flowにおけるissue作りのコツとは…達人による登壇を聞いてポイントをまとめてみました。
###①Issueの粒度について
マネージャー視点ではある気がするが(プレーヤーも気を付ける必要があると思う)

• Issueの粒度とコミュニケーションコストは比例関係にある

• Issueを立てるときにはこれを考慮する必要がある

参考図

#####Issue粒度の具体例
粒度「大」

• UIと要求仕様のみを記載する

• 単体機能で記載する

担当者に実装の設計も委ねるので裁量が大きい
マネージャーからするとコントロールしにくいタスクとなる
※外部設計のような、UI部分であったり実処理などは担当者にゆだねてしまうと
そもそもの実現したいIssueの揺れが発生する可能性があるため、そこまではIssueの段階で解消するということ
あくまで内部実装に関してのみ粒度を大きくして担当者の裁量に任せるということか
粒度「小」

• テーブルのカラム名、ロジックまで指定する

• ある機能を実現するための処理の部分的な実装(MVCでいうモデルのみ、コントローラーとビューのみ)

担当者はコーダーに近い役割になる
マネージャーからするとコントロールしやすいタスクとなる
###②親Issueと子Issueについて

• 親Issueで大きな機能単位で設定する

• 子Issueは親Issueを細分化した内容にする

• 親Issueは子Issueがすべて完了することで完了となる

####親Issueの例

• Issueの中で子Issueのリンクとチェックボックスを設定する等

• すべてチェックが付けば子Issueがすべて完了したということにする

####親Issue→子Issue分解の過程

１． 実現すべき内容を機能単位でIssueにする

例）ログイン機能を実装する

２． より小さなIssueを渡したい人向けに分割できないか検討し、子Issueとして細分化

例）【フロントエンド】Presentational Componentを作成する　～(どうつくるかなどをこの後に細かく記載する場合もあり)
例２）【サーバーサイド】ログイン用APIの実装　～(どうつくるかなどをry)

##まとめ

• 調べた結果、Issueについて何となくどう使われているかを理解することができた

• ただ、実際はプロジェクト単位で運用が変わるところではあり、唯一解があるわけではないということが分かったのもよかった

• 特にIssueの粒度などは調べる前にぼんやりとどうするんだろうと感じていたことではあった

• それに対する考え方の指標ができたのでよかった