Development cycle in Leon adheres to the LeSS framework, dedicated for large-scale agile modeling of product development. Apart from the typical elements of LeSS (refinements, retrospectives, etc.) we have introduced a number of additional components to face the specific challenges we had identified in the process.
Each new feature (or any change in application logic, for that matter) starts with a specification done typically by a Product Owner, and usually consists of a description of a use case for a customer. After such user-centered specification is ready, all To-Do features are briefly presented on the overall “refinement” meeting with the programmers (as a part of our company-wide LeSS approach), where the specification is further clarified in response to any question that may occur at this point. This step allows us to resolve any uncertainties about any given feature even before the programmers start working on it.
More than a teamwork
After the specification has been approved by the Product Owner as well as the programmers, one of the teams is assigned to a given feature. Shortly after the overall “refinement”, each team schedules a team “refinement” where all features assigned to a given team are further discussed, with an emphasis on technical details and any difficulties that may arise. When both the user-centered as well as technical descriptions are complete, the feature is scheduled to be developed in the following two-week sprint.
Each team consists of 4–6 people (mostly full-stack developers), working in a separate room. The room layout is modeled to promote an open environment, so that every question or uncertainty can be quickly resolved instead of consuming more time and posing problems in the future. Each team schedules daily a short morning meetup to discuss current progress and possible threats to the completion of the current sprint. During such meetings, each team member reports on their current work, and tasks from the current sprint are distributed among the programmers, taking into account any potential absences, delays as well as programmers’ personal preferences.
TEAM DURING ONE OF REFINEMENT MEETINGS
The entire source code of Leon is maintained as a git repository, which allows us to track the entire history of the codebase and ensures that any accidental change in the source code can be easily reverted. In parallel with the implementation of any actual feature, the programmers are required to implement unit tests for it. Test-driven approach is highly encouraged. The unit tests are checked for each changeset in our repository in our CI (continuous integration) system, so that any problem with unit tests will be immediately visible even if overlooked by the programmers. The implementation process is further facilitated with tools for static code analysis, integrated into the IDE and configured in order to ensure that all new code company-wide adheres to the established standards.
Only after the feature is implemented together with unit tests in accordance to the specification agreed on by the team, the new feature goes into a code review. This is a point when other members of the team (and sometimes, from outside the team as well) inspect the code and check whether it correctly adheres to the logic, whether the code style is acceptable and whether all the required unit tests are written correctly. If any of these conditions is not met, the feature is sent back to the assigned programmer with a constructive feedback.
When a feature passes the code review, it is thoroughly tested first within a team (internal tests) and then in cooperation with our customer’s support staff (end-to-end tests). This step is introduced to ensure that the outcome meets the user’s requirements and is fully useful from the user’s point of view. Any potential problems e.g. with UI (user interface) are reported at this stage back to the team, in order to be resolved as soon as possible. After the feature is approved, it is integrated into our company-wide development version of Leon (entirely independent from the production data or infrastructure) so any potential integration problems may be easily detected.
Almost ready to go
After the two-week sprint is finished, all features that were completed and integrated into the development version in that period, are being gradually enabled for the customers, using a canary deployment model. The entire process takes typically three to four days, and any issues discovered during that period can be quickly resolved without causing inconvenience to customers, which do not yet have access to the new version at this specific instant. In case of any major problem, we can safely rollback the previous version for any selected customer or for all customers at once, until all issues are resolved.
DEVELOPMENT CYCLE IN LEON
The last step in our quality cycle is marked by retrospective meetings (both within teams as well as company-wise), in which programmers and management discuss any issues that may have been encountered in the previous sprint, on any step of the production process. Complicated technical issues are also discussed on separate bi-weekly back-end and front-end meetings for IT staff, where programmers from different teams may brainstorm their ideas for improving the development process and share technical knowledge.
The constant feedback helps us in improving the overall process, which is additionally evaluated on our monthly quality meetings, during which, various quality-related metrics (such as percentage of code covered by unit tests) are evaluated. These also serve as a platform to discuss long-term goals and potential improvements to our LeSS approach.
Not yet a member of Leon community? Contact our Sales team to find out more or jump straight into the 30-day free trial.
PIOTR RÓŻAŃSKI | |
|
Subscribe and Follow Us
