- The Six "Facets" of Traceability
- The Five Orders of Traceability
- The Four "Rings" of Enterprise/Stakeholder Visibility
- The Three Driving Forces for Traceability
- The Two Overarching Objectives of Traceability
- One Ultimate Mission/Vision - Fostering Trust
To make a long (but hopefully interesting) story short, we concluded that the overarching objectives of traceability are:
- Transparency: the ability to readily view all the information we are concerned with, and ...
- Identification: the ability to identify our concerns so we can separate independent sets of concerns and cohesively associate the related ones.
And these are supposed to be what help to engender trust. So can we achieve transparency and identification (and hence "navigable knowledge-spaces") without more traditional traceability methods, and if so, what are the different ways of doing it?
Our CM backgrounds differ strongly with the many vocal opinions expressed in XP community when it comes to the use of tools for tracking requests/changes: We are strongly in favor of using a "good" tracking tool. Index cards are a great and valuable "tool" for eliciting dialogue and interaction with the "customer" (and some of us even use them for this purpose, along with post-it notes). But from a CM-perspective, index cards alone simply do not suffice as a serious means of storing, tracking, sorting, searching, slicing & dicing development change requests.
We do believe an extent of traceability is necessary, and that it's not necessarily "agile", but that it can be, and should be, "lean" and streamlined. And it should serve the purpose of transparency, visibility and status-accounting rather than being a goal in itself. There are viable alternatives to achieving transparency and identification other than what many regard as "formal traceability." Some of these include things like:
- Direct customer communication, and better ways to make project information more transparent to the customer
- Ways of applying principles of simplicity and minimizing intermediate artifacts
Many of these concepts and more are embodied in Sam Guckenheimer 's recent book on Software Engineering with Microsoft Visual Studio Team System . We found this book to be surprisingly good (outstanding even), and not at all what one might expect given the apparent tool/vendor-specific nature suggested by the title. The value-up paradigm and most of the other concepts and values in the book are very well aligned with agility while still meeting the needs of more rigorous ceremony in their software and systems engineering efforts. Guckenheimer describes the basic differences as follows:
Attitudinal Differences Between Work-Down and Value-Up Paradigms
|Planning and change process
|Planning and design are the most important activities to get right. You need to do these initially, establish accountability to plan, monitor against the plan, and carefully prevent change from creeping in.
|Change happens; embrace it. Planning and design will continue through the project. Therefore, you should invest in just enough planning and design to understand risk and to manage the next small increment.
|Task completion. Because we know the steps to achieve the end goal, we can measure every intermediate deliverable and compute earned value running as the percentage of hours planned to be spent by now versus the hours planned to be spent to completion.
|Only deliverables that the customer values count (working software, completed documentation, etc.). You|