Shulou(Shulou.com)06/03 Report--

This article mainly introduces "what is the knowledge of software project management". In the daily operation, I believe that many people have doubts about the knowledge of software project management. I have consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "what is the knowledge of software project management?" Next, please follow the editor to study!

Traditional methodology

The traditional project management model mentioned in this paper refers to the project management framework which has a long history, pays more attention to framework and methodology, and is relatively stricter at the same time. The typical traditional software project management mode is the waterfall flow development mode (Waterfall), which is the development mode adopted by many traditional software projects, in which the Gantt chart is also widely known, and even becomes the symbol of project management. In addition, the more popular traditional project management framework is PMBOK (full name Project Management Body of Knowledge) in the United States, which is a project management guide edited and issued by the global project management member organization PMI, and is also the basis of professional project management certification PMP. It can basically be regarded as a "driver's license" in project management. The IT project management certification issued by the British government, like PMBOK, is also a global authoritative software project management framework, which is more suitable for large-scale projects; in addition, there is 6 Sigma, which pays attention to quality management, which is completely different from other methodologies, which emphasizes quality priority and is more suitable for manufacturing and other industries that need high-precision quality control. This article does not intend to introduce all the project management methodology, readers who want to know more about it can refer to the introduction of Project Manager.

Waterfall flow development model

The so-called waterfall flow development pattern (Waterfall) is easy to understand literally: the whole development project consists of many tasks and subtasks; each task has a corresponding planned start and end time; there is usually a dependency and sequence between tasks; if the planned execution time of the task is visualized on the Gantt Chart, it looks like a waterfall flow. The following is a typical project management Gantt chart.

The above Gantt chart reflects the system development life cycle (SDLC, full name System Development Lifecycle) of a software project, including requirements analysis (Requirements Analysis), system design (System Design), development (Development), testing (Testing), acceptance (Closing) and other stages. Requirements analysis is usually in the initial stage of a software project, while testing and acceptance are usually in the final stage of the project. In the waterfall flow development model, the project tasks are linked and closely linked, and the project manager can see the whole project at a glance in the Gantt chart. By planning project tasks and designing Gantt charts, we seem to expect to be able to accurately predict the project cycle and completion time.

However, "the ideal is very plump, the reality is very bony". The biggest problem with the waterfall flow development model comes from its low tolerance for uncertainty. Nowadays, the market environment is changing rapidly and business opportunities are fleeting. The survival pressure of enterprises no longer allows the development team to spend a lot of time on requirements analysis and system design. Many traditional software companies spend months or even a year in the analysis and design stage, and then spend months or even years to develop, test and launch products, only to find that end users are dissatisfied or even refuse to use them. a lot of time and labor costs have been wasted. This is a lesson learned by many IT companies with their blood. Nowadays, enterprises prefer to have a more flexible software project management framework to meet business development.

PMBOK

As mentioned earlier, the PMP certification supported by PMBOK is the "driver's license" in the project management industry, because the management framework defined in PMBOK is applicable to almost any industry. It was born in the 1970s and has been released to version 6 after decades of development. it can be said to be the most well-known and authoritative project management guide. To put it simply, PMBOK summarizes project management into 10 areas. Through the system management of these 10 areas, we can effectively control the progress, cost, resources and other factors of the whole project, ensure the success of the project, and control the risk to the maximum extent. Readers who want to learn more about PMBOK can refer to PMI's official website.

PMBOK is not only applicable to the IT industry, various industries can use its project management framework, so it is a large and comprehensive methodology. Including the waterfall flow development pattern mentioned earlier is also an implementation approach in some areas of PMBOK. They are not mutually exclusive. Similarly, the methodology of PMBOK involves many concepts, so it also appears more formal, in which the statement of work (SOW, full name Statement of Work), Charter, Closing Report can be used as official documents of the project, so it is widely used in large projects.

Other

The author does not have in-depth contact with PRINCE2 and 6 Sigma, so I will not expand in detail.

Agile development model

In the context of the rapid development of the IT industry, there are very few IT practitioners who have not heard of agile development (Agile Development). Agile development, literally, is a project management approach that pays great attention to flexibility and interaction. In the process of practicing agile management, project teams can jump out of the traditional project management framework and become more "agile". Those seemingly immutable goals, deadlines, and even deliverables can be flexibly adjusted according to the actual situation in the agile framework. Like Mongolian cavalry without heavy armor and large-scale baggage bondage, agile development teams can quickly adapt to changes in the battlefield environment, allowing them to break through enemy defenses flexibly and easily.

Agile development features

