Table of Contents
アジャイル開発の世界
ユーザーに取って必要なソフトウェアであり続ける為に
タイムリーな開発を実現する為には企画と開発が一体となりユーザーに取って価値のあるものを創造していくことが必要。
アジャイル開発は改善することが前提
アジャイルでは短い期間でリリース → フィードバックで改善するサイクルが基本。
アジャイルの一流派であるスクラム開発では通常1 ~ 4週間の一定の期間(スプリント)を開発サイクルとしている。(=その期間でソフトウェアが動くところまで開発を進める)
アジャイル開発の価値観
下記が2001年にまとめられたアジャイル開発宣言の内容。
「AよりもB」をという形式だが、Aの概念が不要である価値観ではないことに注意する。(= アジャイル開発でもドキュメントや計画が必要な場合も存在する)
- プロセスやツールよりも個人と対話を
- 包括的なドキュメントよりも動くソフトウェアを
- 契約交渉よりも顧客との協調を
- 計画に従うよりも変化への対応を
なぜアジャイル開発なのか
従来の開発手法「ウォーターフォール」
概要
下記の図の工程通りに進行する為、進歩の確認が容易である。
また、工程が完全に分離されている為明確な役割分担がしやすい。
要件定義
顧客がソフトウェアを利用して達成したい事を「要求」と呼ぶ。
そして、この「要求」を実現する為に必要な機能や性能が「要件」。
- 機能要件：開発対象に求められている機能
- 非機能要件：性能や品質などに対する要件
設計と実装
基本設計：要件定義に基づいてユーザーが直接触れる部分の設計を行う。
詳細設計：ソフトウェア内部構造を決定する。
工程の切り替え
各工程で作り上げたものを正確に伝える為に詳細なドキュメントが作成される。
アジャイルとウォーターフォールの違い
ウォーターフォールでは各工程での成果物を完成品とみなしており、後工程での出戻りが発生しないようになっている。
アジャイルでは一定のスプリント毎に動くソフトウェアが作成され、次のスプリントではそのソフトウェアから得られた気づきを元に要件レベルから見直しが行われる。
アジャイルの利点
- ソフトウェアの本当に必要なものに気づく
- コミュニケーションの不確実性等のリスクを減らす
- プロダクトの不必要部分を切り取ることができる
アジャイル開発がもたらす変化
職能横断型チーム
自己組織化チームとリーダーシップ
自己組織化チームとは自走できるチーム。
- 共通ビジョンの元、自ら判断し動くことができる
- 必要なスキルを保有し、また必要となるスキルを自ら身に着けることができる
- 想定外の自体に自ら判断し対応することができる
自己組織化チームとマッチするリーダーシップスタイルは「サーバントリーダーシップ」(=支援型リーダーシップ)
アジャイル開発の中核にあるコンセプト
アジャイル開発の3つのコンセプト
アジャイルチームに必要な役割
