アジャイル開発の具体的な進め方2022

2022年版 アジャイル開発の進め方 クラスメソッド株式会社 CX事業本部 藤村 新

プロセスの 全体像

(出所)『Chose Your WoW!』

方向づけ (要件定義フェーズ)

(出所)『Chose Your WoW!』

共通ビジョンの策定 •やること •キックオフMTG •インセプションデッキ •成果物 •インセプションデッキの結果など

スコープの探索 •やること •ユーザーストーリーマッピング •成果物 •プロダクトバックログの叩き台 •見積もられていない状態 •フェーズの定義 •MVPなど •フェーズごとのプロダクトゴール

ユーザーストーリーマッピング

ユーザーストーリーマッピング

プロダクトバックログ

リリースの計画 •やること •プランニングポーカー •PBIの相対見積もり •成果物 •プロダクトバックログ •全体のボリューム(フェーズごと) •リリース計画

リリースの計画

アーキテクチャー戦略の特定 •やること •技術アーキテクチャのモデリング •SaaS(Shopifyなど)含む •方向づけフェーズではMVPフェーズのスコープのみ •API設計 •UIフロー/ワイヤーフレーム検討 •成果物 •ドキュメント •クラウドアーキテクチャ図 •MVPフェーズの機能のAPI I/F仕様書(Swaggerなど) •MVPフェーズの画面遷移、画面仕様書(フェーズごと)

画面遷移、画面仕様書(フェーズごと) MVP

画面遷移、画面仕様書(フェーズごと) MUST (参考)

画面遷移、画面仕様書(フェーズごと) ADDITIONAL (参考)

エンタープライズの方針との整合 •やること •ツール、サービスの選定、アカウント準備 •Git、AWSアカウント、CI/CD、… •SaaS(Shopifyなど) •アプリ配布用(App ID、Ad Hoc証明書) •ドキュメントのテンプレート採用 •成果物 •開発で必要なツール、サービス •合意したドキュメントのテンプレート

ドキュメントのテンプレート

ドキュメントのテンプレート

ドキュメントのテンプレート

ドキュメントのテンプレート

テスト戦略の立案 •やること •テスト強度、アプローチ(ブラックボックス等)の合意 •テスト対象の合意 •端末、OSバージョン、ブラウザなど •テスト仕様書の認識合わせ •成果物 •テスト強度、テストアプローチ、テスト対象などを定 義したドキュメント •合意したテスト仕様書のフォーマット

テスト戦略の立案

テスト戦略の立案

テスト戦略の立案

チームの形成 •やること •チームビルディング •可能であればベトナムで実施 •進め方の認識合わせのためのMTG •成果物 •自己組織的なワンチーム •MTGスケジュール

チームの形成

その他 •やること •プレ・スプリント •DoD(完成の定義)の叩き台作成、合意 •Acceptance Criteriaの例作成、合意 •成果物 •動くソフトウェアを1〜2週間でリリース できる環境 •DoD、Acceptance Criteriaの例

構築

プロジェクト の一週間

スプリントレビュー デイリースクラム デイリースクラム デイリースクラム デイリースクラム レトロスペクティブ スプリントの切れ目 プロダクトバックログ リファインメント スプリントプランニング (1部) スプリントプランニング (2部) ベトナムチームでの レトロスペクティブ

水曜日 •定例MTG(10時〜13時30分) •アジェンダ •スプリントレビュー •レトロスペクティブ •スプリントプランニング(1部) •スプリントで実施するPBIを選択 •その他議題があれば議論する •Zoomを使ったビデオ会議

スプリントプランニング(1部)

水曜日 •スプリントプランニング(2部) •TLがPBIの仕様をエンジニアへ説明し、質疑応答 •開発チームがPBIをタスク分割、タスク見積もり •タスク分割した結果とキャパシティをPOに報告 •スプリント開始

スプリントプランニング(2部)

スプリントプランニング(2部)

スプリントプランニング(2部)

木曜日〜火曜日 •デイリースクラム •バーンアップチャートをベースに進捗を共有 •問題があればその場で共有 •必要に応じて二次会を開催 •スプリント

デイリースクラム

スプリント

月曜日 •プロダクトバックログリファインメント •次回のスプリントの対象PBIがREADYかを確認 •POが追加したPBIの説明、見積もり •各PBIの優先順位の入れ替え •サイズの大きいPBIの分割

プロダクトバックログリファインメント

水曜日 •定例MTG(10時〜13時30分) •アジェンダ •スプリントレビュー •実機でのデモ •フィードバック収集 •テストレポート共有 •レトロスペクティブ •KPT •スプリントプランニング(1部) •その他議題があれば •Zoomを使ったビデオ会議

