Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile development-course-advanced-3-4

2,362 views

Published on

Course materials. 2 of 6

Published in: Technology
  • You have to choose carefully. ⇒ www.HelpWriting.net ⇐ offers a professional writing service. I highly recommend them. The papers are delivered on time and customers are their first priority. This is their website: ⇒ www.HelpWriting.net ⇐
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Agile development-course-advanced-3-4

  1. 1. アジャイル開発手法特論 © 2013 Miho Nagaseアジャイル開発手法特論 2013.6.22
  2. 2. アジャイル開発手法特論 © 2013 Miho Nagase今日やること第3回• 講義「将来を計画する」• 演習(適宜)第4回• 同上課題2
  3. 3. アジャイル開発手法特論 © 2013 Miho Nagase将来を計画するアジャイル開発手法特論 第3回
  4. 4. アジャイル開発手法特論 © 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組織的な取り組み将来を計画する4
  5. 5. アジャイル開発手法特論 © 2013 Miho NagaseAgendaプロジェクトの立ち上げ• インセプションデッキ• プロジェクト調整のパラメーターScrumの計画のしかた• プロダクトバックログ• 相対見積もり• ベロシティ• リリース計画5
  6. 6. アジャイル開発手法特論 © 2013 Miho Nagaseプロジェクトの立ち上げ‣ Scrumではプロジェクトの立ち上げはカバーしていない- Scrumで扱うのはプロダクトが主体- そもそもScrumは改善しながらうまく進めるための話‣ PMBOKでは立ち上げプロセス群がカバーしている- プロジェクト憲章- プロジェクトマネージャーに対する指示書- 通常はプロジェクトオーナーが作る6「決まりはないしとにかく始めちゃおう」「こういうことだから後は頼んだ」
  7. 7. アジャイル開発手法特論 © 2013 Miho Nagaseプロジェクトの立ち上げ‣ Scrumではプロジェクトの立ち上げはカバーしていない- Scrumで扱うのはプロダクトが主体- そもそもScrumは改善しながらうまく進めるための話‣ PMBOKでは立ち上げプロセス群がカバーしている- プロジェクト憲章- プロジェクトマネージャーに対する指示書- 通常はプロジェクトオーナーが作る7「決まりはないしとにかく始めちゃおう」「こういうことだから後は頼んだ」プロダクトオーナープロジェクトオーナープロジェクトマネージャーの力量に依存しているかなり大変
  8. 8. アジャイル開発手法特論 © 2013 Miho Nagaseロールの復習‣ アジャイルなチームは自己組織化している- 指揮命令による制御はない• 全員が目的を共有している• その上でそれぞれが適切に判断して有機的に動く- ソフトウェアを作ることに寄与する人しか必要ない• 線表を引いて眺めているだけの人は不要• 口だけ出して手は動かさない人は不要• 情報をRetweetしているだけの人は不要- 物事はできるだけシンプルに扱う8
  9. 9. アジャイル開発手法特論 © 2013 Miho Nagaseアジャイルに仕事をすすめるには‣ 変化の波をうまく乗りこなす必要がある‣ 関係する全員の意識合わせが必要- ゴールや目的の共有- 課題の共有‣ さながら試合前のロッカールーム9試合前の準備が重要!
  10. 10. アジャイル開発手法特論 © 2013 Miho Nagase‣ プロジェクトの目的について曖昧なことや誤解があれば潰しておく‣ 対立や不整合がおきそうな部分はどのあたりか見極める‣ プロジェクトが始まる前に課題をあぶり出す‣ 関係者全員の認識を合わせるインセプションデッキ10という目的のための道具
  11. 11. アジャイル開発手法特論 © 2013 Miho NagaseJonathan  Rusmusson,  西村直人(監訳),  角谷信太郎(監訳),  近藤修平(翻訳),  角掛拓未(翻訳),  Pragmatic  Bookshelf  2010,  オーム社  2011インセプションデッキ‣ ThoughtWorks社で使われていたうまいやり方‣ プロジェクトの初期に使うともっとも有効な道具‣ Jonathan Rasmusson氏の著書で有名に11
  12. 12. アジャイル開発手法特論 © 2013 Miho Nagaseアジャイルインセプションデッキ‣ いつ‣ 誰が‣ 何をするのか12
  13. 13. アジャイル開発手法特論 © 2013 Miho Nagaseアジャイルインセプションデッキ‣ いつ- プロジェクトを始める前- ただしプロジェクトの途中でも見直す‣ 誰が‣ 何をするのか13
  14. 14. アジャイル開発手法特論 © 2013 Miho Nagaseアジャイルインセプションデッキ‣ いつ‣ 誰が- プロジェクトに直接関係する人みんなで‣ 何をするのか14
  15. 15. アジャイル開発手法特論 © 2013 Miho Nagaseアジャイルインセプションデッキ‣ いつ‣ 誰が‣ 何をするのか- 1組のスライドを作る- 必要であれば独自のスライドも- すべて完成させなくてもいい- みんなに見えるところに貼りだしておく15
  16. 16. アジャイル開発手法特論 © 2013 Miho Nagase‣ いつ‣ 誰が‣ 何をするのか- 1組のスライドを作る- 必要であれば独自のスライドも- すべて完成させなくてもいい- みんなに見えるところに貼りだしておくアジャイルインセプションデッキ16プロジェクトの開始前に問題をあぶり出して合意するのが目的
  17. 17. アジャイル開発手法特論 © 2013 Miho Nagase日本語版,  0.4:  2012-­‐04-­‐02,  @kakutaniインセプションデッキ17
  18. 18. アジャイル開発手法特論 © 2013 Miho Nagase日本語版,  0.4:  2012-­‐04-­‐02,  @kakutaniインセプションデッキ18
  19. 19. アジャイル開発手法特論 © 2013 Miho Nagase日本語版,  0.4:  2012-­‐04-­‐02,  @kakutaniインセプションデッキ19
  20. 20. アジャイル開発手法特論 © 2013 Miho Nagase日本語版,  0.4:  2012-­‐04-­‐02,  @kakutaniインセプションデッキ20
  21. 21. アジャイル開発手法特論 © 2013 Miho Nagase日本語版,  0.4:  2012-­‐04-­‐02,  @kakutaniインセプションデッキ21
  22. 22. アジャイル開発手法特論 © 2013 Miho Nagase日本語版,  0.4:  2012-­‐04-­‐02,  @kakutaniインセプションデッキ22
  23. 23. アジャイル開発手法特論 © 2013 Miho Nagase日本語版,  0.4:  2012-­‐04-­‐02,  @kakutaniインセプションデッキ23
  24. 24. アジャイル開発手法特論 © 2013 Miho Nagase日本語版,  0.4:  2012-­‐04-­‐02,  @kakutaniインセプションデッキ24
  25. 25. アジャイル開発手法特論 © 2013 Miho Nagase日本語版,  0.4:  2012-­‐04-­‐02,  @kakutaniインセプションデッキ25
  26. 26. アジャイル開発手法特論 © 2013 Miho Nagase日本語版,  0.4:  2012-­‐04-­‐02,  @kakutaniインセプションデッキ26
  27. 27. アジャイル開発手法特論 © 2013 Miho Nagase日本語版,  0.4:  2012-­‐04-­‐02,  @kakutaniインセプションデッキ27
  28. 28. アジャイル開発手法特論 © 2013 Miho Nagase日本語版,  0.4:  2012-­‐04-­‐02,  @kakutaniインセプションデッキ28
  29. 29. アジャイル開発手法特論 © 2013 Miho Nagase日本語版,  0.4:  2012-­‐04-­‐02,  @kakutaniインセプションデッキ29
  30. 30. アジャイル開発手法特論 © 2013 Miho Nagase日本語版,  0.4:  2012-­‐04-­‐02,  @kakutaniインセプションデッキ30プロジェクトの開始前に問題をあぶり出して合意するのが目的再掲
  31. 31. アジャイル開発手法特論 © 2013 Miho Nagase日本語版,  0.4:  2012-­‐04-­‐02,  @kakutaniインセプションデッキ31作りあげたものよりも作る過程そのものが重要!
  32. 32. アジャイル開発手法特論 © 2013 Miho Nagaseワークショップインセプションデッキを作ろう32
  33. 33. アジャイル開発手法特論 © 2013 Miho Nagase日本語版,  0.4:  2012-­‐04-­‐02,  @kakutaniプロジェクト調整のパラメーター33‣ QCDS- Quality(品質)- Cost(費用)- Delivery(納期)- Scope(範囲)
  34. 34. アジャイル開発手法特論 © 2013 Miho Nagase固定する計画駆動の場合34D CS
  35. 35. アジャイル開発手法特論 © 2013 Miho Nagase固定する計画駆動の場合35D CS
  36. 36. アジャイル開発手法特論 © 2013 Miho Nagase固定する計画駆動の場合36D CS
  37. 37. アジャイル開発手法特論 © 2013 Miho Nagase固定する計画駆動の場合37D CS
  38. 38. アジャイル開発手法特論 © 2013 Miho Nagase固定する計画駆動の場合38D CS
  39. 39. アジャイル開発手法特論 © 2013 Miho Nagase固定する計画駆動の場合39D CS
  40. 40. アジャイル開発手法特論 © 2013 Miho Nagase固定する計画駆動の場合40D CS
  41. 41. アジャイル開発手法特論 © 2013 Miho Nagase固定する計画駆動の場合41D CS
  42. 42. アジャイル開発手法特論 © 2013 Miho NagaseQ↓↓↓固定する計画駆動の場合42D CS
  43. 43. アジャイル開発手法特論 © 2013 Miho Nagase固定するアジャイル開発の場合43D CS
  44. 44. アジャイル開発手法特論 © 2013 Miho Nagase固定するアジャイル開発の場合44D CS
  45. 45. アジャイル開発手法特論 © 2013 Miho Nagase固定するアジャイル開発の場合45D CS
  46. 46. アジャイル開発手法特論 © 2013 Miho Nagase固定するアジャイル開発の場合46D CS
  47. 47. アジャイル開発手法特論 © 2013 Miho Nagase固定するアジャイル開発の場合47D CS
  48. 48. アジャイル開発手法特論 © 2013 Miho Nagase固定するアジャイル開発の場合48DSC
  49. 49. アジャイル開発手法特論 © 2013 Miho Nagase固定するアジャイル開発の場合49D CS
  50. 50. アジャイル開発手法特論 © 2013 Miho Nagase固定するアジャイル開発の場合50D CS
  51. 51. アジャイル開発手法特論 © 2013 Miho Nagaseプロジェクトのパラメーター51ここで調整する
  52. 52. アジャイル開発手法特論 © 2013 Miho NagaseQuality(品質)‣ 変動するパラメータではない?52
  53. 53. アジャイル開発手法特論 © 2013 Miho NagaseCost(費用)‣ TCO - Total Cost of Ownership- イニシャルコスト- ランニングコスト53
  54. 54. アジャイル開発手法特論 © 2013 Miho NagaseDelivery(納期)‣ 価値の提供までの時間(time-to-market)54
  55. 55. アジャイル開発手法特論 © 2013 Miho NagaseScope(範囲)‣ スコープ- プロダクトスコープ- プロジェクトスコープ‣ 調整のしかた- 1か0か- 強弱か55
  56. 56. アジャイル開発手法特論 © 2013 Miho Nagase調整のしかた‣ フィーチャーセット固定- 中核をなすフィーチャーのかたまり(フィーチャーセット)はすべて完成させる必要がある場合- フィーチャーセットをやりきるまで続ける- つまり期日を伸ばして調整する‣ 期日固定- リリースの日付がずらせない場合- 期日がくればリリースしなければいけない- つまりフィーチャーセットを出し入れして調整する56
  57. 57. アジャイル開発手法特論 © 2013 Miho Nagaseフィーチャーセット固定57残作業量(見積り)時間フィーチャーセット
  58. 58. アジャイル開発手法特論 © 2013 Miho Nagaseフィーチャーセット固定58残作業量(見積り)時間やることが多ければ期日も伸びる
  59. 59. アジャイル開発手法特論 © 2013 Miho Nagaseフィーチャーセット固定59残作業量(見積り)時間やることが少なければ期日は縮む
  60. 60. アジャイル開発手法特論 © 2013 Miho Nagase日付固定60残作業量(見積り)時間
  61. 61. アジャイル開発手法特論 © 2013 Miho Nagase日付固定61残作業量(見積り)時間増えた
  62. 62. アジャイル開発手法特論 © 2013 Miho Nagase日付固定62残作業量(見積り)時間やりたいことが増えたら
  63. 63. アジャイル開発手法特論 © 2013 Miho Nagase日付固定63残作業量(見積り)時間やらない増えた分だけ総量を調整する
  64. 64. アジャイル開発手法特論 © 2013 Miho NagaseAgendaプロジェクトの立ち上げインセプションデッキプロジェクト調整のパラメーターScrumの計画のしかた• プロダクトバックログ• 相対見積もり• ベロシティ• リリース計画64
  65. 65. アジャイル開発手法特論 © 2013 Miho Nagase将来を計画するアジャイル開発手法特論 第4回
  66. 66. アジャイル開発手法特論 © 2013 Miho NagaseScrumの計画のしかた‣ プロダクトバックログ‣ 相対見積もり‣ ベロシティ‣ リリース計画66
  67. 67. アジャイル開発手法特論 © 2013 Miho Nagase(C)  KANMEプロダクトオーナー‣ チームの作業の価値を最大限に発揮することに責任を負う役割- プロダクトのビジョンを持つ- プロダクトの成功に責任を持つ- マーケットについての深い知識を持つ- プロダクトに熱意を持つ- 意見は組織の全員に尊重される67復習
  68. 68. アジャイル開発手法特論 © 2013 Miho Nagase‣ やること- スクラムの力を最大限利用する- Ready なプロダクトバックログをつくる• プロダクトバックログはやりたいことリスト• プロダクトバックログはプロダクトの道標プロダクトオーナーログインする商品をリストするオススメを表示する買い物かごに入れるオーダーを決定するクレジットカードで決済するコンビニ決済する68これをいかに準備するかプロダクトバックログ リリース判断可能なプロダクト復習
  69. 69. アジャイル開発手法特論 © 2013 Miho Nagaseプロダクトオーナー‣ やること(くわしく)- ビジョンやゴールやプロダクトバックログ項目について開発チームと明確に共有する- プロダクトバックログの優先順位を決める- チームの成果を最大限にする- プロダクトバックログを見える化し、チームが次にやることが明確であるようにする- プロダクトバックログの項目をチームが理解できるレベルにする69復習
  70. 70. アジャイル開発手法特論 © 2013 Miho Nagaseプロダクトバックログ‣ プロダクトバックログ- やりたいことのリスト- プロダクトオーナーが優先順位をつける- 各プロダクトバックログアイテムは見積もられる70
  71. 71. アジャイル開発手法特論 © 2013 Miho Nagaseプロダクトバックログの作り方‣ プロダクトオーナーがたたき台を作る- ステークホルダーに聞いてまわる- たたき台を開発チームに見てもらう‣ 開発チームがたたき台を作る- プロダクトオーナーから聞いてまわる- たたき台をプロダクトオーナーに見てもらう‣ みんなで集まってやりたいことを収集するためのワークショップをおこなう71
  72. 72. アジャイル開発手法特論 © 2013 Miho Nagaseやりたいことを収集する‣ 誰が- プロジェクトに関係する人すべて- とくにビジネスの要件を出す人たち- 当然開発チームの人たちも‣ どうやって- 付箋にたくさん書き出す- 同じ意見はまとめる- 全体を眺めて網羅性を確認する72
  73. 73. アジャイル開発手法特論 © 2013 Miho Nagaseプロダクトバックログ‣ 欲しいものややりたいことのリスト- 機能性- 技術- 課題• ゆくゆくは課題の解決方法で置き換えられる‣ 欲しい順に並べて、上から順に終わらせていく‣ 各項目の呼び方はいろいろ- PBI (Product Backlog Item)- プロダクトバックログ項目73
  74. 74. アジャイル開発手法特論 © 2013 Miho Nagaseプロダクトバックログ項目の一覧74ログインする商品をリストするオススメを表示する買い物かごに入れるオーダーを決定するクレジットカードで決済するコンビニ決済するオーダーをキャンセルする商品を登録するオーダー一覧を見る返品する……高低優先順位 優先度特A超AAAAABB
  75. 75. アジャイル開発手法特論 © 2013 Miho Nagaseプロダクトバックログ項目の条件1‣ 価値があること- 実現されると誰がどう嬉しいのか‣ シンプルに書かれていること- 書かれたことをきっかけに話が始まること‣ 詳細過ぎないこと- 代替手段の可能性が残っていること- その他の項目との依存性が低いこと‣ 実現されたことが確認できる単位- 「動くソフトウェアこそが進捗の最も重要な尺度です」75
  76. 76. アジャイル開発手法特論 © 2013 Miho Nagaseプロダクトバックログ項目の条件2‣ 優先順位の高い項目は適度に具体的であること- 着手できる程度に具体的であること- どうなると「できた!」かわかること- 見積もられていること76優先順位ログインする商品をリストするオススメを表示する買い物かごに入れるオーダーを決定するクレジットカードで決済するコンビニ決済するオーダーをキャンセルする商品を登録するオーダー一覧を見る返品する……詳細荒々
  77. 77. アジャイル開発手法特論 © 2013 Miho Nagase優先順位の順に並べる‣ 比較する- 1つ1つ比較する- いくつかを塊にして塊同士で比較する‣ 優先順位の付け方- 必要な順- やりたいことをウォークスルーする77
  78. 78. アジャイル開発手法特論 © 2013 Miho Nagaseワークショッププロダクトバックログを作ろう78
  79. 79. アジャイル開発手法特論 © 2013 Miho Nagase見積もる‣ 比較して見積もる- 1つ1つ比較する- いくつかを塊にして塊同士で比較する‣ 全員で見積もる‣ ざっくり見積もる79
  80. 80. アジャイル開発手法特論 © 2013 Miho Nagase相対見積もり‣ 絶対的な見積もり- 私の身長は何センチ?- この教室の広さは何平米?‣ 相対的な見積もり- 天井の高さは私の身長と比べると?- あの教室の広さはこの教室の広さと比べると?80
  81. 81. アジャイル開発手法特論 © 2013 Miho Nagaseみんなでざっくり見積もる理由‣ 見積もり自体の合理性- 遠くの見積もりほどあてにならないものはない- 相対的な見積もりのほうが正確なことが多い- 一人でやるより正確なことが多い‣ 見積もり作業の合理性- 精度に命をかけるプレッシャーがない- 見積もる対象に対して共通認識をもてる- 時間をかけない!81見積もりよりも見積もる作業が重要
  82. 82. アジャイル開発手法特論 © 2013 Miho Nagaseプロダクトバックログの見積もり‣ バックログ項目を見積もった大きさ‣ 単位はなんでもいい- 「ポイント」を使うことが多い‣ 大きさ=労力+リスク+不確かさ‣ これらは同じ大きさになる可能性がある- 大量の単純作業- 少しだけど難しそうな作業‣ 必要であればプロダクトバックログ項目を分割する82
  83. 83. アジャイル開発手法特論 © 2013 Miho Nagaseプランニングポーカーを使う‣ 開発チーム全員が見積りに参加できる- 当事者意識を高める- プロジェクトの内容を理解できる良い機会‣ 見積りの偏りが減る- 見逃しや思い込みを避ける- 「俺がやれば…」がなくなる‣ さっさと終わる- うだうだ計画している会議はムダ!‣ 単純に楽しい83
  84. 84. アジャイル開発手法特論 © 2013 Miho Nagaseプランニングポーカーに必要なもの‣ プランニングポーカーカード- 各人が1組のカードを持つ• 1, 2, 3, 5, 8, 13...‣ プロダクトバックログ‣ ペンとか付箋とか84
  85. 85. アジャイル開発手法特論 © 2013 Miho Nagaseプランニングポーカーのやり方‣ 基準を決める- プロダクトバックログの中から「簡単そう」なものを探す- 3とおく‣ 1人の人がプロダクトバックログの中から優先順位が最も高い項目を読み上げる‣ 各人が、最初に選んだ「簡単そう」なものを3とおくと、それがいくつになるか思い浮かべる- 一度に出せるカードは1枚‣ 「せーの」でカードをオープン85
  86. 86. アジャイル開発手法特論 © 2013 Miho Nagase議論のしかた‣ 違う見積もりになるのは当たり前‣ 一番大きい数字と一番小さい数字を出した人がそれぞれその数字を出した理由を述べる‣ 各人がそれを受けて考えなおす(変えなくてもいい)‣ 「せーの」で出す‣ すばやく見積もるためのルールを決めておくと良い- 「隣り合う2つの数字の場合は大きい数字を採用する」- 「隣り合う3つの数字の場合は大きい数字を採用する」86
  87. 87. アジャイル開発手法特論 © 2013 Miho Nagaseワークショッププロダクトバックログを見積もろう87
  88. 88. アジャイル開発手法特論 © 2013 Miho Nagaseベロシティ88残作業量(見積り)時間この傾きのこと
  89. 89. アジャイル開発手法特論 © 2013 Miho Nagaseベロシティとは89‣ チームの作業の速度- 固定された期間(タイムボックス)の中でどれだけのプロダクトバックログ項目を実現できるか- スプリントごとに計測する- 終わらせたプロダクトバックログ項目の見積もりの合計値
  90. 90. アジャイル開発手法特論 © 2013 Miho Nagaseベロシティは変化する‣ 1スプリントごとでなく傾向を判断する‣ 初めてのスプリントの前には仮のベロシティを計測する010.0020.0030.0040.00#1 #2 #3 #4 #5 #6 #7 #8安定期(たぶん)何かが起きてる90
  91. 91. アジャイル開発手法特論 © 2013 Miho Nagaseリリース計画‣ スコープ固定‣ 日付固定91
  92. 92. アジャイル開発手法特論 © 2013 Miho Nagaseスコープ固定92残作業量(見積り)時間8/1 10/1ここまで終わりそうな日付ここまで終わりそうな日付‣ 見積もりポイント数合計 ベロシティ=所要スプリント数
  93. 93. アジャイル開発手法特論 © 2013 Miho Nagase日付固定93残作業量(見積り)時間8/1 10/18/1までに終わりそうな分10/1までに終わりそうな分‣ 所要スプリント数 ベロシティ=できそうなポイント数合計
  94. 94. アジャイル開発手法特論 © 2013 Miho Nagase教科書と参考図書94http://bit.ly/scrumbcbook http://www.scrum.org/Scrum-Guides
  95. 95. アジャイル開発手法特論 © 2013 Miho Nagase質疑応答95
  96. 96. アジャイル開発手法特論 © 2013 Miho Nagase今日やること第3回講義「将来を計画する」演習(適宜)第4回同上課題96
  97. 97. アジャイル開発手法特論 © 2013 Miho Nagase本日の課題(レポート)97Scrumの全体像を表す一枚絵を見なおして改善しあなたの理解で描いてください

×