この記事にはオーディオバージョンがあります：オーディオバージョンをダウンロード
スクラムとエクストリーム 実際、これらのプロセスのいずれかを行っているチームに参加した場合、スクラムチームかXPチームかをすばやく決定するのに苦労するかもしれません。 違いは、多くの場合、非常に微妙ですが、彼らは重要です。
- スクラムチームは、通常、二週間から一ヶ月の長さの反復（スプリントと呼ばれる）で作業します。, XPチームは通常、一週間または二週間のイテレーションで作業します。
- スクラムチームはスプリントへの変更を許可しません。 スプリント計画会議が完了し、一連のプロダクトバックログ項目の提供に対するコミットメントが行われると、その項目のセットはスプリントの終 XPチームは、イテレーション内で変更する方がはるかに従順です。 チームが特定の機能の作業を開始していない限り、同等のサイズの新しい機能をXPチームのイテレーションに入れ替えて、未スタートの機能と引き換えにすることができます。,
- 極端なプログラミングチームは、厳密な優先順位で作業します。 開発される機能は、顧客（スクラムの製品所有者）によって優先され、チームはその順序でそれらに取り組む必要があります。 対照的に、スクラムのプロダクトオーナーはプロダクトバックログを優先しますが、チームはバックログアイテムを開発する順序を決定します。 私はスクラムチームが最優先事項に取り組むことを選択していないのを見たことがありません。 そして、スクラムチームは非常に可能性が高い第二の最も重要に取り組むことを選択します。, しかし、ある時点で、優先度の高い項目の一つが計画されているスプリントには適していないかもしれません—それに取り組むべきキーパーソンは、優先度の高い項目に取り組むことに圧倒されるかもしれません。 あるいは、チームが＃10が実装されるコードで作業するため、わずかに低い優先度の項目（＃10ではなく製品バックログで＃6としましょう）で作業することは理に
- スクラムはエンジニアリングプラクティスを規定していません。, 私はXPのエンジニアリングプラクティス、特にテスト駆動開発、自動テスト、ペアプログラミング、シンプルな設計、リファクタリングなどが大好きです。 しかし、私はそれがチームに言うのは間違いだと思う”あなたは自己組織化している、私たちはあなたを信頼していますが、あなたはこれらの特定のエンジ…”これは混乱を引き起こすチームに混合メッセージを送信します。 僕はXPの慣行がないように義務付けます。 チームには自分で価値を発見してもらいたいです。
これらはスクラムとXPの間の小さく、しばしば微妙な違いです。, しかし、彼らはチームに大きな影響を与えることができます。 チームに対する私の典型的なアドバイスは、”スクラムから始めて、独自のバージョンのXPを発明する。”XPのプラクティスは素晴らしいですが、彼らは最高の仕事をし、チームは彼らが義務付けられているのではなく、彼ら自身を発見した場合、最もstridently彼らに 私はチームが私のコーチングでこれを行うのを助けます、”もし私たちがテスト駆動開発をしていたら、このバグは起こったでしょうか？”と”ペアリングしていたら、そのミスを犯しただろうか？”▲真のXPは遠くの小さな目標であることがわかります。, チームがそれを目指して雄牛の目を打つことができれば、素晴らしいです。 しかし、そうでない場合は、ハッキング（例えば、自動化されたテストやTDDなしのリファクタリング）が起こりそうです。 スクラムは、単に追加のフォーカスとタイムボックスの反復を通じて、それ自体で大きな改善をもたらす大きな雄牛の目です。 これは、XPのプラクティスを追加するための良い出発点です。