| 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 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
|
