Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [epf-dev] Another Unpublished Capability Pattern - Design Solutionno TDD

I was initially uncomfortable with the idea of having “hidden” capability patterns that come with the OpenUP distribution, but aren’t in the default published configuration.  However, the “TDD-optional” pattern made me reconsider.  The main reason is that TDD is hard to do well without some prerequisite skills and perspectives on development.  At its most basic, it’s really a personal habit, not a “process” in any formal sense, so rolling it out into an organization can be tough work.

 

My concern is that unfamiliarity or fear of TDD will dramatically drive down OpenUP adoption.  Worse, it could leave adoption unaffected, but immediately create a situation where team members say, “well, we have this published process that says this, but REALLY we do it THIS way.”  Process suicide!  After looking at the TDD-optional workflow below, I think it’s quite valuable to have it in our back pocket.  That way, we can always say, “well, you don’t have to do TDD to use OpenUP, you can do this more familiar workflow instead, and move to the preferred TDD pattern later.”  I would suggest making all three tasks parallel.

 

This helps organizations that are moving to more agile projects, because they can incrementally adopt practices without overwhelming their teams, and without complicated process engineering.

 

HOWEVER, let’s make sure that these optional patterns don’t violate our goal of “minimal, extensible, complete.”  The default configuration must be the preferred, executable process.  I sure don’t want to be giving speechs like, “OpenUP isn’t a process, it’s a process framework, and you have to tailor it before you can use it.”  Yuck!

 

Thanks,

Nate

 


From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Brian Lyons
Sent: Tuesday, July 10, 2007 2:10 PM
To: epf-dev@xxxxxxxxxxx
Subject: [epf-dev] Another Unpublished Capability Pattern - Design Solutionno TDD

 

hiho,

 

There was another side topic of discussion about how strict OpenUP treats a certain aspect of the process.  And that is, does the process “enforce” TDD.

 

Version 0.9 of the process had the work on developer tests going on in parallel with the implementation of the solution.  Then there was Concept: Test-first Design promoting the technique.

 

The default version 1.0 has a very explicit TDD workflow in the Capability Pattern: Develop Solution.  A Guideline: Test-first Design was also added to give more detail on the technique.

 

There has been discussion that some places just adopting agile techniques might not have the tool support and habits that work with TDD.  Do we want to have the process so explicitly prescribing the technique that someone will look at it and say “well, I don’t see myself working that way, so I guess it is not the process for me”?

 

With that in mind, I created a Capability Pattern with the element name develop_solution_no_tdd.  Each version of the Develop Solution Increment capability pattern has an overview of the workflow in the Main Description.  The default one has very explicit TDD verbiage along the lines of “The tests are run up front and, in failing, clearly define the criteria to determine if the implementation works as intended.”  The non-TDD one is more casual saying “Once the organization of the technical solution is clear, the development and testing of the implementation ensues.

 

Like the Iteration Template described in a previous message, this non-default CP is in the repository and not in the default published site.  But it supports the notion that OpenUP promotes TDD and that is the preferred way to build software, but it is not enforced such that non-TDD implementation should be characterized as “not doing OpenUP”.

 

I am distinctly out on a limb here and I welcome feedback.

 

Even if we agree that there should be a non-enforced-TDD version of this capability pattern, I think my first draft needs work.  Below I have pasted the standard 1.0 version of the workflow and then my non-TDD one.  As you can see, the default one has benefited from some good work by Jim Ruehlin stressing that the design can be revisited for refactoring once the tests pass.  That nuance is lost on my crappy version.

                                                                                                                               

                                   ----------------- b

 

 

 

Current drafty Non-TDD version

 

 

Standard develop_solution

 


Back to the top