ASE2019 model hindsight group meetings

Zhuge Liang document

Vision and goals

1. Our software to solve the problem? Whether clearly defined? Is there a clear description of the typical user and a typical scenario?

Under the traditional model of education programming for beginners (mostly new to programming students) often rely on teachers and teaching assistants in the classroom, due to time constraints or lack of targeted training, programming poor first experience, we hope that through AI and considerate the design, with a better software to help beginners learn programming language.

Our problem is more clearly defined, the software "AI Coach" little new to python programming language for beginners, programming experience, optimize their learning curve, improve their learning introductory programming experience.

Typical users: beginning with python programming language for the first contact with the freshmen.

A typical scenario: Programming never touched before Xiao Ming University, freshman to start learning python, very difficult, I do not know where to start, hoping to find a platform in their spare time to do targeted exercises to improve the level of programming.

2. We reached the goal yet (function originally planned to do a few? As originally planned delivery time delivered what? Originally planned to reach the number of users reached it?)

We reached the goal alpha stage, to achieve the basic requirements of the minimum available system model. Recommended title features originally planned (cold start and warm start), a friendly error function (in three different ways) have done and delivered on time. The number of users in each group from the alpha stage of testing of students.

3. On a stage and compared the quality of the software engineering team to improve it? In what has been improved, increase the number of specific, how to measure?

The current alpha stage only to achieve a minimum available system, but the internal interfaces and back-end interface definition division has been more clear, and it should be said to achieve the objectives of the project quality, inadequate and ill-considered place in the beta stage can go further improve .

4. The amount of users, users in advance of the expected agreement on acceptance of it and we have important functions? Our goal from the closer it?

 alpha stage of our subscribers only several groups of students, there is no multi-user functionality, we are tested under the same user, from the test results, users do question on the page, run the code and see the results , a friendly error, submit evaluation process has been able to complete run down. Basic functions to the extent available, acceptable. The results for some aspects of friendship error error gives good results, but there are some incorrect results are less reliable, need to be further improved. We took a big step from scratch in alpha stage, away from the more recent the target.

What are the lessons? If history all over again, what would we do to improve?

Lessons learned, we have carefully examined our previous workflow at the end of the alpha stage and found a lot of places you can improve. The scrum process because the model set of tasks larger span, do different things within the group were quick exchange students to discuss, together we finally summed up the day's work together to achieve greater efficiency in the same time, better AC reducing spending extra time because of miscommunication arising. Internal and interface with other groups earlier should discuss and determine, once it is determined necessary to avoid change, big time spending in the butt than working group between the teams, it needs to be more attention.

plan

1. Is there enough time to do the plan?  

No, we have not done before because the full investigation of the task model group, but added alpha phase at the beginning we did not know what to do, modify the plan is also kept in the implementation process.

2. Team at the planning stage is how to resolve the disagreement colleagues for planned?

scrum discussed, then majority

3. You work planned if finally done? If you have not done, and why?

finished

4. find that you do not have some hindsight did not need or do not count for much?

No

5. Is each task are clearly defined and measurable deliverables?

Yes

6. The whole process if the project were carried out according to plan, the project what had happened? What are the risks was not estimated, why not estimated?

No plans to amend non-stop, because we did not start very well clear of the problem definition.

7. There is no buffer left in the plan, the buffer role it?

There, the buffer is full rule based, this two days to make things right, we have all escape route

8. Future plans will do what changes? (Example: Define buffer, overtime)?

No, we explore this alpha stage development of similar research carried out very pleasant.

9. What have we learned? If history all over again, what would we do to improve?

We found that, in fact, R & D and scientific research is the same, it is important to identify problems, define and solve problems, we not only experience in the process to develop the full, also felt the joy of creating something new.

In the beta phase, we will use the digging project, the model group is responsible for the problem, and then trying to find "local optimal solution."

Resources

1. We have enough resources to fulfill the tasks it?

