Software Engineering - Agile Requirement in Product Development, How To?

Author

Agile Requirement in Product Development, How To?

me@andreat.de

2006-08-24, 4:01 am

Hello everybody,
I am at the moment trying to find out a suitable combination of Agile
techniques and Requirement Management methods to successfully manage
Product Development.

I try to be more specific... I am absolutely Agile Inside, I believe
that People Matter more than anything else, I believe that prototyping
is the only way to share results with the customer (internal or
external) and I believe that for each environment there is a different
suitable organizational solution to best perform agile. I also believe
that the "documentation" part of a project should be limited to the
amount that is bringing value, but what happens in case of Product
Development?

It is known, at least to me (and you can check also on
http://www.controlchaos.com/about/how.php) that Agile methods are more
suitable for "new" product development rather than for extensive
development, which means that "Product Development" in a way it is
included. My experience is that product development mostly spans
through years, development teams are changing and requirements are
changing in time... put the product vision, the goals and the main need
to fulfill are mostly the same.

In such condition how would requirement be agile enough and at the
same time "detailed" enough that new people coming to work on a product
can easily have an idea of what has been already implemented and what
not? Wiki can be a solution for sure, but is a "means" is not a
"method" :-) I am not searching for a "formal" something that does not
exist, but for a consistent way to bring key information forward in
time and better manage product maintenance.

am sure you all know that there are "maintenance fees" in every
contract including the usage of software licenses, and it is extremely
important to be able to identify, in case of "issues" whether the
"issue" submitted by a client it is a "Bug", a "Change Request" or a
"New Requirement", cause it has different impact from a contractual
point of view of course.

My understanding is that the "User Story" approach is a very good way
to understand the customer/market needs rather than the way things
should be implemented, and what happen normally (at least in Agile
project, one shot for one customer) is that the HOW the need (WHAT) is
solved, is up to the developers who are taking in care of that specific
"user story". This is ok, but what if the WHAT itself, or the real need
is understood in different ways from different developers, and it is
not written somewhere, how could it be possible in the future to find
out which requirement are already implemented inside the product and
which not? (don't tell me to look at the code... there are not so many
Linus out there ;-) )

So what are your suggestion, if you think I posed the problem in a
correct way? And do you think that the "Requirements Model" (however it
is formalized) is a part of the product itself, and is more or less a
real asset?

Thanks in Advance
ANdreaT

Phlip

2006-08-24, 7:00 pm

me wrote:

> I am at the moment trying to find out a suitable combination of Agile
> techniques and Requirement Management methods to successfully manage
> Product Development.

The Agile methodologies are unanimous that requirements must be gathered in
real-time, as a project grows. Never collect a zillion requirements up
front, then try to implement all of them.

Software projects should run in one-w

iterations, producing release
candidates with high-value features in them.

> I try to be more specific... I am absolutely Agile Inside, I believe
> that People Matter more than anything else, I believe that prototyping
> is the only way to share results with the customer (internal or
> external)

I thought "prototyping" was out. Define prototype.

> and I believe that for each environment there is a different
> suitable organizational solution to best perform agile.

Yes, but there are also certain engineering rules that are always right. You
always scrub before performing surgery. That's not zealotry, it's common
sense.

There was a time when it was the highest zealotry.

In software, you _always_ write tests before writing the tested code, you
_always_ sort features in order of business value, and you _always_ work in
short complete iterations. There are simply no exceptions for these simple
rules. They have a profound effect on design, and on your releases.

> I also believe
> that the "documentation" part of a project should be limited to the
> amount that is bringing value, but what happens in case of Product
> Development?

Then the Onsite Customer requests documentation (such as a users manual) and
the team delivers.

> It is known, at least to me (and you can check also on
> http://www.controlchaos.com/about/how.php) that Agile methods are more
> suitable for "new" product development rather than for extensive
> development, which means that "Product Development" in a way it is
> included.

You may have misunderstood that page. The Agile coaches - especially Scrum -
tend to _only_ target Product Development. They don't target research, or
one-shot programming. They target projects that expect to grow
indefinitely - for years if necessary. And they specialize in adaptive
planning.

> My experience is that product development mostly spans
> through years, development teams are changing and requirements are
> changing in time... put the product vision, the goals and the main need
> to fulfill are mostly the same.

Adaptive planning means you change the team, the requirements, and possibly
the goals, in real-time. The code's always high quality, so it's always
ready to change. The team can safely use the code, with end-users

Growing a big user population is an excellent way to maintain the long-term
goals. The goals are whatever the long-term customers want!

Put another way, we are not here to meet goals, we are here to help
customers profit.

> In such condition how would requirement be agile enough and at the
> same time "detailed" enough that new people coming to work on a product
> can easily have an idea of what has been already implemented and what
> not?

Most Agile shops write acceptance tests for all the requirements.

> Wiki can be a solution for sure, but is a "means" is not a
> "method" :-) I am not searching for a "formal" something that does not
> exist, but for a consistent way to bring key information forward in
> time and better manage product maintenance.

Pick one of these Wikis:

http://fitnesse.org
http://www.zeroplayer.com/cgi-bin/wiki?TestWikiFormat

They both edit and run acceptance tests.

Writing such tests is a "formal" method. Nothing about Agile is sloppy or
haphazard; it's _more_ disciplined than other processes.

> am sure you all know that there are "maintenance fees" in every
> contract including the usage of software licenses, and it is extremely
> important to be able to identify, in case of "issues" whether the
> "issue" submitted by a client it is a "Bug", a "Change Request" or a
> "New Requirement", cause it has different impact from a contractual
> point of view of course.

Why?

You can simplify by asking the customer to pay per iteration. They then get
to specify which feature requests and bug fixes (if any) go in each
iteration.

> My understanding is that the "User Story" approach is a very good way
> to understand the customer/market needs rather than the way things
> should be implemented, and what happen normally (at least in Agile
> project, one shot for one customer) is that the HOW the need (WHAT) is
> solved, is up to the developers who are taking in care of that specific
> "user story". This is ok, but what if the WHAT itself, or the real need
> is understood in different ways from different developers, and it is
> not written somewhere, how could it be possible in the future to find
> out which requirement are already implemented inside the product and
> which not? (don't tell me to look at the code... there are not so many
> Linus out there ;-) )

The acceptance tests and unit tests thoroughly document the product, from
the What to the How.

> So what are your suggestion, if you think I posed the problem in a
> correct way? And do you think that the "Requirements Model" (however it
> is formalized) is a part of the product itself, and is more or less a
> real asset?

You need to read a few books. You started with some major misconceptions,
and then you neglected several Agile practices that completely fix them.

--
Phlip
[url]http://c2.com/cgi/wiki?Z

Land[/url] <-- NOT a blog!!!

me@andreat.de

2006-08-24, 7:00 pm

Phlip wrote:
>
> The Agile methodologies are unanimous that requirements must be gathered in
> real-time, as a project grows. Never collect a zillion requirements up
> front, then try to implement all of them.

I never talked about collecting requirement front up, my concern is
more on how to keep them always up to date and versioned in a baseline
with the actual code... may be on an iteration base. After 4 or 5 years
if requirements are not kept in sync there will be no traceability left
with the product, and requirements will become completely unusefull :-(

> Software projects should run in one-w

iterations, producing release
> candidates with high-value features in them.

I think this is "theorically" right, but every project I have seen up
to now, was barely able to deliver every 2-3 w

s something
valuable... and release candidate have to be tested (acceptance tests)
before being actually released, and this time is != 0

>
> I thought "prototyping" was out. Define prototype.

Ok I missmatched, I was meaning here the incremental build, or builds
that are conceptually giving an idea on how the functionality will look
like (from the user point of view) but are not fully completed. To be
more clear, are valid functional increments from the developer point of
view but are probably only a part of a Feature from the user
perspective.

>
> In software, you _always_ write tests before writing the tested code, you
> _always_ sort features in order of business value, and you _always_ work in
> short complete iterations. There are simply no exceptions for these simple
> rules. They have a profound effect on design, and on your releases.

I agree, but to write tests you need requirement to be tested,
otherwise against what you test?

>
> Then the Onsite Customer requests documentation (such as a users manual) and
> the team delivers.

Uhm... all unstructured documents that can be interpreted in a
different way from different persons, I would be more confortable in
having well defined SMART requirement agreed and discussed at every
iteration. Than you can keep all the requirement model versioned
together with the product releases.

> You may have misunderstood that page. The Agile coaches - especially Scrum -
> tend to _only_ target Product Development. They don't target research, or
> one-shot programming. They target projects that expect to grow
> indefinitely - for years if necessary. And they specialize in adaptive
> planning.

For sure I have misunderstood, I am reading a lot of documents and
books at the moment, but what matters more is the experience of people
really doing it ;-)

