RSR_Dev Process Method - adriancollier/demo GitHub Wiki
We use a combination of different Development Methodoloiges to create a working process for RSR. This combines elements from Agile, Waterfall and other Current methods, whilst adapating them to our specific needs and requirements as an organisation.
We have multiple stages of development to be followed for all Feature Development Tasks the Team carries out:
- Requirements
- Design
- Preparation
- Approval
- Implementation
- Verification
- Maintenance
No step can be continued until the previous step has been completed. Any step can regress a project to a previous step if there is work to be done. No step can be skipped.
We will of course be implementing a flexible model for this, as we work with a live business. But we should be strict about asking and ensuring we get feedback from all at the right point in time. If someone brings new Requirements to the table, then this should be raised directly with Product Management to determine the course of action.
Requirements, Design and Preparation should all be carried out prior to any coding work taking place. This information should be encapsulated within this template document: https://docs.google.com/document/d/1R4gadnh_AgdB9_Fv73gAyBwt-oQtEo-jSP__VWdsFis/edit?usp=sharing
1 - Requirements: Adrian responsible to provide Requirements for all Features and Bugs that are raised. Ideas and suggestions for Design will be included if existing.
2 - Design: The Assigned Developer is responsible for the Design of the feature. All suggestions should be considered in addition to all Requirements. Suggestions may be overruled in the event of a better solution. The Design should also take into account all external resources needed including:
- DevOps
- Designers
- Comms
- Documentation
- External Systems
- New Libraries/Packages
- Staging of implementation
3 - Preparation: Here the work to be done is split into smaller issues and set into phases to be implemented. All the issues are given time estimates and a deadline is set.
4 - Approval: Before work officially starts on a feature or issue, the Specification and plan needs to be approved. Approval should be given on each project by one of the relevant persons from each group. Approval Groups include:
- RSR Product Management
- Akvo Management
- Partner Team
- RSR Development Team
- DevOps Team
- Design Team
If a Feature has no portion for a paritcular team then this team should not be required to provide approval. This should be included within the Spec. For example, a pure Back End infrastructure change would not need Partner Team and Design Team approval.
5 - Implementation: Progress should be provided on the Github Issue. Any blockers to progress should be raised either directly or during the next standup. Developer documentation on the code being written should be provided during the implementation phase. Feature documentation will be written during the Verification phase.
6 - Verification: The QA Team are responsible for ensuring that the feature is working according to the Requirements. Product Management & Partner Team are responsible for providing the Feature documentation for our Partners.
7 - Maintenance: Product Management in conjunction with the Partner Team will carry out reviews of implemented Features ensuring that they continue to meet the requirements. Any changes or modifications required, will be highlighted and taken through the process as a new Feature. Only if the Entire Feature is to be pulled out of Deployment, would the Feature Itself be returned to a previous phase.
Back to RSR Development Process