Today I thought that my home-project would be interesting for IT managers and you could give me feedback. My topic is analyzing the commit history in git and the conclusions we can draw for work.
POV: You are joining a new team. Team have three or six programmers who have been working on the project full-time for six or twelve months.
Idea:
- save the Git log to a text file and parse;
- find patterns and connections of different events;
- show statistics and recommendations;
Can a task tracker do this?
It happens that the situation in the code does not match the situation in the task tracker. And task trackers can be so-so.
Tools for it:
- about 25 free scripts on Github, where you need to work with bash scripts or be programmers to get the simple HTML report;
- 6 full-fledged products, but all of them need to be integrated with your work environment (even demo only on order). You can't put your data there in double clicks.
I write this free solution, but you can choose any other. The main charts are often the same in any solution. The main thing is that it can be used quickly and easily without waiting for any integrations and registrations.
So let's start analyzing the charts and metrics!
Saving the code by day for all time
The schedule allows you to estimate the pace, seasonality of work, as well as the stage of the project. Example:
You can click on the day and find out who exactly came or quit, as well as a list of tasks that somebody worked on that day.
- If an employee commits every day, it means that he works in this team.
- If an employee commits every day, but has not done so for a month, then he has quit.
- If an employee sometimes commits to this repository and there is a long time interval between them, then this is not his main profile. Maybe it is DevOps fixed deploy config or Back and fixed config for Nginx
Example:
Auto Tempo from JIRA
In some companies, you need to track off time for tasks. This is usually a +/- formality, in the form of smearing 8 hours on the number of tasks per day. If the developers write out the commit message correctly, then this schedule is create automatically:
You can see who, what and when did. And if you need dynamics by week, then there is such a schedule:
Here it is clearly visible that the number of tasks decreases every week. You can check the task granularity (it is small). This means that the team takes small tasks and does them very slowly, stretching the time. Why did this happen? It looks like an underload. Maybe it's time to reduce the composition?
The speed of feature implementation and delivery.
It is not always possible to build this schedule, but if it is possible, then you can estimate the speed of delivery. If the tasks are +/- homogeneous in terms of volume and timing, and the team composition does not change, we can get a time forecast for one task from taking on work to delivery into the release (or develop).
But in terms of auditing, the schedule of long-lived PRs is more interesting. The work was finished, but the code was merged after a long period of time:
How did it happen? Was the task unnecessary? Did the testing not accept the code? The customer of the feature is missing? This list (its content and length) is almost always an indicator of problems.
Release schedule and composition
Continuing the topic of rare graphs that are not always possible to build:
For example, in my team this chart will show that the frontend is quietly pouring code without approve QA. The actual release task list differs from what is described in the delivery documentation.
From the point of view of an external audit, we can immediately pay attention to the date confusion: releases are released every day, and then a break of two weeks. What was that? Rolled out a bunch of bugs? Have people quit? Is the broken CI/CD ? Actually, this is another reason to talk to the team about the problems.
List of all tasks
Two things happened in the course of our work: we moved from one task tracker to another, and the team split into two. All this led to the loss of some tasks and confusion in numbering. It's good that the developers signed their comments with the task number. The system compiled a list of tasks for which the code was writed:
This will help you survive various attacks in the style of "prepare a work report for the 1st quarter of 2007"
The cost of features
The features in the commit text are indicated extremely rarely (almost never). But if you set up such a rule in the pre-commit hook, then in six months you will be able to collect actual data on the costs of a particular feature from source code.
Knowing the average po and who worked on the features for how long, the system will automatically estimate the cost of the feature, as well as show the contribution of different developers.
A similar technique counts the files that the team has been working on. This makes it easy to identify areas of competence, even if you have not yet had time to get to know the team of programmers themselves.
About team member
You can learn more about the behavior pattern of each team member. For example, to assess the personal pace of work:
Or a typical works hours:
After all
I believe that this approach to team analysis is not the only correct one. But it can help you better assess the current situation and look at it from different angles. At least you can find the bottlenecks and sketch out the questions for the team.
Also in general, it is assumed that the team is not told that somebody is analyzing the git log. This will change their behavior.
I will be glad to hear your opinion on this matter. Do you know any other metrics that can be analyzed?
Git stat tool on github: link
Top comments (0)