Re: Agile Project Management
On 2/9/2012 9:45 AM, markspace wrote:
On 2/9/2012 3:53 AM, Lionel wrote:
Agile == hacking.
lol.
Actually, I feel the same way. But I also see a lot of folks (including
management and executives) who feel Agile is the best way to go. And
this is in Silicon Valley!
Anyone want to discuss pros and cons of various software development
methods? Or maybe pros and pitfalls of Agile, i.e., how to avoid doing
it wrong.
Also, new thread, or jack this one?
The subject line is fine for a discussion of agile project management,
so I think hijack it.
First of all, I have seen a general pattern to software development
methodologies:
1. Some people come up with an approach to software development.
2. A lot of books get written, and complete, detailed systems combining
many ideas are produced.
3. The detailed systems, applied completely and unintelligently, do not
work well.
4. Some of the ideas, mixed with other ideas and selected to fit the
project and situation, turn out to be extremely useful, and become part
of the essential software project toolbox.
I've seen this pattern repeat several times, starting with "structured
programming" in the 1960's and 70's.
Given that background, I do not buy in to the idea of certification
tests on XP and SCRUM, or an "agile manifesto". I do think some of the
agile programming ideas are very useful in some situations.
As part of my dissertation research I wrote a program that needed to
change frequently in directions that were difficult to anticipate. I
would run some tests, look at the results, think of some new questions,
modify the program to answer the new questions, run some more tests etc.
I used a combination of test driven design, simplicity, and refactoring.
I did not even try to design for future change. Rather, when I had the
new questions and knew what I needed next week I would refactor anything
that made those changes unnecessarily difficult. I could not use pair
programming because it was an individual project. I was my own customer
so I definitely had continuous customer involvement.
I think my approach was much more effective, for that project, than
trying to anticipate what the requirements would be. I would have
guessed wrong in the early stages of writing and using the program, and
wasted time making the design support types of changes that were not needed.
I don't care whether it was "hacking" or not. It worked.
On the other hand, what worked well for a small program undergoing rapid
change and fully understood by the entire (one person) programming team
might not have been so good for a large program, with definite
objectives. For a sufficiently large program, programmers have detailed
knowledge of at most part of the program. Architectural rules, carefully
reviewed design changes, and long range planning become much more important.
Patricia