开发方法和生命周期绩效域

1、开发方法和生命周期绩效域概览

开发方法和生命周期绩效域的相关核心概念

• 开发方法 ：在项目生命周期内用于创建并改进产品、服务或结果的方法，例如预测型、迭代型、增量型、敏捷型或混合型方法
• 节奏 ：在整个项目期间所开展活动的节律
• 项目阶段 ：一组具有逻辑关系的项目活动的集合，通常以一个或多个可交付物的完成为结束
• 项目生命周期 ：项目从开始到结束所经历的一系列阶段

1.1不同生命周期的比较

• 预测型生命周期 。这是一种更为传统的方法，提前进行大量的计划工作，然后一次性执行；执行是一个连续的过程
• 采用迭代型方法的生命周期 。这种方法允许对未完成的工作进行反馈，从而改进和修改该工作
• 采用增量型方法的生命周期 。这种方法向客户提供各个已完成的，可能立即使用的可交付物
• 采用敏捷型方法的生命周期 。这种方法既有迭代，也有增量，便于完善工作，频繁交付价值

2、敏捷相关的基本知识

2.1、敏捷宣言回顾

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值

2.2、敏捷原则回顾

1. 我们最优先要做的是通过 尽早的、持续的交付有价值的软件 来使客户满意
2. 即使到了开发的后期，也 欢迎改变需求
3. 经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好
4. 在整个项目开发期间， 业务人员和开发人员必须天天都在一起工作
5. 围绕 被激励起来的个人 来构建项目
6. 在团队内部，最具有效果并且富有效率的传递信息的方法，就是 面对面的交谈
7. 工作的软件是首要的进度度量标准
8. 敏捷过程提倡平稳的开发节奏；发起人、开发者和用户应该能够保持一个
   长期的、恒定的开发速度
9. 不断地关注优秀的技能和好的设计会增强敏捷能力
10. 简单化是根本（不做过度设计和预测）
11. 最好的构架、需求和设计出自于 自组织的团队
12. 每隔一定时间，团队会在如何才能更有效地工作方面 进行反思 并对自己的行为进行相应调整

1
2
3
4
5
6
7
8
9
10
11
12

持续交付，小步快跑
拥抱变化，提高优势
尽早反馈，价值排序
成果达成，衡量进度
持续更新，强化敏捷
精简产品，杜绝浪费
团队合作，每日互动
信任成员，给予支援
当面沟通，高效明了
各方成员，稳定节奏
同心协力，自我组织
团队自省，持续改进

敏捷的灵魂是思维模式的转变，而不是工具方法的堆砌

2.3、敏捷的角色

• 敏捷团队中有三种常见的角色：
  ✓跨职能团队成员（team）
  ✓产品负责人（PO）
  ✓团队促进者（team Facilitator，在不同的模型中可被成为Scrum Master，Team Leader，Project Manager等）
• 其他的辅助性角色：
  ✓治理团队
  ✓PMO

2.3.1跨职能团队成员（team）

• 一般情况人数在 3 - 9 个左右
• 团队成员跨职能（包括开发人员、测试人员、用户界面设计师等），鼓励成为T型人才，最好是 全栈式工程师
• 敏捷团队成员需要全职，不能随意发生变化（至少迭代内），否则影响团队速度
• 在团队章程内有权力做任何工作形式的决策来确保达到迭代/冲刺的目标
• 高度的自组织能力（重点强调尊重、承诺和责任，而不是肆无忌惮的自由散漫）
• 需要向Product Owner演示产品功能
• 团队需要定义DoD（针对所有任务的）

2.3.2DoD/AC/DoR的区别和联系

• 在敏捷项目管理中，常用Definition of Done“完成的定义”来表示工作是否已完成，不同的活动有不同的完成定义（迭代DoD、发布DoD、每日DoD、用户故事DoD等）
• 用户故事的DoD实例：
  ✓用户故事最终的描述符合INVEST
  ✓用户故事得到测试用例的对应覆盖
• DoD是针对于所有需求，任务，迭代，交付定义的（整体性），而验收标准AC（Accept criteria）是针对每个需求定义的（局部性）
• DoR（Definition Of Ready）是某一个阶段正常开启的先决条件。而DoD则是某阶段产物完成的标准和原则

2.3.3产品负责人（Product Owner）

