Scrum の用語やルールとかをまとめてみました。他のアジャイル開発の開発手法の情報とメリット・デメリットもまとめてるので、どの開発手法を採用しようか悩んでる方は参考までにどうぞ。
アジャイル開発とは？
- 関係者は目的の達成のためにお互いに協力し合いながら開発を進める。
- 利用者の反応や関係者からのフィードバックを継続的に得ながら、計画を調整する。
- 一度にまとめてではなく、少しずつ作る。そして実際に出来上がったものが求めているものと合っているかを頻繁に確認する。
アジャイル開発の前提
事前に全てを正確に予測し、計画することはできない。
Scrum とは？
- アジャイル開発の1つ
- 作業、会議、成果物を定めたもの（フレームワーク）
Scrum の特徴
- 要求を常に順番に並べ替えて、その順にプロダクトをつくることで成果を最大化する。
- 実現されている価値やリスクや必要性を基準にする。
- 固定の短い時間に区切って、作業を進める。（＝タイムボックス）
- 現在の状況や問題点を常に明らかにする。（＝透明性）
- 定期的に進捗状況や作っているプロダクトが正しいのか、仕事の進め方に問題がないかどうかを確認する。（＝検査）
- やり方に問題があったり、もっとうまくできる方法があれば、やり方そのものを変える。（＝適応）
継続的に実施し、プロジェクトを進める。
Scrum における開発の進め方
Scrum は開発の進め方にフォーカスした最低限のルールだけを定めている。
→ルールをどのように実際に適用していくかは自分たちで考える。
Scrum のルール
| ルール | 成果物・役割・会議体・仕組み | ポイント |
|---|---|---|
| プロダクトの責任者 | プロダクトオーナー | プロダクトの結果責任をとる プロダクトバックログの並び順の最終決定権限を持つ プロジェクトに必ず一人必要 開発チームを活用し、プロダクトの価値を最大化 開発チームに相談はできるが、干渉はできない |
| 動作するプロダクトを開発する | 開発チーム | リリース判断可能なプロダクトを作る 3〜9名で構成 全員揃えばプロダクトを作れる 上下関係はない |
| 短く区切って繰り返す | スプリント | スプリント期間は固定する スプリント期間が変動してはいけない |
| 頻繁に計画する | スプリント計画ミーティング | スプリントで開発をする為には計画が必要 プロダクトオーナーは何を欲しいのか（第一部） 開発チームはどれくらいでできそうか（第二部） 開発チームはどうやってそれを実現するか（第二部） |
| リリース判断可能 | リリース判断可能なプロダクト | 開発チームはリリース判断可能なプロダクトを作る |
| 完了の定義 | 完了の定義 | 何をもってリリース判断可能かを定める 途中での縮小は避ける |
| 毎日状況を確認する | デイリースクラム | 開発チームの状況を毎日確認 |
| 出来上がったプロダクトを確認する | スプリントレビュー | 開発チームの成果物をプロダクトオーナーが確認 |
| もっとうまくできるはず | スプリントレトロスペクティブ 振り返り |
プロセスやツール等の観点で今回のスプリントを検査 うまくいったこと、今後改善すべき点を整理 今後のアクションプランをつくる |
| 縁の下の力持ち | スクラムマスター | プロセスがうまく回るようにする 妨害を排除する 支援と奉仕をする 教育、ファシリテート、コーチ、推進役 |
インセプションデッキ
インセプションデッキとは？
プロジェクトに関する理解を深めるもの
→チーム全員がプロジェクトについて十分理解する。
プロジェクト開始時に作成する（ Why 、 How を定義する）
→大切なことを話し合い、合意の結果、何がどれだけ必要かが明確になる。
プロジェクトについて多くを知ることで、
- 様々な状況で正しい判断を下しやすくなる。
- ステークホルダーは決断しやすくなる。
インセプションデッキ作成時の参加者
- プロダクトオーナー
- スクラムマスター
- 開発チーム
インセプションデッキの内容
| 内容 | カテゴリ | ポイント |
|---|---|---|
| 我々は何故ここにいるのか？ | ミッション | プロジェクトの経緯や達成すべきゴールを確認 |
| エレベーターピッチ | ニーズ | 顧客の気持ちやビジネス側のゴールを確認 |
| パッケージデザイン | ビジョン | ユーザの気持ちやプロダクトの価値を確認 |
| やらないことリスト | スコープ | 決めかねていることややることを確認 |
| ご近所さんを探せ | プロジェクトコミュニティ | ステークホルダーや連携して仕事をする人を確認 |
| 技術的な解決案を描く | アーキテクチャ | 技術的にどう実現するかを確認 |
| 夜も眠れなくなるような問題は？ | リスク | 目標の達成を妨げる出来事と対策について |
| 期間を見極める | スケジュール | ざっくりといつ終わるかについて |
| トレードオフスライダー | 優先順位 | 何を重要視しているかやどう調整できるのかについて |
| チームの体制 | 体制 | 必要なスキルと役割や誰が最終判断するかについて |
| 何がどれだけ必要か？ | 最重要事項 | いつ完了していくらかかるか |
インセプションデッキの作り方
ポイント
- ワークショップ形式で実施！！
- 事前にインセプションデッキを作成するのに必要な情報は準備しておく。
- アイデア出しの場ではなく、方向付けの場である。
- 議論のたたき台になる情報を持っている側が準備してくる。
材料
- ホワイトボード
- スライド（インセプションデッキのテンプレート）
- 太いペン（適量）
- 強粘着の付箋
- マスキングテープ等他に必要なもの
進め方
- スライドのテーマについて話し合う。
- 1〜1.5 時間程度話したらスライドをまとめる。
- 1 に戻る
その他参考資料
その他のアジャイル開発の開発手法
Scrum 以外のアジャイル開発の開発手法について以下の表にまとめておきます。 Scrum と併用して使用できる開発手法もあるので、それぞれの開発手法について簡単にでも良いので調べてみても良いと思います。
| 名前 | 特徴 |
|---|---|
エクストリームプログラミング( XP ) |
小〜中規模開発向け(10名程度) プログラマ主体の開発 |
| スクラム | マネジメント主体の開発 少人数の開発向け |
機能駆動型開発( FDD ) |
中〜大規模でも適用可能 全体モデル、機能リスト、計画、設計、構築を行う 最初に開発の全体像を捉える |
| リーンソフトウェア開発 | リーンをソフトウェア開発に適用したもの リーンが分かってないと導入が難しい |
アジャイルユニファイドプロセス( AUP ) |
小〜大規模でも適用可能 ガイドラインや基準が整備されている 成果物が多くなりすぎる 詳細まで定義されている |
| クリスタル | 汎用性が高い プロジェクトに応じてプロセスを決定 プロセスのチューニングが必要 チューニングの途中で成果物を放棄することもある |
動的システム開発手法( DSDM ) |
ビジネス視点の考え方 |
プロジェクトの条件と開発手法のマッチング
開発規模と開発手法の対応範囲
開発手法のメリット・デメリット
最後に
アジャイル開発の Scrum で使用する用語について説明しました。用語の意味まで覚えておけば同じレベル間で会話もできるようになると思います。アジャイル開発は Scrum 以外にも色々あるので、他の開発手法についても用語などをまとめていきたいと思います。
コメント