> Adaptive planning means you change the team, the requirements, and possibly
> the goals, in real-time. The code's always high quality, so it's always
> ready to change. The team can safely use the code, with end-users

The Code is always high quality? How? Because "very-good" developers
are writing it? I think one of the goal for the development team is to
have high quality code, that can change easily with new requets, that
can't be an assumption! It is indeed one of the reasons why it is
important to have good requirement, to try do design the architecture
in the better way possible from the beginning, doesn't mean that it has
not to change, but to build a toaster and a washing machine are two
different things ;-)

> Growing a big user population is an excellent way to maintain the long-term
> goals. The goals are whatever the long-term customers want!

100% Agree, I never discussed about the content...

> Put another way, we are not here to meet goals, we are here to help
> customers profit.

100% the customer profit is the customer goal, and our goal is to make
the customer reaching is goal => the customer profit is our goal!

>
> Most Agile shops write acceptance tests for all the requirements.

But where are the requirement written? And how can be acceptance test
detailed if the requirement are not? I agree that one should validate
the other, and is mostly like this, it also often happens that the user
is changing is mind or changing the requirement during the explanation
of the acceptance tests, this helps everybody in the project to
collaborate toward a common understanding and the best suitable
solution to the customer need, but still is not the answer... is it a
practice to write requirements and iterate validations also through
acceptance tests?

>
> Pick one of these Wikis:
>
> http://fitnesse.org
> http://www.zeroplayer.com/cgi-bin/wiki?TestWikiFormat
>
> They both edit and run acceptance tests.

I will have a deeper look, thanks a lot

> Writing such tests is a "formal" method. Nothing about Agile is sloppy or
> haphazard; it's _more_ disciplined than other processes.

I believe so... and I am always fighting when I see people comparing
agile with doing less things or being less formal...

>
> Why?
>
> You can simplify by asking the customer to pay per iteration. They then get
> to specify which feature requests and bug fixes (if any) go in each
> iteration.

Unfortunately if you work on a project bases, you make project
contract, and is everything included, the risk of the project is at
your side, this is how mature cutomer are working (think about
governament projects or public bid, there is a budget and that's it).
The good management of the project is indeed in being able to define at
every step what will be delivered and the more detailed it is the
better it is... so if you can prove that there is a big change compared
to the initial requests you can ask for extras or refuse the change if
it will impact too much on the project.

>
> The acceptance tests and unit tests thoroughly document the product, from
> the What to the How.

I agree, at some extent, but is more or less like the "complementary"
description of what the product is doing, would not be easiear just to
write requirements?

>
> You need to read a few books. You started with some major misconceptions,
> and then you neglected several Agile practices that completely fix them.

I do really apprecate your comments, I do read book and I will never
stop to, it is a way to learn thing, but beside I think experience is
much more valuable. I also didn't neglect anything about agile, I just
posed a problem that I have to solve, and I would like to have some
comments, that all!

Thanks again
ANdreaT
--
Andrea Tomasini - <me@andreat.de>
http://www.andreat.de
http://processinpractice.andreat.de <- it is a Blog!

JXStern

2006-08-24, 7:00 pm

On 24 Aug 2006 02:07:04 -0700, me@andreat.de wrote:

>Hello everybody,
> I am at the moment trying to find out a suitable combination of Agile
>techniques and Requirement Management methods to successfully manage
>Product Development.

Don't expect some magic formula to do your job for you!

> I try to be more specific... I am absolutely Agile Inside, I believe
>that People Matter more than anything else, I believe that prototyping
>is the only way to share results with the customer (internal or
>external) and I believe that for each environment there is a different
>suitable organizational solution to best perform agile. I also believe
>that the "documentation" part of a project should be limited to the
>amount that is bringing value, but what happens in case of Product
>Development?

I guess by "product development" you mean something like "product
management" over time, marketing and strategic decisions that overlap
but are also somewhat outside of "development" concerns.

> It is known, at least to me (and you can check also on
>http://www.controlchaos.com/about/how.php) that Agile methods are more
>suitable for "new" product development rather than for extensive
>development, which means that "Product Development" in a way it is
>included. My experience is that product development mostly spans
>through years, development teams are changing and requirements are
>changing in time... put the product vision, the goals and the main need
>to fulfill are mostly the same.

OK. I think.

> In such condition how would requirement be agile enough and at the
>same time "detailed" enough that new people coming to work on a product
>can easily have an idea of what has been already implemented and what
>not? Wiki can be a solution for sure, but is a "means" is not a
>"method" :-) I am not searching for a "formal" something that does not
>exist, but for a consistent way to bring key information forward in
>time and better manage product maintenance.

YOU have to be agile!

> am sure you all know that there are "maintenance fees" in every
>contract including the usage of software licenses, and it is extremely
>important to be able to identify, in case of "issues" whether the
>"issue" submitted by a client it is a "Bug", a "Change Request" or a
>"New Requirement", cause it has different impact from a contractual
>point of view of course.

OK.

> My understanding is that the "User Story" approach is a very good way
>to understand the customer/market needs rather than the way things
>should be implemented, and what happen normally (at least in Agile
>project, one shot for one customer) is that the HOW the need (WHAT) is
>solved, is up to the developers who are taking in care of that specific
>"user story". This is ok, but what if the WHAT itself, or the real need
>is understood in different ways from different developers, and it is
>not written somewhere, how could it be possible in the future to find
>out which requirement are already implemented inside the product and
>which not? (don't tell me to look at the code... there are not so many
>Linus out there ;-) )

There's no magic answer. For each issue, somebody has to look at the
code (white box) or exercise the product (black box) to verify the
report and diagnose the situation, propose a solution and an estimated
cost, which then gets presented to you (or whoever decides) for
prioritization with your limited resources (time, people, expertise).
Being product marketing, you have to go outside and see the positive
"opportunity costs" attached to each, in order to make your decisions.

> So what are your suggestion, if you think I posed the problem in a
>correct way? And do you think that the "Requirements Model" (however it
>is formalized) is a part of the product itself, and is more or less a
>real asset?

It's part of product management. You don't need to ship it to the
customers.

However, depending on your product and customer base, it can be useful
to put together a "users group" and review your entire things-to-do
list with them and let them vote. You don't have to follow the
results entirely, but it's good if you promise to at least give
special priority to the top 1 or 3 or 10 that get the votes.

>
>Thanks in Advance
>ANdreaT

I agree with Phlip, get yourself some books, on product management and
marketing, more than on software development.

Agility is a virtue in business, too!

J.

Scott Frye

2006-08-24, 7:00 pm

Phlip wrote:
> In software, you _always_ write tests before writing the tested code, you
> _always_ sort features in order of business value, and you _always_ work in
> short complete iterations. There are simply no exceptions for these simple
> rules. They have a profound effect on design, and on your releases.

This global, all-encompasing statement is VERY close minded and will
prevent people from exploring better ways to develop software.

There is a lot of software (good and bad) out there that was developed
in other ways and than continues to be developed in other ways.

What you describe, MAY be a good goal, but its not the only way things
ARE done or CAN be done.

>
> Most Agile shops write acceptance tests for all the requirements.
>

Requirements and unit tests are not the same thing.
Unit tests and software documentation are not the same thing.

>
> You can simplify by asking the customer to pay per iteration. They then get
> to specify which feature requests and bug fixes (if any) go in each
> iteration.

The real world doesn't always work this way.

> The acceptance tests and unit tests thoroughly document the product, from
> the What to the How.

Just because they thoroughly document the product, doesn't make them
the only required documentation.
FOR EXAMPLE:
If you project is going to be 1 million lines of code, then your tests
should be at LEAST 1 million lines of code, according to popular
thought on unit test-code ratios. I can't imagine using Unit tests as
your documentation to discuss how you are going to structure your
business rules layers; or your deployment scenario. Furthermore, a
plan should be made BEFORE you waste your time writing those 1 million
lines of tests. Finally, that plan should be part of the product
documentation and be referenced by the developers writing creating the
code.

-Scott Frye
-------------------------------------------------
"The person who says it cannot be done should not interrupt the person
doing it."
Chinese Proverb.
-------------------------------------------------

Phlip

2006-08-24, 7:00 pm

me wrote:

>
> I think this is "theorically" right, but every project I have seen up
> to now, was barely able to deliver every 2-3 w

s something
> valuable... and release candidate have to be tested (acceptance tests)
> before being actually released, and this time is != 0

