Re: [ba-ohs-talk] Facilitated Evolution: Agile software development
But wait....there's more.
http://www.martinfowler.com/articles/newMethodology.html
Martin Fowler again. He's the same fellow that brought you continuous
integration, a previous post of mine. (01)
"...in fact the source code is a design document and that the construction
phase is actually the use of the compiler and linker. Indeed anything that
you can treat as construction can and should be automated.
This thinking leads to some important conclusions:
· In software: construction is so cheap as to be free
· In software all the effort is design, and thus requires creative
and talented people
· Creative processes are not easily planned, and so predictability
may well be an impossible target.
· We should be very wary of the traditional engineering metaphor for
building software. It's a different kind of activity and requires a
different process " (02)
At 12:53 PM 12/11/2001 -0800, you wrote:
>Very much reminds me of constructivist learning methodology...
>http://www.sdmagazine.com/documents/s=844/sdm0108a/0108a.htm
>
>Prominent in this writing is Martin Fowler, who has written extensively on
>using UML. It strikes me that this is represents a mechanism for
>"facilitated evolution".
>
>""We are uncovering better ways of developing software by doing it and
>helping others do it. We value:
>· Individuals and interactions over processes and tools.
>· Working software over comprehensive documentation.
>· Customer collaboration over contract negotiation.
>· Responding to change over following a plan."
>This statement has a number of fascinating aspects, not the least of which
>was getting 17 people to agree to it. First, the word uncovering. While
>this was a group of experienced and recognized software development
>"gurus," the word uncovering was selected to assure (or frighten) the
>audience that the Alliance members don't have all the answers and don't
>subscribe to the silver-bullet theory.
>Second, the phrase by doing it indicates that the members actually
>practice these methods in their own work. Ken Schwaber (a proponent of
>SCRUM) told of his days of selling tools to automate comprehensive,
>"heavy" methodologies. Impressed by the responsiveness of Ken's company,
>Jeff Sutherland (SCRUM) asked him which of these heavy methodologies he
>used internally for development. "I still remember the look on Jeff's
>face," Ken remarked, "when I told him, 'None—if we used any of them, we'd
>be out of business!'"
>Third, this group is about helping, not telling. The Alliance members want
>to help others with agile methods, and to further our own knowledge by
>learning from those we try to help.
>The value statements have a form: In each bullet point, the first segment
>indicates a preference, while the latter segment describes an item that,
>though important, is of lesser priority. This distinction lies at the
>heart of agility, but simply asking people to list what's valuable doesn't
>flesh out essential differences. Roy Singham, Martin's boss at
>ThoughtWorks, put it well when he said that it's the edge cases, the hard
>choices, that interest him. "Yes, we value planning, comprehensive
>documentation, processes and tools. That's easy to say. The hard thing is
>to ask 'what do you value more?'" (03)