(I didn't "publish" here for a year, I put it out of the translated article half a year ago to prove that I am still here :). It is about project management methods. Demporates bad, there is a problem, everyone is mentioned, let me learn. If you like, I will take the next book ...)
Methods of Project Management
by Vox Guo translation warton (source unknown) This article is not called methodology but methods, because it concentrates on the specific ways used in the software development procedure. It focuses more on practical applications than on academic analysis. But as you all known, these CONCLUSONS ARE BASEDOME. SO it is not confusingiffness.
This article is not named methodology, but is called method because some of the specific methods used in software development are not described here. Relative to theoretical analysis, this paper focuses on the application of application software development practices. But as you know, these conclusions are based on past engineering experience and my personal feelings. All, please don't be used by my article, if there is some wrong words here. Therefore, any further discussion and recommendations are welcome.
1. OverviewFor the software development procedure, the most pivotal factor is controllable. A disordered project directly causes high cost, prolonged developing period and finally low-quality software product. Of course that is not the result that we would like to see.
1. Overview
For software development processes, the most critical elements are controllable. A chaotic project directly leads to high cost, delayed development period and low software products. Of course, this is not what we want to see.
In my opinion, when a project finishes, we need not only a stack of software, but also little maintenance (means high quality) and a bridle-wise team and a heritable developing procedure. Inheriting means accumulation and continuity. That is why many great companies can rapidly issue new products to survive from the competitive market. It is just like the words from a famous scientist, "I have gained so much success. Because I am standing on the shoulder of giant."
According to my opinion, when an item is over, we need not only a bunch of software, but there are less maintenance costs (meaning high quality) and well-trained teams and can inherit the development process. Inheritance means accumulation and continuity. This is also why so many companies can quickly issue their new products to fortunate to market competition. This is like the famous scientist (Newton Translator's Note), "I succeeded because I stand on the shoulder of the giant." For those developing little-sized companies, it is not worthy to manage software project entirely according to procedure of CMM (Capability Maturity Model for Software), because the cost is so high that these companies will lose their flexibility. Software developing, however, should Conform to Some Basic Rules for Software Quality Management. It is helpful for the Quality of Final Product.
For those small development companies, it is not worthwhile to manage software projects based on CMM (Capability Maturity Model For Software Software Capability). Because this cost is too large, it will lose their toughness. For software quality management, software development should comply with certain basic rules. This will be helpful for later product quality.
If I am asked to describe the project management using only one sentence, I'd like to say it is controllable procedure. What I mean is that the quality and schedule should be controllable whichever software phase you are in.
If I let me use a sentence to describe project management, I want to say that it is a manageable and manipulative process. I actually said that both the quality and progress should be controlable whether in the stage of software development.
2. Tips for Software DevelopingHerein I list some tips for software developing. As the background and habits are different, these tips probably are not available to every person. But if these tips will bring you some further thoughts, I think they are valuable.
2. Some tips developed in the software
Here I list some prompts for software development. These tips may not be effective for anyone due to background and habits. But if these tips bring you some in-depth thinking, I think they are valuable.
2.1 Software EstimationThe working-out for any plan is based on the software size. In case we grasp the software size and architecture cognition for software project, we can originally arrange the manpower resources and schedule. This arrangement must not be accurate. As the software Developing Procedure Goes Along and The Undware Deepens, HoWever, Software Estimation Will Become More And More Accurate and Also The Plan Arrangement Will Press Close To Practical Case.2.1 Software Budget
Any planning of the plan is based on the software size. Once we seize the understanding of the software size and architecture of the project, we can initially arrange human data and progress. This arrangement does not have to be accurate. When the software development process is advanced, after understanding, the software budget will become more accurate and planned to be arranged in any case. . . .
In the initiation phase of software project, we should carry out the first software evaluation The software project can be divided into some correspondingly independent functional modules. (Note: the modules are different from those modules defined in HLD phase) Functional points of every module. . should be nailed down According to these functional points, we can evaluate the size of the module through our software common sense. (note: some methods are provided by software engineering) Meanwhile we can also realize which module is most difficult and which module is most significant. Once we have these data, our rudimentary manpower resources and schedule are not far from us. At the same time, we can keep our eyes on those difficult and significant modules on which more resources are used.
In the initial stage of the software project, we should implement the first software software assessment. Software projects can be broken down into some functions of relatively independent functional modules (note: The modules here are different from those defined in the HLD phase). In addition, we can also realize which module is the most difficult and which is the most important. Once we have this data, our fundamental human data and progress are not far from us. At the same time, we can keep our vision above these difficulties and major modules, that is, those who have invested larger resources.
At the end of every software development phase, such as SRS and LLD, we should re-estimate our software size and adjust our project plan. In fact it is a review procedure to the project plan. The advantages of this review are to make good use of our project resources and find the existing problems in the project. Only through these continuous updates, can the project plan really direct our developing activities. Otherwise it will become a piece of useless white paper with the project going on. Then you will feel That The Schedule is always controlled in your hand. Of Course, IT IS a Very Pleasant Feeling. End of each software development phase, as SRS and LLD, we can re-evaluate the size of the software and adjust our project plan. In fact, this is a project plan review process. The advantage of this review is to better use project resources and discover project issues. Only through these continuous updates, the project plan can really guide our development behavior. Otherwise, as the project is carried out, this will become a white paper that is not used. So you will feel the progress is always under your control. Of course, this is a very pleasant feeling.
2.2 Discussion and Review Software development is a team project. So we think that team spirit is very important, even it is a key to the success of the project. Usually there is not so much time left to software project because of market competition. Every Project Manager, Therefore, SHOULD PURSUE DOING A Thing Well in One Time. Discussion and Review Are Good Ways to Reach That Goal.
2.2 Discussion and review
Software development is a team project, so we believe that the team spirit is very important, and it is a key to the success of a key project. Generally, we don't have enough surplus time to leave a software project due to market competition. Therefore, a project manager should track what is doing at any time. Discussions and reviews are a very good path to the purpose.
A good project must have a good developing procedure. It is document that reflects this good developing procedure. How can we finish top-quality documents in limited time? I think there are three significant factors. First of all, before you begin to write, discussion among related team members is required. This discussion includes not only technical problems, but also some details such as document style. Once these problems are solved by the team, the following work is only documental work which is a piece of cake. Secondly, in the process of writing document, if you find new problems that you can not understand or you think the previous design is wrong, please do not hesitate to put forward these problems to discuss with your colleagues. Through this continuous discussion, we can converge the wisdoms of all the team members to assure there are few errors left in the final document. With the project going on, our understanding will deepen. Then we maybe find some ignored sectors which wi LL Influnce Our Design. So The Third Factor To Get Top-Quality Documents, I Think, is The Review and Upgrade of The finished document WHENEVER WE HAVE New Findings must have a good development process. It is a document that reflects the development process. How do we complete high quality documents in a limited time? I think there are three major factors. First, the discussion of the relevant team members before you start writing. This discussion includes not only technical issues, but also details such as document style. Once these issues are solved by the team, the next document work is just a snatch. Second, in the process of writing a document, if you find new problems, you can't understand or you know the previous design is wrong, please don't hesitate to discuss these questions and discuss it with your colleague. With this continuous discussion, we can gather a wisdom of all team members to ensure less errors in the final document. As the project progresses, our understanding has also deepened. So we might find some partially ignored parts that will affect our design. So, whenever we have new discovery to get a high quality document, I think the third factor-review and update the document that has ended is very necessary.
Undoubtedly, for a limited-period project, discussion and review mean abundant cost of time and it is not easy to arrange in most cases, especially in case of work occurring synchronously. The key to resolve the problem is elaborate partition for time and manpower. Giving an example, if we have some documents to review next week, it is reasonable to finish arrangement in this weekend. This arrangement includes attendees, time, sites and duration of every review. Only through this careful arrangement, can we avoid conflict of review . Usually before the formal review, we leave time to team members to prejudge the review content. in the review meeting, in order to save time, the only aim is finding problems, not solving problems. Further discussion should be held after the review meeting No doubtful, for a time-limited project, discussions and reviews means that you have to spend a lot of time, and in some cases this is not Easy to arrange, especially when working simultaneously. The key to solving this person's problem is to carefully divide time and humanity. Give an example, if we have some documentation next week, we need to review this weekend. This arrangement includes the reviewed participants, time, location, and duration. Only through this careful arrangement, we can avoid review conflicts. Usually before the formal review, we should leave time to give the project team members to the content of the judgment judgment. At the review meeting, in order to save time, the only purpose is to discover problems, not solve problems. In-depth discussion should be held after the conference. Together, we should take steps to track problems found at the review meeting to avoid missing.
It is worth using plenty of time on discussion and reviews, because many personal errors are exposed in discussion and reviews. At the end of our project, we find that the value of discussion and reviews is incredible. Additionally, through this continuous communication and cooperation WE KNOW EACH Other Better and The Effectiveness of The Team Has Been Stregthened.
It is valuable to spend a lot of time to discuss and review, because many people are exposed in the discussion and review. At the end of the project, we found that discussions and reviews are incredible. In addition, through this continuous exchange and cooperation, we have more understanding of each other and the team's effectiveness is also reinforced. 2.3 VENTURE Management
Venture occurs everywhere. In the process of software developing, we will meet many difficulties and we will indeed try our best to overcome them. On the other hand, we still need to forecast the ventures we will encounter in the future and take action to decrease The Influence of Those Potential Ventures. this is the concept of venture management.
2.3 Risk Management
Risk is everywhere. In the software development phase, we will encounter many difficulties, and we should truly try to overcome them. On the other hand, we still need to foresee our possible risks in the future, and take action to reduce this potential risk on the project. This is the concept of risk management.
For a software project, the most serious venture is manpower. Most projects are divided into different functional modules managed by individual engineer. Can you imagine some engineer leave the company suddenly? To avoid catastrophic sequent, manpower backup plan should be initiated in the beginning phase OF Software Project.
For a software project, the most serious risk is human resources. Most items are split into functional modules managed by separate engineers. Can you imagine a sudden leaving of an engineer to the company? In the beginning of the software project, in order to avoid the swollen surface of the disaster, the human backup plan should be initiated.
How can we process manpower backup plan in case of lacking engineers, which is occurring in many companies? Although we have no way to make some engineers backup the other engineers, it is possible that some engineers are partly in charge of other modules. At least they must understand the basic principle of other modules. This thought can be realized in the process of discussion and review if we make management reasonably. If one engineer is selected as a candidate to a module, he should take part in all the discussion and review related to this module. that is to say he is relative to this module. When a project manager lays a course, therefore, he should consider this relationship. As long as we stick to this method, that engineer or more engineers will be familiar with That Module Which is not in the scope of his or their charge essentially. As A Result, EVEN IF THIS VENTURE BECOMES Reality, the Project Can Survive More SMOOTHLY. How do we deal with the human backup plan? This is happening in many companies. Although we have no way to make some engineers as other backups, it is also possible that some engineers are partially controlled by other modules. At least, they must understand the basic principles of other modules. If we do properly, this idea can be implemented in the process of discussing and reviewing. If an engineer is elected as a module, he should participate in all discussions and reviews about this module. In other words, he has a relationship with this module. Therefore, when a project manager arranges a process, he should consider this association. As long as we insist on this method, the engineer or more engineers will be familiar with the module that is not asking them. As a result, even if this risk becomes practical, the project can also survive more smoothly.
There are other ventures beside manpower, such as lab equipment, tool software and test environment. All these ventures should be recorded and traced. Meanwhile the project should have a plan to reduce the effect of the ventures. While one venture disappears, the record related to this venture should be closed. At the end of every developing phase, project manager should call a meeting to discuss which venture we will probably meet in the next phase. It is just like a saying, "Although it does not rain, we should "In addition to manpower, there are many other risks, such as experimental equipment, tool software, and test environments. So these risks should be recorded and tracked. Between, the project should have a plan to reduce the impact of this risk. When a risk has passed, this risk record should be closed. At the end of each development process, the project manager should be held a meeting to discuss which risk may occur in the next stage. That is to say, "If there is no rain, we should also prepare umbrellas."
3. Epilogue
There are many factors determining the success of a software project. After all person with ability is the most important resource in a company. For most companies, we think that controllable and regular developing procedure is also an essential condition. Efficiency from the combination of person WITH ABILITY AND FINE Developing Procedure Will Be Incredible.
Conclusion
There are many factors that determine the success of the software project. After all, people have the ability to have the most important resources. For most companies, I think that controlled, standardized software process is also a basic condition. The efficacy of the joint and good development process from talents will be incredible.
