XPへの回帰
私の中だけで盛り上がっている事ですが。
最近、アジャイル開発だScrumだと叫ばれていますが、一旦、XPに戻る気がしています。
特にDevelopers Summitやいろいろな勉強会に参加して感じる事ですが、
・文書のやりとりなど「コミュニケーションより技術」な論争が多い
・ScrumはFrameworkなので芯が無い人は迷子になる
・TDDの立ち位置？
ココら辺の橋渡しや理論武装としてのXPが担う箇所が多いと感じています。
今一度XPを見直すべきだと思います。
フルスクラッチしないフレキシブルプロセス。そんなフレキシブルの源泉が何処にあるのか？勘と経験と度胸(読経？)にしか無いとか変だけど、そこがない人がそれを受け取った時に経典になってしまわないだろうか
— 爆弾ィヮォさん (@iwaoRd) 2013年2月19日んな訳でScrumフレームワークの土台にXPライフサイクルが息衝いているのでは？と。
XPを勉強していて、今のアジャイル開発（単に本を読んでスタートした場合）で欠けている点が以下だと思います。
1) ソフトウェア開発の経済学
「待つ」と言うオプションの価値として「下落リスクを回避する」事を認める事
未来を邪推して悩み、ムダな機能の実装をやめる
2) 意思決定の遅延
今日の決定コストが高く、正しい可能性が低く、明日よりよい方法を知る可能性が高く、将来設計を行うコストが低いのなら、今日必要でない設計の決定を今日してはならないこと。
それよりも今の機能をシンプルにする事に注力する。
3) 変更のコスト逓減
変更のコストが時とともにゆっくり上昇し、そのまま一定の値を保つのであるのならば、プロセス内で大きな決定をすることを可能な限り、遅らせて決定が正しくなるまで待つ
その為の「シンプル設計」「テスト駆動」「ペアプログラミング」
決定を遅らせると言うのはp112の『今日の決定コストが高く、正しい可能性が低く、明日良い方法を知る可能性が高く、将来に設計を行うコストが低いのなら、今日必要でない設計の決定を今日してはならない』がそれだと思う。
— 爆弾ィヮォさん (@iwaoRd) 2013年2月18日その前提は対応コストの曲線が将来に向かって逓減する事。その中心にはテストコードを置く事になるが、そのテストはテストファーストであって、仕様のプログラミング。
— 爆弾ィヮォさん (@iwaoRd) 2013年2月18日@kdmsnr 前提が「変更のコストが時間と共に劇的に上昇しない」なので、今日出来る設計をシンプルに保ち、必要になった時に改めて考えるとするのでは無いでしょうか。3章のソフトウェア開発の経済学の「下落のリスクを回避する」になるのかと。
— 爆弾ィヮォさん (@iwaoRd) 2013年2月18日
でも、まだ腹落ち感がないですね。
じゃあ、それって例えば何？というメタファー（実例？）があれば納得感があるのでしょうが。
XPはまだ「エクストリーム・プログラミング入門」を読んだだけです。
しかし、Twitter上では角さんと討論させて頂いたり、Scrum同様にまだカイゼンの余地や、その先に大きな可能性を秘めていると感じています。
XPマニアの人がいたら、一緒に議論させてください。
