Project Management Summary

1. Have your project team used the source code management tool?

It should be used. VSS, CVS, PVCS, ClearCase, CCC/Harvest, FireFly, and SVN are all supported. My choice is CVS. Svn (TortoiseSVN) is also quite good.

2. Have your project team used the defect management system?

It should be used. ClearQuest is too complex. My recommendation is BugZilla.

3. Are your test groups still using Word to write test cases?

Do not use Word to write Test cases ). Run the junit test framework using jbuilder.

4. Have you set up a portal for your project team?

There must be a portal for storing the Contact Info, Baselined Schedule, News, and so on.

5. Do you all know who to look?

You should know. Each Feature should have at least one Owner. Of course, the Owner can continue Dispatch to others.

6. Someone said, "I thought ..." ?

To eliminate "what I think ". Never assume anything.

7. Are all people in your project team sitting together?

Yes. Against Virtual Team, it is best to sit together if you can sit together, which has many advantages.

8. Does your schedule reflect the latest development progress?

It should be reflected. The progress bar on the MS project.

9. do you estimate your workload by yourself?

Everyone should make their own estimation. Estimate the workload from the bottom, rather than from the top down. Unless there are other reasons, such as fixed political tasks.

10. Do your developers work overtime from the very beginning of the project?

Do not. Do not get tired at the beginning. Working overtime from the very beginning of the project can only indicate that the project progress is unreasonable.

11. Is the Buffer Time added after each small task in your project plan?

No. The Buffer Time is added after each small task, which can be easily consumed. Buffer Time must be added to the entire segment before a Milestone or checkpoint.

12. It is worthwhile to spend more time, from 95% to 100%.

Especially when the project is not busy in the future, stick to it. This will bring a qualitative difference to the product.

13. Have the reproduction steps been written during registration of new defects?

Yes. This is a means of communication between Dev and Test. Face-to-face communication is required, as well as Repro Steps. Therefore, the format of bug writing on bugzilla is specified.

14. Do you have any prior agreements on priority of defects?

Must be defined. Bugzilla can help us achieve this goal.

15. Are all defects closed by the registrants?

The Bug should be disabled by BugAdmin. Mulder is responsible for this. Dev cannot disable bugs without permission.

16. Do your programmers hate to modify old code?

Dislike is normal. The solution is to organize the Code Review and set aside time. XP is also a method.

17. Do your project team have their own Logo?

You must have your own Logo. At least have your own Codename, the model name on CVS.

18. Does someone keep checking-In code for a long time?

No. For most projects, Check-In should be performed In a maximum of two or three days.

19. Have you filled In comments when checking-In code?

You have to write at least one or two sentences, for example, "Fixed Bug No. 225 ". If you pull to a height, this is also part of the "configuration audit.

20. Can you compile all source code into an installation file at once?

