アジャイル

短いイテレーションで動くソフトウェアを継続的に届け、変化に適応する開発手法の総称

開発手法チーム
「アジャイル」の技術書を見る →

アジャイルとは

アジャイルは、短いイテレーションで動くソフトウェアを継続的に届け、変化に適応する開発手法の総称である。2001 年のアジャイルソフトウェア開発宣言で 4 つの価値と 12 の原則が定義され、原則は動くソフトウェアを届ける間隔を数週間から数か月とし、短いほうを好むとしている。

4 つの価値

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

ウォーターフォール vs アジャイル

観点ウォーターフォールアジャイル
計画全体を事前に計画イテレーションごとに計画
リリース最後に一括イテレーションごと
変更コストが高い歓迎する
フィードバック遅い (数ヶ月後)速い (数週間後)
リスク最後に発覚早期に発覚

アジャイルのフレームワーク

スクラムは、スプリントとその中のイベント、チームの 3 つの責任を定めたフレームワーク (2020 年 11 月版のスクラムガイドの語)。カンバンは WIP 制限とフロー重視。XP (エクストリームプログラミング) はペアプログラミングと TDD を重視する。SAFe は大規模組織向けのスケーリングフレームワーク。

スクラムの基本

スプリント (2週間)
  ├── スプリントプランニング (何を作るか)
  ├── デイリースクラム (15分の同期)
  ├── 開発作業
  ├── スプリントレビュー (成果物のデモ)
  └── レトロスペクティブ (プロセスの改善)

アジャイルと CI/CD

アジャイル + CI/CD:
  コード変更 → 自動テスト → 自動デプロイ → フィードバック
  → 次のイテレーションに反映
  → DORA メトリクスで改善を計測

アジャイルのアンチパターン

アジャイルの儀式だけ導入しても形だけで本質がない。スクラムガイドは、スプリント中にスプリントゴールを危うくする変更をしないとし、範囲はプロダクトオーナーと明確にしたり交渉し直したりしてよいとしている。レトロスペクティブを省くと、改善の機会が減る。「アジャイルだから計画不要」は誤解で、計画は必要だが粒度が異なるだけ。

アジャイルの前提条件

アジャイル宣言の原則は、自己組織化するチーム、ビジネス側と開発者が日々一緒に働くこと、技術的卓越性と良い設計への継続的な注意を挙げている。

理論と実装の両面から学ぶなら関連書籍が参考になる。

共有:

この記事は役に立ちましたか?

関連用語

関連する記事