ぐるぐるDDD/Scrum - モデリングと実装のうずまきをまわそう

5,669 views
5,516 views

Published on

レッツゴーデベロッパー変真で行ったぐるぐるDDD/Scrumのワークショップ資料です。

Published in: Technology
0 Comments
25 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,669
On SlideShare
0
From Embeds
0
Number of Embeds
2,601
Actions
Shares
0
Downloads
0
Comments
0
Likes
25
Embeds 0
No embeds

No notes for slide

ぐるぐるDDD/Scrum - モデリングと実装のうずまきをまわそう

  1. 1. 原田騎郎 株式会社アトラクタ 1 レッツゴーディベロッパー変真 2013/7/13
  2. 2. 原田 騎郎Kiro HARADA アジャイルコーチ ドメインモデラー SCMコンサルタント Twitter: @haradakiro 認定スクラムプロフェッショナル 認定スクラムマスター 認定スクラムプロダクトオーナー 株式会社アトラクタ 代表 2
  3. 3. 14:20& &14:50 &Scrum/DDD& 14:50& &15:50 & &&&&15:35& &15:50 15:50& &16:50 &&&&16:35& &16:50 16:50& &17:20 ( ) 3
  4. 4. !  DDD って何? !  Scrumって何? !  DDD と Scrum の似ているところ? !  両方のフィードバックサイクル 4
  5. 5. !  で、どうやるの !  プロダクトバックログとモデリング !  スプリントプランニングとモデリング !  バックログリファインメントとモデリング !  コードレビューとモデリング !  モデルのリファクタリング 5
  6. 6. !  モデルをテストする !  シナリオで確かめる !  コードで確かめる。 ▪  ドメインモデルを TDD する 6
  7. 7. DDD やってますか? 7
  8. 8. !  難しいから、もうちょっと勉強してから& !  小さいシステムにはいらないでしょ& !  やったほうがよさそうだと思っているん だけれど。 8
  9. 9. Scrumやってますか? 9
  10. 10. !  「どうせ、Scrum&はやるもんじゃな い!」って言うでしょ。& !  やってみたら問題ばっかりでてくるし。& !  「いきあたりばったりやっているだけ じゃないの?」と突っ込まれるし。 10
  11. 11. どうやったら& DDD&&&Scrum& をうまくやれる?& 使える? 11
  12. 12. 12
  13. 13. !  ソフトウェアプロジェクトで、まず注意 を払うべきなのは、ドメインとドメイン ロジックである。 !  複雑なドメインの設計はモデルに基づく べきである。 13
  14. 14. !  コアドメインに集中する !  ドメインの実務家とソフトウェアの実務 家による創造的な共同作業によって、モ デルと探求する !  明確に境界づけられたコンテキストの中 で、ユビキタス言語により会話する & 14
  15. 15. モデル探索の& うずまき モデルを新しいシナリオで& 揺さぶる シナリオ モデル モデルを提示& 状態ウォークスルー& 解決策ウォークスルー& 言語の探求& 間違う ストーリーを語る& 肉付けする& 難しいところに再フォーカス& コアドメインに再フォーカス コードによる探査 シナリオを テスト としてコードする& 厳密さを加える& 言語を洗練する& 解決策を探求& 間違う 収穫&文書化&  参照シナリオ&  まともなモデルの一部&  ほとんどのアイデアは書かない 15
  16. 16. !  正しいモデルを探求するのが目的ではな い。& !  使えるモデルを探し続けるのが目的。 16
  17. 17. !  複雑で変化の激しい問題に対応するため のフレームワークであり、可能な限り価 値の高いプロダクトを生産的かつ創造的 に届けるためのものである。& !  軽量& !  理解が容易& !  習得は非常に困難& & 17
  18. 18. 18
  19. 19. 19
  20. 20. !  Product&Backlog& !  Sprint&Backlog& !  Backlog&Refinement& !  Sprint&Review& !  Retrospective& & !  Potentially&Shippable&Increments 20
  21. 21. 21http://cognitiveKedge.com/
  22. 22. 22
  23. 23. !  境界& !  フィードバック& !  リズム 23
  24. 24. !  プロダクトビジョン& !  ユーザーストーリー& !  ユースケースシナリオ& !  モデル& !  モデルとシナリオのうずまきをまわす 24
  25. 25. !  ストーリーの順位付けをする& !  モデルを書いてみる& !  (モデルは常に複数ある)& !  モデルはストーリーを記述できるか?& ▪  モデルは役に立つか?& !  モデルをストーリーが十分説明できるか。& ▪  足りていないストーリーはないか? 25
  26. 26. !  難しいモデルは実装して確かめる& !  ドメインモデルのみ& ▪  永続化層&/&UI&はとりあえず考えなくてよい& ▪  複数のモデルを確かめる& ▪  記述力& ▪  実装のしやすさ& ▪  テストのしやすさ& ▪  拡張のしやすさ 26
  27. 27. !  「検査と適応によって、間違っても、それ から学べば良い」& & けれど& & !  わかる間違いには、気づきたい。& !  2週間は短い。それ以上、短くするとき つい。& 27
  28. 28. !  ホワイトボード& !  関心ごとのある部分だけホワイトボードに& !  適宜清書してリポジトリに& !  astah*&使ってます 28
  29. 29. !  ドメイン以外にビジネスロジックが埋も れていないか?& !  ドメインモデルに書いたテストを、そのまま 使えるか?& !  実装しにくいところはどこか?& ▪  ドメインの使い方を間違えやすいところはどこか 29
  30. 30. !  バックログを見積もる& !  モデルの変更が不要& !  モデルの拡張が必要& !  モデルの変更が必要 30
  31. 31. !  スプリント期間を短くするだけでは成功 は難しい。& !  単一のスプリント内で複数のオプション を試す。& !  モデルを利用した並行開発 31
  32. 32. !  パターン指向リファクタリング& !  次のバックログが見えないうちにリファ クタリングするのはアンチパターン& !  リファクタリングのためのリファクタリング は悪& 32
  33. 33. !  バックログが Ready&になる前に実装モデ ルを拡張するな& !  概念モデル、仕様モデルをシナリオでテスト してから。& !  リファレンスモデル、パターンの適用を検 討する 33
  34. 34. !  富& !  資産& !  農業資産& !  家畜& !  牝牛& !  ベッシー 34S.I.Hayakawa&“Language&in&Thoughts&and&Action”&1939&
  35. 35. !  リファレンスモデルは抽象度が高く、再利 用性が高い。& !  時間をかけて確かめられている。& けれど& & !  プロジェクトに役に立つかは、確かめな いとわからない。 35
  36. 36. !  小規模プロジェクトは、要件変更に弱い& !  使えるリソース、期間が限られている& !  小規模プロジェクトの範囲を&DDD&による モデルで定義する。& !  モデルの拡張範囲を合意する& !  モデルの変更をともなうバックログは混入し ない 36
  37. 37. ありがちなハマりどころ 対応策 モデリング地獄(DDD)& •  モデルを作ることを目標にしてし まう& •  いつまでたってもモデルが完成し ない& & & スプリント(Scrum)& •  出荷可能な製品を2週間ごとに!& •  モデリングも含めて使えるフィー チャーを2週間で作らなければな らない。 全体を見ないで開発(Scrum)& •  システムの全体像を考えない& •  全体計画を立てない& & & & ユビキタス言語(DDD)& •  みなが使える共通言語をつくる& •  共通言語による全体理解を促進& •  全体計画のガイドとしてのモデル 37
  38. 38. !  DDDとScrumは、うまく組合せられる& !  DDDもScrumも変える必要がない& !  お互いのメリットをうまく使える& !  短いサイクルを軽量にまわすのが大事& !  まずは、小さく始めてみましょう。 38
  39. 39. !  5人程度のグループを作ってください& !  グループ作業がしやすい用に、机、椅子 は適宜並べ替えてください。& !  約50分後に、簡単に成果の発表をして いただきます。& 39
  40. 40. 駐車場 40
  41. 41. 41
  42. 42. 42
  43. 43. 43
  44. 44. 44
  45. 45. 45
  46. 46. 46
  47. 47. 47
  48. 48. !  空き地& !  イベントのときなどの一時的な駐車場& !  月極め駐車場& !  時間貸し駐車場& !  コインパーキング& !  店舗に付属& !  店舗と提携 48
  49. 49. !  無人有料駐車場(時間貸し)の管理システム 49
  50. 50. !  シナリオを書いてみる& !  基本シナリオ?派生シナリオ?& & !  どう拡張される? 50
  51. 51. !  シナリオを記述できるモデルを書いてみ る& !  そのモデルに足りないシナリオはない? 51
  52. 52. モデル探索の& うずまき モデルを新しいシナリオで& 揺さぶる シナリオ モデル モデルを提示& 状態ウォークスルー& 解決策ウォークスルー& 言語の探求& 間違う ストーリーを語る& 肉付けする& 難しいところに再フォーカス& コアドメインに再フォーカス コードによる探査 シナリオを テスト としてコードする& 厳密さを加える& 言語を洗練する& 解決策を探求& 間違う 収穫&文書化&  参照シナリオ&  まともなモデルの一部&  ほとんどのアイデアは書かない 52
  53. 53. !  永続化、UI&はいらない& !  モデルをそのまま実装できるかどうか?& !  モデルがおかしいところはない?& !  実装しづらいところはない? 53
  54. 54. !  プロダクトバックログ& !  優先順位のついたシナリオのリスト& !  ドメインモデル& !  UML&のクラス図など& !  ドメインの理解を助けるものなら何でも& !  コアドメインのサンプル実装& !  コアドメインの受入れテストがあるといいな 54
  55. 55. !  50分しかありません。& !  時間の使いかたを計画しましょう。 55
  56. 56. !  成果を説明してみましょう。 56
  57. 57. !  びっくりしたこと、気づいたこと& !  学んだこと& !  次にやってみること 57
  58. 58. 58
  59. 59. !  週末料金?夜間料金?& !  煩雑期と閑散期で値段が変わる?& !  店舗利用による無料範囲& !  会員割引& !  誤入場をどうしよう?& !  駐車券なくしちゃったら?& !  とめっぱなしの車はどうしよう?& 59
  60. 60. !  駐車場の種類が変わると、変える必要の ある部分は?& !  車止め式& !  ゲート式& !  階数ごとに入場制限がある?& !  出場時にナンバーを認識する? 60
  61. 61. !  駐車料金が変わると、どこが変わる?& !  週末料金とかは?& !  車止め vs.&入退場ゲート& & 61
  62. 62. 62
  63. 63. 63http://www.lalaportKkoshien.com/access/index.html#05
  64. 64. 64
  65. 65. 65
  66. 66. !  成果を説明してみましょう。 66
  67. 67. !  びっくりしたこと、気づいたこと& !  学んだこと& !  次にやってみること 67
  68. 68. !  DDD&/&Scrum&を実際の業務で使ってみるに は?& !  グループディスカッション& 68

×