A Preliminary Study on the "minimal mode" of software development and teams: 2-6 people model (I)

Six-person Model

In the previous article, we talked about "2 main lines and 4 steps". As a matter of course, my software development team's "minimum model" is a six-person model. Before launching the six-person model, I must clarify the following points as the general principles of the six-person model:

L first of all, the reason why I want to use six people instead of six roles is to imply that I think six peopleIndependentBut opposed to merger and part-time jobs (although I have some understanding of part-time jobs-please refer to the following chapters: King Kong fit and giant shoulders ), in my opinion, six people do not have to participate in the whole process, but do not combine them into one.

L six people are the smallest model,6IndispensableThe lack of one that hurts the foundation of the software quality, or that the software quality will fall below the limits I can tolerate, but whether it meets my quality standards is not equal to the software success standards, this requires a clear understanding.

L six people have their ownProfessional fieldsThey have their own unique directions and skills. Maybe our team could not find 6 absolutely appropriate people for the moment, but we must admit that this is our direction.

Which 6 people are there? What do they need and do?

1. Managers

2. Architecture

3. Demander

4. Designers

5. Encoding

6. Tester

Manager

A team leader who follows the main management line and leads the ship.

Managers need software project management skills.

Is a manager "idle"? The answer must be no. We will not talk about the nine fields and five links of PMP, nor will we talk about the long articles of CMMs on various management, I pointed out four things that I think managers have to do. Let's see if we need this manager.

1. Time Management: plan to tell everyone what to do, supervise and understand what everyone is doing, and check to ensure that everyone's work has been completed. Tell me, if there is no manager, who knows what you need to do, how much you do now, and when you will do it in the future.

2. communication Management: software development does not exist independently. There are more customers who have requirements at any time, and there are expectations that will always be higher than the actual senior management. Every day, there are different people who want to know, exchange and change the content and process of software development. Are these communication work suitable for those who are willing to develop with headphones.

3. team Management: three members form a party and four members form a group. The human problems are always more complicated than the code. No matter how you organize a small dinner, you can solve everyone's troubles, the presence of a facilitator is always required here.

4. risk management: Are there any risks in software development? Are there any software products that no one can believe and have never completed on time; so who will lead everyone to plan ahead and make all preparations before the risk comes, minimizing the impact of the risk, can only be managers.

Architect

A team leader following the main technical line, the software development is still technically active, and the technology level determines the software level.

Architects must be proficient in project-related technologies, have considerable application experience, and be able to select and control relevant technologies to provide reasonable solutions for the project. The solution is traceable, executable, and trainable.

First, architects need to know a certain number of related technologies in this field to facilitate selection based on different project requirements, and architects need to have enough technical reserves.

It is not enough to choose the technology. The framework should have a certain degree of confidence in its enforceability, and neither of them can afford to be the best choice of others? The most typical Architecture joke is that everyone is willing to give full play to their own architecture. If everyone is not thorough enough to use a framework, why can't you digest it first, this allows you to avoid detours and reduce quality loss. If someone has a better understanding of the architecture than you do, then why do you want to be the architect.

The final architecture should not only consider implementation, but also extend attributes, such as performance, stability, and concurrency. This requires accumulation, rather than one day.

Demander

Demand is the reason for the existence of the Software. satisfying the need is the main criterion for the success of the software. The demand is the source of the original demand, which is organized and abstracted to become the demand of the software.

In the six-person model, managers should be completely non-technical personnel (although many managers were born with technology, they have almost no technical functions in my model ); the demander is half-open. Why? The demander has two stages.

L requirement mining-Customer communication

L requirement development-System Analysis

Requirement mining requires communication and logic capabilities.

System Analysis requires logical capabilities and software design, analysis, and technical skills.

The requirement personnel need to mine data from the customer side (please note that it is not just a record, because many customers do not understand their actual needs), and then abstract, analyze and design a prototype of software, provide the designer with a pre-range. At the same time, the demander must, with the help of the constructor, ensure that the software system is built on an executable technical architecture based on its own technical skills.

