LoginSignup
2
2

More than 3 years have passed since last update.

@masatatsu777

Scrum開発メモ

Posted at

デイリースクラム

目的

  • Sprint Goalを自己組織的に達成できることを目指すSprint再計画の場

進め方

# やること 目的
1 バーンダウンチャートを確認 ゴールへの着地感を確認。乖離がある場合は課題があるはずなので、課題は何かを明確化する
2 個人の今日やること、課題を確認 着地に向かって今日やること、問題となっていることを確認する
3 ゴールに達成に障害となるチーム・個人問題を確認（必要に応じてImpediment Listを見る） ゴールへの障害の明確化、リスト化、POへのアクション有無の確認

Impediment List

課題管理をJiraで実施するために、Impediment Listを作成する。

Impediment Listとは

Scrumの実行する上で障害となるもののリスト。
振り返りの場で確認をしましょう。

Kanban

表示条件

下記の2条件を満たしたItemが表示される

  • TypeがTask
  • Labelに"課題"がついている

ライフサイクル

追加

下記のイベントで発生した管理するべき障害、課題が発生した場合にScrum Master（もしくはそれ相当の人材）が追加する

  • デイリースクラム
  • 振り返り

優先順位付け

チーム内だけで解決できない場合、解決に大きな稼働が必要になる場合はPO/PO補佐と相談してSprintゴールとしてチェックしましょう

更新

完了、削除含めて更新は振り返りの場で確認するようにしましょう

チケットに記載する内容

下記を必ず含めること

  • 課題
  • 解決策

SBI粒度とDoD

Sprint計画第二部においてタスクをスライスする方法について記載する

タスクスライスの方法

タスクを分割する方法は大きくわけて2つ存在

  • 機能単位
  • コンポーネント単位

この分割の議論はPBIの分割やチームの分割など大小関わらず存在する

Agile開発においては、デモが実施かのうな機能単位(feature単位)での分割が良いとされている

それぞれの比較

  • 機能単位
    • メリット
      • 実際に開発する単位に近いことが多い
      • 横断的に実施するので一人の人がすべてのコンポーネントを触ることになり、機能横断なチームになりやすい
    • デメリット
      • 見積もりするには結局コンポーネント単位に分割して考える必要があったりする
  • コンポーネント単位
    • メリット
      • 見積もりがしやすい
      • PBIに対してタスクのテンプレ化がしやすい（画面設計、画面製造、API設計、API製造、UT、ITなど同様のタスク郡にしやすい）
    • デメリット
      • 細かくスライスしすぎると、実際の開発作業とは異なるサイズになったりする。（作業単位より細かい状況）

Discussionポイント

実はコンポーネント単位でスライスすることが結構多くの現場ではやられています。
私が所属してきたチームはだいたいコンポーネント単位でスライスされていました。
理由としてはStoryのサイズが機能の最小単位ぐらいまでに細かくなっていたためです。
結局実際の作業する単位に分割されていればOKです。
それより細かいのはNG。

取れそうなアクションは下記の通り

  • ストーリーをさらに機能単位に分割する
  • いままで通りコンポーネント単位でスライスするが、粒度を大きくして実際の作業の単位に揃える

結局は細かすぎず、大きすぎずの単位でやっていきましょう

SBIの単位

SBIのステータス

※参考

# ステータス 意味合い
1 作業前 未着手状態
2 作業中 Work in Progress
3 保留中 要否確認中 or 取り下げ
4 レビュー待ち ここのitemをレビュアーがPullしてレビューを実施する。レビューに関するDoDが完了している状態
5 レビュー中 レビュアーがPullしてレビュー中の状態
6 完了 DoDを満たしたもの

DoDの定義

受け入れ基準を満たしている
- 静的チェックが通っている
- 規約に合っているかチェック
- レビューが完了している
- UTがCoverage:C0/C1 100%, All green
- 上記で満たせない事項が発生した場合は個別にサブタスクに記載する
など。

参考 ScrumとKanbanの違い

Agileの手法としてScrumとKanbanが存在する（Kanbanはタスクボードといういみではなく、ソフトウェア開発手法の方法としてのいみ）

ScrumでもKanbanでも同様にPBIをベースに開発を実施することが基本となる。
PBIの状態を管理する方法が異なっている。

