Scrum のバックアップ(No.2)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ | ログイン ]

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• Scrum へ行く。
  • 1 (2017-04-06 (木) 04:52:58)
  • 2 (2017-04-09 (日) 12:28:04)

---

アジャイル開発とは †

「事前に全てを正確に予測し、計画することはできない」という前提を意識し、以下のように進めること

• 関係者は目的の達成のためにお互いに協力し合いながら進める。
• 利用者の反応や関係者からのフィードバックを継続的に得ながら、計画を調整する。
• 一度にまとめてではなく、少しずつ作る。そして実際に出来上がったものが求めているものと合っているかを頻繁に確認する。

• 重要なもの、リスクの高いものを先に作り、重要度の低いものは後に回すことで、要求の分析や設計などに必要以上の時間をかけないようにする。

Scrumとは †

アジャイル開発手法の一つ。常に進む方向を調整しながら目的を達成できるプロダクトを作るために、全員が一丸となって行うべき作業、会議、成果物を定めたもの。

特徴 †

• 要求を常に順番に並べ替えて、その順にプロダクトを作ることで成果を最大化する
• Scrumでは実現される価値やリスクや必要性を基準にする。固定の短い時間に区切って作業を進める。この期間のことを「タイムボックス」と呼ぶ。
• 現在の状況や問題点を常に明らかにする。これを「透明性」と呼ぶ。
• 定期的に進捗状況や作っているプロダクトが正しいのか、仕事の進め方に問題がないかどうかを確認する。これを「検査」と呼ぶ。
• やり方に問題があったり、最も上手くできる方法があったりすれば、やり方そのものを変える。これを「適応」と呼ぶ。

これらを継続的に実施してプロジェクトを進めていく。

プロダクトバックログ【成果物1】 †

• Scrumでは、プロダクトへの要求を抽出し、順番に並べ替えた「プロダクトバックログ」と呼ばれるリストを1つ作成する
• 順番は、その要求が実現されたときに得られる価値やリスク、必要性などによって決定される
• それぞれの項目はプロダクトバックログ上で一意な順番を持ち、順位の高いものから開発される
• 計画する際に利用するために、それぞれの項目は見積もりが行われている必要がある。見積もりには時間や金額などの絶対値ではなく、作業量を相対的に表した値がよく使われる。

• プロダクトバックログは一度作って順番に並べ替えたら完成ではない。絶えず修正され、最新の状態に保つ必要がある。
• プロダクトバックログの項目の書き方には特に決まりはないが、ユーザーストーリーと呼ばれる形式で書くことが多い

プロダクトオーナー【ロール1】 †

• プロダクトの結果責任をとる
• プロダクトバックログの管理者で、並び順の最終決定権限を持つ
• プロジェクトに必ず1人必要
• 開発チームを活用して、プロダクトの価値を最大化する
• 開発チームに相談できるが、干渉はできない

• プロダクトのビジョンを明らかにし、周りと共有する
• おおよそのリリース計画を定める
• 予算を管理する
• 顧客、プロダクトの利用者や経営者などのプロジェクト関係者と、プロダクトバックログの項目の内容を確認したり、作る順番や実現時期を相談したりする
• 既存のプロダクトバックログの項目の内容を最新の状態に更新する
• プロダクトバックログの項目の内容を関係者が理解できるように説明する
• 作られたプロダクトが要求に合っているかどうかを検査する

• プロダクトオーナーが決めたことを他人が勝手に覆してはならない。プロダクトオーナー自身が決めることで、結果に対する責任が負えるようにする。

開発チーム【ロール2】 †

• リリース判断可能なプロダクトを作る
• 3人〜9人で構成する
• 全員揃えばプロダクトを作れる（プロダクトを作るために必要な「全ての」作業ができなければならない）
• 上下関係なし

スプリント †

• Scrumでは最長1ヶ月までの固定の期間に区切って、繰り返し開発を行う。この固定の期間のことを「スプリント」と呼ぶ。
• 開発チームはこの期間の中で、計画、設計、開発、テストなどのプロダクトのリリース判断に必要な全てのことを行う
• このように固定の期間に区切って開発を繰り返すことにより、開発チームにリズムができて集中できるようになり、プロジェクトのゴールに対する進捗が把握しやすくなったり、リスクに対応しやすくなったりする

