Agile Practices
Publié le 24/06/2007, par Romain Linsolas dans Agile | Ajouter un commentaire
Article paru dans la newsletter #15 – Septembre 2006
Dirk Läessig is from Valtech Germany, though some will remember him from his days in London. In March 2006, he wrote an article for the Agile Centre of Competence in the Valtech DE public Newsletter. Here is an excerpt from that article, whose original content can be obtained from Dirk (Dirk.Laessig@valtech.de) – Eric.
More Best Practices
You have seen that Scrum is a lightweight process. It helps to manage a team that has to work creatively. It may not only be used for software project. Other projects may benefit from this type of management as well.
For software projects more must be added to make it a successful process. You can utilize practices from other agile and iterative processes. Therefore applying Scrum in a software project means more than just using the Scrum process.
Blending Scrum with UP
If the project is bigger and the environment is more difficult, more artefacts and workflows can be taken from the Unified Process (UP). The Unified Process is a process framework that supports projects ranging from small to large scale applications. Melting Scrum with UP creates a process that Valtech calls the Agile-UP. Melting Scrum with UP and adding XP requirements capture and test-first practices results in a model we call Extreme UP.
Although many artefacts are optional, a project team should create some helpful (UP) artefacts (besides the running software) depending on the project’s needs and environment. One highly recommended example is the Vision Document. It captures the vision of all stakeholders of the project. The Vision Document is created in the first phase of the project. It will be helpful if later the stakeholders cannot agree on some issues. Then the stakeholders can step back and have a look to the vision that they have agreed on earlier.
If the customer is working in a separate unit, they may not be able to be co-located and available to the team. Actually we found that this is a very infrequent exception.
If it’s not possible to have a customer onsite or if project complexity mandates requirements should be captured in detail using Domain and Use Case Models. We used business analysts as proxies to the business departments. For the developers they were acting as the customer onsite, because they were working on the same floor as part of the team.
More Agile Practices
Other agile processes like XP provide more practices. We briefly mention Test Driven Development and Continuous Integration.
Writing unit tests from the very beginning helps to enforce high quality and agility of your software. This is called Test Driven Development. Before you implement the software automated tests are written. Then the software is coded to pass the tests. The next tests are written and the software is enhanced again to pass the tests. These steps are done many times to finally get the operational and feature-complete software. Besides having the software permanently tested during development, the outcome also includes an automated suite of tests. Running the test suite to make sure the software is still working can now test any minor changes – regression testing at unit level.
Continuous Integration is based on automated testing in combination with an automated build procedure. A daily, hourly or even continuous build creates functional software, which is tested automatically by executing the test suite. If developers have finished implementing a feature they are encouraged to commit their changes into the source code management system as soon as possible. Integrating the changes of the software often keeps the time for the integration process short, because the bugs for little integration steps can be easier eliminated. The time for integration increases exponentially, if more changes and bigger changes have to be incorporated. Continuous Integration therefore reduces risks and minimizes the effort of integration at the end of the project (or iteration).