Scrum

PBIをタスク化してSprint Backlogとして管理する。
TaskのレーンはTodo, WIP, Doneのみ（Rejected, Waitingなどを入れてもよし）。
各種タスクの詳細見積もりを実施することで、Sprintでの着地が可能かを精緻に見積もる。
Sprint内でのSprint Goal達成を見越したプラクティス。

Kanban

Scrumで規定したタスク粒度のレーンを用意して、PBIを移動させる。
各種レーンの見積もりは実施しない。
各種レーンの滞留状況などを見てボトルネックを発見し、PBIの左から右へ流れるリードタイムをどの様に短くするのか？のカイゼンを図るためのプラクティス。

各プラクティスのタスクボードの考え方が違う

Scrum Kanban
Sprint Goal達成 (目標としているPBI郡の実現) PBI実現のリードタイム低減 (PBI一つひとつに対するアプローチ)

いまはレーンの考え方が、タスク分解とステータス両方のいみを持っているように見える（レビューレーンなど）

スクラム運営ガイド

スクラムの構成要素

スクラム自体はScrum.orgが出している"スクラムガイド"が聖書. ここに書いてあることが"正しい"です。DRY原則に反するので各種定義については記載しません。

  • イベント
    • スプリントプランニング
    • デイリースクラム
    • スプリントレビュー
    • レトロスペクティブ
  • ロール
    • プロダクトオーナー
    • スクラムマスター
    • 開発チーム
  • 成果物
    • プロダクトバックログ
    • スプリントバックログ
    • インクリメント

重要なことはスクラムはカイゼンのためのフレームワークであり、下記の2つのカイゼンを回すためのフレームワークであるということです。

  • Whatのカイゼンループ
    • プロダクト（何を作るのか）のカイゼンループ
  • Howのカイゼンループ
    • スクラムチーム（作り方）のカイゼンループ

作る対象とその作り方をカイゼンしていくことがスクラムです。

スクラムはフレームワークであり、メソッドではない

スクラムはフレームワークでありメソッドではない。言い換えると、具体的な手段ではなく枠組みだけが提供されているものです。さらに言い換えると、スクラムは枠組みだけを提供するから具体的な実装はチームがやってね？というスタンスです。したがってスクラムチームの数だけやり方があると言っても良いです。

この記事（スクラムは抽象クラス）がよりよく示しています。
スクラムは抽象メソッドであり、実装はチームがする旨が記載されています。

とはいえ「よくやる実装方法」みたいなものはあるので、それをこのドキュメントでは紹介していきます。

  • バックログリファインメント (バックロググルーミング)
  • インペディメントリスト
  • POの作業とPO補佐
  • スクラムマスターの作業
  • 振り返りの手法

バックログリファインメント (バックロググルーミング)

これはスクラムガイドにも記載があるが、任意実施である"プロダクトバックログの最新化"をするイベント。

実施する目的は、次の「スプリントプランニング」でスコープ(スプリントゴール)が決定できるような状態にプロダクトバックログを調整すること
具体的には下記を実施する。

  • スプリントレビューで得られたフィードバックや開発チームの意見を持とにプロダクトバックログアイテムの内容や優先順位を見直す
  • 次スプリントで取り組むバックログアイテムについて、不足している要件や調査が必要な技術課題を明らかにし、計画会議にReadyになるように調整する
  • スプリントプランニングで見積もる時間がない/適切でない場合は、バックログアイテムの見積もりを実施する

特に実施する必要がないSprintでは実施しなくても良い。

インペディメントリスト

スクラム Guideには登場しないもののカイゼンのフレームワークであるスクラムではよく実施されるプラクティスです。

インペディメントリストは下記の特徴を持ったリストです。

  • 障害や課題が一覧化されたリスト
  • レトロスペクティブやデイリースクラムで更新される
  • 優先順位をつけて対応を実施する
  • スクラムマスターが管理する

What, Howに関わらずカイゼンループが回っている場合にはそれなりのインペディメントリストのI/Oがあります。
List内のItemが滞留していたり、全くなかったりする場合はカイゼンループが回っていない可能性があります（スクラムとしては黄信号）

POの作業とPO補佐

