読者です 読者をやめる 読者になる 読者になる

WhereToStart

色々手をつけすぎてすぐに忘れるので備忘録

はじめて業務外でチーム開発をして思ったこと

ほぼ反省。

チームとして

  1. 簡単なコーディング規約ぐらい決めておけばよかった
  2. 進捗報告はコードレビューしながら週1ぐらいでやればよかった
  3. 早めにバージョン管理を導入するべきだった
  4. ツールを途中で変更することも考えておくべきだった

リーダーという役割を担った自分個人として

  1. プレッシャーをもっとかければよかった
  2. 動くものを作るということをもっと伝えればよかった
  3. コードを書くべきではなかった

チームとして

簡単なコーディング規約ぐらい決めておけばよかった

最低限、定数名・変数名・関数名あたりで、
パスカルケース・キャメルケース・スネークケース・アッパーケース
のどれを何に使うのかぐらい決めておけばよかった。
今回の場合業務でJavaな人、PHPな人、C#な人が集まっていたわけで、
みんな普段の規約も違うので。。。

進捗報告はコードレビューしながら週1ぐらいでやればよかった

上の反省と絡む点もある。これやっとけば途中で気づけた。
もう一個はアプリケーションの全体に影響するような変数をそれぞれ
個別の担当箇所で作っていたこと。
gameClearFlag的なのが別のスクリプトに存在する。。。
Statusクラスとか途中で作る発想が生まれてたかもしれない。

早めにバージョン管理を導入するべきだった

最初の頃はzipで固めてLINEで共有してた\(^o^)/
さっさとバージョン管理導入するべきだった。
後半になって無理!ってなってから導入したが、
使い方もよく分からん状態であんま機能しなかった。
ちなみに今回はgitとcodebreakを使った。

その時チームメンバー向けにサクッと書いた記事
Unity4.3のプロジェクトをcodebreakで管理する - WhereToStart

ツールを途中で変更することも考えておくべきだった

連絡はほぼLINE使ってた。
ChatWork使えばよかった。
タスクふれない\(^o^)/


書いてて疲れてきました。休憩。
リッチマン、プアウーマンの石原さとみが超絶可愛い理由 - NAVER まとめ


リーダーという役割を担った自分個人として

プレッシャーをもっとかければよかった

もともと強制力のあった開発ではなかったのですが、
やるからにはもっとプレッシャーをかけて上げるべきだったと思いました。
なぁなぁでやってても何も身につかないし、
結局終わってもやり切った感がなくて楽しくないかもなーと思います。
みんながどう思ってるか知らんけど。

動くものを作るということをもっと伝えればよかった

モチベーションに関わるところですね。
どんなにちゃちくてもいいから最初に動くものを作るべきだと
もっと伝えればよかった。
最初っから機能洗いだして、担当振ってーとかやっていたけど、
それじゃ手が動かせない状態だったなーと。
みんな初めて触るUnityだったわけですし。

コードを書くべきではなかった

リーダーという役割を担っていながら自分で巻き取る作業が多かった。
いっそのこと自分は書かないと決めて役割をはたせばよかったなーと。
いや、理想は書きつつもリーダーとしての役割もやるべきだった。
どっかで「自分がリーダーなんて」って自分で上限決めてた感がありました。


まとめ

わーと30分ぐらいで書いたので文章もめちゃくちゃだし読みづらいかもしれませんが、
はじめて「チーム開発」をしたうえで思ったことを書きました。
チームメイトに聞いたらもっと色々でてきそうだなー(´・ω・`)

作ったアプリ近々GooglePlayに公開します。

広告を非表示にする