3 ms·
No, no, no. What you're describing is Barry Boehm's Spiral Model from the early 1980s. If you look at a single Agile sprint you should not see a miniature water
by zb 16y ago
No, no, no. What you're describing is Barry Boehm's Spiral Model from the early 1980s. If you look at a single Agile sprint you should not see a miniature waterfall. In Agile, activities like requirements, design, coding and testing happen at the same time. This is the essence of Agile, and what separates it from the Spiral that came before.
- kenjackson 16y agoHow is it possible that you get requirements and code at the same time? Like I literally start writing code, while at the same time have a meeting with the customer to figure out if they want an accounting system or a CMS?
- zb 16y agoBecause the customer has no freaking idea what the requirements are at the start of the project. That's always been the failure of Waterfall. You've never been writing code and suddenly thought of something that needed to be added to (or removed from) the system? Seriously?
- kenjackson 16y agoI'm not sure how what you said is incompatible with waterfall/spiral. You can certainly add/remove/change requirements, but you don't start coding until you have at least a first pass on some subset of requirements.
- Ramone 16y agoWaterfall doesn't have multiple passes. You have to have all your requirements before you move on to design. And that has to be complete before you move on to implementation. That's why they use the waterfall metaphor, because waterfalls don't flow back up. And if waterfall seems completely braindead now, keep in mind that the old software guys used to be hardware guys, and it makes much more sense for hardware. You're right about Spiral though... Spiral is iterative, so its much more compatible.
- newt 16y agoWaterfall doesn't have multiple passes the only way that it can not have multiple passes is if the program is thrown away after V1.0. Any successfully program will be maintained and extended.
- newt 16y agoBecause the customer has no freaking idea what the requirements are at the start of the project. I disagree. to get a scrum project (or any project) going, you do need to have a vague idea of what you want (e.g. I want a website to sell my widgets online) and a few features for the next iteration (.e.g. List all the widgets. Take an order by email). Scrum just says that you can inspect, adapt and iterate over that process.
- newt 16y agoThey happen in parallel. You can be working on feature B while someone else is drafting a spec for feature C, and feature A is with the tester already. meanwhile the wishlist (features F, G, to ZomgPonies) is going onto the backlog in vague outline form for use in future iterations. meeting with the customer to figure out if they want an accounting system or a CMS That's an exaggeration. You seen some vision of what broad need the software fills before you start, and an initial backlog of high-priority features to get you going.