アジャイルソフトウェア開発の奥義 第2章 エクストリームプログラミングの概要
開発
Published: 2019-05-23

「アジャイルソフトウェア開発の奥義」の読書メモです。

時々、個人の見解入りです。

エクストリームプログラミング (XP) とは

シンプルかつ具体的なプラクティスの集合から構築されているアジャイル開発プロセスである。

実践

実践法について書かれていました。

全部を満たす必要はない(できない)と思ったのと、状況に応じてカスタマイズしていった方が良いと思います。

チームメンバーとしての顧客

XPチームにとっての顧客とは、仕様の定義とその優先順位の決定権を持つ個人またはグループである。

物理的な距離も近い方が理想とのことです。

確認がすぐ出来るので、同意。

ユーザーストーリー

機能として入れるかどうかを検討できるため、同意。

短期間のリリースサイクル

おそらくここでいうリリースは、プロジェクトの成果物としてという意味だと思います。

運用されているサービスにリリースするということではないと思います。

受け入れテスト

本では顧客が提示とあるが、現実的にはエンジニアが顧客と共通認識を持つことになるのかなと思います。

ペアプログラミング

相談しながらやるという意味で同意。

ただ数時間もやる必要性は感じません。

テストファーストの開発

理想だと思いますが、実現できている組織はどれくらいあるのか気になります。

個人的にはユニットテストは、設計のセルフチェックの比重が大きいと思います。

(組織の状況によって変わると思います)

共同所有権

情報を共有するという意味で、同意。

継続的なインテグレーション(統合)

組織がどんなアーキテクチャを使っているかによりそうです。

ちなみには本ではビルド必要そうな言語想定かもしれません。

持続可能なペース

同意。

オープンワークスペース

他のペアの会話も聞こえる程度の環境の方が、作業効率が2倍になる研究もあるようです。

計画ゲーム

特に書くことなし。

シンプルな設計

不具合を発生させる可能性を低くするなら、構造をシンプルに保ち続けるという意味で同意。

  • 何とか動くだけの最もシンプルなものを考えよう。
  • あとで必要になんてならないよ。
  • 同じことは2度しない。

冗長性をなくす最善の方法は、アブストラクション(抽象化)を使うことである。

リファクタリング

コードはすぐに劣化していく。

コードを書いた当時と状況が変わるためだと思います。

リファクタリングは常に考える必要がありますが、作業ボリュームとの相談が必要です。

メタファー

概念の定義(言葉の定義)が大切。

同じ言葉で共通認識を持っていれば、その言葉だけで伝わるので必要と思います。