I really like using graph paper to draw UI designs on, and for just about everything else. Now I can get my graph paper via the office printer and not OfficeWorks ! I hope this is of use to you.
Thanks konigi !
I use Complexian in my Java work and it is simple and fantastic, and now Marty Andrews has released a tool similar to Checkstyle but for Ruby. It is called Roodi. I’m sure this will be another simple and fantastic tool. Check it out here on Marty’s site. Btw - Thats Marty in the pic.
While re-reading Chapter 8 - Agile Collaboration, of the book Practices of An Agile Developer I smiled again at the section title “Architects Must Write Code”, but I also wondered, What really is an Architect, what Role do they play and do we really need one ? Luckily, Martin Fowler wrote a piece for the IEEE that answers these questions, at least in terms of Software. The article is here.
In the article there is a quote from an email message between Martin Fowler and Ralph Johnson on the the differences between building architecture and software architecture that in my opinion exemplify what it means to be Agile, and that is, to make (software) it easy to change. The quote and article go on to explain how making something easy to change makes the overall system a little more complex and I’m not in total agreement with this, but the point I want to make is that Agile is about the practices that make it easy to change. Practices like Test Driven Design, Pairing, Continuous Integration, feedback loops (Iterations), and a constant focus on working releasable software.
Agile and it’s practices are why I confidently put off decisions on various components until the last possible minute, which is when we are most likely to know the most about the real needs of the component. So embrace change and make it easy to do it.
What I don’t do, and what I don’t believe Agile advocates, is to leave the gathering of scope until the last minute, since having some idea of where the project is going and what it may be delivering is crucial contextual information. I’m not saying you need to get all the stories up front, but most of the epic stories is a good start.
Now this is neat !
And a new LISP like dialect that targets the Java Virtual Machine called Clojure
Yesterday we had one of those awkward meetings where the Company wants to bang a hamster through a star shaped hole and not make a mess, you know the ones. In our case it was on how long our project would be without having all the requirements, fun times.
The project is an Agile one so we developers started explaining the Point scheme and how we had a heuristic from the last project that we wanted to use for this one as a starting point. However, the road-block, head against a brick wall came about when management estimated the “optimum” points for the team and thought our heuristic was too low. It went something like this ….
You have 5 developers and an iteration of two weeks, so that is 5 x 10 = 50 points. Aaaargh!
When we explained that this was totally unrealistic since it didn’t even account for toilet breaks during the working day, management were kind enough to relax the estimate by 40%, ain’t they kind ?
This was still double our established heuristic which I thought we could improve on, but at least our heuristic was a realistic starting point. However, management were not going to swallow our figure so we continued our difficult negotiation.
Luckily, Jacky, a member of the development team piped up with a formula for determining a good starting Point Count for the iterations. It went something like this:
Days in Iteration x Developers in team x Skill Level of Developers x Company Efficiency.
Interestingly this formula resulted in a point count that was higher than our heuristic but one that was lower than “60% of optimum” that was proposed by management. As an aside, have you ever noticed that when someone estimates what work load you can do it always seems sensible and feasible? Maybe we should get management to estimate and developers to estimate and then the lower groups with the lower estimate has to do the work? Anyway, I digress …
The Skill level a developer is a measure of their efficiency when working on the project, while the Company efficiency is a measure of what percentage of time at work the developer is involved in actually developing for the project. For example, we have a regular company meeting and other non-project interruptions which all reduce the time a developer can be working on the project. We quickly noticed how the Company Efficiency and Skill level effected the Point Count dramatically. Here is how our figures looked:
10 x 5 x 70% x 85% = 29.75 Points
We have reached an agreement using the formula, and soon I hope to post about how to determine the skill level percentage of developers and the efficiency of the company but I’m sure you could work with the formula now. We still intend to use the Point Count as a start and then as each Iteration completed we will use the achieved Points as the goal for the next iteration, which also means we need to use the achieved Points in the Planning games.
My presentation on LISP has been given to the Melbourne Patterns Group, and if there is a big enough interest I will post the slides, however the slides don’t really stand alone as I don’t put what I am saying on slides, I just use them to illustrate my points. Something I learned from Presentation Zen, which I blogged about earlier.
A special thank you to Bill Birch who answered questions on LISP and showed his Genyris dialect of LISP, and to Henry Guillaume for providing me some Emacs LISP code he wrote back in the day, which incidentally is still in Emacs today.
One attendee said: “?first really interesting user group meeting I’ve been to this year”
Today I am giving the same presentation as a brown bag to the developers at work, in the hope that they look further into LISP.
I will be presenting at the next Melbourne Patterns Group on LISP. It will be a quick and simple introduction to the language and why I think you should use it.
There will be two special guests to support my presentation !!
The date and time is September 3rd at 6:30pm and the address can be found at the web site linked above.
I hope to see you there.
Creating a Product from a list of System Attributes is not as effective as creating one from a list of User Goals, and while useful, it is not going to lead to a market leading product. Here’s why:
The System Attributes approach is why we have MP3 players like the Creative iRiver, while the User Goals approach is how we get the Apple iPod. We both know which MP3 player dominates the market by 90%, the Apple iPod, and yet the iRiver has more features (attributes).
For example, here is a list of System Attributes:
1. The product shall have a gas engine.
2. The product shall have four wheels.
2.1. The product shall have a rubber tire mounted to each wheel.
3. The product shall have a steering wheel.
4. The product shall have a steel body.
What does the System do for the User ?
What attribute should be done first ?
Here is an example of a list of User Goals that the System should support:
1. As a user, I want to mow my lawn quickly and easily.
2. As a user, I want to be comfortable while mowing my lawn.
Both of the examples above describe a Lawn Mower, but only the User Goals approach removes the ambiguity necessary to creatively and efficiently deliver what the User actually wants and will pay for.
I support / promote a move from the System Attribute approach to the User Goals approach because:
1. We can deliver each User Goal incrementally and get a ROI sooner.
2. The resulting Product is what the User wants and will use, because this was the driver.
3. We can easily go from User Goals to a list of System Attributes, but not the reverse.
4. The resulting Product will be more cohesive.
*The example attributes above are taken from the presentation, “User Stories Applied” by Mike Cohn.
In this post about Exploring Requirements I spoke about the need to get good requirements, even if using an Agile process, but how can we capture these requirements as good User Stories?
Writing good User Stories is a skill that takes practice, and I think that removing ambiguity and conveying the problem being solved are keys to good stories. There is also the acronym INVEST to guide you well. This acronym is covered in this blog post and in this blog post, so I won’t regurgitate it here, but please take some time to read them.
There are many schools of thought about how big or small a User Story should be but my preference is to make them fit comfortably within the teams iteration. So if the Story can’t be done within an iteration it is probably an epic story that needs to be broken down into smaller stories. Smaller stories are easier to complete and this helps the team maintain a positive rythmn and feeling of progress. However, a Story should deliver something of business value to the customer, something they can use, which I think is a key to just how small a Story can be.
There are also many opinions on what details a Story should contain and to what level the details should go. For me, a Story can be just the title and one or more tests. It must have a test.
If we take the requirements from the Exploring Requirements post we can easily convert them into User Stories, with the requirement becoming the title of the story. For example:
What we can also see from this set of Stories is that Story #2 is probably an Epic, since the range of things that can make a BABY uncomfortable may be rather large. In this case I would split the Story into smaller Stories and capture the linkage to the Umbrella/Parent/Epic Story in the title of the new Story. For example:
You may think that the Stories #2 and #3 don’t need to be separate. I make this judgement by checking to see if there is a different priority for each to the Customer. For example, if being too cold is worse than being too hot then story #3 would have a higher priority, and therefore it makes sense to have it separate so it can be scheduled and delivered individually. Where the priority is the same then it comes back to the ability for the Story to be delivered in a single iteration and separating it where this can’t be achieved.
Often I am asked where the solution details go and the answer is, not in the Story, but in the code and or comments or attachments to the Story. The Story should stand alone from any particular implementation.
At the end if the day the best User Story detail and size is what works best in your Team and for your Customer.
We have a new Customer at home and they have three requirements:
What I hope you will notice from the above requirements is that they are stated as close to a problem as possible, and the level of ambiguity is rather low. While this example may seem trivial it is surprising how many requirements I see that are stated in terms of a solution, that contain attributes of a solution or are peppered with ambiguity. I have found it hard to get a Customer to see these problems and amend the requirements accordingly; I think it’s much harder than looking after my new Customer, and that’s all consuming and *very* hard.
Agile encourages small feedback cycles and on my current work project this cycle is two weeks, and while this is the timeframe in which the Customer will confirm our course to be correct or not, we can do a lot more to ensure the possibility of moving in the correct direction by spending more time on the requirements themselves. Time spent removing ambiguity and ensuring the wording makes clear what the problem being solved is.
Studies have shown that the costs of fixing errors in the production phase created by false assumptions and ambiguity in the requirements phase are a ratio of some 40 - 1000 times. So economics suggest that more time should be spent on the requirements, and although Agile may mitigate some of these risks the risks remain making it economically prudent to have good requirements.
As a developer I want to give the Customer what they want, and by ensuring they convey the problem they are trying to solve, I am more likely to give them a solution to the problem, even where ambiguity exists. Where a requirement states all or part of a solution the chances are you wont have solved the Customers problem, since you don’t know what it is, and the Customer wont be happy because the problem still exists. A requirement that states a solution can sometimes remove the possibility of options being presented to the Customer, but this depends on the team culture.
Ambiguity exists when two people can read the same requirement and make different assumptions, for example, comparative words like “small” or “inexpensive” lead to ambiguity.
There are a lot of techniques for refining requirements, driving out ambiguity and focusing the requirements to convey the problem and the best collection of these techniques I have found is in the book “Exploring Requirements, Quality Before Design” by Donald C. Gause & Gerald M. Weinberg. However, if time to read the book is an issue, just ask “why?” at least five times on each requirement and “what problem does this solve?”. I typically find this approach uncovers a mass of things that need to be covered.
Update:
Some people have asked me about how requirements can be ambiguous and I thought an example from the book would be ideal. In keeping with things that appeal to my new Customer, I have chosen the example in the book where the authors take a familiar nursery ryme and apply a process of emphasizing each of the words in the line, one by one, and then in combinations to identify ambiguity. They uncover 32 different meanings of just the first line of the familiar poem, that could be 32 different solutions all of which may not be right for the Customer. The poem is:
Mary had a little lamb.
its fleece was white as snow.
And everywhere that Mary went,
The lamb was sure to go.
Here are some of the different meanings uncovered in just the first line of the poem, but please get the book to see the full set which really drives home this technique.
Mary had a little lamb.
(It was Mary’s lamb, not Tom’s, Dick’s or Harry’s.)
Mary had a little lamb.
(She no longer has the lamb)
Mary had a little lamb.
(She had only one lamb, not several.)
Mary had a little lamb.
(It really was surprisingly small.)
Mary had a little lamb.
(She didn’t have a dog, cat, cow, goat, or parakeet.)
Mary had a little lamb.
(John still has his little lamb.)
Mary had a little lamb.
(As contrastred with Pallas, who still has four large turtles.)
My personal favourite is what happens when you apply different dictionary meanings to the words, like ‘had’, for example:
Mary had a little lamb. So what did she have for desert ?