• スプリントの最終日に作業が残っていてもスプリントは終了し、期間は延長しない
• スプリントの期間は、プロダクトの規模や開発チームの人数や成熟度、ビジネスの状況などを踏まえて決定する。短ければ1w、長くて4w。週単位で期間が設定されることが多い。大体2w。

スプリント計画ミーティング【会議体1】 †

• スプリントを始めるにあたり、まずスプリントで何を作るのか（What）、どのように作るのか（How）を計画する必要がある
• 計画は「スプリント計画ミーティング」と呼ばれる会議で決定する
• スプリント計画ミーティングに使える時間は1ヶ月スプリントであれば8時間、2週間スプリントであれば4時間となる

• スプリント計画ミーティングは二部構成
  • 第一部（プロダクトオーナーは何を欲しいのか？開発チームはどれくらいできそうか？）
    • プロダクトオーナー、開発チーム、スクラムマスターが参加し、そのスプリントで、どのプロダクトバックログの項目を開発するのかを検討し、内容を確認する
    • 開発する量は過去のスプリントの実績と今後の予測を参考にして決定する
    • 過去の実績のことを「ベロシティ」と呼ぶ
    • 第一部で検討した内容を踏まえて、今回のスプリントの目標を簡潔にまとめておく。これを「スプリントゴール」と呼び、開発チームがなぜここで選択したバックログの項目を開発するのか理解しやすくなる。
  • 第二部（開発チームはどうやって実現するか？）
    • 第一部で選択したプロダクトバックログの項目を完了させるために必要な全ての作業（タスク）を開発チームによって洗い出す
  • タスクを洗い出した結果、開発チームがスプリント中にタスクを完了できないと判断した場合は、プロダクトオーナーと相談し、選択したプロダクトバックログの項目の一部を外したり、実装の方式を検討し直したりすることによって、作業量を調節する

• 開発チームはスプリント計画で合意した内容を完了させることに全力は尽くす必要はあるが、計画したことを全て完了させることを約束しているわけではない

スプリントバックログ【成果物2】 †

• タスク一覧
• スプリントバックログは開発チームの作業計画であり、スプリント期間中も自由にタスクを追加したり削除したりすることができる
• 個々のタスクは1日以下の単位とする

リリース判断可能なプロダクト【成果物3】 †

• プロダクトオーナーと開発チームが「リリース判断可能」の指す内容について共通の基準を持つ必要がある。これを「完了の定義」と呼ぶ。
• 完了の定義によって、何をもってリリース判断可能かを定める。
  • コードレビュー
  • チェックイン
  • ユニットテスト
  • カバレージ
  • ドキュメント
  • セキュリティ
  • 性能
  • デプロイ
  • and more
• 途中で定義を追加することは許されるが、削除は避けた方が良い

デイリースクラム【会議体2】 †

• 開発チームの状況を毎日確認する
• 開発チームの人数に関係なく、15分間のタイムボックスで行われ、延長はできない
• デイリースクラムでは開発チームの各メンバーは以下の3点について、開発チーム全体に向けて簡潔に報告する
  • 前回のデイリースクラムからやったこと
  • 次回のデイリースクラムまでにやること
  • 困っていること
• これにより、スプリントがゴールに向かって進んでいるか、作業の進捗はどうなっているか、メンバー間の協力が必要なことがないかなどを確認する
• 開発チームによっては、他の質問を追加したり、進捗状況を可視化するためにスプリントないの残タスクの見積もり時間の合計、もしくは残タスク数をプロットしたグラフを更新したりする
• デイリースクラムは開発チームのための会議であり、特定の誰かに向けての報告会議ではない
• 問題解決の場ではない。問題についてはデイリースクラム終了後にあらためて、問題解決に必要な人を集めた別の会議を設定する。
• デイリースクラムの結果を踏まえて、開発チームはスプリントの残り時間でどのように作業を進めるかについて、プロダクトオーナーやスクラムマスターに報告できるようにしておく

