これはほんとに、プログラマにとっては、とってもわかりよい例え話。
www.ryuzee.com
Javaでは抽象クラスのインスタンスを作ることはできません。 これが意味するのは、抽象クラスはそのままの形では存在しえないということです。 派生させて、具体的な実装が行われれば、実体として存在できるようになります。
言い換えると、抽象クラスで規定されている振る舞いが気に入ったのであれば、そこから派生できるし、自分独自のバージョンを作れます。 しかし、そこには暗黙の契約もしくは了解があります。 抽象クラスを使うということは、そこで規定されている振る舞いを継承してそれに適合させることに合意するということです。 抽象クラスから派生させると、あなたのサブクラスは、そのインスタンスになるのです。
ここでちょっと、スクラムが抽象クラスであると想像してください。
（中略）
スクラムは肉付けする必要があるメソッドシグネチャのセットを定義しています。 全てのイベントやロールや作成物がスクラムの実装によって調整されていたとしても、それは依然としてスクラムです。 抽象クラスとの契約をを破ってメソッドを除去したり省略した場合だけ、それはスクラムではなくなります。 その場合は、何か他のものを実装しているのです。
スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない。（スクラムガイド）
抽象クラスの中身を実装する上で素晴らしい点は、メソッドの追加が自由なことです。 実際、スクラムを実装すると、すぐに既定のメソッドは最低限であることに気づくでしょう。 いくつかの重要だと思われるメソッドが完全に欠落しているのです。
スクラムガイドはソフトウェア開発の細かいことを規定したりチェックリストであることを意図しているわけではありません。 重要なプラクティスの多くはスクラムガイドには載ってはいません！ 実際に進めてみて、自分たちに足りないものを見つけないといけないのです。
この不足自体が完全に設計された意図的なものである点は興味深いと言えるでしょう。
抽象クラスのメタファーでスクラムを表すと、エンジニアリングプラクティスを自分たちで定義して追加しなければいけないメソッドだと考えることになります。
全文を引用してしまいそうな勢いなので、このくらいにしといて、
あとは@ryuzeeさんのBlogをご参照ください。
