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.
原田騎郎株式会社アトラクタ1
原田 騎郎Kiro HARADAドメインモデラーアジャイルコーチSCMコンサルタントTwitter: @haradakiro認定スクラムプロフェッショナル認定スクラムマスター認定スクラムプロダクトオーナー株式会社アトラクタ 代表2
DDD やってますか？3
¡  難しいから、もうちょっと勉強してから  ¡  小さいシステムにはいらないでしょ  ¡  やったほうがよさそうだと思っているんだけれど。4
Scrumやってますか？5
¡  「どうせ、Scrum はやるもんじゃない！」って言うでしょ。  ¡  やってみたら問題ばっかりでてくるし。  ¡  「いきあたりばったりやっているだけじゃないの？」と突っ込まれるし。6
どうやったら  DDD & Scrumをうまくやれる？  使える？7
¡  ソフトウェアプロジェクトで、まず注意を払うべきなのは、ドメインとドメインロジックである。¡  複雑なドメインの設計はモデルに基づくべきである。8
¡  コアドメインに集中する¡  ドメインの実務家とソフトウェアの実務家による創造的な共同作業によって、モデルと探求する¡  明確に境界づけられたコンテキストの中で、ユビキタス言語により会話する  9
モデル探索の  うずまきモデルを新しいシナリオで  揺さぶるシナリオモデルモデルを提示  状態ウォークスルー  解決策ウォークスルー  言語の探求  間違うストーリーを語る  肉付けする  難しいところに再フォーカス  コアド...
¡  正しいモデルを探求するのが目的ではない。  ¡  モデルを使いつつ、さらに使えるモデルを探し続けるのが目的。  ¡  うずまきを廻し続ける。11
¡  複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。  §  軽量  §  理解が容易  §  習得は非常に困難    12
13http://www.scrumprimer.org/anime
14SCRUM  BOOT  CAMP  THE  BOOK  翔泳社より  https://www.facebook.com/ScrumBootCampTheBook
15http://www.ryuzee.com/
¡  Product Backlog ‒ プロダクトバックログ§  Sprint Backlog ‒ スプリントバックログ▪  Backlog Refinement ‒ バックログ洗練§  Sprint Review ‒ スプリントレビュー...
17By  Dave  Snowden  http://cognitive-­‐edge.com/http://en.wikipedia.org/wiki/File:Cynefin_framework_Feb_2011.jpeg  を ...
¡  境界  ¡  フィードバック  ¡  リズム18
¡  プロダクトビジョン  ¡  ユーザーストーリー  §  ユースケースシナリオ  ¡  モデル  §  モデルとシナリオのうずまきをまわす19
¡  ストーリーの順位付けをする  ¡  モデルを書いてみる  §  (モデルは常に複数ある)  §  モデルはストーリーを記述できるか？  ▪  モデルは役に立つか？  §  モデルをストーリーが十分説明できるか。  ▪...
¡  難しいモデルは実装して確かめる  §  ドメインモデルのみ  ▪  永続化層  /  UI  はとりあえず考えなくてよい  ▪  複数のモデルを確かめる  ▪  記述力  ▪  実装のしやすさ  ▪  テストのしやす...
¡  「検査と適応によって、間違っても、それから学べば良い」    けれど    ¡  わかる間違いには、気づきたい。  ¡  ２週間は短い。それ以上、短くするときつい。  22
¡  ホワイトボード  §  関心ごとのある部分だけホワイトボードに  ¡  適宜清書してリポジトリに  §  astah*  使ってます23
¡  ドメイン以外にビジネスロジッックが埋もれていないか？  §  ドメインモデルに書いたテストを、そのまま使えるか？  §  実装しにくいところはどこか？  ▪  ドメインの使い方を間違えやすいところはどこか24
¡  バックログを見積もる  §  モデルの変更が不要  §  モデルの拡張が必要  §  モデルの変更が必要25
¡  スプリント期間を短くするだけでは成功は難しい。  ¡  単一のスプリント内で複数のオプションを試す。  ¡  モデルを利用した並行開発26
¡  パターン指向リファクタリング  ¡  次のバックログが見えないうちにリファクタリングするのはアンチパターン  §  リファクタリングのためのリファクタリングは悪  27
¡  バックログが Ready になる前に実装モデルを拡張するな  §  概念モデル、仕様モデルをシナリオでテストしてから。  ¡  リファレンスモデル、パターンの適用を検討する28
¡  富  ¡  資産  ¡  農業資産  ¡  家畜  ¡  牝牛  ¡  ベッシー29S.I.Hayakawa  “Language  in  Thoughts  and  Action”  1939  
¡  リファレンスモデルは抽象度が高く、再利用性が高い。  §  時間をかけて確かめられている。  けれど    ¡  プロジェクトに役に立つかは、確かめないとわからない。30
¡  小規模プロジェクトは、要件変更に弱い  §  使えるリソース、期間が限られている  ¡  小規模プロジェクトの範囲を DDD によるモデルで定義する。  §  モデルの拡張範囲を合意する  §  モデルの変更をともなうバ...
¡  パターンランゲージとしての Scrum  ¡  パターンランゲージとしての          Domain  Driven  Design32
33http://domainlanguage.com/ddd/patterns/  CC-­‐BY  3.0  Unported
34http://jeffsutherland.org/scrum/scrum_plop.pdf
35Coplien,  James  and  Neil  Harrison.  Patterns  of  Agile  Software  Development.  Addison-­‐Wesley,  ©2004.
ありがちなハマりどころ 対応策モデリング地獄(DDD)  •  モデルを作ることを目標にしてしまう  •  いつまでたってもモデルが完成しない      スプリント(Scrum)  •  出荷可能な製品を２週間ごとに！  •  モ...
ユーザー  ビジネス プロダクト オーナー  開発者  フィードバック  プロダクト  バックログ  出荷可能な  増分  DDD で Scrumを廻してみる
¡  DDDとScrumは、うまく組合せられる  §  DDDもScrumも変える必要がない  §  お互いのメリットをうまく使える  ¡  短いサイクルを軽量にまわすのが大事  ¡  まずは、小さく始めてみましょう。38
¡  DDD+Scrumのワークショップをやります。¡  次回開催は未定です§  (たぶん７月には一回)。§  Twitter @haradakiro でアナウンスします。39
Upcoming SlideShare
Loading in …5
×

