ハチャメチャに始めたプロジェクトの管理とかを見なおしてみる。
進行しているプロジェクトがあります。
バージョン管理とフレームワーク、どちらも勉強したてホヤホヤではじめました。
あと、プロジェクト管理は基本的にgoogleのスプレッドシート、そして設計書とか仕様書とかってものはほとんど存在しません。あるとしたら、ワイヤーフレームに類似するものぐらい。
この状態のプロジェクト管理の問題点（もはや問題だらけかもしれない）と、これからどうしようかを考えてみる。
>問題点
・コミットがマジ適当
コメント、ブランチ、粒度すべてがいつもバラバラ。
・バージョン管理はしてあるので、誰が何処を変更したかは分かるが、その変更から更に変更を加えるときに、コードを書いた意図がわからないことがある。
作業を引き継ぐときとかに大分困ります。何も知らずに追加でコードを書いて、バグったりします…(´・ω・｀)
・スプレッドシートに書いてある要件は、非エンジニア視点のことが多いので、担当分けや具体的な仕事単位が大きいことがある。
書いてあることから、実際に対応していくときに、これの担当はどうしようかとか、個々の変更をするためには他のところも変えないといけないとかそういう情報が盛り込まれない＆一個あたりの単位が大きくなって変更が遅れることがある…
・バージョン管理はしているが、master,devとブランチを切っているのはいいものの、みんなdevブランチに自らマージし、なぜかdevブランチの内容を本番環境のテスト環境でデプロイするっていうmaster空気な感じなことが起きてる( ﾟдﾟ)
やっている本人も意味がわからないと思うこれ…ｗ多分原因は焦ってたから←うわー
非常にひどい問題点ですが、これを解消する方法を考えてみる。
（ちなみに、上記のひどい問題点からわかるように、この手の経験はあまりないのでまたオレオレになる感じはあるかもしれない…）
>やってみること
・仕様をある程度まとめる
終わりが決まらなくてやりづらい（主にバージョン付などで）ので、この機能とこの機能を入れて○○版とかいう感じでざっくりとしたゴールの推定をしておく。
・BacklogでTiDDみたいなことをする。
スプレッドシートにまとまった要件は、Backlogの課題に粒度を小さくして載せておく。その時に重み付けや担当を決め、gitのブランチと関連付けをする。
・git
コミットは細かく。
コミットメッセージは、ある程度のルールを作る。（最初にサマリを書く、その後に詳細を３行ぐらいで書く）
git-flowを入れる。
リリースと開発をわけ、masterにリリースをおき、バージョンをタグ付する。
backlogの課題ベースでブランチを作成する。
マージする担当を作る。
>参考にしたもの
