「XPエクストリームプログラミング入門」を読みました

基本的に仕事ではスクラム（or カンバン）をベースに考えてるのですが、スクラムの中でもXPのプラクティスは補完的に使えると思うし、Webで流し読みぐらいしかしたことなかったので、今改めて。

XPエクストリーム・プログラミング入門―変化を受け入れる

第3章 価値、原則、プラクティス

よく出てくる用語だけど、それぞれの意味や関係をちゃんと理解してなかったので。こういうことらしいです。

Xp2 from Toru Koido

第9章 応用プラクティス

「チームの継続」と「チームの縮小」。まさに考えてるところなので、参考になりました。

小規模な組織にはこのような問題はない。チームが1つあるだけだ。

...

大規模な組織は、チームの価値を無視し、代わりに「プログラミングリソース」という分子または流動体のメタファを採用する場合が多い。（中略）この戦略では、部分的な効率性は最大限となるが、全体的には組織の効率性が損なわれる。

今僕が見ているチームは、まさにスケールしている最中なので、小規模・大規模のこの辺がよく実感できます。合わせて、うちでは分散拠点なので、ロケーションの問題も考慮しないといけないのが、更にややこしいところなんですよね。もちろん、ロケーションの問題を極力埋めるために、オンラインビデオ会議などシステムで回避できるようなものも積極的に取り入れようと試みてはいますが。

第10章 XPチーム全体

メトリクス（測定値）とは何ぞや？というのを、すごい分かりやすく説明した文章があったので引用。

速度計が速度を指し示すのと同じように、開発後の欠陥と投資から収益までの時間はどちらもチームの有効性を示している。速度計の針をつかんで動かしてみても、車の速度を上げることはできない。速度を上げたければ、アクセルを踏み、その効果を確認するために速度計を見る。同じように、測定値に基づいて目標を設定できるが、チームは根本的な問題に対処する必要がある。数字を直接改善しようとしても、数字が修正されるだけで、プロジェクトに関する透明性の価値が排除されてしまう。

メトリクスはあくまで現状を測るためのものなんですよね。メトリクス自体を補正しようとしても、まったく意味がない、というのが分かりやすい例えでした。

ただ、そもそもメトリクスがないと、実際にいい方向に向かってるのか悪い方向に向かってるのかが分からない（感覚的にはある程度わかっていても）。なので、まずはメトリクスを取ってみるというところは意識付けしていきたいなと思ってます。

---

その他にも制約理論の話とか、ちょいちょい見たことがある話もありましたが、もろもろ再確認できました。ただ、正直なところ、何か文章が頭に入ってきづらかったんですよね。。寝不足で疲れてたとかもあるのかも。読書も持続可能なペースでいきたいものです。