|
| [ Reposted from news:microsoft.public.msf ]
Newsgroupies:
The alleged "Agile Alliance" was a meeting in which some select members of
the so-called "Agility Movement" were invited to find where their ideas on
software engineering methodology overlapped. (Some leading agile coaches
weren't invited - that's another story...)
The group agreed on a few motherhood-and-apple pie things like:
* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan
The participants generally espouse coding in very tiny increments, mixed
with testing, designing, delivering, etc. Each Agile Coach has written a
book or seven about their technique (Extreme Programming, Scrum, etc.). The
elements in common for these processes are:
- the team can take feature requests in any order
- the customer sorts feature requests by business value
- the team implements under test and review,
keeping the bug rate very low
- the team continuously integrates, permitting
each build to remain the highest possible quality,
even while its design
- the customer specifies each feature mechanically,
using a "storytest", typically hosted in an
"acceptance test framework".
- the team minimizes the time between fully specifying
a feature and deploying it to end users
- the best feedback is gains in end user productivity
Now we come to the file MSF_AGILE_CTP_Release_1.ZIP, listed here:
http://msdn.microsoft.com/library/d...ml/vsts-msf.asp
The file unzips into a little Web site (with admirable use of XSL and XML
for its content!).
The page "Overview" naturally repeats the Agile Alliance's Attitudes: "Rely
on People", "Deliver Business Value", "Partner with Customers", "Adapt to
Change".
Inside the lifecycle, however, the customer role is conspicuous by its
absense. No verbiage recommends sorting features by business value -
something _all_ the Agile methodologists recommend. The only verbiage I can
locate regarding iteration planning is "bug triage", as if Agile processes
were generally bug-driven.
The sacred word "refactoring" appears once, in the context "Additional steps
may include refactoring and shelving the code". (Agilistas recommend
"shelved" code be excized from the code base before it turns into risk.)
The verbiage surrounding "unit test" says "Execute unit tests whenever a
change is made to the code base". Those who study TDD tend to run their test
after fewer than 10 edits, not each time they change the "code base", which
generally means checking in their code. (Of course they also run as much of
their suite then, too.)
The most eagerly researched technical end of the "Agile" hooey is something
called "Test-Driven Development", where you write a test that fails, write
poor-quality code that passes, and immediately upgrade the code - oops I
mean "refactor" - to improve its quality. This lifecycle drops that term
once, without explanation. Champions of this process claim you use it to
design, "emergently". They also claim it removes the possibility of most
bugs, however much of this MSF dwells on cleaning up after a bug.
Code review - another bug prevention technique, is reduced to "Spot check
the code". Most "Agile" teams practice pair programming, to review each
change to code.
One of the most notorious features of Agile development is delaying design
decisions until pairs make them, with live code and refactoring. However,
this MSF cannot break away from the traditional "architect" concept,
granting the lifecycle what "agile" methodologists would call a "single
point of failure".
In conclusion, in MS's eagerness to put an "Agile" label on their Spiral and
Chief Programmer Team processes, they have neglected to research (or
experience) the rudiments of the Agile methodologies.
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
|
|