Test Driven Development changes that formula. Without it, you can't guess
which feature will be the one that causes a long bug hunt. So you must use
longer iterations, to fit in the easy features with the hard ones.

Further, without TDD, rework gets harder, so design quality is harder to
maintain. So you also need bigger feature batches, to avoid endlessly
merging small features into an existing design.

With TDD, you can safely pick small features of highest value. So a plan
that a GUI may someday use a list box is fine, but if you can make a single
edit field useful, now, you deliver that first.

>
> Ok I missmatched, I was meaning here the incremental build, or builds
> that are conceptually giving an idea on how the functionality will look
> like (from the user point of view) but are not fully completed. To be
> more clear, are valid functional increments from the developer point of
> view but are probably only a part of a Feature from the user
> perspective.

A "feature" is everything a user needs. Users need each feature to contain:

- storytests, so the feature is stable
- unit tests, so the feature's code is stable
- well-designed code supporting the feature
- a users manual detailing the feature
- a GUI for the feature
- an installer for the feature's application
- a database and support details.

Don't do one of those, as a prototype, in isolation from the others. Do all
of them for each feature.

> I agree, but to write tests you need requirement to be tested,
> otherwise against what you test?

Let's call "requirement" the "thing that the user thinks will make them
profit". A requirement is a line-item of a project.

Call "specification" the "technical details of a feature that are testable".
You specify each feature as you code it. If you can't test it, you can't
code it.

>
> Uhm... all unstructured documents that can be interpreted in a
> different way from different persons, I would be more confortable in
> having well defined SMART requirement agreed and discussed at every
> iteration. Than you can keep all the requirement model versioned
> together with the product releases.

Have you seen this working before?

It's the storytest role I indicated.

>
> The Code is always high quality? How? Because "very-good" developers
> are writing it?

Because if it's not, you stop and fix it until it is. A pair of programmers
who find a way to improve something are "required" to attempt the
improvement.

An Agile project always works with the code in a high quality state.

> I think one of the goal for the development team is to
> have high quality code, that can change easily with new requets, that
> can't be an assumption!

When you add a new feature, the design quality may drop. The feature might
be different than the current design. At that time, you refactor the design
(under test) until the quality improves.

I'm glad we hit this speedbump in your understanding. Many shops willingly
let the quality slide, _knowing_ that it could be improved, and accusing
programmers who s

improvements of "wasting our time with that academic
stuff".

Low code quality causes death by a thousand tiny nibbles.

> It is indeed one of the reasons why it is
> important to have good requirement, to try do design the architecture
> in the better way possible from the beginning, doesn't mean that it has
> not to change, but to build a toaster and a washing machine are two
> different things ;-)

Always delay expensive and irreversible decisions. For your first set of
features - in your first one-w

iteration - you supply just enough code to
deliver those features.

This is why above I noted that a feature is not complete unless it has
"well-designed code supporting the feature". A code with a speculative
design, with empty stuff that _could_ someday work, when we implement more
features, is not high quality.

>
> 100% Agree, I never discussed about the content...

They are the requirements base. They still exist (hopefully), and still
require your software. That is the momentum you s

- not paperwork.

Paperwork is the assumption we don't have a user base, so we must write down
what they would need, if we had them. That's the admission of defeat.

> But where are the requirement written?

IN ACCEPTANCE TESTS

> And how can be acceptance test
> detailed if the requirement are not?

Because you don't write them until you are ready to code them. Hence you
have researched the situation - just enough - with your onsite customer's
help, to start specifying and coding them.

> I agree that one should validate
> the other, and is mostly like this, it also often happens that the user
> is changing is mind or changing the requirement during the explanation
> of the acceptance tests, this helps everybody in the project to
> collaborate toward a common understanding and the best suitable
> solution to the customer need, but still is not the answer... is it a
> practice to write requirements and iterate validations also through
> acceptance tests?

What specific problems with requirements have you endured in the past?

>
> I believe so... and I am always fighting when I see people comparing
> agile with doing less things or being less formal...

No need to fight that; just win.

>
> Unfortunately if you work on a project bases, you make project
> contract, and is everything included, the risk of the project is at
> your side, this is how mature cutomer are working (think about
> governament projects or public bid, there is a budget and that's it).

Then don't cut contracts like that. Cut a start-up period of, like 6
iterations, and then use pay-as-you go. And run the first 6 iterations
exactly like the rest, so the client knows how the system will work. They
should be delighted to get better control over the system.

> The good management of the project is indeed in being able to define at
> every step what will be delivered and the more detailed it is the
> better it is... so if you can prove that there is a big change compared
> to the initial requests you can ask for extras or refuse the change if
> it will impact too much on the project.

That's "big requirements up front", which I busted on. It adds risk. Adding
risk terms to the contract is not the same as fixing the risk!

--
Phlip
[url]http://c2.com/cgi/wiki?Z

Land[/url] <-- NOT a blog!!!

bill turner

2006-08-24, 9:59 pm

On 24 Aug 2006 13:22:10 -0700, "Scott Frye" <scottf3095@aol.com>
wrote:

>
>Phlip wrote:
>
>This global, all-encompasing statement is VERY close minded and will
>prevent people from exploring better ways to develop software.
>
>There is a lot of software (good and bad) out there that was developed
>in other ways and than continues to be developed in other ways.
>
>What you describe, MAY be a good goal, but its not the only way things
>ARE done or CAN be done.
>
>
>Requirements and unit tests are not the same thing.
>Unit tests and software documentation are not the same thing.
>
>
>The real world doesn't always work this way.
>
>
>Just because they thoroughly document the product, doesn't make them
>the only required documentation.
>FOR EXAMPLE:
>If you project is going to be 1 million lines of code, then your tests
>should be at LEAST 1 million lines of code, according to popular
>thought on unit test-code ratios. I can't imagine using Unit tests as
>your documentation to discuss how you are going to structure your
>business rules layers; or your deployment scenario. Furthermore, a
>plan should be made BEFORE you waste your time writing those 1 million
>lines of tests. Finally, that plan should be part of the product
>documentation and be referenced by the developers writing creating the
>code.

And, you seem to be only talking about functional requirements. I
don't know how you would use a test case to document many of the
non-functional requirements, such as look and feel, usability,
performance (well, this might be easy to document with a test case),
operational (e.g. environment factors like extreme heat or cold, loud
noises, etc.), product distribution requirements, migration,
maintainability/supporability/adpatability, data integrity, privacy,
political, and compliance. Yes, many of these could be captured in
tests, but just as many would be difficult, if not impossible to
capture. Without a knowledgeable RE, it is hard to imagine a coder (or
pair) working in conjunction with an on-site user that will elicit all
these requirements and keep them in the forefront so as not to be
violated by later development.

There are three components to the requirements process: elicitation,
analysis and validation and verification. As can seen from the
paragraph above, I am dubious of the capability to elicit all the
important requirements in a timely fashion, let alone have the
capability to document them all with test cases, especially in large,
complex projects. But what seems to be really missing is the analysis
of the requirements. Requirementes analysis is, of course, a large
topic. What the test cases cannot do is identify possible
off-the-shelf candidates. Nor can they identify reusable artifacts or
existing similar products that can be copied. Nor can they identify
risks. Tests generally are focused on the product under development,
so they do not tell us anything about the impact on the operating
environment, nor on other systems that may interact either directly or
are data coupled. They won't tell us anything of potentially adverse
user reactions. They do not tell us anything of the risks.

Because of the manner in which requirements are elicited in Agile
development, it does not encourage or even really allow for one to
search beyond the edges, to see a bigger picture. This would seem to
decrease the likelihood that one would produce a product that is a
great leap forward.

Then there is the meta question. How, if one substitutes tests for
real RE, can one ever learn of all these potential areas of study so
that they can be brought to the fore in a timely manner and kept
there?

Agile development definitely has its positives. Just be aware that
there are areas for concern. This being just one. Go ahead and use it,
just remain skeptical of all silver bullets and think critically about
what it is you are doing.

>
>-Scott Frye
>-------------------------------------------------
>"The person who says it cannot be done should not interrupt the person
>doing it."
>Chinese Proverb.
>-------------------------------------------------

------------------------------------------
Bill Turner

A faith that the free play of market forces will eventually end in Good is, in fact, more 'absurd' than religious belief, for there, at least, there is a presumption of an intelligent Agent Who writes straight with His crooked lines. - William Pfaff

Views expressed are entirely my own and only coincidentally represent those of other persons or entities.

Phlip

2006-08-25, 8:00 am

bill turner wrote:

> Scott Frye wrote:

[color=darkred]
[color=darkred]

"Louis Pasteur's theory of germs is ridiculous fiction". --Pierre Pachet,
Professor of Physiology at Toulouse, 1872

Now focus on the terrible meaning behind that silly pronouncement. ~20 years
after Pasteur's studies, a surgeon at a teaching hospital is _still_ not
washing his hands, or sterilizing his instruments, before he operates on
people. And neither are his students.

So people are dying, needlessly, because he thinks that there can't be One
True Way to prepare for surgery. Sometimes, in technology, there actually is
One True Way.
[color=darkred]

And some of Pierre's patients indeed survive their experience with him...
[color=darkred]
[color=darkred]

Acceptance tests are not unit tests.
[color=darkred]

I don't have that problem.
[color=darkred]
> And, you seem to be only talking about functional requirements. I
> don't know how you would use a test case to document many of the
> non-functional requirements, such as look and feel, usability,
> performance (well, this might be easy to document with a test case),
> operational (e.g. environment factors like extreme heat or cold, loud
> noises, etc.), product distribution requirements, migration,
> maintainability/supporability/adpatability, data integrity, privacy,
> political, and ...

Of course you can't. That's no excuse not to write every other kind of test
you can think of, and to go to them first for documentation and such.

> ...compliance.

In this specific case, regulatory bodies might indeed someday demand
compliance via automated tests.

I can see the complaint now: "Oh, why should a fascist government body force
us to pass automated tests??!! They are infringing our freedom! Back in my
day, all we had to do was fill out useless forms that didn't really force
compliance!!"

> Yes, many of these could be captured in
> tests, but just as many would be difficult, if not impossible to
> capture. Without a knowledgeable RE, it is hard to imagine a coder (or
> pair) working in conjunction with an on-site user that will elicit all
> these requirements and keep them in the forefront so as not to be
> violated by later development.

Once you acheive the non-functional requirement, many tests on functional
requirements tend to pin it down. The odds of it changing go down.

And I suspect you think someone said, "never write down any requirements,
ever". Write the remaining f---ers down. The list will be short enough to
actually reduce risk!

> There are three components to the requirements process: elicitation,
> analysis and validation and verification. As can seen from the
> paragraph above, I am dubious of the capability to elicit all the
> important requirements in a timely fashion, let alone have the
> capability to document them all with test cases, especially in large,
> complex projects. But what seems to be really missing is the analysis
> of the requirements.

It's not a "user story" until it has a priority, a cost estimate, and a plan
for a test. Determining these things _is_ analysis.

You aren't going to tell us you don't determine all three of those things
for every single one of _your_ requirements, are you?

> Requirementes analysis is, of course, a large
> topic. What the test cases cannot do is identify possible
> off-the-shelf candidates.

That's why there are other practices, such as hiring programmers with more
than two brain-cells to rub together.

Oops, I think that's not in the White Book. I guess you are right!

> Nor can they identify reusable artifacts or
> existing similar products that can be copied.

That's under "duplication removal".

> Nor can they identify
> risks.

I can't think of a risk that can slip thru all this discipline. Could you
name a specific one?

> Tests generally are focused on the product under development,
> so they do not tell us anything about the impact on the operating
> environment, nor on other systems that may interact either directly or
> are data coupled. They won't tell us anything of potentially adverse
> user reactions. They do not tell us anything of the risks.

That's why you deploy early and often, you practice internal Continuous
Deployment, and you automate your entire build and test pipeline.

> Because of the manner in which requirements are elicited in Agile
> development, it does not encourage or even really allow for one to
> search beyond the edges, to see a bigger picture. This would seem to
> decrease the likelihood that one would produce a product that is a
> great leap forward.

Besides, uh, sorting features in order of business priority? And only fully
specifying the highest value ones?

It seems to me those would be the ones that the customers have the _best_
idea what they need.

So sorting features by business value might just be an ... analysis
technique, hmm?

Or do you "analyze" by sorting in some other order?

> Then there is the meta question. How, if one substitutes tests for
> real RE, can one ever learn of all these potential areas of study so
> that they can be brought to the fore in a timely manner and kept
> there?

Yawn. That's the Onsite Customer's role. That's why it's a fulltime role.

> Agile development definitely has its positives. Just be aware that
> there are areas for concern.

Yes; a lot of people thoroughly misunderstand some of its simplest aspects.

--
Phlip
[url]http://c2.com/cgi/wiki?Z

Land[/url] <-- NOT a blog!!!

Phlip

2006-08-25, 8:00 am

Land[/url] <-- NOT a blog!!!

tumma72

2006-08-25, 8:00 am

JXStern wrote:
> Don't expect some magic formula to do your job for you!

I never do... I just try to find a good enough recipe ;-)

