マネージャーと開発者が安心してアプリ開発を続けるための開発ルール - Qiita

@eaglesakura です。 皆さん、進捗どうですか？ お仕事の規模が大きくなれば、参加人数が増えていくでしょう。 参加人数が増えれば、様々な宗教観の人がプロジェクトに参加するでしょう。 お一人様プロジェクトを中心にやっていた人もいれば、大規模案件のソルジャーとしてキャリアを積み上げてきた人もいます。彼らのスキルレベルもまちまちです。 私が参加している（そしてプログラマーに対して強い権限のある立場である）プロジェクトでは、次のようなルールをベースに適用しています。 これはなるべくプログラマーの負担をかけずに管理側（プロジェクトマネージャー＝PM）が開発管理を行える（進捗がブラックボックス化しない）ことを目的とした開発ルールです。 前提ルール ソースコード管理はgit/githubを利用する 1コミット（1ブランチ）に対して、複数Issueを処理しない githubはリポジトリ管理（作成

[uturi]

issueが細かすぎると、今度は管理が煩雑になりそう。issue同士の結びつきを管理しておかないと、全部解決したと思いきや見逃しがあった、みたいな事態が頻発するのでは。

[an_emerald]

Issueを分割してといってもめんどくさがってやらない人も多いんだよね。 分割することのメリットがないとだめなんだよなぁ。

[honeybe]

「2issue/day ルール」理想なんだけどここまで細かくissue分けるのツライ

[oakbow]

進捗管理はやりやすいだろうけど、このissueの細かさはストレスにならないのかな…。ここまで細かく分ける方も、分けられる方も。

[modal_soul]

2issue/dayはいい指標な気がする。この数値を上げても下げても、それぞれ練度が必要そう。状況みて変更だろうね。でも、少なくとも1日1個は消費できたかは見たいから1issue/dayより下ってことは無いかなぁ

[teracy_junk]

『issue粒度の最大値を「1日に2issue以上closeできる程度」としておきます』粒度大事

[yutaka_kinjyo]

“導入したライブラリに責任を取れるか ”

[jumperson]

管理者視点の管理の話。アプリに限った話ではない。issueのルールとかは参考になる。

[kabacsharp]

CoC？

[gonta616]

issueの粒度は人それぞれで悩んでたところの暫定解になりそう。勉強になりました

[uchiuchiyama]

“プログラマーに対して強い権限のある立場”は開発リーダーのことだと思うけど、この手法はその立場にある人に非常に高い水準の能力を求めているよなあ

[tkrkt]

「UIと機能でissueを分ける」「2issue/dayくらいの粒度で」

[sezemi]

issueを分割してモーメンタムを得る

[sinya77]

「 大規模案件のソルジャー」カッコイイ響きだなあ。issue/dayは明確なリズムが作れそうで試してみたい。

[iekusup]

ほー。

[sadoru3]

issue番号（チケット＃）をコミット単位でつけてたけど、やっぱりブランチ名に入れたほうがスッキリしそうだなと思った。