I found out a day or two ago I have to read all these papers and case studies at my job about Agile software development (mostly with SCRUM) and I was wondering what the programming board thinks of the Agile method.I think its not any different then when I was programming on my own just more focus on working programs, less documentation and customer satisfaction. Sounds like a cluster fuck to me.
Here's some info for people who don't know:
http://agilemanifesto.org/
http://en.wikipedia.org/wiki/Agile_software_development
http://en.wikipedia.org/wiki/SCRUM
Checked only the first URL...
> Working software over comprehensive documentation
HOLY FUCKING RAGE GET THE FUCK OUT WITH THAT FUCKING CRAP.
> Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas
DIE
> Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Their highest priority is "early and continuous delivery" ie writing shit code and patching it over and over (and presumably charging you)
fuck it. that's total bullshit. a joke. brainwashing material.
> Their highest priority is "early and continuous delivery" ie writing shit code and patching it over and over (and presumably charging you)
If they want to keep you as a customer and get referral as well, it's really not. You can coast on past success, but only for so long.
Iterative development, regardless how it's dressed up, is the one of the best development practices. Waterfall models don't work except for systems that are small, well-understood and critical -- and even then I'm dubious. The advantage of "early and continuous delivery" is you're producing what the customer needs over a perfect bauble that the customer doesn't. It's the whole Worse is Better argument again.
I also happen to agree with all the points in that manifesto, although calling it a manifesto is overly grandiose.
>Agile software development
It's like all those shitty Web 2.0 sites that display BETA in their logos like it's some kind of badge of pride.
Perpetual Beta = You're doing it wrong!
>>5 the business of programming
>>6
you can make a business out of anything, that doesn't mean it's relevant to it.
>>7 yes it does
So, back on topic...
I have studied Aagile methodologies and tried to apply them in the workplace where the development typically followed the waterfall model [http://en.wikipedia.org/wiki/Waterfall_model]). I have found that many of the Agile concepts only work if you have highly skilled developers that can write self-documenting code.
Following the DRY (Don't Repeat Yourself [http://en.wikipedia.org/wiki/Don't_repeat_yourself]) principle, means programmers should avoid 'double duty' whenever possible. Often documentation is analogous to the code that expresses it ... which often seems like wasted effort. I believe Agile is an extreme form of the DRY principle.
IMO, the waterfall model is better suited to development teams that are not as skilled at software development. Unfortunately in the real world at most development shops, not every programmer has the skills and discipline needed to work effectively in a strict Agile development environment.
JavaMan out!
JavaMan can's spelll...
Fuck Fowler and the rest, man. The good parts of Agile are obvious, and easy to apply. Learning these should take you about 15-30 minutes. The rest of it is pure cockvomiting bullshit, a lame attempt to spin a few decent ideas into another [b][u][i]ENTERPRISE BEST PRACTICES METHODOLOGY[/i][/u][/b] and sell a lot of books.
[b][u][i]ENTERPRISE BEST PRACTICES METHODOLOGY[/i][/u][/b]
Only have experience with RAD here. It was a horrible experience. No one had the full picture what was going on. A clusterfuck trying to integrate the different layers since no one knew how the different parts should communicate with each others. Since there were minimal planning everyone had their own picture how the system would look like resulting in nothing being delivered.
[b]lol[/b]
You need overall plan and at least some design ideas, but when working on code, agile development is in my opinion most efficent. But it is easy to make it go wrong - if you seperate all teams from each other and leave everyone on their own. Cooperation between teams is needed and some good project management as well.