RE: [scrumdevelopment] Re: Scrum and Traceability
- What about them? You seem to be saying that there are two areas of concern here. By talking about 'safety critical' applications, you are acknowledging that a high level of care in development and testing is required. Yes, good idea, and very necessary. We don't want to cook anyone in the MZRI scanning machine.
But you are also talking about a second dimension, which is to document and 'trace' changes, and documen your risk analysis, and document ... and document ... and document ... because some external agency requires that documentation. OK, let's first get it straight ... th external agencies have imposed a documentation requirement. Scrum does not! And anyway, why do you really need to 'trace' all of this? I would assume that at the start of the project, at the project 'envision' phase, the safety critical issues would have been identified, and understood. Perhaps even at that point everyone agrees on ways and means to ensure that those risks are overcome. Perhaps even an auditor from the external agency will be present to observe the discussion and be satisfied that everyone understands those important matters. I would imagine a relatively small amount of documentation, probably in dot point form, would be created, as a checklist for later verification. I would also imagine that this list is not going to be totally comprehensive. Things will be realised and discovered as development proceeds. At the end of each sprint the list is ticked off as to compliance so far.
Why do we need to talk about 'traceability keys' and introduce other high-falutin' language for what is a quite simple matter?
Date: Mon, 1 Mar 2010 17:04:45 +0100
Subject: Re: [scrumdevelopment] Re: Scrum and Traceability
What about regulated environments like medical technology or safety critical applications?Imagine you're software product gets audited by an external governmental organization and/or a strong internal quality management department. These guys will take a look at your product's initial requirements with severe impacts (product risks). They want to know how these requirements are fulfilled, what you have done to minimize product risks, and which test cases have been defined and executed. What are you going to do other than introducing traceability keys?Cheers,Marc2010/3/1 Steve Ropa <theropas@...>Brian: "Why aren't women allowed to go to stoning, mother?"Mother: "Because its *written* that's why!"I see this discussion going the same direction as the baseline discussion. The only reason I've ever seen for either one, and I am not making light of this reason, is because someone else requires it. Whether it be the big boss on Mahogany Row who needs to see where things were and where they are going, or a project manager who has "learned over the years" that these artifacts are required. What I haven't seen is any need for the actual development team to have traceability of anything in particular..Ron,
Ron Jeffries wrote:
> Hello, pauloldfield1. On Monday, March 1, 2010, at 2:57:00 AM,
> you wrote:
>>> Is there any role for traceability in scrum? How can we handle
>>> links in scrum?
>> There are about 14 distinct reasons to have traceability, if you
>> count them all up. Almost all of these are irrelevant if you are
>> working in an agile fashion, and most or all of the rest are covered
>> by having a set of regression tests at 'green' (or not, as the case
>> may be).
> I'd love to see a list of about 14 reasons to have traceability,
> each with a few sentences on why with Agile one does not need them,
> and/or why they are covered by regression tests ...
As would I. I've seen may people ask about traceability on this an
other lists. Not one of them has answered my questions about what they
want to trace and why. The best answer I can get is that it's "required."
------------ --------- --------- --------- --------- --------- -
* George Dinwiddie * http://blog. gdinwiddie. com
Software Development http://www.idiacomp uting.com
Consultant and Coach http://www.agilemar yland.org
------------ --------- --------- --------- --------- --------- -
http://marcbless. blogspot. com
Get straight to the Point Find a great deal on your next car.
Couldn't we write the tests such that they don't look like tests, but rather requirements?
With one, and only one formal specification, which also happens to be executable against the actual system, aren't we better off than having to split time between two possibly out-of-sync artifacts?
ThoughtWorks has a testing tool called Twist, which uses something called Business Workflows. And now it has a nestable declarative aggregator called a "Concept" (what a concept!).
Twist is... designed to help you deliver applications fully aligned with your business. It eliminates requirements mismatch as business users directly express intent in their domain language.
I have not used the tool myself. If anyone has, please add some insight.
P.S. I have no affiliation w/ ThoughtWorks.
--- In firstname.lastname@example.org, "woynam" <woyna@...> wrote:
> --- In email@example.com, "pauloldfield1" <PaulOldfield1@> wrote:
> > (responding to George)
> > > I feel like a broken record with my questions.
> > I guess I need to learn to answer you better :-)
> > > pauloldfield1 wrote:
> > > > IMHO Traceability, of itself, has no value. However some of the
> > > > things that we DO value may be achieved readily if we have
> > > > Traceability.
> > >
> > > What are those things?
> > Well, I gave you a list of 15 things that some people value.
> > I guess we could take a lead from Hillel's sig line and say
> > they are all various categories of attempting to use process
> > to cover for us being too stupid to be agile.
> > We value knowing that we are testing to see that our system does
> > what the customer wants (but we're too stupid to write the
> > requirements directly as tests)... etc. etc.
> And this continues to irk the sh*t out of me. Why do we create another intermediate artifact that has to be translated by an error-prone human into a set of tests? What does the requirements document provide that the tests don't? Couldn't we write the tests such that they don't look like tests, but rather requirements?
> With one, and only one formal specification, which also happens to be executable against the actual system, aren't we better off than having to split time between two possibly out-of-sync artifacts?
> If you continue to have a separate requirements document, and your tests don't reflect the entirety of the requirements, what mechanism do you use to verify the uncovered requirements? How is that working for you?
> "A man with one watch knows what time it is; A man with two watches is never quite sure."
> > Paul Oldfield
> > Capgemini