「開発スピードをあげろ!」と言われる事は多々ある。
実際にチームの開発スピードが遅かったとしたら、それは開発チームがなにかしらの問題を抱えている事になる。それに対して、偉い人達は「とりあえず開発者を増やせばスピードがあがるはず!」と人を追加する。しかし、根本的な問題は解決していないので、大きくスピードは上がらない、もしくは逆に遅くなってしまう事がある。
開発にかかる時間をざっくり分解すると「仕様決め」「コードを書く」「検証」の3つに分ける事が出来る。つまり「仕様決め」「検証」を効率良く進めて「コードを書く」時間を増やす。また「コードを書く」事自体を効率良く進める事が、開発スピードを上げる事だと考えられる。なので、3つのフェーズの問題点とそれらの解決方法を考える必要がある。
例えば、「仕様決め」の問題点は
- 仕様が決まらず、MTGの時間が長い
- 仕様を決める人がいない
- 誰かに確認する事が多い
- 開発者自身が新しい仕様に必要な現状の仕様の理解をしていない
解決方法は、「機能に関して誰が責任持って決めるのか決める」「機能に関する責任者がいない場合はMTGしない」「必要なこと・不要なことをまず最初にまとめる」など。
「コードを書く」の問題点は
- 各開発者が、一人で考えこんで必要以上に悩んでいる
- リファクタリングから始めて、機能開発の着手が遅れる
- プルリクの目的から逸れたことも同じプルリクでやってしまい、マージが遅れる
解決方法は、「プルリクを分ける」「機能開発してからリファクタリングを行う」など。
「検証」の問題点は
- 開発者が行う検証に時間がかかっている
- 開発者がテスト項目書を作っていて時間がかかっている
解決方法は、「QAチームに委譲する」「自動テストの充実化」など。
これらはただの例で、フェーズの中でなにが問題になっているのか・それらの解決方法は、チームや個人によって違う。
まとめ
「開発にかかる時間」を分解し、それらのどこで問題が起きているのか、1つ1つ理解して対応していくことが、「開発スピードをあげる」事につながっていくと思う。
- 作者: ドナルド・C・ゴース,G.M.ワインバーグ,木村泉
- 出版社/メーカー: 共立出版
- 発売日: 1987/10/25
- メディア: 単行本
- 購入: 53人 クリック: 509回
- この商品を含むブログ (190件) を見る