Agile development has three major characteristics.

Driven by the development cycle. Each cycle usually lasts 1-4 weeks, ensuring that deliverables in each cycle can be evaluated frequently, thus allowing development efforts to focus on product optimization.

Based on the iterative cycle. Each iteration cycle is usually fixed, so there is always a valid delivery at the end of the cycle.

Open to customers. Customers can see the semi-finished products at the end of the cycle, thus improving transparency and interaction.

Significance of agile development

The biggest difference between agile development and traditional development model is that agile development does not require the execution plan of the entire project task in advance before the project execution. In agile development, the whole project is divided into more controllable phases, and project milestones (Milestone) are set at the completion of the phases. When the milestones are reached, the customer (Customer) and related stakeholders (Statekholder) can provide feedback according to the phase deliverables (WIP, full name Work in Progress) to provide reference for the next phase of development. In such a continuous "Planning-> Development-> feedback-> Planning->." In the periodic development model, the final delivered products are likely to be closer to what customers expect, so as to improve customer satisfaction and avoid a lot of waste of resources. In the global bestseller Lean Entrepreneurship, the author mentioned that the biggest waste of enterprises comes from "rework". Therefore, by adopting the agile development model, the project team can effectively avoid the risk caused by the change of requirements. This enables enterprises that practice agile development to have anti-vulnerability and gain the ability to adapt to environmental uncertainty through constant iteration and learning.

Iteration / period / sprint

A core concept in agile development is Iteration, also known as Phase or Sprint. This is the minimum unit of time in agile development and usually lasts 1-4 weeks. The iterative process is actually a process of constantly optimizing the product. At the end of the iteration cycle, the project team usually completes some or the entire (possibly imperfect) product and receives feedback from customers or relevant stakeholders to provide reference for the next iteration. For example, in an advertising background management system development project, the first phase development team developed a very basic background system based on the initial simple requirements, with only the core functions of advertising and viewing data; the project team presented the first phase delivery to the end user at the Sprint 1 wrap-up meeting and told the end user that it was not the final product End users suggest some improvements or report some Bug; based on the actual usage scenario. In the next phase, the project team can adjust according to the feedback of Sprint 1 and schedule the optimization task and Bug repair task in Sprint 2; then iterate over and over again. In this way, after each iteration is completed, the final delivery will be closer and closer to the optimal state.

Related roles

There are several important roles in agile development.

Product owner (Product Owner). Mainly responsible for communicating with customers, relevant stakeholders and the development team, developing user stories (User Stories), and the need to continuously work with the development team to ensure the progress of development.

Development team member (Development Team Members). Project task implementers, usually developers, designers, testers, etc.

Process Manager (Scrum Master). Be responsible for the smooth implementation and development of the whole Scrum process in the project, and solve the communication obstacles between customers and developers. This role can overlap with the product owner.

Relevant stakeholders (Stakeholders). Not necessarily directly responsible for the product, but may be indirectly involved in the process of using the product.

Daily station meeting

The daily station meeting (Daily Stand Meeting) is a short meeting that lasts about 15 minutes for project team members to communicate face to face every day. The main purpose is to track the progress of project development tasks, solve problems encountered in the implementation of tasks, and coordinate resources. Don't simply think that standing meetings are "standing meetings". First of all, standing together can make the project team members focus their attention and focus on the project tasks; secondly, the shorter meeting time can keep the whole meeting from the theme, save time and improve work efficiency; in addition, the daily station requires everyone of the project team members to speak, which increases the participation of the team members. The picture below is an example of a daily station meeting.

Kanban

Kanban is a management tool in lean production of Toyota JIT (Just in Time). It sets different states for project tasks, usually Backlog, To Do, In Progress, Testing, and Done. Each task estimates how long it will take to complete, usually by hour. Another important task attribute is priority. During the backlog phase (Backlog), development team members need to determine the time required for the task based on their experience and expertise, and define the priority of the task. Different types of tasks are marked with different colors. This kind of viewing version can play a great role in the daily station meeting, because it is clear and intuitive and can be clear at a glance. When a task changes state, such as a developer taking out a task card from Backlog, it will be placed directly in the To Do. The following picture is a schematic diagram of Kanban.

Of course, we now have more modern tools to manage the process of Kanban without having to manually design a Kanban or buy a lot of stickers. Some popular tools include Trello, Zen Tao, Teambition and so on.

Burnout diagram

