Issue（タスク）

Issueの見積もりはチームで行う

チームでプランニングポーカーを行い、SP（ストーリーポイント）をつける。

SPには、1, 2, 3, 5, 8, 13 のように、「フィボナッチ数列」を使用する。
これは、数字が大きくなるにつれて、見積もりの精度が低くなることを表している。

SP: 8 以上がついたIssueは精度が低いことが多いため、原則Issueを分割する。

Issueの分割とプルリクエストからのIssue起票

Iterationで設定したIssueだが、実際に着手すると、分割した方が良いことがわかることがある。 適宜分割する。

また、プルリクエストでコメントをもらったものの、そのPRではなく別のタスクとして行う場合は、Issueを起票する。

切り出したIssueは、説明が省略される傾向にあり属人化したり意図がわかりにくくなったりしやすいため、以下の対応を行う必要がある。

1. 切り出し元となるIssueやコメントがあれば引用してリンクを貼ること
2. 引用だけでなく、そのIssueを見れば内容がわかるように簡潔にまとめた説明を書いておくこと

また、切り出したIssueは、デフォルトでGitHub Projectの No Iteration に入るため、見逃しやすい。

1. 今Iterationでやれるものは、今Iterationに追加する
2. すぐに着手できないものは、次Iterationに入れて、次回のプランニングで目に入るようにする

リファクタリングIssueをいつやるか

原則、リファクタリングIssueはすぐに着手するか、起票すべきである。

しかし、起票から着手までの期間が空くほど、着手の際に内容を思い出すための時間がかかってしまう。

重く、見積もりや計画が必要なタスクでなければ、後回しにせず、今Iterationか次Iterationで着手すること。

そのためにも、機能開発の見積もりは、リファクタリング等のバッファを含めて考えておかなければならない。

どのくらいのSPを消化できるのか（Velocity）を計測する

見積もりをしてSPを設定しても、計測しなければ活かせない。

Iterationごとに、稼働時間とSPを集計して、プロジェクトごとに履歴を残していく。

すると、1時間でどのくらいのSPを消化できるのかや、1SPを消化するのにどのくらいの時間がかかるのか（Velocity）がわかるようになる。

ある程度Iterationをこなし計測数値がたまったら、Iterationで消化できるSPの目安として活用する。

大きいIssueは子Issueに分割して管理する

8SP以上の大きなIssueは、GitHubの Tasklist を用いていくつかの子Issueに分割する。

親Issueには epic ラベルをつけて、親Issueであることが分かるようにする。

親Issueは、全ての子Issueを完了させたタイミングで担当者がCloseする。