> I guess by "product development" you mean something like "product
> management" over time, marketing and strategic decisions that overlap
> but are also somewhat outside of "development" concerns.

Product Management is more a marketing discipline rather than a
development practice, but it affects extremely the way the product is
developed, expecially in fully product driven companies.

Think that you have a good idea and you want to create a new product
for the market... or a new technology, you don't have any "user" out
there, and you have to find out as fast as possible, without investing
too much money if the idea you have is worth of making a product.

You develop a kind of "Proof-of-Concept" which is for me a prototype to
check whether the idea you have had was good and some people are
willing to use it (ok, you make market analysis, you try to identify a
market where to place your product...) than assume you decide to make
a product.

As far as my experience tought me, what happens is that at first you
know what to build because you are evolving and refining the original
idea, that was to make "your something" and to please a certain number
of potential users, than the users will start to ask you to change
things. Never the less the point is that if you want to be different,
and to make your product special, you should be able to anticipate some
how the needs on the market, otherwise if the rule would be:
"...the largest customer base you have, the more detailed and
interesting feedback you have, the better product you can build..."
than only big companies will exist, company who can also pay to have
users, and company who have enough resources to buy what they need to
succeed. But thank good is not like this, there are also some recent
examples (think at skype) they had a good idea, they started to promote
it for free, and than they found an interesting business model that
somebody else was liking... ;-)

The point I wanted to stress is, a product lifecycle, from the
development point of view is unpredictable and subject to a lot of
market rules, but never the less has always a "strategic" driver, that
is what makes the difference between two solution to the same problem
(problem: WordProcessing, solutions: MS Word, OpenOffice, KWrite,
Abiword...) and what make some customer choose for you instead of the
competitor. These differences are mostly coming out of the vision of
people who are developing the product. After 3 to 5 year the product
may be really a big thing, and without having a disciplined way of
managing requirements - from the beginning - I don't think frankly that
you could survive so long. The developers in a product development
context are some time forced to "prepare" functionalities for future
releases, it is not so straightforward that you have a w

ly iteration
and you put inside everything that is needed... and done!?

>
> YOU have to be agile!

Yes, what I meant was, how can I be agile related to Requirements?

> There's no magic answer. For each issue, somebody has to look at the
> code (white box) or exercise the product (black box) to verify the
> report and diagnose the situation, propose a solution and an estimated
> cost, which then gets presented to you (or whoever decides) for
> prioritization with your limited resources (time, people, expertise).
> Being product marketing, you have to go outside and see the positive
> "opportunity costs" attached to each, in order to make your decisions.

And don't you think that if you would be able to keep "agile" in sync
the all traceability chain from Requirement through code, once you have
an issue related to some topics, you would be able to limit the scope
to a very specific set of Requirements->Features->Code->Tests to be
checked and thus avoind to fish into a blakbox?

>
> It's part of product management. You don't need to ship it to the
> customers.

It is true that you don't need to ship it to the customer, even if up
to now I always had to write down requests from the customer (user
story) transform it into SMART requirements, go back to the customer
with them and agree that I had a good understanding of the problem,
write acceptance tests and go back to agree that the customer would be
happy and satisfied if all the defined tests, matching the defined
requirement will be executed correctly, and all this "baselined" to
specific product releases. So the customer is getting a part of it,
even if not as a product.

Be aware that this doesn't mean to have Huge Front Up requirements,
because at every iteration there may be some new, and some changes to
old one, the only difference is that you can show the customer, against
a issue, that he agreed something else before and if he wants to change
that thing now, it will mean to change other things... and is going to
take time... and money possibly :-)

> However, depending on your product and customer base, it can be useful
> to put together a "users group" and review your entire things-to-do
> list with them and let them vote. You don't have to follow the
> results entirely, but it's good if you promise to at least give
> special priority to the top 1 or 3 or 10 that get the votes.

This is a good technique, is what I call Requirement Workshops, is not
always applicable (you need a certain number of domain experts
available) but it is indeed a very good way to collect and identify
requirement, for sure less expencive than interviews ;-)

