[Beta] M2 Post-mortem analysis

Plan

Did you finish the work you planned to do in the end? If there's anything unfinished, why?

A: No, all functions are not implemented. Among them, the interface is two, the logic of the alarm clock logic and group logic, it can be said that these things are one of our core functions, missing their impact on our entire team is very large. The reasons are complicated, but the main reason is because of heavy schoolwork pressure and "omission" mentality.

Did you find that you did something that didn't seem necessary or valuable afterwards?

A: Re-detect the backend and reassign the task. It turns out that we should have a training first. The technical fault has arisen, making the members very hard to follow. The variety of statements on the Android platform once again brings trouble to program writing. In addition, we generally think that compiling is more important, there is a kind of escape mentality.

are deliverables clearly defined and measured for each task?

Answer: Yes. Each task is clearly defined and delivered, but the handover is difficult and there will be a variety of problems in the handover. Documentation and learning methods, addresses are not defined, which is one of the reasons why we do things very difficult. "We must first find the right way to learn, standardize the entire project" If you say harvest, this is one of the most rewarding things I've learned in this iteration.

If the whole process of the project is going according to plan, what are the risks that were not estimated at that time, and why not?

A: The whole project was completely out of the plan, and as planned, we could do most of the work on December 28, but in fact, we had a small and insignificant amount of work before December 28. In the beta iterations, we encountered a lot of tests or sudden interception of large jobs, which slowed down our overall progress.

Is there a buffer left in the plan, and does the buffer function?

A: Our buffer time is 1.1 to 1.7 days, but it turns out that this buffer does not play a role in buffer. In the middle of December, when all the subjects were in a big job, the 1.4th compilation exam also made the idea of a buffer period obsolete. In fact, after December 20 we have ushered in the compilation of curriculum design, mathematical modeling papers, database curriculum design, buffer does not work.

What changes will be made to future plans? (example: definition of buffer, overtime)

A: There is no next iteration of the plan, assuming that there is a third round of iterations, will be the first to organize ideas, assemble the team. Write documentation and learning materials. Otherwise the progress will be very difficult.

What have we learned? If history does it again, what improvements will we make?

A: The main thing to learn is team management. For example, how to mobilize the enthusiasm of the team members, how to estimate the project itself, how to deal with the members of their own things and the relationship between the task, and so on. If I do it again, I will improve the overall team's staffing ratio and generate several skilled code engineers to implement the functionality. Then write the design documents and declarations for the entire team project. Also write a learning document for all team members to promote themselves.

Resources

Do we have enough resources to do all the work?

A: For our group, the most valuable resource is time. Time is not enough. And the rest of the hardware or software, our resources should be more abundant, it may be our entire team project needs too little resources.

How is the time and other resources required for each task estimated and how accurate?

A: There are a lot of courses in the beta phase close to the deadline, time is tight, we are also very nervous, sink to develop soft workers. So we have a lot of time to decorate, but we have a problem: there is no time for enthusiasm, agitation to be motivated there is no time. It's a real knot.

Is the test time, manpower and software/hardware resources sufficient? Do you underestimate the difficulty of resources that do not require programming (artwork design/copywriting)?

A: sufficient human resources. I did not notice the previous question, did not find human resources is also a resource. We need 4 skilled Android developers who can develop quickly, yet our team members do not. For UI and copywriting, we don't underestimate the difficulty or overestimate the difficulty. We are still full of confidence in this respect.

Have you ever felt that what you do can be done by others (more efficient)?

Answer: Yes. My interest in Android development is not very high, and I have suffered a lot in the search for APIs and test APIs, so it's extremely inefficient. And in fact, we can do the system development program The number of apes is very small. However, my work also needs to be done. So I can only harden my head.

What lessons do you have? If history does it again, what improvements will we make?

A: Do not have heroism, do not blindly self-confidence. You have to understand that what other people can finish in 5 days you can't finish it all day, learn to use the strength of the team, learn to mobilize the overall enthusiasm, which is very important for a team.