Yes. Refer to the zhanhua project on realserver. This is the basis for Daily compilation (Daily Build. It must also be automated. Three things are required for software projects/product development: 1. bug management; 2. source control; 3. daily build.

21. The simpler the design, the simpler the better.

There may be endless troubles in the future when there is one more sentence in design. We should be brave in cutting from the very beginning. This is called scope management.

22. Use existing products, technologies, and code as much as possible. We started developing with advanced languages.

23. Everyone in the project team wrote a Weekly Report, which is our Weekly work Report. One is to communicate, and the other is to spur oneself.

24. The project manager is also responsible for issuing the Weekly Report, which includes the current progress, possible risks, quality status, and progress of various jobs.

25. Do your project team have at least one plenary meeting every week?

Yes. Make sure you have a meeting. Programmers hate meetings. Includes team meeting, spec review meeting, and bug triage meeting. Never try to write code. Someone in the meeting is responsible for hosting and recording.

26. Do other departments know what your project team is doing?

Send some Newsflash to the entire organization. Show your team's value. Otherwise, when you are sitting in the elevator and people from other departments ask, "what are you doing?" And when you answer "ABC Project", others don't know at all. That is not a good feeling.

27. communicate in a timely manner via MSN and formally communicate via Email.

28. Does everyone know where to find all the documents?

Everyone should know. Generally, project-related documents are stored in the $ {cvs} \ {project} \ doc folder.

29. Have you told everyone the reason when you make decisions and make changes?

I want to tell you why. One of the methods for Empower team member is to provide sufficient information, which is one of the principles of MSF. Indeed, tell me why is a common human condition, so tell me why can have understanding. Chinese people like to restrict their work and restrict information. It seems that the person who can see a document is a person with an identity. A big mistake. Authority and power are not about access to information/data, but about access to resources.

30. Stay agile and keep CT change should be like this.

The requirement will change, and the code already written will be required to be modified. Be prepared and do not resist change. Instead, perform CT change.

31. Do you have a full-time software tester?

Dedicated testing is required. If there are not enough people, you can perform peer test and exchange the test. Never test your own.

32. Can your programmers see test cases?

Yes. Let Dev see Test Case. We all come together for the same purpose: to improve quality. Only write Test Case for the required business. Do not add one Test Case to each other. In other words, software engineering is a very practical, very engineering, and very flexible set of methods. In some cases, some methods are good methods.

33. Do you need to take some people for usability testing?

To do so. You can easily view your own program interface. This is called Aesthetic Fatigue ?? After a long time, the system will not be smelly. If it is inconvenient for a long time, it will become accustomed to it.

34. Are you expecting automatic testing?

Don't expect too much. In my opinion, in addition to performance testing, we should forget "automatic testing" and "WinRunner.

35. Does your performance test work only after all functions are developed?

This is not the case. Performance tests cannot be classified into the so-called "system tests" phase. Early test, early correction, early death, early promotion day.

36. Have you noticed the Pesticide Effect in the test?

Worms are resistant, and bugs also exist. It is normal to find fewer and fewer new bugs. At this time, we 'd better exchange the area for testing, or use other tools and techniques to discover new bugs.

37. Can someone in your project team tell you about the overall quality of the product?

Yes. When the boss asks about the current quality of the product, Test Lead/Manager should answer the question.

38. Did your programmers throw the wall after writing the code?

Taboos. After writing a program, you should run it yourself, even if you do not perform unit tests. Even with dedicated testers, developers cannot perform tests at all. Microsoft also has the statement "Test Release Document". If the program is too bad, the Test has the right to kick it back.

39. Do all the functions in your program have input checks?

No. Although the input check is the key point of write secure code, do not perform too many input checks. Some internal functions do not need to check the input when passing parameters. In the same way, it is not necessary to write comments to all functions. Write a part of the main enough.

40. Does the product have a unified error handling mechanism and Error Reporting interface?

Yes. It is better to have a unified error message, that is, the errorpage declared in tomcat.

41. unified code writing specifications are required.

42. do each of you understand the commercial significance of the project?

Yes. This is what Vision means. Do not treat projects as work only. Sometimes you have to think about how much taxpayer money this project can save for a certain national department every year, or tell the team member from time to time that it is a pioneer in informatization for a certain industry in China, this gives us motivation. Ordinary things can also have a lofty goal.

43. Are the interfaces and operation habits of various products consistent?

To do this. Make the user think that the entire program is written by a person.

44. Shorten the product startup time as much as possible.

The Start-Up time is the customer's first impression of performance. Therefore, the released version must have the pre-compilation function of jsp.

45. Do not focus too much on internal quality and ignore the first-eye external impression. programmers can easily make this mistake: they are too concerned with performance, stability, and storage efficiency, but ignore external feelings. The opposite is true for senior managers and customers.

46. do you develop according to the detailed product function manual?

To do this. So we have RED (requirement document) and SDD (design document ).

47. Did everyone carefully review the function design before the test?

. Therefore, in addition to the simple function instruction document of the project included in the test plan, it is equivalent to a simplified user manual.

48. Do everyone always think about The Whole Image? To do this. Although everyone in the project is only manufacturing a leaf, everyone should know how the tree where the leaf is made is. I am opposed to the blue-collar software, and I am opposed to taking software manufacturing as a pipeline and a workshop too much.

49. Is the Dev work divided vertically or horizontally?

We are now divided by functional modules.

50. Did you ask him to write a program during the interview?

Yes. I like making people do strings and linked lists. There are many loops, judgments, pointers, recursion, and so on in this type of question. They neither tend to take over algorithms nor take over specific APIs.

51. Do you have any technical exchange lectures?

Yes. The internal Tech Talk or Chalk Talk will be conducted during the weekly meeting to share the technical experience among the team members. Sharing is a pleasure. In this regard, huson is doing well.

52. Can your programmers focus on one thing?

Let programmers focus on one thing. For example, if a department has two projects and 10 people, one way is to have 10 people participate in two projects at the same time, and each project spends 50% of their time; another method is five people go to project A, five people go to Project B, and each person is 100% on A project. I must select the other one. Many people understand this truth.

53. Will your programmers exaggerate the time required to complete a job?

Yes, this is common. In particular, it will exaggerate the time required for a change later in the project to resist the change. The solution is to sit down and slowly sharpen the programmer's reverse psychology, analyze it together, and reduce the granularity of the estimated time.