Chapter 7 exercise and Discussion of modern software engineering

7.7 migration development method-more agile than TFs

Several software college students came to consult a Chao. The students proudly said that we should use a full set of TFS agile development model development projects!

Really? A Chao cannot believe it.

Classmate: Yes! We need to use five types of work items-task, defect, scenario, risk, service quality requirement,

A: How many practical projects do you have? Oh, none. This is your first practical project. I suggest you forget so many work item types and spend your time writing code.

Classmate: but does the teacher want us to adopt agile development?

A Chao: When the agile mode becomes forced, Where can it be agile? If you are not available, I suggest you use only two types of work items:

• Task
• Defects

Classmate: Chao Zong. I think other work item types are also very useful, such as scenarios and risks-no risk management. How can we get to the CMM Level?

Student: there is also "QoS-Service Quality Requirements". Do you not pay attention to program efficiency and scalability?

A Chao: It seems that you are doing well in reading books, but those types are good, but not directly using these types does not mean that we do not pay attention to them, especially risks. It is also a risk to use all work item types without discrimination in a brand new team. It increases the complexity of the vsts system, increases the difficulty for users (that is, You And Me) to learn and use, and wastes time. The progress of the project may be affected! As for "service quality requirements", we pay great attention to program efficiency and scalability, but we do not have to stick to a specific type.

For small-scale projects, My principle is "going straight to the theme and streamlining the process". What is our theme? Let users buy our products. If users are satisfied with our products, will they care about which types of work items are used in our internal development model?

I personally think there are two different types of things in the project development process:

(1) The tasks to be done as expected in advance. This is a task, which combines the tasks to be done to meet a specific user requirement. This is a scenario and can also be expressed by tasks.

(2) events that have not been predicted in advance but have to be done for the success of the project. This is a defect.

The process of software development is to finish these "scheduled tasks" and "no plans, but what you have to do". Just do it well. After you have completed three or five projects and written more than 10 thousand lines of programs, it is not too late to look at scenarios, risks, and service quality requirements.

Classmate: You are reasonable, but the teacher asked us to use a full set of agile models. What should we do?

A Chao: You can go back and tell the teacher that this is the latest "simplified development mode for migration to mountains", which fills in gaps at home and abroad and is very useful.

After passing the passing away, a Chao thought about it. Why not? The simplified development model may be a good model for small teams.

For example, if we want to design an online auction website, commercial users (merchants for short) can open stores and sell things. General users can browse and shop.

Merchants can log on using our system. This is a scenario or task. We need to drive development and testing based on this:

We plan to implement merchant login management on the network user interface, which is a task.

We plan to implement merchant login management at the intermediate logic layer, which is a task.

We plan to implement merchant login management at the data layer, which is a task.

We plan to test the merchant login. This is the task.

We plan to allow the system to support access by more than 100 merchants at the same time. This is a task and a "Service Quality Requirement ".

In some cases, merchant login fails, which is a defect. We did not anticipate such a problem beforehand.

Under the standard configuration, when more than 20 merchants log on simultaneously, the system response time is slow, which is a defect. We did not anticipate such a problem in advance.

An error occurs when the system uploads an image file. This is a defect.

For a less complex system, the scenario to be implemented in each milestone (iteration) should be measured by two fingers. The scenario is relatively stable and will not suddenly change significantly. For frontline developers and testers, daily dealing with tasks and defects is more important. Too many types will increase management and communication costs. A developer can simply view the "my tasks" and "my defects" searches every day to know what to do today. At the same time, the communication between development and testing is mainly completed through the "defect" type. Management personnel are also very concise in tracking progress and reporting progress. In this case, the "scenario" only plays a role of integration and classification, so that managers and customers can know which functions can be used and which are far from being used. Therefore, "scenario" can be equivalent to "task ". This is what we expected to do.

If "Service Quality Requirements" are added, there are four types of work items that each person in the team needs to access. If the tester finds that some parts of "service quality requirements" do not meet the requirements, we need to reactivate "service quality requirements", create a new "defect", and notify all relevant personnel. Is it really necessary for a small team with relatively concentrated personnel?

It is important to maintain a streamlined process and management method for a new team. As long as the task and defect types are sufficient to solve the problem, you do not have to consider more work item types, but concentrate on developing the project.

 

 

In the process of software engineering development, various experts summarized the principles of Software Engineering in different periods, the following is the software engineering principle proposed by Barry Boehm in 1983 after summarizing multiple projects (each project took about 175000 man-months in total, mainly related to national defense, aviation, and aerospace) [I], compare it with the principles of MSF and agile to see what are the similarities and differences?

Table 7-2 software engineering principles summarized by Barry Boehm

Principles	Chinese translation and Explanation
1. Manage using a phased Life-Cycle plan.	Use a phased plan to manage the process, emphasizing demand analysis and resisting random changes to the project plan.
2. Perform continuous validation.	Continuously check and authenticate to detect problems in the early stage.
3. Maintain disciplined product control.	Adhere to the standard product control-verified procedures or documents can be modified only when the standard process is passed.
4. Use modern programming practices.	Use modern programming methods and tools
5. Maintain clear accountability for results.	Ensure that team members can generate testing and review results in stages and modules, and be responsible for the results.
6. Use better and fewer people.	Reduce communication costs and improve efficiency with fewer and more refined personnel.
7. Maintain a commitment to improve the process.	Continuously collect data and feedback, and strive to improve the process and overall software quality through multiple iterations.

Xiao Fei: can there be a compromised MSF? It seems that it is not easy for a team to accept the "9 Basic Principles" of MSF. Can we implement MSF at a discount? If so, how should we implement it?

A Chao: these principles are mutually dependent and mutually reinforcing. If only the 50% principle is implemented, it may only serve as 10%. But you don't have to worry about it. As long as you start to change and often sum up, it is a good thing.

Xiao Fei: the more fully authorized and trusted the team is, the more unconscious the team is. The code written in the result is perfunctory (many teams in the university are like this ), do we need any incentive mechanism to promote it, or do we have to rely on the personal consciousness of team members?

A Chao: Let's ask what is the commercial value of this project? If this project has no commercial value, I think you are also embarrassed to copy the commercial software practices. However, this project may be of great value to individuals (improving the value of personal technology). Those who are motivated to exercise themselves can be self-driven and deserve "Authorization" and "trust ".

Xiao Fei: What I know most is: "If you ask a technician, the technician often tells you with disdain-open the" tool | option, under an "Advanced option", modify a parameter. Some technical staff, especially developers, of the mountain company, even have some scornful eyes. Refer to this news (Beijing prohibits salesman' from looking at the customer with contempt) [II], I made a bold suggestion: "moshan prohibits developers from scanning testers with a contemptuous view "!

Daniel: I agree, and I want to extend it to "prohibit developers from looking at non-developers with contempt "!

JELLY: "eliminate numerical goals, numerical quotasand management by objectives. substitute (that with) leadership ", which means that (in the Team) the goals and shares defined in numbers should be eliminated, as well as management principles based on class goals. We should replace it with leadership.
Does this conflict with the requirements of "quantitative management" level?

Erzhu: Software Engineering refers to some fantastic concepts. The professional terms of the mouth, coupled with complicated processes, are actually not that difficult to do software, it mainly relies on the cultivation of programmers and the quality of completing their work.

What do you think of the two pillars?

[I] paper information: seven basic principles of software engineering, Barry W. Boehm, link: http://dx.doi.org/10.1016/0164-1212 (83) 90003-1

[II] http://news.sina.com.cn/c/2006-11-30/202110650498s.shtml