Timeline for Is there a viable alternative to the agile development methodology?
Current License: CC BY-SA 2.5
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 30, 2012 at 23:09 | comment | added | user7519 | Business always changes; a business that is not changing and adapting is a business that is dying. Time is a constant, which doesn't interact with change well. A system that has the philosophy that acknowledge Change is expected can accomodate the change, otherwise, Time has to accomodate change, and it is an unyeilding constant! | |
| Dec 21, 2010 at 1:22 | comment | added | Paul Nathan | Hi Stephan, not all software requirements constantly change. | |
| Nov 12, 2010 at 21:07 | comment | added | Stephen Furlani | @Hounshell, when you use agile, you don't have to release to customers the first iteration. I'll probably go through at least 2-3 iterations on the project I'm working on before it's even stable enough to release. But at each iteration, you can get customer feedback, (as in, 'oh no that's not what we want at all') and fix bugs before they get buried deep into the project. That's far more advantageuous than getting a req doc, working for a year, and only testing it at the very end. What happens if you did something wrong at that point? How expensive is it to fix? | |
| Nov 12, 2010 at 21:04 | comment | added | Stephen Furlani | @Hounshell, the roads however are aren't vastly different. The composition of dirt didn't radically change in the past two years. You don't have to use a new paving material that forces you to change out every one of your paving machines. | |
| Nov 12, 2010 at 21:04 | comment | added | Hounshell | I don't want to seem like an ass or like I'm grandstanding for waterfall myself. Both have a place. When I'm building a web project (which is what I typically do these days), it's my particular flavor of agile all the way. When it was risk analysis for synthetic CDO bond swaps on wall street working with the quants, agile just wasn't even an option. | |
| Nov 12, 2010 at 21:00 | comment | added | Stephen Furlani | @Hounshell, that's absolutely true. Embedded software relies more strongly on not having changes (or errors). I see I neglected that in my response. Embedded software is also usually much smaller in scope (fly-by-wire, or fire control), and the entire project could be completed in a single agile "pass." | |
| Nov 12, 2010 at 20:59 | comment | added | Hounshell | And lastly, you say "With a waterfall method, you would need to retrain your team to handle even minor bug-fixes." That's just so ignorant of how the waterfall process works. You should try out a good waterfall shop before you grandstand about how it's inappropriate for every software development scenario. | |
| Nov 12, 2010 at 20:57 | comment | added | Hounshell | And just to shotgun more holes in your argument, there are road designs being engineered right now that would be appropriate for a road between Kansas and California, but not between New York and Boston. And new techniques for handling asphalt are coming out all the time. | |
| Nov 12, 2010 at 20:55 | comment | added | Hounshell | There are a lot of aspects of software design that are as absolute as the laws of physics. Agile is a tool just like waterfall or other methodologies, and as other people posted there are a lot of business cases where it does not make sense. I would be surprised if I saw you in line to get on an airplane where Boeing said they were in the middle of an agile process on the flight control software and they needed customers to iterate on whether the plane doesn't flip in midair for no reason. | |
| Nov 12, 2010 at 16:45 | history | answered | Stephen Furlani | CC BY-SA 2.5 |