最近のお仕事まわりでツラツラと書く

今の仕事についてつらつらと書く。今漠然と思ってることを書き出しただけなので、そんなに意味のある内容でもないかも。

アジャイル

そもそも何をもってアジャイルと言うのか、中々難しいところではある。昨日から読んでる「間違いだらけのソフトウェア・アーキテクチャ」では僕はアジャイル(開発)というのは、できればアジャイル宣言を守るか、守る努力をしているものだけに、その名前を冠してほしいと思っているけど・・・。とある。そういう意味だと改めてうちのチームでもアジャイル宣言を確認するべきかもしれない。

何はともあれ、今うちのチームではCTOのちゃんとアジャイルな開発をしていきたいという想いからいくつかのプラクティスを実践している。イテレーション、プランニングポーカー、バーンダウンチャートなど。まだまだチームとして未熟な為、見積りの精度ややり方が少しうまくいっていない気はするけどこの辺りは徐々に改善されそう。

特にポイントを付けたことで、今週に終わらせないといけないポイント量や、バーンダウンチャートで間に合うのか間に合わないのかがわかるのがいい。現時点で正直色々と間に合っていないのだけど、納期と言うか1回目のリリースのタイミングは既に決まっていてそれはずらすことが出来ない。その代わり1回目のリリースに向けてストーリーを削れないかという交渉をしたりした。以前は(実は以前お世話になったところで個人として契約して仕事している)そもそもこう言う交渉すらなかったのでいい兆候だと思う。

ただ、削ってもまだ間に合わないのでここは残業や土日でカバーをするしかないのが残念なところ。土日や残業で消化したポイントをベロシティに含むと正しいベロシティが出ないのかなと少し思ったけど、残業や土日作業は一時的なもの(リリースが今月)なので、そのうち誤差としておさまっていくのかな。

最近コードを書くことに集中していたので改めてこの辺も勉強しなおすべきかなとちょっと思っている。とりあえず、「アジャイルな見積りと計画づくり」を読み直そうと思う。

ネガティブな感情

実は最近自分自身にあまり良くない兆候がある。漠然とだけど、汚いコードや落ちてるテストを見ると「なんでちゃんとやれないんだ」という少しネガティブな感情があることにここ数日気づいた。念の為言っておくと、「テスト落ちてますよー」と言えばすぐ直してコミットしてくれるし、汚いコードと言うのもエンジニア同士でよくネタにする「ひどいコード」みたいなものではなく、「もう少し上手く書けるよなー、これ」と言ったもの。

つまり、コードの質に拘るあまり若干過敏になり過ぎてる部分がある気がしてる。もちろんコードは出来る限りきれいに書くべきだとは思う。ただ、そこに拘り過ぎて本来の目的を忘れちゃいけないと思う。今の目標は最初のリリースに間に合わせることで、細かいリファクタリングや修正はその後でも出来る。

テスト駆動開発

テストコードの量を見る限り少し不十分な部分もありそうだけど、少なくとも全くテストが無いって部分は無くなってきてる感じ。バグがあった場合も「再現するテストコード書いて修正してください」で済むのでいい感じ。TDDに関してはそれなりに習得していると思うので、チーム内で不十分だなと思ったところは上手くサポートしていきたい。例えば僕が率先してテストコードを書けばそのコードから他のメンバーも書き方を知ることができるみたいに。

steak

今回、受け入れテストをsteakで書いてる。今のところ僕が書いてるだけだけど。実はまだチーム内でcukeにするかsteakにするかハッキリ決まってない。と言うのももしかしたらcukeのシナリオをエンジニアじゃない人が書く可能性があるから。ただ、結局テストデータを用意する必要があったりとかで中々難しいのかなとも思う部分もある。この辺@moroさんとちょっと話してみたいな。

git-svn小話

git-svnについてはこの間も記事にしたけど、少しだけ補足。

topic branchをmergeする前にgit rebase master

gitはmergeした時にmerge commitを作るときがある。コミットメッセージがデフォで「Merge branch ‘hoge」みたいになっている奴。これをそのままgit svn dcommitするとその「Merge branch ‘hoge’」のコミットだけsvn側に反映される。これだと他の人が具体的にどんなコミットかよくわからない。なので、branchをmergeする前にmasterでgit svn rebaseしてbranch側でgit rebase masterをすると良い。これで履歴が一直線になるのでmerge commitが作られずsvn側にもちゃんとbranch側の各コミットが反映される。

topic branchは作業が終わるまでmasterの変更を取り込まない

この辺の話は「入門Git」に詳しく書いてあったので細かくは話さない。何となしに、作業中のbranchに最新のmasterをrebaseしたら落ちてるテストがコミットされててちょっと面倒だったので改めて思い直した次第。

Rails3.0とRuby1.9.2

今のところ目立って困ってる所はなし。主要なライブラリもRails3.0に対応してきたし、結構実務でも使えるのではなかろうか。ただ、日本語の情報があまりなくRailsGuides(僕は大体edgeを見てる)や、http://railsapi.com/や海外のブログを見ながら手探りな感じの部分もあったのでその辺は少し大変かも。個人的には今後Rails2系を使う理由はないかなといった所。個人的にはArelがお気に入り。Arelについては@a_matsudaさんのRuby Freaks Lounge 第43回 Rails 3を支える名脇役たち その1 - Arel -Active Record Query Interfaceを読むといいです。

本当につらつらと書いただけになったけど、ここまで読んでくれた人ありがとうございました。