エクストリームプログラミング解説 その4:プラクティス

| 3 min read
Author: makiko-nakasato makiko-nakasatoの画像

はじめに

#

中佐藤です。XP解説その4です。前回までで、「価値」の解説が終わっています。今回は「プラクティス」についてです。

プラクティス

#

いきなりですが、すべて列挙してみましょう。第2版のプラクティスを軸(左欄)に置いて、対応する(と思われる)第1版のプラクティスを右に配置しました。ざっと眺めて下の解説に行ってください。

第2版の主要プラクティスと対応する第1版のプラクティス

#
第2版の主要プラクティス 第1版のプラクティス
全員同席
チーム全体
情報満載のワークスペース
いきいきとした仕事 40時間労働
ペアプログラミング ペアプログラミング
ストーリー
週次サイクル 計画ゲーム
四半期サイクル
ゆとり
10分ビルド
継続的インテグレーション 継続した結合
テストファーストプログラミング
インクリメンタルな設計 シンプルな設計

第2版の導出プラクティスと対応する第1版のプラクティス

#
第2版の導出プラクティス 第1版のプラクティス
本物の顧客参加 オンサイトのユーザー
インクリメンタルなデプロイ
チームの継続
チームの縮小
根本原因分析
コードの共有 共同所有
コードとテスト
単一のコードベース
デイリーデプロイ 短期リリース
交渉によるスコープ契約
利用都度課金

第1版のみのプラクティス

#
第2版に該当なし 第1版のプラクティス
メタファ
テスト
リファクタリング
コーディング規約

プラクティス:一覧について補足

#

第2版の主要プラクティスと導出プラクティスの違いは何かというと、「主要プラクティスを事前に実践していなければ、導出プラクティスを導入するのは難しい」と書かれていて、主要=基礎、導出=応用というイメージです。

例えば、「(ペアプログラミング、継続的インテグレーション、テストファーストプログラミングなどで)欠陥率をゼロに近づけないまま、デイリーデプロイを開始しようとすれば、大惨事を招くことになる」というように。個人的には、一度ヒドイ目に遭ってから、じゃあどうする、を自分たちで考えていくのもありなんじゃないかとは思いますが。

第2版と第1版の対応は私の判断です。ちょっと迷ったものもありますが、エイヤっと並べてみました。比較すると単に訳が変わっているだけのもの(例えば、継続的インテグレーションと継続した結合)も、言葉は変わっているけれど同じことを意図しているもの(例えば、いきいきとした仕事と40時間労働)もあります。

プラクティス:解説

#

今になってみると、結構知っている/使っている手法も多いのではないでしょうか。CI(継続的インテグレーション)とか、アジャイルとは関係なしに導入している現場も多いでしょう。その前提となる、コードの共有(共同所有)とか単一のコードベースとかもごく普通です。リファクタリングとか、え、XPのプラクティスだったの、という印象かも。

時代の変化に伴い、位置づけや意義が変わってしまったものもあります。例えば、デイリーデプロイ。まさかこの頃(第2版の原著は2005年出版)には、4年後に DevOps なんてキーワードが出てきて ”10 deploys per day” などという話が出てくるとは想像していないでしょう。ただ、思想としては正しくて、現在のCI/CDのまさしく源流ではあります。

後は、メタファでしょうか。「顧客にも開発側にもわかる言葉でシステムを理解しよう」というもので、例えばWindowsのごみ箱を例に挙げることが多かったですが、そうそういい言葉は見つからないよね、と思っていました。しかし、後でDDD(ドメイン駆動設計)のユビキタス言語の話と結びつける考え方を知り、なるほどなと思ったものです。

どう使うか

#

さて、ここからが大事なところです。XPのこれらのプラクティスの解説をすると、大抵言われることが、「え、これ全部やらないとXPやったことにならないの。ならウチではXPは無理」ということです。よくやり玉に上がったのが「本物の顧客参加(オンサイトのユーザー)」というやつ。「開発現場にずっとお客さんにいてもらうなんて非現実的」って何回聞いたことか。

ここで「無理」と思考停止しないでください。この連載の最初に出した全体像の図のうち、価値とプラクティスだけを以下に抜き出しました。

プラクティスの適用

追加した青矢印と赤矢印が、みなさまが行うべき思考の流れです。プラクティスのうち、意義はわかるけど自分たちの状況ではできないと思うものがあれば、そのプラクティスがどの価値を実現したものかを考えてください(青矢印)。例えば「本物の顧客参加」であれば、おそらく主には「シンプル」な顧客との「コミュニケーション」です。

さらにその価値をできるだけ損なわないように、かつ、自分たちができる方法を考えましょう(赤矢印)。顧客とできるだけ密にコミュニケーションするには? それもよりシンプルな方法は? 自分たちが顧客とコミュニケーションしたいことって何? これらに一律の答えはなく、自分たちで自分たちの状況に合わせて知恵を絞り、そのやり方そのものを継続的に改善する必要があります。

私に言わせれば、スクラムではこれを「プロダクトオーナー」という役割にしたのです。

ゴールデンサークル

#

そうは言っても多いわ! と思うそこのアナタ! 実は私もそう思います。そんな方にうってつけなのが、以下のゴールデンサークル。Clean Agileに掲載されています。

ゴールデンサークル

一番内側のプラクティスは個人でも適用できるもの、中間の輪っかがチームで適用するもの、一番外側は顧客を巻き込む必要があるものです。まずはこれらを起点に考えるのもよいかと思います。

アジャイルプラクティスメトロマップ

#

逆に、いやいやもっと知りたい、できるだけいっぱい知りたいというアナタには、アジャイルプラクティスメトロマップをどうぞ。これはAgile Japan 2016の際に、印刷して参加者に配布したものです。当時の実行委員で、原作者に許諾を得て英語から翻訳しました。

確か、これに刺激を受けて(かどうかはわからないですが)、某コンサル会社様が、いわゆる大規模アジャイルの手法まで入れた、もっと巨大なマップも作っていた気がします。興味のある方は調べてみてください。すいません、私は一度見て、あまりの膨大さにそっ閉じしました。

次回に続く

#

次回は残しておいた「原則」の話です。

豆蔵デベロッパーサイト - 先週のアクセスランキング
  1. 自然言語処理初心者が「GPT2-japanese」で遊んでみた (2022-07-08)
  2. Tauri でデスクトップアプリ開発を始める (2022-07-08)
  3. Deno による Slack プラットフォーム(オープンベータ) (2022-09-27)
  4. Jest再入門 - 関数・モジュールモック編 (2022-07-03)
  5. ORマッパーのTypeORMをTypeScriptで使う (2022-07-27)
  6. 第1回 OpenAPI Generator を使ったコード生成 (2022-06-04)
  7. 直感が理性に大反抗!「モンティ・ホール問題」 (2022-07-04)
  8. Rust によるデスクトップアプリケーションフレームワーク Tauri (2022-03-06)
  9. 箱ひげ図で外れ値を確認する (2022-05-18)
  10. Nuxt3入門(第1回) - Nuxtがサポートするレンダリングモードを理解する (2022-09-25)