エクストリーム・プログラミング入門を読み直す

今頃になって、XPエクストリーム・プログラミング入門(白本)を読み直してみた。
考えたことをラフなメモ書き。

【元ネタ】
Hot Heart, Cool Mind.: エクストリームプログラミング(XP)

邦訳(XP エクストリームプログラミング入門)へのコメント

パターン、Wiki、XPは良書: プログラマの思索

【1】XPエクストリーム・プログラミング入門は第2版になって、原理・原則・プラクティスが覚えきれないほど大幅に増加している。
だから、以前の僕は第1版にあるプラクティスの方が分かりやすくて好きだった。
しかし、今になって見直すと、現在までのアジャイル開発の流れを予測しているかのような概念が出てくることに驚かされる。
応用プラクティスにある各プラクティスを考えてみる。

「インクリメンタル配置」は小規模リリースと同じ。インクリメンタルな開発、つまりイテレーション単位の機能改善によるリリースと同義。

「根本原因の分析」は、トヨタ生産方式のなぜなぜ分析そのもの。なぜを5回繰り返して、技術要素だけでなく心理的要素まで問題を突き詰める。

「単一のコードベース」はメインラインモデルないしtrunkによるソース管理と同義。

「日次配置」は継続的デプロイ、あるいはもっと発展させれば継続的デリバリーと同義。ソフトウェアを本番環境へ頻繁に配置することで、顧客に価値あるソフトウェアを納品できる。
継続的デプロイと継続的デリバリーの違いは「継続的デリバリー」に書かれている。
前者はアプリケーションの単なる頻繁なデプロイに過ぎないが、後者は、アプリケーションだけでなくデータ移行やサーバーの構築なども含んでいる。

「協議によるスコープ契約」「利用分払い」はまさにアジャイルな契約と同義。
「協議によるスコープ契約」は、イテレーション単位にスコープを決めて契約するわけだから、準委任契約に相当するだろう。
「利用分払い」は、SaaSのようにサービスを利用したコストだけ支払うという契約。
@kuranukiさんが提唱する「納品しない受託開発」や木下さんの価値創造契約もこの範疇に加わるのではなかろうか？

【2】また、@sugimoto_keiさんが言われている箇所もとても指摘が鋭いと思う。

(引用開始)
「計画ゲーム」をとってみよう。スコープ管理が大切だとは誰もが知っている。
しかし私たちが（少なくとも私が）そう口にするとき、本当に意味しているのは、「スコープの拡大を抑制せよ」という意味である。ケント=ベックは、スコープを自由変数として扱い積極的に制御せよ、という。
このとき彼の言わんとしていることは、たとえ当初想定されていた機能であっても重要性の低いものは削ぎ落とせ、しかもサブシステムや画面・帳票といった大粒度の単位だけではなく「機能特性（feature)」という小粒度の単位でも削ぎ落とせということだ。
反対に、重要性が高い機能特性なら後になってでも盛り込めとも言う。
しかもそれを二、三週間おきにやれという。
私はこんなにきめ細かいレベルでスコープを制御している例を見たことがなかった。
しかし言われてみると、決して不可能とも不合理とも思えない。
(引用終了)

XPでは、スコープを抑制するのではなく、開発者やユーザがスコープを変数とみなして積極的にコントロールする所に重要な主張がある。
WF型開発ならば、外部設計終了時に要件定義で発生した曖昧な要求や不相応に多い機能を削減して、スコープを減らして固定する。スコープが確定して初めて開発が始まる。
「仕様凍結」がWF型開発のキーワードの一つ。
だが、XPでは「ドライブ」という概念があるように、変化を敵視するのではなく逆に制御しようとする。

更に「パターン、Wiki、XP」で説明されているXPでは、プロジェクトの4つの変数という概念が提示されている。
それは、スコープ・品質・リソース・時間の4つだ。
4つの変数には特徴がある。

(引用開始)
・時間とリソースは限られている
・品質の目標は少しだけフレキシブルだが、振れ幅は狭い
・変更できるのはスコープだけである
・これらの4つについて、誰が決定権を持っているのかを確認し、彼らが適切な判断を下せるように開発状況と見積もりを報告する
(引用終了)

