最近聞いた話。

勤務先のアプリは社内向け dogfood (beta) や、より狭い範囲の fishfood (alpha) を weekly でリリースしているチームが多い。これは continuous delivery の仲間と見ることもできるし、XP とかにあるイテレーションのデモの亜種と見ることもできる。

そんな weekly release を採用したチームのプログラマが、目先のリリースごとに新機能を入れないといけないせいで突貫工事をする羽目になって辛いと文句を言っていた。PM などから「次の weekly release にこれ入れてね」とか言われるらしい。興味深い現象。これはプログラマと PM のどちらが悪いのか。

プログラマからみると、 weekly のような time-boxed release の利点は締め切り優先で無理にコードを突っ込まなくていいことのはずなのに進捗を示したいがために無理を強いられるのは理不尽に感じる。リリースが頻繁だから少し送れてもダメージが少ない。それが CD の狙いではなかったか。

PM からすると、毎週少しずつ進んでいくインクリメンタルな開発を可能にするのが weekly release の利点であり、少し進んだらその成果を示すべきではないかと言いたい。かもしれない。

外野から見ると、潜在的な問題は 3 つ思いつく。ひとつ目は weekly な dogfood/fishfood の新機能という粒度は weekly の成果には大きすぎる場合もあるだろうなということ。テストプログラムのデモくらいの粒度で checkpoint させてほしい機能もあるよね。ふたつ目は、PM とプログラマの話し合いが不十分なせいでインクリメンタルにできない順番での実装を強いられている（PMが悪い）、あるいは単にそのプログラマがインクリメンタルに進めるのが苦手（プログラマが悪い）。

でも上の dichotomy は自分の想像で、このケースは PM もプログラマも agile とか興味ないのだろうなあ。Weekly release ってのはまあ agile の文脈から生まれてきた習慣なわけだけれど、インフラなどの進化で敷居が下がり普及した結果とくに agile 信者でないチームもなんとなく weekly release を採用できてしまい、背景を理解してないせいで苦労する。Travis CI のバッジがいつも赤い open source プロジェクトみたいな...

この一周回った感じ、当事者には悪いけどちょっと面白いね。教科書的な答えとしては weekly release を導入するなら開発プロセス全体もちゃんと見直しましょうね、というかんじか。えらそう。みんながんばれ。