本篇笔记总结了软件工程中团队项目管理与敏捷开发的核心概念。首先，介绍了软件项目管理的四个关键要素（人员、产品、过程、项目）以及主要干系人角色，并探讨了团队领导者的 MOI 模型和不同的软件团队结构。随后，分析了团队协调与沟通的重要性，并强调了避免团队“毒性”的必要性。接着，笔记详细介绍了敏捷开发的核心理念，包括敏捷宣言、敏捷原则、敏捷团队的特点以及敏捷开发过程的关键实践，如极限编程（XP）、Scrum 和动态系统开发方法（DSDM）。最后，讨论了敏捷建模和敏捷统一过程（AUP），强调了敏捷方法在软件开发中的灵活性和高效性。（由 gpt-4o 生成摘要）
Ch.31 Project Management Concepts
1. The Four P's
在软件项目管理中，有四个关键要素（被称为 四个 P(The Four P's)），它们共同决定着项目的成败。
- 人员(People)：这是项目成功的最重要的因素。
- 产品(Product)：指的是要构建的软件本身。
- 过程(Process)：指为了完成软件工程工作而采用的一系列框架活动和软件工程任务。
- 项目(Project)：指的是使产品成为现实所需完成的所有工作。
2. Stakeholders
干系人(Stakeholder) 是指所有受到项目影响或者对项目有影响的个人或组织。主要的软件项目干系人包括：
- 高级管理者(Senior manager)：他们定义业务问题，这些问题通常对项目有重大影响。高级管理者的支持和决策对项目的资源分配和方向具有重要意义。
- 项目经理(Project manager) / 技术经理(technical manager)：负责计划、激励、组织和控制进行软件工作的实践者。
- 实践者(Practitioner)：提供工程化产品或应用所需的技术技能，包括程序员、设计师、测试人员等。
- 顾客(Customer)：包括提出软件需求的人员和对结果有间接兴趣的其他相关方。
- 最终用户(End-user)：软件发布投入生产使用后与之交互的人员。
3. The MOI Model
MOI 模型(The MOI Model) 概括了优秀的 团队领导者(Team Leader) 需要具备的三个关键能力：
- 激励(Motivation)：鼓励技术人员尽最大能力进行生产（通过“push or pull”）。
- 组织(Organization)：塑造现有流程（或创建新流程），使最初的概念转化为最终产品。
- 想法或创新(Ideas or innovation)：鼓励人们即使在为特定的软件产品或应用程序建立的界限内工作时，也能创造并感到有创造力。团队领导者需要营造鼓励创新的氛围，激发团队成员的创造潜力，从而产生更具竞争力的软件产品。
4. Software Team Structure
选择软件项目团队结构时，必须考虑以下因素：
- 要解决的问题的难度。
- 最终程序的大小（以代码行或功能点计）。
- 团队将保持在一起的时间（团队 寿命(lifetime)）。
- 问题可以 模块化(modularized) 的程度。
- 要构建的系统的所需质量和 可靠性(reliability)。
- 交付日期的 严格性(regidity)。
- 项目所需的社交性（沟通程度）。
4.1. Organizational Paradigms
组织范式(Organizational Paradigm) 描述了不同的团队组织结构和管理风格。Constantine 提出了四种组织范式：
- 封闭范式(closed paradigm)：按照传统的等级权威结构组织团队，强调集中控制和层级管理。
- 随机范式(random paradigm)：结构松散地组织团队，并依赖于团队成员的 个人自驱力。这种范式鼓励创新和自由。
- 开放范式(open paradigm)：试图以一种方式组织团队，使其实现与封闭范式相关的一些控制，但也实现了使用随机范式时发生的许多创新。——试图在控制和创新之间找到平衡，是综合了前两个。
- 同步范式(synchronous paradigm)：依赖于问题的自然划分，并组织团队成员在问题的各个部分上工作，团队成员之间几乎没有积极的沟通。同步范式适用于问题可以被清晰地分解为独立模块的项目，各模块可以并行开发。
4.2. Avoid Team "Toxicity"
团队“毒性(Toxicity)”指的是阻碍团队有效工作并导致项目失败的负面因素。应该努力避免以下团队“毒性”：
- 疯狂的工作氛围，使得团队成员浪费精力，失去对工作目标的关注。
- 个人冲突、业务目标不明确、技术难题等导致团队成员之间产生 矛盾(friction) 和 挫折(frustration)。
- “分散的(fragmented) 或 协调不良的(poorly coordinated) 程序” 或定义不明确或选择不当的流程模型，成为完成任务的障碍。流程混乱、缺乏规范、流程模型不适合项目特点都可能导致团队工作效率低下。
- 角色定义不清导致项目成员缺乏 责任感(accountability)，并随之而来引发 互相指责(finger-pointing)。
- 持续和反复的失败，这将导致团队成员的信心丧失，士气(morale) 低落。
5. Agile Teams
敏捷团队(agile team) 是一种适应性强、高效协作的团队模式，特别适用于需求变化频繁的项目。敏捷团队具有以下特点：
- 团队成员之间必须相互信任。
- 技能的分布必须适合问题，团队成员之间能够形成互补的技能组合。
- 为了保持团队凝聚力，可能必须将特立独行者排除在团队之外。
- 团队是“自组织”的：
- 自适应(adaptive) 的团队结构：敏捷团队的结构可以根据项目需要灵活调整。
- 使用随机 / 开放 / 同步范式的元素，敏捷团队综合了这些范式的优点。
- 成员拥有高度的 自主权(autonomy)。
6. Team Coordination & Communication
有效的 团队协调与沟通(Team Coordination & Communication) 是项目成功的关键保障。团队可以使用多种沟通方式：
- 正式的、非个人方法(formal & impersonal approaches)：包括软件工程文档、工作产品、技术备忘录、项目里程碑、进度表和项目控制工具（第 23 章）、变更请求和相关文档、错误跟踪报告、和存储库数据（第 26 章）。这些方法主要用于记录和传递项目信息，例如需求文档、设计文档、代码、测试报告等。
- 正式的、人际程序(formal & interpersonal procedures)：侧重于应用于软件工程工作产品的质量保证活动（第 25 章）。这些包括状态审查会议以及设计和代码检查。例如：评审会议、代码审查、走查等，这些方法主要用于确保软件质量。
- 非正式的、人际程序(informal & interpersonal procedures)：包括用于信息传播和问题解决的小组会议以及“需求和开发人员的搭配”，如头脑风暴等。
- 电子通讯(electronic communication)：包括电子邮件、电子公告板，以及扩展的、基于视频的会议系统，这些方法可以打破时间和空间的限制，方便团队成员远程沟通。
- 人际网络(interpersonal networking)：包括与团队成员和项目外部人员的非正式讨论，他们可能拥有有帮助的经验或见解。
7. The Product Scope
产品范围(The Product Scope) 定义了软件系统需要实现的功能和特性，它必须在管理和技术层面都是明确和可理解的。产品范围需要从以下几个方面进行描述：
- 背景(Context)：要构建的软件如何适应更大的系统、产品或业务背景？由此产生什么约束？ 理解软件的背景有助于确定其边界和约束条件。
- 信息目标(Information objectives)：软件作为输出产生哪些客户可见的数据对象？需要哪些数据对象作为输入？ 明确输入和输出数据对象有助于定义软件的功能和数据处理流程。
- 功能和性能(Function and performance)：软件执行什么功能将输入数据转换为输出？是否需要解决任何特殊的性能特征？ 定义软件的功能和性能指标，有助于指导软件设计和开发。
7.1. Problem Decomposition
问题分解(Problem Decomposition) 有时也称为 分区(partitioning) 或 问题细化(problem elaboration)。
- 一旦定义了范围，其可以被分解为 组成功能(constituent functions)、用户可见的 数据对象(data objects)、一组 问题类(problem classes)……
- 分解过程将持续进行，直到定义了所有功能或问题类为止。
- 目的：将复杂的问题分解为更小、更易于管理和解决的子问题。
8. The Process
项目的 过程(process) 框架的搭建需要考虑以下要素：
- 项目 特点(characteristic)
- 确定所需的 严谨程度(degree of rigor)
- 为每个软件工程活动定义 任务集(task set)——任务集包含以下内容：
- 软件工程任务(software engineering task)：为了完成特定的软件工程活动而需要执行的具体任务，如需求分析、设计、编码、测试等等。
- 工作产品(work product)：可交付物，包括需求文档、源代码、测试用例等等。
- 质量保证点(quality assurance point)：如测试或。
- 里程碑(milestone)：项目进展过程中的重要事件或时间节点。
Melding the Problem and the Process
9. The Project
项目在以下情况下会陷入困境...
- 软件人员不了解客户的需求。
- 产品范围定义不明确。
- 变更管理不善。
- 选择的技术发生变化。
- 业务需求发生变化或定义不明确。
- 截止日期 不切实际(unrealistic)。
- 用户抵制。
- 赞助(sponsorship) 丢失或未正确获得。
- 项目团队缺乏具有适当技能的人员。
- 管理人员（和实践者）没有从最佳实践中吸取教训。
9.1. Common-Sense Approach to Projects
对项目采取 常识性方法(Common-Sense Approach to Projects)，可以有效地提高项目成功率。这包含以下几个关键原则：
- 良好的开端(Start on the right foot)：努力（非常努力）理解要解决的问题，然后设定切合实际的目标和期望。项目启动阶段至关重要，需要充分理解客户需求，明确项目目标和范围。
- 保持动力(Maintain momentum)：项目经理必须提供激励措施，以最大限度地减少人员流动，团队应强调其执行的每项任务的质量，高级管理层应尽一切可能不干涉团队的工作。保持团队稳定、重视质量、减少外部干扰，都有助于项目保持良好势头。
- 跟踪进展(Track progress)：对于软件项目，当工作产品（例如，模型、源代码、成套测试用例）被生产出来并作为质量保证活动的一部分获得批准（使用正式技术评审）时，就会跟踪进展。通过定期跟踪项目进展，及时发现和解决问题，确保项目按计划进行。
- 做出明智的决定(Make smart decisions)：本质上，项目经理和软件团队的决定应该是“保持简单”。在项目决策过程中，应优先考虑简单有效的方案，避免过度设计和复杂化。
- 进行事后分析(Conduct a postmortem analysis)：为每个项目建立一致的机制，以吸取经验教训。项目结束后，应进行回顾和总结，提炼经验教训，为后续项目提供借鉴。
9.2. To Get to the Essence of a Project
Barry Boehm 提出了以下五个 W 和两个 H，以帮助抓住项目的核心要点：
| CN | EN |
|---|---|
| 为什么要开发系统？ | Why is the system being developed? |
| 将要完成什么？ | What will be done? |
| 何时完成？ | When will it be accomplished? |
| 谁负责？ | Who is responsible? |
| 他们在组织结构中的位置在哪里？ | Where are they organizationally located? |
| 如何在技术和管理上完成这项工作？ | How will the job be done technically and managerially? |
| 每种 资源(resource)（例如，人员、软件、工具、数据库）需要多少？ | How much of each resource (e.g., people, software, tools, database) will be needed? |
9.3. Critical Practices
以下是一些关键实践(Critical Practices)，可以显著提高软件项目成功率：
| CN | EN |
|---|---|
| 系统的风险管理 | Formal risk management |
| 经验成本和进度估算 | Empirical cost and schedule estimation |
| 基于度量的(metrics-based) 项目管理 | Metrics-based project management |
| 挣值(earned value) 跟踪 | Earned value tracking |
| 针对质量目标的 缺陷跟踪(defect tracking) | Defect tracking against quality targets |
| 以人为本的项目管理 | People aware project management |
Ch.5 Agile Development
1. Agile Development
1.1. The Manifesto for Agile Software Development
由 Kent Beck 提出的敏捷软件开发 宣言(manifesto) 的核心价值观是：
- 个体与互动(Individuals and interactions) 胜过 流程与工具(processes and tools)
- 可工作的软件(Working software) 胜过 完善的文档(comprehensive documentation)
- 客户合作(Customer collaboration) 胜过 合同谈判(contract negotiation)
- 响应变化(Responding to change) 胜过 遵循计划(following a plan)
1.2. What is "Agility"?
敏捷(Agility) 意味着：
| CN | EN |
|---|---|
| 所有 干系人(stakeholder) 之间有效的沟通 | Effective communication among all stakeholders |
| 将客户融入团队 | Drawing the customer onto the team |
| 组织团队使其能够掌控工作 | Organizing a team so that it is in control of the work performed |
| 进而实现：快速、增量式的软件交付（逐步交付软件，而不是一次性交付所有功能） | Yielding... Rapid, incremental delivery of software |
Agility and the Cost of Change
2. Agile Process
典型的 敏捷开发过程(Agile Process) 具有以下特点：
| CN | EN |
|---|---|
| 根据客户的需求描述驱动敏捷开发 | Is driven by customer descriptions of what is required (scenarios) |
| 必须认识到计划是短期的，承认计划需要不断调整和迭代，不能奢求直接得到长期计划 | Recognizes that plans are short-lived |
| 通过高度强调构建活动来迭代地开发软件——每个迭代周期都需要包含设计、编码和测试环节，确保都能产生可工作的版本 | Develops software iteratively with a heavy emphasis on construction activities |
| 将软件分解成多个“软件增量”并交互给客户 | Delivers multiple software increments |
| 随着变化而适应——能够根据项目进展和客户需求灵活调整方向 | Adapts as changes occur |
3. Agility Principles
敏捷开发遵循以下 12 条 敏捷开发原则(Agility principles)。
| CN | EN |
|---|---|
| 最重要的目标是通过尽早和持续交付有价值的软件来满足客户。 | Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. |
| 欢迎需求变化，即使在项目后期。敏捷过程 利用(harness) 变化来为客户创造竞争优势。 | Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. |
| 经常交付可工作的软件，交付周期从几周到几个月不等，倾向于较短的周期。 | Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. |
| 业务人员和开发人员必须在整个项目中每天一起工作。 | Business people and developers must work together daily throughout the project. |
| 围绕积极主动的个人构建项目。为他们提供所需的环境和支持，并信任他们能够完成工作。 | Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. |
| 与开发团队进行信息传递的最有效方法是 面对面(face-to-face) 的交谈。 | The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. |
| 可工作的软件是衡量进度的 主要指标(primary measure)。 | Working software is the primary measure of progress. |
| 敏捷过程提倡 可持续的(sustainable) 开发。发起人、开发者和用户应该能够 无限期地(indefinitely) 保持稳定的节奏。 | Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. |
| 持续关注技术卓越和良好设计有助于提高敏捷性。 | Continuous attention to technical excellence and good design enhances agility. |
| 简洁(simplicity) 至关重要，应最大限度地减少工作量。 | Simplicity - the art of maximizing the amount of work not done - is essential. |
| 最好的架构、需求和设计来自 自组织的(self-organizing) 团队。 | The best architectures, requirements, and designs emerge from self-organizing teams. |
| 团队 定期(at regular intervals) 反思如何变得更有效率，并据此调整自身的行为。 | At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. |
4. Human Factors
在敏捷开发中，人为因素(Human Factors) 至关重要。开发过程应该去 适应(mold) 人和团队的 需求(need)。以下是敏捷团队成员和团队必须具备的关键特质：
- 能力(Competence)：团队成员需要具备完成工作所需的专业技能和知识。
- 共同目标(Common focus)：团队成员需要对项目目标有统一的认识和认同。
- 协作(Collaboration)：团队成员之间需要密切合作，共同解决问题。
- 决策能力(Decision-making ability)：团队需要拥有自主决策的能力，快速响应变化。
- 模糊问题解决能力(Fuzzy problem-solving ability)：面对不确定性和模糊性，团队需要能够灵活应变，找到解决方案。
- 相互信任和尊重(Mutual trust and respect)：团队成员之间需要相互信任和尊重，营造积极和谐的工作氛围。
- 自组织(Self-organization)：团队需要具备自组织能力，自主管理和分配任务。
5. Agile Progress Examples
5.1. Extreme Programming
极限编程(Extreme Programming, XP) 是最广泛使用的一种敏捷开发过程，最初由 Kent Beck 提出。
- XP Planning
- 从创建 用户故事(user stories) 开始——用户故事是描述用户需求的一种简洁方式。
- 敏捷团队评估每个用户故事并分配成本。
- 用户故事被分组形成 可交付的(deliverable) 增量。
- 做出 交付日期(delivery date) 的 许诺(commitment)。
- 使用 项目速度(project velocity) 帮助定义后续增量的交付日期——项目速度指每个迭代周期内需要完成的工作量。
- XP Design
- 遵循 KIS 原则(Keep It Simple, KIS)，保持设计简单。
- 鼓励使用 类-职责-协作卡(Class-Responsibility-Collaboration card, CRC card)（第 8 章）。
- 对于困难的设计问题，使用小型的设计 原型(prototype) 来探索和验证设计方案的可行性，称作“spike solutions”。
- 鼓励 重构(refactoring)，通过迭代改进内部程序设计。
- XP Coding
- 建议在开始编码之前，为用户故事构建 单元测试(unit test)。
- 鼓励 结对编程(pair programming)。
- XP Testing
- 每天执行所有单元测试——可以使用 持续集成(Continuous Integration, CI) 工具。
- 验收测试(Acceptance test)：由客户定义，用于评估软件是否满足客户的需求。
Adaptive Software Development
5.2. Industrial XP
工业极限编程(Industrial Extreme Programming, IXP) 是 XP 的扩展和增强版本，更加注重管理、客户角色和技术实践。其包含六个新的实践：
- 准备度评估(Readiness assessment)：在项目开始前评估团队和组织的敏捷开发准备程度。
- 项目社区(Project community)：强调建立积极协作的项目社区，包括所有利益相关者。
- 项目章程(Project chartering)：制定清晰的项目目标、范围和愿景。
- 测试驱动管理(Test driven management)：使用测试结果来驱动项目管理和决策。
- 回顾(Retrospectives)：定期回顾和总结项目经验，持续改进。
- 持续学习(Continuous learning)：鼓励团队成员持续学习和提升技能。
5.3. Scrum
Scrum 最初由 Schwaber 和 Beedle 提出，其显著特点包括：
- 将大的开发工作划分为一个一个小的 包(packets)。
- 测试和文档在产品构建过程中持续进行，贯穿始终。
- 通过 待办事项列表(backlog) 划出若干段的开发周期，称为 “冲刺(sprints)”。
- 使用非常简短的会议形式，有时甚至可以站着进行。
- 每一个冲刺周期结束后的都向客户交付 演示(demo)。
5.4. Dynamic Systems Development Method
动态系统开发方法(Dynamic Systems Development Method, DSDM) 由 DSDM 联盟推广，其大多数方面与 XP 相似，并有以下九条指导原则：
| CN | EN |
|---|---|
| 用户的积极参与 至关重要(imperative) | Active user involvement is imperative. |
| DSDM 团队必须 被授权(empowered) 进行自主决策 | DSDM teams must be empowered to make decisions. |
| 重点是产品的频繁交付 | The focus is on frequent delivery of products. |
| 验收的基本标注是对业务的 符合程度(fitness) | Fitness for business purpose is the essential criterion for acceptance of deliverables. |
| 迭代和增量开发是实现精确业务解决方案的必要条件 | Iterative and incremental development is necessary to converge on an accurate business solution. |
| 开发期间的所有变更都是 可逆的(reversible) | All changes during development are reversible. |
| 需求在较高层次上基线化——即不必太过详细，可以在迭代过程中进行细化 | Requirements are baselined at a high level |
| 测试贯穿整个 生命周期(life-cycle)——必须在每个阶段都进行 | Testing is integrated throughout the life-cycle. |
80% 原则(80 percent rule)：通常，一个应用程序的 80% 经常在 20% 的时间内交付，而另外 20% 的部分则需要剩余的 80% 的时间。
6. Agile Modeling
敏捷建模(Agile Modeling) 最初由 Scott Ambler 提出，包括以下原则：
- 以目标为导向进行建模(Model with a purpose)：建模应该服务于特定的目标，例如沟通、理解或设计。
- 使用多种模型(Use multiple models)：根据需要选择合适的模型，例如用例图、类图、流程图等。
- 轻量级建模(Travel light)：避免过度建模，只创建必要的模型，保持模型的简洁和实用性。
- 内容比表示形式更重要(Content is more important than representation)：模型的目的是传达信息，内容比模型的具体表示形式更重要。
- 了解模型和用于创建模型的工具(Know the models and the tools you use to create them)：熟练掌握建模技术和工具。
- 局部适应(Adapt locally)：根据具体项目和团队情况，灵活调整建模方法。
7. Agile Unified Process
敏捷统一过程(Agile Unified Process, AUP) 是一种简化的 Rational Unified Process (RUP) 的敏捷版本，包含以下活动：
- 建模(Modeling)：理解需求，设计系统架构和组件。
- 实现(Implementation)：编写代码，构建软件组件。
- 测试(Testing)：单元测试、集成测试、系统测试等，确保软件质量。
- 部署(Deployment)：将软件部署到目标环境。
- 配置(configuration) 和 项目管理(project management)：版本控制、配置管理、项目计划、进度跟踪等。
- 环境管理(Environment management)：搭建和维护开发、测试和部署环境。