How to use github projects
This page is still under discussion.
English version will be prepared later.
PEM injection team repository: https://github.com/gw-analysis/detector-characterization
Basic idea
- 2週間(目安)ごとのマイルストーンを設定しそれを達成する、というサイクルを回してタスクをこなしていく。(アジャイル開発)
- カンバン式でプロジェクト管理をする。パイプラインは以下の6つ。
New Issue --> Icebox --> Backlog --> In progress --> Review/QA --> Done
- New Issue
- 全ての新しいissue(=タスク)はここに来る。
- ミーティングでIceboxかBacklogに振り分けられる。
- ミーティング後にはこのパイプラインは空にする。
- Icebox
- 優先度が低いissueをこのパイプラインに置く。
- 将来的に優先度が上がるだろうissueもここに置く。
- Backlog
- 優先度が高いissueをこのパイプラインに置く。
- マイルストーンの期限内にここのパイプラインを空にする。
- In progress
- 進行中のissueをこのパイプラインに置く。
- 大まかな進捗具合はチェックボックスの埋まり具合でわかるようにする。
- Review/QA
- 完了した(定義は後述)issueをここに置く。
- 担当者はミーティングで完了報告を行い。承認されればissueをcloseする。
- Done
- closeされたissueがここに来る。
- 上のアジャイル開発の方法には以下のような問題点があると思われるので、そこは注意してPEMチーム用にチーム全員からのフィードバックを受けてカスタマイズしながらやっていきましょう。(これがアジャイル開発)
メンバー全員がPEM専属じゃないのでスクラムが弱くなりそう。
- マイルストーンを落とすためのIssueつぶしに集中しすぎて長期の計画を練りにくいかもしれない。
- 対応策: "Long-term"というラベルを付けて"Icebox"の上の方に置いておいて、忘れないようにする。
Workflow
- 2週間ごと(目安)にミーティングでマイルストーンを設定する。
- Githubでissueを適宜作り、"New issue"に入れる(後述のやり方をすれば基本的には自動で入るはず)。issueの作り方は後で詳しく説明。
- ミーティング内で、"New issue"にあるissueの内容・優先度("Icebox"か"Backlog"か)を議論し、誰かにアサインする。ミーティング後には"New issue"にissueがなくなるようにする。
- このときのアサインは、その人がそのタスクをやることを必ずしも意味しない。例えば、ここでアサインされた人が、ミーティングに出ていない誰かに孫アサインしても良い。ただし、その場合は、ミーティングで話されたことを責任をもって伝える。
- 新しいマイルストーンが始まった時のミーティングでは"Icebox"も確認し、必要なら"Backlog"に移す。
- 取り掛かったら"In progress"にissueを移す。
- issue内のミニタスクが完了したらチェックボックスをチェックする。
- "In progress"にあるタスクについてのミーティングでの報告は短めでOK。「このミニタスクが終わりました」とか。なんならいらないかも。
- 相談事があったらSlackで聞く。generalチャンネルで聞いて、スレッドにし、関係者がコメントできるようにする。必要ならテレコンも開く。
- 全体ミーティングではあまり細かい話題はしないようにする。
- 変更(例えば追加のミニタスクとか)があったらコメントに書いて、本文を更新する。
- issueが完了したら(=チェックボックスが全て埋まったら)に"Review/QA"に入れる。
- ミーティングで"Review/QA"にあるタスクについて完了報告をし、OKならcloseする(自動的に"Done"に入る)。
- 完了報告は基本的にはissueの本文を見ながら、あるいはissueから辿れるような形(URLをはるとか)でできるようにしておく。
- マイルストーンの期日までに、"Backlog"からissueがなくなるようにする。
- 1.あるいは2.に戻りどんどん回していきましょう!
How to make issue
どのようなissueを作るかがプロジェクトの中で最も重要な部分です。以下にissueを作るときの注意点をまとめておきます。これは個人の意見であり絶対ではありませんが参考にして下さい。
- 1つのissueの粒度は大きくしすぎない。
- 1つのタスクは1つのマイルストーン内(2週間程度)でできるくらいの大きさにする。
- 例えば「コイルの製作」とかは良さそう。一方で「リハーサルの準備」とか「全部」というフレーズが入っているものは大きすぎます。
- issueの目的は具体的にする。
- 例えば、「xxをする方法を考える」はちょっと抽象的なので、いっそ「xxをする」とした方が良さそうです。
- 1つの判断方法としては、そのタスクをcloseできるか(=客観的に見て完了したと言えるか)考えると良いかもしれません。
- タスクをいくつかのミニタスクに分けて、それをチェックボックスで書くようにする。
- そうすればそのタスクの進み具合を客観的に判断できるようになります。ここで、1つのミニタスクの大きさはすべて等しいと仮定しました。
- そのタスクに関する情報は、そのissue内ですべてわかる、あるいは辿れるようにする。
- isseuのタイトルはそのタスクの目的を表すように付けて下さい。
- 基本的には後述のissueテンプレートを使えば良いと思います。
- 同じようなタスクがIcebox内にないか確認する。
- githubのissueは(私の知る限り)削除できません。重複しないように気をつけましょう。
- issueは自由に作る。
- ひとつ上の注意と反するように見えますが、issueは思いついたら好きに作って下さい。どんな小さいことでも良いです。全体のプロジェクトから見ればどのissueも些細なものなので、結局どれも変わらないと思います。
- それでもこれは流石にあまりにも微粒子レベルで小さいと思うようなら、projectsのcard機能を使うと良いかもしれません。
How to make new issue in github
ここでは、具体的なissueの作り方を説明します。
- githubのレポジトリを開き、さらに上の方にあるissueタブを開く。
- 緑色の"New issue"というボタンをクリック。
- issueを作るほどでもない時はprojectの方からカードを作る。
- タイトルを付ける(ひとかたまりのタスクの名前:例 コイルの作製)。
本文に、目的/目標、ToDo(ミニタスク)、参考文献等を書く。このとき、ToDoにはチェックボックスを付けるようにする。テンプレートは後述。
- 人をアサインする。issueを作った段階では必ずしもアサインされている必要はないが、"Backlog"等に移動されるタスクにはかならず人がアサインされている必要がある。
- ラベルを付ける。どのようなラベルをつけるかは後述。
- プロジェクトを選ぶ。PEMプロジェクトを選べば自動的に"New issue"に入る。
- そのタスクがマイルストーンと関連している時はマイルストーンを設定する。マイルストーンを設定したタスクは、その期日までに必ず完了する。
- previewでチェックして大丈夫そうなら、"Submit new issue"をクリックする。
- しゅーりょー!
issue本文のテンプレート
必ずしもこれに従う必要はありません。例えば、一人にアサインされた仕事なら「誰が」は書かなくても良い。
## 目的／目標 短く簡潔に書きましょう ## ToDo 常に最新版になるようにupdateしてね - [ ] いつまでに誰が何をするか - [ ] いつまでに誰が何をするか - [ ] 完了 ## 関連URL/JGW Docs/Files URL等 ## 完了報告 ミニタスクの報告はここに書く。例えば写真とか測定結果とかを書く。 ## その他 なにかあったら書いてね
Label
- High prio: プライオリティが高いとき
- on-site, off-site: オンサイト、あるいはオフサイトでしかできないタスクのとき
- Help wanted: 助けが必要(チーム内外問わず)。有識者の知恵を借りたいもの
- Discussion: ディスカッションが必要なもの。
- Stale: 手を付けなくなってだいぶ時間が経つもの
- Pending: 何らかの要因で実行していないもの
- 例えば物品の納品待ちとか。
- これを付けたら「その他」に理由を書いておく。
- Order: 物品の発注を含む作業。物品発注は先にやっておかないと、時間をロスする可能性が高い。
- Long-term: 長期的なビション。