プロダクトバックログのメンテナンス

プロダクトオーナの作業は準備期間にバックログを作って終わりではなく、スプリント毎にフィードバックの収集やバックログのメンテナンス、次のスプリントの準備をします。

  • 開発依頼元の方に定期的にプロダクトを触ってもらい、感想や意見をもらう。
  • 実際のユーザにプロダクトを触ってもらい、感想や意見をもらう。
  • 実際のユーザがプロダクトを触っている様子を観察し、プロダクトの改善に繋がりそうな気付きがあれば記録する。
  • プロダクトへのアクセス履歴や利用履歴を収集・分析する

これを基に、プロダクトが想定した価値を満たしているのか評価し、バックログアイテムの優先順位の見直しや、新しいバックログアイテムを作成する為のインプットにします。

リリース予測

開発チームの生産値（ベロシティ）からリリース予測を行います。
Agile開発におけるマネジメントの考え方から、計画より進んでいるかいないかをチェックします。
基本的にはリリース予測が早かろうが、遅かろうがスコープを調整するのが基本的な考え方です。
Agile開発でコントロールするマネジメントパラメータはスコープです（図参照）

このマネジメント方式のため、基本的には下記のスタイルでリリース予測を立てていきます。

  1. リリースまでの開発期間、リソースを決める
    • たとえば、2週間（0.5ヶ月）を10人で10スプリント実施する場合は、10人の5ヶ月の開発リソースが決まります。
  2. 開発スコープ（PBL）を決める
    • たとえば、機能A から 機能Eまでを開発する場合には、2週間10人のハコにどのようにPBIを入れていくかを検討する
  3. 開発スコープ（PBL）を変更する
    • 当初スコープに対して変更をPBLに加えながら、次の2週間10人のハコにどのようなPBIをいれるのかを決める
    • 当初計画していた機能Eはスコープアウト、機能Fをスコープイン、機能Aは強化して機能A'にするなど変更を加えながらスコープをコントロールしていく
    • 2週間10人×10スコープの全体の面積はコントロールしない
  4. 開発スコープ（PBL）を変更する
    • 繰り返し...

PO補佐

POは一人であることが通常ですが、実際の作業まで落とし込むのは困難です。したがって、PO補佐を設けることが多いです。PO補佐はプロダクトバックログの詳細化（システム要件の検討）など、システム側のサポートを実施することが多いです。

スクラムマスターの作業

スクラムマスターは実施することが不明確な場合は多い（初めてやる場合は特に）ので、スクラムの実装方針としてやることを示していきます。

ちなみにここで示したことが全てではありません。スクラムマスターは開発チームをリードする存在ですが、リーダーシップはサーバントリーダーシップです。
開発チームが気持ちよく働けるように、そしてスプリントゴールを達成できる様に支援することがスクラムマスターの役割です。考えて行動しましょう。

サーバントリーダーシップでのスクラムマスターは下記で示しています。

https://www.youtube.com/watch?v=eNe0UEsBalA

行動指針

  • 決められたタスクに縛られずに仕事ができる
  • いつでも何でも人のために行動できる
  • スクラムのプロフェッショナルとして自負を持っている
  • 決断力と不屈の精神を持っている
  • 高い理想を描ける
  • 自ら手を下すのではなく、まずはサポートをする
  • プロダクトオーナや開発チームのイエスマンにならない

フロー効率とリソース効率

スクラムマスターがチームを改善するときに意識するべき効率について、従来型の開発でどちらかというと「リソースが100%稼働する」ことを重視する。すなわちリソース効率が良い状態を目指すことが多いです。
一方、アジャイル型の開発ではリソースがある程度浮いても、もの（PBI）が素早く世の中に出ることを優先する。すなわちフロー効率が良い状態を目指すことが多いです。多少リソース効率が悪くても一つのPBIを実現することを目指すというイメージです。

この考え方は黒田樹さんという方の記事が詳しいので一度目を通しておくと良いです。

スクラムマスターのアクション例

これらの行動指針や効率の考え方を踏まえてスクラムマスターのアクション例を記載します。

  • チームの立ち上げ
  • イベントのファシリテート
  • コミュニケーションのサポート
  • チームのマネジメント