DDDをScrumで廻す あるいは ScrumをDDDで廻す

15,279 views

Published on

QConTokyo 2013 で講演させていただいた DDDとScrumのお話の資料です。

簡単なライブモデリングもありましたが、モデリングのネタは、ワークショップのお楽しみということで、お願いします。

Published in: Technology
no profile picture user

  • Login to see the comments

Show More

DDDをScrumで廻す あるいは ScrumをDDDで廻す

  1. 1. 原田騎郎株式会社アトラクタ1
  2. 2. 原田 騎郎Kiro HARADAドメインモデラーアジャイルコーチSCMコンサルタントTwitter: @haradakiro認定スクラムプロフェッショナル認定スクラムマスター認定スクラムプロダクトオーナー株式会社アトラクタ 代表2
  3. 3. DDD やってますか？3
  4. 4. ¡  難しいから、もうちょっと勉強してから  ¡  小さいシステムにはいらないでしょ  ¡  やったほうがよさそうだと思っているんだけれど。4
  5. 5. Scrumやってますか？5
  6. 6. ¡  「どうせ、Scrum はやるもんじゃない！」って言うでしょ。  ¡  やってみたら問題ばっかりでてくるし。  ¡  「いきあたりばったりやっているだけじゃないの？」と突っ込まれるし。6
  7. 7. どうやったら  DDD & Scrumをうまくやれる？  使える？7
  8. 8. ¡  ソフトウェアプロジェクトで、まず注意を払うべきなのは、ドメインとドメインロジックである。¡  複雑なドメインの設計はモデルに基づくべきである。8
  9. 9. ¡  コアドメインに集中する¡  ドメインの実務家とソフトウェアの実務家による創造的な共同作業によって、モデルと探求する¡  明確に境界づけられたコンテキストの中で、ユビキタス言語により会話する  9
  10. 10. モデル探索の  うずまきモデルを新しいシナリオで  揺さぶるシナリオモデルモデルを提示  状態ウォークスルー  解決策ウォークスルー  言語の探求  間違うストーリーを語る  肉付けする  難しいところに再フォーカス  コアドメインに再フォーカスコードによる探査シナリオを テスト としてコードする  厳密さを加える  言語を洗練する  解決策を探求  間違う収穫＆文書化   参照シナリオ   まともなモデルの一部   ほとんどのアイデアは書かない10
  11. 11. ¡  正しいモデルを探求するのが目的ではない。  ¡  モデルを使いつつ、さらに使えるモデルを探し続けるのが目的。  ¡  うずまきを廻し続ける。11
  12. 12. ¡  複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。  §  軽量  §  理解が容易  §  習得は非常に困難    12
  13. 13. 13http://www.scrumprimer.org/anime
  14. 14. 14SCRUM  BOOT  CAMP  THE  BOOK  翔泳社より  https://www.facebook.com/ScrumBootCampTheBook
  15. 15. 15http://www.ryuzee.com/
  16. 16. ¡  Product Backlog ‒ プロダクトバックログ§  Sprint Backlog ‒ スプリントバックログ▪  Backlog Refinement ‒ バックログ洗練§  Sprint Review ‒ スプリントレビュー§  Retrospective ‒ 振り返り¡  Potentially Shippable Increments ‒ 出荷可能な増分¡  プロジェクトじゃなくて、プロダクトの開発サイクルを廻し続ける。16
  17. 17. 17By  Dave  Snowden  http://cognitive-­‐edge.com/http://en.wikipedia.org/wiki/File:Cynefin_framework_Feb_2011.jpeg  を  CC-­‐BY  3.0  ライセンスに基づき翻訳。  
  18. 18. ¡  境界  ¡  フィードバック  ¡  リズム18
  19. 19. ¡  プロダクトビジョン  ¡  ユーザーストーリー  §  ユースケースシナリオ  ¡  モデル  §  モデルとシナリオのうずまきをまわす19
  20. 20. ¡  ストーリーの順位付けをする  ¡  モデルを書いてみる  §  (モデルは常に複数ある)  §  モデルはストーリーを記述できるか？  ▪  モデルは役に立つか？  §  モデルをストーリーが十分説明できるか。  ▪  足りていないストーリーはないか？20
  21. 21. ¡  難しいモデルは実装して確かめる  §  ドメインモデルのみ  ▪  永続化層  /  UI  はとりあえず考えなくてよい  ▪  複数のモデルを確かめる  ▪  記述力  ▪  実装のしやすさ  ▪  テストのしやすさ  ▪  拡張のしやすさ21
  22. 22. ¡  「検査と適応によって、間違っても、それから学べば良い」    けれど    ¡  わかる間違いには、気づきたい。  ¡  ２週間は短い。それ以上、短くするときつい。  22
  23. 23. ¡  ホワイトボード  §  関心ごとのある部分だけホワイトボードに  ¡  適宜清書してリポジトリに  §  astah*  使ってます23
  24. 24. ¡  ドメイン以外にビジネスロジッックが埋もれていないか？  §  ドメインモデルに書いたテストを、そのまま使えるか？  §  実装しにくいところはどこか？  ▪  ドメインの使い方を間違えやすいところはどこか24
  25. 25. ¡  バックログを見積もる  §  モデルの変更が不要  §  モデルの拡張が必要  §  モデルの変更が必要25
  26. 26. ¡  スプリント期間を短くするだけでは成功は難しい。  ¡  単一のスプリント内で複数のオプションを試す。  ¡  モデルを利用した並行開発26
  27. 27. ¡  パターン指向リファクタリング  ¡  次のバックログが見えないうちにリファクタリングするのはアンチパターン  §  リファクタリングのためのリファクタリングは悪  27
  28. 28. ¡  バックログが Ready になる前に実装モデルを拡張するな  §  概念モデル、仕様モデルをシナリオでテストしてから。  ¡  リファレンスモデル、パターンの適用を検討する28
  29. 29. ¡  富  ¡  資産  ¡  農業資産  ¡  家畜  ¡  牝牛  ¡  ベッシー29S.I.Hayakawa  “Language  in  Thoughts  and  Action”  1939  
  30. 30. ¡  リファレンスモデルは抽象度が高く、再利用性が高い。  §  時間をかけて確かめられている。  けれど    ¡  プロジェクトに役に立つかは、確かめないとわからない。30
  31. 31. ¡  小規模プロジェクトは、要件変更に弱い  §  使えるリソース、期間が限られている  ¡  小規模プロジェクトの範囲を DDD によるモデルで定義する。  §  モデルの拡張範囲を合意する  §  モデルの変更をともなうバックログは混入しない31
  32. 32. ¡  パターンランゲージとしての Scrum  ¡  パターンランゲージとしての          Domain  Driven  Design32
  33. 33. 33http://domainlanguage.com/ddd/patterns/  CC-­‐BY  3.0  Unported
  34. 34. 34http://jeffsutherland.org/scrum/scrum_plop.pdf
  35. 35. 35Coplien,  James  and  Neil  Harrison.  Patterns  of  Agile  Software  Development.  Addison-­‐Wesley,  ©2004.
  36. 36. ありがちなハマりどころ 対応策モデリング地獄(DDD)  •  モデルを作ることを目標にしてしまう  •  いつまでたってもモデルが完成しない      スプリント(Scrum)  •  出荷可能な製品を２週間ごとに！  •  モデリングも含めて使えるフィーチャーを２週間で作らなければならない。全体を見ないで開発(Scrum)  •  システムの全体像を考えない  •  全体計画を立てない        ユビキタス言語(DDD)  •  みなが使える共通言語をつくる  •  共通言語による全体理解を促進  •  全体計画のガイドとしてのモデル36
  37. 37. ユーザー  ビジネス プロダクト オーナー  開発者  フィードバック  プロダクト  バックログ  出荷可能な  増分  DDD で Scrumを廻してみる
  38. 38. ¡  DDDとScrumは、うまく組合せられる  §  DDDもScrumも変える必要がない  §  お互いのメリットをうまく使える  ¡  短いサイクルを軽量にまわすのが大事  ¡  まずは、小さく始めてみましょう。38
  39. 39. ¡  DDD+Scrumのワークショップをやります。¡  次回開催は未定です§  (たぶん７月には一回)。§  Twitter @haradakiro でアナウンスします。39

×