Reflection and Summarization on the alpha iteration of software engineering

Reflection and Summarization on the alpha iteration of software engineering

The software engineering of the A-round iteration, we set out a very small problem. As a team, our team had a very serious situation, so that the teacher felt that we were out of control. So I wrote this article, to reflect, summarize and improve. This article is divided into three parts, in the first part I will explain some of our processes during development, the second part I will analyze the causes of the cause, the third part I will describe our next solution. Finally, there is a little reflection.

First, the occurrence of things

At that time we team relatively late, originally wanted to break up the points to each team, and then just have classmates no group on, the teacher put our remaining these people set up a new group. So we lacked group at the beginning of the team.

Then we have a group that is formally composed. In the beginning, the group can also maintain a period of communication, really started to do, the college's laboratory has a very urgent project, the need for our main developers to complete, and help him out of all the subjects of the class time. This made him unusually embarrassed in the first round of iterations. Go to the lab during the day and come back at night. Software Engineering team Development is also considered, slowing down the progress of the whole team slightly. But the other classmates have no matter, but also did not fill in his position. Everyone's enthusiasm for the project is not very high, I do not finish the task to go to the leisure and entertainment things happen.

The biggest problem is that our scrum meeting didn't write well, which allowed us to lose dozens of points in each of the first iterations.

For these questions, I will analyze them one by one. Do not evade the problem, to find out the real solution.

Two Problems and Causes

Team mode:

Zou teacher in the "construction of the law" has been divided into the team cooperation model swarm model, attending physician mode, star mode, community mode, secret Team mode, etc., our team belongs to the attending physician mode, there is a chief programmer, the rest of the people are to serve him:

in such a team, there is the chief programmer (Chief Programmer), who is responsible for the design and coding of the main modules, and the other members support his/her work from various angles (backup programmers, system administrators, tool developers, programming language experts, business experts).

This model is a good generalization of our problems. In our team, only one person understands all the schemas of the current code. This has led to the inefficiency of other helper programmers.

At the beginning of the project, we designed the model as a functional team model. Like most teams are divided into PM, backend, frontend, UI and so on. But in the end we didn't have the control.

In agile development, we mainly take personal communication as the main, and the development staff work together. This is in line with the principle of agile development, and the fact that we don't have enough communication is highlighted. This is a big taboo for agile development. This is partly because we have also violated a principle:

" With aggressive people as the team for the project core, full trust to support them. "

Due to the absence of one of our main players, this greatly not only slowed down the progress of our team (because there were 3 people writing the code, but also absent a main force at this time), the more prominent problem was that the rest of the developers were stressed.

Agile Development:

The next step is to talk about our major mistakes in scrum meeting.

There are many kinds of software development processes, how do we measure whether a development process is appropriate for the current project/team? I think the key to the successful implementation of Scrum/sprint is scrum Master. I've heard that some teams are also implementing scrum, but they randomly pick a member to do Scrum master, as if scrum master were to greet everyone in a meeting and keep track of everyone's progress, which is a great possibility of failure.

I have to say, this is our big mistake. Our scrum meeting was not released on time, leading to a lower score for the team, and several members of the group were not responsible for the problem, so let me say:

1. When assigning tasks to separate PM and blog tasks, my heart is to balance the team contribution value, can let our group members score very small. In fact, I was reading this sentence:

Scrum Master not an official, but a non-power communicator, just like Microsoft pm, he/she also has to do specific work in the team. Most of the ways to turn the original "manager" into Scrum master won't work.

Now the facts tell us: PM and blog can not be completely separated. Otherwise there must be a problem.

We also have a problem is four days before the end of the iteration, and the teacher through the mail to explain the lack of our blog, said to fill in time, but the same night our team members have been developing, in a moment to forget about this matter. The last Scrum meeting failed to fill up.

1. The second is responsible for the blog of the students of the big mistake. At that time assigned tasks, her task is responsible for the blog, we ask her to pay attention to the dynamics of teacher Luo, not all the information to find the development of the students want to put the blog in the group to write well. But she didn't update the team's blogs in a timely manner, such as feature descriptions and meeting minutes, which resulted in the persistent non-renewal of our overall blog. I think, if you can read the teacher's blog in time or timely class, you can know the teacher's reminder, will not have such a big problem.
2. The third issue is PM. In fact, we in the first half of this round of iterations, is basically in a no-PM state. We found this problem before appointing a person for PM. Ordinarily PM must remind all personnel of the progress, but PM body and number of jobs, really can't in balance all tasks. There are more deadly reasons for this problem, and I will analyze it later.

To summarize briefly, our team members did not meet the requirements for Agile development: self-management, self-organization.

Self-management: The previous leadership assigned the task, we can do it, and now we have to pick the task, each sprint after the end of the summary of deficiencies, to propose improvements, and to implement these improvements on their own. "Self-management" does not mean "no management".

Self-organization: Before doing their own things good, feel relieved to work. Now everyone is going to be in charge of the project, someone is lagging behind and helping him improve, and the project lacks a certain kind of resources to top up.

