This is a guest post by Kenji Hiranabe, CEO of Change Vision, Inc. – the maker of software modeling tool Astah (our most recent sponsor for this site, thanks!) for UML, SysML, GSN, ERD and more, also a face of Japanese Agile Community (See his profile). In this post he summarizes his views on Agile Software development, focusing on where “modeling” will fit, and how it can bring the best value in it as a whole.
Introduction
Now that Agile methods have become mainstream in software development, working code (and automated tests) are being considered as the most important team artifacts.
Is modeling not needed any more? Is UML dead? I think that’s not true. In this post, I’ll explore the spaces where modeling fits and plays an important role in this Agile age, especially when development scales to multiple teams and a shared understanding of the system’s “Big Picture” becomes essential.
Where is “Design” in Agile
“While code is the truth, it is not the whole truth – Grady Booch”
To begin with, I’ll describe a minimal process of an Agile team using Scrum. Figure. 1 shows an intentionally simplified process with the only essential artifacts left explicit.
- The “User Requirements” are listed as a “Product Backlog”.
- The development team picks items from the list and implements them within a short iteration (or “Sprint”).
- After each Sprint, the team produces “Working Software” (or “Increments”) as “Product Code” and “Test Code”.
Figure 1- Simple Scrum Framework
In this minimum framework, the input to the team is “User Requirements” as “Product Backlog” and the output is “Working Software” as code (“Product Code” and “Test Code”). No other design artifacts between them are explicitly described here. All the design intentions generated during the Sprint will hopefully have been deployed into the working codebase as assets of the team, but there will be information which cannot be expressed directly as code. Scrum is a process-framework and intentionally mentions nothing about design, but we still have design and design activities in our team.
As Grady Booch says “The code is the truth, but it is not the whole truth.” So if there is information which cannot be expressed or communicated by the code, where can we keep those information assets? That is the question this post attempts to answer.
Is documentation not Agile?
“Model to have a conversation. – Craig Larman and Bas Vodde”
“In our minds!” would be one answer to the previous question. Daily meetings, pair programming, design workshops and all these social practices act as synchronization and continuous integration of the minds of the team members. But when the team gets bigger, geographically distributed, and people leave the team, “models in minds” will quickly evaporate. We need to maintain the shared understanding of the system somewhere as documentation to share information which is not well communicated and retained only by the code.
One point that Agile makes clear is the value shift from documentation to conversation, so writing heavy design documentation (which often duplicates information from the code) is not the right approach. Documentation that makes conversations effective is the approach that we should take, and it should be the simplest possible set of models which works complementary to the code.
One aspect where models have an advantage over code is visual expression. In other words, text is a poor medium of communication in a certain context. Figure. 2 shows how textual communication fails miserably (thanks to Jeff Patton for introducing the book to me).
Figure 2 – How textual communication fails
I guess this “wreck” is caused by a message left to an answering machine of a cake shop, but if he/she had been able to use a simple picture (and text), he/she could have easily avoided the wreck. Sometimes, “a picture is worth 1,000 words”.
So what models can be effectively used for which purposes in Agile teams?
We can divide “models” into two categories – one is a “Keep model” that you keep and maintain throughout the project which represents (1) architecture as Class/Package diagrams, (2)domain model as a Class Diagram/ER Diagrams and (3) key use cases as UseCase Diagrams and Sequence/Communication Diagrams. Another category is a “Temp Model” which can be used temporarily to share the same understanding in the team.
To read further of this article, please visit here: http://astah.net/
Figure 3 – Models to keep, temporal models
Conclusion
- Design has been and still is an important part of software development in Agile
- Keep the simplest set of models updated and throw away other after it is expressed as code or tests
- Modeling fits into an Agile development framework like Scrum, and certain models should be kept throughout the lifecycle of the product
- Modeling is strongly effective to communicate design intentions and to establish a shared understanding of the system
To continue the discussion, you may also want to take a look at my own opinion on the topic Agile and Modeling / MDE : friends or foes?
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
Recent Comments