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