Burnout diagram (Burndown Chart) is an effective tool to track the progress of a project. It is a curve decreasing over time. The horizontal axis is the duration, and the vertical axis is the total value of the remaining story, the estimated total man-hours of the task, and so on. The burnout diagram usually has two curves: one is the estimated ideal decline curve, which usually decreases linearly with time, and the other is the actual decline curve, which indicates the actual remaining value or working hours at a certain time. If the actual curve is higher than the ideal curve at some point, it means that the current progress is lagging behind; on the contrary, if the actual curve is lower than the ideal curve, the progress is ahead. The following picture is a schematic diagram of burnout.

User stories and project tasks

In agile development, user stories (User Story) are easily confused with project tasks (Project Task). They are described from the perspective of different roles. The user story is simply the usage scenario of the end user. It is usually collected by project leaders from customers or end users, and sets the Value and Priority of each story from a business point of view. The project task is the actual development task decomposed by the development team according to the description of the user story, combined with the actual system architecture, technical environment and other factors, which is more landing than the user story. Therefore, it can be said that the project task is designed to realize the user story. The value and priority of user stories usually need to be combined with actual business background and business value, so they need to be led by the product owner; project tasks are usually more technical, so they need to be developed by developers who know more about technical modules. This can usually be done at initial meetings and milestone summary meetings.

Scrum vs extreme programming (XP)

For readers who have known about agile development, they may have heard of Scrum and even equated Scrum with Agile. This view is not accurate from a technical level. Scrum, including XP (Extreme Programming), which we will talk about later, is just a guiding framework under agile development methodology. Their goal is to be as flexible as possible while ensuring the quality of the project; many technical terms, such as user stories, project tasks, and iterations, are consistent. The main difference between them is how to perform each iteration or sprint.

In Scrum, the project plan in each iteration is usually not allowed to change, and once decided at the beginning of the iteration, user stories and project tasks are not allowed to change. Only when the iteration is over can adjustments be made according to the actual feedback. The advantage of this is that project team members can focus on completing their own tasks in each iteration to ensure the quality and efficiency of the functions, in order to pursue the stability and reliability of the product after the completion of the iteration cycle. But there is a drawback, which is that it is not relatively "agile", because once the project plan is established, it is not allowed to add new requirements or change existing requirements. In addition, the iteration cycle of Scrum is generally 2-4 weeks, which is relatively long.

In XP, unimplemented user stories can be replaced by new user stories, as long as the two user stories are implemented with equal hours. On the other hand, XP is more strict in the priority of user stories, requiring the actual project tasks to strictly follow the priority of user stories. In addition, XP is also more stringent in the process of software implementation, which generally requires relatively strict quality control measures, such as test-driven development (TDD, full name Test Driven Development), automated testing (Automated Testing), pair programming, refactoring and so on. Therefore, although XP is flexible in user stories, it is very strict in the software implementation process, so it requires higher technical and experience requirements for the development team.

Other

Agile development also includes many other elements, so I won't go into detail because of the limited space in this article.

How to choose the project management mode

In the actual work, we will encounter large and small project requirements, how to choose the project management model is an important issue. Unfortunately, there is not a perfect solution for all software projects. Although this article has devoted a lot of space to agile development, it does not mean that agile development is omnipotent. The traditional waterfall flow development model has many disadvantages, but it also has many applicable scenarios, such as government IT projects, or some highly professional development projects. Moreover, before making the choice of project management model, we also need to fully understand some hidden factors that are not so obvious on the surface, such as corporate culture, organizational structure, industry background, human resources, team experience and so on. Therefore, the author believes that agile development is not the master key to solve all problems. We should think twice before making a practical choice. Even in some cases, a variety of management models need to be adjusted to a certain extent according to the actual situation to make it more suitable for the current project background.

The advantage of agile development is very obvious, it can better adapt to the rapidly changing business and market environment, and help enterprises overcome some uncertain factors, so that they can deliver more products that are valuable to users. Moreover, agile development usually omits a lot of unnecessary documentation and tedious communication processes compared to traditional waterfall flow development, so it usually takes less time to accomplish more things. However, agile development is less formal than traditional waterfall development, and feels a bit like a "guerrilla" vs "regular army". Traditional project management model, such as PMBOK, has very complete process management and document management, which is more suitable for long-term large-scale projects.

Therefore, the author believes that if your market environment and customer needs will change frequently, and this uncertainty will greatly affect the financial health of the enterprise, then you must not hesitate to choose agile development. Conversely, if the market environment is not changing so fast and customer requirements are relatively fixed, with high compliance and formal documentation requirements, such as government IT projects, then you can choose to use traditional project management models, such as waterfall flow development.

At this point, the study of "what is the knowledge of software project management" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.