CPT203 Software Engineering 软件工程 Pt.6 软件管理（中英双语）

10. Project Management（项目管理）

10.1 Project Management Overview

10.1.1 Project Management Importance（项目管理的重要性）

1.由于专业软件工程总是受到组织预算和时间表限制的影响，因此需要对项目进行管理。
2.项目管理的目标是确保软件项目能够满足并克服这些限制，并交付高质量的软件。

良好的管理并不能保证项目的成功，但糟糕的管理可能会导致项目交付延迟、成本增加，以及无法满足客户的期望。

10.1.2 Criteria for Project Management（项目管理的准则）

1.在约定的时间将软件交付给客户。
2.控制整体成本在预算范围内。
3.交付符合客户期望的软件。
4.保持开发团队的和谐与高效运作。

10.1.3 Challenges in Project Management（项目管理的挑战）

1.产品是无形的：无法被看到或触摸。
2.大型软件项目通常是一次性项目：从之前项目中学到的经验和教训可能无法直接应用到新的项目中。
3.软件过程具有变化性和组织特定性：软件开发过程在不同的组织中可能会有显著的差异，这使得预测特定软件开发过程可能导致的问题变得困难。

10.1.4 Manager’s Responsibility（经理的责任）

1.项目规划：负责规划、估算和安排项目开发的进度，分配任务并监督团队成员的工作。
2.报告：向客户和公司管理层汇报项目的进展情况。
3.风险管理：评估可能影响项目的风险，监控这些风险，并在问题出现时采取行动。
4.人员管理：选择团队成员并建立工作方式，以确保团队的协作和高效运作。
5.提案撰写：撰写提案以赢得执行工作的合同。

10.1.5 Ability of A Good Project Manager（一个优秀项目经理应该具有的品质）

1.激励能力：项目经理需要有能力激励技术人员充分发挥他们的能力，以产出最佳成果。
2.组织能力：项目经理需要有能力塑造现有流程或者创新新的流程，以确保最初的概念能够被转化为最终的产品。
3.创新能力：项目经理需要有能力激发团队成员的创造力，使他们在必须在特定软件产品或应用程序的规定范围内工作时，仍能够保持创造性。
4.解决问题能力：一个有效的软件项目经理能够诊断技术和组织问题。
5.管理身份：一个优秀的项目经理必须能够主导项目。他们必须有信心在必要时掌控局面，并且能够信任优秀的技术人员按照自己的直觉行事。
6.影响力和团队建设：一个有效的项目经理必须有影响力，并且能够建设团队。他们需要能够理解团队成员的言辞和非言辞的信号，并且能够根据这些信号的需求做出反应。

10.2 Risk Management（风险管理）

风险管理涉及到预见可能影响项目进度或正在开发的软件质量的风险，并采取行动来避免这些风险。
Risk management involves anticipating risks that might affect the project schedule or the quality of the software being developed, and then taking action to avoid these risks.

10.2.1 Types of risks（风险类型）

三种相关的风险类型如下：
1.Project risks（项目风险）：影响项目进度或资源的风险（例如，经验丰富的设计师离职）。
Risks that affect the project schedule or resources(e.g., loss of an experienced designer).
2.Product risks（产品风险）：影响正在开发的软件质量或性能的风险（例如，购买的组件未能按预期性能运行）。
Risks that affect the quality or performance of the software being developed (e.g., failure of a purchased component to perform as expected).
3.Business risks（业务风险）：影响软件开发组织或软件采购组织的风险（例如，来自竞争对手的新产品）。
Risks that affect the organization developing or procuring the software (e.g., a new product from competitors).
下图展示了常见的项目、产品、业务风险的例子。

10.2.2 Risk Management Process（风险管理过程）

下图展现了风险管理过程。


该过程包含以下几个阶段：
1.Risk identification（风险识别）：识别可能的项目、产品和业务风险。
identify possible project, product, and business risks.
2.Risk analysis（风险分析）：评估这些风险发生的可能性和后果。
assess the likelihood and consequences of these risks.
3.Risk planning（风险规划）：制定应对风险的计划，包括避免风险或最小化其对项目的影响。
plans to address the risk, either by avoiding it or minimizing its effects on the project.
4.Risk monitoring（风险监控）：定期评估风险及其应对计划，并在了解更多风险信息时对计划进行修订。
regularly assess the risk and your plans for risk mitigation and revise these when you learn more about the risk.

