M1 Stage Post-Event Summary _

The development of the M1 phase is over. Our efforts have been due in return, below we will focus on some of the issues arising from the M1 phase analysis and reflection.

I. Vision AND OBJECTIVES

1. Our app is more like a "know" app for students in Beihang University. The app provides basic functionality: User management, search, categorization, upload and download, user contributions and interactions.

2. In the alpha phase, we use the first week of time to interpret and analyze the code of the seniors, and to develop plans accordingly. We think that the time to make the plan is very ample, but due to our inexperience, there are some problems in testing the functionality of the original site, resulting in the late modification of the original code of the bug occupy too much time.

3. As there is only one person in the team who really did the development of the Android app, there was no disagreement about how to make a general plan. When other issues may be encountered in the development process, the team's core technicians will give different solutions depending on the situation. We have been in a multi-communication, multi-communication development model, which I think is one of the important factors for the team to be successful in the alpha phase.

First of all, since our search function is officially completed today, the application has not been put on other platforms to promote, so the number of users is relatively small. But when we use the alpha phase to test the results, the basic functionality is already available. This also shows that our one-month project development was successful despite some twists and turns.

If history starts over, we may start by calling four members of the group to focus on fixing bugs first. Our team is very strong, but it also took nearly 10 days to repair. If the first four groups of students to discuss the analysis and modification of the bug, maybe we will do better.

Two. Planning

1. Our original plan is to initially implement the basic functions of the Genius website, in fact, after nearly one months of team members have stayed up, we have actually finished.

2. One months of development time, each person is doing their best to do everything. We only found some of our own shortcomings in the process, but we have not found out what has been done.

3. When not familiar with the project, everyone is groping to try not to dwell on the details, only to make a general outcome, in the beta phase to continue to repair.

4. Project planning is the first week to interpret the code, the second week and the third week of software development, the fourth week of testing, of course, this is a very ideal state. But in the process of development we encountered two big challenges and disrupted our plans. The first challenge was to test the original code and find bugs that made our project almost no progress within 10 days. The second challenge was to find a major problem connecting the database at the end of the third week, and it took us nearly a week to adjust it to solve the problem. The reason, or the experience of our development projects is not enough to think of all aspects of the problem. But this has also become a lesson in our future project development.

5. A buffer time of about three days was planned, but after a succession of two challenges, our buffers were gone. Fortunately, the team members of the technology is very strong, this will allow our software to release on schedule.

6. For nearly one months, the team spent about 5-6 hours a day on the project. The core technicians have an average of nearly more than 10 hours a day, far exceeding the working hours we planned. Because our software already implements basic functionality, the main task of the next phase is to fix bugs.

Three. Resources

1. The strong ability of our team members is the most important guarantee for our project to succeed in the end. At first, we probably underestimated the difficulty of the project, and the problems we encountered later were a big hit.

2. The initial allocation of mandates was discussed by the core technical staff. During the development process, PM is allocated according to the daily workload of each person.

3. We have done a simple test in the development process, because there are indeed more bugs, we intend to do more detailed testing in the beta phase.

4. We discuss each person's strengths before the start of the project, the technology can not be hard to write documents, strong technical ability to lead you to overcome a problem.

Four. Change Management

1. We set up a QQ group at the beginning of the project, so that we can communicate at any time. Because there are two girls in the project, can not meet with boys at any time to communicate, so QQ group communication is extremely important.

2. Because the basic functionality of the software is determined, we determine whether a feature is deferred or must be implemented around the basic functionality. Functions related to basic functions that affect the alpha phase results must be implemented.

3. We determine whether the export conditions of the software are based on the ability to implement basic functions and, if so, can be published.

4. For some of the problems and challenges we have encountered before, we have met to discuss solutions in a timely manner. Because in the project, we set up two people on the front end, there are two people on the back end, and a mobile staff, the relative ability is stronger, can handle some emergency events at any time.

5. From the inception of the team to the present, none of us have given up on our work because of slacking off, and everyone has almost 200% enthusiasm to deal with the project. Unexpected job requests occur on a daily basis, mainly because there are too many problems in the original code, so that in the process of development, it takes more than one time to repair, rather than to create.

Five. Design/implementation

1. The design work was completed by the team of people familiar with Android application development at the end of the first week of the project. Because the first week of the meeting is planned to look at a week of code, in this week's time we help each other to read as much as possible code, and then development. Our project may not be designed to take too much effort, we need to consider the division of labor for everyone.

2. The design phase did not create ambiguity.

3. Due to the very long development time, no in-depth testing has been conducted and will be carried out in the next phase.

4. During the testing phase, it was found that there were a lot of bugs in user management and searching for two parts. Mainly because these two parts of the original code is almost empty shell function, the team's two people are responsible for these two parts respectively. It's very difficult to deal with so many bugs in less than two weeks.

5. The front-end backend has two developers, and a mobile developer can review the code at any time to identify vulnerabilities.

Six. Test/release

1. Initially we did develop a test plan, which is expected to take place in the fourth week. However, the development did not end in the fourth week, and some small tests were done during the development process, so the final plan was not implemented.

2. No formal acceptance tests have been carried out for the time being.

3. The release process due to the release of the platform account to be audited, the test platform account also to be audited. So we only released our alpha version of the app on Baidu's web disk.

After a budding and running-in phase, I think our team is moving towards the normative stage. At the end of the M1 phase, we saw the return we paid and completed the planned plan.

In contrast to the principles of agile development, I think our team is best placed to "be motivated to be the core of the project, to fully support the trust of them" and "face communication, both inside and outside the team, is always the most effective way to communicate." I think we will finally be able to develop in a limited time a function of so many applications not only in the core of the project's technical ability, but also because of our full trust and frequent communication. Imagine, if we do not understand each other in the development phase, communication, in the event of a bug when there is no communication, but blindly self-instead focusing, perhaps the release of software will be delayed. In the next stage, we will continue to maintain our passion and responsibility to meet other challenges!

M2 phase of the plan:

1. Continue to refine the functionality and modify the UI

2. The main task is to merge data with the team of the online system, while our two teams have decided to share a server so that the data can be shared and the data requirements of group first to second are clearer, but there is also a huge collaborative problem between teams, with two teams working together to develop This poses a greater challenge to communication.

3. Fix bugs

M1 Stage Post-Event Summary _