| By Pak-Tjun Chin,
on 31-10-2008 10:54
|
Views : 407  |
Favoured : 32 |
Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it.
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
That is, while there is value in the items on the right, we value the items on the left more.
If you would like to sign the Agile Manifesto, kindly go to http://www.agilemanifesto.org/sign/signup.cgi and add your name to the signatory list.
12 Principles of Agile
- High priority to customer satisfaction via early and continuous delivery of valuable software.
- Welcome changing requirements.
- Deliver working software frequently.
- Continuous working relationship between developers and business stakeholders.
- Projects are built around motivated individuals, who should be trusted.
- Frequent face-to-face conversations.
- Working software is the primary measure of progress.
- Promotes sustainable development.
- Continuous attention to technical excellence and good design.
- Simplicity.
- Self-organizing teams.
- Constant adaptation to changing circumstances.
Agile vs Waterfall
| Agile |
Waterfall |
| Adaptive - welcomes change. |
Predictive - resist change. |
| People-focussed. |
Process-focussed. |
| Working software is the primary measure of progress. |
Comprehensive documentation is the primary measure of progress |
| Produce completely developed and tested features (but a very small subset of the whole) every few weeks or months. |
Development and testing phases consume a relatively longer time and generally not broken up into smaller chunks. |
| Constant communication between all project team members throughout the project lifecycle. |
Communication is 'compartmentalized' and infrequent. |
| Customer collaboration. |
Contract negotiation. |
| Responds to change. |
Follows strictly to a plan. |
Suitability of Projects Using Agile
| Agile |
Waterfall |
| Low criticality. |
High criticality. |
| Mostly senior developers. |
A mix between junior and senior developers. |
| Relatively higher requirements change. |
Relatively lower requirements change. |
| Small number of developers. |
Large number of developers. |
| Culture that thrives on chaos. |
Culture that demands order. |
Key Success Factors of Agile Projects
- The culture at the organization must be supportive of negotiation.
- People must be trusted.
- Fewer but more competent people.
- Projects must live with developers' decisions.
- Project must have an environment that facilitates and promotes communication between team members.
- Project size should be fewer than 20 to 40 people.
Agile Development Best Practices
Collaboration
So, what are some practical aspects of Agile that we, as developers, could start adopting from today?
Well, we could start by setting up a wiki page to allow for collaboration of ideas and information related to a particular project or application.
I recall the first couple of months after rejoining the ED&IA (Enterprise Document & Imaging Archive) Asset Team at National Australia Bank Ltd and working with Mark Ng to uplift the jLetters application. At that time, there was not much, if any documentation on what jLetters was, how jLetters worked and why it worked that way.
Thus, one of the first things that we did was to set up a wiki section dedicated to jLetters, with the objective of ensuring that any new developer that joined the ED&IA team as a jLetters developer would be able to set-up a working development environment and be productive within a week, and not weeks.
Since then, we had a new jLetters developer join the team, I think he lasted only about a month, well, his short stay had nothing to do with work, but the point I would like to make is that this developer managed to start coding after a few days, large due to the information contained in the wiki.
Communication
Communication is one of the key success factors of Agile. Direct and constant communication with business stakeholders, with testers, with infrastucture designers, or with anyone else that is part of a project delivery team should be encouraged.
For one of the projects that I was a part of, the Dynamic Pricing Calculator Project at National Australia Bank Ltd, we had daily stand-up meetings in which even business stakeholders participated. Stand-up meetings cover 3 things:
-
Things I have done since yesterday's meeting.
-
Things I am going to get done today.
-
Obstacles that I need someone to remove.
Each participant should only be allowed a couple minutes to speak and try not to let participants go into solution mode during the stand-ups.
Continuous Build
A continuous build (or some would call it Continuous Integration) environment encourages the practice of frequently committing code change to a central source control system (ClearCase for example). Having a continuous build environment has numerous advantages:
-
Bugs may be uncovered when unit test fails. Developers would be notified as soon as this happens and they would have options of either fixing the bug immediately or reverting to a previous working version of code.
-
Issues with integration would be detected early and investigated as soon as they crop up. This reduces the risk of integration issues cropping up during Systems Integration Testing (SIT).
-
Avalability of an up-to-date working codebase at any time.
For the ED&IA (Enterprise Document & Imaging Archive) Asset Team, we have adopted Cruise Control for this purpose.
In the next couple of screenshots, you are being presented with a summary screen of all the projects that are part of a continuous cycle. From this page, we would have a snapshot of each projects build status, frequency of builds, etc.
Should there be a build failure, CruiseControl has been configured to spam relevant developers until the issue is resolved. Recently, a couple of red and green lava lamps have been integrated to our CruiseControl server that servers as a visual representation of build status. If you are interested in its details, please read the Integrating Lava Lamps to CruiseControl article.
Automated Testing
A continuous build environment with automated test execution is really of great benefit to me personally. I recall one project, VOL2, that I led earlier this year.
Due to the extensive coverage of unit test cases, the VOL2 code yielded only 4 low-level defects throughout the SIT, UAT, PPTE and SAT phases of the project. The project also cut down its SIT cycles from 3 to 2, and UAT took just a couple of days for business sign-off, instead of the planned 2 weeks.
VOL2 has since been in production for about 6 months (as at September 2007) and we have yet to have any further functional or performance defects raised against the application.
Responding to Change
Finally, Agile is a real proponent of constant face-to-face communication between project team members.
Key team members should meet regularly with business stakeholders to go through previous action items. Valuable feedback from business stakeholders assist in bettering documentation and processes, which are continuously refined.
References
http://agilemanifesto.org - Agile Manifesto
http://en.wikipedia.org/wiki/Agile_methodology - Agile Software Development Methodology
http://www.martinfowler.com/articles/newMethodology.html - The New Methodology
Last update: 03-11-2008 15:53
|