スプリントレビュー【会議体3】 †

• 開発チームがスプリント中に作り終わったプロダクトバックログの項目を確認する
• 開発チームは確認用の環境などを用意して、作ったものを見ながら確認できるようにする
• 実際に操作しながらプロダクトオーナーに内容を説明したり、プロダクトオーナーに触ってもらったりする
• プロダクトオーナーはそれを受けて、プロダクトバックログの項目が依頼した通りのものであれば作業完了と判断する
• 依頼したものと異なる場合は、作業は完了していないものとし、プロダクトバックログに戻す
• このように毎スプリントごとにプロダクトが要求通りに作られているかを検査することによって、最後にまとめて確認して多くの手戻りが出たりすることを避ける

• スプリントレビューで確認するのは、あくまでも「実際に動作するプロダクト」

• 以下についても報告・議論を行う
  • 開発チームが完了できなかったプロダクトバックログの項目について説明する
  • プロダクトオーナーがプロダクトの状況やビジネスの環境について説明する
  • プロダクトバックログに追加すべき項目の有無について議論する
  • プロジェクトを進める上で問題となる事項について関係者で議論する
  • 現在の進捗を踏まえて、リリース日や完了日を予測する

• スプリントレビューに使える時間は、1ヶ月スプリントであれば4時間、2週間スプリントであれば2時間となる

スプリントレトロスペクティブ【会議体4】 †

• スプリントの最後に行う
• 直近のスプリントでのプロダクト開発に関わる活動において問題がなかったか、もっと成果を出すためにできることがないか検査を行い、次回のスプリント以降のアクションプランを決める
• より効果のありそうな項目から取り組んで、より成果を出せるように自分たちの仕事のやり方を変えていく

• このように、仕事のやり方を常に検査して、より良いやり方に変え続けていくことはアジャイル開発における大事な点の1つであり、Scrumではスプリント単位でそれが行われる仕組みとなっている

• スプリントレトロスペクティブに使える時間は、1ヶ月スプリントであれば4時間、2週間スプリントであれば2時間となる
• スプリントの期間に関係なく毎週スプリントレトロスペクティブを実施する例もある

スクラムマスター【ロール3】 †

• Scrumのルールや成果物、進め方をプロダクトオーナーや開発チームに理解させ、効果的な実践を促し、Scrumの外にいる人からの妨害や割り込みからプロダクトオーナーや開発チームを守る
• まだScrumに慣れていない段階では、スクラムマスターはプロダクトオーナーや開発チームにScrumのやり方を教えたり、会議の司会進行を行ったりするような先生役やトレーナーとして振る舞うことが多くなる
• 振る舞いに慣れてきたら、プロダクトオーナーや開発チームの求めに応じて作業を助けたり、よりうまく仕事を進められるようなヒントを与えたりする活動にシフトしていく

• スクラムマスターがプロダクトオーナーや開発チームに対して行うことの一例
  • わかりやすいプロダクトバックログの書き方を教える
  • プロダクトバックログの良い管理方法を探す
  • プロダクトオーナーや開発チームにアジャイル開発やScrumについて説明して理解してもらう
  • スプリント計画ミーティングやスプリントレトロスペクティブなどの会議の進行を必要に応じて行う
  • プロダクトオーナーと開発チームの会話を促す
  • プロダクトオーナーや開発チームの生産性が高くなるように変化を促す

• 仕事を進める上での妨げとなっていることをリスト化して、優先順位をつけて解決の方法を検討し、必要に応じて、しかるべき人に解決を依頼するといったことも行う。この際に作成するリストを「妨害リスト」と呼ぶ。

スクラムチーム †

• プロダクトオーナー、開発チーム、スクラムマスターを合わせたチーム

---

• SCRUM BOOT CAMP THE BOOK サポートページ

     

Site admin: anonymous

PukiWiki 1.5.1 © 2001-2016 PukiWiki Development Team. Powered by PHP 5.6.99-hhvm. HTML convert time: 0.154 sec.