エクストリームプログラミングを読んだ感想とメモ
アジャイルの原点を探るべく、XPを学ぶ。普段スクラムで開発してるけど、XPについてあまり知らなかったので、改めて読んでみる。
第1章 XPとは何か
何が書かれているか
タイトル通り、XPとは何かについて書かれた章。定義として章の最後に以下のように書かれてる。
- XPとは、効果のない技術的/社会的な古い習慣を捨て、効果のある新しい習慣を選ぶことである。
- XPとは、自分が今日やるべきことを十分に理解することである。
- XPとは、明日をよりよくしようとすることである。
- XPとは、チームのゴールに貢献した自分を評価することである。
- XPとは、ソフトウェア開発で人間としての欲求を満たすことである。
感想
なるほどと思いつつ、あまり具体的ではないので、少しよくわからなかった。後続の章に詳しく書いてそうなので読み進めると良さそう。なぜ、XPが経済的に有効なのか考えていく、内容が書かれてるらしい。「チームよってXPのやり方も成功の度合いも違う」と書かれてたりもするので、XPとはなんぞやというエッセンスを感じつつも、最終的には自分たちで考えることも含めて大事だよね、みたいな感じになりそう。
第2章 運転を学ぶ
何が書かれているか
XPを運転に例えて説明した章
「運転というのはね、車を正しい方向に走らせることじゃないの。常に注意を払って、こっちに行ったら少し戻して、あっちに行ったら少し戻して、そうやって軌道修正していくものよ」
地平線を目指して運転してるとどこに進んでるかわからなくなるので、注意して運転しつつ、次にどこに向かうかを毎週考えることが重要。何がゴールに近づけて、何がゴールから遠ざけるかわかるようにするのが大事
感想
運転に例えるとそんな感じなんだねって感じだった
第3章 価値、原則、プラクティス
何が書かれているか
XPは、価値、原則、プラックティスの3つの要素で構成されてる(?)らしく、この3つの関係性について書かれてる章。
感想
価値、原則、プラックティスの関係がイマイチよくわからなかったけど、XPを実践する上で、その価値を分かった上でやるのと知らずにやるとでは、大きな違いがあり、知ってた方がいいよねという話だった。
第4章 価値
何が書かれているか
価値について書かれた章。価値とは、チームにとって大切なこと。
感想
3章で、急に「価値、原則、プラクティス」という言葉出てきて若干謎だったが、この章で「価値」について詳しく説明があった。
XPで開発するにあたって、重要の価値には5つ定義していて以下のようなものがあった。よく聞く内容だけど、XPの方が元ネタで僕が知ってるのは流れ着いたところで聞いた話なのかもしれない。
- コミュニケーション
- シンプリシティ
- フィードバック
- 勇気
- リスペクト
第5章 原則
何が書かれた章か
価値は抽象度が高いので指針となる原則が必要。原則について書かれた章。
感想
XPとは何なのかと迷ったときに読み返すと良さそう。個人的に好きだった原則は「失敗」の原則で、議論自体に時間をかけるより、失敗のリスクを受け入れて実行した方が速いということが書かれてる。他にもXPな振る舞いをするための原則が書かれているので、読んでて勉強になった。
以下、XPの原則
- 人間性
- 経済性
- 相互利益
- 自己類似性
- 改善
- 多様性
- ふりかえり
- 流れ
- 機会
- 冗長性
- 失敗
- 品質
- ベイビーステップ
- 責任の引き受け
第6章 プラクティス / 第7章 主要プラクティス
何が書かれているか
XPのプラクティスについて書かれた章。XPをどう実践するか書かれていて、プラックティスには、主要プラクティスと導出プラクティスがあるらしい。
感想
XPを実践する際に読み返すと良さそう。開発者は目の前のストーリーに集中しちゃうんで、四半期の計画を振り返った方がいいと書かれて、その通りだなと思った。ゆとり(slack)について、計画が遅れた時に外せるような優先度の低いタスクも計画に含めた方がいいと書いてあったのも、良さそうだと思ったので、参考にしたい。
- 全員同席
- チーム全体
- 情報満載のワークスペース
- イキイキとした仕事
- ペアプログラミング
- ストーリー
- 週次サイクル
- 四半期サイクル
- ゆとり
- 10分ビルド
- 継続的インテグレーション
- テストファーストプログラミング
- インクリメンタルな設計
第8章 始めてみよう
何について書かれているか
XPの始め方について書かれてる。
感想
この章以前の章でXPについての価値、原則、プラックティスが分かったので、実際にはじめてみる場合どうしたらいいか書かれてる。スクラムに似てるなと思ったけど、スクラムもXPもアジャイルな考え方がベースにあるので、似てる感じになってそう。
印象に残ってた記述に、XPは自分一人でも始めることができ、自分を変えることが、良いプロセスを作るための第一歩、といった感じに書かれてるのが良かった。何か新しいことを始めるには、まず自分から変わらなければいけない。
第9章 導出プラクティス
何が書かれているか
主要プラクティスができている場合、さらに開発プロセスを改善したい場合のプラックティスについて書かれた章。
感想
主要プラックティスができてる前提でさらに改善した場合のアプローチが色々書かれてて勉強になった。本物の顧客もチームの一員という考え方は良かった。
第10章 XPチーム全体
何が書かれているか
チーム全体を通して、XPにおける各ロールの概要が書かれてる
感想
チームの全体像がわかって良かった。チームは所属する組織によって違うと思うけど、各ロールの職業について、(経営幹部、PM、デザイナー、テクニカルライターなど)解説されてて勉強になった。
第11章 制約理論
何が書かれてるか
制約理論について書かれてる。制約理論は、システム全体のスループットを見ることができる。
感想
制約理論について、洗濯機の説明わかりやすかった。洗濯(45min) -> 乾燥(90min) -> 畳む(15min) という流れがある場合、乾燥の部分が制約になっていて、これを改善するには、乾燥する方法を別で追加するか、乾燥する時間を早くするしかない。実際の開発プロセスを改善する場合も、乾燥するに相当する問題を見つけることで、改善することができそう。
XPを取り入れ、開発の生産性が上がると、制約が開発プロセスの外にでき、そうなると開発自体が一旦いらなくなるので、チームが解散させられるという話、興味深かった。
第12章 計画:スコープの管理
何が書かれてるか
見積もりや計画づくり、スコープの管理について書かれてる。スケジュール通りにいかない場合の再調整やり方。
感想
ペアプロとソロプログラミングを比較したときに、単独で作業した方がペアでやるよりも2倍以上時間がかるらしい。最近よくモブプロで作業してるけど割と体感と近い気がする。ストーリーの見積もりはをポイントではなく時間でやる方が好みと書かれていて意外だったが、確かに実時間にした方が認識合いやすくて良さそうだと思った。
第13章 テスト:早めに、こまめに、自動化
何が書かれてるか
ソフトウェアの欠陥とそれを防ぐためのテストについてか書かれた章。ソフトウェアで欠陥が生じると信頼が失われるため、テストは信頼を守るために重要なもの。XPにおけるテスト重要性が書かれている。
感想
何のためにテストコードを書くのか、に対する答えとして、「安全にコードを変更できる」や「バグを防ぐ」「品質を守る」などいろいろな答えがあると思うけど、「信頼を守るため」という表現はすごく良いなと感じた。顧客や同じチームのメンバー、ステークホルダーなどソフトウェアに欠陥があれば、信頼されなくなる。信頼されなくなると、使われなくなったり、仕事がうまく回らなかったりする。信頼を守るために、テストコードを書くことはとても大事だなと改めて感じた。
第14章 設計:時間の重要性
書かれてること
インクリメンタルな設計を受け入れる理由について書かれている。インクリメンタルな設計とは段階的に設計していくこと。直感で考えた設計
、熟考した設計
、経験に基づいた設計
と段階があったときに、経験に基づいた設計
が一番品質が高くなるので、設計するのは、経験するまで遅らせることがポイントらしい。設計はシンプルに保つことが大切で、設計のシンプルさの評価基準も説明されてる。
- 対象者に適している
- 情報が伝わりやすい
- うまく分割されている
- 最小限である
感想
設計をシンプルに保つための4つの評価基準とてもいい基準だった。設計する時の観点として常に意識したい。特に対象者に適している、最小限である、の考え方好きだ。良い設計をするためには、シンプルさを意識しつつ、経験を積むしかないなと改めて思った。
設計がいかに見事で洗練されているかは重要ではない。その設計を使うべき人たちが理解できなければ、それはシンプルではない。
情報が伝わりやすい。伝えるべきすべてのアイデアがシステムに表現されている。システムの要素は、用語集の単語と同じように、未来の読者に情報を伝えるものである。
うまく分割されている。ロジックや構造の重複は、コードの理解や修正を困難にする。
最小限である。上記の3つの制約を守った上で、システムの要素はできるだけ少なくする。要素が少なければ、その分だけ必要なテスト、ドキュメント、コミュニケーションが少なくなる。
第15章 XPのスケーリング
この章で書かれていること
XPがスケールする方法が書かれてた章。人数や組織の規模が大きくなったときに、XPをどう適用させればいいかが書かれてる。
感想
人数が増えた場合は、問題を分解して小さくして、増えた人数を小さなチーム分割して、各チームで小さな問題を解いていくようにする。そうすることで、チームが大きくなる前のやり方と同じように問題に取り組めるし、さらに人数が増えていっても似たようなやり方でスケールすることができる。と書かれててなるほどなと思った。
大きな問題を解くときはまず小さな問題に分解していくこと大事。
問題を小さな問題に分割する。
簡単な解決策を適用する。
問題が残っていたら、複雑な解決策を適用する。
第16章 インタビュー
この章で書かれていること
SabreAirlineSolutions社の航空製品開発シニアバイスプレジデントであるブラッド・ジェンセンのインタビュー。XPを導入していて、XPの成果や推しポイントについて書かれてる
感想
ブラッド・ジェンセンさんは、XPの推しポイント(利点)として、欠陥が少ない、生産性が40%向上したと言っているが、生産性が高いとはどういうことか、具体的に調べたいと思った
第17章 はじまりの物語
この章で書かれていること
XPのはじまりの物語について書かれた章。リリースまで残り2ヶ月を切ってるが、プロジェクト自体はトラブルだらけで、XPの価値、原則、プラックティスを導入して、0から立ち上げ直したことについて書かれてる。著者が初めてXPを使ったプロジェクトの原体験について書かれてる。
感想
残り2ヶ月しかない状態でプロジェクトを最初からやり直す決断をしたのはすごい。ここからXPが始まり、その知見が現在に生きていると思うとやっぱりXPすごいなと思った
第18章 テイラー主義とソフトウェア
この章で書かれていること
テイラー主義とソフトウェア開発について書かれた章。テイラー主義とは、工場の生産性について科学した結果得た知見のことで以下のようなもの
通常、物事は計画どおりに進む。
局所最適化は全体最適化につながる。
人はほぼ代替可能であり、何をすべきかを指示する必要がある。
感想
テイラー主義とソフトウェア開発は合わないと感じた。計画通りに行く、リソースが代替可能という考え方が、アジャイルの思想とは合わなそう
第19章 トヨタ生産方式
この章で書かれていること
トヨタ生産方式(TPS / Toyota Production System)について書かれた章。TPSの開発プロセスでは作業者が作業のやり方について意見を述べて無駄を改善していくなどTPSのプロセスについて書かれてる。
感想
ソフトウェア開発とも類似性があって、XPの要素も多いのでソフトウェアを開発するでも参考にできることが多そう。ソフトウェア開発は作り直すことが可能だが、車の生産は不可逆(作ったら戻しずらい)ので、類似性はありつつ、物理的なものを作る開発は難しそうと思った。
第20章 XPの適用
この章で書かれていること
XPを適用するときや適用後の改善活動での注意点などが書かれた章
感想
XPのプラックティスをやってみるだけならすぐできると思うが、プラックティスに紐づいた価値や原則も一緒に組織全体で理解して実践するのは、結構時間がかかりそうだなと思った。XPを適用する際に、まずは自ら学ぶことが重要であったり、適用後も改善を繰り返すことが大事だったりするので地道に頑張らないとなと思った。
第21章 エクストリームの純度
この章で書かれていること
自分たちのチームがエクストリームであるかどうかどう判断すればいいか、に対する回答が書かれた章。個人やチームがXPかどうかを判断する方法は基本的にはないけど、ラ・レーチェ・リーグのリーダー認定モデル
を使うのが有効そうで、どうやるかというと、自己申告でチーム内外のメンバーとお互いに同意をとってそれを公にするというやり方。このやり方でXPかどうかを認定して、判断する。
感想
チームがXPかどうかはというのはそんなに重要じゃなくて(成果が出ていればXPじゃなくても良くて)、XPの価値・原則・プラックティスを実践してて、チーム内に共通の認識があり、成果が出ていることが大事。
第22章 オフショア開発
この章で書かれていること
オフショア開発と今後のグローバルなソフトウェア開発のの展望について書かれた章。グローバルなソフトウェア開発のシナリオは二つあって、一つはコストの高い国が政治的な力を利用してコストの低い国を利用し続けるシナリオ。もう一つは世界中のプログラマーが無駄を排除して、信頼性や効果の高い安価な新世代のソフトウェアが生み出し、グローバル市場が盛り上がるシナリオ。
感想
個人的にもオフショアという概念があまり好きではないので、無駄を排除して盛り上がってほしい。
第23章 時を超えたプログラミングの道
この章で書かれていること
ビジネス的な関心ごと技術的な関心ごとが一致しない問題について書かれた章。ソフトウェア開発は、プログラマーとその他大勢で成立するものではなく、関係者全員の関心ごとが一致していないと貢献できない人が出てくる。XPは、経営幹部、マネージャー、顧客も含めたチームのメンバー全員が、自分のできることを全力で貢献するかどうかにかかっている。
感想
プログラマーの世界だけでXPやっても仕方がなくて、チーム全体でXPをやらなければいけない。
第24章 コミュニティーとXP
この章で書かれていること
コミュニティーとXPの関係について書かれた章。コミュニティーはソフトウェア開発の偉大な資産
感想
コミュニティーで話すより聞くスキルの方が重要なのは話を聞いてくれる人(Giveしてくれる人)が多いと、自分一人で解決できないことを解決できて、さらに自分も Give できるようになる好循環が生まれるからなのかなと思ったりした。僕もコミュニティで学んできたこともあるし、コミュニティーや文化は大事だと思った。
第25章 結論
この章で書かれていること
この章まで書いてきたXPについてのまとめ。XPとは、あなたが自分の理想について考え、その理想にもとづいて行動するための方法だ。
感想
とてもいい本だった。ソフトウェア開発に対する、価値や原則、理想などを考えたことがなかったので、この本を読んでとても影響を受けたし、XPの価値や原則を受け継ぎたいと思った