In a word, in the team, to take advantage of the strength of the team.

Change Management

Every relevant employee is informed of the change in time?

Answer: Yes. We will be notified in the group, but occasionally there will be less communication. But that's a bit rare.

What do we use to determine the "deferred" and "must do" functions?

A: The main point is to look at the killer advantage of their own procedures, can realize our killer advantage is of great significance to us. So when a killer advantage is in trouble, we postpone the rest of it to him.

Are the export conditions of the project clearly defined?

A: When stress tests and compatibility tests are complete and the two tests are basically no problem, we think we can release them.

Can a contingency plan be developed for possible changes?

A: Generally speaking, if the problem is very large, we will put aside the rest of the work to do him. If this problem is not important, we should give it up directly.

Are employees able to effectively handle unexpected job requests?

A: No, everyone is very important to their time management, so generally do not agree with the work request outside the plan. But reasoned, this semester everyone is really tired, tired to every night without strength, who do not want to do something. I can understand this matter.

What have we learned? If history does it again, what improvements will we make?

A: Actively understand the life of the team members, and then try to take everything to a good place to guide, although sometimes may not be able to do, but also have to try.

Design/implementation

When and by whom is the design work done? Is it the right time for the right person?

Before the start of the second phase, everyone had a meeting to discuss the function, progress, and possible problems of our second phase, and then we assigned a plan that was mostly discussed by everyone and the time was right.

Is there any ambiguity in the design work, and how does the team solve the problem?

No, our task is written in a very problem-oriented, telling you what to solve a problem.

Does the team use unit test, test-driven development (TDD), UML, or other tools to help design and implement? Do these tools work?

The tests did not work well enough, and a part of the unit tests were used, with no significant effect.

What features produce the most bugs and why? What important bugs were found after the release? Why didn't we think of these when we were designing/developing?

User part, this part has a lot of bug, this is the reason that we haven't paged up to this. Because in the beginning did not think good push how to write, wasted a lot of time and no gain. This type of problem may arise because you do not practice it yourself.

How does code Review work, and do you strictly enforce code specifications?

Most of the code is code-compliant, and not all of them are strictly executing code specifications. Code review by the test of the classmate yellow to see, however, there is still a part of the lazy change. That's what we did bad.

What have we learned? If history does it again, what improvements will we make?

Design phase we made a big taboo: think too good, do too little. Many things can not be timely follow-up, perhaps due to the enthusiasm is indeed not high.

Test/Release

Does the team have a test plan? Why not?

According to our plan, we have finished writing a function to be tested by testers.

Is there a formal acceptance test?

Not fully completed, all acceptance tests were not carried out.

Does the team have testing tools to help test?

The main is Vs's own module and plug-in.

How does the team measure and track the performance of the software? Is it useful to see how the software actually works? What should be improved?

This part we can say not much, because the whole software is not fully implemented, empty talk efficiency is just an armchair, no meaning.

What unexpected issues were discovered during the publishing process?

No new version was released, so I can't answer this question.

Summarize

What grade do you think the current state of the team belongs to in Cmm/cmmi?

A: I think the current state of the team is defined level, there are standard documents for maintenance, but there is no strict code review process, team collaboration is more coordinated.

Which stage of the budding/running/spec/creative stage Do you think the team is in?

A: I think our team is currently in a running-in phase. The whole team still can't get together, federative.

What do you think the team has improved in this milestone compared to the previous milestone?

A: The improvement is we introduced a code great God, better communication and development than the original team. Have to say a self-motivated, not afraid to pay the teammates really is really important.

What do you think is the most necessary improvement in the present?

or the overall degree of completion. We have a low level of completion, we are not very motivated to learn and work, which is also a more sad place to us.

What have we improved compared to the alpha phase?

Learned to use Git to manage projects, publish tasks, and generate Burndown charts.

What characteristics do we maintain compared to the alpha phase?

Maintaining the thinking and real-time improvement of the project also preserves our original idea and killer advantage.

[Beta] M2 Post-mortem analysis