チーム立ち上げ
  • スクラムを教える
    • POと開発チームにスクラムを教える
    • ステークホルダに対してスクラムを教える、価値観の変革の必要性を説く
    • スクラムを始める前に必要な要素をスクラムチームに理解してもらう
  • チームをファシリテートしてルール整備する
    • 開発チームとPOが下記を決められるよう主導する
      • タイムボックス
      • Doneの定義 (Definition of Done, DoD)
      • コミュニケーション方法
      • 透明性を保つ方法
  • 環境を整備する
    • タスクボードなどスクラムツールを整備する
    • 開発チームをサポートしながら、自動試験環境などを構築する（インフラTでも可）
    • 知見の文書化
イベントのファシリテート
  • デイリースクラム
    • Sprint Goalへ意識が向かうようにイベント全体をファシリテートする
    • 挙がった障害はインペディメントリストに追加して、スクラムマスターが管理する
    • 問題解決の議論など、デイリースクラムの目的と直接関係の無い話題になったら、デイリースクラムの後で続きをするようにファシリテートする
  • スプリントプランニング
    • タイムキーパーとファシリテータを務める
    • 議論を促すために、議論に消極的なメンバをサポートする
    • スプリントのスコープについてプロダクトオーナと開発チームで合意ができるように調整役を担う
  • スプリントレビュー
    • タイムキーパーとファシリテータを務める
    • レビュー後、プロダクトオーナに受け入れ基準に従った受け入れ判断を依頼する
    • 受け入れ確認だけではなく、開発チームとプロダクトオーナがプロダクトについて議論できるようにファシリテートする
  • レトロスペクティブ
    • タイムキーパーとファシリテータを務める
    • チームの状況に合わせて振り返りの手法を選択する
    • 初めに前回の振り返りで取り組む事に決めた事が実際に取り組めているか参加者で確認するように促す
    • 実際に取り組む対策とその主担当者を決めるように開発チームに促す
コミュニケーションのサポート
  • POとDevのコミュニケーションサポート
    • Agile開発においてプロダクトオーナと開発チームのコミュニケーションが重視される理由を両者に説明する
    • 円滑なコミュニケーションが出来るように、プロダクトオーナと開発チームのコミュニケーションルールを両者と一緒に作る（ルールは準備期間中に作る）
    • プロダクトオーナや開発チームがコミュニケーションルールを守れていない場合は、守るように監督する（ルール自体に問題があると思われる場合、両者を集めてルールの見直しを行う）
    • プロダクトオーナと開発チームの間にコミュニケーションの仲介役が入った場合、仲介役を外してプロダクトオーナと開発チームが直接コミュニケーション出来るようにする
  • 複数の開発チームが存在する場合、開発チーム間の連携をサポート
    • 案件の規模が大きく、複数のチームに分かれて開発をする場合、チーム間で打合せが必要になった際はスクラムマスターが調整をする
    • チーム間のコミュニケーションに必要な環境、ツールの手配をする
    • 他チームのスクラムマスターとチームに生じている問題や、有効な解決策を共有し、プロジェクト全体としてパフォーマンスが向上するように取り組む
  • プロジェクト外部との連携をサポート
    • 他システム連携などでプロジェクトの外のチームと開発チームでコミュニケーションが必要になったら、日程調整などはスクラムマスターが行う
  • チャットコミュニケーション
    • 浸透的コミュニケーション（Osmotic Communication）
      • あまり日本語では情報がないが浸透的コミュニケーションという言葉がある。他人が話している内容をチャットに流すことでその内容が自然と共有されるという意味。情報が浸透していく。その状況ができるようにする。
      • プライベートチャネルが乱立、DMでやり取りしてしまっている。Publicチャネルが静かな場合はこの状況にあっていることがある
