インクリメンタルなデプロイ – XP本読書会9回目のふりかえりのふりかえり

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

インクリメンタルなデプロイ

ここでは失敗事例が結構なまなましく語られていて、とても強い気持ちが感じられるセクションです。規模の大きなシステムで長期間にわたって開発が続く場合、期日にまとめてリリースしようとしてたいていの場合失敗する。しかも、数ヶ月とか1年が過ぎると、そもそもの要望が大幅に変わって来たり。スケジュールが大幅に遅れて、かなり無理をして新たなシステムに移行したものの、個々の機能にあれこれ問題が発覚して、そのような状況で大幅な変更とか、まぁ対応できるわけがありません。ですが、なんだかよく聞くようなストーリーです。

直前の「本物の顧客参加」にもつながりますが、部分的にでも使える状態にして、実際に使ってもらって、そのフィードバックをもとに次の機能を進めていく。その積み重ね。問題があれば、速やかに対応。日数が経過してからだと、対応にも時間がかかったりしますが、そうでなければ対応も比較的楽ですよね。そうして、ちゃんと機能するものが積み上がっていって、しかもこまめにフィードバックも得ているので、あるタイミングで大幅な変更で混乱、という事態にもなりにくいと思います。あるいは、多少大きめの変更が発生するとしても、それまでの実績があるので、その時点での変更コストが見通しやすい。

チームの継続とか縮小とか

チームを継続しながら適度なローテーション、てどうでしょう。意図してローテーションというのはあまりされていないような気もします。おそらくですが、個人のスキルに依存するばかりで、チームとしてのパフォーマンスに対する意識が低いのではないかと。対象とする分野とか業種によって、それぞれ要求されるスキルとかノウハウが異なるとは思いますが、それを固定化することがチームとか組織としてはたして良いのかどうか。例えば、ある分野で培ったノウハウを別のチームに持ち込んでみると、そこで新たな気づきにつながって、組織全体としてパフォーマンスが上がる可能性もあると思います。

コードの共有

個人の責任で追い詰めたところで何も解決しないどころか、時間のロスやモチベーション低下につながりますよね。チームでコードを共有して、チームで責任を持つと思えば、自然と個々のコードの品質も上がって、チームとしての評価も上がるはず。

といった感じで今日はこの辺で終わりにします。