よんログ

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

#勉強ノート#アジャイル開発#開発手法
2021年1月12日12 min

アジャイルソフトウェア開発 (以下アジャイル開発) とは、現実世界で生じた変更にすばやく適応するための軽量なソフトウェア開発手法群の総称である。

特徴

  • 開発対象を多数の小さな機能に分割し、反復のサイクルを繰り返すことで 1 つずつ機能を追加的に開発していく。
    • この反復をエクストリーム・プログラミング(後述)ではイテレーション、スクラムではスプリントと呼ぶ。
  • 1 つの反復で 1 つの機能を開発する
  • 各々の反復で、計画, 要求分析, 設計, 実装, テスト, 文書化といった、ソフトウェアプロジェクトの工程を 1 つの反復内で行う。
  • 各反復が終了するごとに、機能追加された新しいソフトウェアをリリースすることを目指す。
  • 各反復が終了するごとに、プロジェクトタスクの優先度を評価しなおす。

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

アジャイルソフトウェア開発宣言は、アジャイルソフトウェア開発がもつ特徴や価値を明らかにしたものである。

プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、価値とする。

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

ウォーターフォール開発との比較

アジャイル開発は従来のウォーターフォールと比較して生産性の高い開発手法と言われる。 しかし、これは誤解を招く表現だ。 そもそも、ウォーターフォール開発とアジャイル開発では生産性を測る指標が異なる。

ウォーターフォールの指標
チームの忙しさ (= リソース効率性)
アジャイルの指標

一定時間に生んだ付加価値 (スクラムにおいてはベロシティ = 1 スプリントで消化したポイント)

スピード (速さ) とベロシティ (速度) は異なる。 速さはスカラーであることに対し、ベロシティはベクトルであり、正しくゴール (= 理想の状態, To-be モデル) に向かうベクトル成分だけを評価する。

以下の理由から、アジャイル開発はウォーターフォール開発にリソース効率性という指標で劣る。

  • 1 つの反復で 1 つの機能を開発するアジャイル開発では、メンバーが常に何らかのタスクをもっている状態をキープすることが難しい → リソース効率性の低下
  • 各反復が終了するごとに、機能追加された新しいソフトウェアをリリースすることで、追加の QA (Quality Assurance = 品質保証) コストやデリバリーの作業コストがかかる。

アジャイル開発が向いているシステム領域

システムは SoR (System of Record) 領域と SoE (System of Engagement) 領域に分けて考えることができる。

SoR

記録処理や信頼性を重視するシステム。

価値
信頼性
可用性
MTBF (= Mean Time Before Failure, 平均故障間隔)
MTTR (= Mean Time To Repair, 平均修復時間)
開発サイクルの長さ
数ヶ月〜数年
例

基幹系システム, 勘定系システム, CRM (= Customer Relationship Management, 顧客管理) システムなどのミッションクリティカルなシステム

適正
正解 (仕様) が決まっている → ウォーターフォール適応

SoE

サービスを提供する顧客との繋がりを実現するシステム。

価値
処理速度 (スループット)
利便性 (ユーザ体験, UX = User eXperience)
開発サイクルの長さ
数日〜数週間
例
銀行のフロントシステム
適正

正解がない, PoC (Proof of Concept, 概念実証) を反復して正解を探す必要がある → アジャイル適応

アジャイル開発手法の実例

  • スクラム
  • エクストリーム・プログラミング

スクラムはこの記事では解説しない。

エクストリーム・プログラミング

エクストリーム・プログラミング (eXtreme Programming, 以下 XP) はソフトウェア品質を向上させ、変化する顧客の要求への対応力を高めることを目的としたソフトウェア開発プロセスである。

原則とプラクティス

XP には 3 つの原則があり、12 のプラクティスが以下に示す 4 つにグループ化されて存在する。

変化を受け入れる

時間の経過とともに問題がよりよく理解されたことでの顧客の要求の変化を期待する。

シンプルさを前提に

設計を単純にすることは、よりよい問題の理解に繋がり、アジャイルにおける変化する顧客の要求への備えにもなる。

KISS (Keep it simple stupid) の原則

設計の単純性は成功への鍵であり、不必要な複雑性は避けるべきだという主張。

YAGNI (You ain't gonna need it)

「後で使うだろうという予測の下に作られたものは、実際には 10%しか使われない」

「余計な機能があると、仕事が遅くなり、リソースを消費する」

以上の理由から、機能は実際に必要となるまで追加するべきではないという主張。

コーディング規約

使用するプログラミング言語でのソースコードの一貫したスタイルと形式を規定する。

#コード規約反逆のリリース - Twitter 検索 / Twitter

リファクタリング

プログラムの外部から見た動作を変えずにソースコードの内部構造を整理する。 簡単に行えるソフトウェアテスト (ex. 単体テスト) が整備されなければ、リファクタリングによって新たなバグを作り込んでしまう (デグレード) リスクがあり、結果としてリファクタリングの敷居は大きく上がってしまう。

「早すぎる最適化は諸悪の根源である」
ドナルド・クヌースによる、早すぎる段階での最適化を戒める言である。

フィードバック

適応的 (adaptive) の立場をとるアジャイル開発では、開発の成果物に対する、顧客やチーム, システムからのフィードバックまでのリードタイムが短いことを期待する。

手戻りコストの法則

設計ミスによる手戻りコストは後工程にいくほど増大するという法則。 設計段階での設計ミスによる手戻りコストを 1 とすると、開発段階では 10、リリース後では 100 と言われている。

システムからのフィードバック

ユニットテストを書いたり、定期的に統合テストを実行することで、プログラマーは、変更した後にシステムの状態から直接フィードバックを得ることができる。

テスト駆動開発

プログラムに必要な各機能について、最初にテストを書き、そのテストが動作する必要最低限な実装をとりあえず行った後、コードを洗練させるスタイル。

CI (Continuous Integration, 継続的インテグレーション)

開発ブランチをメインラインにマージするときの統合の競合や失敗のリスクを小さくするために、メインラインへの統合をより頻繁に行う。 ビルドサーバーが定期的にコードのコンパイルや静的分析, 単体テストや統合テストを実行し、その結果を開発者に報告する。

顧客からのフィードバック
小さなリリース

ソフトウェアのデリバリーは、具体的な価値を生み出す機能の頻繁なリリースを介して行われる。 小さなリリースは、前述の CI や自動テストによる QA コストの削減, CD (Continuous Deployment, 継続的デプロイ) によるデプロイコストの削減が前提となる。

チームからのフィードバック
ソースコードの共同所有
すべてのコードに対してすべての人が責任を負う。
ペアプログラミング

2 人のプログラマが 1 台のマシンを操作してプログラミングを行う手法。 コードを書く人をドライバ、もう 1 人をナビゲータと呼ぶ。 ペアプログラミングを支援するツールとして、Visual Studio Code の Live Share や Floobits などがある。

コードレビュー

開発工程で見過ごされた誤りを検出・修正することを目的としてソースコードの体系的な検査を行う。 コードレビューを受ける人をレビューイ、レビューを行う人をレビュアーと呼ぶ。 コードレビューを支援するツールとして GitHub の Pull Request などがある。

最後に

この記事の内容はアジャイルソフトウェア開発の一部分であり、参考文献に記したソースを読むことを強くオススメする。

参考文献

前の記事

Google を支える技術

次の記事

検索システム