> I agree with Phlip, get yourself some books, on product management and
> marketing, more than on software development.

I already read a lot of books, and I have been a product manager as
well, now I am working as a consultant and I am trying to support
client in optimizing and improving the End-to-End software development
process. If you have some books in particular, you think can help me in
finding out applicable agile requirement solution for product
development, please tell me!

> Agility is a virtue in business, too!

That's really the silver bullet :-)

Ciao & Thanks
ANdreaT
--
Andrea Tomasini - <me@andreat.de>
http://processinpractice.andreat.de
http://www.andreat.de

tumma72

2006-08-25, 8:00 am

Phlip wrote:

>
> Test Driven Development changes that formula. Without it, you can't guess
> which feature will be the one that causes a long bug hunt. So you must use
> longer iterations, to fit in the easy features with the hard ones.

With TDD it is possible to define Unit tests, and suites, but as far as
I can understand, there are some acceptance tests that have to be
executed from the users, and some different sample data that should be
used against the user-interface, so you can't really automate them, and
these will take normally a significant amount of time.

> Further, without TDD, rework gets harder, so design quality is harder to
> maintain. So you also need bigger feature batches, to avoid endlessly
> merging small features into an existing design.

Assuning you do TDD, the principle is to write first how you whould
test things, than to run tests until you fixed all the error in the
simplest way possible and the test are running, than you improve the
tests... and you go forward... but where exaclty you enforce design and
patterns with TDD?

> With TDD, you can safely pick small features of highest value. So a plan
> that a GUI may someday use a list box is fine, but if you can make a single
> edit field useful, now, you deliver that first.

I agree, this is my "prototyping" concept, the thing it is working but
is not exactly what the user expects from a usability point of view...
(some usabililty requirement that you can't test with automated tests
nor with TDD).

> A "feature" is everything a user needs. Users need each feature to contain:
>
> - storytests, so the feature is stable
> - unit tests, so the feature's code is stable
> - well-designed code supporting the feature
> - a users manual detailing the feature
> - a GUI for the feature
> - an installer for the feature's application
> - a database and support details.
>
> Don't do one of those, as a prototype, in isolation from the others. Do all
> of them for each feature.

And if the feature has nothing to do with a Database? Or the whole
application has no persistence data at all? Ok... this is a
philosophical objection, I agree in general with the principle that
each requirement should be SMART = Specific Measurable Achievable
Realistic Traceable (instead of Time-Bound), than is a requirement. Are
all subjective qualities more or less, but the fact that are Measurable
== You can Test Them (not only with code), and Traceable == The
customer asked for it in that user story...

>
> Let's call "requirement" the "thing that the user thinks will make them
> profit". A requirement is a line-item of a project.

That's the most difficult thing to achieve... requirements from users,
you alway get solutions and not needs, they tell you what they want the
system to do... instead of what is their problem, so a part of the
analysis is to transform their request into needs, and go back to them
to check that the need are well understood, than you can propose the
best solution to suite the need within time, budget, technology and
quality constraints.

>
> Have you seen this working before?

Yes, I did, it is possible if you start from the beginning of a project
to deal with the client and the requirement in this way... there is a
change, file the change, at every iteration pick up all the changes
sort them out, get some, drop some others, check the affected
requirements, trace to the code and tests, propagate the change through
the all chain and version again... :-)

> Because if it's not, you stop and fix it until it is. A pair of programmers
> who find a way to improve something are "required" to attempt the
> improvement.
>
> An Agile project always works with the code in a high quality state.

That doesn't mean that the desing is good neither that the architecture
is good, because these two things depends on the high level scope and
performace, scalability constraints that you can't simply melt into
Unit Tests...

> When you add a new feature, the design quality may drop. The feature might
> be different than the current design. At that time, you refactor the design
> (under test) until the quality improves.

I think this is a good principle, and I often used it, the point is
that it is working good if all the people working in to the project
already have a very deep knowledge on the whole architecture, and they
can start poting things in the right places, than refactoring is
moderately expensive. In general I keep in mind that to fix problem at
the requirement/design level has a cost, to fix them at the code level
has a much higher cost (don't think always to waterfall ;-) )

>
> Always delay expensive and irreversible decisions. For your first set of
> features - in your first one-w

iteration - you supply just enough code to
> deliver those features.

I never managed to have a one w

iteration if not for really small
projects, but anyway I am GTD oriented, so I try to get things done, in
a way or another, and I mostly try to plan, not to let things happen
;-)

> This is why above I noted that a feature is not complete unless it has
> "well-designed code supporting the feature". A code with a speculative
> design, with empty stuff that _could_ someday work, when we implement more
> features, is not high quality.

Absolutely right, but you said as well that you would deliver a gui
with a text box instead of a combo, which is maybe dinamically filled
wih only the value that are pertinent depending on the status of the
transaction... so the feature may be there, but not so easy to use and
not so easy to be productive... so?

> They are the requirements base. They still exist (hopefully), and still
> require your software. That is the momentum you s

- not paperwork.

See the other post, related to Product Management, some times you don't
have users, you have to find them ;-)

> Paperwork is the assumption we don't have a user base, so we must write down
> what they would need, if we had them. That's the admission of defeat.

And what about a new product? You mean "potential users" than ok, but
how can you have a "potential users" base helping you with
requirements?

>
> IN ACCEPTANCE TESTS

The acceptance tests are not requirements, but how you would test them,
which is not the same thing, they are dual in some whay... but why I
should get the risk that a developer is extracting a requirement from
an acceptance test, than a feature description from a test suite, if in
order to write the socond ones I need anyway the first ones?

>
> Because you don't write them until you are ready to code them. Hence you
> have researched the situation - just enough - with your onsite customer's
> help, to start specifying and coding them.

I agree on the fact that requirement are validated with code and tests,
and should be reviewed and modified at each iteration, are a part of
the product. But your is not really an answer, sounds more like a
recursive statement Requirement->Test->Requirement what is first?

> What specific problems with requirements have you endured in the past?

That without a disciplined management of the Requirement, specially in
product developement, you start to leave them back, and evolve the
product on a "patch" base, getting CR and BUGS, and the product will a
bit loose the track, and most of all the vision that was expressed in
all those requirements, that may be were not all implementable when you
started, but than in the future could be...

More over, with incremental development, if you don't extensively
refactor, you incur in serious architectural problems and the whole
product risk to explode for performance, scalability or whatever
reason. The refactoring is anuway not always justified (economically
speaking) and some times you should be able to decide to drop some
feature requests because are out of scope, or because have a very
limited scope, but if the customer is paying for it, you do it anyway,
and you can't refactor a car to became an airplane because a customer
asked for the wings and is paying for it! Did I made the point?

> No need to fight that; just win.

Funny goys around here... indeed :-)

> Then don't cut contracts like that. Cut a start-up period of, like 6
> iterations, and then use pay-as-you go. And run the first 6 iterations
> exactly like the rest, so the client knows how the system will work. They
> should be delighted to get better control over the system.

The contract has nothing to do with the method you manage the project,
and with the control the customer has on it.

>
> That's "big requirements up front", which I busted on. It adds risk. Adding
> risk terms to the contract is not the same as fixing the risk!

No it is not, it is just to write down, the whole project goals and
deliverable, than brake down the goals into more specifc things on an
iteration base, after aving defined priorities, than manage those
requirements, if after some iteration the customer is coming out that
he wants to change something defined in a different way, you can show
him what it will cost in terms of artifacts to be changed, reviewed and
tested, and he will understand and have the control and decide if doing
it or not.

There are always 3 variable: Budget (man power|money|tomatos), Time
(elapsed|deadline), Requirements (from which derive Features), you can
fix 2 of them and you have the third ;-)

Thanks to everybody, I think is getting interesting
Ciao
ANdreaT

--
Andrea Tomasini - <me@andreat.de>
http://processinpractice.andreat.de
http://www.andreat.de

tumma72

2006-08-25, 8:00 am

bill turner wrote:
> And, you seem to be only talking about functional requirements. I
> don't know how you would use a test case to document many of the
> non-functional requirements, such as look and feel, usability,
> performance (well, this might be easy to document with a test case),
> operational (e.g. environment factors like extreme heat or cold, loud
> noises, etc.), product distribution requirements, migration,
> maintainability/supporability/adpatability, data integrity, privacy,
> political, and compliance. Yes, many of these could be captured in
> tests, but just as many would be difficult, if not impossible to
> capture. Without a knowledgeable RE, it is hard to imagine a coder (or
> pair) working in conjunction with an on-site user that will elicit all
> these requirements and keep them in the forefront so as not to be
> violated by later development.