• 产品负责人（Product Owner）的职责如下：
  ✓确定产品的功能
  ✓决定发布的日期和发布内容
  ✓根据市场价值等因素确定需求（用户故事）的优先级
  ✓为产品的profitability of the product (ROI)负责
  ✓每个冲刺/迭代（Sprint）前，根据需要调整功能和优先级
  ✓接受或拒绝接受开发团队的工作成果
  ✓作为客户代言人，接收不同的需求和反馈，并不断梳理待办
  项清单，但不能在迭代中影响团队现有的工作

2.3.4 团队促进者（Team Facilitator ）

• 此角色在不同的敏捷模型中可能被称为项目经理、Scrum Master、Team Facilitator等
• 促动者倡导仆人式领导（servant leadership）
• 促动者更像是守望者，不是做决策，而是提供支持。对流程负责，对内容不负责
• 和Product owner及团队紧密地工作在一起，他可以及时地为团队成员提供帮助
• 确保团队资源完全可被利用并且全部是高产出的，否则应提供相应的培训和指导
• 保证各个角色及职责的良好协作，让大家了解敏捷的真正作用与相关要求
• 解决团队开发中的障碍（沟通障碍、流程障碍等）
• 做为团队和外部的接口，处理外界对团队成员的干扰（信息发射源、看板解决信息
  不对称的问题；新的需求转移给PO解决新需求影响团队的问题）
• 保证开发过程按计划进行，组织各种会议（如Scrum中的：站立会（Daily Scrum）,冲刺回顾会、迭代规划会等）

2.3.5仆人式（服务型）领导为团队赋权

• 敏捷方法强调，仆人式领导是一种为团队赋权的方法。仆人式领导是
  通过对团队服务来领导团队的实践，它注重理解和关注团队成员的需
  要和发展，旨在使团队尽可能达到最高绩效
• 以下仆人式领导的特征让项目领导变得更加敏捷，促进团队的成功：
  ✓提升自我意识（ 不强行决策与干预 ）
  ✓倾听（ 了解根因与现状，了解团队的情绪 ）
  ✓为团队服务（ 解决团队现有的障碍 ，而不是制造麻烦）
  ✓帮助他人成长（ 培训与辅导 ）
  ✓引导与控制（ 让团队说话，在流程上控制好，而不是内容 ）
  ✓促进安全、尊重与信任（ 先私下沟通，鼓励团队自组织 ）
  ✓促进他人精力和才智提升（ 减少其他人对团队的影响 ）

2.3.6敏捷PMO

• 设立PMO的目的是引导组织实现商业价值。敏捷PMO为价值驱动型、面向创新型、多学科型
• 敏捷PMO可进行如下职责：
  ✓ 制定和实施标准 。提供用户故事、测试案例、累积流图等模板，提供敏捷工具并培训支持小组了解迭代开发概念
  ✓ 通过培训和指导发展人才 。协调敏捷培训课程、教练和导师以帮助员工过渡到敏捷思维模式并升级其技能。鼓励和支持员工参与本地敏捷活动
  ✓ 多项目管理 。通过不同项目交流协调敏捷团队。考虑分享进度、问题、回顾性发现和改进实
  验等内容。借助适当的框架，帮助管理项目层的主要客户发布和项目组合层的投资主题
  ✓ 促进组织学习 。收集项目进度信息并获取、存储和记录回顾性发现成果
  ✓ 管理干系人 。提供产品负责人培训，指导验收测试以及评估方法，并提供系统反馈。宣扬主题专家(SME)对项目的重要性
  ✓ 招聘、筛选和评估项目领导 。制定敏捷实践者访谈指南
  ✓ 执行专业化项目任务 。培训和提供回顾促进者，与敏捷项目问题解决者订立协议，并提供导师和教练

2.4、敏捷相关的基本知识

2.4.1 敏捷方法

• 敏捷方法是在敏捷宣言（ 4 条）、敏捷原则（ 12 条）的指导下，根据不同的场景总结出的良好实践
• 在PMI《敏捷实践指南》中，“敏捷方法”是一个囊括了各种框架和方法的涵盖性术语

2.4.2 看板的作用与优势

