Software Developers/Engineers/Managers - Quick Question
Jul 30th 2011 | 6:46 am
#16
Forum Regular
Joined: Sep 2010
Posts: 250
Re: Software Developers/Engineers/Managers - Quick Question
Waterfall is horrible, tedious long requirements, design docs, implementation docs. Who would read 100 pages long doc! After many months meetings, everybody got tired and finally each manager signed off the docs, then developers didn't have enough time to complete the implementation, but the business wanted to change the requirements. Meetings started all over again. I saw many projects failed or the final production was miles away from what the business really wanted. Finally the boss decided to make all project managers redundant, got rid of 50% developers and manual testers, recruited agile developers and automation testers, brought in Thoughtworks guys and went for Scrum.
Scrum works well when the tools are up to support it. In London, my team used Jira, Wiki, svn, TracTimeline, Hudson and other tools integrated system. Everything was connected automatically. It was so easy to track down the issue and find the history and conversations.
Here we use Scrum as well, but word docs fly everywhere! Everything is connected by a ticket ID.
Scrum works well when the tools are up to support it. In London, my team used Jira, Wiki, svn, TracTimeline, Hudson and other tools integrated system. Everything was connected automatically. It was so easy to track down the issue and find the history and conversations.
Here we use Scrum as well, but word docs fly everywhere! Everything is connected by a ticket ID.
Jul 31st 2011 | 12:20 pm
#17
Assimilated Pauper
Joined: Mar 2005
Posts: 40,070
From: Ontario
Re: Software Developers/Engineers/Managers - Quick Question
In at nutshell, Agile development is a software development project methodology, and Scrum is one version of that.
Essentially you do away with a big up front analysis and design phase. You list the requirements, and tackle the project in chunks of a set duration (usually between 2 to 4 weeks), taking a number of these requirements at a time. These chunks are called 'sprints', and the idea is that after every sprint, or set number of sprints you have a something to release that is production ready, rather than waiting until every single requirement is done. I won't go into the benefits as I'm trying to keep this post short (go Google).
That's a very basic description and there's much more to it than that, but implemented properly it works very well indeed, and (I say again - *if* implemented properly) much more natural to a software developer, although I do admit that not all agree.
On the flip side I've seen some very messed up attempts at implementing it. Not only does everyone involved in the project have to be on board with it (developers, testers, project managers, the business representatives, management <anyone else involved>), they also all have to understand it.
These projects usually fail because one or more parties doesn't buy into it and works against it, or because one or more parties doesn't get it and has the wrong expectations.
It's worth noting that not all projects are suited to Agile, and for some projects the good old fashioned waterfall approach is best.
And I was trying to keep this post short too.
Cheers
Chris
Essentially you do away with a big up front analysis and design phase. You list the requirements, and tackle the project in chunks of a set duration (usually between 2 to 4 weeks), taking a number of these requirements at a time. These chunks are called 'sprints', and the idea is that after every sprint, or set number of sprints you have a something to release that is production ready, rather than waiting until every single requirement is done. I won't go into the benefits as I'm trying to keep this post short (go Google).
That's a very basic description and there's much more to it than that, but implemented properly it works very well indeed, and (I say again - *if* implemented properly) much more natural to a software developer, although I do admit that not all agree.
On the flip side I've seen some very messed up attempts at implementing it. Not only does everyone involved in the project have to be on board with it (developers, testers, project managers, the business representatives, management <anyone else involved>), they also all have to understand it.
These projects usually fail because one or more parties doesn't buy into it and works against it, or because one or more parties doesn't get it and has the wrong expectations.
It's worth noting that not all projects are suited to Agile, and for some projects the good old fashioned waterfall approach is best.
And I was trying to keep this post short too.
Cheers
Chris
Without Agile all is the same but in English.
