Overview of Nezasa’s regular software development and delivery processes, which are applicable for Development Services (Custom Platform Services (CPS) and Accelerated Platform Services (APS))
Nezasa Development Process
Nezasa uses agile software development principles to continuously improve its Software as a Service (SaaS) platform. This approach supports velocity and transparency over the development process and also helps minimise costs and risks connected to development. The development cycles are defined by Quarterly Product Roadmaps and Biweekly Development Sprints.
Quarterly Product Roadmap
The Product Roadmap is the mid-to-long term planning of the platform development.
Nezasa plans two quarters in advance, being the first quarter where the planning is more detailed and supported by bigger deliverables, called “Epics”, and the second quarter where the strategic ideas are considered.
Quarterly Roadmap schedule according to the illustration above:
- Planning Freeze: One month before the start of a new quarter (28-Feb, 31-May, 31-Aug, 30-Nov) the roadmap for the next quarter is outlined. Bigger development items need to be submitted to Nezasa at least six weeks ahead of a new quarter in order to be considered for the next quarter.
- Start Roadmap Execution: At the beginning of each quarter, the execution of the roadmap starts. The scope for these three months is fixed and can only be changed for exceptional reasons.
- End Roadmap Execution: At the end of each quarter, the execution ends and the implementation of the next quarter’s roadmap items starts.
Biweekly Development Sprints
The Development Sprints are the short-time executions of the roadmap. Nezasa plans biweekly sprints by using agile principles:
Sprint Schedule according to the illustration above:
- Planning Freeze: The week prior to the Sprint Start, the planning of the following Sprint is fixed (usually on Thursdays). This means that, in order to consider a specific request for the upcoming Sprint, the relevant business requirement specification and the decision to implement this requirement needs to be submitted to Nezasa latest by the previous Wednesday prior to the week of the Sprint Start.
- Sprint Start: Each Sprint starts on a Wednesday morning and runs for two weeks. During a Sprint run, the scope of the Sprint is fixed unless there is a Bug report with a “Blocker” status. However, Bugs with lesser criticality will be considered for one of the following Sprints.
- Sprint End: Each Sprint finishes on a Tuesday night (UTC+1) of the second week. Once a Sprint is finished, the deployment to the production environment starts, which usually ends before Wednesday morning.
- Business Acceptance: One week after the delivery, the work will be considered as accepted by the client, unless agreed differently.
Regression Testing by Customers
The staging environment of Nezasa does not come with any type of SLA. The environment and its usage is optimized for Nezasa’s internal testing and release processes.
Thursday (usually evening, no fixed time): PROD database is cloned to STAGING database.
Friday, Monday, Tuesday: Release candidates are deployed throughout these days until the release is stable and Nezasa could perform all relevant tests.
Tuesday: Between Tuesday noon and Tuesday midnight, the last release candidate of staging is promoted to production once ready.
Should a customer wish to perform certain tests during the release days, the recommendation is as follows:
- Do not test before Monday.
- Staging is not as stable as production, and even less stable during release days. Short interruptions can occur.
- Do not immediately report bugs or instabilities. Before reporting, check a bit later or ideally after the next release candidate. The release version/candidate can be found in the application header:
- In case you report any issues out of staging, always mention the release version from the header and clearly state that the issue was found in staging and not production.
Please be aware that this opportunity for regression testing is not meant in any way for reporting minor issues or improvements. Nezasa is happy to receive that feedback. However, before reporting it, please re-test first in production or staging after the official release is out. Only severe issues may be looked at and be processed still during the release days. Please use the usual reporting channels in that case. Also, note that It is possible that even a severe issue has to be tackled in a follow-up release.
Nezasa will inform the customer each time a custom development item has been delivered to the production environment. Once delivered and notified, the customer has one week time to submit a notification in case of defect or in case the item was not delivered as defined.
After this notification period, the delivery will be considered as accepted.
Besides the above listed details applicable for development services (APS, CPS) Nezasa offers other Professional Services such as project management, advisory, training as well as product customisation and configuration on customer's request. In order to deliver a high quality service, Nezasa asks Customers to respect the following lead time of interaction:
- Configurative Changes. Examples:
- Setup of new users/agencies: app. 2 days
- Adding languages/currencies: app. 2 days
- Parameterisation of Inventory: app. 2 weeks
- Setup of new distribution channels: app. 2 weeks
- Change Requests requiring Code Changes. Examples:
- Setup of new instances: app. 4 weeks
- Update of Supplier Configuration: app. 4 weeks
- Request for Professional Service: app. 4 weeks
- Integration Projects. Examples:
- Setup of new API connection: app. 4 months
- Integration of new 3rd party supplier: app. 4 months
The listed lead times are indicative only.