The Way to Neat Code
Synopsis:
This book is a summary of the experience of programming guru "Uncle Bob" over 40 years of programming career, explaining what kind of attitude, what kind of principles and what kind of actions are needed to become a real professional programmer. The author takes the detours and mistakes he and his colleagues have made as examples, with the intention of guiding those who come after him and helping them to take a higher step in their careers.
This book is suitable for all programmers and can be used as a reference for all those who want to become professionally literate in the workplace.
Chapter 13: Teams and Projects
How should I implement small projects? How to assign programmers? And how should large projects be implemented?
13.1 Is team development just a simple mix?
Over the years I have consulted for many banks and insurance companies. The one thing that all of these companies seem to have in common is that they all assign projects in a quirky way.
Banks usually have relatively small projects.It only takes one or two programmers to work for a few weeks。
Such a project will usually have a project manager who also manages several other projects, a business analyst who also works on other projects, several programmers who also work on other projects, and one or two testers who also test other projects. See the pattern in this? These projects are too small to fully allocate one person's entire time to them. Each person's commitment to the project is calculated at 50% or even 25%.
But don't forget: there is in fact no such thing as half a person.
Having a programmer devote half of his time to project A and the rest to project B is not feasible, especially when the two projects have different project managers, different business analysts, different programmers, and different testers. Can you call this ugly combination a team? It's not a team, it's just a mixture from a juicer.
Cohesive team:
It takes time to form a team.Team members need to build relationships first. They need to learn how to work with each other, they need to understand each other's proclivities, strengths, and weaknesses, and ultimately, they need to come together as a team.
There really is something magical about a cohesive team.They are able to work miracles together. They are confidantes of each other, able to look out for each other, support each other, and motivate each other to bring out their best. They are invincible.
The composition of the team and its proportions:
- Cohesive teams usually have about 12 members. The maximum can be 20, the minimum can be as few as 3, but 12 is best. This team should be equipped withProgrammers, testers and analystsThe same time there is also aproject manager。
- Programmers are counted as a group, testers and analysts are counted as a group, there is no fixed limit to the ratio of the number of people in the two groups, but 2:1 is a better combination.
- The ideal team of 12 people is staffed like this: seven programmers, two testers, two analysts, and a project manager.
Division of labor and responsibilities of team members.
Analysts & Testers:
- Analysts develop requirements and write automated acceptance tests for them. Testers also write automated acceptance tests, but they both have different perspectives. Both write requirements but analysts focus on business value while testers focus on correctness.
- Analysts write success path scenarios; testers have to be concerned with those things that can go wrong, and they write failure scenarios and boundary scenarios.
Project Manager:The Project Manager tracks the progress of the project team and ensures that team members understand the project timeline and priorities.
supervisor: one of the team members may devote part of his/her time to the role of team coach or Master [2].Responsible for ensuring the progress of the project and supervising the discipline of the members.They are charged with the responsibility of being the backbone of the team if they choose to stop halfway through a project because the pressure is too great.
The team's fermentation period:
- It takes some time, perhaps 6 months or even a year, for members to overcome their individual differences, work together and trust each other to form a truly cohesive team.
- Once cohesion is truly formed, it creates a kind of magic. Members of the team will make plans together, solve problems together, face issues together, and take care of everything together.
- Teams are already cohesive, but to break up such a team just because the project is over is ridiculous. The best thing to do is to not break up the team and let them continue to work together, just keep assigning new projects to them.
What comes first, the team or the project?
A professional development organization will assign projects to cohesive teams that have formed, rather than forming teams around projects. A cohesive team that is able to take on multiple projects at the same time and distribute the work according to the willingness, skills, and abilities of each member will successfully complete the project.
How do you manage cohesive teams?
Manage the team's project velocity:
Every team has its own velocity. A team's velocity is the amount of work the team can accomplish in a given time period. Some teams measure their velocity using weekly points, where "points" is a unit of complexity. They break down the characteristics of each work item and use points to estimate them. Speed is then measured in terms of the number of points that can be accomplished each week. Managers can set a target value for projects assigned to the team.
The Project Contractor's Dilemma:
As a project contractor who has an exclusive team fully committed to his project, he is able to clearly calculate how much the team is committed. They understand that forming and disbanding teams is costly and hence the company does not transfer teams for short term reasons.
If projects are assigned to a cohesive team, and if those teams are working on multiple projects at the same time, then project priorities can be changed at the whim of the company. This may affect the project contractor's sense of security for the future. The resources they rely on may suddenly be taken away from them.
Forming and disbanding teams is just an artificial difficulty and companies should not be bound by it.If the company considers one project to be a higher priority than another in the business, resources should be reallocated quickly. It is the role of the project contractor to clearly define and present the value and significance of the project so that it is recognized and supported by company management.
13.2 Conclusion
Teams are harder to build than projects.Therefore, it is a better practice to form robust teams that move as a whole to work together on project after project. And, teams can also take on multiple projects at the same time.
When forming a team, give them plenty of time to form a cohesive team that works together all the time and becomes a strong engine for continuous project delivery.