1st step: daily consultation of the personalized feedback
The cockpit allows every developer to consult in the form of a news feed the impact of its last changes on the code in termes of quality. The cockpit may also be used by the facilitators to analyze the last trends on each project.
Which data consul?
The reading of the cockpit has to allow every developer to identify the added defaults of code, as well as the understanding of the associated good practices in an approach of continuous improvement (how may the default be corrected?). The fils of source code may directly be open from Themis to get a better understanding of the problem. Likewise for the tests: when the code coverage of a file has decreased, or if the added code is not covered by tests, the developer may easily detect the portions of code underlying this result. Conversely, the cockpit consolidates every developer when he achieves clean actions, and values even more its work in the case of corrective actions.
When use it?
The use of the cockpit is recommended daily for every developer, when he knows that he has done changes on the code and that he wishes to identify its impact on quality. Depending on the settings of synchronization of the data applied in Themis, several consultation by day may make sense. The developers may also choose to be notied (mail, Slack...) when new actions are available. The goal of these personalized feedbacks is that the developers develop the habbit of going regularly on Themis.
2nd step: diagnosis and identification of axes for improvement
What does it consist of?
The "Diagnosis" section brings you a sharp and global understanding of the actions on a set of projects. The diagnosis is done by practice and offers the following categories:
- The evolution of the number of clean, harmful and corrective actions
- The distribution of the contributions by teams and developers
- The location of the actions in the map of the code
The "Technical debt" practice offers two additional categories, namely:
- The set of rules of good practices with the number of remaining defaults to correct
- The set of rules of good practices corrected/violated on a period of time, with precisions on the location and the involved developers
The use of the Filters in the bar placed atop the screen allows you to refine your analysis.
This section is intended to the facilitators and the pilot to identifier the axis for improvement of the teams on the current project, but also more broadly to observe the achieved progresses as well as the health condition of the projects.
When use it?
It is advised to use this section at the end of a a period, depending on the dynamics of the projects (sprints, 2 weeks/3 weeks). It is then recommended to gather the team to share these information, do a feedback session together and validate collectively the actions to conduct and the recommendation to take for the next phase.
3rd step: The action plans to achieve your strategy
What does it consist of?
The action plans allow to define a checklist of objectives to achieve by the teams. Those objectives, that may be individual or collective, may have different natures: non-creation of debt, number of corrective actions to do, number of defaults of code to correct on a specific practice... An action plan has and end date that allow to limit and finely calibrate the efforts that one wishes to execute on the strategy of quality. The action plans are an excellent way to provide to the developers the reminders and the "todos" in terms of quality.
The action plans are generally defined by the facilitators or else the pilot developers. Every developer may also freely create its own action plan to help him structure his approach. The developers will then access to the action plans to get an understanding of the objectives to reach and identify the actions to conduct to achieve them.
When use it?
The action plans may be created at any time within a period. It is advocated to set up action plans at the beginning of a period. The developers will then during all the action plan consult the status report of the objectives to identify what is left to be done. At the end of a period, it is advocated to gather the team and to analyze together the outcome of the action plans. This work is ideally in addition to the step 2 (Diagnosis). After the debriefing of the previous action plans, and due to the work of diagnosis, the action plans for the new period are set up.
How to meet these targets?
For every objective, Themis supports every developer offering him personalized suggestions. These are based on the ways of working of the developer and on the parts of code that he masters the most. Accessible in Themis, the suggestions are also regularly sent to the developers in the form of notifications.
4th step: The game as a vector of commitment
Why a game?
The objective of the game is to strengthen the commitment and the involvement of the developers in the strategy of software quality. This part allows to make fun the daily management of the software quality. The game constitue for the developers an additional motivating factor to do clean and corrective actions on the code.
What does the game consist of?
The developers may gather within a gaming room with other developers. A room covers a set of projects and is punctuated by game turns, which duration is configured at the creation of the gaming room.
In a room, every developer has a level that increases according to the done actions. The clean and corrective actions allow to win points. The developers may then get badges. All badges are unique and are won thanks to the "achievements" of the developers: few harmful actions, participation to the d'action pans, reduction of technical debt... The rank allow to establish a healthy and fun with the teams.
It is significant to note that people working on different projects or technologies may participate together to the same gaming room. It allows several developers not working on the same projects to create an emulation between them all the same.
Accessible by the developers and facilitators, only the developers may participate in a room and appear in the rank. A summary of the badges and the levels on the current period is also accessible via the Cockpit.
Every developer is free to join a gaming room. There is no impact on the rest of the use of Themis for the people that do not participate in the game.
5th step: Monitoring of indicators and reporting
These pages allow you to monitor indicators at a higher level: the technical debt, the test coverage, the number of bugs. You may observe the impact of Themis on the different projects. In refining the time window thanks to the filters, you may thus identify identify major trends on the period that interests you. You may also import your own performance data to detect correlation and possible metrics.
This part adresses the facilitators and pilots charged with monitoring the indicators of software quality measurement and performance indicators, and identify the next actions to conduct to reach the different milestones.
To extract data of software quality measurement (technical debt, code coverage...) and thus share the results of the actions conducted in Themis for the people outside the team, this section dedicated to the reporting provides synthetic elements for the follow-up of the good practices and the impact on the data of software quality measurement. The reporting may also be used as a internal support for the teams during the overviews at the end of the period addressed previously.
The PDF reports will help communicate the data of Themis outside. They are used during the overviews with the team in order to synthesize the information.