アジャイルソフトウェア開発 (以下アジャイル開発) とは、現実世界で生じた変更にすばやく適応するための軽量なソフトウェア開発手法群の総称である。
アジャイルソフトウェア開発宣言は、アジャイルソフトウェア開発がもつ特徴や価値を明らかにしたものである。
プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、価値とする。
アジャイル開発は従来のウォーターフォールと比較して生産性の高い開発手法と言われる。 しかし、これは誤解を招く表現だ。 そもそも、ウォーターフォール開発とアジャイル開発では生産性を測る指標が異なる。
一定時間に生んだ付加価値 (スクラムにおいてはベロシティ = 1 スプリントで消化したポイント)
スピード (速さ) とベロシティ (速度) は異なる。 速さはスカラーであることに対し、ベロシティはベクトルであり、正しくゴール (= 理想の状態, To-be モデル) に向かうベクトル成分だけを評価する。
以下の理由から、アジャイル開発はウォーターフォール開発にリソース効率性という指標で劣る。
システムは SoR (System of Record) 領域と SoE (System of Engagement) 領域に分けて考えることができる。
記録処理や信頼性を重視するシステム。
基幹系システム, 勘定系システム, CRM (= Customer Relationship Management, 顧客管理) システムなどのミッションクリティカルなシステム
サービスを提供する顧客との繋がりを実現するシステム。
正解がない, PoC (Proof of Concept, 概念実証) を反復して正解を探す必要がある → アジャイル適応
スクラムはこの記事では解説しない。
エクストリーム・プログラミング (eXtreme Programming, 以下 XP) はソフトウェア品質を向上させ、変化する顧客の要求への対応力を高めることを目的としたソフトウェア開発プロセスである。
XP には 3 つの原則があり、12 のプラクティスが以下に示す 4 つにグループ化されて存在する。
時間の経過とともに問題がよりよく理解されたことでの顧客の要求の変化を期待する。
設計を単純にすることは、よりよい問題の理解に繋がり、アジャイルにおける変化する顧客の要求への備えにもなる。
設計の単純性は成功への鍵であり、不必要な複雑性は避けるべきだという主張。
「後で使うだろうという予測の下に作られたものは、実際には 10%しか使われない」
以上の理由から、機能は実際に必要となるまで追加するべきではないという主張。
使用するプログラミング言語でのソースコードの一貫したスタイルと形式を規定する。
プログラムの外部から見た動作を変えずにソースコードの内部構造を整理する。 簡単に行えるソフトウェアテスト (ex. 単体テスト) が整備されなければ、リファクタリングによって新たなバグを作り込んでしまう (デグレード) リスクがあり、結果としてリファクタリングの敷居は大きく上がってしまう。
適応的 (adaptive) の立場をとるアジャイル開発では、開発の成果物に対する、顧客やチーム, システムからのフィードバックまでのリードタイムが短いことを期待する。
設計ミスによる手戻りコストは後工程にいくほど増大するという法則。 設計段階での設計ミスによる手戻りコストを 1 とすると、開発段階では 10、リリース後では 100 と言われている。
ユニットテストを書いたり、定期的に統合テストを実行することで、プログラマーは、変更した後にシステムの状態から直接フィードバックを得ることができる。
プログラムに必要な各機能について、最初にテストを書き、そのテストが動作する必要最低限な実装をとりあえず行った後、コードを洗練させるスタイル。
開発ブランチをメインラインにマージするときの統合の競合や失敗のリスクを小さくするために、メインラインへの統合をより頻繁に行う。 ビルドサーバーが定期的にコードのコンパイルや静的分析, 単体テストや統合テストを実行し、その結果を開発者に報告する。
ソフトウェアのデリバリーは、具体的な価値を生み出す機能の頻繁なリリースを介して行われる。 小さなリリースは、前述の CI や自動テストによる QA コストの削減, CD (Continuous Deployment, 継続的デプロイ) によるデプロイコストの削減が前提となる。
2 人のプログラマが 1 台のマシンを操作してプログラミングを行う手法。 コードを書く人をドライバ、もう 1 人をナビゲータと呼ぶ。 ペアプログラミングを支援するツールとして、Visual Studio Code の Live Share や Floobits などがある。
開発工程で見過ごされた誤りを検出・修正することを目的としてソースコードの体系的な検査を行う。 コードレビューを受ける人をレビューイ、レビューを行う人をレビュアーと呼ぶ。 コードレビューを支援するツールとして GitHub の Pull Request などがある。
この記事の内容はアジャイルソフトウェア開発の一部分であり、参考文献に記したソースを読むことを強くオススメする。