On this day when all of us celebrated the official entry of the. Game framework into sourceforge.net, our project should also start to run. Although we are an open-source project, we still have a core team. Are you ready to take action for all core team members?
Here, I would like to cite how MVM can write 75 pieces of good quality software in the correct way, the core members who are preparing to participate in the evaluation should evaluate themselves against the following 75 questions.
1. Have your project team used the source code management tool?
2. Have your project team used the defect management system?
3. Are your test groups still using word to write test cases?
4. Have you set up a portal for your project team?
5. Have you purchased the best tools for your project team?
6. Do your programmers work in a quiet environment?
7. does each of your employees have a phone number?
8. Do you all know who to look?
9. Someone said, "I thought ..." ?
10. Are all people in your project team sitting together?
11. Does your schedule reflect the latest development progress?
12. do you estimate your workload by yourself?
13. Did your developers work overtime from the very beginning of the project?
14. Is the buffer time added after each small task in your project plan?
15. It is worthwhile to spend more time, from 95% to 100%.
16. Have the reproduction steps been written during registration of new defects?
17. Will known defects be solved before new code writing?
18. Do you have any prior agreements on priority of defects?
19. Do you have any defect in the Three Kingdoms meeting?
20. Are all defects closed by the registrants?
21. Do your programmers hate to modify old code?
22. Does your project team have a team morale activity?
23. Do your project team have their own logo?
24. Do your employees have T-shirts with company logos?
25. The general manager shall attend at least one project group meeting every month.
26. do you open a branch for each Dev?
27. Does someone keep checking-in code for a long time?
28. Have you filled in comments when checking-in code?
29. Have you set the daily check-in deadline?
30. Can you compile all source code into an installation file at once?
31. Do your project team perform daily compilation?
32. Have your company accumulated a project risk list?
33. The simpler the design, the better.
34. Use existing products, technologies, and codes whenever possible
35. Will you stop and consolidate the code after a while?
36. Do everyone in your project team write a daily report?
37. Will your project manager issue a weekly report?
38. Do your project team have at least one plenary meeting every week?
39. Are there records of meetings and discussions in your project team?
40. Do other departments know what your project team is doing?
41. all formal communication via email
42. Create multiple mailing groups for the project team
43. Does everyone know where to find all the documents?
44. Did you tell everyone the reason when you made decisions and made changes?
45. Stay agile and keep CT change
46. Do you have any full-time Software testers?
47. Do you have a general plan for testing to determine what to do and how to do it?
48. Did you write test case before testing?
49. Will you create test cases for various input combinations?
50. Can your programmers see test cases?
51. Do you need to take some people for usability testing?
52. Are you expecting automatic testing?
53. Is your performance test performed only after all functions are developed?
54. Have you noticed the Pesticide Effect in the test?
55. Can someone in your project team tell you about the overall quality of the product?
56. Do you have a unit test?
57. Did your programmers throw the wall after writing the code?
58. Do all the functions in your program have input checks?
59. Does the product have a unified error handling mechanism and Error Reporting interface?
60. Do you have unified code writing specifications?
61. do each of you understand the commercial significance of the project?
62. Are the interfaces and operation habits of various products consistent?
63. Is there any cool feature that can serve as a promotional highlight?
64. Shorten the product startup time as much as possible
65. Do not focus too much on internal quality and ignore the first-eye external impression
66. do you develop according to the detailed product function manual?
67. Have you carefully reviewed the functional design before you start development and testing?
68. Do everyone always think about the whole image?
69. Is the division of Dev work purely vertical or horizontal?
70. Do your programmers write program design instruction documents?
71. Did you ask him to write a program during the interview?
72. Do you have any technical exchange lectures?
73. Can your programmers focus on one thing?
74. Will your programmers exaggerate the time required to complete a job?
75. Try not to use virtual heads
Among the 75 articles, there are reviews of the project content and brand, discussions on the development process, and suggestions on various aspects of staff training. I don't think we can use it all here, but I hope that at least we can clearly define our goals, understand our position, and understand the dynamics of others.
We hope that all team members will come to the first Development Team meeting from to this week.
The main content of this meeting will be:
1. Determines the position and role of each person in the team. In order to optimize human resources and avoid repeated development.
2. Complete the division of labor on SF and standardize registration information.
3. Specifies the project development tools and code styles. (Each person may have their own preferences, but the style should be consistent as much as possible in the team .)
4. A more in-depth discussion of the program framework. (You can think as much as possible over the past few days. I hope you will have a mature set of opinions during the meeting. It is best to sort the text in advance)
5. Arrange the Work Plan for the last month based on the division of labor and the framework of procedures.
