If you have a team of software engineers and want to move them to Mac, you will need to consider a number of things before you do so.
Here’s what’s new in our January 2023 Release Notes:
* Tables Columns Sorting Improved
* Reconcile Commits Count Between KPI Card and the Table
* Efficiency Tab Improvements and Efficiency KPI Cards Align
After many intense brainstorming sessions, days of implementing, testing and improving, we can finally present it to you: the Amazing, highly detailed, super insightful Developer Scorecard! Get to know your developers, this time for real, including their performance metrics and work patterns.
As we mentioned, it is detailed, but also, it gives you context. Right now, there’s not only one perspective of your developer’s work, but three independent points of view! Finally, you’ll be able to quickly answer questions like:
And these are just for the beginning! You already get the big picture, right? So let’s dig deeper into that so you can get familiar with some helpful details.
You might be wondering “How will I know on which level I’m checking this developer?”.
The comparing values will tell you exactly on which level you’re comparing them.
How to get there? Here’s the path:
This is what the top of the page will look like:
If you take a closer look at the metrics tiles, you’ll notice that the results and comparisons are reflected based on the workspace average. Voila! That’s your first level of Developer Scorecard insights.
How to get there?
As you can probably notice, the charts look very similar. But, the numbers represented are different! That’s because they were calculated on different baselines, according to the project’s context and overall results.
Again, to make sure what kind of developer’s scorecard you’re checking, just take a look at the tiles summary. Here it specifies the project average.
How to get there?
This time there are no surprises here – the charts look very similar again.
But if we take a closer look at the metrics we can see it’s about the team’s average results.
So just to sum up: Please remember that some charts might look very similar, but even in a case when the main metrics values might be the same, the comparison values and the charts’ trends are different. The calculation baseline is different in each case depending on where exactly you click on the developer’s name.
Let us quickly walk you through the new charts!
Sum of days when a developer has committed, created, or reviewed a PR within the selected period.
Total estimated hours spent on writing code within a selected time frame.
Number of commits authored by the developer within the selected timeframe.
Ratio of developer’s coding time and work time on the current project.
A.K.A. Contribution. Total of lines inserted and 20% of lines deleted in a commit.
Percentage of productive lines of code (which didn’t need any rewrite within last 3 weeks) vs. the total implementation lines.
The number of Pull Requests created by the developer within a selected timeframe.
The number of review comments by the given developer.
Average Pull Request Cycle Time in the selected period.
Based on some predefined patterns we try to categorize development work into these categories. There’s always some overlap between them.
Our team members can work on a lot of things. Based on their strengths and weaknesses in each work type, you can help them to work more efficiently with the right task allocation.
There are 6 work types that we differentiate between:
Counts all the contributions from a given developer and uses the technology for categorization.
Calculated from all the PRs created by the developer in the given time interval. We have the avg cycle time as 100% and we divide this into three parts by calculating all the average times spent on each step (development, pickup, or review).
A new table was added to the Dev Scorecard and Deep Dive views: Pull Request Activity. It’s the same concept we have with the Commit Activity: all the metrics based on pull request data are a separate column in the table.
You can find various places in the application with the “Show commits” or “Show pull requests” link. By clicking on the link you can view a list of all the matching PRs and commits used in that context.
We’ve made the invitation system more clear and easier to understand:
Now you can go into the details on your developer’s pull requests activity for a better overview of the development lifecycle than tracking single commit-based activities.
No need to click the “back” button in the browser anymore! In case you dig deeper in your projects or teams, you can go back by as many levels as you need.
The scorecard feature aims to provide you with a detailed overview at a glance of how each of your developers are doing generally – and in relation to their team and project. If one of their metrics seems amiss, you can easily dive deeper to help determine why.
This update also enhances the details of your pull request and commit activity, while making it easier to manage developers and collaborators. Last, but not least, you should also find it easier and faster to navigate from section to section without having to hit the “back” link on your browser. It’s a small, but significant step forward!
If you read our Benchmarking review comparing Pluralsight Flow and Gitential, you may have picked up on something else that we are working on – we will soon be adding industry benchmarking, too. This will provide you a fourth view allowing you to compare developer performance to industry standards.
There’s much more to come – some exciting things are in the works that we aim to announce before the end of 2021. We’d love to hear your feedback on the Developer Scorecard and recent enhancements. Do they work better for you now? Are there any changes you’d like to see? Please let us know!
