I prefer to work in small teams: up to 10 people. You know all the team members personally; more often than not, you do not need to specifically “reserve time” to discuss something and make decisions.

But it also happens that we take on the work on large projects. By “big” I mean the composition of the following factors:

1. More than 50 projects in the solution. Assignment not all of them you know
2. Build and display last more than 5 minutes
3. Dozens or hundreds of people in different offices (possibly countries) work on the code
4. There is a clear division of labor and the responsibility of each team.
5. There are strict regulations, standards for the design of the code, passing a review is a mandatory criterion for the task
6. The accounting of working time is performed in order, analyzes the reasons for the discrepancy of estimates and real labor costs.

The bureaucracy in this case is a necessary evil, however, acting on nerves. To avoid the loss of precious cells, I advise you to immediately prepare for the fact that you have to change your usual workflow. The good news is that, having retrained, you will not be difficult to do well on small projects. Most likely, your colleagues will be pleasantly surprised by such thoroughness

1. Use feature-brands and atomic commits.

Council from the category of captain, but if everyone obeyed this rule, an article like this would not have gained so many advantages. I did not study this technique on purpose, just at some point I began to clearly divide the work into subtasks and make each commit at the end of each. It is easier to use atomic commits along with TDD, because the development itself in this case is iterative. The extra bonus for you is that if you nakosyachite themselves in your branch, just do a git reset --hard. Think of it as a mandatory save in complex computer games.

If a colleague in another branch needs your code, which is not finished yet, he will be able to make a cherry-pick without surviving the merge and pick up only the changes he is interested in, and not your entire stream of consciousness.
The main argument I hear against this practice is “the state of the stream is lost.” I can not comment on it, because the “state of the stream” cannot be measured, touched and evaluated.
')

2. Use the commit naming format.

Naming commits should start with the task ID in the tracker. All modern project management systems are able to synchronize with the build server and VCS. In addition, it is easier to track the history in the repository.

3. Get aliases in git to prepare pull request

It is always necessary to launch all local commits in upstream, download with the master / dev branch. These are simple actions, but after work on a complex task, attention may not be enough. It is better to entrust this automation.

4. Get a checklist with the daily routine.

For example, such:

1. Check pool requests, have all gone, are there any rejected?
2. Transfer the task with the rejected pool-request to the “development” status, assign assignee to itself if there is a revider left there or the field is empty
3. Correct rejected pull requests, translate task into review, reopen pool request
4. To take the task that we have agreed to work for today, to transfer development into status
5. At the end of the work, keep master / dev
6. Fix conflicts
7. Conduct smoke testing
8. Translate task into review, open PR
9. Go to the next task

In some organizations there are strong dev-ops and it is enough to push the first commit into the upstream so that the card goes to the desired status automatically. I strongly welcome such mechanics, but far from all and not everywhere set up such automation.

5. Agree on everything in advance.

Generally about everything. Processes in large organizations are regulated, and the work of key employees who make decisions is always above the roof. If you need a review tomorrow afternoon, make an appointment tonight. Need help with a complex piece of code that you reach in the evening. Check with the person whose help you need in the morning. He may have his own business. If you need to clarify requirements with staff from other departments / clients, start this week.

6. Think about plan B

Even if you agree on everything, the employee you need can get sick, it can be pulled to an unexpected fact. Anything can happen. If possible, consider alternative tasks in case of blocking.

7. RTFM

Seriously, read. It will save time and nerves to you and your colleagues. Just ... do not trust the documentation at 100%. Documentation is never relevant :)

8. Build partnerships with colleagues

Learn who you will interact with. Who can block you? Whose orders should you carry out, and whose not? Who can help you in case of what? You don't have to love all your colleagues, just act like a human being. Do not harm and do not be rude. Corrupted relationships with other employees may haunt in unexpected ways.

9. In any incomprehensible situation, act formally.

No, I do not call for an Italian strike . The larger the company, the less time the management has to go into the details of the problems. Perhaps you showed yourself heroically and tried your best to correct the situation. If this does not work on the head you are not stroked. And the prize will not give. In general, you will remain extreme. Do everything that depends on you, but within the rules. In most cases, no matter how you think, they are reasonable. If the rules are not reasonable - change jobs.

9 ¾. Be careful and prudent than usual

It does not pull on a full-fledged council, so I limited myself to three quarters. The more people on the project, the more downtime and mistakes begin to “cost”. The developer sent a pull request. Timlid was busy and did not review, the code did not contain. The next day, his teammate needed a code from a non-merged request. Pulk-request zakdeklaynili, two features were delayed, QA did not have time to test. On a company scale, this translates into enormous time and money overruns. Therefore, it is very important to make maximum efforts so that everything happens in a timely manner. No reasonable reserves will stand up if they “go” at once to several tasks on the critical path of the project .

To all employees of the invisible front of the “bloody enterprise”, I suggest sharing their positive (or not so) experiences in the comments .