Scrum"再"入門
Upcoming SlideShare
Loading in...5
×
 

Scrum"再"入門

on

  • 2,545 views

名古屋アジャイル勉強会 Srcum"再"入門

名古屋アジャイル勉強会 Srcum"再"入門
http://blogs.yahoo.co.jp/nagoya_agile_study_group/36920922.html

Statistics

Views

Total Views
2,545
Views on SlideShare
2,396
Embed Views
149

Actions

Likes
4
Downloads
25
Comments
0

4 Embeds 149

http://devlog.mitsugeek.net 57
http://d.hatena.ne.jp 46
http://monasan.info 40
https://twitter.com 6

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Scrum"再"入門 Scrum"再"入門 Presentation Transcript

  • 名古屋アジャイル勉強会 Scrum"再"入門 2012年11月24日(土) You&I 1
  •  H/N: You&I(読み:ユーアンドアイ) 出身: 生まれも育ちも名古屋市 年齢: 30代中盤 本職: 商学部出身の職業プログラマ 言語: C++, C#, VB6.0, 日本語COBOL 日記: http://d.hatena.ne.jp/youandi/ 所属: プログラミング生放送 名古屋支部 名古屋アジャイル勉強会
  • 本資料は後日公開致します。 資料の内容について全てのメモを取る必要はありません。 セッション内容に集中して 頂ければ幸いです。 3
  • 1. 本セッションの位置付け2. "アジャイルな開発"とは3. Scrumガイド4. Scrumの三本柱5. Scrumの四つのイベント6. Scrumチームと三つの役割7. Scrumにおける三つの成果物 4
  • 1. 本セッションの位置付け2. "アジャイルな開発"とは3. Scrumガイド4. Scrumの三本柱5. Scrumの四つのイベント6. Scrumチームと三つの役割7. Scrumにおける三つの成果物 5
  • 2012年5月26日(土)開催の 「Scrum Boot Camp in 名古屋」 http://atnd.org/events/274812012年5月23日(水)開催の 分科会 Scrum入門読書会 https://sites.google.com/site/nagoyaagile/ Home/subcommittee/scrum- primer/questions 6
  • この2つのイベントの内容を土台にScrumについて得られた知見をふり かえる事で、Scrumについての理 解を更に深めるものです。イベントに参加されていない方にも理 解できるように整理を行っています。 7
  • 資料の説明の流れだったり、説明内容はScrum Boot Camp in 名古屋のメイン講師を務めま した永瀬美穂さんの発表資料を参考にしていま す。というか、イベント参加者には再配布禁止で期間 限定で公開されたその資料の要点のみを抜き出 した劣化コピーとなります。 8
  • 1. 本セッションの位置付け2. "アジャイルな開発"とは3. Scrumガイド4. Scrumの三本柱5. Scrumの四つのイベント6. Scrumチームと三つの役割7. Scrumにおける三つの成果物 9
  •  そもそも"アジャイルな開発"とは? You Cant Do Agile  by Dave Thomas  http://pragprog.com/magazines/2011- 02/agile-- 10
  •  But friends, agile is not a noun. It’s an adjective, meaning to be able to move quickly and easily. アジャイルというのは名詞ではない。 アジャイルは、素早くそして機敏に動く事ができる。 という形容詞である。 11
  •  従来のやり方  V字モデル  大規模/大人数/長期間  要求の変化は小さい  書類によるコミュニケーション  手続き型言語 12
  •  ビジネス環境の変化  経営戦略の寿命は2年半  1994年~2001年の期間の世界売上高ランキング上位 50社の平均滞留年数は4.8年。(出典:ITアーキテクト Vol.12(2007年))  経営戦略の見直しや変更の予測が困難 13
  •  ビジネス環境の変化の背景  技術の進歩  ハードウェア性能の向上  技術や技法の進化  インターネットの普及  オープンソースソフトウェア(OSS)  集合知  これらを利用した破壊的イノベーションをもたらす製品 の登場 14
  •  今までうまくいっていた???やり方  計画ありき、計画の軌道修正なし  失敗したらやり直せば良い  故障等したら替わりを用意すれば良い  プロジェクトの障害を想定しない  問題はスーパーヒーローが何とかしてくれる  何とかプロジェクトが終了したら、打ち上げして水に流 す 15
  •  システムの内、使われる機能は全体の20%であ る。この20%がシステムの価値を決めている。 (Chaos Report V3, The Standish Group 2000)  http://www.agilemodeling.com/essays/e xaminingBRUF.htm 16
  •  長期間のプロジェクトのリスク  プロジェクトの終了間際にならないと動くソフトウェアが得ら れない事。 アジャイル開発って  要は小さく細切れにして反復開発する事でしょ?  違います。  Jeff Patton, ThoughtWorks, Successful Incremental Releases, P.40 - P.44  http://www.agileproductdesign.com/downlo ads/patton_incremental_releases_handouts. pdf 17
  • 18
  • 19
  •  今までのやり方との違い 計画駆動開発 アジャイル開発 予言的な計画 適応的な計画 プロセスありき 人ありき 20
  •  リーンソフトウェア開発と組織改革の前書きより  開発者にはeXtreme Programming(XP)の本を  プロジェクトマネージャーにはScrumの本を  そして経営者にはLeanの本を  渡せ by ロジャー・レントン Leanは会社全体、Scrumはプロジェクト全体、 XPは開発向けの様々なアジャイル・プラクティスを 定義している。 これらはツールであるので自由に組み合わせて使 えば良い。 21
  •  2012/05/25(金) 第42回 名古屋アジャイル 勉強会「アジャイルマニフェストから始めるアジャイ ル」  https://sites.google.com/site/nagoyaagile /Home/nagoya_agile_study_event 22
  •  私たちは、ソフトウェア開発の実践あるいは実践を手 助けをする活動を通じて、よりよい開発方法を見つ けだそうとしている。 この活動を通して、私たちは以下の価値に至った。  プロセスやツールよりも個人と対話を、  包括的なドキュメントよりも動くソフトウェアを、  契約交渉よりも顧客との協調を、  計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値がある ことを認めながらも、私たちは右記のことがらにより価 値をおく。 23
  •  アジャイル宣言の背後にある原則 私たちは以下の原則に従う: 1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続 的に提供します。 2. 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き 上げます。 3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ 短い時間間隔でリリースします。 4. ビジネス側の人と開発者は、プロジェクトを通して日々一 緒に働かなければなりません。 24
  • 5. 意欲に満ちた人々を集めてプロジェクトを構成します。環 境と支援を与え仕事が無事終わるまで彼らを信頼します。6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・ トゥ・フェイスで話をすることです。7. 動くソフトウェアこそが進捗の最も重要な尺度です。8. アジャイル・プロセスは持続可能な開発を促進します。一 定のペースを継続的に維持できるようにしなければなりま せん。9. 技術的卓越性と優れた設計に対する不断の注意が機 敏さを高めます。 25
  • 10. シンプルさ(ムダなく作れる量を最大限にすること) が本質です。11. 最良のアーキテクチャ・要求・設計は、自己組織的 なチームから生み出されます。12. チームがもっと効率を高めることができるかを定期的 に振り返り、それに基づいて自分たちのやり方を最適 に調整します。 26
  •  今回は音読しませんが、ここで伝えたい事は  アジャイル開発とは  顧客にとっての価値を一番に考えて  要求の変化は避けられない事を受け入れて  現実的に対応していく  ソフトウェア開発のやり方である。 27
  •  アジャイルプラクティスを実行したからといって、ア ジャイルな開発になっているとは限りません。 アジャイルなやり方(=プラクティス)を学ぶ前に、 アジャイルな考え方(=マニフェスト+12の原則) を学び・身につけましょう。 新しいやり方に変えるには、意識を変える必要。 まずは自分自身から。自分が変わらない事には 周りを変えることはできません。 28
  • 1. 本セッションの位置付け2. "アジャイルな開発"とは3. Scrumガイド4. Scrumの三本柱5. Scrumの四つのイベント6. Scrumチームと三つの役割7. Scrumにおける三つの成果物 29
  •  無料で読めるScrum概要資料  Scrumガイド  http://www.scrum.org/Scrum-Guides  Scrum入門  http://bit.ly/scrum-primer-ja  塹壕より Scrum と XP  http://www.infoq.com/jp/minibooks/scrum- xp-from-the-trenches 30
  •  http://www.scrum.org/Scrum-Guides Scrumは、複雑なプロダクト開発を支援するた めのフレームワークである。 Scrumは、スクラムチームとその役割・イベント・ 成果物・ルールで構成される。それぞれに目的が あり、 Scrumの利用や成功に欠かせないもので ある。 Scrumのルールは、役割・イベント・成果物をま とめ、それらの関係性や相互作用を統括するも のである。 31
  •  資料を読んだだけでScrumを理解し、実践する 事は難しいです。 ScrumにはScrumアライアンスによる認定制度 があります。CSM, CSPO, etc...  http://scrumalliance.org/pages/scrum_ce rtification あとは、今日のイベントのようにワークショップを交 えてフレームワークの理解を深めましょう。 32
  • 1. 本セッションの位置付け2. "アジャイルな開発"とは3. Scrumガイド4. Scrumの三本柱5. Scrumの四つのイベント6. Scrumチームと三つの役割7. Scrumにおける三つの成果物 33
  • 透明性検査適応 34
  • 透明性• 見える化 • 視認でき計測可能な状態を作る事• 共通認識 • 全員が合意できる事• 正直さ • 隠せない、誤魔化せない、嘘をつけない • 問題 対 私達 35
  • 検査• チェックポイント • 4つのスクラムイベント(後述)• 計測 • 見える化されていることが前提 36
  • 適応• 改善 • より良くしていくこと • 想定外の情報こそが肝 • 失敗が唯一のドライバー • 小さな傷が広がる前に治すこと 37
  • 1. 本セッションの位置付け2. "アジャイルな開発"とは3. Scrumガイド4. Scrumの三本柱5. Scrumの四つのイベント6. Scrumチームと三つの役割7. Scrumにおける三つの成果物 38
  • やりたい事 成果物 39
  • やりたい事 成果物プロダクトバック スプリントバック リリース可能に ログ ログ なったもの 40
  • やりたい事 成果物 スプリント レビュー (スプリント デイリース レトロスペ クラム クティブ) スプリント 計画ミー ティングプロダクトバックログ スプリントバックログ リリース可能になったもの 41
  • 1 • スプリント計画ミーティング2 • デイリースクラム3 • スプリントレビュー4 • スプリントレトロスペクティブ 42
  •  Scrumの三本柱と四つのイベント  計画  スプリント計画ミーティング  実施  デイリースクラム  検査と適応  デイリースクラム  スプリントレビュー  スプリントレトロスペクティブ 43
  •  スプリント  1週間~1ヶ月のタイムボックス  期間は固定し、縮めたり、伸ばしたりしない。  スプリントの開始時に決めた「作るもの」は変更しない  変更を行う場合は基本的に次のスプリント以降で行う。  この方針が許容できる長さが適切な実施期間となる。  目的  開発のリズムを作る。フィードバックループの単位。  期間の固定化による、生産性の予測を可能とする。  スプリント中に余計な仕様変更等が入らない安心感。 44
  • 1. スプリント計画ミーティング(1/3)  2部構成で実施する。  第1部  スプリントで「何」を完了させるか決める。  やる事やゴールを決める。  プロダクトオーナーと開発チームとスクラムマスターが参加する。  第2部  スプリントで「どう」完了させるか決める。  機能の実現方法の検討、作業量・作業時間の見積。  開発チームとスクラムマスターが参加する。プロダクトオーナーはい つでも連絡が取れる状態となっていれば良く、参加しない事もある。 45
  • 1. スプリント計画ミーティング(2/3)  第1部の目的  状況確認  プロダクトバックログ(優先順位付けされたやる事リスト)  キャパシティ(開発チームの過去の作業実績の確認)  作るものを決める  スプリントで実施するプロダクトバックログ項目の選択  プロダクトオーナーと開発チームで作業内容について合意する  スプリントゴールを設定する(※オプション)  スプリント毎に達成されるフィーチャーなどを決める事によって、スク ラムチームの目標を明確にしたり他者へ説明しやすくする。 46
  • 1. スプリント計画ミーティング(3/3)  第2部の目的  選択したバックログ項目を実現する為にゴールにたどり着く 方法を計画する。  どこまでできてるか  どのようにやるか  技術的な難易度等  作業内容を適切な大きさにする(タスク作成)  ユーザーストーリーをタスクに落とし込む  タスク=スプリントバックログ項目  タスクの時間見積(タスク作業は理想時間による見積) 47
  • 2. デイリースクラム(1/2)  ルール  毎日決まった時間と場所で立ったまま行う十数分以内の チームミーティング  スプリントバーンダウンチャートやタスクボードの前で行う。  3つの事について話す 1. 前回のデイリースクラムから今までに何をやったか 2. 次のデイリースクラムまでに何をするか 3. 作業の妨げや問題になっている事はなにか  参加者は開発チームとスクラムマスター。それ以外の人の 立ち会いは認めるものの、発言権は与えない。  議論をしない。デイリースクラム終了後にやる。 48
  • 2. デイリースクラム(2/2)  目的  スプリント作業を行う人達の為に行う。  スプリントの完了条件に向かって自分達が何をしているの か説明できるようにする為  余計なミーティングや妨げとなるもの(問題点)を排除する 為  迅速な意志決定を助長する為  チーム内コミュニケーションの促進 49
  • 3. スプリントレビュー(1/2)  スプリントの成果物の確認、リリースバーンダウンチャー トなどで状況確認、プロダクトバックログの改訂  目的  スプリント作業をする人向け  やった事に対するフィードバック及び更なる協力を引き出す  成果物を受け取る人向け  動作する成果物を確認できる  皆にとって  現実についての共通認識を持てる  現実に即した予測ができる 50
  • 3. スプリントレビュー(2/2)  バックロググルーミング(実は4+1のイベント?)  プロダクトバックログのメンテナンス作業。スプリントレビューの タイミングだけでなく、スプリント中の任意のタイミングで実施 する。  スクラムチームで集まってプロダクトバックログ項目の追加・ 削除・優先順位の変更を行います。  スプリント計画ミーティングの開始時には、そのスプリントや 更にその次で実施する分のプロダクトバックログ項目の準備 が整って("Ready")いなければならない。 51
  • 4. スプリントレトロスペクティブ(※オプション)  やる事  スプリント中の人や関係、やり方、方法についてふりかえる。  通常KPTやプラス&デルタなどのプラクティスを使います。  上手くいった事を共有する。  改善点を特定する。  スクラムチーム全体の改善計画を作る。  目的  スクラムチームの「検査と改善」の機会のひとつ  現実に合わせてこまめに軌道修正する 52
  •  Scrumの四つのイベントについて、スクラムチーム や利害関係者(ステークホルダー)の誰が参加す べきなのかをまとめた参考資料  [Agile]Scrumにおける会議体と出席者  http://www.ryuzee.com/contents/blog/3989 53
  • 1. 本セッションの位置付け2. "アジャイルな開発"とは3. Scrumガイド4. Scrumの三本柱5. Scrumの四つのイベント6. Scrumチームと三つの役割7. Scrumにおける三つの成果物 54
  • プロダクトオーナー開発チームスクラムマスター 55
  •  「鶏と豚」でのたとえ話  鶏:顧客、豚:開発チーム  http://d.hatena.ne.jp/kaorun55/20110328/1301284585 最近は「海賊と忍者」  http://en.wikipedia.org/wiki/Pirates_versus_Ninjas 56
  • 1. プロダクトオーナー(1/3)  顧客に一番近い立場。でもスクラムチームの一員。  従来のプロジェクトマネージャーとは役割が大きく異な る。  役割  スクラムチームによる作業が最大限に発揮される事に責任 を負う  プロダクトのビジョンを持つ  プロダクトの成功に責任を持つ  プロダクトに熱意を持つ  マーケットについての深い知識を持つ  意見は組織の全員に尊重される 57
  • 1. プロダクトオーナー(2/3)  やる事  ビジョンやゴールやプロダクトバックログ項目について開発 チームと明確に共有する。  プロダクトバックログの優先順位を決める。  プロダクトバックログを見える化し、開発チームが次にやるべ き事を明確にする。  プロダクトバックログの項目を開発チームが理解できるレベ ルにして"Ready"な状態にする。  開発チームの成果物を受け入れるかどうか判断する。 58
  • 1. プロダクトオーナー(3/3)  スプリントの中止  プロダクトオーナーだけがスプリントを中止させる権限を持つ。  スプリントの完了条件が世の中にマッチしなくなった場合  スケジュールが守れそうにない場合  中止するにあたって何をするか  Doneになったものを確認する  Doneにならないものは再見積してプロダクトバックログに戻す  スプリント中止の儀  スクラムチーム全員で地面に寝転んで15分間手足をバタバ タさせる 59
  • 2. 開発チーム(1/2)  役割  プロダクトバックログ項目をリリース可能なものとして実現。  クロスファンクショナルチーム。  会社組織の部門の垣根や職位など関係なく、目的を達成する為 に部門横断した1つの組織として行動する。  ドメインに特化したサブチームは持たない。  自己組織化して行動する。  管理されたいのであればサボれ。それが嫌ならちゃんとやろう。  by 永和システムマネジメント 角谷信太郎さん  やる事  リリース可能なものを作る 60
  • 2. 開発チーム(2/2)  最適な人数は6±3人  メンバー構成が変われば、生産性は変わる  指標となる生産性=ベロシティ(スプリント毎に完了したス トーリーポイントの合計値)  効率と効果を獲得する仕組み  自分達で課題を解決する  知恵を出し合って相互作用する  ゴールに到達する為に行う全ての事の権限を持つ  スクラムマスターを雇ったり、解雇できる 61
  • 3. スクラムマスター(1/4)  やる事  スクラムチームがScrumを理解し、プラクティスやルールを 守ってもらうようにする。  開発プロセスの監視役ではないので権限を持たない。  スクラムチーム(特に開発チーム)を守る。  会議等のファシリテーター。状況に応じてスクラムイベントを ファシリテートする。  プロダクトオーナーを支援する。  開発チームを支援する。  組織を支援する。 62
  • 3. スクラムマスター(2/4)  プロダクトオーナーへの支援  プロダクトバックログの効率的な管理方法を探す  POに経験主義の中で長期に渡るプロダクト計画を理解し て貰う  POに開発チームにとって理解しやすいプロダクトバックログ 項目を作って貰う  POがアジャイルを理解し実践するのを手助けする  組織内でPOの意見が尊重されるようにする 63
  • 3. スクラムマスター(3/4)  開発チームへの支援  Scrumがまだ完全に適用・理解されていない現場でコー チする  自己組織化と機能横断についてコーチする  高価値のプロダクトを作る方法を教育し指導する  開発チームの進捗の妨げとなるものを排除する  スプリント中の仕様変更  ハードウェア性能不足の解消 64
  • 3. スクラムマスター(4/4)  組織への支援  他のスクラムマスターと一緒になって、Scrumの組織への 導入効果を高める  Scrumの採用と導入について、指導・コーチする  Scrumの推進を計画する  Scrumや経験主義的プロダクト開発について社員や利害 関係者に理解してもらう  スクラムチームの生産性を高めるような変化を促す 65
  •  役割(ロール) の兼任  スクラムマスター兼プロダクトオーナー  止めた方が良い。  プロダクトオーナー兼開発チーム  やってやれなくもない。  スクラムマスター兼開発チーム  やってやれなくもない。 兼任は止めておけ。  責任を明確にする為の役割分担である。 66
  • 1. 本セッションの位置付け2. "アジャイルな開発"とは3. Scrumガイド4. Scrumの三本柱5. Scrumの四つのイベント6. Scrumチームと三つの役割7. Scrumにおける三つの成果物 67
  • プロダクトバックログスプリントバックログリリース可能になったもの 68
  • やりたい事 成果物 スプリント レビュー (スプリント デイリース レトロスペ クラム クティブ) スプリント 計画ミー ティングプロダクトバックログ スプリントバックログ リリース可能になったもの 69
  • 1. プロダクトバックログ(1/2)  プロダクトオーナーがビジョンを実現する為に、やる 事・やりたい事リスト  顧客のやりたい事をプロダクトオーナーが整理したもの  機能要件・非機能要件を含む  プロダクトオーナーが項目に優先順位を付けの責任 を持つ。  スクラムチームのメンバーは誰もが項目を追加する 事ができる。  バックロググルーミング又は任意のタイミング 70
  • 1. プロダクトバックログ(2/2)  各リリースの最初のスプリントが始まる前に作成する  2~4スプリントを経て1リリース  プロダクトバックログ項目は、通常インデックスカード に記述する。以下の様式を利用する事が多い。  ユーザーストーリー  ユースケース  プロダクトバックログ項目は見積もられている。  相対見積でなるべく正確になるように見積もる  優先順位が低いほど見積は粗くて良い 71
  • 2. スプリントバックログ  スプリント計画ミーティング第2部の成果物。  開発チームが、各スプリントで"ここまでできる"と予 測したプロダクトバックログ項目を、タスクに分解した もの。  タスクの項目も通常はインデックスカードに記述する。  タスクボードやKANBANに貼り出される。  タスクの項目も見積もられている。  作業量の見積は理想時間で見積もる。 72
  • 3. リリース可能になったもの  インクリメントなアウトプット  "Potentially Shippable Increment"  このスプリントでShip(出荷)可能になった増分  スプリントレビューにおいて、完了したかどうかプロダク トオーナーが判断する 73
  •  2012/10/26(金) 第47回 名古屋アジャイル 勉強会「スポーツの秋!サッカーマッピングで現状 分析」  https://sites.google.com/site/nagoyaagile /Home/nagoya_agile_study_event 74
  • 75http://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html
  •  仕事を廻していくには、当然ライトウィング側の 「開発環境」の整備も重要ですね。 Scrumとは先のサッカーマッピングでいうなら、ア ジャイルのレフトウィング側の「チーム環境」の整備 を構築する為の人を中心とするフレームワークで す。 やはり、改善の基礎や土台となるのは「人」であ ると思います。その手助けとなるのがこのScrum であると思います。 76
  •  Scrum Boot Camp in 名古屋 発表資料 by スクラム道 永瀬美穂さん リーンソフトウェア開発と組織改革  http://ascii.asciimw.jp/books/books/detail/9 78-4-04-868741-6.shtml アジャイルなゲーム開発  http://www.sbcr.jp/products/4797369731.h tml Scrumガイド  http://www.scrum.org/Scrum-Guides Scrum入門  http://bit.ly/scrum-primer-ja 77