How to use the right way to write 75 experiences of quality software
Transfer from: http://blog.joycode.com/mvm1. Do you have a source code management tool? Should be used. VSS, CVS, PVCS, ClearCase, CCC / Harvest, Firefly can. My choice is VSS.
2. Is your project group use the defect management system? Should be used. ClearQuest is too complicated, my recommendation is bugzilla.
3. Is your test group still write test cases with Word? Do not use Word write test cases. You should use a specialized system, you can be Test Manager, or you can develop a small website of ASP.NET. The main purpose is TRACK and BROWSE.
4. Does your project group have a portal? There is a portal, used to place Contact Info, Baselined Schedule, News, and so on. Recommended SharePoint Portal Server 2003 to achieve, 15 minutes. Can't afford SPS 2003 to use WSS (Windows SharePoint Service).
5. Do you have the best tool you can buy? It should be used to work with as much as possible. For example, you should write C # with vs.net instead of notepad. Most of the NOTEPAD write programs is just a kind of show. But also take into account funds, so say "you can buy the best."
6. Is your programmer working in a quiet environment? Need a quiet environment. This is extremely important, and it is necessary to ensure that each person's space is greater than a certain area.
7. Does your employees have a phone call? Need a phone call. Moreover, the phone is preferably with message function. Of course, such a set of message telephone system overhead is not small. However, at least one phone call must have, don't do anyone standing up and shout: "a phone call". "People" is strongly condemned this approach.
8. Everyone knows who you should find out? should know. Any feature should at least have an Owner. Of course, Owner can continue dispatch to others.
9. You have encountered someone say "I thought ..."? To eliminate "I thought". Never associan.
10. Are all people in your project group sitting together? need. I oppose Virtual Team, also opposed DEV in the United States, Test in China. It is best to sit together, and it will be more beneficial.
11. Does your progress table reflect the latest developments? Should be reflected. However, you should use the Baseline method to manage schedule: maintain a stable Schedule, and then maintain a latest change. The method of Baseline should also be used for other SPECs. Baseline is an important means in the management of the change management.
12. Is your workload to be estimated by everyone? Everyone should be estimated. To estimate the workload from the bottom, not from top to bottom. Unless other reasons, such as the policy of the political task.
13. Do your developers work overtime from the beginning of the project? do not do that. Don't make a fatigue war at the beginning. Overtime work from the beginning of the project, only the project progress is unreasonable. Of course, some of the day software outsourcing must work overtime every day, and that belongs to exploitation.
14. Is the buffer time in your project plan? Is it behind every small task? Don't. Buffer Time is added to each of the small tasks, it is easy to be easily consumed. Buffer Time The whole section is added to a MILESTONE or CheckPoint.
15. It is worth a lot of time, from 95% to 100%, it is worth it. Especially when the project is buddy, it is necessary to persist. This will bring quality difference to the product. 16. When registering new defects, do you write a reproduction step? want. This belongs to the communication between DEV and TEST. Face-to-face communication needs, fill in the RePro Steps in detail.
17. Do you solve the known defect before writing a new code? want. Every person's defect cannot exceed 10 or 15, otherwise you must first solve the old BUG to continue writing new code.
18. Do you have a prior agreement on the defects? Must be defined. Severity points 1, 2, 3, agreement: Blue Screen and Data Lost calculate SEV 1, FUNCTION Error calculates SEV 2, the SEV 3 on the interface. But this agreed can be adjusted appropriately according to the product quality status.
19. Do you have a three-country meeting to the shortcomings of opinions? Must have. There is a clear decision process. This is similar to the concept of CCB (Change Control Board).
20. Are all defects that are closed by the registered person? BUG should be shut down by Opener. DEV cannot close Bug privately.
21. Does your programmers disgusted to modify the old code? Avoiding is normal. The solution is to organize the Code Review and leave the time separately. XP is also a way. 22. Do you have Team Morale Activity? Every month must work once, eat, sing, outing, play, open kart, etc., must have. Don't leave these money. 23. Do you have your project group? Be your own logo. At least there should be its own CODENAME. 24. Does your employees have T-shirt with company LOGO? There is. Enhance the sense of belonging. Of course, T-Shirt is better to do, preferably use 80 cotton. Don't wear a few times and break down. 25. The general manager at least participates in the sub-project group meeting at least monthly. Let Team Member feel that the high level pays attention to this project. 26. Are you opening a branch for each DEV? Oppose. Branch management and Merge workload is too large, and it is easy to make mistakes. 27. Does anyone do not Check-in code for a long time? No. For most items, you should check-in for up to two or three days. 28. Are you filled in the comment when check-in code? To write, at least one or two sentences, such as "solve Bug No.225". If you pull high, this is also part of the "Configuration Audit". 29. Is there a final deadline for CHECK-IN every day? To be, you have to clarify Check-in Deadline. Otherwise it will build Break. 30. Can you compile all the source code into an installation file? need. This is the basis of daily compilation (DAILY Build). And you must be able to make automatic. 31. Do you have a daily compile? Of course you have to do. There are three things that are necessary for software projects / product development: 1. bug management; 2. Source Control; 3. Daily build. 32. Have you accumulated a list of project risk? want. Risk inventory. Otherwise, when the next project starts, it can only take a head to analyze Risk. 33. The more simple design is, the better, the better. There is more words when designing, it will bring endless troubles in the future. Shop should be chopped from the beginning. This is called Scope Management. 34. Try to take advantage of existing products, technology, and code, don't do something yourself. BizTalk and SharePoint are the best examples. There are two as the foundation that can increase the starting point. Or you can try as much as possible with ready-made Control. Or try to use XML instead of yourself to Parse a text file; try to use regexp instead of your own operation string, and so on. This is the embodiment of "software reuse". 35. Are you stopped to consolidate the code over a period of time? want. It is best to one month. Learn last year, the Windows group stopped in STEVB's command to enhance security. BTW, "" This word "hang", first voice. 36. Are everyone of your project group written DAILY REPORT? To write. Five minutes is enough, write about 10 sentences, telling yourself what I have done today. One for communication, two spur yourself (if you are free day, you will be embarrassed). 37. Do your project managers issued a Weekly Report? want. Also communicated. The content includes current progress, possible risk, quality status, progress in various work. 38. Do you meet at least every week? want. Be sure to meet. The programmer hates the meeting, but at least 4 hours each week is at least 4 hours.
Includes Team Meeting, Spec Review Meeting, Bug Triage Meeting. Don't worry about it. 39. Do you have a record in your project group? Meeting Request and Agenda, some people are responsible for hosting and recording, and some people will be responsible for Meeting Minutes, which is the point of Effective Meeting. Moreover, each meeting must form Agreements and Action Items. 40. What are you doing in other departments? Send some newsflash to the entire major organization. SHOW Your Team's Value. Otherwise, when you sit in the elevator, the people in other sectors ask: "What are you doing?" When you answer the "ABC Project", others don't know, the feeling is not very good. 41. The benefits of all formal communication email via Email are reluctant. However, it is also necessary to avoid overkill, the best way is to say first, and when email is confirmed. 42. Built multiple mailing groups for the project group If you are in Ad Exchange, you will build a Distribution List. For example, I will build ABC Project Core Team, ABC Project Dev Teesters, ABC Project Extended Team, and so on. This is convenient to initiate email, and people who can receive email are received, and should not be harassed. 43. Everyone knows where to find all documents? Everyone should know. This is called Knowledge Management. The most convenient thing is to put the document in a concentrated File Share, a better way to use SharePoint. 44. Do you make a decision, tell everyone the reason? To tell everyone the reason. One of the means of Empower Team Member is to provide sufficient information, which is one of several principles of MSF. Indeed, Tell Me why is a human condition, and Tell Me why has Understanding. Chinese people do things like to engage in restrictions, restrict information, and those who can see a document are people with identity. Big wrong. Authority, power, is not to be able to Access Information / Data, but is not to master resources. 45. Stay Agile and Expect Change To do this. The demand will change, and the code that has been written will be modified. Do your psychological preparation, do not resist Change, but Expect Change. 46. Do you have a full-time software tester? There is a full-time test. If the human hand is not enough, you can exchange the test. Don't test your own yourself. 47. Do you have a general plan to specify what to do and how to do? This is Test Plan. Do you want to do performance testing? Do you want to do a USABILITY test? When do you start testing performance? What is the standard passing? What is the means, automatic or manual? These problems need to be answered with Test Plan. 48. Do you write Test Case first and then test it? It should be. It should be designed before programming, first Test Case and then test. Of course, things are flexible. I sometimes make Test Case while doing the first pass.
As for the first Test Case again, I don't like it, because I am not used to it, it is too trouble, as for others, try it. 49. Will you create test cases for various input combinations? Don't, don't engage in border conditions. When the heart combination explosion. There are a lot of Test case tools to automatically generate a combination of various boundary conditions - but if you want to clear, do you have time to run so much Test Case. 50. Can your programmers see test cases? want. Let DEV see TEST CASE. We are all come together for the same purpose: improve quality. 51. Do you have someone else to do any useful test? To do this. I look at my own program interface, how to see it is pleasing. This is called aesthetic fatigue - it is not smelling for a long time. It is used to it. 52. Are you the expectation of automatic testing? Don't expect too much. According to me, in addition to performance test, I still forget "automatic test", forget WinRunner and LoadRunner. For the status quo of domestic software test, it can only be "correctly" must pass. " 53. Does your performance test do all functions have been done? can not be like this. Performance tests cannot be returned to a so-called "system test" phase. Early measurement, early death, early death. 54. Have you noticed the insecticide effect in the test? Bug has anti-drug resistance, BUG is also. The new bug found is less and less normal. At this time, it is best to exchange the Tested Area, or use other tools and techniques, will find some new bugs. 55. Is there anyone in your project group to say the current overall quality of the product? There is. When the boss asks this product, Test Lead / Manager should be responsible for answering. 56. Do you have a unit test? Unit tests must be. However, there is no unit test, I have done a project that has no unit test, and it will be successful - it may be lucky, maybe everyone is the relationship of the family. Still, software engineering is very practical, very engineered, very flexible, some methods will be better than others in some cases, and vice versa. 57. Your programmer throws the wall after writing the code? Badge. After writing a program, even if you don't do unit test, you should run a run. Although there are special testers, people who do developing are not doing it. Microsoft also has Test Release Document's statement, the program is too bad, the test has the right to kick it. 58. Are all functions in your program have input checks? Don't. Although it is said that the input check is the point of Write Secure Code, do not do too much input check, the parameter passes between some internal functions do not have to check, save the efforts. The same reason, not necessarily written to all functions. It is enough to write some main. 59. Does the product have a unified error handling mechanism and an error interface? There is. It is best to have uniform error messages, and then each Error Message takes an error number. In this way, users can go to the error specific description and possible reasons of Error Number to User Manual, just like SQL Server errors. Similarly, ASP.NET also has a unified Exception process. You can refer to the Application Block. 60. Do you have a unified code writing norms? There is. Code Convention, you can send it to everyone. Of course, if there is a FXCOP tool to check the code is better. 61. Everyone you know is the business meaning of the project? want. This is Vision meaning. Don't take the project only as a job.
Sometimes I want to be a pioneer in the informationization of a certain industry in China, or tell Team Member from time to time, can this project save how many million taxpayers in a certain national department each year, this is Powerful. Ordinary things can also have a noble goal. 62. Are the interfaces and operational habits of each part of the product? To be this. To make users feel that the entire program seems to be written by one person. 63. Can you be a COOL feature as a highlight of the promotion? want. This is an enhanced team cohesiveness, confidence. Moreover, "a junior huns", there is a highlight to cover some problems. In this way, for the customer, it feels that the product is still an acceptable from a quality point of view. Alternatively, Cool Feature or highlights can make up for measures as a matter of quality problems. 64. Shorten the startup time of the product as much as possible. Software start-up time is the first impression of customers' performance. 65. Don't pay too much attention to the external impression programmer in the first eye, it is easy to make this error: too much weight, stability, storage efficiency, but ignore the external feelings. And the high-level manager, the customer is opposite. These two aspects should be taken into account and coordinate these is the work of PM. 66. Do you have developed according to the detailed product function manual? To be this. It is necessary to have a design to develop. Design documentation, you should say how this product will run, and you should take some stories. Don't diamond details when design, don't drill into the database, code, etc., those behind them, those behind, and step in step. 67. Do you carefully review the functional design before starting to develop and test? To do it. Function Spec Review is used to unify thinking. Moreover, Review has formed a consensus later, no one can say anyone in the future, "You see, I am against the designed, now I am suffering," 68. Everyone always thinks the whole image? " To be this. Although everyone is only manufacturing a leaf, everyone should know how they are in the tree in which they are manufactured. I oppose the software blue collar, opposed excessive development of software manufacturing to the pipeline, workshop. See section 61. 69. Is the division of DEV works in a simple portrait or landscape? It cannot be simply divided according to the functional module, or in a single score according to the performance layer, the intermediate layer, the database. I recommend this: First, according to the function module, then each "layer" has an Owner to review owner's design and code to ensure consistency. 70. Do you write program description documents? want. However, I heard that Microsoft's programmers did not write before 1999. So, it is not absolute writing, and it is sometimes possible. See Article 56. 71. Do you write a program when you recruit him? need. I like to make a string and list of questions. This topic has a lot of loops, judgments, pointers, recursive, etc. 72. Do you have a technical exchange? need. Every two worships have an internal Tech Talk or Chalk Talk. Let the team members share the technical experience, this spent is sent to the outside to train. 73. Can your programmers focus on one thing? Let the programmer focus on one thing. For example, a department has two projects and 10 people. One way is to let 10 people participate in two projects, each of each item spends 50% time; another method is 5 people going to project A, 5 Personal to project B, each person is 100% on a project. I must choose later. There are many people in this truth understand, but many leaders practices themselves as a resource that can be split.
74. Does your programmer exaggerate the time required to complete a job? Yes, this is common, especially in the later stage of the project, the time required to do a change, boycotting Change in a time. The method of solving is to sit down and slowly, grind the programmer's counter-opposite, together analyze, and make the granular particles of the estimated time be smaller. 75. Try not to use Virtual Heads, do not use Virtual Heads. Virtual Heads means Resource IS Not Secure, Shared Resource reduces the work efficiency of Resource, which is easy to increase the chance of error, and people who will use the people don't have much time to go to Review Spec, Review Design. A Dedicated person, it is necessary to have two people who can only put 50% time and energy. I have a loss: 7 part time Tester, discovered bugs and dry live, add up to two full-time. See Section 73. 73 are for programmers, 75 are for Resource Manager.
