|
Size: 3535
Comment:
|
Size: 8370
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 6: | Line 6: |
| == Basic Usage == | == Basic idea == |
| Line 8: | Line 8: |
| 1. 新しくissueを作る。 | * 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がここに来る。 == Workflow == 1. 2週間ごとにミーティングでマイルストーンを設定する。 1. Githubでissueを適宜作り、"New issue"に入れる(後述のやり方をすれば基本的には自動で入るはず)。issueの作り方は後で詳しく説明。 1. ミーティング内で、"New issue"にあるissueの内容・優先度("Icebox"か"Backlog"か)を議論し、誰かにアサインする。ミーティング後には"New issue"にissueがなくなるようにする。 * このときのアサインは、その人がそのタスクをやることを必ずしも意味しない。例えば、ここでアサインされた人が、ミーティングに出ていない誰かに孫アサインしても良い。ただし、その場合は、ミーティングで話されたことを責任をもって伝える。 1. 新しいマイルストーンが始まった時のミーティングでは"Icebox"も確認し、必要なら"Backlog"に移す。 1. 取り掛かったら"In progress"にissueを移す。 * issue内のミニタスクが完了したらチェックボックスをチェックする。 * "In progress"にあるタスクについてのミーティングでの報告は短めでOK。「このミニタスクが終わりました」とか。なんならいらないかも。 * 相談事があったらSlackで聞く。generalチャンネルで聞いて、スレッドにし、関係者がコメントできるようにする。必要ならテレコンも開く。 * 全体ミーティングではあまり細かい話題はしないようにする。 1. 変更(例えば追加のミニタスクとか)があったらコメントに書いて、本文を更新する。 1. issueが完了したら(=チェックボックスが全て埋まったら)に"Review/QA"に入れる。 1. ミーティングで"Review/QA"にあるタスクについて話し、OKならcloseする(自動的に"Done"に入る)。 1. 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の作り方を説明します。 1. githubのレポジトリを開き、さらに上の方にあるissueタブを開く。 1. 緑色の"New issue"というボタンをクリック。 |
| Line 10: | Line 75: |
| * 毎週のミーティングでPlannnedに追加したタスクについて報告し、内容等について議論する。 1. タイトルを付ける(ひとかたまりのタスクの名前:例 コイルの作製)。このときタスクの範囲を大きくしすぎない。たとえば「リハーサルの準備」は大きすぎる(「全部」とかっていうと大きすぎ)。そういうのはマイルストーンにする。 1. 本文に、目的/目標、ToDo(ミニタスク)とスケジュール、参考文献等を書く。このとき、ToDoにはチェックボックスを付けるようにする。テンプレートは後述。 * チェックボックスをつければ、プロジェクト画面でそのタスクがどれくらい進んでいるのかパッと見て分かる。 * ミーティング中などでさっと書きたい時は、アサインする人/ToDo/このタスク全体のスケジュールくらいを書いておいて、後で体裁を整える。 1. 人を必ずアサインする。 1. ラベルを付ける。プライオリティ、ハード/ソフト、オンサイト/オフサイトくらい。後述 1. プロジェクトを選ぶ。PEMプロジェクトを選べば自動的にPlannedに入る。 1. マイルストーンがあれば設定する。 1. 取り掛かったら Working onに移す。 * プライオリティが高い場合は、コメントではじめたことを宣言する???あるいはSlackで報告???ミーティングでの報告で十分か。 * Working onにあるタスクについてのミーティングでの報告は短めでOK。「このミニタスクが終わりました」とか。 * もし相談したいことがあったら、ミーティングでもSlackでもよいので聞く。 1. 完了したミニタスクはチェックを入れる。 1. 変更(例えば追加のミニタスクとか)があったらコメントに書いて、本文を更新する???? 1. 一通り完了したら(=チェックボックスが全て埋まったら)In reviewに入れる。 1. ミーティング等でIn reviewにあるタスクについて話し、OKならcloseする(自動的にDoneに入る)。何かまだ必要ならWorking onに戻す。 |
1. タイトルを付ける(ひとかたまりのタスクの名前:例 コイルの作製)。 1. 本文に、目的/目標、ToDo(ミニタスク)、参考文献等を書く。このとき、ToDoにはチェックボックスを付けるようにする。テンプレートは後述。 1. 人をアサインする。issueを作った段階では必ずしもアサインされている必要はないが、"Backlog"等に移動されるタスクにはかならず人がアサインされている必要がある。 1. ラベルを付ける。どのようなラベルをつけるかは後述。 1. プロジェクトを選ぶ。PEMプロジェクトを選べば自動的に"New issue"に入る。 1. そのタスクがマイルストーンと関連している時はマイルストーンを設定する。マイルストーンを設定したタスクは、それまでに必ず完了する。 |
| Line 28: | Line 82: |
| === 本文のテンプレート === | === issue本文のテンプレート === 必ずしもこれに従う必要はありません。例えば、一人にアサインされた仕事なら「誰が」は書かなくても良い。 |
| Line 33: | Line 89: |
| ## ToDoとスケジュール - [ ] xx/xx いつまでに誰が何をするか - [ ] xx/xx いつまでに誰が何をするか - [ ] xx/xx 完了 |
## ToDo - [ ] いつまでに誰が何をするか - [ ] いつまでに誰が何をするか - [ ] 完了 |
| Line 40: | Line 96: |
| ## 完了報告 ミニタスクの報告はここに書く。例えば写真とか測定結果とかを書く。 |
|
| Line 46: | Line 104: |
| === 必須 === * priority: high, normal, low * hard, soft * on-site, off-site === オプション === * Bug * Disccusion: チームで議論する必要があるもの * Documentation: ドキュメント作成に関するもの * Help wanted: 助けが必要。有識者の知恵を借りたいもの |
* High prio: プライオリティが高いとき * on-site, off-site: オンサイト、あるいはオフサイトでしかできないタスクのとき * Help wanted: 助けが必要(チーム内外問わず)。有識者の知恵を借りたいもの |
| Line 60: | Line 109: |
| * これを付けたら「その他」に理由を書いておく * All members: 皆でやるもの |
* 例えば物品の納品待ちとか。 * これを付けたら「その他」に理由を書いておく。 * Collabo: 他のチームとの共同作業 |
How to use github projects
This page is still under discussion.
English version will be prepared later.
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がここに来る。
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"に入る)。
- 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"に入る。
- そのタスクがマイルストーンと関連している時はマイルストーンを設定する。マイルストーンを設定したタスクは、それまでに必ず完了する。
issue本文のテンプレート
必ずしもこれに従う必要はありません。例えば、一人にアサインされた仕事なら「誰が」は書かなくても良い。
## 目的／目標 短く簡潔に書きましょう ## ToDo - [ ] いつまでに誰が何をするか - [ ] いつまでに誰が何をするか - [ ] 完了 常に最新版になるようにupdateしてね ## 関連URL/JGW Docs/Files URL等 ## 完了報告 ミニタスクの報告はここに書く。例えば写真とか測定結果とかを書く。 ## その他 なにかあったら書いてね
Label
- High prio: プライオリティが高いとき
- on-site, off-site: オンサイト、あるいはオフサイトでしかできないタスクのとき
- Help wanted: 助けが必要(チーム内外問わず)。有識者の知恵を借りたいもの
- Stale: 手を付けなくなってだいぶ時間が経つもの
- Pending: 何らかの要因で実行していないもの
- 例えば物品の納品待ちとか。
- これを付けたら「その他」に理由を書いておく。
- Collabo: 他のチームとの共同作業