10.2.2.1 Risk Identification（风险识别）

风险识别是风险管理过程的第一阶段。
它涉及识别可能对软件工程过程、正在开发的软件和开发组织构成重大威胁的风险。
It is concerned with identifying the risks that could pose a major threat to the software engineering process, the software being developed, and the development organization.
风险识别可以通过项目组对可能的风险的集体讨论完成，或者管理者凭借之前项目中出错的经验识别风险。
Team process and/or project manager’s call.

下图展现了一些风险的例子。

10.2.2.2 Risk Analysis（风险分析）

对每个识别出的风险进行评估，判断其发生的可能性和严重程度。
To consider each identified risk and make a judgment about the probability and seriousness of that risk.

可能性的分级如下：
非常低 (<10%)，
低 (10–25%)，
中等 (25–50%)，
高 (50–75%)，
非常高 (>75%)。

严重性的分级如下：
catastrophic灾难性的 (威胁到项目的生存)
serious严重的 (会导致重大延误)
tolerable可容忍的 (延误在允许的范围内)
insignificant无关紧要的

风险类型和例子如下图所示。

10.2.2.3 Risk Planning（风险规划）

考虑已经识别出的关键风险，并制定管理这些风险的策略。
To consider each of the key risks that have been identified, and develops strategies to manage these risks.
思考如果风险中所识别的问题发生，可能采取的行动，以最小化对项目的影响。
To think of actions that you might take to minimize the disruption to the project if the problem identified in the risk occurs.
思考在监控项目时可能需要收集的信息，以便预测可能出现的问题。
To think about information that you might need to colect while monitoring the project so that problems can be anticipated.

这些策略分为以下三个类型：
1.Avoidance strategies（规避策略）：采取这些策略意味着风险发生的可能性将会降低。例如避免使用有缺陷的组件。
Following these strategies means that the probability that the risk will arise will be reduced. (e.g.,Defective components)

2.Minimization strategies（最小化策略）：采取这些策略意味着风险发生后的影响将会减少。例如，制定应对员工疾病的计划。
Minimization strategies: Following these strategies means that the impact of the risk will be reduced. (e.g., Staff illness)

3.Contingency plans（应急计划）：采取这些策略意味着你已经为最坏的情况做好准备，并制定了应对策略。例如，制定应对组织财务问题的计划。
Following these strategies means that you are prepared for the worst and have a strategy in place to deal with it. (e.g., Organizational financial problems)

下图展示了更多的风险管理策略。

10.2.2.4 Risk Monitoring（风险监控）

风险监控是检查你对产品、过程和业务风险的假设是否发生变化的过程。
Risk monitoring is the process of checking that your assumptions about the product, process, and business risks have not changed.
定期检查已识别的风险，以确定这些风险是否变得更加可能发生或减少可能性。
Regularly assess each of the identified risks to decide whether or not that risk is becoming more or less probable. (Probabilty)
同时，考虑风险的影响是否发生了变化。
Also think about whether or not the effects of the risk have changed. (Seriousness)

下图展示了风险类型以及对应的监控指标。

10.3 Managing People（人员管理）

10.3.1 Importance（重要性）

人员管理是重要的，因为在软件组织中工作的人员是其最重要的资产。招聘和留住优秀人才需要付出很大的成本，而能否确保组织能够获得最佳的投资回报也是要考虑的。

10.3.2 Four critical factor（四个关键要素）

1.Consistency（一致性）：项目团队的成员应该以一种可比较的方式受到对待。
2.Respect（尊重）：不同的人拥有不同的技能，管理者应该尊重这些差异。
3.Inclusion（包容性）：当员工感觉到自己被倾听并且他们的建议被考虑时，他们会更有效地做出贡献。
4.Honesty（诚实）：应该始终对团队中的好坏情况保持诚实。

10.3.3 Motivation People（激励人员）