I agree, beside in every complex project there are a lot of Requirement
which are not automatically testable, and this applyes pretty often to
Social, Environmental and Political requirements.

> Because of the manner in which requirements are elicited in Agile
> development, it does not encourage or even really allow for one to
> search beyond the edges, to see a bigger picture. This would seem to
> decrease the likelihood that one would produce a product that is a
> great leap forward.

I think it is more that with the impetous to "get things done..." there
is the real risk that you forget to abstract a bit from the user
perspective and see things in a more generic environment, which is what
should happen in product development, you never have only "one"
customer and not all the need are compatible to each other, thing that
is pretty hard to find out if you don't analyze requirement all
together ;-)

Ciao
ANdreaT

--
Andrea Tomasini - <m...@andreat.de>
http://processinpractice.andreat.de
http://www.andreat.de

Scott Frye

2006-08-25, 8:00 am

Phlip wrote:

> "Louis Pasteur's theory of germs is ridiculous fiction". --Pierre Pachet,
> Professor of Physiology at Toulouse, 1872
>
> Now focus on the terrible meaning behind that silly pronouncement. ~20 years
> after Pasteur's studies, a surgeon at a teaching hospital is _still_ not
> washing his hands, or sterilizing his instruments, before he operates on
> people. And neither are his students.

This argument is an example of the logical fallacy "Hasty
Generalization".

>
> (snip) Sometimes, in technology, there actually is
> One True Way.

Not in my experience. I recommend you read "No Silver Bullet"
http://www.virtualschool.edu/mon/So...lverBullet.html

> Acceptance tests are not unit tests.

You are quite correct. My mistake. However, correcting the error, my
point still stands.
Requirements are NOT acceptance tests.

I feel that a good way to attack a software problem is:

1. Gather requirements.
2. Analyze the requirements for interactions/contradictions/refinements
unspoken requirements (i.e. non-funcitonal) All this is done with the
customer.
3. Design several architectures that will meet the requirements and
select the most appropriate.
4. Develop a prototype to test concepts and solidify understanding with
the customer (sometimes necessary, sometimes not).
5. Create tests (unit and otherwise) based on refined requirments and
architecture. (may result in changes to the requirements).
6. Develop code based on tests and design.
7. Create any non-unit tests.

Steps 5,6,7 are done in iterations an may uncover misunderstandings and
changes in 1,2,3,4. Additionally 5,6,7 can be done in parallel.
Sometime the test are written 1st, sometimes last, sometimes
concurrently. Unless there's a huge misunderstanding in about the
entire system, then test creation and code development should only
uncover slight changes to the design and architecture instead of full
rewrites.

>
>
> I don't have that problem.

This is a bit ambigous. I can't tell if you agree or disagree.

> Of course you can't. That's no excuse not to write every other kind of test
> you can think of, and to go to them first for documentation and such.
>

Sometimes these things are easier to understand when written as prose
than when written as a test.

> Once you acheive the non-functional requirement, many tests on functional
> requirements tend to pin it down. The odds of it changing go down.

This may be true, but as indicated earlier, it may be more consice to
represent them in non-test format so they can be discussed and agreed
upon. In fact this discussion should take place BEFORE the tests are
written.

>
> That's why there are other practices, such as hiring programmers with more
> than two brain-cells to rub together.

On small projects this will work. But on larger projects these two
functions need to be seperated because it is more than one person can
handle.

>
> Yawn. That's the Onsite Customer's role. That's why it's a fulltime role.

This doesn't address the problem. It just shifts the responsibility to
the customer. I don't believe that most customers have (or should
have) the skills to do this.

-Scott Frye
-------------------------------------------------
"The person who says it cannot be done should not interrupt the person
doing it."
Chinese Proverb.
-------------------------------------------------

Phlip

2006-08-25, 7:00 pm

tumma72 wrote:

> Product Management is more a marketing discipline rather than a
> development practice, but it affects extremely the way the product is
> developed, expecially in fully product driven companies.

Then developers should use a process that is as responsive as possible to
the Product Managers' whims. Then they can easily steer the product towards
its goals.

I recently met with a product manager who said that his team, for one
project, was delivering a new version, with just one new feature or tweak in
it, every few days.

Oh, guess which recipe they were using.

> Think that you have a good idea and you want to create a new product
> for the market... or a new technology, you don't have any "user" out
> there, and you have to find out as fast as possible, without investing
> too much money if the idea you have is worth of making a product.

So don't stack up all the requirements you possibly can - they will only
burden and slow down programmers getting to that first release.

> You develop a kind of "Proof-of-Concept" which is for me a prototype to
> check whether the idea you have had was good and some people are
> willing to use it (ok, you make market analysis, you try to identify a
> market where to place your product...) than assume you decide to make
> a product.

However, like any other version of a product, your prototype should not be
quick-n-dirty, or disposable. It should have:

- clean code
- complete (minimal) features
- high value features
- wall-to-wall tests
- a prototype build pipeline

Now if your customer asks for one more feature, what ever it is, you are
ready to add that and refactor. You don't need to say, "Thanks for liking
it, but we have to re-write it, and productize it, before we can get you
that next feature!"

No sophomore album jinx!

> As far as my experience tought me, what happens is that at first you
> know what to build because you are evolving and refining the original
> idea, that was to make "your something" and to please a certain number
> of potential users, than the users will start to ask you to change
> things. Never the less the point is that if you want to be different,
> and to make your product special, you should be able to anticipate some
> how the needs on the market, otherwise if the rule would be:
> "...the largest customer base you have, the more detailed and
> interesting feedback you have, the better product you can build..."
> than only big companies will exist, company who can also pay to have
> users, and company who have enough resources to buy what they need to
> succeed. But thank good is not like this, there are also some recent
> examples (think at skype) they had a good idea, they started to promote
> it for free, and than they found an interesting business model that
> somebody else was liking... ;-)

Why, that's almost like saying marketing and Product Management can itself
be emergent!

> The point I wanted to stress is, a product lifecycle, from the
> development point of view is unpredictable and subject to a lot of
> market rules, but never the less has always a "strategic" driver, that
> is what makes the difference between two solution to the same problem

So development's goal, at each iteration, is to leave marketing's options as
wide open as possible. And the decision to release any build should be
entirely a business-side decision. No, "Oh, but tell them they can't click
on that button there..."

> (problem: WordProcessing, solutions: MS Word, OpenOffice, KWrite,
> Abiword...) and what make some customer choose for you instead of the
> competitor. These differences are mostly coming out of the vision of
> people who are developing the product. After 3 to 5 year the product
> may be really a big thing, and without having a disciplined way of
> managing requirements - from the beginning - I don't think frankly that
> you could survive so long. The developers in a product development
> context are some time forced to "prepare" functionalities for future
> releases, it is not so straightforward that you have a w

ly iteration
> and you put inside everything that is needed... and done!?

Programs with wide appeal (and shallow profit models) would tend to sustain
by the pull of their established customer base. Even lowly copycats like
Abiword have one.

This pull adds to the internal push from any internal requirements
technique.

A program with narrow appeal (and deep profit models), like air-traffic
controlling, has users that need you to take on a greater burden of
requirements management, because your users manual is part of their
knowledge base standard operating procedures. So this situation requires
many full-time customer liaisons.

>
> Yes, what I meant was, how can I be agile related to Requirements?

By putting as many of them as possible, as close as possible to the code. So
a newbie, even told, "Go add a bug!", will have no choice but learn them.

Another good technique here - from /Domain Driven Development/ by Eric
Evans - is "Ubiquitous Language". A software project should put its
product-specific jargon everywhere. It should link source code to unit tests
to acceptance tests to the users manual to the documents of finished
requirements.

Team members - even non-technical ones - should learn to discuss the project
with other team members using these terms. All projects do this - develop an
in-house jargon. Product managers should leverage the technique, so its
unified and ubiquitous, and easier to learn.

>
> And don't you think that if you would be able to keep "agile" in sync
> the all traceability chain from Requirement through code, once you have
> an issue related to some topics, you would be able to limit the scope
> to a very specific set of Requirements->Features->Code->Tests to be
> checked and thus avoind to fish into a blakbox?

Yup. That is "requirements tracing", and you get it for free with even the
sloppiest program that practices storytest-first and test-first.

You should be able to put assert(false) into any block of any function, and
get a list of failing acceptance tests. These are the requirements which
constrain that line of code.

I don't believe that a formal requirements tracing system could possibly
have that high level of coverage, with that high level of trust in the
results. STDD and TDD give it to you for free, as a side-effect of rapid
development.

