アジャイル開発が流行る中で、一番初めに流行りが来た手法です。
最近ではすっかりスクラムの方が流行っていますが、スクラムよりも組織論のよりも開発チームに近いので、最初に導入したり、考え方を理解するのには向いているかもしれません。
基本的にアジャイル開発なので、スクラムの手法の中にも似たようなものも多くあります。
原則
４つの価値
- コミュニケーション
- 単純さ
- フィードバック
- 勇気
の４つに最大の価値を置く。
これは他のことに価値が無いということではないので
選択を迫られたときにどちらがこの価値基準に近いのか？
ミーティングなどで小さなリスクや小さな問題、課題を攻め立てて変えることを止める人がいるが
この勇気や単純さ(シンプル)に従って実行するべきかを判断すれば、ちゃんと共通した答えが出せるはずです。
5つの基本原則
- 素早いフィードバック
- 単純さの採用
- インクリメンタルな変更
- 変化を取り込む
- 質の高い作業
XPはこの原則が一番のポイントになる。
その中で、まだアジャイルな考えを取り込めていない組織の中で重要なものは
「変化を取り込む」ということと「勇気」をもつこと、そして変化へのゴールが「質の高い作業」になっているかというチェックだと思っています。
正直、この考えに沿っていれば、どんな状況も、どんな判断であっても、どんな方法を使っても良いと思っています。
ただ、まだ何も試せていない状況ではどんなことから始めていけば良いのかわからないと思いますので
ここでXPのプラクティスの幾つかを紹介します。
XPのプラクティス
計画ゲーム(ストーリーの作成、リリース計画)
○○が○○出来る。のような短い機能の概要をストーリーとして上げていきます。
例を挙げると「ユーザ管理機能」と言う風に上げるのではなく
- ユーザー情報一覧を表示できる。
- ユーザー情報を検索することが出来る。
- ユーザー情報を登録することが出来る。
- ユーザー情報を編集することが出来る。
このように書くことが出来ます。もし、ここに権限管理がちゃんとあるときには
- 管理者はユーザ情報を編集できる。
- ユーザは自分のユーザ情報を編集できる。
のように、別々の機能になります。
そして、上の機能一覧では削除が書かれていないので、削除機能はタスクに入っていません。
開発計画のフェーズによりますが、開発チームに作業を渡すときにはこのレベルで渡す必要があると思います。
また、このストーリーをもとに開発者と一緒にリリースの計画を作ります。
リファクタリング
機能の変更はなく、よりよいコードに変えていくことです。
そうすることで、システムの柔軟性やメンテナンス性を上げて、バグの発生率や機能追加のコストを下げることが出来ます。
コードが具体的にそろってきたり、業務の知識が増せばよりよいクラス設計が思いつきますし、機能追加などでさまざまなものが追加されてば、ツギハギの部分も出てくるため整理もしたいです。
また、何もしなくても開発のソースコードは時代が進めば新しいライブラリが生まれたり、よりよい書き方や方法が見つかっていくものです。
そして、動いているフレームワークやライブラリ、ミドルウェアのバージョンのメンテナンスなども終わっていきます。
アプリケーションを継続的に良くしてくためにはリファクタリングは必要なものです。
これらは技術的負債の一部です。技術的負債は解消していくべきですが、以前にこちらの記事で色々書いたので読んでもらえたらと思います。
ペアプログラミング
２人でコードを書くことです。１人がコードを書き、もう１人がどういうコードにするべきかを考えながら進めます。
開発スピードが下がるかどうかは微妙なラインです。最初からバグが少なく、書き直しが少ない良いコードが完成すれば、結果的に開発スピードが上がることがあります。
ただ、開発の内容とプログラマのレベルによっては開発スピードが下がります。
タイミングやフェーズ、チームなどさまざまなものを見て導入するべきか考えましょう。
それでも、１度はやってみて体験するべきものかと思います。
プログラミングは１人の世界でやることが多いですが、人の考え方、開発の進め方などを理解すると、その後の開発スピードが格段に上がることがあります。
特にテスト駆動開発などの手法を導入する際は、どのように進めるのかを具体的に見せたりしたほうが理解が早いと思います。
最近ではGitHubなどコードをプルリクエストを出して、その場でレビューコメントがつけられるものが広がってきたため、積極的にペアプログラミングすることなく、コード品質に対する意識を上げれるようになったと思います。
ソースコードの共同所有
意識の問題です。誰かが書いたコードが自分のコードに影響をあたえることはしばしばあります。
また、クラス設計のなかで、まとめたほうが良い処理、インターフェイスをそろえたり、変えたり、そのようなことはよく起きます。これが誰が書いたからと責任を押し付けていては結果的にコード全体を見たときにバラバラのコードの構成になり、トータルで品質の低いソースコードとなってしまうことがあると思います。
良いところはどんどんよくして、悪いところはどんどん直してよいです。
全員でそのプロダクトを良くしていくのです。
GitHubなどのレビューも同じです。
レビューコメントが相互につかないチーム状態はたいていコード品質も低いです。
みんなでよりよい方法を考え、みんなで成長をしましょう。
テスト駆動開発
テストを書いてから実装をする方法です。
AdventCalendarの前の日にも書きました。
テストを書いてインターフェイスを先に定義することで、使いやすいメソッドを定義できるメリットもあります。
継続的インテグレーション(CI)
これもAdventCalendarの前の日に書きました。
そちらのほうが詳しいと思いますので、そちらを参照下さい。
YAGNI You Aren't Going to Need It(今、必要なことだけする)
将来こんな機能が必要なのでは？こういう機能も作られることになるのでは？これがあったら便利では？
そう思うこともよくあります。でも、作る必要はありません。そう思ったことの８割は作られることはありません。
理由は簡単です。コストと見合わないことが多いからです。
今必要な機能に注力しましょう。
ただし、将来の仕様の追加や変更に柔軟な作りにしておくために、欲しい機能を想像することはとても良いことだと思います。
まさに何も考えずに今の機能だけを考えると、コードが硬くなってしまいがちです。
考えることはするけども、実装は必要な分だけ。
これが一番いいバランスだと考えています。
イテレーション
開発のサイクルを回すことです。
部分的に設計・実装・テストを行い、常に動く半完成品システムの状態を維持することです。
大抵１回のイテレーションは１，２週間になります。
締め
主に開発チームの行うプラクティスを中心に紹介しました。
この他に顧客や管理者などの概念も出てくるので、興味がある方はもっと深く勉強してみて下さい！
また、技術的負債については個人的に非常に興味がありますので、文中にもありましたが、こちらも読んでもらえると嬉しいです。
技術的負債と戦わずにマネジメントする