この特徴は「アジャイルサムライ」の「荒ぶる四天王」という話でも出てきた。
ソフトウェア開発とは、4つの変数を意識的に制御しながらプロジェクトを進める、つまりドライブするものと考えることができる。

【3】エクストリーム・プログラミングの底流に流れている思想の一つは、利用者と設計者のバランスを重視することだ。
XPエクストリーム・プログラミング入門の第23章「時を超えたプログラミングの道」でケント・ベックは自身の考え方を散文的に説明している。
僕の理解では下記のようになる。

アレクサンダーの建築の世界では、パターン・ランゲージ設計者と利用者の間にある力の均衡を取る手段として使われる。
その力の均衡はどちらが優位であるわけでもなく、設計者の深い技術的理解と利用者が持つ希望や社会的関係に対する理解が相互に結びつけて調和させることが本来の目的。

しかし、その力の不均衡は建築だけでなくソフトウェア開発でもある。
XPエクストリーム・プログラミング入門ではこう書かれている。

(引用開始)
ビジネス上の理由で設定された納期とスコープでは、チームの完全性を維持できない。
ユーザとスポンサーの関心事項は重要だが、開発者の要求にも正当な根拠がある。
3者全員が互いに情報を提供する必要がある。
(引用終了)

XPの目的は、調和とバランス。
つまり、設計者と利用者が一致する世界を目指している。
ソフトウェア開発における利用者と開発者の関係は固定された関係ではない。
そもそもコンピュータ、ソフトウェアの歴史は建築に比べるとはるかに短く、社会的関係も含めて新しく定義し直せる機会がある、と。

利用者と開発者が一致する世界とは、例えば、ユーザ企業自身が自分たちの業務やサービスのためにソフトウェア開発する場合があるだろう。
つまり、自分たち自身が利用者であり開発者であること。
最近、SNSやゲームに関する企業がアジャイル開発を積極的に取り入れている理由の一つは、ここにあるのかもしれない。

【4】更に、XPエクストリーム・プログラミング入門ではこう書いている。
この文章が一番心に残った。

(引用開始)
XPはソフトウェアについての信頼性の高い見積もり、実装、配置を迅速に行うことができる、強力なプログラマが増えることに依存している。
このようなプログラマはチームに対してなされたビジネス指向部分の方向転換ができる。
チーム間の権力と責任の適切な共有は、非現実的に思えるかもしれない。
このバランスには相互尊重が不可欠である。
絶対的な権力は存在しない。
XPでの権力は、悪用すると消滅する。
見積もりをごまかし、プライドを捨てて仕事を急いで終らせるたびに、チームは力を発揮できなくなっていく。
XPは、重役、マネージャ、顧客など全員が責任をもって全力を尽くすチームにかかっている。
協力して作業するチームは、それぞれのメンバの労力を合計する以上のことを成し遂げられる
(引用終了)

XPの価値の一つに「尊重」があるけれど、その発端は上記の引用にあるのだろう。

XPを批判する人たちは、XPは能力の高いプログラマに依存しすぎるとよく言うけれども、XPはそれを肯定している。
更に、技術志向な開発スタイルをナイーブに提唱しているのではなく、ソフトウェア開発では様々な権力の相互作用、つまり政治力を必要としていることも考慮に入れている。
開発現場では、有能なプログラマは発言そのものが大きな影響力を持つ。
でも、当然、顧客(プロダクトオーナー)も会社の上司(プロジェクトオーナー)も相当の権力を行使している。
僕自身もそのような経験をして下記に書いた。

プログラマにコミュニケーションが足りないと言われる時: プログラマの思索

SE、PL、そしてPMになるほど、開発チーム・顧客・SIの3つの立場を配慮しながら、その権力を行使する。
3者のバランスを取りながら、本来作るべきシステムは何なのか、を考えて、システムを漸進的に作っていく。
その開発現場は一つの社会的関係とも言えるわけだ。

アジャイル開発については今後も考えていく。