How to start Project Management (2)

(3) What documents, tools, and efforts do we need?

Software projects cannot be separated from documents and management tools. If your projects do not have them, start from now on. Is there more documents, the better? The old saying is good. The right one is the best. Small and sophisticated documents and tools will make us get twice the result with half the effort. Large and complete documents will make us exhausted and lost in the sea of documents.

We writeCodeAll of us know that incorrect comments are more terrible than no comments. Similarly, documents that are not updated in time are more terrible than documents that are not, because documents are project comments. So is it necessary for us to update documents that we have never used at all? Obviously, this is not necessary, and it is a waste of resources. The document is actually a tool that provides a basis for development and traces the development process and records the development results. We only use it to make it necessary to exist.

So there are too few or no documents at all, isn't it more concise? I want to say: Isn't it more concise to not write code? Joke is a joke. If there are no documents or too few documents, you may also encounter problems: the process is not traceable, and some very important logics are not recorded, when it is necessary, the team members should stick to each other, and even the customer needs to confirm it again, but the customer thinks that we are not professional enough. Some very important designs are not recorded, which leads to difficulty in code maintenance, so that the maintenance staff shouted at what spam code the developers wrote and what spam design they made. Some designs are very clever and worth learning. However, they are scolded By beginners like me because they have not left any records.NTimes. When reflecting on whether you are not smart enough, should I also let the code writers reflect on why they failed to keep some records?

One idea is that the best design is code, which means code is design. The Code should be very good and readable, so that people can understand it at a Glance. I totally agree. If the code is written to this level, the document is useless. So ask yourself, are you doing this? If yes, there is no documentation, no problem; if not, please write down the important things. So what are important?

Which are required, Which areOptional. Which documents are more important depends on the specific circumstances of the project, especially the project size, logic complexity, personnel situation, and many other factors. In my projects, some of the most important documents and tools I personally think are described as follows:

1,Function manual (Functional specification)------Priorities are divided by independent functions. Each record is a deliverable and a function. The entire document describes the delivery functions and priorities of the entire project. Everyone in the project should pay attention to this document: test is used to write test cases; developers use it to decide which function to develop first;PMUse it to view the completion and verification status of the function. Generally, it should not contain too much content (determined by the project scale). I think a function that can be operated independently can be described in at most two lines. As for the understanding of this function, it should be responsible for itsProgramPersonnel to complete.

2,Core flowchart. This flowchart may describe the process of using the system, the data flow in the system, or the form flow. In short, it describes a process that is very important to users. This graph is sometimes replaced by other graphs, such as sequence graphs.

3,Deployment document. This document describes how to deploy the system. It is not necessarilyWordDocument, or it may be only oneBatFile. This document describes how to deploy the project, how to deploy the project, what files are needed, what hardware support is required, and what to pay attention. Deployment has never been very important. Do you think that deployment is not enough if something is made? Actually not. After a certain period of development, many of the configurations accumulated during the development process, environment requirements, and real deployment will be forgotten, therefore, deployment may take a lot of unnecessary time. I think this is what Microsoft wants to do.Daily buildOne of the reasons, every dayBuildOf course, there is no problem with the deployment of an available version. At the beginning, we may not need to spend every day.BuildOne version, but it takes at least one week or two weeks to deploy one version. Every time you deploy an automated script or document, it will make your final launch very easy.

4,Test cases. I am not a tester, and I think the test has never been done. Objectively speaking, I think the case should be written with great care, just as the user is actually using the software.The project should be designed and developed to meet the needs of use cases, rather than thinking of use cases after development., Test, find the problem, and then modify it. Think about it later. This may be the reason why the test-driven development is generated. We know that the cost of Error modification discovered by users is higher than that detected by ourselves. Similarly, the cost of the problem solved during the design and development phases is much lower than that found during the test phase. The sooner the problem is discovered, the easier it is to solve and the lower the cost.

5,BugManagement tools. This management tool can beExcelOf course, I do not recommend this. After allExcelBut it is not so automated. HoweverExcelIt is enough to automate an information system that can record problems and transmit data. I recommend that you useBug trackerThis isDOTNETDeveloped open-sourceBugManagement tools can also manage requirements, which is very practical.

The five above are what I think are the most important. I think it is essential to start the project management stage. The following are some of the options that you can choose based on your situation.

6,Core class diagram. This may be optional, because sometimes the class is not so complex, so there is no need to have this graph; on the contrary, it needs to be recorded.

7,Database design. The database design document may be inReview.

8,Inter-system interface diagram. If the product has several subsystems, suchWeb ServiceAnd so on. I think we need a diagram describing the interface and interaction between systems. This diagram should be developed in the early stages of design for everyone to use and be updated and focused at any time.

With documents and tools, is everything right?OKNow? No, just as a large and comprehensive document cannot help us succeed. Having a document doesn't mean that the project can succeed. How to maintain and use these documents and tools is very important. Every document should be maintained by someone. Who will do this? I think the project manager should often hold a functional instruction book for meetings. It can also be seenWBSThe initial version can be marked with the status and priority. Everyone should be familiar with the flowchart and propose to test the flowchart at any time.ReviewA person should be designated to be responsible for building. This does not take a lot of time, but requires careful and perfectionist spirit. Testers naturally need to maintain test cases. Everyone, especially developers, there should be a kind of consciousness, that is, once you think of the important logic, whether it is the business logic or the system'sAlgorithm, Should be recordedBugManagement tools.BugManagement tools can record these scattered but important items for future convenience.

Here, I also briefly talked about some of my views based on my own experiences. This is not a golden rule. I have to say that what suits you is the best.

(4) Code specification Selection

Code specifications are inevitable for development. Some specifications will be learned from the last course, but each company is different. What specifications should we comply? I personally think that a qualified programmer should be able to adjust himself to any specification at any time, which is a kind of professionalism and ability. There are also some principles for when to follow the rules.

1,It is developed based on the existing system (CODE. In this case, we should try to follow the specifications of the original system, whether it is naming or commenting. If you have to write according to your habits, the system will have two completely different types of code, which is a nightmare for future maintenance. However, following the original specifications is not an error. If you find that the original specifications cause certain problems, you must immediately correct them.

2,Create a team to develop a new system. The team members in the newly created team may come from different environments, and the tendency to choose specifications must be different. What should we do at this time? At this time, the project leader should organize everyone to make a decision, discuss how to define variables, how to name controls, and so on. The project manager should make a clear decision when there are different opinions and no one can convince anyone. At this time, it is far better to choose a specification than to accommodate two people at the same time. Otherwise, there will be two specifications in the new system, which is also a nightmare of maintenance.

3,The stable team develops new systems. This situation is much easier. After the team is stable, the team members gradually understand each other's habits. After mutual learning, it is easier to reach a compromise. You only need to make the new members adapt.

Some people may think that the code specification is no big deal and its functions are correct.BugNo? Of course, if noBugIt must be okay, but a system is not running until it retires.BugWho has seen it? After I did some O & M work, I gradually learned that reading code of different styles is like reading code at the equator for a while and at the south pole for a while, which is very painful, sometimes it may even cause many system inconsistencies, greatly increasing the maintenance workload. Isn't one of our goals to increase the maintainability of the system?