Write 75 of high quality software experience _ Classic NET Pick

75 experiences of how to write high quality software in the right way
1. Does your project team use source code management tools?
MVM: It should be used. VSS, CVS, PVCS, ClearCase, Ccc/harvest, Firefly are all available. My choice is VSS.

2. Does your project team use the defect management system?
MVM: It should be used. ClearQuest is too complicated, my recommendation is bugzilla.

3. Are your test groups still using Word to write test cases?
MVM: Do not write test cases in Word. You should use a dedicated system, either test Manager or your own small web site for developing a asp.net. The main purpose is track and browse.

4. Did your project team set up a portal site?
MVM: To have a portal site for contact Info, baselined Schedule, news, and so on. Recommend SharePoint Portal Server 2003来 implementation in 15 minutes. You cannot afford SPS 2003 with WSS (Windows Sharepoint Service).

5. Did your project team use the best tools you could buy?
MVM: You should work with as good a tool as you can. For example, you should use vs.net instead of Notepad to write C #. Writing programs in Notepad is mostly just a show of ostentation. But you also have to consider the funding, so that is "you can buy the best."

6. Do your programmers work in a quiet environment?
MVM: You need a quiet environment. This is extremely important, and to ensure that each person's space is greater than a certain area.

7. Do all your employees have a phone?
MVM: Everyone needs a phone. And the phone is best with a message function. Of course, such a set of message phone system overhead. But at least a phone call to have, do not make often people stand up shouting: "So-and-so a phone." This practice is strongly condemned in the human piece.

8. Do each of you know who should be looking for a problem?
MVM: You should know. Any feature should have at least one owner, of course, owner can continue to dispatch to others.

9. Have you ever met someone who said, "I thought ..."?
MVM: To destroy "I thought." Never assume anything.

10. Are all the people in your project group sitting together?
MVM: Need. I am against virtual team, and also against Dev in the United States, test in China this way of development. It's better to sit together and have a lot of benefits.

11. Does your schedule reflect the latest developments?
MVM: should be reflected. However, a baseline approach should be used to manage the schedule: maintain a stable schedule and maintain a new change. The baseline method should also be used in other spec. Baseline is an important tool in change management.

12. Is your workload first estimated by everyone?
MVM: Everyone should estimate for themselves. You need to bottom-up estimate the workload, rather than assigning it from the top down. Unless there are other reasons, such as the fixed duration of political tasks.

13. Did your developers work overtime from the start of the project?
MVM: Don't do that. Don't get tired from the start. Working overtime from the start of a project can only indicate that the project is not progressing properly. Of course, some software outsourcing to Japan must work overtime every day, that is the category of exploitation.

14. Is the buffer time in your project plan added behind each small task?
MVM: Don't. The Buffer time is easily consumed by the time it is added behind each small task. Buffer time to add the whole paragraph to the front of a milestone or checkpoint.

15. It is worth spending some more time, from 95% to 100% good
MVM: Well worth it, it's worth it. Especially when the project late Mashi, should insist. This will make a qualitative difference to the product.

16. Did you clear the recurrence steps when registering new defects?
MVM: To. This is a means of communication between Dev and test. Face-to-face communication needs, detailed fill repro steps also need.

17. Will the known defect be solved before writing new code?
MVM: To. Each person's flaw cannot exceed 10 or 15, otherwise must solve the old bug first to continue to write new code.

18. Do you have any prior agreement on the priorities of the defects?
MVM: There must be a definition. Severity should be divided into 1, 2, 3, a good deal: blue screen and data lost calculated SEv 1,function error SEv 2, the interface of the calculation SEv 3. But this kind of agreement may adjust according to the product quality present situation suitably.

19. Do you have a meeting of three countries on the flaws of disagreement?
MVM: It has to be. There must be a clear decision-making process. This is similar to the concept of the CCB (change Control Board).

20. Have all the defects been closed by the registered person in the end?
Mvm:bug should be closed by opener. Dev cannot shut down bugs privately.

21. Are your programmers sick of changing old code?
MVM: Disgust is normal. The solution is to organize the code Review and leave the time alone. XP is also a method.