Human resources: our group is more adequate staff can be assigned to several groups, respectively, to complete two different tasks: Recommended system prompt system.

Hardware resources: our group due to the use of neural networks, the need to ensure a certain degree of GPU computing speed; because the majority of the members of our group have GCR node, therefore sufficient for debugging development. When the final deployment, we also use the GPU GCR node.

2. The time and other resources required for each task is how to estimate how accuracy?

Estimates ways: the tasks required time and other resources were estimated by scrum manager, PM and corresponding responsible staff in the scrum meeting, along with the actual work to expand adjusted accordingly.

Accuracy: early, due to the demand and technology selection is not fully determined, the estimated hours of work error is large, part of the estimated error of half a day; the latter, we gradually work to determine the specific content and technical details of the discussions within the group and with the back-end communication process , operating time estimation error can be controlled within 30min.

3. Test of time, manpower and software / hardware resources are sufficient? For those without programming resources (graphic design / copy) whether underestimate the difficulty? 

4. Have you ever felt that you can do to let others do the (more efficient)?

What are the lessons? If history all over again, what would we do to improve?

Change Management

1. Each relevant employees in a timely manner that the message changed?

Each team member can be timely and relevant messages that change. The following two aspects Description:

(1) changes in demand: When we need to add new features, or to require us to have a greater change when the product features, PM will discuss with the relevant team members face to face, in all relevant team members to reach consensus only after formally adopted. At the same time, we will be allocated on a VSO or modify tasks, associated members will receive e-mail alerts.

(2) changes in the technical details: When there are some technical details need to be adjusted when the (often appear in groups when docked), we will modify the document, and notify the relevant members in a timely manner be modified according to the document.

2. What measures we have adopted a decision "to postpone" and "must be achieved" feature?

We are mainly based on the importance of each function a;. B time required to achieve these two factors to decide.

Specifically, for core functionality, we require "must be implemented." For example, a friendly error message this feature and found to be heavily modified before docking at the time and the back end of the butt, but because this is the very core function, "must be implemented", so team members put a lot of effort to be modified.

For some non-essential functions, under the conditions schedule does not permit, we will decide "to postpone."

3. The conditions of export project (Exit Criteria - what "done") have a clear definition of it?

For the alpha stage, the project export conditions we define as:

(1) defined three tasks must be completed: Friendly error and prompt the user to build and intelligent portrait recommend title, improved model based on user data. In our final products, the successful completion of these tasks.

(2) the finished product must be robust. For a variety of circumstances that may arise, we must ensure that the program does not crash. After the completion of the preparation of the basic program, we have for this improvement, the basic guarantee of the robustness of the product.

4. For possible change whether contingency plans?

At this point we do it is not very good. Our work has been guided by a "minimal use" principle to carry out, for all kinds of changes we will first make available a program. But in the "planning" We are still lacking, more of a step by step.

5. Are employees able to effectively deal with unexpected work request?

Yes, the crew were able to effectively deal with unexpected work request. This aspect thanks to members of their sense of responsibility, on the other hand, also benefited from the rational organization of the group. When there are unexpected work needed, PM will coordinate the process, not "thrown pot", but members and relevant to discuss whether to handle, when the amount of time the task, will arrange for other team members to assist.

What have we learned? If history all over again, what would we do to improve?

In this regard change management, we learned

Design / implementation

1. Design work at what time and by whom done? Is the right time, the right man?

Design work is divided into two stages, in the early planning stages of the project, we conducted a unified discussion to determine a preliminary design of the project as a whole a modular architecture, and the team is divided to several groups to correspond to different functional modules. After initially identified project requirements to determine the specific details of each module was designed by internal members of each group discussion. In this way, our top-down decomposition of the entire design task, and let each member involved in the design of their own familiar good part to ensure the reasonableness of staffing and timing.

2. Design work has not encountered ambiguous situations, how the team is resolved?

