Matt Wynne taking it one tea at a time
If you’ve ever tried to copy the source files from a Visual Studio 2005 ASP.NET solution, especially if you’re using TFS and Resharper, you’ll have probably noticed all great steaming heaps of fluff and nonsense these tools leave all over your hard drive. Not to mention all the built assemblies lurking in your bin/Debug folders.
If you have a unix/linux/apple machine handy, or have at least had the sense to instal cygwin or coLinux on your quaint old PC, then give this a rumble.
One of the several great things about working for my current client is that their high public profile means it’s reasonably easy to get interesting people to come and visit us from time to time.
Last week the mighty Martin Fowler dropped by to talk to us.
My notes on DanNorth and JoeWalnes‘ session at Spa 2008.
Five artefacts:
Four roles. People might fill more than one, or more than one person might be in a role:
Taking a requirement, the Stakeholder and the Analyst have a conversation:
Then the Analyst and the Tester have a conversation:
Tester then ‘monkeyfies’ the scenarios, using the following template:
Given …
– assumptions, context in which the scenario occurs.
When …
– user action, interaction with the system
Then …
– expected outcome
e.g.
Given we have an account holder Joe
and their current account contains $100
and the interest rate is 10%
When Joe withdraws $120
Then Joe’s balance should be $-22
The tester and the developer sit down and write an automated test to implement each scenario.
You might chain these up, but you can always categorise test code into these three partitions. This really helps how you look at test code.
See the Consumer Driven Contracts paper on Martin Fowler‘s website.
Consider extending / creating the domain model to cover the application itself – the UI, the back end.
Loads of tools are availlable. Use whatever works and build on it.
Ubiquitous Language – Start with a shared language. It becomes ubiquitous when it appears everywhere – documents, code, databases, conversations.
You will use different vocabularies in different bounded contexts. A context might be your problem domain, testing domain, software domain, or the user interface domain.
Beware which roles understand you when you’re talking in a particular domain. Often terms will span domains.
e.g. NHibernateCustomerRepository
<– 1 –><– 2–><– 3 –>
1 = 3rd Party Provider Domain
2 = Problem Domain
3 – Software Domain
Make your tests tell a story – make it flow. Don’t hide away things in Setup methods that will make the test hard to read. If that means a little bit of duplication, so be it. ‘Damp not DRY’.
Basically what you need is a way to assemble different permutations and combinations of Given / When / Then with different parameters to make different scenarios.
Think in terms of narrative, flow. Think in terms of bounded contexts, and who the audience (role) is for that context. Who will understand that vocabulary?
Make sure the intent is clear – that’s the main thing.
Do you want to hook into continuous integration build?
Which version of the code is it going to run against?
Keep the tests in two buckets:
* in progress
* done
Those which are in the ‘done’ bucket, should always work, those which are in progress are allowed to be failing, until you make them pass.
Things you can do today.
What to aim for.
So I got to SPA yesterday afternoon, but this is my first day proper.
The sessions are longer than at other conferences I’ve been to, which allows for more depth. I’ve been to three today:
– Code Debt (Workshop)
– Is Software Practice Advancing? (Panel Discussion)
– Real Options (Workshop)
The evening is ensuing with more BoF sessions, so there’s no rest!
Is scrum a virus? Jason Gorman and Brian Marrick have been pondering on whether that might be a good thing.
I have a couple of metaphors of my own for Scrum.
Continue reading “Scrum Metaphors: Virus, Bulldozer, Stabilisers”
Scrum tells you to build ‘potentially shippable’ changes to your product (let’s call them ‘User Stores’) in fixed-length iterations. By estimating the relative complexity of delivering each of these changes using arbitrary units (let’s call them ‘Story Points’) you can measure how much estimated complexity was turned into ‘potentially shippable’ software over a fixed duration.
So far, so good. Where could it possibly go wrong?
Continue reading “Where Scrum Gets Dangerous: Potentially Shippable? Make Sure You Mean It”
Hmph. I just discovered Markdown which makes a great partner to the TextMate Blogging Bundle, but my recent markdown-formatted posts don’t seem to be appearing on the homepage of my blog…
Anyone know what’s going on?
A while back I alerted you to a post Karl Scotland had written on his implementation of a kanban system for producing software. Kenji Hiranabe has posted a very informative and well-researched article on the InfoQ website which also sheds a great deal of light on the practical application of this exciting emerging practice. Well worth a read if you’re open to fresh ideas on how to get stuff done.
I facilitated our regular end-of-iteration retrospective last week, and although the feedback from the team was positive, I was left with a feeling that something wasn’t right.
With our second major live release looming large on the horizon, I focussed the session on the theme of ‘Success’. My aim was to give the team a blueprint for a successful iteration to keep in mind when things were tough, and to help ensure that we were all pulling in the same direction by agreeing as a team what constitutes success for us.
Karl Scotland has posted a great description of how his team solved some issues they were having within their Scrum team by moving over to using a lean-thinking or Kanban system, based on a short buffer or Queue of Minimum Marketable Features (MMFs). It’s probably the clearest explanation I’ve seen yet of why and how to employ this emerging technique, and Karl certainly makes a compelling case for considering this as a progression for teams who are experienced with Scrum and need to be able to adapt rapidly during the development of a story or feature.
One of my key questions about Kanban is how it’s possible to predict long-term delivery dates for specific features, and although Karl goes some way to answering those questions, it looks as though you need, as well as a mature agile team, a fairly mature and trusting organisation to make this work.
I guess you also need to be working on a product that’s already in production and being updated regularly.