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

一人KPT

ぼちぼち今のプロジェクトで初めて作った機能がリリースできそうなので、一人KPTしておく

作ったもの

ソーシャルゲームのギルド機能
ただし、

  • 横展開もの
  • でも横展開元では使っていなかった

チーム(上の機能を作ったメンバー)

Keep

  1. 久しぶりに開発に集中できた
  2. GitHubEnterpriseでエンジニア二人でコードレビューしてお互いに確認しながら開発を進められた
    • 時々勘違いされるけど、このプロジェクトで初めてGitHub使い始めたGit素人ですよ
  3. きちんと発行されているSQLのチェックとかできた
    • 今回パフォーマンスは周りから口酸っぱく言われていたのでひと通り見れたのはよかった
  4. 初めてのメンバーで開発した
    • HipChat上でコミュニケーション取りながら、謝るときには某焼き土下座の画像出したり、「デプロイだん」を「デプロイたん」と空目されたときには、すぐ萌CIの画像を探してきたりとか。

ProblemとTry

  1. 横展開ものと使いまわせるかなーと思ってたら使ってないため不具合があったり、効率悪そうなコードがあったので結局がっつり書き換えたのでスケジュールがギリギリになった(横展開あるある)
    • 作り始めてから再度スケジュール引き直せばよかった
  2. エンジニアとデベロッパーそれぞれでスケジュール引いてマージしなかったので、お互いの進捗を確認するのが面倒だった
    • スケジュールマージすればよかった
  3. 二人で同じ機能を開発してたからコンフリクトが何回か起きてその度にマージ作業をするはめになった
    • コンフリクト起きないようにもう少し小機能ごとにサービスクラスを分けるとかすればよかった。もしくは既存クラス修正するのではなくて一度破棄して追記するとか
  4. 第三者レビューをしてもらう時間が少なかった
    • WIPとかやってみたほうが良かったのかもしれない
  5. 経緯はわすれたけどなぜかURLがいけてないちらほら(個人的には/名詞/動詞という形にしたかった)
    • URL決めるのをバラバラで決めるのではなくて、命名規則を早めに出したほうがよかった
  6. フロントが使ってるAjaxライブラリのデフォルトHTTPメソッドがPOSTだったので、データ取得するからGETメソッドだと思い込んで作ってたら、フロントからデータ取れませんと言われてハマった
    • ちゃんとフロント側のJSコード読まなきゃ
  7. 結合テストのあたりでテストチームにバグ出してもらった時に、最初は誰がハンドリングするんだ?とふわっとなってしまった(後半はプランナーが仕切ってくれたのはよかった)
    • 人毎に各フェーズで何をやるかをある程度明確にしたほうがいい
  8. エンジニア2人ともチームに入って間もなかったので、他職種を交えた進め方が本当にこれでよかったのか謎
    • 人が違うとやり方(決めること)が異なるのは色々ストレスだと思うから、WBSのテンプレとか作れる気がする