RE: [scrumdevelopment] Re: Scrum and Traceability
- Why does "PCI-DSS requires traceability of code changes to requirements and to individual programmers and reviewers"? To what purpose? How is that information used? How is that information recorded and stored and disseminated and responded to and ustified and verified and validated?
And how does this add to the efficiency and effectiveness of the development team, and the business value of the product?
Date: Sun, 28 Feb 2010 22:40:34 +0000
Subject: [scrumdevelopment] Re: Scrum and Traceability
Scrum doesn't get into what to work on or how to do it -- it defers decisions on that to the product owner (for the what) and the team (for the how).
If you need traceability, your product owner should require that as a project constraint and let the team choose how to obtain it. One possibility would be to add some steps and checks into the development process -- just as you would do with any other project management framework. There might be others.
If your question is whether Scrum is compatible with traceability, the answer is yes: a team I worked for used Scrum (or at least some sort of scrum-but) in a PCI-DSS compliant company. PCI-DSS requires traceability of code changes to requirements and to individual programmers and reviewers, which I guess is what you're asking about.
Jordi Salvat i Alabart
--- In scrumdevelopment@ yahoogroups. com, "dsrkkk" <dsrkkk@...> wrote:
> Is there any role for traceability in scrum? How can we handle links in
Find out now Link all your email accounts and social updates with Hotmail.
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 email@example.com, "woynam" <woyna@...> wrote:
> --- In firstname.lastname@example.org, "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