スプリントレビュー

スプリントレビュー

スプリントレビュー

スプリントレビュー

スプリントレビューのデモで初 • めて機能を見てもらい、その場 で判断してもらうのではなく、 事前に配信しておく事が重要

レトロスペクティブ

オフショアで 工夫した点

チーム体制

オフショアだから工夫した点 •2部制でのスプリントプランニング •PO交えたβチームでPBIの選択(1部) •αチームでスプリントバックログ作成(2部)

オフショアだから工夫した点 •母国語を使ったレトロスペクティブ •αチーム内で先行して実施(ベトナム語) •βチームのレトロスペクティブで共有(日本語)

オフショアを機能させる

SMの役割例 • スクラムチームαの進捗を妨げるあらゆる障害物の排除 • スクラムチームαをブラックボックスと考える • クライアントが担うPOのあらゆる支援 • スクラムの理論、プラクティスの説明 • プロダクトバックログの管理支援 • POの不安、不満を早めに察知し、スクラムチームα に改善を働きかける • POの先にいるステークホルダーへの説明 • スクラムチームβのスクラムイベントファシリテート

オフショアの開発チームを指導できる

アーキテクトの役割例 • リファインメント • PBI毎の技術的確認事項をクライアントと調整 • スプリントプランニング(1部) • どのPBIまで着手できそうかの目安の共有 • クライアントからの技術的な質問への回答 • スプリントプランニング(2部) • PBI毎に作成した技術仕様をエンジニアに説明 • エンジニアからの質問に回答

アーキテクトの役割例 • スプリントレビュー • スプリントでの成果として、PBI毎にデモを実施 • スプリント期間中 • 次スプリントで対応予定のPBIの技術仕様をWikiなどに記載 • ベトナム開発パートナーのエンジニアからの質問に回答 • ベトナム開発パートナーがデプロイしたPBIを確認 • 確認して問題なければ、クライアントにPBI完成報告 • クライアントからのフィードバック確認、対応

お客様のPOに 期待すること

プロダクトバックログの管理 •PBI(プロダクトバックログアイテム)≒機能を明確に表現頂く •PBIの背景からご説明頂く •PBIの優先順位を明確に決定頂く •優先順位を決める上で参考にする見積もりは開発チームが行う •変化に応じて、PBIの追加、削除、優先順位の変更を随時行う •新しいPBIを追加する場合は、他のPBIの優先順位が下がると いうトレードオフでご検討頂く

セレモニーへの参加 ■スプリントプランニング(第1部) - スプリントプランニング(第一部)への参加 - 1時間/週 - 開発チームが選択した当スプリントで対応するPBIに対するフィードバック、合意形成 ■スプリントプランニング(第2部) - 開発チームがスプリントプランニング(第2部)で作成した計画(タスクと合計見積もり時間)の確認、承認 ■デイリースクラム - 毎日のデイリースクラムへの参加 - 15分×4日＝1時間/週 - 開発チームからの進捗、要望に対するフィードバック - チームに関係するビジネストピックの共有 ■スプリント期間中 - 開発チーム、スクラムマスターからの質問(テキストチャット)に対して可能な限り早めの回答 - 開発チームが順次開発、デプロイしたPBIの動作確認、フィードバック記載 - Backlogなどのチケットへのフィードバック記載を想定

セレモニーへの参加 ■スプリントレビュー - スプリントレビューへの参加 - 1時間/週 - 可能であれば、プロダクトオーナー自らがステークホルダーに対してデモを実施 - 難しい場合は開発チームが行うデモに対してフィードバック - 集まったフィードバックの判断 - 意見として聞くが、プロダクトには取り込まない - プロダクトに取り組む - プロダクトバックログにPBIとして追加 - その際の優先順位の決定 - 各PBIの完成の判断 - スプリントの成果を元に、全体リリース計画のアップデート - 必要に応じて対策をスクラムマスター、開発チームと協議

セレモニーへの参加 ■スプリントレトロスペクティブ - スプリントレトロスペクティブへの参加 - 1時間/週 - 良かった点、問題点、改善点の意見だし - 他のメンバーからのフィードバック確認 ■プロダクトバックログリファインメント - プロダクトバックログリファインメントへの参加 - 1時間/週 - プロダクトバックログ全体をスクラムマスター、開発代表者とともに確認、整理 - 新規PBIがある場合は優先順位の決定 - 優先順位が高いPBIに対しては、着手可能かの確認、可能でない場合は着手可能にするための検討 - 必要に応じて全体リリース計画のアップデート - 必要に応じて対策を協議

以上