Note: This post is part of a series; you can find the first post here.
Introduction
Well, another 14 days passed by for the NerdBeers project, and a lot has happened:
- @Grumpydev added a proper design
- I did some major refactoring in the
FailingSqlite branch, which will allow us in the future to have full integration testing available for doing proper BDD (or top-down TDD, if you prefer to call it like that). Unfortunately, this branch is still pending for integration due to some problems.
- I got some followers/forks over at github (Yay!!)
- Some more people offered to help me out
- Both @MarkRendle and @NotMyself progressed a lot with both
Simple.Data and Simple.Data.SQLite
- Spring started; I enjoyed the sunshine outside with the kids and the Mrs.
- Social obligations
- My brother in law's house renovation deadline is approaching
- My brother's birthday party
- Lots of catching up with some friends
- ...
So Nerdbeers Has Not Really Changed a Lot? Are You Lamenting???
No, in fact I am not, I spent quite a lot of time on trying to get the "FailingSqlite branch" going, but unfortunately I have not been able to finish it, so I cannot integrate all my changes into the master branch.
After receiving a kind offer from someone to help me out on the project, he asked me what still needed to be implemented. This got me thinking:
In this project, I reject tools/methodology as long as possible. Since I noticed the project was starting to slip - I've spent a lot of time on it, but the Net result for the end user is still zero - I wondered how I could prevent this from happening again.
After all, that is what Agile/Lean is all about: be as efficient as possible in what you do, and the minute you are getting less efficient, look back at what happened, and find a way to make sure it does not happen again.
I used this approach all the time in the Nerdbeers project: I started without any tests or IOC, I postponed them until the manual testing process was slowing me down/not error-prone enough. This might mean I have a suboptimal design, but since there is no real business value in this, I can safely neglect this. When the suboptimal design starts getting in the way of doing efficient development, I can always refactor.
Anyway, back to the slipping part.
How Can I Prevent This Lamenting Stuff ?
The reason for lamenting is quite straightforward: I need a proper way to determine my - and the contributor's priorities. So I started creating issues on github, and after a few attempts of tagging, I finally found a method that works for me. It is heavily inspired by the Kanban stuff I use all the time during dev.
This is what the open issues list currently looks like:
Whoa, That's a Lot of Tags!! Why is That?
Well, because I need them; let's look at them one by one, in the order they are assigned:
- Type: Determine whether an issue is providing direct business value (bug or feature) or not (Tech)
- Time: A very rough estimate how much time it might take to implement; the purpose is helping you prioritize issues
- Care: This tag points to the person who is taking care of this issue (you could consider this a bit like an assignment)
- Stat: (short for status) Using
stat, you can follow the progress of the task
I tried searching for the minimal amount of tags which would allow to determine the correct priorities.
Using these tags, I found out that the huge branch I'm currently working on, does not really provide a lot of added business value, so I decided to lower the priority and make it a bottom one. This is actually something that happens a lot with projects: things get implemented because they are "cool", but they actually do not provide a lot of direct business value. These tags should help me to prioritize.
Another cool thing is that the closed issues list now actually provides some value:
Fixing the Features
As I was thinking about all the possible features, I noticed that I was adding a lot of them, without actually thinking them through. Since I wanted to avoid adding features which do not provide business value, I decided to implement a BDD technique into my feature definition.
Let's take a look at this in detail:
<span style="TEXT-DECORATION: underline">As a</span> site owner
<span style="TEXT-DECORATION: underline">I would like</span> the Nerd
<span style="TEXT-DECORATION: underline">To be able to</span> view a map of all upcoming nerdbeers
<span style="TEXT-DECORATION: underline">So that</span> he can choose whether he would organise one himself, or just join another one
This uses my favorte BDD format for BDD stories: you inform the reader who wants the feature, for whom it is designated, what it is and what the business value is.
This approach actually made me remove some of the issues I had entered, and made me alter some others. Someone who looks at a feature should now be able to figure out a lot based on these four simple sentences.
Conclusion
While the app in itself has not really evolved a lot, the way we approached it now has; this is what Agile/Lean is all about to me: provide business value in small incremental steps, reducing waste/being efficient as much as you can. I am rather curious to know what the next step will be in this project !!!
<script type="text/javascript" src="http://s7.addthis.com/js/250/addthis_widget.js#pub=xa-4aec37702e3161d4"></script>