>
> It is true that you don't need to ship it to the customer, even if up
> to now I always had to write down requests from the customer (user
> story) transform it into SMART requirements, go back to the customer
> with them and agree that I had a good understanding of the problem,
> write acceptance tests and go back to agree that the customer would be
> happy and satisfied if all the defined tests, matching the defined
> requirement will be executed correctly, and all this "baselined" to
> specific product releases. So the customer is getting a part of it,
> even if not as a product.

Right, but the customer liaison should not specify these requirements too
far in advance. That adds back lots of risk that the other techniques had
reduced.

Note that you only go to this liaison with questions about features in
_this_ iteration. Not the features you plan to get around to a year from
now.

> Be aware that this doesn't mean to have Huge Front Up requirements,
> because at every iteration there may be some new, and some changes to
> old one, the only difference is that you can show the customer, against
> a issue, that he agreed something else before and if he wants to change
> that thing now, it will mean to change other things... and is going to
> take time... and money possibly :-)

It seems this customer liaison has the full-time job of operating a written
requirements backlog.

>
> This is a good technique, is what I call Requirement Workshops, is not
> always applicable (you need a certain number of domain experts
> available) but it is indeed a very good way to collect and identify
> requirement, for sure less expencive than interviews ;-)
>
>
> I already read a lot of books, and I have been a product manager as
> well, now I am working as a consultant and I am trying to support
> client in optimizing and improving the End-to-End software development
> process. If you have some books in particular, you think can help me in
> finding out applicable agile requirement solution for product
> development, please tell me!

/FIT for Software Development/ by Ward and friends?

--
Phlip
[url]http://c2.com/cgi/wiki?Z

Land[/url] <-- NOT a blog!!!

Phlip

2006-08-25, 7:00 pm

tumma72 wrote:

> I agree, beside in every complex project there are a lot of Requirement
> which are not automatically testable, and this applyes pretty often to
> Social, Environmental and Political requirements.

But most of them are testable.

The primary goal of storytests is not documentation - that's a nice
side-effect. The primary goal is to keep the important things resistant to
unwanted change.

If a change fails a non-functional requirement, the failure itself should
suggest a test. If the program gets slow, you add a test case that times it.

> I think it is more that with the impetous to "get things done..." there
> is the real risk that you forget to abstract a bit from the user
> perspective and see things in a more generic environment, which is what
> should happen in product development, you never have only "one"
> customer and not all the need are compatible to each other, thing that
> is pretty hard to find out if you don't analyze requirement all
> together ;-)

Some early XP literature tried to say there should be only one Onsite
Customer. That means a developer need only go to one person to get a
responsible answer to a question on specifications.

The modern "Customer Team" concept puts all of marketing and QA on the
Customer side. Then that team must determine how the "customer speaks with
one voice". That means a developer will know how to get a responsible
answer. Maybe certain aspects of the program get certain domain experts, or
the team uses an on-call system.

--
Phlip
[url]http://c2.com/cgi/wiki?Z

Land[/url] <-- NOT a blog!!!

bill turner

2006-09-08, 7:01 pm

On Fri, 25 Aug 2006 15:39:44 GMT, "Phlip" <phlipcpp@yahoo.com> wrote:

>tumma72 wrote:
>
>
>But most of them are testable.
>
>The primary goal of storytests is not documentation - that's a nice
>side-effect. The primary goal is to keep the important things resistant to
>unwanted change.

You have stated several times that acceptance tests document the
requirements. What am I misunderstanding?

>
>If a change fails a non-functional requirement, the failure itself should
>suggest a test. If the program gets slow, you add a test case that times it.

And here is the fallacy that tests are requirements. A performance
requirement, for example, is much more than "Shall process 1M records
in 10 minutes." It includes things like the rationale for the
requirement, what it means to the customer if this requirement is not
met, what it means to the customer if it is exceeded (not always a
good!), supporting documentation that provide further explanation for
the requirement, and a history of changes/deletions to the
requirement. I am probably leaving out many other things that a test
does not capture. Failure to record this information makes it
difficult to perform design trade-offs. Of course, with XP, you have a
customer sitting next to you that will help determine the solution
space. Though, little help that is for someone that must modify the
system a year later, or even during the project because of a
refactoring prompted by new info from the on-site customer. And,
worst, this presumes that the customer has enough knowledge of what
makes a rigorous requirement to think of all these things.

As I have said before, I think there is much to be admired about Agile
methods. I just feel it important that anyone that embarks on that
path be aware of what is being given up. And, we have only talked
about what is lost at the requirements level.

>
>
>Some early XP literature tried to say there should be only one Onsite
>Customer. That means a developer need only go to one person to get a
>responsible answer to a question on specifications.
>
>The modern "Customer Team" concept puts all of marketing and QA on the
>Customer side. Then that team must determine how the "customer speaks with
>one voice". That means a developer will know how to get a responsible
>answer. Maybe certain aspects of the program get certain domain experts, or
>the team uses an on-call system.

If you are getting answers from more than one person, then you need to
perform some sort of conflict resolution. That is analysis. Even if
there is only one person representing the business units, if the
project is cross-functional, and especially cross-departmental, it is
unlikely that the one person will be the best resource for all
requirements, nor the best resource for prioritization. I can easily
see an on-site customer gold bricking his/her pet concerns, which,
inevitably leads to other areas being shortchanged, un- or under-
developed, or project expenses being greater than necessary.

------------------------------------------
Bill Turner

A faith that the free play of market forces will eventually end in Good is, in fact, more 'absurd' than religious belief, for there, at least, there is a presumption of an intelligent Agent Who writes straight with His crooked lines. - William Pfaff

Views expressed are entirely my own and only coincidentally represent those of other persons or entities.

bill turner

2006-09-08, 7:01 pm

On Fri, 25 Aug 2006 04:55:03 GMT, "Phlip" <phlipcpp@yahoo.com> wrote:

>bill turner wrote:
<snip>
>
>
>I can't think of a risk that can slip thru all this discipline. Could you
>name a specific one?

Choose any technological risk, for example: new hardware, new
software, new communication protocols.

Then there are the risks that the on-site customer is not really
skilled enough to flesh out the requirements or understands them
poorly. This risk is doubled if the RE knowledge of the development
team is equally limited, especially if they have no real knowledge of
the business at hand.

These are but a couple areas.

------------------------------------------
Bill Turner

A faith that the free play of market forces will eventually end in Good is, in fact, more 'absurd' than religious belief, for there, at least, there is a presumption of an intelligent Agent Who writes straight with His crooked lines. - William Pfaff

Views expressed are entirely my own and only coincidentally represent those of other persons or entities.

bill turner

2006-09-08, 7:01 pm

On Fri, 25 Aug 2006 04:55:03 GMT, "Phlip" <phlipcpp@yahoo.com> wrote:

>bill turner wrote:
<snip>
>
>
>Besides, uh, sorting features in order of business priority? And only fully
>specifying the highest value ones?
>
How do either of this activities promote searching beyond the borders?

To get beyond the edges, you need to know where those edges are and
how external actors interact with the proposed system. Use Case
diagrams, Context diagrams, and, what I feel are the best for this
task, Problem Frame diagrams, all help to see these edges clearly and
promote discussion. Without such discussions, it is hard to see how a
paradigm shift can occur, how break-through applications can be
devised.

To be fair, for the vast majority of projects, it is probably
unnecessary to have such leaps.
------------------------------------------
Bill Turner

A faith that the free play of market forces will eventually end in Good is, in fact, more 'absurd' than religious belief, for there, at least, there is a presumption of an intelligent Agent Who writes straight with His crooked lines. - William Pfaff

Views expressed are entirely my own and only coincidentally represent those of other persons or entities.

Phlip

2006-09-08, 7:01 pm

bill turner wrote:

> If you are getting answers from more than one person, then you need to
> perform some sort of conflict resolution. That is analysis. Even if
> there is only one person representing the business units, if the
> project is cross-functional, and especially cross-departmental, it is
> unlikely that the one person will be the best resource for all
> requirements, nor the best resource for prioritization. I can easily
> see an on-site customer gold bricking his/her pet concerns, which,
> inevitably leads to other areas being shortchanged, un- or under-
> developed, or project expenses being greater than necessary.

The Onsite Customer has the incentive to deliver value early and often. Once
they see a team's velocity numbers, and start using them to steer, they
typically start fiercely defending the story points, and only putting in the
highest value features. If these only benefit one user population, the
others populations have an opportunity to notice that problem, once per
w

.

And beyond the Early Deployment guideline, the remaining issues are Not an
XP Problem. No known methodology will magically defend its features from a
Goal Donor who wants to gold-brick.

>
> You have stated several times that acceptance tests document the
> requirements. What am I misunderstanding?

