Gitpab Nice to meet you

Hello. I am Gitpab . Pleased to meet you. I was made to make it easier to supervise the programmers. I take the clock that the developers have noted in Gitlab, and count up how much time spent on tasks. And the project as a whole. Rumor has it that the big bosses with my help consider the salary of progers and the profitability of projects. And indeed it is. Even with my help, you can increase the marginality of software projects. And now I will tell you how I can be useful for your team and for you personally.

How i work

I work without days off and sleep and lunch breaks. It sounds scary, but you can be sure of this by deploying me on your server. Benefit in the readme there are instructions on how to do this.

Do not forget to register in the config projects, for which I must follow. Once an hour I will drop in at Gitlab and pick up a fresh one from there - new sprints, tasks, comments, retired time, information about participants.

Looking ahead to say that I myself look like this:



This is my dashboard, here you can see the main indicators. The most interesting of them is the Balance. It reflects how many hours the developer has advanced, or vice versa should pay at the moment.

But now let's go in order. I decided to talk about myself. The fact is that I personally saw quite a few different projects and different project managers. Nothing personal, just let me first tell you about the technique, our mother.

Project in Gitlab

I myself am a supporter of Scrum. Because Scrum is the worst of all but the rest. Now I’m here to copy our internal document, which our new employees must read.

What is missing

Short instructions, but it helps to build Scrum in my projects. It does not say about something. Let me now come up with even some fancy term for this. In! Ied Cool, right? Ied Iron Eggs Discipline. Discipline Iron Eggs. Without due attention to the development process, any instruction with the project together will stall.

How helpful I am, Gitpab

The teams, for whose activities the author of the article is responsible, consist of non-staff employees - all work with payment for the time devoted to projects. I must say that managing such teams with high quality is a bit of a jewel. The bigger the team, the harder it is to keep track of it. And the moments that need to be monitored are not enough.

• Isn't any developer a podzavis?
• Do not write off the task more than it is worth it?
• Are invoices issued specifically for works that were completed during the period?
• How much do we need right now to the developer? And to all developers in general?
• Do not go beyond the project budget?

I, Gitpab, answer all these delicate questions, simultaneously solve other problems.

Retired time

This report alone is worth something. Here you can filter retired time by the desired criterion.

Let me tell you a story. Once we inexorably moved to deadline. The project was done qualitatively and responsibly, everything went well, and we had already completed work on the tasks, when suddenly a week before the deadline we received 63 comments. The nuances of the relations of the Don Don Directors were such that it was necessary to close these tasks for a week in order for us not to defer payment. This is not to say that these tasks were terribly difficult, these were comments on the “licking” of the system. But we did tasks for 20 per sprint. The maximum that the team has had in the entire history of the project is about 40 tasks per week. How to perform one and a half times more? According to the assessment, the tasks were pulled for a couple weeks.

But the thought was born. The team had me, Gitpab. Therefore, the author suggested to the budget owner in this decisive week to increase the rate by one and a half times to everyone, provided that this rate will apply to these comments. All these tasks were assigned a separate label in Gitlab and began to code. I think it is possible to suppress such a decision, but it was well presented to the team. And all 63 tasks were closed for the weekly sprint. Seriously. 63 and high quality.

For the calculation of premiums, we simply filtered for each member the time written for this label for the period.

Task ratings

Why evaluate tasks? First, as mentioned above, so as not to gain extra in the sprint. I am a supporter of taking tasks as much as the team will manage to complete the train. And if there is time, take something else in the process. So the team looks more profitable to the customer, because it gives real promises that it keeps, and even does a little more than promised.

But there are other reasons. Another story. The team was a developer who sought to write off time for tasks more than it was worth it. And sometimes 5, and sometimes 10 times more. The author did not really like it. But this developer, I must say, arranged everything except for this nuance. There was no desire to clash or disassemble. At that time, we did not evaluate all tasks. In Gitpab it was not difficult to see that a lot of time was written off only for invaluable tasks. They began to evaluate all tasks without exception, and it helped.

And I, Gitpab, give you a tool for checking the estimated and actual time spent on tasks.

Customer reports

Along the way, I save time on the preparation of reports on the work done for the sprint. Look, you open the sprint, and there is a ready-made report. Just start a new tag in Gitlab and copy the description from the sprint there. It is already in Markdown.



Skopipasti in Gitlab:



Customers recognize that it is nice to deal with a team that lets in their Gitlab in the course of the project, and also gives detailed weekly reports on the work done.

And some business-like customers sometimes ask for some crazy ones.unmatched task lists with their status. In such cases, it is very convenient to start a separate label for such a list and from time to time unload these tasks filtered by label. Just press the button “Export to csv”. Buddy, you would know how much time it sometimes saves ...

Money

For each project participant, you can specify a rate per work hour: A



user with finance rights sees this section along with balances. Balances here in hours - how many hours are prepaid (green). Or how many hours to pay (red). Comfortable, right?

But that is not all. When placing a bet, you can set the costs - how much you need to pay in order for a person to get his bet on his hands. For everyone, this is your percentage.



Wait, that's not all. There is an interface for making payments. Here you can see the history of payments, paid hours.



And when you make a payment, the paid hours are automatically considered taking into account the costs.



If you have employees in staff on fix, then the reasonable question is why this problem with the maintenance of payments? I agree, you do not need it. But if you have people on an hourly rate, then such a tool is very helpful. When paying you, you will not have to build reports on the time spent, look for what the report ended last time. And there will be no confusion, you will not accidentally take over previously paid work. And do not miss unpaid time.

Now all you need is to look at the balance of the employee and throw enough money to the person to make his balance green.

Project's budget

Since you now have numbers for each problem, it’s not tricky to calculate their sum. Thanks to this, you will understand if the project is not beyond the budget:



Similar statistics are also constructed for sprints.

Hey, Gitpab, when does your author have time to work?

Decomposing tasks, monitoring the implementation, coordinating the team, and plus everything else described above ... you might think that takes a lot of time. Of course, it eats up time. But this is much better than a floating project without control. Do not make my author me, he would have become a lost manager who forgot how the IDE looks like (not to be confused with the IED, see above). And thanks to me, he manages to scuff the code no less than his colleagues in the workshop.

To summarize

The above methodology is described and how can I help you follow it using Gitlab in conjunction with Gitpab. This works well in the case of the author. Perhaps you want to change something for yourself. No problem, change, adjust for themselves. In the end, you probably have a goal - to carry out projects with high quality and to profit from them, and I, Gitpab, are just your help in this.

And now the cookie in the studio

By the way, I was created by one good uncle, the author of this article. He was so kind that he made me open-source. I'll be happy for the stars on Github .

I almost forgot about the most important thing. I am a tool. And one of my friends, a successful entrepreneur and a simple Russian billionaire, says that the tools do not work. People work. I hope you understand what I mean. Take advantage, I'm at your service. Successful projects.

ps Looked into the publication and found quite a few minuses. When you put a minus, do not be lazy to comment, I am interested in feedback.