Lec3
SE6: 软件工程中的人文因素¶
在软件工程领域，技术能力固然重要，但人文因素同样不可忽视。本章将详细探讨软件工程师的个人特质、团队心理学、团队结构、敏捷团队、社交媒体影响、云计算在软件工程中的应用、协作工具以及全球团队面临的挑战。
6.1 软件工程师的特质¶
成功的软件工程师通常具备以下特质：
- 责任心：对自己的工作负责，确保任务按时高质量完成。
- 理解用户：深刻理解团队成员和利益相关者的需求。
- 勇于承认错误，提出建设性意见：能够坦诚面对设计缺陷，并提出改进建议。
- 抗压能力：在压力下保持冷静，继续高效工作。
- 公正：在处理团队事务时保持公平公正。
- 注重细节：对细节有高度的关注，确保软件质量。
- 务实：在解决问题时，注重实际效果而非理论完美。
6.2 软件工程心理学¶
软件工程心理学涉及多个层面的行为模型：
- 商业环境：影响软件开发的商业背景。
- 公司：公司文化和政策对团队的影响。
- 项目团队：团队内部的动态和协作。
- 个人：个人的认知和动机。
边界跨越团队角色¶
- 大使：代表团队与外界沟通。
- 侦察员：探索新的机会和技术。
- 守卫：保护团队免受外部干扰。
- 哨兵：监控项目进展，确保按计划进行。
- 协调员：协调团队成员的工作。
6.3 软件团队¶
高效软件团队的属性¶
- 目标感：团队成员对项目目标有清晰的认识。
- 参与感：每个成员都积极参与项目。
- 信任感：团队成员之间相互信任。
- 改进意识：团队不断寻求改进的机会。
- 技能多样性：团队成员具备多样化的技能。
避免团队“毒性”¶
- 混乱的工作氛围：团队成员浪费精力，失去对目标的关注。
- 高挫折感：个人、商业或技术因素导致团队成员之间的摩擦。
- 流程不协调：流程模型选择不当或定义不清，影响项目进展。
- 角色不明确：缺乏责任感，导致相互指责。
- 持续失败：反复失败导致信心丧失，士气低落。
6.4 团队结构¶
组织范式¶
- 封闭范式：按照传统的权威层次结构组织团队。
- 随机范式：团队结构松散，依赖成员的主动性。
- 开放范式：结合封闭范式的控制和随机范式的创新。
- 同步范式：依赖问题的自然划分，团队成员在各自部分上工作，沟通较少。
影响团队结构的因素¶
- 问题的难度：问题的复杂性影响团队结构。
- 代码量：代码行数或功能点的数量。
- 团队寿命：团队合作的时间长度。
- 问题的模块化程度：问题是否可以被模块化。
- 系统的质量和可靠性要求：系统的高质量和可靠性要求。
- 交付日期的刚性：交付日期的严格程度。
- 项目的社交需求：项目所需的沟通程度。
6.5 敏捷团队¶
通用敏捷团队¶
- 个人能力与团队协作：强调个人能力和团队协作的重要性。
- 人优先于流程，政治优先于人：敏捷团队自组织，有多种结构。
- 自适应团队结构：使用Constantine的随机、开放和同步结构。
- 高度自治：团队有高度的自主权。
- 最小化计划：计划仅受业务需求和组织标准的约束。
极限编程 (Extreme Programming, XP) 团队价值观¶
- 沟通：团队成员和利益相关者之间的紧密非正式沟通。
- 简单性：设计仅满足当前需求，而非未来需求。
- 反馈：来自已实现的软件、客户和其他团队成员的反馈。
- 勇气：抵制为未指定的未来需求设计的压力。
- 尊重：团队成员和利益相关者之间的相互尊重。
6.6 社交媒体的影响¶
- 博客：用于与团队成员和客户分享信息。
- 微博：允许向关注者发布实时消息（如Twitter）。
- 定向在线论坛：允许参与者发布问题或意见并收集答案。
- 社交网络站点：允许软件开发人员之间连接以分享信息（如Facebook、LinkedIn）。
- 社交书签：允许开发人员跟踪和分享基于网络的资源（如Delicious、Stumble、CiteULike）。
6.7 云计算在软件工程中的应用¶
优势¶
- 访问所有软件工程工作产品：提供对所有工作产品的访问。
- 设备无关性，随处可用：不受设备限制，随时随地可用。
- 分发和测试软件的途径：提供分发和测试软件的途径。
- 信息共享：使团队成员开发的软件工程信息对所有成员可用。
担忧¶
- 可靠性和安全风险：云服务分散在团队控制之外，可能带来可靠性和安全风险。
- 互操作性问题：大量服务分布在云上，互操作性问题可能增加。
- 可用性和性能与安全、隐私和可靠性的冲突：云服务强调可用性和性能，但可能与安全、隐私和可靠性产生冲突。
6.8 协作工具¶
协作开发环境（CDE）的服务¶
- 命名空间：允许安全、私密地存储工作产品。
- 日历：协调项目事件。
- 模板：允许团队成员创建具有共同外观的工件。
- 度量支持：允许定量评估每个团队成员的贡献。
- 沟通分析：跟踪消息并隔离可能暗示问题的模式。
- 工件聚类：显示工作产品的依赖关系。
6.9 全球团队¶
团队决策的复杂性¶
- 问题复杂性：问题的复杂性影响决策。
- 不确定性和风险：与决策相关的不确定性和风险。
- 意外后果：决策工作可能对另一个项目目标产生意外影响。
- 不同观点：对问题的不同看法导致不同的结论。
- 全球团队的额外挑战：全球软件团队面临协作、协调和沟通的额外挑战。
影响全球软件开发团队的因素¶
- 文化差异：不同文化背景的团队成员可能对工作方式有不同的理解。
- 时区差异：不同时区的团队成员可能难以同步工作。
- 语言障碍：语言差异可能导致沟通不畅。
- 技术基础设施：不同地区的技术基础设施可能影响团队协作。
通过深入了解这些人文因素，软件工程师和团队可以更好地应对项目中的挑战，提高工作效率和软件质量。
SE7: 软件工程实践指导原则¶
在软件工程领域，知识更新速度极快，许多技术可能在短短几年内就会过时。然而，软件工程的基本原则却是经久不衰的，它们为软件开发人员提供了长期的指导。本文将详细探讨这些原则，并结合示例和拓展知识点，帮助读者更好地理解和应用这些原则。
1. 软件工程知识¶
1.1 原则 #1：保持敏捷¶
无论选择的是传统的瀑布模型还是敏捷开发模型，敏捷开发的基本原则都应当贯穿整个开发过程。敏捷开发强调快速响应变化、持续交付和团队协作。
示例：在敏捷开发中，团队通过短周期的迭代（Sprint）不断交付可用的软件版本，并根据用户反馈进行调整。例如，Scrum框架中的每日站会（Daily Standup）帮助团队及时沟通和解决问题。
1.2 原则 #2：每一步都关注质量¶
每个过程活动、动作和任务的退出条件都应关注所产生的工作产品的质量。质量不仅仅是最终的测试阶段，而是贯穿于整个开发周期。
示例：在代码编写阶段，开发人员应遵循编码规范，进行代码审查，确保代码的可读性和可维护性。在测试阶段，单元测试、集成测试和系统测试都应严格执行，确保软件的功能和性能符合预期。
1.3 原则 #3：随时准备适应¶
软件开发过程不应僵化，应根据问题、人员和项目的实际情况进行灵活调整。
示例：在项目初期，团队可能选择了瀑布模型，但随着项目进展，发现需求变化频繁，这时可以考虑切换到敏捷开发模型，以更好地应对变化。
1.4 原则 #4：建立高效的团队¶
软件工程的核心是人，建立一个自我组织的团队，成员之间相互信任和尊重，是项目成功的关键。
示例：在团队建设中，可以通过团队建设活动、定期的沟通会议和透明的任务分配机制，增强团队成员之间的协作和信任。
2. 指导过程的原则¶
2.1 原则 #5：建立沟通和协调机制¶
项目失败往往是因为信息遗漏或利益相关者未能有效协调。因此，建立有效的沟通和协调机制至关重要。
示例：使用项目管理工具（如Jira、Trello）来跟踪任务进度，定期召开项目会议，确保团队成员和利益相关者之间的信息畅通。
2.2 原则 #6：管理变更¶
变更管理是软件开发中的重要环节，无论是正式的还是非正式的，都必须建立机制来管理变更的请求、评估、批准和实施。
示例：在敏捷开发中，变更请求可以通过产品待办列表（Product Backlog）进行管理，团队在每个迭代中评估并优先处理这些变更。
2.3 原则 #7：评估风险¶
软件开发过程中存在许多风险，必须制定应急计划以应对可能的问题。
示例：在项目初期，团队可以进行风险评估，识别高影响和高概率的风险，并制定相应的应对策略。例如，技术风险可以通过技术预研和原型开发来降低。
2.4 原则 #8：创建有价值的工作产品¶
只创建那些对其他过程活动、动作或任务有价值的工作产品，避免不必要的文档和流程。
示例：在敏捷开发中，团队应专注于交付可用的软件，而不是过多的文档。例如，用户故事（User Story）和任务卡片（Task Card）可以简洁地描述需求和任务，而不需要冗长的需求文档。
3. 指导实践的原则¶
3.1 原则 #1：分而治之¶
分析和设计应始终强调关注点分离（Separation of Concerns, SoC），将复杂问题分解为更小、更易管理的部分。
示例：在系统设计中，可以将系统分为多个模块，每个模块负责特定的功能。例如，在Web应用中，可以将前端、后端和数据库分离，每个部分独立开发和测试。
3.2 原则 #2：理解抽象的使用¶
抽象是简化复杂系统元素的一种方式，通过抽象可以更好地传达系统的核心概念。
示例：在面向对象编程中，类（Class）是对现实世界对象的抽象，通过定义类的属性和方法，可以简化复杂系统的设计和实现。
3.3 原则 #3：追求一致性¶
一致性使软件更易于使用，用户界面、代码风格和设计模式都应保持一致。
示例：在用户界面设计中，按钮、菜单和对话框的样式和布局应保持一致，使用户能够快速熟悉和操作软件。
3.4 原则 #4：关注信息的传递¶
在分析、设计、构建和测试过程中，应特别关注接口的设计，确保信息的有效传递。
示例：在API设计中，应定义清晰的接口规范，确保不同模块之间的数据传递准确无误。例如，RESTful API通过HTTP方法（GET、POST等）和状态码（200、404等）来传递信息。
4. 沟通原则¶
4.1 原则 #1：倾听¶
在沟通中，应专注于对方的言辞，而不是急于回应。
示例：在需求讨论会上，开发人员应认真听取客户的需求，理解客户的真实意图，而不是急于提出解决方案。
4.2 原则 #2：沟通前做好准备¶
在沟通前，应花时间理解问题，确保沟通的有效性。
示例：在项目启动会上，项目经理应提前准备好项目背景、目标和计划，确保会议的高效进行。
4.3 原则 #3：指定沟通活动的负责人¶
每次沟通会议都应有负责人，确保讨论朝着正确的方向进行，并调解可能出现的冲突。
示例：在Scrum的每日站会中，Scrum Master负责引导会议，确保每个成员都能及时汇报进展和问题。
4.4 原则 #4：面对面沟通最佳¶
面对面沟通通常更有效，尤其是在有其他信息表示（如文档、图表）的情况下。
示例：在需求讨论中，面对面的沟通可以帮助双方更好地理解需求，减少误解。同时，使用白板或图表可以更直观地表达复杂的概念。
5. 规划原则¶
5.1 原则 #1：理解项目范围¶
在规划之前，必须明确项目的范围，确保团队知道目标是什么。
示例：在项目启动阶段，团队应与客户明确项目的目标和交付物，确保双方对项目的范围有一致的理解。
5.2 原则 #2：让客户参与规划¶
客户定义了项目的优先级和约束条件，因此在规划过程中应积极与客户沟通。
示例：在敏捷开发中，客户作为产品负责人（Product Owner）参与每个迭代的规划会议，帮助团队确定任务的优先级。
5.3 原则 #3：规划是迭代的¶
项目计划不是一成不变的，随着工作的进展，计划可能需要调整。
示例：在项目执行过程中，团队应根据实际情况调整计划。例如，某个任务的实际工作量超出预期，团队可以重新评估任务的优先级和时间安排。
5.4 原则 #4：基于已知信息进行估算¶
估算应基于团队对当前工作的理解，提供工作量、成本和任务持续时间的指示。
示例：在敏捷开发中，团队可以使用故事点（Story Point）来估算任务的复杂度，并根据历史数据进行调整。
6. 建模原则¶
6.1 需求建模原则¶
需求建模应涵盖信息域、功能域和行为域，并以分层的方式逐步揭示细节。
示例：在需求分析中，可以使用用例图（Use Case Diagram）来描述系统的功能，使用活动图（Activity Diagram）来描述系统的行为。
6.2 设计建模原则¶
设计模型应可追溯到需求模型，并考虑系统的架构、用户界面和组件级细节。
示例：在系统设计中，可以使用类图（Class Diagram）来描述系统的结构，使用序列图（Sequence Diagram）来描述组件之间的交互。
7. 构建原则¶
7.1 编码原则¶
在编写代码时，应遵循结构化编程实践，选择合适的数据结构，并保持代码的简洁和可读性。
示例：在编写代码时，应使用有意义的变量名，遵循编码规范，并通过适当的缩进和空行提高代码的可读性。
7.2 测试原则¶
测试应追溯到客户需求，测试计划应在测试开始前制定，并遵循帕累托原则（80%的错误集中在20%的代码中）。
示例：在测试过程中，应优先测试那些容易出现错误的模块，并根据测试结果进行代码重构和优化。
8. 部署原则¶
8.1 管理客户期望¶
在软件交付前，应管理客户的期望，确保客户对软件的功能和性能有合理的预期。
示例：在软件交付前，团队应与客户进行沟通，明确软件的当前状态和未来的改进计划，避免客户对软件有过高的期望。
8.2 提供完整的交付包¶
在软件交付时，应提供完整的交付包，包括安装程序、用户手册和技术文档。
示例：在软件交付时，团队应确保交付包中包含所有必要的文件，并通过测试确保交付包的完整性和可用性。
结论¶
软件工程的基本原则为软件开发提供了长期的指导，帮助开发人员在快速变化的技术环境中保持高效和质量。通过理解和应用这些原则，团队可以更好地应对复杂的软件开发挑战，交付高质量的软件产品。
SE31: 项目管理概念¶
在软件工程中，项目管理是确保项目成功的关键因素之一。本章将详细探讨项目管理的核心概念，包括“四个P”、利益相关者、软件团队的组织与领导、团队协作与沟通、产品范围的定义、问题分解、过程管理以及项目的常见问题与应对策略。
1. 项目管理的“四个P”¶
项目管理的核心可以归纳为“四个P”：
- 人员（People）：项目成功的最重要因素。无论是项目经理还是开发人员，团队成员的技能、协作能力和积极性都直接影响项目的进展。
- 产品（Product）：要构建的软件。明确产品的需求和目标是项目管理的首要任务。
- 过程（Process）：完成项目所需的框架活动和软件工程任务。合理的过程管理能够确保项目按计划推进。
- 项目（Project）：使产品成为现实所需的所有工作。项目管理需要协调资源、时间和任务，确保项目按时交付。
2. 利益相关者¶
项目的成功离不开各利益相关者的支持与协作。主要的利益相关者包括：
- 高级管理层：定义业务问题，对项目有重大影响。
- 项目经理：负责计划、激励、组织和控制开发人员。
- 开发人员：提供技术技能，负责软件的实现。
- 客户：指定软件需求，关注项目的最终成果。
- 最终用户：使用软件的用户，他们的反馈对产品的改进至关重要。
3. 软件团队的组织与领导¶
软件团队的组织和领导是项目成功的关键。以下是团队领导的核心模型和常见的组织范式：
3.1 MOI模型¶
- 激励（Motivation）：鼓励团队成员发挥最佳能力。
- 组织（Organization）：建立或改进流程，确保项目从概念到产品的顺利过渡。
- 创新（Ideas）：鼓励团队成员在既定框架内发挥创造力。
3.2 组织范式¶
- 封闭式范式：传统的层级结构，强调权威和控制。
- 随机范式：松散的结构，依赖团队成员的主动性。
- 开放式范式：结合封闭式和随机范式的优点，既控制又鼓励创新。
- 同步范式：依赖问题的自然分解，团队成员独立工作，减少沟通。
4. 团队协作与沟通¶
有效的团队协作和沟通是项目成功的基础。常见的沟通方式包括：
- 正式的非个人沟通：如技术文档、项目里程碑、错误跟踪报告等。
- 正式的个人沟通：如状态评审会议、设计和代码审查。
- 非正式的个人沟通：如团队会议、需求与开发人员的协作。
- 电子沟通：如电子邮件、电子公告板、视频会议。
- 人际网络：与团队成员及外部专家的非正式讨论。
5. 产品范围的定义¶
明确产品范围是项目管理的首要任务。产品范围包括：
- 上下文：软件在更大系统或业务中的位置及其约束。
- 信息目标：软件输出的数据对象及其输入需求。
- 功能和性能：软件如何将输入数据转换为输出，是否有特殊性能要求。
- 可靠性、接口、安全性：软件的其他关键特性。
6. 问题分解¶
问题分解（也称为分区或问题细化）是将复杂问题分解为更小、更易管理的部分。分解过程包括：
- 功能分解：将产品范围分解为具体的功能模块。
- 数据对象分解：将产品范围分解为用户可见的数据对象。
- 问题类分解：将产品范围分解为一系列问题类。
7. 过程管理¶
一旦确定了过程框架，项目管理需要考虑以下因素：
- 项目特性：如项目规模、复杂度等。
- 严格程度：根据项目需求确定过程的严格程度。
- 任务集：为每个软件工程活动定义任务集，包括任务、工作产品、质量保证点和里程碑。
8. 项目的常见问题与应对策略¶
项目常常会遇到以下问题：
- 需求不明确：客户需求未被充分理解。
- 范围定义不清：产品范围模糊或定义不当。
- 变更管理不善：变更未得到有效控制。
- 技术变化：所选技术发生变化。
- 业务需求变化：业务需求未明确定义或发生变化。
- 不切实际的截止日期：项目时间安排不合理。
- 用户抵制：用户对项目成果不认可。
- 缺乏赞助：项目缺乏足够的支持。
- 团队技能不足：团队成员缺乏必要的技能。
- 忽视最佳实践：项目团队未遵循最佳实践。
9. 项目管理的常识性方法¶
为了确保项目成功，项目管理可以遵循以下常识性方法：
- 正确起步：充分理解问题，设定现实的目标和期望。
- 保持动力：减少人员流动，强调质量，避免管理层过度干预。
- 跟踪进展：通过工作产品的评审跟踪项目进展。
- 明智决策：保持简单，避免过度复杂化。
- 事后分析：从每个项目中提取经验教训，持续改进。
10. 项目的本质问题¶
要理解项目的本质，必须回答以下问题：
- 为什么开发该系统？
- 要做什么？
- 何时完成？
- 谁负责？
- 他们在组织中的位置？
- 如何从技术和管理上完成工作？
- 需要多少资源（如人员、软件、工具、数据库）？
11. 关键实践¶
项目管理中的关键实践包括：
- 正式风险管理：识别和管理项目风险。
- 经验性成本与进度估算：基于历史数据进行估算。
- 基于度量的项目管理：通过度量指标管理项目。
- 挣值跟踪：跟踪项目的实际进展与计划。
- 缺陷跟踪与质量目标：跟踪缺陷，确保质量目标达成。
- 人员意识的项目管理：关注团队成员的需求和动机。
通过以上内容，我们可以看到，项目管理不仅仅是技术问题，更是人员、过程和资源的综合管理。只有全面考虑这些因素，才能确保项目的成功交付。