このドキュメントについて
このドキュメントは私が所属するチームで行うScrum開発についての解説を行います。
Scrumは、一言でいえば「チームで仕事の進めるための枠組み（フレームワーク）」です。
このドキュメントでは私の所属するチームでの開発を行うために最適化しているため、本来のScrumと一部相違がある部分があります。
Scrumをより詳しく学びたい方は以下の参考資料をご確認下さい。
Scrumについての参考
US
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf#zoom=100
JA
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
Scrumを行う目的
目的は以下の通りです。
- ユーザー目線でプロダクトを成功させる
- メンバー間のコミュニケーションの活性化
- メンバー全体の底上げ
- チームとして開発に取り組みやすくする
- 個人の能力の依存を出来るだけ回避する
- 自己組織化したチームを構築する
Character/登場人物 (Ristでの名称・略称)
Scrumの登場人物について
User / ユーザー
受託開発であれば顧客、SaaSなど自社プロダクトであればその利用者を意味します。
Scrumを行う目的に ユーザーに目線でプロダクトを成功させるがあります。
そのため、プロダクトにおけるユーザーは明確にする必要があります。
開発チーム
TLとエンジニアメンバーの事。
Team / チーム
PO・スクラムマスター・開発チームの事。
PO / プロダクトオーナー （スクラムにおける役割）
SaaSなど自社サービスであれそのばプロダクトの方向性を決める人、プロダクトの責任者であるPdMが担う。（PdM=POではありません）
ユーザーの目線でプロダクトの課題解決に責任を負う役割を担う。
以降で説明するStoryの作成者になります。
TL / テックリード
開発の方向性を定め、プロダクトの価値を最大化することに責任を持ちます。
開発の責任者であるためプロダクトレベルでの決定については基本的に従いその中で開発の成功させる責任を負う人。
以降で説明するTaskの作成を開発チームとともに行います。
- プロダクト(又は受託開発のプロジェクト）における開発の責任者
- 開発方針などの最終決定を行う
- 俯瞰的に開発を把握する立場
- 上記のため、実際に手を動かす事は他のエンジニアの50%以下程度なる
- 事業、プロダクトの最終方針には基本的に従うがエンジニアの視点で開発が最も成功するように責任を負う人。
補足
プロダクト(又は受託開発のプロジェクト）によって担当者が変わります。
POから適任者が依頼を受けます。
Scrum Master / スクラムマスター （スクラムにおける役割）
スクラム開発のプロセスを正しく実行できているかを管理します。
またPOのStoryの作成やその実現のためにエンジニアのTaskの作成をサポートします。
Assignee 担当者
以降で説明を行うStory、Task、SubTaskを完了に責任を持つ人。
主に開発チームの主にエンジニア。PO・PMが担当者になる場合もあります。
Reviewer / レビュワー
Story、Task作業の確認を行う人。
開発チームのそのチケットの担当者以外の人が担当します。
Story、Taskについては必須で作業が開始するまでに決めておく必要があります。
※SubTaskはReviewerは指定されません。別途説明有り
Term / 用語
以下はScrumで使われる用語です。
Sprint
Sprintは、1週間や2週間といった、時間枠(Time Box)です。
私の所属するチームでは現在は2週間にしています。
Epic
Storyの集まり、複数のStoryに分割可能な大きなStoryの事
PMとScrum Master(サポート)がStoryを整理しEpicを作成します。
Story
ユーザにある価値を提供する事を目的に作られるチケットです。
そのため開発の担当者目線では無く、ユーザーの目線で作成されるもの。
SprintReview(※以降で解説)を行う対象になります。
StoryはPOとScrum Master(サポート)が作成を行います。
reference
- ユーザーと開発者の両方が理解できる言葉
- ユーザーにとってのプロダクトの価値やシステムの振る舞いを提示
- ユーザーストーリーは、従来のように開発者の視点でシステムの機能を説明するものではない
- ユーザーに対する価値を重視する
- ユーザーと開発者の両方が理解できる言葉
- ユーザーにとってのプロダクトの価値やシステムの振る舞いを提示
- ユーザーストーリーは、従来のように開発者の視点でシステムの機能を説明するものではない
- ユーザーに対する価値を重視する
- etc
Storyが大きすぎる時
StoryのStoryPoint(工数)が多すぎる場合は、Storyとして分割するか、次に説明するTaskとして切り出せるものは切り出す作業を行う必要がある。
※工数があまり大きくない場合(目安20pt以内)の場合は後で説明するSbuTaskで対応する。
Task
Storyを完了させるために必要となる課題の解決につくられるチケット。
完了をしてもユーザーに直接価値を提供する事は出来ない。(単体でその必要はない)
そのためSprintReviewの対象外とな、チーム内のReviewが完了とすれば終了となる。
Taskの作成は開発開始前にではTLが開発チームと行います。
例)ロボットアームの把持についての技術調査を行う
技術調査の結果はプロダクトの課題を解決するために必要であるが、直接的にユーザーに価値を提供する事は出来ないためTaskとなる。
SubTask
StoryやTaskを実行するための作業工程を分解したチケット。
分解を必要としない場合は不要なので必須ではありません。
Taskと同様に担当者の目線で作成されるものであるため完了をしてもユーザーに直接価値を提供する事は出来ない。(単体でその必要はない)
SubTaskの作成はStoryやTaskの担当者が基本的には直接行います。POが事前に作成している場合もあります。
大きさ
SubTaskの大きさは担当者で完結出来る作業程度にとどめます。
そのため他の担当者のレビュを必要とする作業はTaskにする必要があります。
GitHubのPRのレビュー、Story、TaskのレビューはSubTaskとしてチケットを作成し各担当者をアサインする必要があります。
Epic、Story、Taskの例
下記はECサイトの一部の機能の実装を例にあげています。
Epic
ユーザーは自宅から商品を購入し数日後に受け取る事が出来る
Story
上記のEpicを下記のように分解
- ユーザーは商品一覧から商品を選択する事が出来る
- ユーザーは購入ボタンを押す事が出来る
- ユーザーは決済を完了する事が出来る
- ユーザーは配達された商品を受け取る事が出来る
- etc
Task
e.g)Story「ユーザーは商品一覧から商品を選択する事が出来る」の工程で大きな作業を下記のようにTaskに分割する
- 商品一覧の画面のデザイン
- 商品一覧のWeb画面の開発を行う
- 商品データの取得処理の開発
- etc
SubTask
e.g)Task 「商品一覧のWeb画面の開発を行う」の工程のレビュを必要しない程度の作業をSubTaskに分割する
- デザインデータから画像を切り出す
- HTMLのコーディングを行う
- CSSを適用する
- etc
その他に「GitHubのPRの確認」、「Story、TaskのReview」などもSubTaskとして扱います。
Goal
Story、Taskを完了するための条件、受け入れ条件になります。
これはSpritの開始時点でチーム内で合意を得ている必要があります。
Spritの期間中に新たなStory、Tasが作成が必要な場合はPOと相談しGoalまでを作成します。
ReviewerはこのGoalの内容を満たしているかをReviewで確認します。
StoryPoint
StoryをDoneまでに必要なproduction costs(工数)
利用出来る数値は 1, 2, 3, 5, 8, 13, 21, 40, 100 になります。
これらは時間を表している訳ではなく、単純に課題の大きさを表している数値です。
2021/11現在の参考
私の所属するチームでは１Sprint(二週間)で一人が40pt以内、1週間に20pt程度を目安にしています。
StoryまたはTaskの見積もりを行う場合のSP（ストーリーポイント）の参考
※2021/11/02 現在
| SP | 目安(参考時間) |
|---|---|
| 0.5 | 1時間以内 |
| 1 | 1.5時間～2時間未満 |
| 2 | 4時間未満（半日程度） |
| 3 | 5時間～5時間半程度 |
| 5 | 1日+1.5時間～2時間未満 |
| 8 | 2日(15時間) |
| 13 | 3日(22.5時間)+1.5時間～2時間未満 |
| 20 | 1週間(5日間) |
| 40 | 2週間(10日間) |
| 100 | 5週間 |
StoryPointが多すぎる時
40, 100ptの見積もりはStoryまたはTaskが大きすぎるので分解を行う必要があります。
基本的には20pt以内に分割するようにします。
StoryやTaskの依存関係はJIRAのリンク機能で行います。
Storyを完了させるために行う大きなTaskがある場合は、そのTaskがStoryをBlockしているように設定します。
Story is blocked by Task
Task blocks Story
※見積もりを行う段階、不明確な場合はそれを解消するまでの調査などをTaskとしその調査機関を見積もります。
Product Backlog Item（Backlog）
簡単にBacklogと呼ばれることが多いので以降ではBacklogとします。
※注意 このドキュメントではBacklogはタスク管理Toolの名称ではありません
どのSprintで開発するかは未確定だがいずれは開発をする必要があるタスクを置いておく場所。
開発の開始前は基本的にSprintが無いためBacklogに全てが作成されSprintが作成された後、Backlog Refinementで各Sprintに割り当てられます。
開発の開始後はSprint PlanningでBacklogにあるStoryやTaskを開始するSprintやその後のSprintに割り当てを行います。
Status
開発状況はJIRAなどでタスク管理Toolを利用します。
その際のStoy, Task, SubTaskのStatusは私の所属するチームでは以下のように定義します。
TODO(やること)
Sprint内で着手する事が決まっているが作業を行っていない状態
※今の作業を途中で止めて他のチケットの作業を行う場合は、現在のチケットをこの状態に戻す。
Progress(作業中)
現在、作業を行っているStory,Task,SubTask。
基本的には1つだけがProgressとなる。
StubTaskがProgressの場合はその親のStoy,TaskもProgressとなる。
Review(チームのレビュ中)
担当者がStory,Taskの作業を完了し、Reviewの依頼を受けたReviewerがReviewを行っている状態。
Reviewは漏れがないようにSubTaskで管理し、Reviewerをその担当者にします。
SprintReview(スプリントレビュー)
Storyがチーム内でのReviewを通過しSprint Reviewを待っている状態。
DONE(完了)
Stoy
SprintReviewでPOがGoalの条件を満たし完了していると判断された状態。
Task
開発チーム内のReviewでGoalの条件を満たし完了していると判断された状態。
SubTask
担当者のレベルで作業が完了と判断された状態。
Reviewerへの依頼ルール
ReviewerへのReview依頼は必ずSlackでメンションをつけて依頼。
その後にStatusをReviewに変更を行います。
JIRAのメンションやGitHubでReviewerを指定するとメールが送られますが基本メールは観ていないと考えた方が良いでしょう。
Reviewerが問題がないと判断したら
ReviewerはTaskはDONE(完了)に状態を変更する。
StoryについてはSprintReview(スプリントレビュー)に変更を行う。
Reviewerが問題があると判断したら
Reviewerは
- チケットの担当者を作業を担当したメンバーに戻す
- TODOに状態を変更する
- コメントにDONEに出来ない理由を記載し担当したメンバーに伝える
その他
SubTask
SubTaskはReviewを行わない(作業者個人で完結する作業のみの)ためReviewに状態を変更せず、DONE(完了)にします。
GithubのPRのReview依頼について
GithubのPRのReviewは、Story,Taskの完了と同じでは無い事が多くあります。
そのため、別途StubTaskとして管理し、依頼する場合はこちらもSlackで依頼を行います。
##Goalの定義
StoryやTaskDoneがどうしたらDone(完了)となるかを明確します。
StoryとTaskそれぞれで定義が異なります。
詳細は以下の通りです。
Storyの場合
SprintReviewでPMがレビュー行い、Goalの条件を満たしていると判断した状態
Taskの場合
チームのReviewでReviewerがレビュー行い、Goalの条件を満たしていると判断した状態
SubTaskの場合
作業者の個人で完結する作業になるため担当者がその作業を完了させた状態
MTG
Scrumで行うMTGについて
Backlog Refinement
近い将来に取り組むStoryやTaskについて相談するMTGです。
相談する内容は以下になります。
- チーム内で今後発生しそうなStoryを共有する
- 直近のStoryやTaskについて工数を見積もる
- どのSprint(時期)で行うかを相談する
Sprint Planning
Sprintの開始前にそのSprintで完了する予定のStoryを相談するMTGです。
メンバー全員がそのSprintで行う作業を確定します。
Sprint Review、Sprint Retrospectiveの後はその内容を踏まえて計画を行います。
Daily Scrum
毎日行うSprintの進捗の確認など開発の状況を共有するイベントです。
まずSMが全体の進行具合の確認します。
そしてメンバー個人が
- 前日にやった事
- その日に行う事
- 困っている事
を話します。
15～30分以内で基本的に終わります。
時間がかかる相談はその場で約束して別で行います。
2023/09/25追記:
Daily Scrumよくある朝会や夕会ではなく、Sprint Planningで計画した通りに行かない事が発覚した時、すぐにPOと相談し計画変更を行うなど小さなプランニングの場でもあります。
Sprint Review
私の所属するチームではSprintの終了日にPMがStoryについてReviewを行います。
その際のFeedBackを次で説明するSprint Retrospectiveでチームで振り返りを行い、次のSprintに活かします。
Sprint Retrospective
Sprintの終了後にSprintの振り返りを行います。
具体的には以下について話合い次回の改善に繋げます。
この振り返りの目的はチームでの開発をより良くするためのものです。
※KeepやProblemなどは個人の事では無く、チームの目線でそのSprintを振り返り、考える必要があります。
Keep
What actions that have provided good results we should keep doing.（続けるべきこと）
Problem
Where we are having ongoing problems. （抱えている問題）
Try
What we want to try in the next time period. （次にトライしたいこと）
※Try discusses Keep and Problem as a team.（TryはKeepとProblemについてチームで話合う）
2023/09/25追記:
2022年の後半ころからKPTから単純なOKとNGをMiroの付箋に書いてもらう形式に変更しました。
その方が今抱えている課題などが出てきやすくなるためです。
Tool
JIRAを導入しています。(2021/08)