アジャイル開発のプロジェクトマネジメント研修を受けたので、頭の整理をするために
自分なりの解釈も追加して記事にしてみる。
アジャイル開発とは
ビジネスを成功させるため、システムの利用者の満足を最優先とすることを目的とし、
短い間隔で継続してプロダクト、プロダクトの更新をリリースする開発手法を指す。
ここで重要なのは、あくまでも目的はビジネスへの貢献することが目的であること、
その手段として短い間隔でユーザーと開発者が協調して取り組む大切でその特徴をもつ開発手法ということ
開発体制
スタンダードな体制
拡張的な体制
| 登場人物 | 役割 | スキルセット |
|---|---|---|
| ステークホルダー | PJ関係者。プロジェクト責任者、要求を伝えるエンドユーザー、予算担当など | - |
| プロダクトオーナー | プロダクト(システム)の価値を最大化することに責任を持つ。ステークホルダーからの要求を開発者に伝え、優先度を決定を行ったり、開発者の作成物のレビューを行う | アジャイル経験あり推奨。 業務を理解しており、成果物のレビューが行えるスキルを持っている。 |
| 開発者 | 作成物のリリースに責任を持つ。プロダクトオーナーから要求をタスクに分解する。要求を形にしてリリースを行う。 | 要件整理、設計、開発、テスト等一人で完結して行える。アジャイル経験あり。 ユーザーとの会話が行える。 |
| スクラムマスター | スクラムの推進に責任をもつ。スクラムとしてのプロジェクトの推進に対してPO、開発者へ助言を行う | アジャイル開発の現場経験あり。アジャイルを理解している。 |
| PO補佐 | POの補佐を行う。 具体的には要求のまとめ、要求の優先順位つけの補佐、作成物のレビュー観点など |
クライアントの業務を理解している。基本的な開発知識がある。 |
| プロジェクトマネージャー | プロジェクトマネジメントを行う。スケジュール管理、リスク管理、期待値調整など。 | アジャイル経験あり。PM経験あり。 |
開発手法
短い間隔で、継続的にプロダクトに対する開発、テスト、更新を行う。1つの対応対象の選定からフォードバックまでの流れをスプリントと呼ぶ。
顧客からの要求(ユーザーストーリー)をもらい、
それの優先順位つけを行い、優先順位の高いものから対応してく流れ。
ユーザーストーリーを実現するためのタスクをプロダクトバックログといい、開発者はユーザーストーリーをプロダクトバックログに分解し、それを対応していく。
以下はアジャイル開発の1つのスプリントスケジュール例。この例では1つのスプリントが1週間で設定されている。
流れとしては、まずはスプリントプランニングで本スプリントで対応するユーザーストーリーを選定し、それに対して開発を行っていく。最終日のスプリントレビューでエンドユーザーのレビューを行い、問題なければ本番リリース、フィードバックとなる。朝会は進捗確認。
POのレビューはスプリントレビューまでには完了している必要があるため、実質的には開発期間は3，4日ほどとなる。上記以外の時間は設計、開発、テストに開発者は充てている。
少し視点が異なるが、PO側(クライアント側)もアジャイルを実施するにはかなりの工数を必要とするが、一緒に学習していけるというメリットもある(ウォーターフォールだとできるまでなげっぱなしなので、クライアントが製品の仕様を理解できないままPJがおわることも)
ウォーターフォールとの比較
| アジャイル | ウォータフォール | |
|---|---|---|
| 要求の変更への対応 | 対応可能 | 対応が難しい |
| 向いているPJ | 新しい技術を使ったり、実現が不確実なPJに最適 | 枯れた技術を用いて、期限重視のPJに最適 |
| 要求される人材 | 要件整理からリリースまで独力で行える人材(同じ人が対応するため、共有用のコミュニケーション、ドキュメント作成の工数を軽減) | 要求されるスキルを持った人材が網羅されていればOK(設計、開発で異なる人材を起用可能) |
| テスト | テスト自動化必須 | テストは自動でも手動でも問題ない |
| クライアント側で必要な工数 | 多い | 少ない |
| クライアント側のプロダクトへの理解度 | 高い | 低い |
| クライアント側の満足度 | コミュニケーションを多くとり、都度要求の変更が可能なため満足度が高い傾向がある | リリース直前までプロダクトが見えないため、満足度のばらつきがある |
感想をだらだらと
・テスト自動化が肝、自動化できない、自動化に過剰な工数がかかるプロダクトはアジャイルが向いていない気がする(更新を行ったプロダクトに関しては、以前の要件に関しても満たすつくりになっているかの確認も必要なため、以前までに行っているテストもすべて行う必要がある)
・高い開発スキルをもつ開発者でないと実現できない
・エンジニアに優しい開発手法、委託というよりも社内開発に向いているかも
・基盤側でやる場合IaCが必須？テスト自動化が必要なので、テストコードを書く必要がある。ただその場合、運用フェーズでエンドユーザーがIaCで書いたコードを運用していけるかという部分がある。
・自分の周りのPJだとレポート開発が向いているかも(その場合レポートのテスト自動化が必要)
ここら辺のことをやることになり、サードパーティ製品が必要となる可能性がある
https://learn.microsoft.com/ja-jp/power-bi/guidance/powerbi-implementation-planning-content-lifecycle-management-validate#automate-testing
・ウォーターフォールに比べてアジャイルの方がテストを何倍も行うので、特に継続して更新がかかるプロダクトについては品質が上がりそう
・ウォーターフォールはテストが後にあるのでリスクが後に延びがちだが、アジャイルは先にリスクが高く価値が高いものから対応、テストしていくのでリスクの顕在化と解消が早い傾向があるかも
・とはいえ期限内に必ず終わらせたいというユーザー目線、エンジニアの立場が他国に比べて弱いと聞く日本ではアジャイルが一般的になるのはまだ先になるのかも
・アジャイルを行うとなるとテストの自動化と一連托生になり、後続で利用できるコード資産が増え共通化も行いやすそう。その意味でもいつかアジャイル開発できる機会があればやってみたい
・アジャイル開発やるやらないに関わらず、インセプションデッキは提案などに使えそう