Iteration 1
Iteration one has officially started. Now I am supposed to break down the user
stories of the iteration into tasks:
|
2
|
As a team leader I want to define and maintain iterations in a project
|
2
|
-
Introduce the domain class named iteration and
project (0.5h)
-
Create an ordered association between the two (0.5h)
-
Create a gui dialog for project where you can create and maintain iteration
objects and maintain the relation between the two (2h)
-
Create a search window where we can find projects and open them (2h)
|
|
3
|
As a team leader I want to define and maintain user stories so that we know what our goals are
|
3
|
-
Introduce the domain class user story (0.5h)
-
Build gui to maintain one user story (2h)
|
|
4
|
As a team leader I want to maintain relations between user stories and iterations so we
know what will be done in each iteration
|
2
|
-
Add a relation between userstory and iterations (0.5h)
-
Build gui to support assignment of stories to iterations (1h)
|
I now add estimates on each task in ideal hours. One task that pops up but is
not in any user story is the need for a search window. This is implicit in the
user story and it is clear to me as an implementer that it is needed, it is
important for almost all user stories. I choose to let the first user story take
the hit. Normally I would keep to whole ideal hours but introducing domain
classes and relations will be non-issues with the tool I use so assigning a
whole hour to that seems steep.
A word or two about tools; every team is free to choose their own set of tools.
I found the eco-framework for visual studio and I will never use a tool with
lesser capabilities again. I have read all the important books I believe, books
like Patterns of enterprise applications by Martin Fowler, the DDD book by Eric
Evans, GOF- the design pattern book, the inmates runs the asylum by Alan Cooper,
the DDD book by Jimmy Nilsson. I have also been engaged in many software
projects, both successful and things I would rather forget. I am what you may
call an experienced solution architect that has built enterprise systems
spanning in complexity from 10 database tables up to 300+ database tables.
The most surprising thing I have learned is that developers are stubborn, narrow
minded, know-it-all, won’t listen to
sound arguments type of people. Why is this surprising you may ask; it is normal
human behavior? True, but we are developers! Developers must be open minded,
listen to argument, re-think what is commonly taken for granted etc. It is our
job. Narrow mindedness is for non-developers. So if you recognize yourself in my
description; wise up – be open minded and start to listen to people! It is the
job. If you agree in any part to what I just wrote I salute you and I know that
you are not part of the problem – keep up the good work!
Ok, fine, now I got that of my chest. Thanks.
About the eco-framework for visual studio: You know that Martin Fowler does a
brilliant job in the enterprise patterns book to lay out all the stuff you
eventually need to make an enterprise application based on a domain model work
in real life? The eco-framework for visual studio has all this built in! It is
all there ready to use. Please note that I said “I will never use a tool with
lesser capabilities again”. That means that I am still open minded and if I find
a framework with equal capabilities I will consider using it, and if I find a
framework with better capabilities or one that is better suited for what I want
to do I will use it. Having eco has me satisfied to the degree that I have
stopped to actively look for a replacement.
I will not use hibernate, I will not use NPersist, I will not use
EntitiyFramework, and I will definitely not use the PAG-patterns (PAG-patterns;
do they count as a framework at all – maybe not). I will use eco for visual
studio because it solves all the infrastructure stuff with OR-mapping for any
database I can think of and it gives me excellent domain model tools, and
ability to offer multi level undo and redo for my users etc. It is without a
doubt the strongest domain model framework available. If you do not use a
framework for your work I urge you to list the 10 top reasons for not doing so.
Analyze your reasons with objective eyes and see if the reasons are strong
enough to motivate you to use valuable developer time to solve things that are
already solved and can be used with a small investment of time or possibly
money. To me the answer is so painfully obvious that I am always flabbergasted
when I meet developers that reach another conclusion.
Here I find myself churning away on tools when I should be coding. After all
iteration 1 has started…
I create the data I have for iteration 1 and the search form gives me this:
I double click the project and get this:
Double click a useDouble click a user
story and get this:
Iteration 1 is done. I move on to pick user stories for iteration 2. I could
just as well plan iteration 2 and even iteration 3 before starting iteration 1.
In fact to get an overview of the project I really must plan ahead more than
what I did for iteration 1. The information I have now is not enough to answer
the perfectively legit question: When is AgilePlanner done?
|