Such a situation existed, we've put together to deal with the idea is to gradually expand from simple to complex. First, determine which part of the doubt, and implemented quickly. Before proceeding further details of the design on the basis of the preliminary practice. So that we can ease the sense of confusion to some extent beginning of a project, greatly reducing the possibility of over-designed.

3. Does the team use unit testing (unit test), test-driven development (TDD), UML, or other tools to help design and implement? These tools work? UML Documentation beginning of the project and compare the current state What is the difference? How do these differences arise? Do you want to update UML documents?

We provide external API model are prepared corresponding test case and test code, and the code prior to the merger by each person in charge of checking whether code changes passed the test. This time we did not use test-driven development temporarily, due to the input-output model algorithm is difficult to clear in the early stage of our test samples in order to construct a reasonable model after initial stabilization. Since our team is responsible for the entire project model and algorithm design, so we have designed a set of indicators of quality test model, created the basic conditions for data-driven model iteration.

4. What is the most versatile Bug produced, and why? After publishing discovered something important bug? Why did not we think of these cases in the design / development time?

We found that when the largest number of projects docking bug, and the bug mostly because we both agreed on normative data transmission caused by the inconsistency, which allows us to recognize the necessity of establishing a detailed documentation of the interface, too brief interface documentation will increase the cost of communication lines unnecessarily, even forcing developers to code refactoring and re-deploy many times, in fact, actually increased labor costs. At design time can not pay attention to it because, among a group of us started discussing is not sufficient, there is no advance to reach some of the more clear agreement. When we docked late on a more timely manner to correct these negligence made to improve the interface documentation.

5. Code review (Code Review) is how to proceed, whether the strict implementation of the code specifications?

 Part-time code review by the PM and scrum master two students, when a branch of the function realization is completed, or a version of the iteration is complete, the person in charge of the branch filed Pullrequest, two students were handed over to code review, and put forward reasonable suggestions for improvement. This ensures that the code on the main branch have been a secondary confirmation, to enhance the stability of the main branch of the code as possible.

What have we learned? If history all over again, what would we do to improve?

Clearer feeling is that the project design is hard work overnight, but with the development of projects and constantly enrich and improve. If over again, we will pay more attention to the level and depth of work undertaken, to discuss and implement stepwise from the skeleton to flesh, save time blind some preliminary planning.

Test / release

  1. Whether the team has a test plan? Why not?

  2. Whether formal acceptance testing?

  3. Whether the team has the tools to help test test?

  4. Team is how to measure and track the effectiveness of the software? From the results of the actual operation of the software, these tests work useful? What improvements should have?

  5. What unexpected problems found in the process released?

What have we learned? If you do it all again, what would we do to improve?

The role of team management, cooperation

How each team is to determine the role, is not the best use?

In the first scrum we will group the entire mission Model divided into two parts, Recommender Systems and Hint Systems. Recommended system to be responsible Jie Pan, Linfeng Qi, Kun Yan three people. Tip system is responsible mainly by Xueqing Wu, Yutong Lin, Lei Chai. Jiyan He, as head of two working parts are involved, the final completion of the integration of the code section, while the front-end and back-end docking. Zhipeng Huang Because ddl has CVPR contributors, so is responsible for organizing and writing a daily log of the scrum. Specific members of the division are as follows:

Jie Pan

Recommender::Path, Cold start, Survey design, Learning path design

Hav

API design, Code control, Documents, Dockerize, Server ops, Debugging with FE/BE

Kun Yan

Recommender::ALS, Mock data, Cold start, Debugging with BE

Lei Chai

Hint::www, Documents

Linfeng Qi

Problems, Tags, Input/output, Solutions, , Initial comments

Xueqing Wu

Hint::neural, Documents, Common mistakes, Initial comments

Yutong Lin

Hint::structure, Documents, Common mistakes, Initial comments

Zhipeng Huang

Scrum reports 1,2,3,4,5,6,7,8,9,10,11

