Successfully reported this slideshow.
Your SlideShare is downloading. ×

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

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 39 Ad

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

Download to read offline

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

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

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

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

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Similar to DDDをScrumで廻す あるいは ScrumをDDDで廻す (20)

Advertisement

More from Kiro Harada (18)

Recently uploaded (20)

Advertisement

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. 14 SCRUM  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. 17 By  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. ¡  「検査と適応によって、間違っても、それ から学べば良い」     けれど     ¡  わかる間違いには、気づきたい。   ¡  2週間は短い。それ以上、短くするとき つい。   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  Design 32
  33. 33. 33 http://domainlanguage.com/ddd/patterns/   CC-­‐BY  3.0  Unported
  34. 34. 34 http://jeffsutherland.org/scrum/scrum_plop.pdf
  35. 35. 35 Coplien,  James  and  Neil  Harrison.  Patterns  of  Agile  Software  Development.  Addison-­‐ Wesley,  ©2004.
  36. 36. ありがちなハマりどころ 対応策 モデリング地獄(DDD)   •  モデルを作ることを目標にしてし まう   •  いつまでたってもモデルが完成し ない       スプリント(Scrum)   •  出荷可能な製品を2週間ごとに!   •  モデリングも含めて使えるフィー チャーを2週間で作らなければな らない。 全体を見ないで開発(Scrum)   •  システムの全体像を考えない   •  全体計画を立てない         ユビキタス言語(DDD)   •  みなが使える共通言語をつくる   •  共通言語による全体理解を促進   •  全体計画のガイドとしてのモデル 36
  37. 37. ユーザー   ビジネス プロダクト オーナー   開発者   フィード バック   プロダクト   バックログ   出荷可能な   増分   DDD で Scrumを 廻してみる
  38. 38. ¡  DDDとScrumは、うまく組合せられる   §  DDDもScrumも変える必要がない   §  お互いのメリットをうまく使える   ¡  短いサイクルを軽量にまわすのが大事   ¡  まずは、小さく始めてみましょう。 38
  39. 39. ¡  DDD+Scrumのワークショップをやりま す。 ¡  次回開催は未定です §  (たぶん7月には一回)。 §  Twitter @haradakiro でアナウンスします。 39

×