I was lucky enough to be able to attend Angela Druckman’s two day CSM (Certified Scrum Master) course in London this week. I can highly recommend it not least because the trainer was extremely good and very knowledgeable but also because the attendees brought a lot of interesting questions to the discussions.
Danube offers many free resources to help teams implement Scrum:
A good enumeration in your C# code isn’t going to look like the values in your lookup table in your database and neither is it likely to have great descriptions of the items that you could display to your users. So how to extend the enumeration?
We’ve used attributes and called them EnumDescription (to distinguish it from the ComponentModel defined DescriptionAttribute) and EnumRepositoryValue. We then used extension methods on the enumeration values so they could easily display a good description or submit their equivalent value to the database.
One problem is that the .NET Enum type is not extensible so you can’t easily create a FromRepository() extension method without decorating the base Type. For translating database values to enums we created a helper method instead.
Now you can say this:
EnumMother enumMother =
string description = EnumMother.Some.GetDescription();
string repositoryValue = EnumMother.Some.ToRepositoryValue();
public enum EnumMother
[EnumDescription("Nothing at all")]
None = 0,
[EnumDescription("Some of it")]
Some = 1,
A couple more extensions provide ToList() functionality as a bonus for creating user interface select lists.
We have Object Mothers in Alpha that wrap up test data for the unit tests. This is fine up to a point but we needed to add a Builder pattern to supplement the Factory pattern so we could have easy generation of default + overridden data. A comment on a blog post lead to the excellent NBuilder project which we’re now using.
These snippets of advice on Agile come from people who are practicing Agile and some of the comments are pure gold.
There are some useful resources for adding functionality to your C# application’s framework:
I favour dropping the estimation of Tasks in hours for a Sprint. It’s extra work and it doesn’t add anything to the process.
- It’s proven that relative estimation is more correct than absolute estimation. Since ideal man days is a time measure it’s all too easy to make absolute estimations.
- There is no linear correlation between a story point and the number of hours. People who ask how they can correlate story points with ideal time have not yet learned to separate the concepts properly.
- A story point is a universal measurement across the team. It is not biased by the experience or skills of any individual on the team.
- In the spirit of continuous improvement Agile practitioners ought to be alert to opportunities to reduce their process overhead (without losing effectiveness).
- If each story is small enough to be estimated and tested then there may be little benefit achieved through breaking it down into smaller tasks or re-estimating them in hours.
- The return on investment by estimating in hours is not high enough to make that a serious candidate. We want completed, working software, not very accurate estimates.
- A Product Owner wants to know how many features the team will deliver not how many hours each of them take. If the Product Owner gets an idea of the relative size he can prioritise and plan accordingly.
- After the 3rd or 4th sprint, the team reaches a steady state in story points and it becomes easier for the product owner to fill the backlog with story points.
- It’s difficult and time-consuming to to get developers to estimate time to completion. Developers are terrible at estimating because the work they do isn’t the same each time: either it’s a new business problem or they are dealing with a new technology. Developers also have a tendancy to “hoard” left-over time: if they think they have been allocated so many hours to do something then the work expands to fill the available time.
Dropping hours means that in VersionOne the Sprint Burndown Chart won’t show anything at all but we can refer to the Project Burndown Chart and the Cumulative Flow instead as that burns down Story Points.
64 bit versus 32 bit is stinging us all over the place. Now we have some x64 dev machines (nice) and others using x86 machines. The solution is to set the build platform target of each and every project file to x86.
Also, the build server (TeamCity) is on an x64 box. DLLs that were being called had to be updated like NUnit and the Oracle data client. Then NBehave had to be updated as it’s version of NUnit wasn’t exactly the same so we have a nightly build of NBehave!
There are even problems with some of our tools like this problem with PartCover.