プロダクトバックログとスプリントバックログの違い~要求マネジメント
「成功する要求仕様 失敗する要求仕様」の最後に、要求マネジメントに関するクイックレシピがある。
その方法が、Scrumのプロダクトバックログとスプリントバックログを上手に使い分けるのと同じように思えたのでメモ。
【1】あるシステムを作るために、要件定義をしているとしよう。
その時、「成功する要求仕様 失敗する要求仕様」のクイックレシピによると、以下の手順が必要になる。
1.ブレーンストーミングで要求をまず洗い出す。
要求の実現性は問わない。
要求の優先度や重要度も洗い出す。
2.ブレーンストーミングで洗い出した要求リストから、要求か否かを決定する。
実現できる要求のトリアージを行い、要求の候補を決定する。
但し、この段階では、コストやスケジュールは未決定。
3.リリース計画を作る。
実現可能なスケジュールと予算を作り、リリース計画へ入れる要求を足していく。
但し、作成中のリリース計画では不満がある場合、次のリリースで対応することを考える。
例えば、Ver2.0のリリースでは機能が不十分な場合、Ver2.1というつなぎのリリースで対応する。
あるいは、Ver1.4をリリース済みで、Ver2.0へ向けて開発中の場合、Ver1.5で早めに部分的なリリースで対応する。
4.要求文書を作成する。
5.要求文書を品質測定する。
6.要求をベースライン化する。
7.ステークホルダー全員へ要求を周知する。
8.ベースライン後に、要求を変更・追加する場合、変更管理会議(CAB)でリリース計画を立てる。
【2】上記のやり方の特徴は、要求をトリアージして要求の候補を作ることと、リリース計画へその要求をアサインすることの2点にある。
トリアージして要求の候補を作ることは、Scrumのプロダクトバックログにストーリーカードを入れることと同じ。
つまり、プロダクトバックログにあるストーリーカードは、開発予定の機能であるが、どのバージョンで反映されるかは未決定の状態。
要求をリリース計画へアサインすることは、Scrumのスプリントバックログへストーリーカードを入れることと同じ。
つまり、プロダクトバックログからスプリントへストーリーカードを移したら、そのストーリーカードはそのスプリントで実装することになり、リリース計画に組み込まれる。
スプリントにあるストーリーカード全ては、スプリントバックログになる。
【3】RedmineのScrumプラグインは、上記の機能を実現している。
下記のBlogでは、そのインストール手順が書かれている。
【元ネタ】
プログラマの思索: RedmineへScrumのアイデアを注入
scrumalliance's redmine at master - GitHub
一応動いた…けど、
・スプリントバックログとプロダクトバックログの違いって何?
・ストーリーってチケットをまとめてくれるものじゃないんだ?
プロダクトバックログに入れてたストーリーにバージョンがついてなかったので、付けてみたら…
・プロダクトバックログから、スプリントバックログに移動した!
ScrumやXPにせよ、それらの概念やプラクティスは抽象的過ぎて、実際の現場ではどう運用してよいか分からない時が多い。
しかしながら、上記のようなRedmineのScrumプラグインを使えば、要求のトリアージやリリース計画へ要求のアサインを、Redmine上で実現できる。
つまり、実際の要求マネジメントをRedmine上で行っているのと同じなのだ。
ツールを上手に使いこなせれば、ツールが開発プロセスを改善してくれる。
そうすれば、チームは自然に成長している。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- 文化は組織構造に従う(2021.01.19)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
- カンバンはステータス名が大事(2021.01.02)
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- プロジェクトマネージャーの資質として重要なものの一つに『曖昧さへの耐性』がある(2020.12.11)
「Redmine」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- RedmineをPJ管理ツールと呼ぶのは嫌いだ、Redmineはチケット管理ツールと呼ぶべきだ(2021.01.02)
- PMO観点でRedmineの使い方とは何か(2020.12.20)
- 若手プロジェクトリーダー向けのRedmine教育資料の構想(2020.12.24)
「ソフトウェア工学」カテゴリの記事
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
- 相殺フィードバックを再考(2020.06.17)
- SaaSのビジネスモデルがアジャイル開発を促進したという仮説(2020.06.14)
- なぜなぜ分析、FMEA、FTAの違い(2020.06.09)
「チケット駆動開発」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
- チケット管理ツールの用途が変わってきている(2020.10.28)
「Agile」カテゴリの記事
- 文化は組織構造に従う(2021.01.19)
- 「ストーリーマッピングをはじめよう」本の感想~ストーリーによる企画や要件定義はSaaSと相性がいい(2021.01.17)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
- yWriterは映画の脚本を作るためのアプリだったのではないか(2021.01.05)
- カンバンはステータス名が大事(2021.01.02)
コメント