アジャイル開発とプロセス評価
アジャイル開発は、要求の変化を前提として、短い期間の反復で動くソフトウェアを作り、顧客や利用者のフィードバックを得ながら開発を進める考え方である。代表的な手法にスクラムがあり、そのほかペアプログラミングやローコード開発などの実践がある。また、開発組織やプロジェクトのプロセスを評価する枠組みとしてCMMIがあり、開発手法とは区別して理解する必要がある。
イテレーションの目的
イテレーションは、短い期間で計画、開発、評価を繰り返す進め方である。その目的は、動くソフトウェアを早い段階で顧客に確認してもらい、顧客の要求とのずれを短いサイクルで解消することにある。 また、要求が変化した場合にも、次のサイクルで柔軟に対応できる点が特徴である。
同じ論点は別の年度でも問われており、顧客の要求との不一致の解消と要求の変化への柔軟な対応が目的として示されている。 一方、タスクの進捗を見えるようにすることや、毎日決まった時刻に集まって状況を共有することは、イテレーションそのものの目的ではない。これらはタスクボードやデイリースクラムなどの実践が担う役割であり、問題の早期発見に役立つ点は共通するものの、主目的とは区別する必要がある。
スクラムの役割・イベント・成果物
スクラムは、プロダクトオーナーなどの役割、スプリントレビューなどのイベント、プロダクトバックログなどの成果物、およびそれらを定めるルールから成る開発のフレームワークである。 役割としては、プロダクトオーナーがゴールやミッションの達成に向けて、プロダクトバックログのアイテムの優先順位を決定する。
一方、スクラムマスターはチームのコーチやファシリテーターとしてスクラムの理解と実践を支援する役割を担う。開発者はプロダクトの具体的な作り方や作業計画を専門性に基づいて決め、リリース判断に使えるインクリメントを作成する。役割ごとの責任範囲を取り違えないことが判断の基準になる。
スプリントの振り返りには、KPT手法が用いられることがある。Kは続けたい良い点、Pは問題点、Tは次に試す具体的な改善策を表す。 実務では、Pとして挙がった問題に対し、次のスプリントからの具体的な行動をTとして決めて試すことで、改善が次の反復に結びつく。
この節の続き
- 実践手法の特徴
- プロセス評価の枠組み(CMMI)
- 試験で問われやすい区別
ここまでが冒頭部分です。ログインすると、無料でも1日2節まで全文をお読みいただけます。
アプリでこの節を読む