"Alpha phase" M1 post-mortem report

Design / Implement

If history does it again ,  What will we do to improve ?

1. in the initial design, as far as possible to prepare enough to avoid the occurrence of a large number of invalid tasks

2. use TFS for source control or GitHuband use less QQ Inter-pass files

3. start on the front and back of the workload estimates error, repeat for the front and back of the division will be adjusted

4. attach importance to code specification

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

Designed 3 days before the first week of M1, it is completed by the project experience and the most experienced PM Canhold of website Development. The team thinks it's reasonable.

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

When TFS formulates and establishes tasks, there are ambiguities that are an important reason for the project to produce invalid tasks. Worse still, the team did not attach importance to the TFS task, causing the Burndown graph to deviate from the actual.

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

Design: The team borrows the E-r diagram to model the backend model layer design, which effectively pushes back-end database establishment and backend Dev to understand the project.

Implementation: Borrowing API documentation to standardize the front-end interface to enable front-end interaction. It effectively reduces the coupling between the front and back end work, and improves the project efficiency.

What features produce the most bugs and why?

editing, uploading and displaying of articles.

Reason: The function is more complex, the front and rear side are involved more, the interaction is also more, and the technical details are difficult to deal with, the implementation encountered a lot of bugs and difficulties.

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

The backend has a code review but does not have a rigorous set of processes, just verbal communication between backend Dev and a cursory review.

The code specification does not M1 well, and is not taken into account when it starts planning.

Resources

If history does it again ,  What will we do to improve ?

1. start setting up work together to discuss what tasks to complete, specific to each person's head.

2. Learn the testing mechanism of front-end development.

Do we have enough resources to do all the work?

Our resources are plentiful, and we are able to find detailed learning materials on the front end of the web, and we have an open source code framework for our use. On the server resources, the resources of the school and the resources on the net are enough for us to use. Material collection is also very easy, through Baidu Search can get a lot of relevant material.

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

Estimated time is mainly through the PM to estimate, because the PM to the technical details are not much, so the accuracy is low, often will appear to do the task does not know which should specifically correspond to a specific task on TFS.

Is the user testing time, manpower and software/hardware resources sufficient?

The front end did not do a special test, and then spent about one-third of the time to test, manpower, software, hardware resources are sufficient.

Do you ever feel that what you do makes it more efficient for others to do it?

Our division of labor is relatively clear, we have done better, not suitable for replacement tasks.

If history does it again ,  What will we do to improve ?

1. Use GitHub to manage the progress of our projects and ensure that everyone gets the information in sync.

2. Weekly meetings are more nuanced and anticipate possible contingencies.

Change Management

Every relevant employee is informed of the change in time?

We are mainly through the QQ group of our project to pass the change of news, because we have a lot of people near the dormitory, the notice is also very common hanging dormitory. And our brief meeting every Monday night.

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

According to the specifics of our project, our Prime Minister will implement the basic functions of the project. The main functions of our project are as follows: Activity viewing, event publishing and editing, personnel registration activities, list of participants in community management activities, and related registration login. The completion of these features already have a community management platform look like these are our "must achieve" function, the rest of the relevant functions, can be gradually added in the beta phase.

Is there a clear definition of the export conditions of the project (exit criteria– What is "done")?

Since our alpha phase is made up of only one web-based platform, the direct effect of "doing it" is that all functions and typography on the Web page are capable of achieving their proper functions, which is also a good test. After the page is integrated, it can pass various tests, so it is "done".

Can a contingency plan be developed for possible changes?

Basically no, there are a few emergency situations that our members stay up late to remedy.

Are employees able to effectively handle unexpected job requests?

Although Dev's experience at the outset is insufficient, but in the lead of experienced pm, every time an unexpected job request, PM will come up with a workable solution, so that dev to save a lot of effort, and from the results, the unexpected work of the situation is still good.

If history does it again ,  What will we do to improve ?

1. with Git , with Git , with Git , the important thing to say three times, everyone unified on a server to change the code is too painful. Although we try to stagger the file staggered time to modify the code, but still appeared a lot of two people after the modification with Filezila at the same time upload led to cover the problem, thanks to the time when two people modify the part is not too much, so has not caused greater impact, But this situation is really to change!!

Test/Release

Does the team have a test plan? Why not?

The team has a clear test plan. Back-end testing is mainly written unit tests, functional tests and stress tests.

Front-end testing is primarily a scenario test and testing in different browsers and environments.

Is there a formal acceptance test?

The back-end test completed the unit and functional test modules, and the stress tests were not implemented.

The front-end test plan has been completed and accepted.

Does the team have testing tools to help test?

Back-end testing mainly uses the unit test module that comes with rails to write unit and functional tests.

Use the Fiddler4 tool to test the appropriate API logic to check for incoming requests and returned responses.

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?

Before the performance test we did not consider, mainly because of limited time, so only a few basic tests. To performance testing and load testing will be done in the beta phase, for performance, our team plans to increase the number of servers, logical computing and data interaction separate, and thus improve the responsiveness of the server. For the load side, our team intends to use the database instead of the MySQL implementation and improve the backend rails framework to be accessible in parallel.

What were the unexpected issues that occurred during the release process?

The main problems encountered during the publishing process are some problems with the interface display bugs and front-end JS code logic, which causes some buttons to function properly. All these problems, we have made corrections in time.

"Alpha phase" M1 post-mortem report