開発効率を最大化する方法：プログラミングの基礎知識

システム開発を効率化する手法に、XPというアジャイル開発の一つの手法がある。
このXPとアジャイル開発について調べてみた。

XP

XPとはeXtreme Programmingの略。
1999年にケント・ベック氏らによって提唱。
extremeとは「最大化する」という意味。

XPを実現するために、４つの価値と１２のプラクティスが示されている。

４つの価値

コミュニケーション

チーム内で緊密なコミュニケーションをとることこそ、プロジェクトの成功につながる。ここでのコミュニケーションは直接対面することが前提。

シンプル

実装は可能な限りシンプルに保つことが要求される。将来の要求を予測して現段階では不要な機能は実装してはいけない。
コードをシンプルに保つことで要求が現実化したときにすぐに対応できる柔軟性を重要視する。

フィードバック

実際に動作するソフトウェアをユーザに使用してもらって得られるのが、もっとも価値の高いフィードバック。
ユーザは実際のソフトウェアを見ることで要求が正しく実装されているかを確認でき、また進捗を知ることもできる。
ユーザに頻繁にリリースを行うことが重要。なぜならフィードバックが早ければ早いほど容易に適確な対処ができるから。

勇気

よりよい設計はなにかを常に考え、時には方向転換を決断しなければならない。スケジュールを常に意識し、作業の調整が必要になることもある。判断・決断を行うときに必要なのが「勇気」。
勇気を持って行動できるように、判断に必要な情報を十分に収集することや、不安があるときにはその不安を解消するために全力を尽くすことを示している。

１２のプラクティス

計画ゲーム：次期リリースの計画を早急に立案

小規模リリース：小規模な部分ごとにシステムの運用を開始

比喩：システムの機能をチームに理解させるため比喩を示す

シンプルデザイン：出来るだけシンプルな設計

テスティング：継続的にテストのためのプログラムを作成

リファクタリング：機能を変えず、ソースコードの可読性を高める

ペアプログラミング：２人で１台のPCを使い協力してプログラミング

共同所有権：チーム全員がすべてのソースコードを修正できる

継続的インテグレーション：何度も修正とコンパイルを繰り返し、テストを合格させる

週40時間：週４０時間以上は働かない。無理をしない。

オンサイト顧客：ユーザの意見を聞きながら、ユーザと一緒に開発

コーディング標準：チームｓｗソースコードの書き方を統一、なぜその基準なのかの理解が重要

アジャイル開発

アジャイル開発は効率的なシステム開発を実現する手法の総称。
アジャイル（agile)は「機敏な」という意味。

アジャイルソフトウェア開発宣言

以下の４項目からなる。

方法論やツールより、人と人との触れ合いを重視する。
ドキュメントより、実際に動作するプログラムを重視する。
契約より、お客様との協力関係を重視する。
計画に従うより、変化に対応することを重視する。

アジャイルソフトウェア開発に対する誤解

× アジャイルだからドキュメントは書かない

アジャイルソフトウェア開発宣言に、
「ドキュメントより、実際に動作するプログラムを重視する」
とあることから、ドキュメントは軽視すると考えられがちだが、この考えは誤りである。
実際には、アジャイル開発者はドキュメントを大切にしており、
オブジェクト開発の神髄?UML 2.0を使ったアジャイルモデル駆動開発のすべて
の中でも、
「どんなシステムにもドキュメントは本質的な部分として含まれます。アジャイルソフトウェア開発手法で作られたシステムでも同じです。」
と宣言している。
ドキュメントは、

- 中間成果物ドキュメント（要求定義→設計→実装→テストといったいわゆる「開発工程」の区切りに作成されるドキュメントのこと）
- ソースコードとテストコード
- 利用者向けドキュメント
- コンプライアンス目的ドキュメント
- ロゼッタストーンドキュメント（ソースコードやテストコードだけでは理解しづらい開発対象システムの全体像の把握につながるもの、システムを理解するとっかかりとなる文章やダイアグラムを記述）

がある。この中で、中間成果物ドキュメントを削減すべきだが、他のドキュメントは必要である。

ソースコードがドキュメントの注意点

コードがドキュメントとして役に立たないのは，プログラマがコードのことを真剣にドキュメントとして扱っていないから。スタイルを統一すること，クラスやメソッドに適切な責務を割り当て，よい名前を選ぶこと，意図を明確に表現する単位でメソッドを記述すること、など。プログラムを書く際に「このコードはドキュメントとして通用するか？」を自問することは重要。