アジャイル + スクラム + カンバン

スクラムがすでにアジャイルを指しているというのはさておき、これ考える。連投してすまん。

冷静に考えたら

を一つのポイントで評価するのは悪手では？となった

WIPについては普通にチーム内の人数分をキャパにするのが一番丸い気がした。難易度観点にしたとき、例えばチーム3人いるのに、ポイント上限に達して2issueしか引き取れなかったとなったら、一人何すんねん。となるのではと思ったので

着手中タスク = 人数の状態を保っていればいい気がした。

進捗状態については、複雑さだけを観点にしたほうがいい気がした。優先度が高くて複雑さが低いものと、優先度が低くて複雑さが高いものを同等ぐらいのポイントに設定してしまうと進捗状態が嘘になる。

0~100までの進捗状態は時間をベースに評価するべきで、タスクの時間見積もりは開発者のスキルとタスクの複雑さの2観点でしかないはずなので。

ポイント（報酬）についてはそのまま進捗状況と相関させるでいい気がした。

成果をoutput / inputとして評価する場合、質は開発者のスキル次第だったりプロジェクトの最初の設計次第になる。inputに入る時間を削ることでoutput / input = KPIとしたときにKPIを改善することができるので、じゃあ進捗を進めた分だけ評価が正しいよねという。

ただそれだと優先度が高いissueをやるインセンティブがないんだよなぁ。。。

タスクの複雑さ + 優先度とした場合、前述したとおり

が価値的に釣り合ってしまう。

優先度が進捗状況と関係性が深いか？というのを考えたとき主観的には低いと思うから、そこを進捗状況の評価に使いたくない。

となるとやっぱり進捗状況はタスクの複雑さだけで評価して、報酬ポイントに関してはさらにそこに優先度をかける形で算出する。みたいにすればいいのかなーと思った。

つまりこうなる

---

まあ問題はgithub projectsの機能で個人にポイント割り当てする仕組みはないからissueに報酬フィールド用意して開発者とレビュアーにポイント割り当て。それを別途集計する必要があるという点すかね

github actionsとissueのカスタムフィールドを使えば多分できる。PRマージした人間を開発者、承認した人間をレビュアーとして、承認とマージをトリガーになんかしらのDBにポイントと開発者を突っ込んでいけば後で集計自体はできる。と思った

INTP型のブログ