For Sage Accpac ERP 6.0A development we are adopting the Agile Software Development Methodology. Within the Agile world there are several widely used sub-branches, we are using scrum without going all the way to extreme programming (XP).
For previous versions of Accpac we used the waterfall method of software development has been around a long time, and many successful products have been developed using it. However it does have a number of drawbacks:
1. It relies heavily on all the requirements being defined upfront and then complete accurate specs being developed before coding begins. Practically speaking this has turned out to be humanly impossible. Requirements change as market conditions evolve. No one can review a large spec and ensure that something hasn’t been missed, or gone in a bad direction.
2. The handover from programming to QA leads to huge scheduling problems. You can schedule how long to code something (at least relatively) and how long to perform functional tests. But how do you schedule how many bugs will be found? How long to fix those? How long to retest these? How long QA is delayed because they are blocked by these bugs?
3. Combining 1 and 2, practically speaking the worst design defects are found in QA when it is quite expensive to fix these. Again this tends to be un-sheduleable work and usually is the cause of the biggest product delays.
Agile looks to fix these problems (and many more besides). The idea is to keep units of work manageable without requiring super-human powers. Another idea is that you don’t need the requirements up front, nor do you need the specs up front (if at all). Some of the key ideas:
1. Break down requirements into small easy to manage “user stories”. This makes the requirements more customer focused and really forces functional decomposition right from the beginning. It then lets you prioritize these requirements and tends to limit designer gold plating.
2. All team members are involved for the whole project. There are no hand overs from one group to another. Traditionally these hand overs lead to delays (due to people not being available at the right time), defects due to misunderstandings, and lack of teamwork. With agile the design analyst, programmer, UCD specialist, QA person and product owner are always working together as a team through the whole process.
A lot of the rest of the Agile Development Process is then executing these ideas in a best practices type environment using the experience of previous teams. From the experience of others, leads to the scrum principles:
1. Short fixed length iterations (for use these are 3 weeks).
2. The product is “shippable” quality at the end of every iteration. This goes hand in hand with the idea of continous integration. The product is built everynight complete and automated test scripts are run to ensure nothing is broken.
3. How to break down the user requirements, and pick the ones to implement in each iteration.
4. How to prioritize the requirements and handle things that go wrong, like too hard user stories, key team members on vacation, etc.
5. Better visibility to all stake holders. Everyone can see the list of user stories and the time estimates associated with them. This allows everyone to know how long something will take and why it will take that long.
Generally many product groups have discovered that Agile Development Process’s are more productive (more features or products are developed), quality is higher and the process is more predictable. Probably the hardest thing with adopting Agile is just to forget all those practices taught in older Software Engineering courses in University and accept the newer methods.
