Martin Fowler's Blikiからのメモ
agileな開発の本質とは？が知りたいので色々調べていたところThoughtWorksのMartin FowlerのBlikiの和訳を見つけたので、個人的にピンと来たところをメモ。
要求の変更は次々とやってくる。それでも我々はショックを受けなかった。それぞれについて変更のスコープを見積もり、どれだけコストがかかるかを見つけ出した。だが、その変更によってクライアントに課金することはしなかった。ゆっくりだが確実に、要求変更はバッファを食べ尽くしていった。 6ヶ月余りが過ぎ、バッファは完全に食い尽くされてしまった。我々はこの間、常に Nebbiolo に対してオープンであったため、これ以上変更を受け入れる金銭的余裕がないことを告げても彼らは驚かなかった。
多くの業者は、最初に安値を提示して、後からスコープの変更で利益を得るようなことをしている。しかしこの手法では、クライアントとの関係が悪化してしまう（それにこれはすべての産業で悪評高い）。
本当に生産性を測定するのであれば、ビジネスの価値に基づいてなければなりません。単に機能だけではダメなのです。
プロジェクトを複数のイテレーションに区切る。要求された機能をフィーチャに分ける（または、XPで言うストーリーに分ける）。各フィーチャにどれだけ作業量がかかるかを見積もる。イテレーションごとの作業量を記録し、許容量以上のフィーチャを詰め込まないようにする。 XPのリリース計画とは、どの機能をどのイテレーションに入れるかというものである。
フィーチャを追加したければ、「スペースを空けるために、どれを外しましょうか？」と聞かなければならないのだ。つまり、もしスペースを空けることを考えずにフィーチャを追加しようとしているなら、計画自体が悪いと結論付けてよいだろう。
アジャイラ(agilist)の価値である「機能よりも成果*1」にある。機能リストは有用なツールである。だが、それは手段であって目的ではない。重要なのは、最終的な成果である。私はそれを「顧客価値」だと考えている。
機能リストはプロジェクトが進むにつれて変わりうるものだということを、あらかじめ認識しておくところにある。その都度、新しくできることを発見し、再度、優先付けを行う。これが適応型計画の肝であり、アジャイルな考え方の指標である。
計画が頻繁に変更しないのであれば、適応型計画をしていないのであり、つまりは、アジャイルではないということである。
「Specification By Example（実例による仕様書、SbE）」
仕様書とは、システム全体を網羅するものである。しかし、実例は部分的にしかフォーカスしない。そのため、そこから全体を推測しなくてはならない。SbEだけで要求定義は出来ないように思う。だが、要求定義における主役級の技術に成り得るかもしれない。
SbEのグレートなところは、書くのがとても簡単だという点だ。我々がソフトウェアを提供する非ナードだって書けてしまう。
アジャイル方法論なんて嫌いだというクライアントと話したことがある。「プロジェクトの初期段階で、こんな面倒なことをやるのは間違いだと思う」と彼は言った。彼の反応とは対照的に、私は、この初期の痛みこそがアジャイルや反復的開発の最大の利点だと思った。
ウォーターフォール開発の最大の問題が、プロジェクトの終盤まで問題の発見が遅れるという点だと考えているからである。その時点ではもはや、問題に対処すべき時間も余力も残っていないのだ。反復することによってできるだけ早い段階から、できるだけ多くの問題を見つけ出すことができる。これで対処できる時間が増える。あるいは、問題を洗い出すことで、膨大な予算や作業を費やす前に問題の多いプロジェクトを中止することができる。
最近、「ダメダメagile開発が増えているのはきちんとプラクティスをやっていないから」みたいな記事をみたが、こうしてみるとペアプロとかテストファーストとかのプラクティスも重要だけどそれよりも、「柔軟な開発スコープ」・「反復的な開発」・「ソフトウェアのビジネス的な価値」といったもう一つ上の段階のほうが重要な気がしてくるなぁ。
