Rethinking enterprise software - Codemotion 2014

  • 1,775 views
Uploaded on

As a Software Architect and consultant I designed software with some artefacts in mind. As an entrepreneur I found myself on the other side of the fence. I'd improve distribute holistic knowledge …

As a Software Architect and consultant I designed software with some artefacts in mind. As an entrepreneur I found myself on the other side of the fence. I'd improve distribute holistic knowledge through EventStorming and Domain-Driven Design rather than partition the system with User Stories.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,775
On Slideshare
0
From Embeds
0
Number of Embeds
5

Actions

Shares
Downloads
46
Comments
0
Likes
14

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Rethinking Enterprise Software @ziobrandoCodemotion 2014 - Roma
  • 2. About me @ziobrando ! I do something else instead @ziobrandoAbout me DDD enthusiast Post-it addicted Visual thinker Chaos summoner Developer Idea thief …never satisfied Entrepreneur avanscoperta
  • 3. Some news about software estimation Even broken models can teach us something
  • 4. The real problem with estimations:
  • 5. They may be right, sometimes
  • 6. 11 x 2 = …
  • 7. Easy homework
  • 8. What if we have Legacy?
  • 9. “It’s only a couple of mines somewhere…”
  • 10. Some recap from one year ago
  • 11. Ignorance is the single greatest impediment to throughput. Dan North http://dannorth.net/2010/08/30/introducing-deliberate-discovery/
  • 12. Learning is the constraint Dan North http://dannorth.net/2010/08/30/introducing-deliberate-discovery/
  • 13. Software development is a learning process Working code is a side effect
  • 14. Learning
  • 15. Memories
  • 16. Learning School Boring Study Lesson Experiment Mistakes Fun Marks Exams Stress Life
  • 17. Learning didn’t happen there
  • 18. Learning is crucial for our job, and yet we don’t know much about it Look inside!
  • 19. Learning is non linear (doesn’t fit into spreadsheets, burndown and Gantt charts)
  • 20. Stress Psychological reaction ! To an adverse situation ! Situation is perceived as inevitable
  • 21. Brain can’t learn under stress
  • 22. Relax
  • 23. Looks like…
  • 24. Conformity kills creativity
  • 25. Pressure hurts problem solving
  • 26. Can you estimate learning?
  • 27. I haven’t finished, yet
  • 28. Value Stream Mapping http://agile.dzone.com/books/continuous-delivery-free
  • 29. A quicker notation...
  • 30. We need a different model! (again)
  • 31. Coding 20cl, learning 20cl, deciding 20cl, waiting...
  • 32. Mutual waiting Apparently, a process and organisation issue...
  • 33. Learning is not the only constraint
  • 34. Deciding?
  • 35. We suck at it
  • 36. How many DDD practitioners are needed to name a class?
  • 37. We should really find a name for our daughter... Isn’t a GUID sufficient? No, I mean a proper name... What about Foo now, and refactor later?
  • 38. Should I marry her? Yes No
  • 39. We really should be getting married soon... Can we talk about this another time, honey? I’m facing a zerg assault right now...
  • 40. The strategy?
  • 41. Deadline!
  • 42. Wedding ceremony is a Ponzi schema designed to stop the man procrastinating
  • 43. ...but can we stop afterthoughts?
  • 44. Wow, Kate looked really hot today, maybe… maybe I should have used MongoDB in that project
  • 45. Finally, everybody leaves
  • 46. Can you provide me an estimate? You can use *points if you want…
  • 47. Problem
  • 48. Yes… there’s no one size fits all
  • 49. Summary Repeatable (boring) —> Pseudo-linear Legacy —> Too guilty to accept the real numbers Learning —> Non Linear Deciding —> Deadlines & acceptable results Waiting —> Remove coupling
  • 50. Enterprise software
  • 51. Enterprise software, also known as enterprise software application (ESA), is purposed-designed computer software used to satisfy the needs of an organization rather than individual users.
  • 52. Enterprise software, also known as enterprise software application (ESA), is purposed-designed computer software used to satisfy the needs of an organisation rather than individual users.
  • 53. Which are the needs of an organisation?
  • 54. Kanban View of the system: Decision Making is the bottleneck
  • 55. A business process is a series of connected business-relevant decisions
  • 56. So what should we do?
  • 57. Should we write use cases?
  • 58. Developers loved templates
  • 59. But forgot good readings
  • 60. User Stories As a [role] I want to [action] in order to [goal]
  • 61. Really?
  • 62. A placeholder for future conversation
  • 63. What are we supposed to say?
  • 64. meaningful conversation with the domain expert
  • 65. “...Eric?”
  • 66. ...even better!
  • 67. Hack! Warning: DDD doesn’t work on the Death Star
  • 68. Event Storming!
  • 69. Video If a picture is worth a thousand words…
  • 70. ©  Alberto  Brandolini  2009 #CDays14 – Milano 25, 26 e 27 Febbraio 2014 Video!
  • 71. Yes, I mean that much space...
  • 72. My best friend
  • 73. And… no table.
  • 74. It’s no fun to just watch others play
  • 75. Ubiquitous Language Reloaded
  • 76. Model Affinity
  • 77. Domain Events work better
  • 78. Events are precise
  • 79. Event are meaningful
  • 80. here the user decides Command User issues influences External information influences Read Model
  • 81. Quali informazioni
  • 82. Fine-Grained Delegation Management 30.com
  • 83. Steal and tweak
  • 84. Process fine tuning
  • 85. Conversation happens here!
  • 86. “Which are the events needed in order to make this event happen?” “Which are the information needed for a user in order to take this decision?” (more or less wisely)
  • 87. “Do you have a story to describe edge cases?”
  • 88. Some great ideas here... BDD Specification by example Concrete scenarios
  • 89. We provided a dedicated place for learning to happen
  • 90. Divergence can be managed or enforced
  • 91. There is value in enforcing divergence
  • 92. Conflict resolution
  • 93. The only thing they agree on is fooling us!
  • 94. They’re both right! Context A Context B
  • 95. whew!
  • 96. Tool Affinity
  • 97. Simple notation
  • 98. How long is this cycle?
  • 99. What about ...minutes?
  • 100. Event Storming Provides a model of the shared level of understanding of a complex business process …I’ve never said it’s the right one!
  • 101. Validate with multiple sources
  • 102. ...Waiting
  • 103. Remove dependencies…
  • 104. Scrum Way: —> Cross Functional Teams
  • 105. but…
  • 106. Stand-up meetings You’re doing them wrong
  • 107. Loosely coupled architecture reduces organisation load
  • 108. Bounded Context CQRS Event Sourcing Reactive Apps
  • 109. … not necessarily a process problem
  • 110. Coding against an ecosystem How do we measure effect on an ecosystem?
  • 111. Definition of Done - It works on my machine - Green tests - Deployed in production - Up and running - Users are using it - We’ve solved the business goal
  • 112. Wrap up: There is a better model for enterprise apps ! There are better ways to discover this model and learn together around it ! There are better implementations that perfectly fit this model
  • 113. I am not paying for that!
  • 114. Grazie! Alberto.brandolini@avanscoperta.it @ziobrando