概要
これまでGitの基本やGitHub Flow、Issueについて調べてきた
実際に開発現場においてプロジェクト管理がなされているのかを把握するために調べたことをまとめる
また、今まで調べたことの中で別のツールを使用して(JIRAやZenHub等)プロジェクト管理をしているケースもあったが
複雑生が上がったり(少なくとも自分にとっては)
ツール独特の使用感などがあったりする
と思い、ここではGitHubのみでプロジェクト管理することを目的として内容をまとめている
なので、How Towよりかは機能の説明寄りになる
前提知識
- プロジェクト開発の基本的な内容を理解している
本当に初歩の初歩で構いません。
要件定義→設計→実装→テスト→レビュー→リリース みたいな大雑把な流れ
ウォーターフォールとアジャイルの違いが判っている
スクラム開発について何となく理解している
大筋の参考記事：新入社員におくるGitHubでのプロジェクト管理の初歩
Projects機能
参考：開発者のスケジュール管理に超便利、GitHub Issues、Label、Milestone、Projects使いこなし術
Projects機能とは
- カンバン(※１)式のタスク管理を可能にする機能
- 今どのようなタスクが進行しているのか
- そのタスクの今の状態
等を把握することができる
Projectsの要素
①プロジェクト
1つのリポジトリに対して複数のプロジェクトを作成することができる
②カラム
プロジェクトには複数のカラムを追加できる
③カード(1つのタスクの単位)
カラムの中には複数のカードを追加できる
カラムはカードをグルーピングするために使用する
それぞれのカラムの役割について
カラムの設定はそれぞれのプロジェクトによってさまざまだと思うので、記事の一例を紹介する
To Do
やるべきタスクが配置されるようにする
Automationを設定することで、以下をトリガに自動的にTo Doカラムに移動させることができる
IssueとPRが新しく作られた
Issueが再オープンした
私の中ではスプリントがスタートしたときにすべてがここにあるイメージだった
ここから、IssueにAssigneeを設定して初めてAssigneeが対象のタスクをDevelopingに移動させると思っていた
Developing
開発中のタスクを配置する
Reviewing
レビュー中のタスクを配置する
プルリクでレビュー中の時はここに配置する
通れば後述のDoneに移動し、通らなければ再度Developingに移動する
Done
終了したタスクが配置される
Automationを設定することで以下をトリガに自動的に移動させることができる
・IssueとPRがCloseする
・masterにマージされる
MileStone機能
Issue(タスク)をどの期日までに行うか管理するもの
スクラムでいうスプリントの期間に該当する
MileStoneにIssueを登録していくことで以下が達成できる
・同一MileStoneの中で解決するIssueを選定できる
・進捗率を把握できる
実運用上ではスプリントプランニングのようなことをMileStone作成してIssueを登録する作業では行うことになる
MileStone内に実現されるIssueを決めるために
・Issueの優先順位
・開発工数
・ベロシティ
からIssueを選定する必要がある
(やったことないので優先順位とか適当に選んで最初はやり始める感じでいいと思う)
Issue機能
元はGitHubの機能である
プロジェクトのタスクや課題管理に使用する
Issueの立て方等については以前まとめた記事を参照する
MileStoneに登録するタスクという単位でIssueが存在するので、粒度はある程度揃えたほうが良いかもしれない
★開発者によって異なる粒度の話でいえば
- 親Issueのみを設定するのが熟練度の高い開発者で
- 子Issueで詳細なタスクを設定するのが熟練度の低い開発者ということになるかと思う
粒度が不ぞろいだと
熟練度の高い開発者には振られているタスクが一見少なく見える
プロジェクト管理においての進捗率で評価しにくい
これに関しては熟練度の高い開発者はコミュニケーションで補うのか
カンバンを使用するうえではすべてが透明性を高く保つ必要があると思う
よって、ある程度であれば子Issueを自分で作成し、それをタスクとする
そうすることで
進捗率を細かく持たせ
MileStoneを使用した自分のタスク消化率(＝進捗率)を把握しやすくできると思う
これは開発者だけで共有される内容ではなく、ステークホルダーで共有される内容になると思うので
自分だけが進捗率を把握している状況は好ましくないという判断のもと私が思った内容になる
Pull Request機能
自分が実装したコードを他者にレビューしてもらえる機能
実際のプロジェクトでは自分のタスクをレビューしてもらうレビュアーがいるはず
Developingに移動させたタスクを開発し、Pushした後にPRを作成してレビューしてもらう
PR画面でProjectに載せるかどうかについては以下方針
- Issueだけあればいいときは登録しない
★commitの粒度について
Developingにあるタスクについてトピックブランチを切ると
開発した内容をcommitする必要があるが、そのcommitの粒度をどうするかという問題がある
このスライドを見て勉強する(自分はまだ確認してません)
★PRの書き方
Issue上で詳しく実装の要件等が詰められているのであればIssueの番号を記載するだけでよい
そうでなければ実装上の要件等を記載する？(詳しくは上記のスライドry)
Close,Reopen機能
Issueが解決したらCloseすることができる機能
プロジェクトのReviewingにあるタスクで以下の状態のものをCloseする
レビューが通っている
masterにマージされている
Automationで設定しているとPRのdescriptionなどにCloseするキーワードを含めることで
マージされると自動的にIssueもCloseすることができるらしい
参考：プルリクエストをIssueにリンクする
同じIssueで別の課題ができたときは以下で対応する
新しくIssueを作成する
対象のIssueをReopenする
対象のIssueがCloseしている場合はReopenボタンがあるのでそれを押すとIssueが再度作成される
上記操作をトリガにDoneだったタスクがTo Doに移動する(Automationを設定していること)
大まかな流れ
プロジェクトを作成する
カラムを設定する
ここに関しては開発チームの運用に合わせる
- マイルストーンを設定する
スクラム開発を採用している開発チームはスプリントの期間に合わせる
- Issueを選定する
上記でも開設した通りIssueの粒度をなるべく合わせるか、Issue作成の過程で凡その工数見積もりが可能であればそうする
- 開発
上記の繰り返しになると思います
詳細なスクラム開発の内容については私も実際にしたことがないのでわかりません
実際は工数見積もりにもいろいろ算出方法とかやり方があるみたいです
なんかいろいろあるけどとりあえずそれらは置いといて、GitHubでプロジェクト管理するために必要な
最低限の要素を調べて運用するためにまとめた
まとめ
大まかなGitHubでプロジェクト管理をするための要素と流れについて理解できた
実際に開発するときにこの流れでやってみることにする
commitの粒度という唯一解のないような問題や、PRの書き方などのお作法的なところもどんどんまとめていく予定
※１：Atlassianの記事によると以下
アジャイルでDevOpsなソフトウェア開発の実装によく使用されるフレームワーク
キャパティについてのリアルタイムのコミュニケーションや作業の完全な透明性が必要となる
作業項目は視覚的にカンバンボードに表示され、チームメンバーはいつでもすべての作業の内容を確認できる
読んでない記事
チーム開発と、ステークホルダーも巻き込んだ体制の話になるため、実際にその立場になってから読むためのリンクとしておいとく
GitHubをフル活用してカンバン(Kanban)方式による開発体制を構築したノウハウを惜しみなく公開する