Edited at

仮説・検証(96) open な issue がどんどん溜まる現象を解決するために

現在、5人の事業(project)で6ヶ月目でissueが100になった。


月次でclose

月次の会合では、openなissueを確認し、できるだけcloseするようにしている。

現在open 78 closed 22。

open が多いのは、できれば全員が確認したものをclosedする方針のため。

それぞれ仕事を掛け持ちで、多い人は毎週5つ、少なくとも3つは平行して作業している。

月に1回の仕事など、断続的なものを入れると、多い人で10。

ほぼgitlabを使っている。

年に1−2日の仕事など、時々のものを入れると、多い人で20。


open 比率

open が78%は多い方。

過去に、issueをどんどんあげていって、closeできないものだらけになって破綻したことがある。

やるとよいことを書きすぎて、やれる資源の見積もりができていない。

資源がなければ、最初からあきらめるか、次の事業への申し送り事項として記載するに止めるか。

大いに反省。


週次

週次の会合では、その週にあがったissueを順に議論し、その場でclosedするものはしている。

メンバが5人揃っていて、全員が周知すればいい事項はそこでclosedにする。

不在のメンバがいれば、不在の人が意見を書いて、書いたらclosedするようにしてもらっている。


日次

その日、その日で、思いついたら、おもいついた内容をひとまずissueにあげるようにしている。

資料のURLがわからない場合は、あとからの追記でもよいことにしている。

完全な資料になってからあげるのは、あげるのが遅くなる。

完全であるよりも機敏(agile)にあげるように要請している。

日次で終業30分前にcloseする時間を儲けることを検討中。


参考資料(reference)

プログラマが英語で報告・質問する時のいくつかの事例・方法

https://qiita.com/kaizen_nagoya/items/9cf2ba858e52e9795b67

プログラマの「日報、週報、月報、年報」考

https://qiita.com/kaizen_nagoya/items/97ad8ac9217c12c3bb69

bitbucket/github/gitlab連携環境構築(中)悪戦苦闘

https://qiita.com/kaizen_nagoya/items/87352fe88ceed2c1732d

IT系勉強会をすべて当たりにする方法

https://qiita.com/kaizen_nagoya/items/9f001a79ab4162220406


文書履歴(document history)

ver. 0.01 初稿 20190207

ver. 0.02 参考資料追記 20190208

ver. 0.03 プログラマが英語で報告・質問する時のいくつかの事例・方法 追記 20190212

ver. 0.04 日次で終業30分前にcloseする時間を儲けることを検討中。追記 20190218