Designer

The creator of the final form of the software, as well as the requirement supervisor and coding instructor.

With the specific design ability of the software, he is the follow-up and refinement of the system analysis, but why not let the demander further refine the design, I will say later: If there is no designer, the design will not disappear, it is to transfer to both ends of the requirement or development. Generally, it is to transfer to development. What problems will occur when the design and demand or development are merged? This will be explained in detail later.

Many companies' beauty unions become implicit software designers, which makes sense, because interfaces and human-computer interaction are indeed the most critical part of software design. However, I think it is best for designers to have a certain technical background. Designers without any technical background will bring great troubles to developers, therefore, it is recommended that the artist call the API only as an external resource of the designer.

Encoded:

The final implementer of the software.

I will not describe the capabilities and transactions of the coders here. Everyone is familiar with development.

Tester

The patron saint of software quality, requirement, design and coding supervisor.

It can be said that even if the demand-design-development process is impeccable, the tester's role still exists. The demand verification from different perspectives plays a role in determining the quality of the software. Moreover, the impeccable development process is more like a myth, isn't it?

Testers need to have test-related tools and methods. Their primary responsibility is to verify the consistency of requirements. However, they often participate in technical correction, if this happens, they are even more indispensable, because without them, what will happen to the quality of the software?

Software team standards and Defects

From above, we can draw a software team standard:

Managed?

Is there a specific architecture?

Is there any professional personnel?

Are there any middle-level designers?

Is there any development? (this will not happen)

Is there any final line of defense for testing,

Let's take a look at the basics of a software team.

 

These conditions greatly affect the quality of the software and the success or failure of the project. If these standards are not met, will the software be unable to be carried out? This is not exactly the case. In addition to development, the software can be completed in the absence of five other people, because software development is a magical activity. Please refer to my introduction to my software and team path. What are the defects caused by the absence of any one, please let me break it down slowly:

Unmanageable: the entire development process is out of order. The development team is not controlled and difficult to understand. It is difficult to understand the project plan and progress, and there is no information output. Most risks cannot be avoided or mitigated, various team conflicts are hard to resolve.

No architecture: the technical risks of the project are unknown, and it is easy to enter the technical minefield. Even if it is barely used, it is easy to leave hidden risks. Every developed technology cannot be unified, leading to chaotic project technical choices, even if you are lucky enough to complete the project, it will take a long time to maintain the project. Finally, the team level will never improve.

No requirement: the software will be lost in the developer's self-imagination, and most customers do not have the habit of confirming the requirements. Everyone wants to finish watching it and then change it. The final result is, as a result, the development result is greatly deviated from the customer's expectation, a large number of modifications and rework, the cost time is increased, and programmers are under endless pressure. As a result, the team is stuck in the quagmire and eventually collapsed.

No design: The design is often completed by actual developers alone. The quality and content of the design are completely determined by the individual, the quality level, and the design standards cannot be unified, so that the project has different styles and flaws, although it may not hurt the root cause, it is difficult to name it professional. In addition, development and design are mutually exclusive, and complicated design will inevitably lead to development difficulties. Most developers tend to take advantage of personal technical weaknesses and technical difficulties and simplify the design to relieve their own pressure, this results in the design requirements to be subject to the development requirements and put the cart before the horse.

No development: it is very clear that this is impossible, not to mention.

No tests: the wise may think about it, but there is a loss. Even if the developer has strong self-discipline and self-check capabilities, it also requires the support of an reviewer. Besides, a team that does not even have a test is required, its self-discipline and self-check capabilities are not optimistic, and most of the outcome of no tests can only be hundreds of errors.

 

The following chapters will be introduced one after another:

King Kong fit and giant shoulders: discussing some rights and interests of less than six people and my views

Simple team building guide: around the six-person model, we can imagine building a simple development team.

The six-person model is just a start: Conclusion and some thoughts.