You are currently browsing the tag archive for the ‘UML’ tag.
I’ve been reading/listening to a lot of chatter lately about where the tactical elements of SCRUM stop, and something additional is needed. I’ve seen and heard a lot of feedback indicating that the (purportedly) prescriptive components of SCRUM (story cards, SCRUM meeting procedures, backlogs, burndowns, etc.) are all replacements for things the PM used to do.
So if SCRUM is biased toward the (former) PM community, what about the rest? Even the best-written user story does not build software by itself. I still see a lot of churn and disagreement regarding how to effectively convert verbage on a card into quality working software. Some believe that a developer grabs a card and starts coding, while others believe that architecture, analysis, and design are all still essential activities needed to fulfill a requirement represented by a user story.
From observing behavior of new SCRUMers, if Story Cards are analogous to shouting, the subordinate/supporting tasks and deliverables are barely a whisper. Is this because it’s assumed that traditional Project Management is broken, but Development is fine as long as we leave the developers alone and just let them code?
Just because I’m Agile, doesn’t mean that I need to abandon the multitude of communication tools that help ensure that we build the right thing. I still like storyboards, data element definitions, domain models, use cases, state chart diagrams, business process models, communication diagrams, sequence diagrams, data models, etc. A lot of software requires a great deal of precision – If I don’t write down or draw models of the software I need, I’m bound to forget. What tends to be lost on a lot of new Agile adopters is: It’s okay to write things down, just don’t try to write down absolutely everything before you start building.
I’ve been reading/listening to a lot of chatter lately about where the tactical elements of SCRUM stop, and something additional is needed. I’ve seen and heard a lot of feedback indicating that the (purportedly) prescriptive components of SCRUM (story cards, SCRUM meeting procedures, backlogs, burndowns, etc.) are all replacements for things the PM used to do.
So if SCRUM is biased toward the (former) PM community, what about the rest? Even the best-written user story does not build software by itself. I still see a lot of churn and disagreement regarding how to effectively convert verbage on a card into quality working software. Some believe that a developer grabs a card and starts coding, while others believe that architecture, analysis, and design are all still essential activities needed to fulfill a requirement represented by a user story.
From observing behavior of new SCRUMers, if Story Cards are analogous to shouting, the subordinate/supporting tasks and deliverables are barely a whisper. Is this because it’s assumed that traditional Project Management is broken, but Development is fine as long as we leave the developers alone and just let them code?
Just because I’m Agile, doesn’t mean that I need to abandon the multitude of communication tools that help ensure that we build the right thing. I still like storyboards, data element definitions, domain models, use cases, state chart diagrams, business process models, communication diagrams, sequence diagrams, data models, etc. A lot of software requires a great deal of precision – If I don’t write down or draw models of the software I need, I’m bound to forget. What tends to be lost on a lot of new Agile adopters is: It’s okay to write things down, just don’t try to write down absolutely everything before you start building.
When requirements analysts are thorough, those who read and use the requirements can easily get lost in the muck and mire of the details. I have found that diagrams can add much more specificity to requirements than lengthy narratives describing business rules. This diagram depicts a small excerpt from a requirements model of a financial system.
This tiny drawing eliminates the need to write out all of the following business rules, because they are all clearly shown in the model:
- Every account must be associated to one customer.
- An account cannot be associated to more than one customer.
- An account cannot exist if it does not have a corresponding customer.
- A customer must have at least one account.
- A customer may have more than one account.
- An account must be either an individual account or a corporate account.
Some restrict the use of drawings like this for design, others argue that domain models are old school. I have had great success using this approach for describing business rules. The economy of words eliminates ambiguity, is much more thorough, and can be easier for a designer/developer to use when designing a solution.
On Tuesday at ProjectSummit/BA World, I was invited to be moderator of “Agile Analysis: Can it Work at My Organization?” During and after that session I had numerous discussions centered around this recurring question: “What Should I Document, and What Can I Document?” There’s a common perception that on an Agile project, the only thing I’m permitted to write down is a User Story – the remaining communication occurs through verbal interaction. If Agile is all about effective communication, is it presumptuous to assume that verbal communication is the most productive? In 1956, George Miller proposed a theory that the capacity of a human’s short-term memory is seven plus or minus two things. This was proved, and has been proved and re-proved many times. To free up short term memory to make room for the next batch of information, I have four choices: discard it, pass it to someone else and be done with it, encode it in long term memory (this takes time), or write it down. On a project aimed at building anything larger than small and trivial, chances are that if you don’t write things down they will be lost or forgotten. So, the remaining question related to project efficiency is, “If I write information down, what form works best, what do I do with it once it’s written, and what should I do with it after we are done using the information?”
The reaction to the 3 Pigs was awesome – Yanic from Belgium put a lot of work into his thorough rework of the problem. Check it out here. I realize he’s selling a product, but regardless, I really enjoyed his comments.
I agree with most of the feedback I received, although the spirit of the models was more conceptual’ish than design’ish, which tends to accommodate looser implementation precision.
The one choice I regret the most is sending the “eat()” message to each of the first two Pigs, which is actually telling the Pig to eat. To correct this, either the message to Pig is “getEaten()” or the message eat(Pig) is sent recursively to the Wolf (as Don suggested.)
Nevertheless, I’m really digging the idea of modeling a well known story as a means to hone my UML skills. Maybe I’ll tackle Aesop next…
I like modeling. Not the kind Tyra does, although I do like it when Tyra does it, it’s just not something that I do, not that I’d be any good at it anyway…
Sorry, got off track. Anyway, I like to build models that express information in an organized and precise way. The notation I use doesn’t really matter much, as long as it’s easily understood by the reader. I have used a lot of notations in my career. I still have that green plastic IBM flow chart template that my Dad gave me years ago (I wonder what that would fetch on eBay?); I suffered through the CASE tool years (thanks James Martin); and I used notation from OMT, Booch, and OOSE before becoming an early adopter of UML starting with version 0.9 in 1996. UML has stuck with me through the years, and it has become a casual and efficient way to take notes and express things.
Earlier this week I was talking with a coworker about models and modeling, and I proposed an idea: What would a children’s story look like if expressed in UML? I took this to task that night and produced The Three Little Pigs, in UML. Check it out and let me know what you think. The PDF document can be downloaded here. (It’s set up to print it double sided on legal sized paper.)
The Agilist Network 