AViSTO carries out projects in an agile mode in general and with the scrum methodology in particular. Here is the description of a generic procedure used.
Agile methods are designed to value:
- Operational software more than exhaustive documentation
- Adaptation to change more than following a plan
- Individuals and their interactions more than processes and tools
- Collaboration with customers more than contractual negotiation
The highest priority of the AViSTO team is to satisfy their customers by delivering fast and regular value-added features for the software.
Agile methods exploit change to make it an advantage. For this, the client and the AViSTO team must work together throughout the project.
Here is a quick description of the method used by AViSTO to meet these objectives.
Agile Scrum Method
AViSTO uses one of the most popular agile methods: Scrum. This method consists of:
- 3 roles (Product Owner, Scrum Master, and Development Team)
- Artifacts (Product Backlog, Sprint Backlog, Burndown Charts)
- Rules and tools
Scrum Method Roles
The customer has the role of Product Owner on the project. His responsibilities concern the management of the Product Backlog – so of all the functionalities to be realized.
One of the members of the AViSTO team has the role of Scrum Master. He is the guardian of the respect of the methodology. This is usually the AViSTO project manager – who is responsible for conducting the steering meetings – but this is not mandatory.
The development team is the AViSTO team.
The main characteristic of a Scrum team is that it is self-organized. In particular, there is no hierarchical responsibility – not even with respect to the Scrum Master. The entire team is responsible for the achievement – not each individual based on their particular skills.
She is actively involved in Sprint Backlog management.
Artifacts Scrum Method
The Product Backlog is a list ordered by importance (relative to the estimated functional value for users) of work to be done (also called “user story”) to create and maintain the product. This list is managed by the Product Owner. The AViSTO team estimates each “user story” in charge (Man/days).
The Sprint Backlog is the list of jobs planned for a sprint and its follow-up. Sprint Backlog is managed by the development team. A simple table and post-its can be used as Sprint Backlog. AViSTO uses an online web tool for this.
Burndown Charts are diagrams for tracking sprint activity. This is an important management tool for the development team.
Timebox Scrum Method
Timeboxes represent the events or time slots planned throughout the project. We can mention the sprint (time unit), the sprint planning (meeting to define the user stories), the daily scrum (daily meetings of the development team) etc.
Scrum Project Management
Apart from these purely Scrum timeboxes, project management and management rely on two instances:
- The Project Committee which manages the operational monitoring of the progress of the project
- The Steering Committee which deals with the management of the contract, the project, and the arbitrations
Following each meeting, a report is prepared to incorporate the summary of the decisions taken and a detailed action plan written by the AViSTO project manager and validated by the client.
The report is based on a project dashboard that consolidates and archives various elements (list of speakers, project log, list of expected entries and their follow-up, etc.).
The dashboard information is used to identify the risks of drifting and to trigger project alerts, which will lead to preventive actions whose implementation is monitored at progress points (project committee).
Scrum Method Rules and Tools
Product Backlog and Sprint Backlog Tracking
AViSTO uses an online tool to track the Product Backlog and the Sprint Backlog. This very simple and fast tool of use makes it possible to share the information efficiently.
Test Driven Development
AViSTO implements Test Driven Development when the project is adapted.
This means that the tests are written before the rules are implemented.
The development cycle advocated by Test Driven Development has five steps:
- Write a first test
- Check that it fails (because the code it tests does not exist), to verify that the test is valid
- Just write enough code to pass the test
- Check that the test passes
- Refactor the code, that is, improve it while keeping the same features
The advantage of this method is to ensure, for complex functional requirements, that the test has been written in relation to the need and not in relation to the result of the development. This ensures that you have effective regression tests.
The tool code is safer and more reliable using this method.
Do you have a question? A project to submit to us? Do not hesitate to contact us!