「スクラムを活用したアジャイルなプロダクト管理」を読み解く為の「スクラム入門」入門

1,978 views
1,927 views

Published on

名古屋アジャイル勉強会 分科会『スクラムを活用したアジャイルなプロダクト管理』読書会 #1の発表資料。

Published in: Technology

「スクラムを活用したアジャイルなプロダクト管理」を読み解く為の「スクラム入門」入門

  1. 1. 「スクラムを活用したアジャイルな プロダクト管理」を読み解く為の 「スクラム入門」入門 名古屋アジャイル勉強会 分科会 『スクラムを活用したアジャイルなプロダクト管理』読書会 #1 http://goo.gl/m9SwO 2013/04/17(水) You&I
  2. 2. はじめに・・・  書籍『スクラムを活用したアジャ イルなプロダクト管理』(原題 『Agile Product Management with Scrum』)(以降APMS本と表記)には 以下の一文があります。  APMS本 P.xv 本書は、あなたがスクラムを理解し、 プロダクトマネージメントについて の知識を持っている事を前提として います。 2
  3. 3. はじめられるか?  前提からしてハードル高い!?  まずはスクラムの部分について、 PDFで無料公開されているドキュ メントの『スクラム入門』(以降 PRIMERと表記)を元に解説し、 APMS本を読みやすくしようとする のが本ドキュメントの目的です。  http://bit.ly/scrum-primer-ja 3
  4. 4. ジコ、ショウカイ。  H/N:You&I(読み:ユーアンドアイ)  SNS:@you_and_i  出身:生まれも育ちも名古屋市  年齢:30代中盤  本職:商学部出身の職業プログラマ  言語:C++, C#, VB6.0, 日本語COBOL  所属:プログラミング生放送 名古屋支部  名古屋アジャイル勉強会  わんくま同盟 名古屋勉強会 4
  5. 5. スクラム入門について 5
  6. 6. スクラム入門について(1/2)  原題:Scrum Primer  認定スクラムマスター講習などを 行っているScrum Allianceにて公 開されていた資料。  現在は下記サイトに移行中? http://www.scrumprimer.org/  今回の対象の日本語版はVersion 1.2。上記サイトでは2012年末にリ リースされたVersion 2.0が公開さ れています。 6
  7. 7. スクラム入門について(2/2)  Scrumに関する無料の日本語資料 のまとめ http://www.ryuzee.com/contents/b log/5707  上記サイトでドキュメントの書か れた経緯なども紹介されています。  このドキュメントを題材にした理 由は、色々なドキュメントを読ん でみてこれが一番読みやすかった からです。 7
  8. 8. 従来のソフトウェア開発と スクラム 8
  9. 9. 従来のソフトウェア開発とスクラム  従来のやり方の問題点 アイデアを最初に計画に組み込む必 要がある。そしてアイデアはソフト ウェアを動作させた時にまた新たな アイデアが出てくるが、時期的・ソ フトウェアの構造的に変更が難しい 状態になっている。 情報伝達手段としての文書。誤解を 生まないように詳細に書こうとすれ ばページ数が多くなり読まれない。  これらを解決しようという所から 生まれたのがスクラム。 9
  10. 10. スクラム概要 10
  11. 11. スクラム概要 (1/5)  スクラムは、1986年に野中&竹内 両名により発表された論文にて、 日本の製造業における新製品開発 の流れをラグビーのスクラムに例 えられた事にその名前は由来する。 The New New Product Development Game http://hbr.org/1986/01/the-new- new-product-development- game/ar/1 11
  12. 12. スクラム概要 (2/5)  1993年に先の論文を受けて、Ken Schwaber と Jeff Sutherland博士 によってスクラムは形式化されて 今に至ります。  因みにアジャイルマニフェストが 制定されたのは2001年である。 アジャイルソフトウェア開発宣言 http://agilemanifesto.org/iso/ja/ 12
  13. 13. スクラム概要 (3/5)  スクラムは、スプリントと呼ばれ る固定化された作業期間の周期的 繰り返しで開発を行います。  スクラムのテーマ 1. 検査 成果物や進捗の有効性確認 2. 適応 プロダクトのゴールとプロセスを調整 3. 透明性 ※PRIMERでは明記されず 関係者が共通見解を持つよう見える化 13
  14. 14. スクラム概要 (4/5) 1. スプリントの開始時に、チームは 作業リストから顧客の要求項目を 選び、スプリント終了までに選ん だ項目を完了させる事を製品の責 任者と約束します。 2. スプリントの期間中には要求項目 は変更しません。 3. スプリントの期間中は、毎日チー ムは集まって手短に進捗確認を行 い、当日の作業内容を調整します。 14
  15. 15. スクラム概要 (5/5) 4. スプリント終了後に、利害関係者 と共にスプリントで作成された製 品の差分を用いてスプリントを検 査します。 5. チームは、スプリントの検査から 次のスプリントに向けてのフィー ドバックを得ます。 6. チームは、必要に応じてレトロス ペクティブ(ふりかえり)を行いプ ロセスを改善します。 15
  16. 16. http://www.scrumprimer.org/#animeCreative Commons Attribution-NoDerivs 3.0 Unported License 16
  17. 17. スクラムチームの役割 17
  18. 18. スクラムチームの役割 (1/6)  スクラムチームは7±2人で構成さ れる。諸説あるが基本は10名未満。  チームメンバーはずっと同じメン バーで作業を行い、変更は避ける。  スクラムチームの構成 1. プロダクトオーナー(PO) 2. 開発チーム ※PRIMERではチーム 3. スクラムマスター 18
  19. 19. スクラムチームの役割 (2/6) 1. プロダクトオーナーの役割 スクラムチームに必ず1人置く。 製品特性を特定する事により、投資 収益率(ROI)を最大化する事に責任が ある。※売上に対してではない プロダクトバックログの優先順位付 けを継続的に見直し、次のスプリン トの為に、どのプロダクトバックロ グ項目(PBI)が上位にあるべきかを決 めて、リストを洗練します。 スプリントの成果であるインクリメ ントを受け入れるかどうか判断する。 19
  20. 20. スクラムチームの役割 (3/6) 2. 開発チームの役割 自己組織化された集まりで自律的に 行動する。 多能工として職能上の枠を超えて作 業に取り組む。 POが求める製品を実現する為の最適 な方法を決めて、製品を作成する。 20
  21. 21. スクラムチームの役割 (4/6) 3. スクラムマスターの役割 (1/2) スクラムチームに1人置く。 POと開発チームがうまく仕事をこな す為のサーバントリーダー(奉仕者)。 外部の干渉からスクラムチームを守 る役目を負う。 POと開発チーム、そして組織がスク ラムを正しく理解し、実践する事を 支援します。 POとスクラムマスターは兼任しては いけません。 21
  22. 22. スクラムチームの役割 (5/6) 3. スクラムマスターの役割 (2/2) スクラムマスターは、 POと開発チー ムに対して、プロジェクトの問題や スクラムチームの問題について監視 を行い、スクラムチームに直接言う のではなく、異常について気づかせ ます。 スクラムマスターは、特別な権限は 持ちません。それなので直接指示を 出したり、作業割当を行ったりはし ません。 22
  23. 23. スクラムチームの役割 (6/6)  「鶏と豚」でのたとえ話  http://d.hatena.ne.jp/kaorun55/20110328/1301284585  鶏:顧客、豚:スクラムチーム  最近は「海賊と忍者」(アジャイルなゲーム開発より)  http://en.wikipedia.org/wiki/Pirates_versus_Ninjas 23
  24. 24. スクラムの成果物 24
  25. 25. スクラムの成果物 (1/10)  スクラムの成果物には以下の3つ のものがあります。 1. プロダクトバックログ 2. スプリントバックログ 3. プロダクトインクリメント 25
  26. 26. スクラムの成果物 (2/10) 1. プロダクトバックログ (1/7) プロダクトバックログとは 製品のロードマップを示す。 POによって継続的に更新される作業項 目のリスト。作業項目はプロダクトバッ クログ項目(PBI)と呼ばれる。スクラム チームの誰もがPBIを追加する事が出来 る。 PBIには優先順位が付けられている。PO のみが作業の優先順位を変更する事が出 来る。 26
  27. 27. スクラムの成果物 (3/10) 1. プロダクトバックログ (2/7) プロダクトバックログとは(続き) PBIはその作業規模がスクラムチームに よって見積もられている。 近々のリリースに向けてのバックログは リリースバックログと呼ばれます。 POは、リリースに近いPBIほど情報が詳 細化・細分化されるように準備・調整し ます。 27
  28. 28. スクラムの成果物 (4/10) 1. プロダクトバックログ (3/7) PBIとは PBIには顧客要求(顧客に価値をもたらす 作業内容)が含まれる。改善目標や調査 事項、不具合情報等は含まれない。 スクラムでは、PBIの表記方法、見積方 法、優先順位の決定方法については定義 をしていない。各スクラムチームで自由 に決めて良い。 PBIの表記方法には様々なものがあるが、 ユースケースやユーザーストーリーで表 現される事が多い。 28
  29. 29. スクラムの成果物 (5/10) 1. プロダクトバックログ (4/7) PBIとは(続き) PBIは通常ストーリーポイントという単 位で相対的に作業規模が見積られます。 相対見積を行うのは手早くそれなりの精 度で結果を得る為です。 開発チームが1スプリントでこなす事が 出来るストーリーポイント数の平均値を ベロシティと呼び、見積の基準として利 用します。 PBIにはDoneの定義を行い、作業完了の 条件を明確にします。 29
  30. 30. スクラムの成果物 (6/10) 1. プロダクトバックログ (5/7) ユーザーストーリーとは eXtremeProgrammingのプラクティスの 1つで、顧客要求について「事の発端か ら価値の提供」までの流れをEnd-to-End で記述したもの。 通常はアナログに紙ベースでストーリー の管理を行う。1枚のメッセージカード に1つのストーリーを記述する。 30
  31. 31. スクラムの成果物 (7/10) 1. プロダクトバックログ (6/7) ユーザーストーリーとは(続き) INVESTを意識して記述する。 31 Independent ストーリー同士が独立しているか? 優先順位を自由に入れ替え可能か? Negotiable 交渉の余地はあるか? 最初から詳細に書きすぎていないか? Valuable 顧客にとって価値のある内容か? Estimable 見積可能であるか? Sized Right/Small 作業規模が大きすぎないか? 適切な作業規模か? Testable テスト可能か?
  32. 32. スクラムの成果物 (8/10) 1. プロダクトバックログ (7/7) バックロググルーミング(見直し) スプリント中や任意のタイミングで、ス クラムチームによりプロダクトバックロ グに手入れを行います。 PBIについての要求分析、大きい項目の 細分化、新しい項目の追加、既存項目の 再見積などを行い、1つ又は2つ先のス プリントに向けて準備をします。 32
  33. 33. スクラムの成果物 (9/10) 2. スプリントバックログ スプリント計画ミーティングでの成 果物となる。 スプリントバックログの項目は、タ スクと呼ばれ、PBIの項目を具体的な 作業タスクに分割したものとなる。 1タスクは大体1作業者の1日分の 作業規模となる。 PBIが相対見積だったのに対して、タ スクは理想時間で見積を行う。 33
  34. 34. スクラムの成果物 (10/10) 3. プロダクトインクリメント 開発チームによるスプリント作業の 成果物となる。 この製品の”差分”を受け入れるかど うかの判断はPOが行う。 プロダクトインクリメントは、スプ リント期間にテストまで行われてい る。”差分”とはいっても、テスト内 容はこれまでの機能に影響がないか 回帰テストも行われる。 34
  35. 35. スクラムのイベント 35
  36. 36. スクラムのイベント (1/6)  スクラムには5つのイベントがあ ります。 1. スプリント 2. スプリント計画ミーティング 3. デイリースクラム 4. スプリントレビュー 5. スプリントレトロスペクティブ 36
  37. 37. スクラムのイベント (2/6) 1. スプリント 1スプリント=1~4週間の固定化 された作業期間であり、スプリント は周期的にこれを繰り返し行う。 スクラムチームはスプリント期間内 で終わらせる事のできるベロシティ 内に収まる量の作業項目を選び実施 する。 スプリントの期間中には要求項目は 変更しません。変更を受け付けませ ん。 37
  38. 38. スクラムのイベント (3/6) 2. スプリント計画ミーティング 第1部と第2部の2部構成。 第1部では何をするかを決める POと開発チームとで、プロダクトバッ クログを元に今回のスプリントで行う PBIについて内容やDoneの定義を確認し、 実施するPBIの合意を取ります。 第2部ではどのようにやるかを決める 基本的に開発チームのみで、PBIをタス クに分割し、理想時間でタスク作業量を 見積もり、スプリントバックログを作成 します。 38
  39. 39. スクラムのイベント (4/6) 3. デイリースクラム いわゆる朝礼。朝会とも呼ばれる。 毎就業日の定刻に定位置で開発チー ムの全員が参加し、立ったままで行 う10数分の打ち合わせ。 スクラムチーム外の人の立ち会いは 認めるが発言権は認めない。 3つの事について話し議論はしない。 1.前回から何が完了したか、2.次までに 何を完了させるつもりか、3.何か障害に なっている事はあるか。 39
  40. 40. スクラムのイベント (5/6) 4. スプリントレビュー POと開発チームとでスプリントの成 果物であるプロダクトインクリメン トについて、Doneの定義を満たして いるか検査を行う。 POがプロダクトインクリメントを受 け入れるかどうか判断し、拒否され た場合は、開発チームはタスク内容 についてどこまで出来ているのか確 認して、未完了分の見積を行い、プ ロダクトバックログに差し戻す。 40
  41. 41. スクラムのイベント (6/6) 5. スプリントレトロスペクティブ 開発チームは、スプリントのふりか えりを行い、プロセスややり方につ いて改善を行う。PDCAサイクルの Check/Actionの部分。 ふりかえりのやり方としては、デル タ&プラス、KPT(Keep/Problem/Try) などの継続項目と改善項目を挙げる プラクティスが使われる事が多い。 41
  42. 42. スプリントの進捗確認 42
  43. 43. スプリントの進捗確認 (1/3)  通常はタスクボードで作業状況を 見える化します。デイリースクラ ムをこのボードの前で行うと効果 的です。 43 http://oblog.objectclub.jp/mieruka-guide-2
  44. 44. スプリントの進捗確認 (2/3)  タスクの消化状況は、スプリント バーンダウンチャートで見える化 します。 44 http://www.flickr.com/photos/kakutani/2761992149/
  45. 45. スプリントの進捗確認 (3/3)  タスクボードやバーンダウン チャートの更新は、開発チームの メンバーの誰かがデイリースクラ ムのタイミングなどで行います。  これらのタスクボードやバーンダ ウンチャートはスクラムチームメ ンバーの目にとまる場所に貼り出 しておき、いつでも最新の状態を 確認出来る状態を保ちます。 45

×