作为项目经理，你需要激励与你合作的人，让他们充分发挥自己的能力。
激励意味着组织工作和工作环境，以鼓励人们尽可能有效地工作。

不同的人格对激励的影响如下：
以任务为导向的人，他们受到他们所做工作的激励。在软件工程领域，这些人受到软件开发中的智力挑战的激励。
自我导向的人，他们主要受到个人成功和认可的激励。他们对软件开发感兴趣是为了实现自己的目标。
以互动为导向的人，他们受到同事的存在和行为的激励。随着软件开发变得更加以用户为中心，以互动为导向的个体在软件工程中扮演着越来越重要的角色。

10.4 Teamwork（团队协作）

10.4.1 Importance and Benefits（重要性和优点）

团队协作的重要性如下：
1.在一个大团队中，让所有人一起解决单一问题是不可能的，通常需要将大团队分成多个小组来协同合作。
2.组建一个具有合适技术技能、经验和个性平衡的小组是一个至关重要的管理任务。
3.在一个具有凝聚力的团队中，成员认为整个团队比个体成员更重要。

创建一个具有凝聚力的团队的优点如下：
1.团队可以建立自己的质量标准：由于这些标准是通过共识建立的，所以比外部强加给团队的标准更有可能被遵守。
2.个体相互学习和支持：团队成员之间相互学习和支持。团队鼓励相互学习，降低了因为知识不足而产生的抑制感。
3.知识共享：如果团队成员离开，团队可以保持连续性。其他团队成员可以接管关键任务，确保项目不会受到过度的干扰。
4.鼓励重构和持续改进：团队成员共同努力，提供高质量的结果并解决问题，不管最初设计或编写程序的个人是谁。

10.4.2 Influential Factors（影响因素）

一个团队是否有效，在某种程度上取决于项目的性质和做这项工作的组织。

除了项目和组织问题之外（除了上面我们刚刚提到的之外），或者说给定一个稳定的组织和项目环境，以下三个要素对团队合作有着最重要的影响：
1.The people in the group（团队中的人员）：项目小组需要不同类型的人员。
2.The group organization（团队组织）：应该这样组织团队：小组成员都能尽其所能，所承担的各项任务都能按时完成。
3.Technical and managerial communications（技术和管理沟通）：小组成员之间、软件开发团队和其他利益相关者之间的良好沟通是必不可少的。

而一个优秀的经理应该尝试鼓励团队凝聚力。一些参考方案如下：
1.Organize social events（组织社交活动）
2.Naming the group and establishing a group identity and territory（组建团队并建立团队身份和领地）
3.Explicit group-building activities such as sports and games（明确的团队建设活动，如体育和游戏）
4.Be inclusive（鼓励包容性）

10.4.3 Selecting group members（成员的挑选）

许多软件工程师主要受到工作本身的激励，因此软件开发团队通常由有着自己关于技术问题解决方式的想法的人组成。
具有互补性个性的团队可能比仅仅基于技术能力选择的团队更有效地工作。
其中受到工作激励的人可能在技术上更为强大。
自我导向的人可能在推动工作向前完成工作方面表现最好。
以互动为导向的人有助于促进团队内的沟通。

10.4.3 Group organization（团队结构）

一个团队的组织方式会影响该团队做出的决策、信息交换的方式以及开发团队与外部项目利益相关者之间的互动。
需要考虑的组织问题如下：
项目经理是否应该成为团队的技术领导者？
谁将参与制定关键的技术决策，以及这些决策将如何制定？
与外部利益相关者和公司高级管理层的互动如何处理？
如何整合非同地点的团队成员？
如何在团队内部共享知识？

10.4.3 Group communications（团队交流）

团队成员之间和其他项目利益相关者之间进行有效和高效的沟通是非常重要的：
团队成员必须就他们工作的状态、已经做出的设计决策以及对之前设计决策的更改进行信息交流。
他们必须解决与其他利益相关者出现的问题，并告知这些利益相关者系统变更、团队变更和交付计划的变更。
良好的沟通也有助于增强团队的凝聚力。团队成员了解彼此的动机、优势和弱点，从而加强团队的凝聚力。

