Continuing the saga of "getting a project going," a couple little issues have come up I thought would be "sponge-worthy" "blog-worthy."
Do you write Unit Tests for Private Methods?
Emphatically, no! The private methods should be getting tested through the public methods. One of the more common misperceptions about TDD, or really unit testing in general, is that you write a unit test per method. That's not entirely accurate. You write a unit test per external usage of the class, not in a 1-1 ratio of test to method. If you're truly writing your tests first, you nearly guarantee full coverage. Besides, writing a unit test to a private method is a form of tight coupling to the implementation of the class being tested. That kind of tight coupling between test and class is the most common cause of brittle tests. Brittle tests partially negate the value of unit tests by making change expensive because of breaking the existing tests.
Can you write Technical Stories?
According to some literal readings of XP dogma, each story must be connected to a business need. I think that was mostly intended to rein in the tendency of developers to obsess over technical infrastructure work instead of business value. In practice though, I think it's fine to have some purely technical stories, as long as they specifically enable a business story in the current or next iteration and no more. I think that splitting out a pure play technical story makes estimation and tracking simpler.
I'm happy to leave some sorts of work like build script enhancements be handled by "velocity" as ongoing overhead, but I've seen at least one control freak project manager insist that he have visibility into these activities as a story card that can be tracked. I'd be a little bit weary of that.
Technical stories and spike stories need to be controlled. There has to be a definitive goal of the technical story to know when it's been accomplished to avoid unnecessary Architecture Astronautics. If it's purely a "spike" just to learn about something or create a better estimate, maybe you just cap the story upfront with a maximum number of hours the team is going to spend on the story.
Perfect Estimates versus Let's Get Going
This issue is legitimately worrying me at the moment. I don't feel like we have enough information to go into release planning and create usable . The team and the customers are getting itchy to get on with development. Projects that stew too long in "Envisioning" or "Planning" or "Inception" or whatever run the risk of miring down in analysis/paralysis. I think coders without coding are effectively fish out of water. They can still move around a little bit, but they lose their vitality fast.
I'm definitely feeling like there's significant tension between Control/Predictability and project throughput (cue the inevitable reference to the Heisenberg Uncertainty Principle). Spending more time on analysis may get us better control with more accurate estimates, but I think it's sucking down our energy level. On the other hand, I think we might be far better off just to jump right into the first set of stories. We have a very logical first (large) story to work on that is fairly understood. Maybe we don't start with perfectly known scope, time, and estimates, but I'm very certain that it'll get the team working with much more energy. As long as the client's management understands that the estimates will be changing after that first iteration, I really don't see much downside. I'm much, much more worried about establishing a level of energized work and momentum than perfect predictability.
Estimate Together
This is absolutely crucial. Even though it might sound more efficient to divide up the stories by individual for estimation, it's not. Part of any kind of useful estimating is breaking the work down into finer grained tasks. That task breakdown is a very powerful form of team design. An XP team often creates and socializes their technical approach during tasking. Doing tasking and estimating inside silos hampers the flow of information through the development team.