バックログに入らないタスクを可視化する枠組み2017年2月2日 社内技術勉強会
View Slide
- バックログ = スクラムにおけるタスク管理データ登録のAPI作成データ更新のAPI作成データ削除のAPI作成データ操作の画面作成
- バックログ = スクラムにおけるタスク管理データ登録のAPI作成 5ptデータ更新のAPI作成 3ptデータ削除のAPI作成 2ptデータ操作の画面作成 8pt
- チームベロシティ = スプリント内で消化できるポイント数データ登録のAPI作成 5pt 完成データ更新のAPI作成 3pt 完成データ削除のAPI作成 2pt 完成データ操作の画面作成 8pt 未完10pt
- チームベロシティ 10pt- 全体の見積り 100pt完成までに必要なスプリント数は100 / 10 = 10 スプリント
マネジメントからの要求ベロシティをあげられないか
- チームベロシティ 10pt -> 20pt- 全体の見積り 100pt5スプリントに短縮したい
完成までのスプリント数を短縮する方法- バックログを減らす- ベロシティを増やす
ベロシティを上げる方法- 人数を増やす- 一時的にベロシティは下がる- 稼働時間を増やす- 燃え尽きる
スプリントにおけるタスクへの割当時間を増やす
スプリント期間中の我々の活動- タスク消化- いろいろなミーティング- 期末の評価- サポート調査- 開発環境の整備バックログの消化以外にいろいろある
バックログ以外の活動を可視化しよう
チームタスクをカテゴライズする4つのカテゴリ- 機能実現- 税- スパイク- 前提条件
機能実現システムやソフトウェアパッケージのユーザや購入者に対してビジネス価値を届けるための仕事我々がバックログと呼んでいるものは主にこれ
税会社のための仕事や必須の要求事項であり、チームやグループに重荷となる賦課、義務、任務、請求など。ex) スクラムミーティング, 全社会議や部門会議, 期末の評価税なので、ここを減らすと会社やチームとしてのサービスレベルは低下する
スパイクスパイクは短時間、タイムボックスでおこなう活動で、大規模だったり曖昧だったりするタスクやストーリーを完成させるためにどんな作業が必要か見つけるためのものである。サポート調査タスクなどもここに入る
前提条件前提条件はストーリーに関連するタスクではないが、スプリント中に終わらせるべき作業のことだ。チームが見つけ、プロダクトオーナーやスクラムマスターと交渉する。CIとかデプロイの改善や、アプリケーションフレームワークのバージョンアップなど。
これらの枠組みに応じて作業を可視化する- 可視化されたカテゴリごとに、チームにおける税率などのタスク配分を決める- タスク配分に応じて、スプリント内の機能実現の割当を増やすなどの調整ができる。
参考文献スクラム現場ガイドhttps://www.amazon.co.jp/dp/B01D4JHITO