22. Does your project team have morale activity?
MVM: Once a month, eat, sing, outing, play ball, drive kart and so on, must have. Don't have the money left.

23. Do you have a logo for your project team?
MVM: To have their own logo. At least you should have your own codename.

24. Do your employees have T-shirt with the company logo?
MVM: To have. Can enhance the sense of belonging. Of course, T-shirt to do a good job, preferably with 80 cotton to do. Don't be a mess without wearing it a few times.

25. The general manager attends the project group meeting at least once a month
MVM: That's for you. Let team member feel at the top of the project.

26. Do you open a branch for each dev?
MVM: Objection. The management of branch and the workload of the merge are too large and error prone.

27. Does anyone check-in code for a long time?
MVM: No, you can't. For most projects, a maximum of two or three days should be check-in.

28. Do you fill in the comments when you check-in the code?
MVM: To write, at least one or two words, such as "solve the bug no.225." This is also part of the "Configure audit" if you pull up high.

29. Is there a deadline to set a daily check-in?
MVM: If you want, be clear about check-in deadline. Otherwise, you will build a break.

30. Can you compile all the source code into the installation file at a draught?
MVM: That's for you. This is the basis for daily builds. and must be able to make automatic.

31. Does your project team compile daily?
MVM: Of course you do. There are three things that are necessary for software project/product development: 1. Bug management; 2. Source control; 3. Daily build.

32. Does your company accumulate a list of project risks?
MVM: To. Risk Inventory. Otherwise, at the beginning of the next project, you can only take a head analysis risk.

33. The simpler the design, the better.
MVM: The simpler the better. Design time more than a word, the future may bring endless troubles. Should be brave from the beginning of the chop. This is called scope management.

34. Make the best use of existing products, technology, code
MVM: Don't coding everything yourself. BizTalk and SharePoint are the best examples, both of which can be used as a basis to improve the starting point. Or you can use as much control as you like. Or try to parse a text file with XML instead of yourself; try to use regexp instead of manipulating strings from scratch, and so on. This is the embodiment of "software reuse".

35. Will you stop to tamp down the code at intervals?
MVM: To. Preferably one months or so at a time. It was rumored that the Windows group had stopped for one months at the Stevb command earlier last year to enhance security. BTW, "tamping" the word read "hang", the first sound.

36. Does everyone in your project write the daily report?
MVM: To write. Five minutes is enough, write 10 words or so and tell your team what I did today. In order to communicate, two spur themselves (if the idle day, they will be embarrassed to write).

37. Will your project manager issue a weekly?
MVM: To. Also for communication. The content includes current progress, possible risks, quality status, progress of various jobs, etc.

38. Does your project team meet at least once a week?
MVM: To. Be sure to have a meeting. Programmers hate meetings, but it should take at least 4 hours to add up each week. Includes team meeting, spec review meeting, Bugs triage meeting. Don't let everyone write code.
39. Are there any records of the meetings and discussions of your project team?
MVM: Meeting request and agenda, where someone is responsible for hosting and recording, after which someone will be responsible for meeting minutes, is the main point of effective meetings. Also, each meeting will have to form agreements and action items.

40. Do other departments know what your project team is doing?
MVM: To send some newsflash to the whole big organization. Show your team ' s value. Otherwise, when you are sitting in the elevator, other department people ask: "What are you doing", when you answer the "ABC Project", the other people do not know, that feeling is not very good.

41. All formal communication via email
The advantage of Mvm:email is to avoid repudiation. But also to avoid overdoing, the best way is to use the telephone and face-to-face, and then email to confirm.

42. Establish multiple mailing group for the project team
MVM: If inside the ad+exchange, build distribution List. For example, I will build ABC project Core TEAM,ABC Project Dev TEAM,ABC Project All TESTERS,ABC Project Extended team and so on. This is a convenient way to initiate an email, and it allows the person receiving the email to receive and not be harassed.