チームのマネジメント
  • インペディメントリストの管理
    • 基本的に問題・課題の対応は開発チームが行うが、チームには開発や問題・課題の対応に集中してもらうため、管理はスクラムマスターが行う
    • 問題・課題を管理する仕組みはチームと相談しながら準備する
    • デイリースクラムなどで問題が報告され、すぐに対応が難しい場合、インペディメントリストに記録をし、対応されないまま放置されないように管理する
    • 問題・課題の対応状況をチェックし、開発チームを対応を促すなど、アクションを取る
    • プロダクトオーナ側に原因がある問題など、開発チームだけでは解決出来ない問題はスクラムマスターが対応する
  • チームの改善
    • チームだけで改善のサイクルを回せるのが理想だが、始めはスクラムマスターが改善の音頭をとる
    • レトロスペクティブのやり方を教える
    • レトロスペクティブ以外にも必要があれば改善のためのタイムボックスを設定する
    • レトロスペクティブや振り返りで出たアクションが実行できるように促す
  • チームの作業環境の改善
  • 進捗管理の補助
    • Agile開発では開発チームが進捗管理の役割を持つスクラムマスターは管理のやり方を開発チームに教えてチームだけで管理ができるように指導する（基本はバーンダウンチャートで進捗をライトに見る）
    • 進捗管理の方法及び進捗を見える化する方法を準備期間にチームと一緒に決める
    • 進捗管理に必要なツールや資材の準備をする
    • プロダクトのスケジュールはプロダクトオーナー、スプリントのスケジュールは開発チームに責任がある。スクラムマスターはどちらかというと開発チーム側のポジションだが、両方のスケジュール管理をサポートする
  • 品質の管理
    • アジャイルでは開発チームが品質管理の役割を持つスクラムマスターは管理の方法を開発チームに教えてチームだけで管理が出来るように指導する
    • 準備期間中に開発チーム、プロダクトオーナ、ステークホルダを巻き込んで品質保証プランを決める
    • 作業のDoneの定義を決める際、品質に関する条件を含めるように開発チームと検討する
    • スプリント期間中は、決めた通りに品質の管理が出来ているか確認をする
  • スプリントのデータ収集と改善
    • 次の見積りのインプットになるようなスプリントのデータを収集する（チームのベロシティ、計画時間と実績作業時間の差異など…）
    • どのようなデータを収集すべきか準備期間に開発チームと検討しておく
    • 収集したデータからチームの問題を発見した場合はチームに説明し、レトロスペクティブやその他の振り返りの機会にチームで対策を考える
  • 開発チームの防衛
    • スプリント期間中に開発チームがスプリントバックログと無関係な作業を依頼された場合、プロダクトオーナを通して依頼するようにお願いする
    • プロダクトオーナがチームのキャパシティを大幅に超える作業計画を依頼して来た場合、計画を見直すように依頼し、一緒に見直しをする
  • プロセスの監視
    • Agile開発自体のルールや、チームで決めたルール（Doneの定義など）を守れていないチームメンバが居る場合は、守れるようにコーチングする
    • プロセス自体に問題があると気づいた場合は、チームとプロセスの変更について再検討する
  • チームをアセスメント（評価）する

振り返りの手法

世の中にある振り返りの手法をまとめます

  • KPT
  • Lean Coffee
  • Fun/Done/Learn
  • Timeline
  • Sailboat retrospective

KPT

Keep（継続したいこと）/Problem（問題だと感じたこと）/Try（継続するため、Keepをより良くするアクション、問題を改善するためのアクション）について洗い出しを行い、アクションを選定する手法

手順

  1. Keep 5分付箋に書き出す（個別作業）
  2. Keep 共有（グループ）
  3. Problem 5分付箋に書き出す（個別作業）
  4. Problem 共有（グループ）
  5. Try 5分付箋に書き出す（個別作業）
  6. Try 共有（グループ）
  7. アクション項目を決定する

ポイント

個別作業とグループ作業を分けることがポイント
すべてグループ作業だと、特定の声の大きな人間の意見に流されやすいため。

リモートワーク用

下記をコピーして利用しましょう！
https://docs.google.com/presentation/d/1n1rGAdL0RsB6j4_3zoXmSkk4jyWWfcWmGAxJrfJFru8/edit?usp=sharing

Lean Coffee

話題を起票して、投票によってディスカッションする項目を決める手法

KPTを実施していて項目の洗い出しに終始してしまい、各項目の深い議論を実施できていない場合に実施するとよいプラクティス

