久々にチーム開発したのでメモ
昨年秋頃から年明けにかけてRailsで顧客のサービスをひとつ作った
久々のチーム開発で。チーム人数は3名。
せっかくなので使ったツールややり方などを備忘録的に残しておく。次いつまたチーム開発する機会があるのか知らんけど。
実践したこと
プルリクベースの開発
Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー
上記のやり方が面白そうだったので試してみた。
Githubを使っていれば拍子抜けするほど簡単に流れに乗ることができた。
Git力が足りないので最初は少し大変だったが、馴れてくると細かくブランチを切ってフィーチャーごとに対応するということが開発のテンポを良くしてくれた。
コードレビューはイージーミスによるバグや既存のコードと大きく流れの違うコードが混ざるのを未然に食い止める事ができたりと、一定の成果はあった。
一方でいろいろと言われているように、適切なレビューができたか自信がない、ツッコミ方の問題など、コードレビューの難しさも感じた。
TDD
連携する外部システムが多かったが、その分繋ぎ込みの仕方など最初から仕様が固まっている部分が多く、加えて今後数年は使われると言う寿命が長いシステムだったため積極的にTDDを行った。
必ずしもテストファーストではなく、プロダクトコードを書いた後にテストコードを書くこともよくあった。その際にはテストを実装と同じ時間をかけて書くこともあり、つまり倍時間がかかったりすることがあるのがもどかしかったが、後々のことを考えて粛々とテストを書いた。
プロジェクト後半にはスケジュールのプレッシャーがかかってきたが、実装から時間をおくほどテストを書くコストが上がるので、手間を最小にするためテストの手は抜かなかった。
テストによりつまらないバグが早い段階で補足され、しかも再発しない、というのは着実に前進している感があり、安定感と安心感があった。
顧客の参加した受け入れテストの段階で発覚したバグも迅速かつ確実に修正することができた。
結果として堅牢なコードができあがり、スムーズなローンチ。
スムーズすぎて顧客も俺もびっくり。
TDDをしていなかったら手動テストでボロボロと色々取りこぼしがあったに違いない。こっちを直すとあっちが壊れる的な右往左往も不可避だっただろう。
Vagrant
チーム内の開発環境はVagrantで作りVagrantfileなどはRailsのコードと同じリポジトリの中に含めた。
プロビジョニングにはChefを使った。
チーム内で統一された開発環境があることで環境依存の挙動の違いなどがなく便利だった。
準備したりメンテするのがちょっとめんどくさかったが。
Jenkins
GithubへのpushをトリガーにCIが回るように設定して運用。Jenkinsさんはよく働いてくれた。
テストを壊すコミットの早期発見は非常に助かる。発見が遅れることで修正コストが高まってしまうので。
Pivotal Tracker
プロジェクトの進捗を可視化してくれるツールとしてPivotal Trackerを使ってみた。
リモートでもホワイトボードのように一目で現在のタスクや進捗が分かる物が欲しかったので。
チームに浸透するまでに多少時間がかかったが、開発の見通しをよくするのに役出った。
にわかアジャイル
二週間を1イテレーションとして、節目には集まって振り返りと次のイテレーションのタスク決め、みたいな進め方をした。
あんまり既存のアジャイル手法などに実は詳しくないのでにわかアジャイル。
まずまずうまく回ったと思うが、当初はいまひとつしっくり来ない部分も多く、KPTでの振り返りにより徐々に是正されていった。次の機会があればすでに是正された地点からスタートしたい。
最終的なKeepは次のようになっていた
- ブランチ＆プルリクベースの開発
- 気軽にブランチを切る
- 顧客や関連部署への質問はタイムラグを最小にするためにすぐに直で
- Wikiに情報をまとめる
- 画面の片隅に常にPivotal表示する
- Pivotal
- Jenkins
- 一日の作業開始の時に昨日やったこと・今日やること・困ってることを報告
- 一日の終わりにgithubに作業中のブランチをpush
コミュニケーション
各自リモートでコミュニケーションはSkypeが主。
2週間に1度はイテレーションの区切りということで顔を合わせてミーティングした。
顔を合わせて初めて出てくる話もあり、できればもう少しミーティングの頻度は多くした方がよかっただろう。
最近リモートワークに関するエントリが多く上がっていたが、その中でよく言われるような「定期的に顔を合わせる重要性」は確かにある。
ところで、ここ数年はSkype以外にいろいろとチャットツールが出てきてトレンドになっているようなので機会を見て試してみたいと思っている。
ドキュメント
GithubのWikiで。
Markdown使えていいよね。
Railsの採用
期限までが短かかったので使い慣れたものをと。
今後バージョンアップに追随していくコストも折り込みで採用。
反省点
初期段階の設計不足
走りながら考える、的なノリで簡単な設計をしただけで開発に入ってしまった。
プロジェクト初期に別件でタスクがぽこぽこ入ってきて必要な作業時間が確保できなかった、というのもあり。ハイ、言い訳です。
簡単な設計ながらも一応ツボは抑えてあったので大きな手戻りなどはなかったが、ただひとつぽっかりと抜けていたものがあってまずった。
もう少ししっかりやって、システム構成やユーザーフローなどを図にして可視化しておけば抜けの発見やチーム内での認識共有に役立ったはず。
あとストーリーの検討や見積もりなどをもう少し丁寧にやっておけばよかったかなあと。
スケジュール遅れへの無策
序盤〜中盤でのスケジュールの遅れが積み重なって終盤に響いた。若干の修羅場に。
きちんと走り続けているのに遅れたならスケジュールの引き方が悪いが、今回の場合はのんびりしすぎて遅れた体だったので、積み重なる前に取り返しておくべきだった。
見方によっては悪いタイムボックス型開発の例と言えましょう。
時間内にできたことをこのタイムボックスで可能だったことと安易に追認するのは間違ってる。
ミーティングがgdgd
遅刻や脱線をもう少し何とかしたかった。
ビジネスで光画部時間はちょっと。
世間話は楽しいけどミーティングの後でひとつ。
ミーティングの必要性は認めるが、ダラダラしたミーティングはほんと勘弁なんじゃよ。
サッと集まってシュッと進めてビッとTODO決めて終わるかんじで頼む。
孤独なChef使い
初心者Chefアンチパターンのひとつ。
自分以外のメンバーにもChefでインフラを触って欲しかったが、終盤になるとレクチャーしてる時間とかなかった。
メンバー全員ある程度インフラ側も触れる人間だったので、序盤からChefの使い方を広めていくべきだった。
質疑応答 2014-04-16追記
最先端からは二周か三周くらい遅れてると思った内容に反響がけっこうあってびっくり。
せっかくなのではてブ等から拾った質問に返信してみる。
規模感など
数えたらコントローラーが23個、モデルが46個。
テストはRSpecで596 examplesということらしいです。
中規模ってところかな？
期間は4ヶ月。予算とかお金の話は職務上知り得た秘密ということで。
仕様の共有
GithubのWikiで。
外部システムの仕様書（PDFとかExcel）とかはGoogle Drive。個人的にはあんまGoogle Drive好きじゃないけど。
ツールの選択
メンバーそれぞれの興味と経験から。
- 使ったことないけど便利そうだから使ってみよう
- 使ったことあって便利なので今回もこれを使おう
ざっくり言えば上記のどっちか。
メンバーの誰かが使いたいと持ってきて、他の人から異論が出なければ採用。そのあたりは少人数チームなので適当。
リモートワークとコミュニケーション
リモートワークについては37signalsのREMOTEなどが詳しい。
あと以下のサイトとか。
- 37signalsのREMOTEを読み終えて、1996年のリモートワークを振り返る – アインシュタインの電話番号
- リモートワークには東京がよいのではないかと思った – ワザノバ | wazanova
個人的に思っていることは若干長くなりそうなので気が向いたらあとで書きたい。大したことは書かないと思うけど。
リアルタイムのコミュニケーションはSkypeで何も問題ないけど、席を外しているときにログが流れるとキャッチアップが大変なのが不満。
やはりTDD
YES!
リファクタリングも随時できていい気持ちです。
でも「TDDが向いてないケース」とかでもググってみてください。
ちなみにTDDしてても見逃してるバグがどこかに潜んでいるだろうなとは常に思っている。ただそいつが出てきても速やかに着実に退治できて再発もさせないのがTDDの強み。
TDDやる場合はコードレビュー時にテストコードのレビューも忘れずに
Githubでテストコードもブランチ差分として表示されるのでその点は抜かりなく。
ただ差分以外の部分が表示されないので、差分だけ見てると表示されていない部分との整合性がおかしかったりすることもあるので注意したい。
やっぱり光画部時間ではビジネスは無理か
うーん、意外と光画部時間でビジネスしてらっしゃる方もいたりしますね。
イラッとして胃液がたくさん出るので焼き鳥か何か奢ってください。
逆にgdgdミーティングを増やしたい
gdgdはお茶のみに行ったり、ご飯食べに行ったり、お酒のみに行ったりでお願いしたいところ。
細かい共有は短時間の朝会などで済ませるのがいいと思う。
まあ実際問題上京に片道二時間かかる田舎に住んでますので、ミーティングが増えると死んでしまいます。
都内近郊に住むのがやはり最強なのか。
こういう働き方してみたい
諦めたら試合終了なのでがんばってください。
やれば意外とうまくいくというか、失敗もいい経験になるというか。
あと自分は少人数で割と好き勝手やれる環境にいるので楽だけど、大きな組織に属していたりすると打ち破らなければならない壁があって戦うのが大変そうだ。