影响沟通效果和效率的因素如下：
1.团队规模：随着团队规模的增大，成员之间的有效沟通变得更加困难。
2.团队结构：非正式结构的团队成员之间通常比正式、等级制度明确的团队成员之间更有效地沟通。
3.团队组成：具有相似个性类型的人可能会发生冲突，从而抑制沟通。
4.工作环境：工作场所的组织方式是促进或抑制沟通的主要因素。
5.可用的沟通渠道：如面对面、电子邮件、正式文件、电话以及Web 2.0技术（如社交网络和维基）都会影响沟通的效果和效率。

10.5 Continuous Improvement（持续改进）

10.5.1 Definition（定义）

持续改进：持续改进是指通过持续不断的努力，逐步改善流程、产品或服务，或者通过突破性的改进来提升。这是一种系统性的方法，旨在提高效率、减少浪费、改善质量，并为客户提供更大的价值。
Refers to the ongoing effort to enhance processes, products, or services incrementally over time or through breakthrough improvements.
It is a systematic approach aimed at increasing efficiency, reducing waste, improving quality, and delivering greater value to customers.

持续改进包括以下方面：
1.定期评估和完善软件开发流程。
Regularly evaluating and refining software development processes.
2.利用利益相关者、用户和系统监控的反馈。
Leveraging feedback from stakeholders, users, and system monitoring.
3.将小的、迭代的变化或重大的创新整合进来：
Incorporating small, iterative changes or significant innovations to:
提升代码质量。
Enhance code quality.
优化工作流程。
Optimize workflows.
减少技术债务。
Reduce technical debt.
改善团队成员之间的协作。
Improve collaboration among team members.

10.5.2 Characteristics（特点）

持续改进的特点如下：
1.增量进展：专注于随时间累积的小而持续的变化。
Incremental Progress: Focus on small, consistent changes that accumulate over time.
2.以反馈为驱动：依赖来自测试、用户和监控的反馈循环。
Feedback-driven: Relies on feedback loops from testing, users, and monitoring.
3.目标导向：旨在实现质量、性能或团队生产力的可衡量改进。
Goal-oriented: Targets measurable improvements in quality, performance, or team productivity.
4.协作性：让所有利益相关者参与改进过程，促进共同责任。
Collaborative: Involves all stakeholders in the improvement process, promoting shared responsibility.
5.周期性：改进是一个持续的、迭代的过程，而不是一次性的努力。
Cyclic: Improvement is an ongoing, iterative process rather than a one-time effort.

10.5.3 Strategies（策略）

10.5.3.1 Agile Methodologies（敏捷方法论）

敏捷方法论强调迭代式开发、协作和对变化的响应。团队通过称为冲刺或迭代的周期交付小而增量的改进。
Emphasizing iterative development, collaboration, and responsiveness to change. Teams deliver small, incremental improvements through cycles called sprints or iterations.
Scrum：进行冲刺回顾以评估和改进团队绩效。例如，使用JIRA来识别每个冲刺中的任务描述和需求不清晰的问题。
Conduct sprint retrospectives to evaluate and improve team performance.Example: Use JIRA to identify unclear task descriptions and requriements in each Sprint.
同样地，看板方法：通过可视化任务来识别瓶颈，从而进行持续改进。
Kanban - Visualize tasks to identify bottlenecks.
下图展示了一个JIRA软件界面，包含了两次冲刺。

10.5.3.2 Continuous Integration and Continuous Delivery（CI/CD，持续集成和持续交付）

