この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。
XP本読書会15回目と16回目からいくつかピックアップ。
ロゼッタストーン
プロジェクトが停止する前に、ビルドやテスト、システムを理解するためのガイドのようなものを書いておく。まぁ、停止する前というのもいつかわからないので、プロジェクト開始に合わせて準備して、随時更新しておくのが良さそう。
解決策の複雑さ
Agile459のコミュニティの中で「リファクタリング」が話題にあがることがわりとあります。なかなか日常の仕事の中でリファクタリングに時間をかけるのが難しいとか、その成果を説明するのが難しいとか。あるいは、一旦リリースしたものについて、具体的な予算のないところで手間（工数）をかけることができないとか。ですが、そういった気がかりがあるなら実践して前に進んだ方が良いですし、経費なのか投資なのかという判断が必要ならそういう協力者を見つけておく（15章）のが良さそうです。
継続的にデリバリーする中で、少しずつ複雑さを削り取っていく
と考えると、間違いなくメンテナンス性とか開発効率につながるわけで、変更に柔軟に対応できると考えればオープンにしてアピールすべき点とも思います。逆に、リファクタリングをしないで、複雑な状態のまま変更が求められるとなると、負担が増すばかりで、変更に対しても言い訳が先に立ってしまうような気がします。取引先も含めてお互いに気持ちよく仕事を進めるには大切な要素と思います。
また、次のセクションに出てくるトレーサビリティを考えると、こまめにリリースしておくことで、仮に大きな問題が見つかっても対応しやすいですね。これが長期間にわたってしまうと、何をどこまで戻すとか、その場合の影響範囲とか、考えるだけでもストレスになりそうです。
インタビュー
ペアプログラミングであり、チーム開発なのでそれができないとなるとXPの導入は難しいということ。それと、一部見過ごしていたのですが、見積もり当初は要件を隠しておいて、後からすべてのフィーチャーを要求される、というリスクもあるんですね。ここはやはり顧客との信頼関係ができていないと難しいですね。
全員が品質に責任を持つ
何か問題があると、伝言ゲームのように芋づる式に個人の責任が問われて対応するのが当たり前のような場面が多かったような気がします。それだとリスク管理ができていないわけで、やはりチームでコードを共有してテストも自動化することが大切。チーム全員で責任を共有して、自信を持ってプロダクトをリリース。チーム内のモチベーションにもつながります。