43. Does everyone know where to find all the documents?
MVM: Everyone should know. This is called knowledge management (Knowledge Management). The easiest thing to do is to put the document in a centralized file Share, and a better way is to use SharePoint.

44. When you make a decision and make a change, tell everyone why?
MVM: To tell you why. One of the tools of empower team member is to provide enough information, which is one of several principles at the outset of MSF. Indeed, tell me why is human nature, tell me why can have understanding. The Chinese do things like restricting and restricting information, and people who seem to be able to see a certain document are people with identities. Wrong. Authority, power, is not to be able to access information/data, but is not to grasp the resources.

Stay Agile and expect change
MVM: To do that. The requirements will change, and the code that has already been written must be modified. Be prepared psychologically, do not resist change, but expect change.

46. Do you have a full-time software tester?
MVM: Have a full-time test. If you don't have enough hands, you can peer test and swap tests. Don't test your own.

47. Do you have a general plan for your tests to stipulate what to do and how to do it?
MVM: This is test plan. Do you want to do a performance test? Do you want to do a usability test? When do you start testing performance? What is the test pass criteria? By what means, automatic or manual? These questions need to be answered with test plan.

48. Did you write test case first and then tested it?
MVM: It should be so. You should design the reprogramming first, test the case before testing. Of course, things are flexible. I sometimes make the test case on the first pass. As for the first test case redevelopment, I do not like, because not accustomed to, too troublesome, as for others to recommend, then try it anyway.

49. Do you create test cases for various input combinations?
MVM: No, don't make a combination of boundary conditions. Beware of combinatorial explosions. There are a lot of test case tools that automatically generate a combination of various boundary conditions--but make sure you have time to run so many test case.

50. Can your programmers see the test cases?
MVM: To. Let Dev see test case. We all came together for the same purpose: to improve the quality.

51. Do you just grab some people to do usability testing?
MVM: To do that. I look at their own programming interface, how to look is pleasing to the eye. This is called aesthetic fatigue-smelly look for a long time also does not stink, inconvenient permanent also get used to.

52. Do you expect the automatic test to be correct?
MVM: Don't expect too much. In my opinion, in addition to the performance test, or temporarily forget the "Automatic Test" bar, forget WinRunner and LoadRunner bar. For domestic software testing of the status quo, can only "in vain must be too positive."

53. Are your performance tests done after all the features have been developed?
MVM: No way. Performance testing cannot be attributed to the so-called "system testing" phase. Early detection early correction, early death early ascension.

54. Have you noticed the pesticide effect in the test?
MVM: Bugs are resistant and bugs are there. It's normal to find fewer new bugs. At this point, it is best to exchange the area of the test, or use to see other tools and methods, you will find some new bugs.

55. Can someone in your project name the current overall quality of the product?
MVM: To have. When the boss asked about the quality of the product at the moment, Test Lead/manager should answer it.

56. Do you have unit tests?
MVM: Unit tests are available. But there is no unit test is not not, I did not have unit test project, also do success-may be a fluke, may be the relationship between the proficient. In other words, software engineering is a very practical, very engineering, very flexible set of methods, some methods in some cases better than others, and vice versa.

57. Did your programmer throw the code over the wall before it was finished?
MVM: Big bogey. After writing a program, even if you do not unit test, you should run first. Although there is a special tester, the person who does the development can not do a little testing. Microsoft also has a test release document, the program is too bad, testing the right to kick back.

58. Do all the functions in your program have input checking?
MVM: Don't. Although the input check is the key to write secure code, but do not do too much input check, some of the internal functions of the parameters of the transfer without checking input, save a little kung fu. In the same way, it is not necessary to write notes for all functions. Writing a part of the main is enough.

59. Does the product have a unified error handling mechanism and a faulty interface?
MVM: To have. It is best to have a unified error message, and then each error is brought with an error number. In this way, users can see the exact description of the error and the probable cause, based on error number, in the user manual, as is the case with SQL Server errors. Similarly, ASP. NET also must have the unified exception processing. You can refer to the application block.

60. Do you have a uniform code writing specification?
MVM: To have. Code Convention a lot, make a copy to everyone on it. Of course, it would be better if there was a FxCop tool to check the code.