The term "primary goal"?

Documentation is the immediate secondary goal.

Example: If a test fails and can't be made to pass, because it's too
ambitious, snip it. Don't leave it in the test rig, as a "might run someday"
test. The storytest's most important aspect is it tests live features. If
you want to document what the program might someday do, use a Wiki or
something. The secondary goal is subservient to the primary goal.

I thought you worked a Agile-style project. Did it have storytests?

>
> And here is the fallacy that tests are requirements. A performance
> requirement, for example, is much more than "Shall process 1M records
> in 10 minutes." It includes things like the rationale for the
> requirement, what it means to the customer if this requirement is not
> met, what it means to the customer if it is exceeded (not always a
> good!), supporting documentation that provide further explanation for
> the requirement,

This is why the tests may have comments.

> and a history of changes/deletions to the
> requirement.

Your version controller should trivially contain that. But accessing it
might indeed be hard!

> I am probably leaving out many other things that a test
> does not capture.

You need to Google ["Michael Bolton" "acceptance test"] if you want to see
him rant about all sorts of things they don't capture.

> Failure to record this information makes it
> difficult to perform design trade-offs.

This is Fallacy of the Excluded Middle. You incorrectly claim we don't
document the untestable requirements, then you extrapolate on the
consequences.

All we are saying is that the best requirement is a suite of commented,
passing, executable tests. Any other kind of requirement is suspicious. That
suspicion may indeed sustain the requirement. But how does Brand X handle
this situation? By declaring the best kind of requirement to be something
other than a suite of high-quality tests??

> Of course, with XP, you have a
> customer sitting next to you that will help determine the solution
> space. Though, little help that is for someone that must modify the
> system a year later,

An advisory XP practice is "team continuity". If you want the same product,
you keep the same team members available.

> or even during the project because of a
> refactoring prompted by new info from the on-site customer.

Please read all of the following before commenting on any of it (if at all)!

The great thing about user stories is you split them early and often,
typically into a low and high priority aspect. For example, last night at
the XP San Diego Users Group, we ran one of Peter Merel's Extreme Hours.
That means we practice the XP cycle by drawing a whimsical product on a
whiteboard. Our product was a Robotic Pet.

> And,
> worst, this presumes that the customer has enough knowledge of what
> makes a rigorous requirement to think of all these things.

During our first iteration, our Customer Team (two guys writing whimsical
requirements on index cards) did not think to request a pet that was Cute,
Fuzzy, Warm, Responsive, or anything that would make you want to pet it.

At the end of our (20 minute) iteration, our team had drawn a metal chassis
with 4 tractor wheels on the bottom, and a camera sticking out the top on a
stalk. Oh, and a grappler. You would run screaming if you weren't
introduced.

So to start the second iteration, the customers added two more cards (among
others). They added "cute", and they added "obscure the camera". The QA team
wrote tests on the back of each card, "A 6yo girl must choose it over a
beanie baby that the customer team picks". The other test was, "we can't see
the camera".

The other cards had estimates between 1 and 9 points, so we gave the "cute"
one 20. Our design was indeed very far from that requirement! A lot of
refactoring would have been required!!

I gave the "obscure the camera" card one point. Then I drew a rabbit's head
on top of the camera, fitting over it like a puppet, making it the Cute
part.

As an extra feature, we declared the product would be more Cute than a
beanie baby WE picked - an evil monstrous snarling one.

> As I have said before, I think there is much to be admired about Agile
> methods. I just feel it important that anyone that embarks on that
> path be aware of what is being given up. And, we have only talked
> about what is lost at the requirements level.

Nothing is lost; it's all about requirements. Because our customer team
screwed up (and because we didn't select the best domain experts available
for that role!), we returned evidence to them, within the first iteration.
Because they worked to tests, they didn't demand a Cute feature, and forced
themselves to be disappointed at the end of the iteration. We managed
expectations.

Cute is a non-functional requirement. And (guess what!) our first iteration
didn't hear it, so we completely failed it. So in the second iteration, we
had the opportunity to work towards Cute, and to split the Cute feature into
two cards. One was still non-functional and hard, but the other had a
functional aspect; obscuring the ugly camera on its stalk.

The act of splitting cards itself is where a lot of analysis happens. You
analyze requirements to produce testable specifications, so you get a lot of
little tests, each documenting one testable aspect of a requirement.

So in your question, our puny tests are blind Indian sages, and the
non-functional undocument requirement is the elephant they grope. Each
indeed grabs a different part, the snakelike part, or the treelike part. Our
strategy, over time, is to place enough sages around the elephant they
completely define its shape.

--
Phlip
[url]http://www.greencheese.us/Z

Land[/url] <-- NOT a blog!!!

Phlip

2006-09-08, 7:01 pm

bill turner wrote:

> Choose any technological risk, for example: new hardware, new
> software, new communication protocols.

Could you sketch a scenario? A team doing XP does blah-blah-blah, then they
ignore these looming risks, then they strike, then the team gets in trouble.
Etc.

> Then there are the risks that the on-site customer is not really
> skilled enough to flesh out the requirements or understands them
> poorly. This risk is doubled if the RE knowledge of the development
> team is equally limited, especially if they have no real knowledge of
> the business at hand.

What methodology fixes that??

--
Phlip
[url]http://www.greencheese.us/Z

Land[/url] <-- NOT a blog!!!

Phlip

2006-09-08, 7:01 pm

bill turner wrote:

> How do either of this activities promote searching beyond the borders?

By forcing you to check against competing features which is highest
priority; hence you must "analyze" and whatever enough to know the others
are low.

By forcing you to sketch a test for your feature before committing it to
code, so you must "analyze" enough of the situation for the team to agree
the test expresses the feature?

Or are you advocating programmers should leap into designing, documenting,
and coding low-priority features which nobody has thought of a test for?

> To get beyond the edges, you need to know where those edges are and
> how external actors interact with the proposed system. Use Case
> diagrams, Context diagrams, and, what I feel are the best for this
> task, Problem Frame diagrams, all help to see these edges clearly and
> promote discussion. Without such discussions, it is hard to see how a
> paradigm shift can occur, how break-through applications can be
> devised.

Oh, you must have read the appendix to The White Book, where it said all
those techniques are strictly forbidden.

--
Phlip
[url]http://www.greencheese.us/Z

Land[/url] <-- NOT a blog!!!

David Lightstone

2006-09-09, 7:59 am

"Phlip" <phlipcpp@yahoo.com> wrote in message
news:h7gMg.7689$tU.2177@newssvr21.news.prodigy.com...
> bill turner wrote:
>
>
> Could you sketch a scenario? A team doing XP does blah-blah-blah, then
> they ignore these looming risks, then they strike, then the team gets in
> trouble. Etc.
>

Sometimes it is far more effective to deal with things in the abstract. When
you get down to the specifics it is just so easy to treat things as an
anomaly that can be ignored.

Risks exist, back in the good old days, when Fortran was called 2. When
Computer Science departments were far and few between, the ethos of those
who developed computer programs was based upon the ethos of the department
of the university to which those who taught computer programming

When the Department was Physics or Engineering, experiments were probably
performed more frequently. When the department was Mathematics or
Philosophy something which I would now call a code review (theoretical
analysis) probably was more prevalent.

For those not familiar with the early days of NASA and risk is software
development, when the new technology of computers was first used (when
systematic testing was semi-unknown. ) in Rocket guidance there were a
number of rather dramatic failures. One of which relates to a limitation
shared by human beings- we all make clarical errors . THis one was inserting
a period (".") where a comma (",") belonged in a Fortran statement

Somethig like

DO 10 I=1,20
became
DO 10 I=1.20

No small change. An iteration loop quickly became an assignment statement.
For some reason the testing just wasn't adequate (no doubt do to the
programmer being trained in the wrong ethos.) Self destruct was ordered
rather quickly during the brief flight.

Whethter you wish to consider "XP" a methodology or an ideology, it is a
risk. Take any XP failure as your example. The one you choose is the example
you s

. I trust you are sufficiently self aware to know of such an example
for your own personal consideration. I doubt if you will ever be prepared to
sincerely discuss examples of attempts to use XP that have failed. You ask
for one only for purposes of being able to discard it as an exception or to
declare it a misapplication of XP. Asking for it is basically disengenuous
rhetorical gambit

If you can't understand risk managment, you really have no business
attempting to advocate software development methodolgies. You are advocating
use of a software development methodology, right?

>
> What methodology fixes that??
>
> --
> Phlip
> [url]http://www.greencheese.us/Z

Land[/url] <-- NOT a blog!!!
>

Sponsored Links