This experience is based on the practice summary of two small and medium-sized projects (one 2000 Manday, one 1500 Manday) in the past two years, and I hope to discuss and make progress with you.
- Every team member is the project owner, promoting the common growth of the team and the project
- Cultivating the self-organization of the team "Scrum and XP in the smoke of gunpowder"
- Experts recommend that the team size be 6-9 people "Scrum and XP in the smoke of gunpowder"
- Maintain a certain stability of the team to form a Group Flow.
- Three Part Time team members are not as good as one Full Time team member
- About Team Organization Type
> Component Type (×) Advantage: Each member is familiar with a specific component. Disadvantage: Integration between components takes a lot of time.
> Functional (√) Advantages: Each member is an expert in a specific function with clear responsibilities. Cons: Each member needs to learn a different technical component.
- About the firefighting team
> Established when there are too many bugs
> Disbanded after the bug is resolved
> Protect team members to concentrate on work and avoid interference
- The test team should settle in the team as soon as possible (project summary)
- The test team should be independent of the development team "Scrum in the Smoke of Gunpowder" And XP"
- the test team should be part of the agile team
Regarding the
project owner and project owner , let's not talk about the definition of a team for the time being, but explain why a team is formed.
In the current software environment, that kind of personal hero rarely happens. The software is getting bigger and bigger, the cycle is getting longer and longer, and more and more knowledge is needed, so it is necessary to organize people with different knowledge together. , work together to complete those large systems.
Note that it is a concerted effort, not a separate trick.
I believe that all programmer friends have seen too many stories of entrepreneurial failures. At the beginning of the business, the founders can do their best, help each other, and work together to accomplish the set goals. Each of them is the owner of the project. , everyone is pushing in the same direction. Just like the picture below. This is a beautiful scene when Group Flow is formed.
But after entrepreneurship reaches a certain level or a certain period of time, the goals of the project are more and more scattered, and more and more things are considered, such as interests, power and so on. The project members will become like the following, do you think they can fail?
I believe that the above situation should be found more or less in the company of your programmer friends.
So, how can we make the team work together and help each other to complete the project?
The author programmer feels that the following are the two most important points.
1. Every programmer is the owner of the project. (The sense of ownership)
2. Each programmer has a clear responsibility. (Sense of Responsibility)
About the project owner
Only when every programmer is the owner of the project, each programmer will do his best to ensure the success of the project like the members of the initial entrepreneurial project. So, in the corporate environment, how can we make programmers friends willing to turn over and become masters? Project bonus? work performance? The author programmer feels that these are important, but not the most important. Just imagine, fellow programmers, what is the happiest moment in your career? Promotion? No! Pay raise? No! Bring the beauty back? Haven't had a chance to try this yet, for now. Judging from the author's experience as a programmer, it must be the moment when the project is successful! It's time for honor! At this time, the bosses at all levels praise the project, just like his son is praised, it is a kind of pride! Is a pride!
As a project manager, you must open your mind at this time, remember and speak out, this is everyone's success, not just the project manager or some core members' success, this is the success of the entire team!
If we go further, the team's pursuit of project success must be accompanied by the pursuit of beauty.
Every successful project is beautiful. Every good design is beautiful. Every good piece of code is beautiful. Every good process is beautiful. Every good communication is beautiful. If the goal is beauty, what difficulties cannot be overcome, what hardships cannot be endured? This is art!
About the person in charge of the project
Since every programmer is the owner of the project, it is natural to assume corresponding responsibilities. And there is a clear responsibility. For example, a specific function point must have a unique owner and responsible person. Then, when there is a problem related to this function point, the team can find the corresponding programmer to seek his help. That way, bullshit doesn't happen in the team.
So, whenever possible, try to organize functional teams, rather than component ones. Because a component-based team requires more communication and cooperation, and it is not easy to set a unique owner and responsible person for each function point, it is more likely to cause disputes, although sometimes it is not the programmer's willingness.
There's no question about team productivity
. Programmers are most productive when they're focused on a particular job and don't get distracted. That being the case, an important role of the project manager is to "protect" team members from being disturbed. So try to avoid the arrangement of Part Time. For the programmers of Part Time, not only the efficiency cannot be guaranteed, but also the sense of responsibility and ownership are difficult to be guaranteed.
In some unavoidable circumstances, such as the sudden increase of bugs in the project, or the sudden increase of support work, which affects the normal development, you can try to establish a "firefighting team" and let these firefighters build outside the team. Get a protective cover to protect your team from interruptions. When the "disturbance" drops to an acceptable range, the firefighting team can be disbanded.
The acceptable range defined by the author programmer is that the feature owner can deal with those bugs and support work, and the development plan (Sprint) is not affected.