61. Do all of you understand the business significance of the project?
MVM: To. This is the meaning of vision. Don't treat the project as a job. Sometimes think of yourself as a pioneer in the informatization of a certain industry in China, or tell team member every now and then how many millions of taxpayers ' money this project can save for a certain State Department each year. Ordinary things can also have a lofty goal.

62. Are the interfaces and operating habits of each part of the product consistent?
MVM: To do that. To make the user feel like the whole program is written by a person.

63. Is there any cool feature that can be used as a publicity highlight?
MVM: To. This is to enhance team cohesion, confidence. Moreover, "a handsome cover hundred ugly", there are bright spots can cover up some problems. In this way, for customers, will feel the product from the quality point of view is still acceptable. Or, cool feature or bright spots can be an afterthought to quality problems.

64. Shorten the start-up time of the product as much as possible
MVM: To do that. Software startup time (start-up times) is the customer's first impression of performance.

65. Do not focus too much on intrinsic quality and ignore the first impression of the outside.
MVM: Programmers are apt to make this mistake: too much emphasis on performance, stability, storage efficiency, but ignore external feelings. and senior managers, customers are the opposite. These two aspects need to be balanced, coordination these are PM's work.

66. Do you develop according to the detailed product function specification?
MVM: To do that. It is necessary to have a design in order to develop. Design documents, should be clear how the product will run, should take some storytelling methods. Design time do not drill the details, do not drill into the database, code and other specific implementation inside, those are the things behind, step by step can not worry.

67. Do everyone review functional design before beginning development and testing?
MVM: To do. Function Spec Review is used for unity. Moreover, review after the formation of consensus, there will be no one can say "you see, I was opposed to such a design, now suffer the bar"

68. Does everyone always think about the Whole image?
MVM: To do that. Everyone in the project is just making a leaf, but everyone should know what the tree is like in the leaves that they are making. I am against the software blue collar, against the excessive of the software manufacturing as an assembly line, workshop. See article 61st.

is the division of dev work purely vertical or horizontal?
MVM: Can not be simply based on functional modules, or simply according to the performance layer, the middle tier, the database layer. I recommend doing this: first, according to the functional modules, and then each "layer" has an owner to review everyone's design and code to ensure consistency.

70. Do your programmers write program documentation?
MVM: To. But I've heard that Microsoft programmers didn't write until 1999. Therefore, it is not absolute to write or write, lazy sometimes is also possible. See article 56th.

71. Do you want him to write a program during the interview?
MVM: That's for you. I like people to do strings and lists of topics. This kind of question has many loops, the judgment, the pointer, the recursion and so on, neither leans over the test algorithm, also does not favor too to test the specific API.

72. Do you have any technical seminars?
MVM: That's for you. Make an internal tech talk or chalk talk every one or two weeks. Let the team members share the technical experience, the money sent to the outside to training cost-effective.

73. Can your programmers focus on one thing?
MVM: Let programmers focus on one thing. Say, for example, one department has two projects and 10 people, one way is to have 10 people participate in two projects at the same time, each person on each project to spend 50% time, the other way is 5 people go to project A, 5 people go to Project B, everyone 100% on a project. I must choose the latter one. Many people understand this truth, but many leaders practice it as a resource that can be arbitrarily split.

74. Do your programmers exaggerate the time it takes to get a job done?
MVM: Yes, this is common, especially at the end of the project by exaggerating the time needed to make a change, and resisting change by the time. The solution is to sit down and grind, grind off the reverse psychology of the programmer, analyze it together, and make the size of the estimated time smaller.

75. Try not to use virtual Heads
MVM: It's best not to use virtual Heads. Virtual heads means that the resource is not secure,shared resource will reduce resource productivity, easily increase the chance of error, so that the two-person-use people do not have much time to review spec, review Design A dedicated person is better than two people who can only devote 50% of their time and energy. I have suffered a loss: 7 part time tester, found bugs and dry work, add up to less than two full-time. See article 73rd. 73 is for programmers, and 75 is for resource manager.