😺

エクストリームプログラミング（XP）をざっくり理解する

2021/08/01に公開

アジャイル

アジャイル開発

エクストリームプログラミング

tech

概要

エクストリームプログラミング（XP）は、アジャイル開発の手法の1つです。XPとは変化に対応しながら、いかにシステムの開発を進めるかに焦点をあてたソフトウェアの開発プロセスです。

ユーザーの要求は常に変化します。その変化を前向きに捉えて受容していくため、小さな工程を繰り返しながら前に進み、十分なコミュニケーションとフィードバックをもとに、最初に全体を設計するよりも再設計を繰り返し行っていきます。

XPを理解するには、まずは「プラクティス」と「価値基準」を知る所から始まります。

※本記事でのXPのプラクティスや価値基準で挙げる項目は、Clean Agileを参考にしています

アジャイル開発について

XPの中身に入る前に、アジャイル開発についても軽く触れます。アジャイル開発の考え型を端的に表現したものに、アジャイルソフトウェア開発宣言があります。これはXPと密接に関係しています。

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

※IPAから出しているアジャイルソフトウェア開発宣言の読みとき方は、分かりやすくてお勧めです

XPのプラクティス

アジャイルソフトウェア開発宣言の署名者の一人でもある、ロン・ジェフリーズ氏が描いたサークルオブライフと呼ばれるXPのプラクティスがあります。

リングの位置について

外側のリング... ビジネス向けのプラクティス
中間のリング... チームのプラクティス
内側のリング... 技術のプラクティス

各項目について

計画ゲーム... ストーリーカードに基づいて作業計画を立てます
小さなリリース... できる限り迅速にリリースし、早くフィードバックを貰います
受け入れテスト... ユーザーの立場から、ストーリーが実現できているかを確認します
チーム全体... チーム全体（顧客、プログラマー、マネージャー、テスター等）で活動します
持続可能なペース... 開発者の労働負荷を常に一定に保ちます
共同所有... 全てのコードは全員が等しく共有します
継続的インテグレーション... 単体テストを通るコードができる度に、残りの部分と結合して問題がないかを探します
メタファー（比喩）... 関係者全体でシステムの構造や振る舞いを事例を通じて共有します
ペアリング... 2人1組でプログラミングをします
シンプルな設計... 設計を簡素に保ちます
リファクタリング... 完成したコードでも随時改善を行います
テスト駆動開発... コードより先にテストを記述します

これらのプラクティスは、アジャイルソフトウェア開発宣言の目標とほぼ一致しています。例えば「プロセスやツールよりも個人と対話を、」という部分は、XPのプラクティスのチーム全体・メタファー・共同所有・ペアリング・持続可能なペースが該当し、「包括的なドキュメントよりも動くソフトウェアを、」は、XPのプラクティスの受け入れテスト・テスト駆動開発・シンプルな設計・リファクタリング・継続的インテグレーションが該当します。

ペアリングについて

2人が一緒に同じプログラミングの課題に取り組みます
2人はドライバーとナビゲーターに役割を分けます
1週間の中で半分の時間を自分のタスクに費やし、残りは他の人のタスクを助けるのに使います
ペアになることで、チームメンバーの知見を共有することができます
ペアリングがコードレビューの代わりにもなります

プラクティスの適用について

XPのプラクティスは単独ではなく、組み合わせて使います。しかし、すべての項目を一度に行うことは敷居が高いため、少しずつ取り入れていくと良いです。すべての項目をやっていないからXPではないということではありません。

XPの価値基準

開発チームが何に重きを置くかの判断基準として、4つの価値を示しています。

勇気... 構造の良くない点に気が付いても、設計をやり直すには勇気が必要です。コミュニケーションを取り、フィードバックを的確に受け、シンプルな設計をしていれば、判断に迷わずに思い切って大きな変更をする勇気が持てます
コミュニケーション...コミュニケーションは4つの価値の内で最も重要なものです。頻度の高い直接的なコミュニケーションを大切にします
フィードバック... 計画ゲーム・リファクタリング・テスト駆動開発などは、フィードバックの頻度と量を最大化してくれます
シンプリティ（シンプル）... 今日単純なことをして、明日変更が必要になったときに変更のコストを支払う方が、今日複雑なことをして結局使われないよりも良いというXPの戦略です

まとめ

業務ではスクラムに寄せた形式で、スクラムマスターを置いてプロジェクトを遂行していました。しかし、アジャイルソフトウェアの12の原則にある自己組織的なチームにはなっていなかったのです。スクラムマスター = チームリーダーという立ち位置になってしまい、スクラムマスターの指示待ちの組織になっていました。

そこでアジャイル開発において、スクラムとは別の手法であるXPという話しが出ました。XPはスクラムと比べて、スクラムマスターといった立場の人を置きません。チームの全員が自ら動いてプロジェクトを遂行します。（まだ私の理解が浅いため、間違えていたらご指摘ください）

そのため、アジャイル開発の中でも、スクラムではなくXPに着目し調べていました。

本記事の各項目のプラクティスについては、もう少し深堀りしたかったですが、長文になりそうだったため、ざっくり理解という事にしました。気が向いたら、またXPについて記事を更新します。

概要