• “看板”一词按字面翻译为“视觉符号”或“卡片”。带有卡片的物理看板面板能够推动和实现整个系统中工作流的可视化，让每个人都可以看到
• 该信息发射源包含许多列，表示需要完成的工作流的状态。最简单的面板可能包含三列（即，要完成的工作、进行中的工作和已完成工作），但可以调整为使用团队所需要的任何状态
• 看板方法应用并适用于多种场合，可以确保工作流和价值交付的持续性
• 在看板方法中，完成工作比开始新工作更为重要。从未完成的工作中无法获得任何价值，因此团队将协作实施和遵从在制品(WIP) 限制，让整个系统中的每份工作得以“完成”
• 考试中，看板通常用来起到展示项目情况、透明各方信息的作用

2.4.3 极限编程——eXtremeProgramming

• 轻量级的开发流程

• 最主要的精神是：在客户有系统需求时，给予及时满意的可执
  行程序，所以最适合需求快速变动的项目

• 它强调客户所要的是workable的执行代码，所以把与撰写程序
  无关的工作降至最低，并要求客户与开发人员最好以side-by-
  side的方式一起工作

• XP的实践包括：
  ✓完整团队、计划游戏、客户测试
  ✓简单设计、 结对编程、测试驱动开发
  ✓改进设计、 持续集成 、集体代码所有权
  ✓编码标准、隐喻、可持续的速度

• 持续集成 。无论产品如何，都要频繁地将工作集成到整体中，然后再进行重新测试，以确定整个产品仍然按照预期工作

• 在不同层面测试 。对端到端信息使用系统级测试，对构建块使用单元测试。在两者之间，了解是否需要进行集成测试，以及在何处进行测试。团队发现冒烟测试有助于测试工作产品是否良好。团队
  发现，决定何时以及对哪些产品运行回归测试，可以帮助他们在维护产品质量的同时，良好地构建性能。敏捷团队非常偏爱自动化测试，因此他们可以借此构建和保持交付的势头

• 验收测试驱动开发(ATDD) 。在ATDD中，整个团队聚集一起讨论工作产品的验收标准。然后，团队创建测试，这让团队能够编写足够的代码，进行自动化测试，满足标准要求。对于非软件项目，要考虑怎样在团队完成大量价值时对工作进行测试

• 测试驱动开发(TDD)和行为驱动开发(BDD) 。在编写/创建产品之前编写自动化测试，实际上可以帮助人员设计产品，防范产品错误。对于非软件项目，要考虑如何通过“测试驱动”团队的设计。硬件和机械类项目经常使用模拟进行设计的中间测试

• 刺探（时间盒研究或实验） 。刺探对学习很有用，可以在诸如评估、验收标准定义以及通过产品了解用户行为的流程中使用。在团队需要学习一些关键技术或功能要素时，刺探会很有帮助

2.4.4 Scrum

Scrum包括了 一系列实践和预定义角色的过程骨架 。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员

2.4.5 Sprints（冲刺）

• Scrum的项目过程由一系列的Sprint组成
• Sprint的长度一般控制在 2 - 4 周
• 通过固定的周期保持良好的节奏
• 产品的设计、开发、测试都在Sprint期间完成
• Sprint结束时交付可以工作的软件
• 在Sprint过程中不允许发生变更

2.4.6 Scrum of scrums

• Scrum of Scrums (SoS) 也称为“meta Scrum”，是由两个或多个Scrum 团队而不是一个大型Scrum 团队所使用的一种技术
• 其中一个团队包含三到九名成员来协调其工作。每个团队的代表会与其他团队代表定期召开会议，可能是每日例会，但通常是一周两次或三次
• 每日例会的执行方式类似于Scrum 的每日站会，其中代表将报告已完成的工作、下一步工作设置、任何当前障碍以及可能会阻碍其他团队的潜在未来障碍。其目标是确保团队协调工作并清除障碍，以优化所有团队的效率
• 具有多个团队的大型团队可能要求执行Scrum of Scrum ofScrums，其遵循的模式与SoS 相同，每个SoS 代表向更大组织的代表报告

2.4.7 时间盒（Time Box）

​ 时间盒的价值：

• 帕金森定律的一剂良药
• 人们往往记住失误的日期，而不是失误的特征
• 尽早促成难度大的决策和权衡
• 更好的控制
• 防止镀金，因为时间盒很短，没有时间镀金
  运作规则：
• 在每个时间盒过程中，不要增加人员。Brook定律：在一个滞后的项目中加人只
  能使其滞后
