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