We believe that all members of the whole group all their talent, we completed the maximum efficiency of their own parts. Each team member a specific mutual coordination and cooperation, but also all front-end and back-end to complete a good coordination docking. Whenever there is a member of a work difficulties, timely assistance can be found in the group.

What have mutual help among team members? 

   每天在scrum中,大家在小组讨论中都能及时的提出自己遇到的困难和困惑,其他成员会提出自己的想法,大家在沟通中可以很快的找到更好的解决方法。在日常工作中,我们都能够及时通过teams来沟通和帮助。 

When the issue of project management, cooperation appears, team members how to solve the problem?

In the project's management, progress has been head of jiyan can be a good organization and planning of the project, team members can also make recommendations to the current progress timely. When problems arise collaboration, we often make an appointment to discuss room, face to face to solve the problem. If the problem is small, basically by teams also can get a good solution.

    Each member represents a clear publicly thank the members of the help (and write in their blog in):

    I thank _______ <name> ______ for my help, because some specific things: _____________________.

to sum up:

     1. Do you think the current state of the team belongs grade CMM / CMMI in?

Our team is currently defined in the basic level. In the development process, we divided into two large groups, the last leader of unified coordination. And members are responsible for the interface function and so have a good definition of consent, and will sync up documents. We process the entire project, and others have accused the basic common understanding.

      2. Do you think the team is currently in its infancy / running / specification / create a stage which stage?

Our team at the specification stage. Through the joint work and mutual discussion for some time, we have positioned themselves in the team and assumed by the accused have a basic clear tenure, and mutual cooperation among its members but also an orderly manner.

      3. Do you think the team before this milestone compared to a milestone any improvement? 

We have a clearer understanding of their own to do before the project compared to the morphology of the final product have a common understanding.

      4. What do you think most need to improve aspects is?

Cooperation between our team and t discussion is still to meet at the main line, sometimes not everyone has the time, but sometimes it is a waste of time. We should make more use of online exchanges to improve efficiency.

 5. 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。  

First, avoid unnecessary overhead: Our internal team is divided into two small teams, make a mistake handling a recommendation. Between these two work currently is no coupling, so we are the first to discuss the exchange within the group, and then together to focus on the exchange. Avoid excessive waste of time.

Second, cooperation: each of us is a clear division of functions and interfaces for each division to be achieved we have negotiated in advance, and have the necessary documents to support, so that each division after work is completed, may soon be a member of the the results are combined.

As we mentioned earlier, the quality of software engineering software quality + quality = program, and that the team in the next phase of how to improve the quality of software engineering it?

  1. Quality code management should be specific on how to improve? What is the quality code reviews and code standard should be raised?

Code Management: fully functional version of Git and other management tools, such as branch and other isolate and identified projects in development projects; code review among the members; write tests for their code, ask for help themselves function code testing; for interface code to reach a consensus.

Code review: first to check the functionality of the code, secondly look for defects in the code, and finally to assess the style code

Code specification: code first to be easy to understand, where necessary Notes, the necessary documents. Reached agreement on naming rules and other norms in the group.

  1. How to improve the whole process of the specific architecture? How to improve quality through reconstruction and other methods to improve the quality of how to measure?

  2. Other application software tools, how to improve?

  3. What specific projects to improve the management have?

  4. Project tracking user data, plans to raise what? For example, how do you know / week Daily active users and other data? 

  5. How to improve the quality of project documentation?

  6. For people leadership and management, what specific areas for improvement? See "Building of the law" On PM, the section of performance appraisal, or "human element" and other reference books

  7. For software engineering theory, the laws have any experiences or disagree? Look reading assignments. (This assignment midterm reading)

Each member scores

Quit case

Conference Photos


Lei Chai sick leave
Jiyan He went to open a technology conference in Xi'an.

Guess you like

Origin www.cnblogs.com/huangzp1104/p/11935096.html