手順

  1. 各メンバーが話題を書き出す（個別作業）
    • 話題は開発に関わる、課題や気になっている些細なことでもよい
  2. 書き出した話題を共有する（グループワーク）
  3. 話題に対して投票を行い、優先順位付けを実施する
    • 1人2票投票する形式
  4. 優先順位が高いものから時間を決めて議論する
    1. 5分のタイムボックスで議論をすすめる
    2. 時間が来たら継続するかしないかをチームで話す
    3. 継続する場合は追加の5分、しない場合は次のトピックへ移動する
    4. 振り返り全体のタイムボックス（1時間）を使うまで繰り返し、残トピックがあっても終了次第終わりにする

ポイント

ディスカッションのためのプラクティスなので、KPTなどの他の洗い出しのプラクティスと組み合わせると良い。
Problemの原因分析が浅い、良いアクションが出ない、、、などの課題がある場合に複合するなど。

Fun/Done/Learn

Fun（楽しかったこと）/Done（やったこと）/Learn（学んだこと）に分けて起票していく手法。良かったことをベースに振り返る手法。メンバーのモチベーションを図りたいときに利用すると良い手法。

出典: https://qiita.com/yattom/items/90ac533d993d3a2d2d0f

手順

KPTの項目をFDLに置き換えて実施

ポイント

楽しいことにフォーカスして実施するプラクティスです。KPTマンネリ化したときとかに利用しましょう。内容はふわっとしやすいので、アクションまで落とし込むが難しいという特徴です。良かったなぁで終わらないように、アクションまで落とし込みましょう。メンバーのモチベーションが上がるポイントがわかりやすいプラクティスなので、それを伸ばすアクションを検討すると良いと思います。

リモートワーク用

下記をコピーして利用しましょう！
https://docs.google.com/presentation/d/1vEjMBTZwk08kuw7rGhycXirpll0P7ymZG_WG4hf0w4I/edit?usp=sharing

Timeline

名前の通りにタイムラインで振り返る手法。
バーンダウンチャートベースで事実として起きたことを記載していく。
それぞれの出来事に対して、気持ちが落ち込んだのか上がったのかなどのモチベーションに関する情報を付与していく

出典: https://medium.com/@stephaniebysouth/timeline-achievement-retrospective-5422d63c975d

手順

  1. 付箋に事実を書き出す（個人ワーク）
  2. 一人ひとりバーンダウンチャートに自分の書き出した付箋を貼り付けて発表する（グループワーク）
  3. それぞれの出来事に対してモチベーション情報を付与する
    • 付箋の位置を上に上げる、下げる
    • +1のスタンプなどを貼りつける
    • モチベーショングラフを描く

ポイント

事実を洗い出すプラクティスなので、KPTがマンネリ化して情報がでにくくなっている場合に利用すると良さそうです。反対に事象の深堀りやアクションの検討まで行かないことが多いので、別途Lean Coffeeなどと組み合わせるなどの手法が必要になります。

リモートワーク用

下記をコピーして利用しましょう！
https://docs.google.com/presentation/d/1jkOGmyOO5w3fwyFw8TjOWAg9NfZHrdpAPG8JYODrG00/edit?usp=sharing

Sailboat Retrospective

Scrumチームをボートに見立てて、チームの目標や追い風になるもの、障害になるものなどチームと取り巻く環境を俯瞰的に振り返り、プロジェクト・プロダクトに関する共通認識を醸成する

出典: https://www.techagilist.com/agile/scrum/sailboat-or-speedboat-sprint-retrospective/

手順

  1. 下記の要素について個人ワークで洗い出しをする
    • 船: ProductとScrumチーム
    • 島: Productのゴール
    • 風: Productの追い風になる要因
    • 錨: プロジェクトの足を引っ張る要素
    • 岩: リスク
  2. 各メンバーが発表をし、都度議論を実施する
  3. 議論の中で貼るべき場所が違った場合など、入替を実施する（錨の要素だと想定していたものが風に変更する）
  4. 追加要素があれば都度貼り付けを実施する

ポイント

プロジェクトの開始時や、方向転換時などチームの共通認識を醸成したいタイミングや節目に利用すると良いプラクティスです。

リモートワーク用

下記をコピーして利用しましょう！
https://docs.google.com/presentation/d/1LmZRozh2PfL-VHBRIOjdqi3J4ZghVDIbV30Iv1BmY8w/edit?usp=sharing

2
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
2