持续集成/持续交付（CI/CD）自动化了代码变更的集成过程（CI），并将它们部署到生产环境（CD），以确保更快的交付和更高的可靠性。
CI/CD automates the process of integrating code changes (CI) and deploying them to production environments (CD), ensuring faster delivery and higher reliability.
持续集成（CI）：开发人员频繁地将他们的代码更改集成到一个共享的代码库中。每次集成都会触发自动构建和测试，以确保新的更改不会破坏现有的代码库。
Continuous Integration: Developers frequently integrate their code changes into a shared repository. Automated builds and tests are triggered for each integration to ensure that the new changes do not break the existing codebase.
例如，对于Java应用程序，可以使用Maven或Gradle在每次提交后编译项目。
Example: Automated Builds - For a Java application, use Maven or Gradle to compile the project after each commit in the repository.
持续交付（CD）：持续交付通过自动将代码更改部署到一个分级环境进行进一步测试来扩展CI。它确保应用程序始终处于可部署状态。
Continuous Delivery extends CI by automatically deploying code changes to a staging environment for further testing. It ensures that the application is always in a deployable state.
例如，自动将构建产物（例如Docker镜像）部署到一个分级环境（模拟生产设置的预生产环境）。
Example: Deploy to Staging - Automatically deploy the build artifacts (e.g., Docker images) to a staging environment (pre-production environment that mimics the production setup).
下图展示了CI系统中开发者A和开发者B将他们的代码变更后提交到代码库。

每次提交后，系统都会自动进行构件和测试。如果构建和测试成功，变更将被推送到生产环境。如果构建或测试失败，变更将被标记为失败，需要修复。

10.5.3.3 Other strategies（其他策略）

重构：重构是指重新构造现有的代码，以提高其可读性、可维护性和性能，而不改变其外部行为。通过重构，可以改进代码的质量和结构，从而使其更易于理解和维护。
Refactoring：The process of restructuring existing code to improve its readability, maintainability, and performance without changing its external behavior.
监控和反馈：持续跟踪应用程序的性能，同时收集用户或系统输入以识别改进的领域。例如，跟踪API响应时间并对异常情况触发警报，以及从用户那里收集关于新功能或错误的见解。
Monitoring and Feedback：Continuously tracking application performance, while feedback gathers user or system input to identify areas for improvement. (e.g., Track API response times and trigger alerts for anomalies and Collect insights from users about new features or bugs.)
知识共享：团队内部分享最佳实践、经验和专业知识，以提高技能水平和一致性。
Knowledge Sharing：Sharing best practices, lessons, and expertise within the team to improve skills and consistency.
A/B测试：比较某一功能的两个版本，以确定哪个基于用户互动表现更好。例如，评估"加入购物车"和"立即购买"按钮。
Compares two versions of a feature to determine which performs better based on user interaction. (e.g., evaluate “Add to Cart” vs. “Buy Now” buttons)

10.5.4 Metrics（指标）

指标有助于跟踪流程的有效性、识别改进的领域，并衡量持续改进的进展。
Metrics help track the effectiveness of processes, identify areas for improvement, and measure the progress of continuous improvement.
对于开发：
1.变更时间：从代码提交到部署到生产环境所需的时间。
Time for Changes: Time taken from a code commit to deployment in production.
2.周期时间：从开始处理任务到完成任务所需的时间。
Cycle Time: Time taken from the start of work on a task to its completion.
3.部署频率：新代码被部署到生产环境的频率。
Deployment Frequency: How often new code is deployed to production.

对于产品质量：
1.缺陷密度：每单位代码中的缺陷数量（例如，每千行代码中的缺陷数）。
Defect Density: The number of defects per unit of code(e.g., defects per 1,000 lines of code).
2.平均恢复时间：从故障发生到恢复的平均时间。
Mean Time to Recovery: Average time taken to recover from a failure.
3.逃逸缺陷：指部署到生产环境后发现的缺陷。
Escaped Defects: Defects that are found after deployment to production.

对于团队生产力：
速度：团队在一个冲刺中完成的工作量，通常以故事点或任务来衡量。
Velocity: The amount of work completed by a team during a sprint, measured in story points or tasks.
进行中的工作：当前正在进行的任务数量。
Work in Progress: The number of tasks currently in progress.
流程效率：任务的活动时间与总时间（活动时间+空闲时间）的比率。
Flow Efficiency: The ratio of active time to total time (active + idle) spent on a task.

对于客户和用户：
客户满意度：直接衡量客户对产品或特性的满意度。
Customer Satisfaction: A direct measure of customer satisfaction with a product or feature.
净推荐值：衡量客户推荐产品给他人的可能性。
Net Promoter Score: Measures the likelihood of customers recommending the product to others.
特性采纳率：积极使用新发布特性的用户所占的百分比。
Feature Adoption Rate: Percentage of users actively using a newly released feature.