This happened to the team, that is, "positive is not high." We are not actively engaged in this matter of passion, for the team to give the task is not actively completed. For example, if students can actively come to the code, the knowledge we share to learn completely, blog students can take the initiative to find developers to today's progress. The students who are responsible for assisting the chief programmer in writing code can take the initiative to reduce the burden of the chief programmer, which is a place of "autonomous" control, where we are not in control.

Development process:

The development process for our team is:

Identify software requirements <-> Analysis <-> Programming <-> Coding <-> Testing <-> release. It is basically a variant of the Waterfall Model (Waterfall), and it is not as cumbersome and agile as the Unified process (Rational Unified process), and the documentation is not very complete. In the overall process is generally good, but there are some technical suspended, that is to understand the overall structure of the people only one, the other people are to assist him to achieve specific modules. The reason for reflection now is:

The interfaces, inputs and outputs between the product modules can be well defined and validated in a formalized way.

The technology used is very mature and the team members are familiar with these technologies.

On these two points, we are not doing enough. Our development is a person responsible for a module, architect president of these modules. So only one person is familiar with all things.

Now it's time to mention another big problem with our team: not enough hands. Our international students are very good attitude, some of the tasks assigned to him will agree, just-because of insufficient knowledge accumulation or other reasons, their output is really limited. Most of the things are done by another five members. Of these five people, one person is responsible for all the testing work and one person is responsible for the blog. All development code is completed by the remaining three. That is to say, there are only three developers in our developer. There is no doubt that we have a big disadvantage compared to other groups, because it gives developers a lot of pressure to get 3 people to cope with 5 people. Even if the other players have nothing to do, they will not take the initiative to do something to share the pressure. This is a manifestation of our disunity, enough to warning us. This also stimulated us to solve these problems, improve the development of the group, so that the whole project can meet our expectations.

However, we also have a lot of good places to do and it is worth continuing to develop:

1. Sense of responsibility and mission. When the development time is tight, the task is numerous, we still completed the task. One of the major contributors to this is PM, he wrote a lot of code in the absence of the development of the main, so that we in the sprint phase of a development team less than the case, still completed the initial interface tasks. Remember that night, 2 o'clock in the morning he to the absence of the development of the main force QQ, said we have some results, I see the results, or for his efficiency, because we are starting from scratch to learn Android, and he only spent 6 hours to write a lot of structure and interface. I got a lot of help from him the next time I took over. This time our team in software Engineering's a-round iteration to achieve the intended target, and he has a very big relationship. We still work overtime after I come back, until we finish our goal of a round.

2. Bigger picture the global. When the problem comes out, the team's first thought is how to solve the current problem, rather than the first to pursue who's responsibility. Of course, because we are performance distribution, all will take into account each student's team contribution, do not let the students disappointed. For the students who work less, must be in the second round to do more work in the iteration, or even if it is difficult to get the score they want. Of course, our responsibility is not enough to emphasize, so that some students want to water over. In fact, our task is very big, we need everyone to work together.

Finally we want to say to the teacher, we do not give up, not out of control, we have not interrupted the development of software. Maybe there was a problem in the team, but it was not a waiver of hope. The results are painful and difficult to accept, so I will do more work to improve the overall team performance. We have always been proud to be able to learn real software engineering.

Three What to do to improve

Just now, we have done a deep dialysis on the problem of the team, which in my opinion basically intensifies all the potential contradictions. Makes it possible to analyze our causes more thoroughly. The following should be the process of our healing.

We should make the following improvements in today's tricky situations:

1. We recognize the importance of having a strenuous efforts pm, and in the second round we will appoint a full-time PM to take control of the overall situation.
2. To improve the overall team membership, we need to introduce a classmate who can write code in the second iteration, so that we have 4 main players to develop. This will greatly speed up our progress. Solve the embarrassment of our lack of code force.
3. Increase the enthusiasm of all members. This is not easy for us to work, because we also have a compilation principle and database work, so we must come up with results, timely broadcast results, so that the team has a sense of accomplishment, it naturally has a team of centripetal force. The task was handed over to Huang, who was to drive the whole atmosphere.
4. Perfect e-r diagram, clearly stated the logic of the code, convenient for later students to get started quickly. This matter was mainly given to Chi Qiang, because now he is only familiar with the whole structure.
5. Strictly enforce the performance system, want to score must have positive contribution to the team. To prevent us from being understaffed, so that all students can join in the development process. Each task has task points (Mission point) to mark, and the score is then assigned according to the weight of the task.

Four Finally, say a little more about the proposal for software engineering.

Zou's original intention is to introduce the company's software engineering, which gives us a very different perspective, let us recognize the development of the big company is what it looks like. But companies and schools are not the same. There is no way we can build a system that motivates players, nor can we really make a substantial penalty or statute for some of the players ' actions. Consider the relationship and the impact it brings. All of these differences can affect the team's operation.

Therefore, in next year's experiment, some relative approaches to these problems may make the whole course more perfect. Thank Roger Teacher for our care, understanding, reminders and support, but also thank Zou teacher to bring us close to the real work experience, we have learned a lot of things in this round of process. I hope our team can actively face the next challenges, overcome the difficulties, laugh proud of the wind and rain.

Reflection and Summarization on the alpha iteration of software engineering