XP入門
はじめに
今年の6月からスクラムマスターの役割を担うことになりました。
しかし、私自身現在の会社に勤めるまでアジャイル開発の経験が全くなかったので、理解を深めるために XP について学ぶことにしました。
この記事はケント・ベック氏によって著された「エクストリームプログラミング」の7章までの読書メモと感想です。
XP とは
XP (エクストリームプログラミング)は、アジャイル開発の手法の一つです。
エクストリームは日本語で「極限」という意味で、柔軟な変更や継続的な成長により開発プラクティスを極限まで洗練させ、品質の高いソフトウェアを効率的に開発することを目指します。
価値、原則、プラクティス
XP には、価値、原則、プラクティスがあります。
本書では、イチゴ栽培を例に挙げて説明されていました。
イチゴの隣にマリーゴールドを植える = プラクティス
マリーゴールドはイチゴを食べる虫を寄せ付けない = 価値
隣り合った植物がお互いの弱点を補う(共生栽培) = 原則
この例と本書に書かれている他の内容を基にした私の理解は以下です。
プラクティス = 実際の行動
価値 = プラクティスによって生まれる恩恵、目的
原則 = プラクティスと価値の橋渡しをするもの、活動指針
次からそれぞれについて詳しく内容を見ていきたいと思います。
価値
XP では、個人としてではなく、チームや組織の一員としてどのように振る舞うかに重きを置いています。
全員がチームにとって大切なことに集中するとしたら、何をするべきかについて5つの価値が定義されています。
- コミュニケーション
- シンプリシティ
- フィードバック
- 勇気
- リスペクト
コミュニケーション
- 開発中に問題が発生したときには、すでに誰かが解決策を知っていることが多い。だがその情報は変更する権限のある人には伝わらない。
- 予想外の問題に遭遇した際、コミュニケーションが解決につながる可能性がある。過去に同じような問題を経験した人に話を聞くこともできるし、問題の再発防止についてチームで話し合うこともできる。
- チーム感覚や効果的な協力関係を生み出すために重要なもの。
シンプリシティ
- ムダな複雑性を排除するために、何ができるかを考える。
フィードバック
- 一時的な完成に期待するよりも、常に改善を続けていくことが大事。
- XP ではできるだけ早く、できるだけ多くのフィードバックを生み出そうとする。
- フィードバックが早く手に入れば、その分だけ早く適応できる。
勇気
- 今までのやり方を急激に変えたり、あるいは、今までのやり方を否定するような変化を受け入れることが必要。
- 勇気のみでは危険だが、他の価値と合わせれば強力。
- 「勇気」を持って真実を語れば、「コミュニケーション」や信頼が強化されていく。
- うまくいかない解決策を捨て、「勇気」を持って新しい解決策を見つければ、「シンプリシティ」が促進される。
リスペクト
- チームメンバーがお互いに関心がなく、何をしているかを気にもとめないようであれば、XPはうまくいかない。
- チームメンバーがプロジェクトを大切にしないのであれば、何をしたところで開発は成功しない。
- ソフトウェア開発において人間性と生産性を同時に高めるには、チームに対する個人の貢献をリスペクトする必要がある。
原則
価値は抽象度が高いので、そのままでは振る舞いの指針になりません。
そのため、XP では価値の指針となる原則が定義されています。
- 人間性
- 経済性
- 相互利益
- 自己相似性
- 改善
- 多様性
- ふりかえり
- 流れ
- 機会
- 冗長性
- 失敗
- 品質
- ベイビーステップ
- 責任の引き受け
このうち私が興味を持った原則をいくつかご紹介します。
人間性
- 人間がソフトウェアを開発する。これはシンプルで逃れようのない事実。
- 優れた開発者になるには、何が必要だろうか？
- 基本的な安全性 - 空腹、身体的な危害、愛する人を危険にさらすものが存在しないこと。
- 達成感 - 自分が所属する社会に貢献する機会や能力
- 帰属意識 - グループに所属して、承認や説明責任を受け取ったり、共通の目標に貢献したりすること。
- 成長 - スキルや視野を広げる機会。
- 親密な関係 - 他人を理解して、他人から深く理解されること。
- チームによるソフトウェア開発で難しいのは、個人の欲求とチームのニーズの両方のバランスを取ること。
- 優れたチームが素晴らしいのは、メンバーたちが信頼関係を築き、一緒に働くことによって、みんなが自分らしくいられること。
相互利益
- あらゆる活動は、関係者全員の利益にならなければいけない。
- 相互利益とは、最も重要であり、最も実行が難しい XP の原則。
- XP の相互理解は、現在の自分、将来の自分、顧客に対する利益を求める。
- 将来とのコミュニケーションの問題を相互利益になるやりかたで解決する例。
- 現時点で設計や実装がうまくできるような自動テストを書く。また、テストは将来のプログラマーにも使えるように残しておく。こうすることで、現在の自分と将来の保守担当者の両方の利益になる。
- 意図しない複雑性を排除するために、注意深くリファクタリングする。自分の満足感が得られ、欠陥が少なくなり、あとでコードに触れた人が理解しやすくなる。
多様性
- 問題や落とし穴を見つけたり、問題を解決する方法を複数考えたり、解決策を実現したりするためには、さまざまなスキル、考え方、視点を組み合わせる必要がある。つまりチームには多様性が必要。
- 多様性には衝突がつきもの。
- 衝突が発生しないチームなど存在しないので、生産的に衝突を解決できるかどうかを考えてみる。
- みんなをリスペクトして、自分の言い分を主張すれば、ストレスのかかる状況でもコミュニケーションは円滑になるはず。
品質
- 品質を犠牲にするのは、効果的なコントロール方法ではない。
- 品質は制御変数ではない。
- 低品質を受け入れることで、プロジェクトが早くなることはない。
- 高品質を要求することで、プロジェクトが遅くなることもない。
- むしろ品質を高めることで、デリバリーが高速になることが多い。
- 品質基準を下げてしまうと、デリバリーが遅くなり、予測できなくなってしまう。
プラクティス
プラクティスとは、チームが日常的に行うものです。
単独でも機能しますが、組み合わせた方がより機能します。
すぐに改善につながり、どれからでも始められる「主要プラクティス」と、先に主要プラクティスを習得しておかなければ難しいであろう「導出プラクティス」について書いてありました。
この記事では「主要プラクティス」について紹介します。
- 全員同席
- チーム全体
- 情報満載のワークスペース
- いきいきとした仕事
- ペアプログラミング
- ストーリー
- 週次サイクル
- 四半期サイクル
- ゆとり
- 10分ビルド
- 継続的インテグレーション
- テストファーストプログラミング
- インクリメンタルな設計
チーム全体
- プロジェクトの成功に必要なスキルや視点を持った人たちをチームに集めること。
- プロジェクトの健全性のために綿密なやりとりが必要なところでは、機能単位ではなく、チーム単位でやりとりをすること。
- そのためには、以下のような「チーム」感が必要。
- 我々は、帰属している。
- 我々は、一緒の仲間である。
- 我々は、お互いに仕事、成長、学習を支えている。
- 「チーム全体」の構成要素は動的に変化する。
- スキルや考え方が重要なときには、それを身に付けた人をチームに迎え入れればいい。
- 必要なくなれば、チームから外れてもらえばいい。
- プロジェクト単位でメンバーを動的に変更してもいい。
いきいきとした仕事
- 生産的になれる時間だけ働くこと。
- 無理なく続けられる時間だけ働くこと。
- 意味もなく燃え尽きてしまい、次の2日間の作業が台無しになることは、自分にとってもチームにとってもいいことではない。
- ソフトウェア開発は洞察力のゲーム。洞察力は、準備の整った、休息のとれた、リラックスした精神から生み出される。
- その他の方法では制御不能になったときに、制御を取り戻す手段として、長時間労働することが多い。
- だが、疲労した状態では、バリューを奪っていることさえ気づかない。
- 病気のときは休息と回復に努め、自分とチームをリスペクトすること。静養こそがいきいきとした仕事に戻る近道。
ペアプログラミング
- 同じマシンを前にした2人でプログラムを書くこと。
- ペアプログラミングでやること。
- お互いにタスクに集中する。
- システムの改良について意見を出し合う。
- アイデアを明確にする。
- パートナーがハマったら主導権を握り、相手の失望感を軽減させる。
- お互いにチームのプラクティスの説明責任を果たせるようにする。
- ペアプログラミングは満足感はあるが、実際にやると疲れるプラクティス。
- 休息を挟めば、新鮮な気持ちを一日中保つことができる。
- うまくやるには、お互いのパーソナルスペース、個人差をリスペクトすることが重要。
ゆとり
- どのような計画にも、遅れたときに外せるような重要度の低いタスクを含めること。
- 少しでもやるべきことを果たせば、人間関係の再構築につながるはず。
- 明確で正直なコミュニケーションは信頼を高める。
インクリメンタルな設計
- システムの設計に毎日手を入れること。
- システムの設計は、その日のシステムのニーズにうまく合致させること。
- 最適だと思われる設計が理解できなくなってきたら、少しずつだが着実に、自分の理解できる設計に戻していくこと。
- 欠陥の修正コストは時間の経過によって指数関数的に増加することが示されている。
- 設計に毎日注意を払わなければ、変更コストは急増する。その結果、設計が貧弱で脆弱な変更しにくいシステムになってしまう。
- シンプルで役に立つ解決策は、重複を排除すること。
- 重複のないコードは変更しやすい。
- インクリメンタルな設計は、使用する直前に設計するのが最も効率的。
- そうすれば、システムはシンプルになり、進捗は早くなり、テストが書きやすくなる。システムが小さくなるので、チームのコミュニケーションも軽減できる。
おわりに
スクラム開発と比較すると、XP はより技術的内容にフォーカスしているように思いつつも、原則やプラクティスからは人間性を大切にする考え方が根底にあると感じました。
ソフトウェア開発は人間が行うものであり、またそれを使うのも人間です。
良いものを作ってエンドユーザーの幸福に寄与するためにも、まずは私たちがコンディションを整えたり社会的欲求を満たすことで、自分らしくいられる環境づくりが重要だと思います。
本書で学んだことを取り入れ、スクラムマスターとしてより良い環境づくりを目指したいです。
Discussion