Agile-development-course-advanced-1-2

30,008 views

Published on

Course materials. 1 of 6

Published in: Technology
  • Be the first to comment

Agile-development-course-advanced-1-2

  1. 1. アジャイル開発手法特論 © 2013 Miho Nagaseアジャイル開発手法特論 2013.6.12
  2. 2. アジャイル開発手法特論 © 2013 Miho Nagase今日やること第1回• イントロダクション• Agile/Scrum概要第2回• 講義「チームで協働する」• 演習2
  3. 3. アジャイル開発手法特論 © 2013 Miho Nagase今日やること第1回➡ イントロダクション• Agile/Scrum概要第2回• 講義「チームで協働する」• 演習3
  4. 4. アジャイル開発手法特論 © 2013 Miho Nagaseイントロダクションアジャイル開発手法特論 第1回
  5. 5. アジャイル開発手法特論 © 2013 Miho Nagaseイントロダクション教員紹介概要目的と狙い授業計画評価質疑応答5
  6. 6. アジャイル開発手法特論 © 2013 Miho Nagase‣ 仕事- アジャイルコンサルタント(現職)- エンジニア → マネージャー → スクラムマスター→コーチ‣ コミュニティ活動- スクラム道スタッフ- Scrum Gathering Tokyo 実行委員長- E-AGILITY協議会委員こんにちは、永瀬美穂です6http://about.me/miho
  7. 7. アジャイル開発手法特論 © 2013 Miho NagaseReference教員紹介7
  8. 8. アジャイル開発手法特論 © 2013 Miho Nagase“”概要8仕事のすすめ方評価されている今日日の常識
  9. 9. アジャイル開発手法特論 © 2013 Miho Nagase“”目的と狙い9実践的な開発手法を学ぶ
  10. 10. アジャイル開発手法特論 © 2013 Miho NagaseImage+courtesy+of+David+Castillo+Dominici+/+FreeDigitalPhotos.net授業計画106/15チームで協働する6/29開発環境について7/6テスト環境等について6/22将来を計画する7/13近い将来を計画する7/27計測し改善する7/20日々の作業をこなす8/3組織的な取り組み
  11. 11. アジャイル開発手法特論 © 2013 Miho NagaseImage+courtesy+of+David+Castillo+Dominici+/+FreeDigitalPhotos.net評価116/15チームで協働する6/29開発環境について7/6テスト環境等について6/22将来を計画する7/13近い将来を計画する7/27計測し改善する7/20日々の作業をこなす8/3組織的な取り組み土曜日掲示→水曜日提出Report10Report10Report10Report10Report10Report 10Report 10exam30
  12. 12. アジャイル開発手法特論 © 2013 Miho Nagaseイントロダクション教員紹介概要目的と狙い授業計画評価質疑応答12
  13. 13. アジャイル開発手法特論 © 2013 Miho Nagase質疑応答13
  14. 14. アジャイル開発手法特論 © 2013 Miho Nagase○○に興味があるからお題について書いてください‣ あなたのお名前‣ 普段やっている仕事や専攻‣ 知識レベル- Q1. アジャイル とか Scrum とか知っている? 聞いたことある? 本読んだ?- Q2. Unixのコマンドを知っている? 使える?‣ この授業を受講する動機や期待14永瀬美穂 ECサイトのプログラマーQ1. NoQ2. Yes
  15. 15. アジャイル開発手法特論 © 2013 Miho Nagase永瀬美穂 ECサイトのプログラマーQ1. NoQ2. Yes○○に興味があるから自己紹介をしよう‣ あなたのお名前‣ 普段やっている仕事や専攻‣ 知識レベル- Q1. アジャイル とか Scrum とか知っている? 聞いたことある? 本読んだ?- Q2. Unixのコマンドを知っている? 使える?‣ この授業を受講する動機や期待15永瀬美穂 ECサイトのプログラマーQ1. NoQ2. Yes○○に興味があるから書いたカードを使って隣の人と自己紹介してみよう
  16. 16. アジャイル開発手法特論 © 2013 Miho Nagase自己紹介をしよう‣ あなたのお名前‣ 普段やっている仕事や専攻‣ 知識レベル- Q1. アジャイル とか Scrum とか知っている? 聞いたことある? 本読んだ?- Q2. Unixのコマンドを知っている? 使える?‣ この授業を受講する動機や期待16永瀬美穂ECサイトのプログラマーQ1. NoQ2. Yes○○に興味があるから書いたカードを使って隣の人と自己紹介してみよう
  17. 17. アジャイル開発手法特論 © 2013 Miho Nagase今日やること第1回イントロダクション• Agile/Scrum概要第2回• 講義「チームで協働する」• 演習17
  18. 18. アジャイル開発手法特論 © 2013 Miho NagaseAgendaアジャイルソフトウェア開発• 背景• アジャイルソフトウェア開発宣言Scrum• Scrumとは何か• Scrumの全体像• Scrumのしくみ18
  19. 19. アジャイル開発手法特論 © 2013 Miho NagaseOxford+Dictionary+/+ロングマン英和辞典アジャイルとは?19agile | ˈædʒəlable to move quickly and easilyable to think and understand quickly”“
  20. 20. アジャイル開発手法特論 © 2013 Miho Nagasehttp://pragprog.com/magazines/2011-02/agile--20
  21. 21. アジャイル開発手法特論 © 2013 Miho Nagasehttp://pragprog.com/magazines/2011-02/agile--21
  22. 22. アジャイル開発手法特論 © 2013 Miho Nagase 22今までうまくいっていたやり方
  23. 23. アジャイル開発手法特論 © 2013 Miho Nagase 23今までうまくいっていたやり方要求分析基本設計機能設計詳細設計コーディング受け入れテストシステムテスト結合テスト単体テスト
  24. 24. アジャイル開発手法特論 © 2013 Miho Nagase今までうまくいっていたやり方‣ 大前提- 変化は激しくない‣ やり方- 綿密に計画を立てる- 立てた計画に従う24どれだけ計画どおりであったか?で評価
  25. 25. アジャイル開発手法特論 © 2013 Miho Nagase7%13%16%19%45%システムの20%の機能がシステムの価値を決めている The+CHAOS+Report,+The+Standish+Group,+2000システム機能の利用度まったく使わないほとんど使わないたまに使うよく使ういつも使う26
  26. 26. アジャイル開発手法特論 © 2013 Miho Nagase 27今までうまくいっていたやり方要求分析基本設計機能設計詳細設計コーディング受け入れテストシステムテスト結合テスト単体テスト・要求は当然変化する・予測は当たらないこんなものが欲しかったわけじゃない!!
  27. 27. アジャイル開発手法特論 © 2013 Miho Nagase受け入れなければいけない現実28‣ 状況は必ず変化する- 重厚長大な計画を遵守することのムダ- 綿密すぎる計画をたてることのムダ‣ 予測は当たるとは限らない- 不確実性コーン
  28. 28. アジャイル開発手法特論 © 2013 Miho Nagase‣ 初期の見積もりは1/4∼4倍の誤差があるということ- PMBOKでは超概算見積の精度は-50%∼+100%Boehm,+B+(1981).+Software+Engineering+Economics,+PrenticeOHall.+/+Software+Project+Survival+Guide+(McConnell+1997)不確実性コーン30
  29. 29. アジャイル開発手法特論 © 2013 Miho Nagase‣ 1994年∼2001年世界売上高50位にとどまることができた平均年数は4.8年‣ 経営戦略の見直しや変更がいつどの程度起こるのか予測しにくくなっているITアーキテクト+vol.12,+2007経営戦略の短命化31ビジネスモデルの賞味期限が短くなった
  30. 30. アジャイル開発手法特論 © 2013 Miho NagaseIT活用のコモディティ化‣ IT投資の種類- 基盤関連投資- 業務効率化投資- 情報活用投資- 戦略的投資32事業を創造したいコストを抑えたいサービスを創造したいだいたいやり切ったはずより価値の高いIT投資が求められている
  31. 31. アジャイル開発手法特論 © 2013 Miho Nagaseテクノロジーの進歩‣ ハードウェア性能の劇的な向上‣ 技術や技法の進化‣ 集合知の活用33迅速にものを作れる状況が整ってきた
  32. 32. アジャイル開発手法特論 © 2013 Miho Nagaseアジャイルにならざるを得ない背景‣ 価値を決めるのは顧客- 20%の機能がシステムの価値を決定づける‣ 変化は避けられないことを認めてうまく乗りこなす術- 初期にすべての要求を洗い出すのはほぼ不可能- 分析・設計という行為は新しい要求を生む‣ 現実的な予測にしか意味はない- 動くソフトウェアが進捗そのもの- 計画は死守するものではなくフォーキャスト- もっとも価値のあるものを価値のあるタイミングで34
  33. 33. アジャイル開発手法特論 © 2013 Miho Nagase‣ 同時期にいろいろな人が提唱し始めた課題に対応する様々な方法論35Crystal CleareXtreme ProgrammingFeature Driven DevelopmentAdaptive SoftwareDevelopmentDynamic SystemsDevelopment MethodScrum
  34. 34. アジャイル開発手法特論 © 2013 Miho Nagase共通する特徴36Crystal CleareXtreme ProgrammingFeature Driven DevelopmentAdaptive SoftwareDevelopmentDynamic SystemsDevelopment MethodScrumAgile SoftwareDevelopment‣ 細かく軌道修正してビジネスの要求に沿い続ける‣ 顧客と開発者が協調して進めるアジャイルソフトウェア開発宣言
  35. 35. アジャイル開発手法特論 © 2013 Miho Nagaseアジャイル開発以前の課題‣ 標準的な手順- 従うことが目的になってしまう‣ ドキュメント重視- 絵に描いた餅で議論する‣ 契約の遵守- 人や組織の壁がムダを生む‣ 計画が絶対- 計画はいつでも正しいというのは誤解37
  36. 36. アジャイル開発手法特論 © 2013 Miho Nagase“”http://agilemanifesto.org/iso/ja/アジャイルソフトウェア開発宣言38Kent BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin FowlerJames GrenningJim HighsmithAndrew HuntRon JeffriesJon KernBrian MarickRobert C. MartinSteve MellorKen SchwaberJeff SutherlandDave Thomas
  37. 37. アジャイル開発手法特論 © 2013 Miho Nagasehttp://agilemanifesto.org/iso/ja/アジャイル宣言 : 4つの価値‣ プロセスやツールよりも個人と対話を重視する‣ 包括的なドキュメントよりも動くソフトウェアを重視する‣ 契約交渉よりも顧客との協調を重視する‣ 計画に従うことよりも変化への対応を重視する39左を軽んじるのではなく右をもっと重んじる
  38. 38. アジャイル開発手法特論 © 2013 Miho Nagasehttp://agilemanifesto.org/iso/ja/principles.htmlアジャイル宣言 : 12の原則(1)‣ 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。‣ 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。‣ 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。40
  39. 39. アジャイル開発手法特論 © 2013 Miho Nagasehttp://agilemanifesto.org/iso/ja/principles.htmlアジャイル宣言 : 12の原則(2)‣ ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。‣ 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。‣ 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。41
  40. 40. アジャイル開発手法特論 © 2013 Miho Nagasehttp://agilemanifesto.org/iso/ja/principles.htmlアジャイル宣言 : 12の原則(3)‣ 動くソフトウェアこそが進捗の最も重要な尺度です。‣ アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。‣ 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。42
  41. 41. アジャイル開発手法特論 © 2013 Miho Nagasehttp://agilemanifesto.org/iso/ja/principles.htmlアジャイル宣言 : 12の原則(4)‣ シンプルさ(ムダなく作れる量を最大限にすること)が本質です。‣ 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。‣ チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。43
  42. 42. アジャイル開発手法特論 © 2013 Miho Nagase7th+annual+state+of+agile+development+survey,+2013,+VersionOne利用されている方法論441%1%1%2%2%2%2%4%4%7%9%11%54%ScrumScrum/XP HybridCustom HybridScrumbanKanbanDon’t knowXPFDDLeanOtherAgile Unified ProcessAgile ModelingDSDM Atern
  43. 43. アジャイル開発手法特論 © 2013 Miho NagaseKanban+vs+Scrum+O+Henrik+Kniberg開発プロセスはツール‣ プラクティスの多さによる分類適応的 計画重視Kanban(3)Scrum(10)XP(13)RUP(120↑)DoWhatever(0)45
  44. 44. アジャイル開発手法特論 © 2013 Miho Nagaseいくつかの手法‣ 扱う範囲による違い組織経営マネージメント開発チームLeanScrumXP46
  45. 45. アジャイル開発手法特論 © 2013 Miho Nagaseflickr - ksantome方法論はいろいろ47
  46. 46. アジャイル開発手法特論 © 2013 Miho Nagase計画駆動型開発とアジャイル開発48計画駆動型開発 アジャイル開発立ち上げ計画見積見積単位パラメータ価値提供成功の基準品質リスク管理文化情報共有ツール使用プロジェクト憲章など インセプションデッキなど初期にすべてを計画する 全体をざっくり、直近を詳細にPMが一人で見積もる チーム全員で見積もる絶対的 相対的QCD QCDSプロジェクト完了時 優先順位に従って順次計画通りだったか 現実に対応できたか終盤でテストを実施して確保 序盤から作りこみPMBOK等では規定されている 検査と適応を常時行うコマンド&コントロール 協調的リーダーシップ、自己組織化ドキュメント、形式知重視 会話、暗黙知重視時に政治的、慣行的に選択 人的負担軽減のための自動化
  47. 47. アジャイル開発手法特論 © 2013 Miho NagaseAgendaアジャイルソフトウェア開発背景アジャイルソフトウェア開発宣言Scrum• Scrumとは何か• Scrumの全体像• Scrumのしくみ49
  48. 48. アジャイル開発手法特論 © 2013 Miho Nagase“”スクラムガイド+スクラム完全ガイド:ゲームのルール+2011年10月,+Ken+Schwaber+and+Jeff+Sutherland,+日本語版+角正典Scrumとは何か•••50
  49. 49. アジャイル開発手法特論 © 2013 Miho Nagase“”スクラムガイド+スクラム完全ガイド:ゲームのルール+2011年10月,+Ken+Schwaber+and+Jeff+Sutherland,+日本語版+角正典Scrumとは何か51“フレームワーク”
  50. 50. アジャイル開発手法特論 © 2013 Miho NagaseフレームワークとしてのScrum‣ プロセスや技法ではない。‣ さまざまなプロセスや技法を取り入れることができる。‣ プロダクト管理や開発プラクティスの相対的効果を明確にすることで、改善を可能にする。52様々な技法を取り入れることのできる枠組み
  51. 51. アジャイル開発手法特論 © 2013 Miho Nagaseスクラムの三本柱透明性 検査 適応53
  52. 52. アジャイル開発手法特論 © 2013 Miho Nagase透明性‣ 見える化- 視認でき計測可能な状態を作ること‣ 共通認識- 全員が合意できること‣ 正直さ- 隠せない誤魔化せない嘘をつけない- 問題対私たち54
  53. 53. アジャイル開発手法特論 © 2013 Miho Nagase検査‣ チェックポイント- スクラムイベント- いつでも!!‣ 計測- 見える化されていることが前提- 異常がないかこまかくチェックする55
  54. 54. アジャイル開発手法特論 © 2013 Miho Nagase適応‣ 改善- より良くしていくこと- 想定外の情報こそが有益な情報- 失敗が唯一のドライバー- 小さな傷が広がる前に治すこと56
  55. 55. アジャイル開発手法特論 © 2013 Miho NagaseScrumのしくみ‣ 反復的漸進的にプロダクトを届ける- 常に動く状態にしておく- 常に利用可能な状態にしておく‣ フィードバックループを回し続ける- プロダクトに対するフィードバック- プロセスに対するフィードバック57改善に終わりはない
  56. 56. アジャイル開発手法特論 © 2013 Miho NagaseScrumで定義されていること‣ 3つのロール‣ 5つのタイムボックス‣ 3つの成果物‣ Done の定義58
  57. 57. アジャイル開発手法特論 © 2013 Miho NagaseScrumで定義されていること‣ 3つのロール- プロダクトオーナー- 開発チーム- スクラムマスター‣ 5つのタイムボックス‣ 3つの成果物‣ Done の定義59
  58. 58. アジャイル開発手法特論 © 2013 Miho Nagase✔ ✔ ✔3つのロール60
  59. 59. アジャイル開発手法特論 © 2013 Miho Nagase3つのロール61‣ ロールとは 役割 のこと‣ プロダクトを作ることに寄与する人たちはいずれかのロールにあてはまる‣ プロダクトオーナーは 何を作るか に責任を持つ人‣ 開発チームは どう作るか と 作ること に責任を持つ人‣ スクラムマスターは うまくいくしくみ に責任を持つ人‣ この3者をまとめて スクラムチーム と呼ぶ
  60. 60. アジャイル開発手法特論 © 2013 Miho Nagaseさながらこんな感じ62‣ プロダクトオーナーはカーレーサー- 効率よくゴールへ向かう- ハンドルを微調整する‣ 開発チームはレーシングカー- エンジンそのもの‣ スクラムマスターはメカニック- データを元に燃費やペースを分析する- ドライバーに助言をする- 車をメンテナンスする
  61. 61. アジャイル開発手法特論 © 2013 Miho Nagase顧客(Customer)は?‣ スクラムでは顧客のロールは定義されていない‣ 利害関係者(ステークホルダー)の中でも重要‣ 顧客の声に耳を傾けることは大切- 顧客の声は正しいとは限らない- 顧客を観察しよう- 顧客のフィードバックをもらおう63
  62. 62. アジャイル開発手法特論 © 2013 Miho NagaseScrumで定義されていること‣ 3つのロール‣ 5つのタイムボックス- スプリント- スプリント計画ミーティング- デイリースクラム- スプリントレビュー- スプリントレトロスペクティブ‣ 3つの成果物‣ Done の定義64
  63. 63. アジャイル開発手法特論 © 2013 Miho Nagase5つのタイムボックス65✔✔ ✔✔
  64. 64. アジャイル開発手法特論 © 2013 Miho Nagase5つのタイムボックス66‣ タイムボックスとは固定された 時間の箱 のこと‣ Scrumのしくみをうまく働かせるための機会- 1週間∼4週間の固定の期間(スプリント)で動くものを作り続ける- スプリント計画ミーティングでスプリントの過ごし方を計画する- デイリースクラムで毎日異常がないか検査する- スプリントレビューで作ったものを確認し改善する- スプリントレトロスペクティブでやり方を確認し改善する
  65. 65. アジャイル開発手法特論 © 2013 Miho NagaseScrumのタイムボックス67月 火 水 木 金 土 日9:00-9:15 デイリースクラム9:00-9:15 デイリースクラム9:00-9:15 デイリースクラム 9:15-13:15スプリントレビュー14:00-18:00ふりかえり9:00-9:15 デイリースクラム9:00-13:00スプリント計画第1部14:00-18:00スプリント計画第2部月曜日開始4週間スプリントの例
  66. 66. アジャイル開発手法特論 © 2013 Miho NagaseScrumで定義されていること‣ 3つのロール‣ 5つのタイムボックス‣ 3つの成果物- プロダクトバックログ- スプリントバックログ- インクリメント‣ Done の定義68
  67. 67. アジャイル開発手法特論 © 2013 Miho Nagase3つの成果物69✔ ✔✔
  68. 68. アジャイル開発手法特論 © 2013 Miho Nagase3つの成果物70‣ Scrumの成果物は アクションを促す もの- 誰もが見られて触れる状態にしておく‣ プロダクトバックログ- やりたいことが優先順位順に並べられたリスト- プロダクトオーナーが優先順位を決定する‣ スプリントバックログ- スプリントで実施する開発チームのためのタスクリスト‣ インクリメント- 何が終わっているか明確でないと出荷判断できない
  69. 69. アジャイル開発手法特論 © 2013 Miho NagaseScrumで定義されていること‣ 3つのロール‣ 5つのタイムボックス‣ 3つの成果物‣ Done (完了)の定義71
  70. 70. アジャイル開発手法特論 © 2013 Miho NagaseDone (完了)の定義72✔
  71. 71. アジャイル開発手法特論 © 2013 Miho NagaseDone (完了)の定義73‣ 何をもって終わったというのか を決めたもの‣ これを満たしているインクリメントは出荷判断が可能になる‣ 品質基準と考えていい- 例• リポジトリにソースがチェックインされていること• テストカバレッジが80%以上であること• 本番環境にデプロイしても通常通り動作すること
  72. 72. アジャイル開発手法特論 © 2013 Miho Nagase今日やること第1回イントロダクションAgile/Scrum概要第2回• 講義「チームで協働する」• 演習74
  73. 73. アジャイル開発手法特論 © 2013 Miho Nagaseチームで協働するアジャイル開発手法特論 第2回
  74. 74. アジャイル開発手法特論 © 2013 Miho NagaseImage+courtesy+of+David+Castillo+Dominici+/+FreeDigitalPhotos.net6/15チームで協働する6/29開発環境について7/6テスト環境等について6/22将来を計画する7/13近い将来を計画する7/27計測し改善する7/20日々の作業をこなす8/3組織的な取り組みチームで協働する
  75. 75. アジャイル開発手法特論 © 2013 Miho NagaseAgendaなぜチームで協働するのか自己組織化とはScrumで定義された役割• プロダクトオーナー• 開発チーム• スクラムマスター77
  76. 76. アジャイル開発手法特論 © 2013 Miho Nagase顧客が本当に欲しかったもの78
  77. 77. アジャイル開発手法特論 © 2013 Miho Nagase全員が同じゴールを目指すために79‣ こんなカーナビゲーションシステムはどう?- 目的地の設定• どこが目的地かドライバーにもわからない• ひとたび目的地が設定されたら簡単に変更ができない- ルートの設定• 渋滞情報が見えない• 交通状況が変化してもルート再検索をしない- ナビゲーション• 10km道なりでも200mおきに「まだこのまま」と言う
  78. 78. アジャイル開発手法特論 © 2013 Miho Nagase次はどうしたらいいんだろコマンド&コントロール80
  79. 79. アジャイル開発手法特論 © 2013 Miho Nagase全員が同じゴールを目指すために81‣ こんなカーナビゲーションシステムはどう?- 目的地の設定• 目的地がわかる• 同等の施設があれば教えてくれる- ルートの設定• 渋滞情報が可視化されている• ほぼリアルタイムで交通状況に合わせ再検索できる- ナビゲーション• 10km道なりなら「10km道なりです」と言う
  80. 80. アジャイル開発手法特論 © 2013 Miho Nagaseよけよう後について行こうこっちから行けばいいんだなぶつからないようにしよう自己組織化された人々82
  81. 81. アジャイル開発手法特論 © 2013 Miho Nagaseワークショップ自己組織化ゲーム83
  82. 82. アジャイル開発手法特論 © 2013 Miho Nagaseなぜチームで協働するのか‣ 目的- 共通のゴールにたどり着く- ビジョンを実現する‣ 自己組織化した人々が作業したほうが柔軟で創造性に富み、生産性も最適化される‣ 目的が明確でやることがシンプルであれば現場判断に任せたほうが良い結果が出る84
  83. 83. アジャイル開発手法特論 © 2013 Miho Nagase自己組織化とは‣ 誰の指揮命令を受けなくても、自分たちで自分たちのやり方を考えながら課題を解決していくさま‣ 効率と効果を獲得するしくみ- 自分たちで課題を解決する- 知恵を出しあって相互作用する- ゴールに到達するために行うすべてのことの権限を持つ85
  84. 84. アジャイル開発手法特論 © 2013 Miho Nagase自己組織化を阻む方法‣ 自己組織化を阻害するには?86
  85. 85. アジャイル開発手法特論 © 2013 Miho Nagase実際の仕事だと難しい…‣ だって…- 先のことはわからないし- 壮大なプロジェクトだし- やることはいっぱいあるし87ならば、ゴールを明確にして作業をシンプルにすればいい
  86. 86. アジャイル開発手法特論 © 2013 Miho NagaseそのためのしくみがScrum88
  87. 87. アジャイル開発手法特論 © 2013 Miho NagaseAgendaなぜチームで協働するのか自己組織化とはScrumで定義された役割• プロダクトオーナー• 開発チーム• スクラムマスター89
  88. 88. アジャイル開発手法特論 © 2013 Miho Nagase3つの役割‣ プロダクトオーナー‣ 開発チーム‣ スクラムマスター90
  89. 89. アジャイル開発手法特論 © 2013 Miho Nagase鶏と豚91
  90. 90. アジャイル開発手法特論 © 2013 Miho Nagase(C)+KANMEプロダクトオーナー‣ チームの作業の価値を最大限に発揮することに責任を負う役割- プロダクトのビジョンを持つ- プロダクトの成功に責任を持つ- マーケットについての深い知識を持つ- プロダクトに熱意を持つ- 意見は組織の全員に尊重される92
  91. 91. アジャイル開発手法特論 © 2013 Miho Nagase‣ やること- スクラムの力を最大限利用する- Ready なプロダクトバックログをつくる• プロダクトバックログはやりたいことリスト• プロダクトバックログはプロダクトの道標プロダクトオーナーログインする商品をリストするオススメを表示する買い物かごに入れるオーダーを決定するクレジットカードで決済するコンビニ決済する93これをいかに準備するかプロダクトバックログ リリース判断可能なプロダクト
  92. 92. アジャイル開発手法特論 © 2013 Miho Nagaseプロダクトオーナー‣ やること(くわしく)- ビジョンやゴールやプロダクトバックログ項目について開発チームと明確に共有する- プロダクトバックログの優先順位を決める- チームの成果を最大限にする- プロダクトバックログを見える化し、チームが次にやることが明確であるようにする- プロダクトバックログの項目をチームが理解できるレベルにする94
  93. 93. アジャイル開発手法特論 © 2013 Miho Nagaseスプリントの中止‣ プロダクトオーナーだけが中止させる権限を持つ- スプリントゴールが世の中にマッチしなくなった場合- スケジュールが全然守れそうにない場合‣ 何をするか- Doneになったものを確認する- Doneになっていないものは再見積もりをしてプロダクトバックログに戻す95
  94. 94. アジャイル開発手法特論 © 2013 Miho Nagase(c)+KAME‣ 作業する役割- プロダクトバックログ項目をソフトウェアとして実現する- クロスファンクショナル- ドメインに特化したサブチームはいない開発チーム96
  95. 95. アジャイル開発手法特論 © 2013 Miho Nagase‣ やること- 動くソフトウェアを作る開発チームDB出力ToDo Doing DoneAjaxの実装画面の表示“Done!”ログインする商品をリストするオススメを表示する買い物かごに入れるオーダーを決定するクレジットカードで決済するコンビニ決済する“Ready!”Software97(c)+KAME
  96. 96. アジャイル開発手法特論 © 2013 Miho Nagase自己組織化 する‣ 最適な人数は6 3人‣ 効率と効果を獲得するしくみ- 自分たちで課題を解決する- 知恵を出しあって相互作用する- ゴールに到達するために行うすべてのことの権限を持つ‣ メンバー構成が変われば生産性は変わる98
  97. 97. アジャイル開発手法特論 © 2013 Miho Nagase開発チーム‣ 動くソフトウェアを作るためには何をやってもいい!- スクラムマスターを雇う- スクラムマスターを解雇できる99
  98. 98. アジャイル開発手法特論 © 2013 Miho Nagase(C)+KAMEスクラムマスター‣ やること- スクラムチームがスクラムを理解し、プラクティスやルールを守ってもらうようにする100
  99. 99. アジャイル開発手法特論 © 2013 Miho Nagase(C)+KAMEスクラムマスター‣ やること:プロダクトオーナーを支援する- プロダクトバックログの効率的な管理方法を探す- 開発チームに言ってわかりやすいプロダクトバックログ項目を作ってもらう- 経験主義の中での長期にわたるプロダクト計画を理解する- アジャイルを理解し実践する- 状況に応じてスクラムイベントをファシリテートする101
  100. 100. アジャイル開発手法特論 © 2013 Miho Nagaseスクラムマスター‣ やること:開発チームを支援する- 自己組織化と機能横断についてコーチする- 高価値のプロダクトを作る方法を教育し指導する- 開発チームの進捗の妨げになるものを排除する- 状況に応じてスクラムイベントをファシリテートする- スクラムがまだ完全に適用、理解されていない現場でコーチする102(C)+KAME
  101. 101. アジャイル開発手法特論 © 2013 Miho Nagaseスクラムマスター‣ やること:組織を支援する- スクラムの採用と導入について指導、コーチする- スクラムの推進を計画する- スクラムや経験主義的プロダクト開発について社員や関係者に理解してもらう- スクラムチームの生産性を高めるような変化を促す- 他のスクラムマスターと一緒になって、スクラムの組織への導入効果を高める103(C)+KAME
  102. 102. アジャイル開発手法特論 © 2013 Miho Nagase(C)+KAMEスクラムマスター‣ スクラムマスターは、スクラムチームにとってのサーヴァント・リーダー傾聴共感癒し気づき説得概念化先見力スチュワードシップ 人の成長に関わるコミュニティ作り104
  103. 103. アジャイル開発手法特論 © 2013 Miho Nagase(C)+KAMEスクラム以前のマネージャ‣ プロダクトオーナーに移行するには- プロダクトマネージャは向いてるかも- プロジェクトマネージャも向いてるかも105
  104. 104. アジャイル開発手法特論 © 2013 Miho Nagase(C)+KAMEスクラム以前のマネージャ‣ スクラムマスターに移行するには- 分担(アサイン)を決めるのをやめる- 報告を上げさせるのをやめる- 問題解決策を決めることをやめる- チームに指示することをやめる俺の出番がないぞ…106
  105. 105. アジャイル開発手法特論 © 2013 Miho Nagaseby+Jeff+Sutherlandスクラム以前のロールチーフプロダクトオーナーチームプロダクトオーナースクラムマスター支援ロール チームプロダクトマネージャプロジェクトマネージャビジネスアナリストプログラムマネージャ管理職/ラインマネージャ顧客テスターアーキテクト開発者UCD (UXデザイナー)テクニカルライターDB管理者運用担当者107
  106. 106. アジャイル開発手法特論 © 2013 Miho Nagaseスクラム以前のロールチーフプロダクトオーナーチームプロダクトオーナースクラムマスター支援ロール チームプロダクトマネージャ ○ ○プロジェクトマネージャ ○ ○ ○ビジネスアナリスト ○ ○ ○ ○プログラムマネージャ ○ ○管理職/ラインマネージャ ○ ○ ○ ○顧客 ○ ○ ○テスター ○ ○アーキテクト ○ ○開発者 ○ ○UCD (UXデザイナー) ○ ○テクニカルライター ○ ○DB管理者 ○ ○運用担当者 ○ ○108by+Jeff+Sutherland
  107. 107. アジャイル開発手法特論 © 2013 Miho Nagase(C)+KAMEロールの兼任‣ スクラムマスターかつプロダクトオーナー- 健全な利害対立が必要- つまりかなり無理あの人どっちの立場なんだろ…109
  108. 108. アジャイル開発手法特論 © 2013 Miho Nagaseロールの兼任‣ プロダクトオーナーかつチームステークホルダーと調整する時間がないなあ…タスクもやらなきゃ…110(C)+KAME
  109. 109. アジャイル開発手法特論 © 2013 Miho Nagaseロールの兼任‣ スクラムマスターかつチームプロダクトオーナーのプレッシャーから守らなきゃ…タスクもやらなきゃ…111(C)+KAME
  110. 110. アジャイル開発手法特論 © 2013 Miho Nagase結論:兼任はしないほうがいい‣ 帽子の色分けを相当はっきりとする必要がある‣ スクラムチームが成熟してないとかなり無理112応用は基本ができてから
  111. 111. アジャイル開発手法特論 © 2013 Miho NagaseAgendaなぜチームで協働するのか自己組織化とはScrumで定義された役割プロダクトオーナー開発チームスクラムマスター113
  112. 112. アジャイル開発手法特論 © 2013 Miho Nagase教科書と参考図書114http://bit.ly/scrumbcbook http://www.scrum.org/Scrum-Guides
  113. 113. アジャイル開発手法特論 © 2013 Miho Nagase質疑応答115
  114. 114. アジャイル開発手法特論 © 2013 Miho Nagase今日やること第1回イントロダクションAgile/Scrum概要第2回講義「チームで協働する」演習116
  115. 115. アジャイル開発手法特論 © 2013 Miho Nagase今日やること第1回イントロダクションAgile/Scrum概要第2回講義「チームで協働する」演習117
  116. 116. アジャイル開発手法特論 © 2013 Miho Nagase本日の課題(レポート)118Scrumの全体像を表す一枚絵をあなたの理解で書いてください

×