• 时间盒不用来做绩效考核
• 时间盒内不许有变更
• 每日同步

2.4.8 敏捷的其他常见模式

• 追逐太阳模式 ：追逐太阳的开发过程是一种每天结束时将工作移交给下一个工作地点（可能相差很多时区）的方法，旨在为加快产品的开发
• 鱼缸窗口模式 ：各个地点之间建立长期视频会议链接，创建一个鱼缸窗口。每天工作开始时，打开链接，工作结束时，关闭链接
• 远程结对模式 ：结对编程是一种由两名团队成员结对、同时从事同一工作项目的技术。而远程结对是通过使用虚拟会议工具来共享屏幕，包括语音和视频链接，建立远程对接

2.5、敏捷相关的基本知识

2.5.1 混合型生命周期存在的意义和价值

• 项目管理的目标是在当前环境下尽可能以最好的方式创造商业价值。
• 项目采用何种生命周期的元问题：“我们怎样做才能最成功地交付价值？”
• 混合型生命周期解决价值交付过程中 组织不能完全敏捷的场景 、 敏捷过渡期的场景 、 加速预测生命周期交付速度的场景 以及 改变团队成员思维模式的场景 。目的是为了增加价值交付的效率和效果
• 当团队创造价值时，是否需要快速阶段性反馈？如果需要，增量方法将会有所帮助。在探讨各种想法时，是否需要随时管理风险？如果需要，迭代方法或敏捷方法将会有所帮助
• 当组织无法交付中间价值时，完全的敏捷方法可能不是很有用。可能会选择部分使用敏捷，部分使用预测型生命周期的方式来做项目

2.5.2 混合型生命周期的不同类型

• 敏捷的工具和预测的计划模式在整个生命周期同步存在 。比如：同一项目中结合使用了预测计划法和敏捷工具及思想。如短迭代、每日站会和回顾会等。虽然它显然没有充分体现敏捷思维模式、价值观和原则。不过，这是一种典型的混合方法
• 以预测法为主、敏捷方法为辅的方法 。举个例子，某工程公司正在使用一个新的组件建造一个设施。虽然大部分项目可能是常规的、可预测的，就像组织实施的许多其它的设施项目一样，但这个项目包含了一种新的屋顶材料。承包商可能计划首先在地面上进行一些小规模的安装迭代试验，以确定最佳的安装方法，并在有足够时间解决问题时尽早发现问题
• 以敏捷方法为主、预测法为辅的方法 。当某个特定要素不可协商，或者使用敏捷方法不可执行时，可能会使用这种方法。这种情况的例子包括，集成由不同供应商开发的外部组件，这些外部组件不能或不会以协作或增量方式合作。在组件交付之后，需要单独集成

2.5.3 混合型生命周期的答题思路

• 混合型生命周期的考察重点是敏捷的灵魂（敏捷宣言和原则），偶尔
  会直接考察敏捷的具体工具（如看板、燃尽图等）
• 混合型生命周期的题目会对项目经理/SM的角色定位考察比较深入，
  全面了解考生是否对VUCA环境下项目经理的角色定位有深刻的洞见
  和理解
• 混合型生命周期对沟通和协同的考察比较多，项目经理/SM需要有充
  分的仆人式领导力来为团队扫清障碍，并学会选择优秀的试点推广敏
  捷思想，并且通过结果证明敏捷方法的好处与优势
• 混合型生命周期的部分题目还会关注项目的质量问题，需要对DoD、
  AC、DoR有清楚的理解和认知
• 混合型生命周期是稳定和灵活的一种平衡，需要注意通过治理团队的
  决策作用、产品目标和冲刺/迭代目标的清晰共识、PMO的多项目协
  同让项目更稳定

2.5.4 敏捷转型成功的策略与方法

• 要点一 ：渐进的过渡涉及到要增加更多的迭代技术，以便改进学习，加强团队和干系人的一致性
• 要点二 ：考虑增加更多的增量技术，以加快对发起人的价值和投资回报
• 要点三 ：可以先在一个风险不大、具有中低程度不确定性的项目中尝试这些新技术
• 要点四 ：通过组织成功地使用混合方法后，再尝试更复杂的敏捷项目，这些项目需要增加更多的敏捷技术。这是一种根据组织的情况、特定的风险，以及团队适应并接受变革的就绪情况而调整的渐进混合的良好过渡