http://martinfowler.com/bliki/AgileHandover.html

アジャイルプロジェクトに関して、他チームへの引継ぎはどうするんだ？という質問をよく受ける。開発チームの作業は終わり、サポートチームに引継ぎを行わなければならない。アジャイルプロジェクトは計画駆動型プロセスよりも作成されるドキュメントが少ないというのに、どうやって引継ぎを行うのだろうか？

まずは、計画駆動型プロセスにおいて、どれだけ有用なドキュメントが生成されているのかを考えてみて欲しい。ドキュメントを必須とするプロセスでは、あまり役に立たない成果物まで作成されてはいないだろうか。納期へのプレッシャーで、ドキュメントの更新がなされていないということはないだろうか。対してアジャイル手法では、少量高品質なドキュメントが好まれている。

アジャイルプロジェクトでは、フェイストゥフェイスのコミュニケーションが重要視される。私がよく見るのは、開発チームがいなくなる前にしばらくの間、サポート／保守チームを開発チームと一緒に働かせるやり方だ。両チームがしばらく一緒にいれば、開発チームは保守チームにシステムを実際に動かしながら教えることが出来る。このテーマに関しては、他にもいくつか事例を見たことがある。

  • あるチームでは、チームのメンバのうち1,2人をイテレーション毎に入れ替えていた。そうして、2,3ヶ月かけてチームのメンバを総入れ替えするようにしていたのだ。
  • 私たちがインドにプロジェクト移転したとき（邦訳）は、国内の開発者を最低でも数ヶ月、海外で新しいチームと一緒に働かせるようにしていた。
  • あるチームでは、開発の最後の月にサポートのメンバをひとり、開発メンバに入れてた。

最後の事例は同僚であるJonathan Rasmussanによるものだ。彼はこう指摘している。開発の最後にサポートチームを入れるもうひとつのメリットは、関係性の構築である、と。そうすることで、新しいシステムを簡単にデプロイすることが出来るそうだ。開発チームと運用チームは、たいてい緊張関係にある。開発チームは、運用チームの必要性を無視しがちだ。そこで、運用チームの人間をしばらく開発チームに入れることで、双方向にコミュニケーションのやり取りが行えるようにするのである。

ドキュメントの話に戻るが、Jonathanが言うには、サポートメンバーはドキュメント作成のオンサイトカスタマー的な役割を担うことになるのだそうだ。結果として、いつものドキュメントよりも格段に出来のよいドキュメントが出来るのだそうだ。

追加開発を行うために、まったく新しいメンバを引き連れてやってきた Jonathan は、やがて自分のドッグフードを食べるようになった*1。彼らは、プロセスに従ったものではなく、必要に応じて書かれたドキュメントは非常に役に立つことに気付いた。量よりも質なのだ。システムについて学ぶのに非常に役に立つ方法がまだある。XPの自動テストの中身だ。（XPerは何度でも指摘するだろうが）テストはそれ自体が重要なドキュメントなのである。