ギルド式開発の続き
要はissueの難易度見積もりなんだけど考えるとむずすぎワロタ。
そもそもウォーターフォール開発ではなくアジャイル開発がいいよねという話の根元には「やってみなくちゃわからない」が少なからずあるという話で、issueの見積もりはあくまで見積もりになっちゃうよなぁという
まあでもissueをいい感じにポイント化できたらいい感じにゲーミフィングができて面白そうなので観点洗い出しをざっくりやりたい
※ちなみに調べた感じgithub projectsを使ってstory pointでポイント付けするのがいい感じ。そうすることで残ストーリーポイントから進捗状況を可視化できたり、良いことが増えそう
タスクの複雑さ
複雑さをどう評価するかだけど、
- 開発者の中で知っている人の少ない技術
- 複雑なアルゴリズム
の2観点かなと思った。複雑なアルゴリズムは例えばDEXアビトラでいかにして最速検知 + 最速txを達成するかみたいなやつ
知っている人の少ない技術は例えばだけどAPI作ったことない集団だったら、Hello Worldを返すAPIを作るだけでもそこそこ大変だよねという話。
不確実性
- 外部APIや外部システムが関わってくる
あたり、内部仕様が不透明なほどよくわからないエラーに引っかかったりするので。
またテストコード実装も面倒になってくる。外部APIかかわってくるところのテストのためにmockを作りたいけど、ドキュメントがあてにならねぇ！みたいになると面倒だよねという
他issueへの依存度
Aissueがあったとして、そのissueを解決しないと他issueが進まない。というケースはポイント高めたほうがいいと思った。
AissueをクリアするためにはB,C,Dissueの解決が必要。というケースでAissueをあげるかについてはB,C,D側が一つ目の考えでポイント上昇しているので別にいいかなと思った。
ポイントを報酬として考えたら、優先度を上げるときもポイントを増やす形で対応できるわけで、そしたら前者パターンがいいのか。
issueに観点ごとのポイントを書いておけば、「難易度低いけど優先的に解決してほしいタスクでお得やん！」となって引き取ってもらえるかも
優先度
依存度の話と大体同じ気がする。
---
考えてて思ったけど、ポイントと進捗度が紐つく形になるとポイントの美味しいタスクが優先的に処理される -> ポイントがおいしくないタスクが後々処理されるになって、進捗がスプリント後半になるほど鈍化するのでは？
まあでも後で高速化するよりはそのほうがいいのかもしれない。ポイントがそのスプリントに対して占める重要度やウェイトを示すようにしておけば、まあ別に問題ないような気もするし。
いやー考えてたらテンション上がってきた。
ちょうどよく開発中のbot、構造気に食わなくて作り直してたので、オレオレ開発やろうかな。github projectsで。一人でやることにはなるけど、とりあえずやってみてどんな感覚になるのか試してみる
チーム単位じゃないからポイントがあんまり意味ないような気がするけど、進捗状況を確認できるのは単純にモチベーション理論的に素晴らしいものだし、ロードマップ作製 -> スプリント分割自体はやってみれるし。
土日の楽しみができたぜ
