どうぶつしょうぎプロジェクトの振り返り
チームで一緒に実施したどうぶつしょうぎ開発を振り返る. 実際のソフトウェア開発においても,定期的なバージョン管理システム等の開発プロセスの振り返りはよく行われる. ここではGithub Flowにもとづいた開発が行えたかを下記項目にもとづいて確認する.
担当Task数の確認
各Stepには複数のTaskが含まれる.例えばStep1には6つのTaskが存在する.そのうちいくつのタスクを誰が行ったかを下記に数値として記述し,以下の2項目に問題がないか確認せよ.主開発者や共同開発者の記述の次の行に学生番号を記述しておくこと.
- Step0以外のStepについて,2人以上の開発者がTaskを担当しているか
- 担当Task数に過度のばらつきが無いか.目安として平均担当Task数(全Task数を人数で割ったもの)の±50%の範囲に全員の担当Task数が収まっているか.
開発者 学生番号 |
主開発者 |
共同開発者1 |
共同開発者2 |
共同開発者3 |
共同開発者4 |
---|---|---|---|---|---|
Step0 | |||||
Step1 | |||||
Step2 | |||||
Step3 | |||||
Step4 | |||||
Step5 | |||||
Step6 | |||||
Step7 | |||||
Step8 | |||||
Step9 | |||||
合計 |
担当レビュー数の確認
担当Task数と同様にレビューを実施したTask数も過度にばらつきが無いことが望ましい.担当Task数の確認と同様に,実施したレビュー数をTask単位で数え,下記に記述せよ.また,下記項目について問題がないか確認せよ.Step0についてはレビュアーがいないため,省略している.
- 担当レビュー数に過度のばらつきが無いか.目安として平均担当レビュー数(全Task数を人数で割ったもの)の±50%の範囲に全員の担当レビュー数が収まっているか.
開発者 学生番号 |
主開発者 |
共同開発者1 |
共同開発者2 |
共同開発者3 |
共同開発者4 |
---|---|---|---|---|---|
Step1 | |||||
Step2 | |||||
Step3 | |||||
Step4 | |||||
Step5 | |||||
Step6 | |||||
Step7 | |||||
Step8 | |||||
Step9 | |||||
合計 |
どうぶつしょうぎリポジトリの確認
どうぶつしょうぎリポジトリURL(以下に続けて書く) |
---|
https://github.com/ |
まず,主開発者が作成したどうぶつしょうぎリポジトリURLを上記に記述する.その後Githubのリポジトリページ上で確認できる内容にもとづき,各項目の振り返りを行う.
ブランチ名の確認
冒頭で記述したGitリポジトリURL末尾に"/branches/all"をつけることで,今回作成したブランチの一覧を下記のように確認できる.
master
以外のブランチは開発者自身が分かりやすい名前のブランチ名をつける必要がある.
どうぶつしょうぎリポジトリにおいて自分が作成したブランチ名とそのブランチで実施した内容を記述する.
ブランチ名(master 以外のブランチ名を書く)とそのブランチで実施した内容を書く |
---|
他の開発者から見て,内容と対応が取れており,分かりやすい名前になっているかをブランチ名ごとに考察せよ.考察においては,どのような命名法・ルールを自分の中で(あるいはチームで)決めてブランチ名をつけたのかを明記したうえで,各ブランチ名の説明を行うこと.
コミットグラフ
冒頭で記述したGitリポジトリURL末尾に"/network"をつけることで,下記のようなコミットグラフを表示できる.
コミットグラフとは開発者によってブランチの作成やCommit,Mergeなどがどのように行われたかをグラフ形式で表示したものである.
まず,master
ブランチを含むすべてのブランチがどのように分岐し,Mergeされたかをグラフとして記述せよ.Github上のコミットグラフをそのまま貼り付けて良い.
Github Flowのルールによれば,すべてのブランチはmaster
ブランチから作成され,master
ブランチにMergeされなければならない.
そのため,上記グラフの矢印を見て,下記を確認すること.
- すべてのブランチがMergeされているか
- すべてのブランチが
master
ブランチから作成されているか - 初期コミット以外で
master
ブランチに直接コミットされていないか(Pull RequestによるMergeならOK)
OKでない項目があった場合,なぜそれが発生したのかを説明すること.
Pull Requestの確認
冒頭で記述したGitリポジトリURL末尾に"/pulls"をつけることで,Pull Requestの一覧を見ることができる.すべてのPull Requestが適切にMergeされていれば,このURLでは何も表示されないため,画面左上の「Closed」というリンクをクリックし,Mergeされた(Closeされた)Pull Requestを下記のように表示する.
Pull Requestの一覧から自分が作成・登録したPull Requestと自分がレビューを行ったPull Requestの一覧をすべて 書き出し,Pull Requestの作成及びレビューが適切に行われているかを評価する.
PR URL | |
---|---|
タイトル | |
PR登録者 | |
レビュアー |
上記の表をPull Requestの数だけ作成し,内容を確認する.確認項目は下記のとおり.なお,PR URLは#1,#2等の番号のみでも構わない.
- すべてのPRがMergeされているか
- PR登録者とレビュアーが別の開発者になっているか