敏捷管理（2）- 敏捷价值、需求、估算、计划、监控、风险管理

敏捷的工作价值

   在Scrum的工作流程图中可以看到，PO的主要职责是排列用户故事的优先级，确保价值最优，不会落后于市场，所以敏捷讲的是价值驱动交付。

合理的项目是要保证产生商业价值，并去创造收益或提高服务品质。在每一个组织所选择的项目中，没有一个项目是不会带来价值的。价值可以是经济上的价值，也可以是提升了组织能力的价值，如品牌知名度等。在商业价值中，项目的安全性和合规性可以用商业风险和无法承担的影响来理解。所以，如果做项目的原因是创造价值，那么价值驱动的交付必须贯穿于整个项目规划、执行和监控工作中。如果在做选择时，是不考虑价值驱动开发的长远目标，未来可能会出现问题或导致反馈风险，甚至会在进度前期产生假象。因此，团队需要考虑这些将会影响项目的非功能性需求、风险和客户的建议。

   敏捷推崇尽早交付价值，这意味着团队更注重于尽快交付项目当中价值最高的部分（优先级最高）。毕竟在一个长期运行的项目中，较长的工期会带来风险，如失败、收益减少、机会消失。因此，为了尽可能达到成功，应该更注重于在事情变化或者出现偏差之前，尽快交付高价值的部分。

   其次，相关方对项目的满意度成为一个项目成功的重要因素。支持项目的发起人或业务代表对排除障碍和定义成功起到了至关重要的作用。当前期交付了高价值的内容之后，团队给发起人演示了他们对需求的理解，展示了他们对项目关键部分的共识，并证明他们可以交付成果。有形的成果将会提高发起人的信心，并与他们建立融洽的关系，使他们尽早介入，创造良性循环。

   总之，价值驱动交付就是对项目中排列有附加价值的活动与减小风险的活动之间的优先级做抉择，然后按照这个优先级执行。

 

经济价值评估方法

   商业价值通常是指金融方面的评估，有些项目是为了安全或法规遵从性目的和不易确定的货币价值。在这些情况下，组织可能会想不承担项目的财务影响。

  对于商业项目，价值估算的方法有净现值（NPV）、投资回报率（ROI）、内部收益率（IRR）等组合而成的经济模型得出的具体数值进行选择可以减少个人的偏见，在选择项目上也会更乐观。

 

敏捷的价值产出

   传统项目所产生的价值一般都是在整体项目完成之后才能看到，但是敏捷使用增量的方式，每一个阶段都会有价值产生，这样就可以在第一时间获得客户的认可，这不仅减少了回收期，而且也降低了经济风险。

   传统项目管理范围是固定的，但是时间和成本是灵活的。而敏捷项目管理正好是相反的，时间和成本是固定的，但是范围是灵活的，如果工作按照时间完不成目标数量的工作，就砍掉低优先级的工作。

 

小结

   价值驱动交付就是对项目中排列有附加价值的活动与减小风险的活动之间的优先级做抉择，然后按照这个优先级执行。

   商业价值通常是指金融方面的评估，使用经济指标组合成模型来进行评估。

   传统项目所产生的价值一般都是在整体项目完成之后才能看到，但是敏捷使用增量的方式，每一个阶段都会有价值产生。

 

价值优先级排序方法

   优先级是敏捷流程的基础，即对需求进行优先级排序，把对客户重要的需求先研发出来。敏捷团队通常使用优先级的方法来确认他们正在交付的价值。

在每一个迭代结束的时候，团队和客户都会评审待开发项，来确认下一个迭代需要改变哪些事情，以及下一个迭代要做的工作内容。在两个迭代的中间，可以重新对优先级进行排序，并在下一个迭代中规划相关的工作。

 

基于客户价值的优先级排序

   客户价值的优先级方法关注尽快为客户产生高价值的工作。敏捷方法都是通过优先级的列表来识别客户所需的价值。

 

简单方案

基于主观经验，从高到低排序。

 

MoSCoW方案

在DSDM里使用到，将需求分为Must（必须做）、Should（应该做）、Could（可以做）、Would Not（不要做）。例如微信发送文字消息是必须做的需求；发送语音消息是应该做的需求；表情是可以做的需求；聊天时弹出广告是不可以做的需求。

 

虚拟钱币

经济价值估算，按照钱币得到最多的就是优先级最高的特性进行排序。

 

100点方法

每个成员都有100点来分配给多个需求，按照点数进行高低排序。

 

Kano分析

将需求分为基本需求、期望需求、兴奋需求。例如酒店的洗手间是必须有的基本需求；酒店还提供健身房这类期望需求，也叫线性需求，提供的产品或服务比较优秀，这类需求越多，客户越满意；酒店还有露天的无边界游泳池这种出人意料的附加价值，使得顾客产生惊喜，常常是一些未被客户了解的需求，用户在看到这些功能之前并不知道自己想要它们，这类需求可以提高客户忠诚度，也可以为产品增加额外价格。

 

相对优先级排序

   就是一个简单的列表，从上到下的顺序依次是高中低。当增加新的特性时，可以和现有列表的特性进行比较，并为其设定优先级。

 

小结

   基于客户价值的优先级排序方法：简单方案、MoSCoW方案、虚拟钱币、100点方法、Kano分析。

   相对价值排序就是从上到下的高中低排序。

 

交付增量的价值

   如果交付的产品是在测试环境，而不是生产环境中，这种方法所看到的仅仅是产品总体的价值。但是对于增量交付来说也有其自身的问题，就是到了后期，对缺陷的修订成本很高。

 

最小可行性产品（MVP）

   如果某个或多个功能已经足够代表这款产品了，而这些功能就叫做最小市场特性（MMF），进而投入到市场以最小的代价获得市场的反馈，而这反复试验的过程被称为最小可行性产品（MVP）。即增量规划符合需求的，由市场验证后期做调整。

 

敏捷常用工具与价值衡量

   复杂的工具虽然可以产生大量记忆深刻的报告和图标，但是由于其复杂性，不是所有人都能掌握好的，所以敏捷团队更愿意选择易于掌握的工具，如任务版、用户故事索引卡片、规划扑克便于大家交流。

   低技术高感知的工具，这样的工具更贴近软件开发，当然这样的工具也并不意味着具有全部优点，只是相比较来说会更好。

 

任务板与看板

看板：一般用于看板团队是一种拉动式的管理方法比较看中团队生产力，看板是可以根据自己的生产能力选择添加任务的，并且看板是没有估算的，团队成员也不会对任务进行承诺。

任务板：经常用于Scrum团队中，比起看板，任务版会有角色（PO、SM、Team），会有规定的时间限制，在迭代期间是拒绝增加任务的，并且任务是需要进行估算，团队成员对其任务进行承诺。开发团队适用任务板，运维团队适用看板。共同都是要有WIP（制品）限制，其次都是分阶段的。

 

在制品（WIP）和在制品限制

工作已经开始但还没有完全结束，WIP就是已安排的工作，在这些工作完成之前不接受其他工作。

低限制的看板将会很容易识别出哪些事务阻碍了工作流，让人们可以更有效率的方式来降低制约和移除瓶颈。

例如可能让其他团队成员去做一些预处理的工作。当第一个制约被移除时，可以重新执行这个过程去看看是否有其他事务再次导致工作流缓慢。反复的执行这个过程知道人员产生了闲置。这样用了绝大部分时间去完成工作任务，生产效率也提高了。

WIP限制的目的是优化工作生产效率，不是优化资源利用。

 

累计流量图（CFD）

综合的价值流度量方法，通过它可以得到不同维度的信息，也可以跟踪和预测敏捷项目，帮助了解项目的问题，循环时间、可能的完成时间。

 

小结

   最小市场特性（MMF）、最小可行性产品（MVP）。

   敏捷常用工具有任务板（开发团队）、看板（运维团队）、WIP、累积流量图（CFD）。

 

利特尔定律

如果WIP越多，循环时间越长，意味着当遇到问题的时候，潜在的浪费越多。

 

核实和验证价值

   验证团队创造需要的东西是否跟刚开始描述的东西是一致的。

 

频繁的验证和确认

   使用常规的测试、检查点和评审等技术来解决，这种实践称为频繁的验证和确认，如XP的结对编程。

 

软件开发中的测试和验证

探索性测试

不断学习、探索，不断修正测试方法，强调灵活性的记录测试产物，而不必循规蹈矩，十分强调人的能动性是最大的亮点。实际上就是把戴明环的PDCA发挥到极致。

 

可用性测试

竞争对手比较，不同方案比较，易学性、易记性、容错性、交互效率和用户满意度。

 

持续集成

敏捷项目能够尽可能早的处理问题的一个例子。多人进行项目的多个独立部分的开发，然后把这些部分集成起来，以便创建一个兼备功能与价值的产品。尽早发现问题，在最短时间内解决问题，减少风险和浪费。

 

测试驱动开发（TDD）

要求编写某个功能代码之前，先编写测试用例，通过测试来推动整个开发的进行。这不是一种测试技术，而是一种分析技术、设计技术，更是一种组织所有开发活动的技术。优势有更符合后期开发的需求，因为关注用户反馈，可以及时响应需求变更，更快的适应变化。实现松耦合设计，提高系统的可廓形和抗变性。消除重复设计，优化设计结构，高代码的重用性。完整的测试会帮助团队持续的跟踪整个系统状态。提高团队对代码的信心及对代码重构的勇气，快速提高开发效率。

 

验收测试驱动开发（ATDD）

测试的焦点从代码本身转向业务需求。测试会在编码工作之前被创建。经历如下数个阶段：讨论需求、提炼测试、开发代码并链接测试和使用自动化验收测试脚本来进行探索性的测试，并演示软件。

 

小结

   频繁的验证和确认开发出来的产品。

   软件开发中的测试与验证常用方法：探索性测试、可用性测试、持续集成、测试驱动开发（TDD）、验收测试驱动开发（ATDD）。

 

敏捷需求拆解

   敏捷方法中，不必说明完整的需求。在最初的时候要保证需求的粗粒度，然后随着过程的进展，不断的细化它们。这样有助于保证产品设计的平衡，所以产品不会出现特定领域的过度设计。

   也不会出现匆忙开发导致新信息或突发的需求变更而知需要修改的模块。敏捷是拥抱变更，当建立不断扩大的系统时，更早的获得反馈。

 

基于价值的分析

   敏捷规划是基于价值的分析，是对工作项的业务价值进行评估和排序的过程，然后对其进行规划。这个工作的业务价值是什么？应该如何得到最高的业务价值？

 

基于价值的分解

   这是从相关方那里引出需求的过程，排列这些需求，然后按照优先级排列顺序放入开发过程中。

   开踢会议交流业务需要和见解来定义项目的边界和目的，进而获得项目愿景，从而匹配客户的使命、目标和成功标准。

   在通过特性工作坊将项目愿景拆分为系统潜在的特性，进行优先级排序，最后输出优先级特性列表，然后进入循环的冲刺开发过程中。

 

建立用户故事

用户故事（User Story）在软件开发过程中被作为描述需求的一种表达形式。是为了规范用户故事的表达，便于沟通与理解用户需求，包含：

角色，谁要使用这个功能；

活动，需要完成什么样的功能；

商业价值，为什么需要这个功能，这个功能能带来什么样的价值；

 

好的用户故事应该遵循INVEST原则

独立的（Independent）

用户故事之间具有独立性，不存在应该依赖于其他故事。一般可以组合用户故事或分割用户故事，来减少用户故事间的相互依赖性。

 

可协商的（Negotiable）

用户故事是由客户或者产品负责和开发小组的成员共同协商制定的，不是签订的商业合同，设定一堆的条条框框。

 

有价值的（Valuable）

用户故事站在用户的角度去编写，必须对最终用户是有价值的，描述的是一个个特性，而不是一个个任务。

 

可估算的（Estimable）

对一个用户故事的划分需要足够的领域知识，使得划分故事时就能大致了解故事的开发周期，为了减少估算的不确定性，故事本身不能太大。

 

小的（Small）

尽可能小，也不是说越小越好，最好的故事是能够在一个冲刺周期之内完成的。如果太大，就应该考虑拆分为颗粒度更小的用户故事。

 

可测试的（Testable）

如果一个用户故事无法进行测试，那么也就无法判断该故事是否完成。最后，必须在定义验收测试通过的标准后才能认为故事划分完毕。

 

用户故事待开发项

   用户故事还可以基于不同的技术层次，对故事进行分割，从而撰写用户故事以提供更全面的功能。好处有减少架构的风险，更容易的排列优先级、特性的完成，软件可以加快发布、有利于自动化测试。

   在用户故事完成之后，需要将它们放入待开发项中，是对要完成工作的可视化展示。可以为团队需求优先级提供帮助。

 

需求的层次

在敏捷项目中可以通过冲刺计划达成这点。在项目需求层次中，用户故事处于中间位置。

   特性/史诗

      用户故事

         任务

 

用户故事地图

   大级别的用户故事排在头排，根据优先级，描述用户需求。从而找到一条可以最大化投入产出的路子，可以让各种相关方对功能需求有相对一致的理解和整体的认识。

   最大的特点就是可以完整的讲述整个客户的体验，从用户体验的角度出发，可以验证用户体验的完整性。为敏捷团队提供了一种实现，即用户体验是一个完整的过程。

   更容易看清待开发项（Backlog）的全貌、为产品待开发项梳理（Product Backlog Grooming）和优先级排序（Prioritizing）、允许多维度进行项目规划，确保不同的想法都可以得到考虑和探讨、预防信息蒸发、帮助会议具体细节。

 

梳理待开发项

   Backlog梳理活动，是在下个冲刺开始前，对可能要纳入冲刺中的故事进行细化、估算和优先级排序活动。这个活动中，PO、SM、Team都应该参加。

   PO讲解用户故事背景、业务目标、用户角色、用户场景、业务流程、业务规则，确保团队理解充分并且无异议。

   1、讨论交互流程，画出低保真和交互流程。

   2、讨论测试要点、技术实现方案、技术风险。

   3、估算用户故事规模（故事点数），过大的用户故事拆分成小故事并排列优先级。

 

敏捷估算

   估算是为了确定哪些工作应该在一个版本或冲刺中完成。建立一个整体估算的过程，是对项目开发、上线和维护成本的分解。

   估算的结果应该使用一个范围，以便于管理项目的不确定性。毕竟客户何时改变需求是不知道的。

   做事前估算是必须的，但也是最不精确的，整个项目中需要的是持续的估算，并且最好的估算者是正在涉及工作的团队成员。

   估算是包括了对用户故事规模大小的估算，以及对用户故事完成速度的估算，从而选择适合本次迭代周期的故事数。

 

宽频德尔菲（Delphi）

   基于团队的估算方法， 团队将项目或大问题分解为更多的可管理的模块，创建了一个问题说明书、识别出假设和约束条件，并且概述后续估算周期的过程。然后，一组专家匿名提交估算，进行多伦估算。

 

计划扑克

   宽频德尔菲技术通常用计划扑克来实施，这是一个快速、合作的过程。能使团队快速的进行估算，更加准确和有意思。

   在敏捷中，更加看重的是团队的整体。正如约翰梅纳德凯恩斯说的：粗略的正确好过精确的错误。

   最好的估算的方法是：允许我们改变我们的想法、不要花太多时间、为后续工作提供可用的信息、包容估算的不精确、能够用于发布计划。

   注意点：团队将自己定义故事点；故事点估算应该是将所有时间都包括的，如测试时间；分解时，不需要整体匹配；规划是相对的，复杂性、工作量、风险都计算在内。

 

亲和估算

   参与人包括PO、SM、Team，亲和估算可以快速和更容易估算大量用户故事的技术，是根据之前已经估算的结果，进行分类比较。

 

理想时间和耗用时间

   估算理想时间要比估算耗用时间更加容易，因为耗用时间的不确定因素很多，可能做着做着要写邮件等，并且在实施过程中药避免在两个或多个任务之间切换，因为这会极大的损失效率。

 

估算理想时间

这个故事是唯一需要做的工作、所有需要的事情都准备好了、过程中没有干扰。

步骤：

   决定项目的规划用何种粒度进行估算，是基于故事点还是理想时间。

   计算出结果，团队的产能和能力是按照工时还是人天数或人周数、人月数。

   转换成日程表，包括已经考虑了故事大小规模，需要的资源和依赖条件。

   计算成本，应用劳动生产率及其他涉及的项目花费成本。

 

敏捷计划

   敏捷项目称其为自适应计划，这是一个不间断的过程，有很多种机制可以主动的更新计划。敏捷注重价值交付，所以敏捷认为要尽量稍作无价值的工作。

敏捷是通过实验和示范的方法（原型法）来发现真正的需求，然后对其进行重新计划。

当有不确定的范围和解决方案时，不是期望客户完全用语言来形容产品应该是什么样子，而是应该如何去做。

敏捷项目是依靠建立原型以更好的进行理解，并以此原型为基础，进一步规划和阐述。

   敏捷计划前期投入少，而该计划会在整个项目中贯穿始终，风险和不确定性对前期工作会带来一些问题。所以敏捷方法建议将其分散在整个生命周期中，因此敏捷计划是贯穿整个项目的生命周期的。

敏捷计划在执行过程中不断调整是正常的事情，所以在计划中很多都是渐进明细的，如计划、估算、风险评估、需求确认、架构设计、验收标准、测试用例。

 

计划的过程

PO根据需求层级，决定在每一个发布周期团队可以发布的需求，这是一个概要层次，很粗糙的整体的发布计划；

然后在项目的全生命周期中制定出每个阶段的冲刺计划，这是一个很详细的计划；

客户应该参与到团队中，不断反馈来管理期望，团队利用反馈来驱动项目计划的过程，如优先级调整、演示中产生的变更或新需求、回顾触发流程和技术的改变；

在冲刺结束后，基于现有的信息，更新概要层级信息；

 

发布计划

   敏捷比传统更看重计划，而且做计划的频率更高。按照规模大小排序依次是解决方案计划、发布计划、冲刺计划、每日计划。

发布计划是一个高层级的概述性计划，时间覆盖周期是3~6个月，而根据冲刺周期的冲断可能包含3~12次冲刺。

发布计划对于产品战略非常有帮助，可以帮助相关方了解在哪个阶段发布什么功能，也可以作为小组前进的路标。

PO的职责：确定故事优先级，组织开发人员对用户故事、技术故事的规模和风险进行评估，根据结果在设定优先级。

Scrum Master的职责：确定团队冲刺速率、准备好风险问题跟踪表、组织召开发布计划会议（制定里程碑计划，考虑各方的意见，达成共识，制定可达成的目标计划）。

 

冲刺计划

   冲刺计划是在冲刺计划会议上制定的，参与人包括PO、分析师、测试、UI、开发等。

在规划冲刺时，并不分配任务给具体的人。所以敏捷中，可以是个人一开始不承诺任务，而在冲刺开始之后承诺1~2项任务，在完成承诺任务之前，不安排新的任务。

Scrum Master职责：明确本轮冲刺需要完成的项目范围；帮助提出项目风险并制定风险消解计划；安排实现的先后顺序，讨论用户故事、选择用户故事、定义验收标准和撰写验收测试、拆分用户故事为任务、估算任务。

 

每日计划

Scrum Master组织会议，实践中更主张各自轮流，并且无规矩不成方圆。这个计划的主要目的是沟通、检查和适应。会议在15分钟之内，每日人轮流发言。自上次站会到现在做了什么？计划到下次站会完成什么？遇到的问题。

 

敏捷监控

敏捷的监控在Scrum流程中可以通过冲刺评审与冲刺回顾会议这两个环节来作为组成部分。并且每日站会中也是识别问题的重要机制，在每日站会中还可以尽早发现表面问题或潜在问题。

在工具上可以采用燃尽图和燃起图来可视化的监控项目。燃尽图是向下的，不断减少，可以感受到压力的；燃起图是向上的，不断增加的，需要不断需要鼓励去突破的。

 

发现问题，解决问题

   小洞不补、大洞吃亏，问题解决技术是以在问题发展过于严重而超出变更成本曲线之前解决问题为目标的。

 

过程分析与持续改进

   过程分析：评审和诊断敏捷方法的问题。阿利斯泰尔科伯恩提供了警惕反模式：所有项目用同一方法、无法忍受、厚重、修饰、未尝试、只使用一次。

   持续改进：收尾时期进行检验教训的捕捉，便于组织对那些有着类似的商业或技术领域有着相似团队动力的项目应用这些经验教训。经常性的考虑适应性和改进点。包括检查、适应、改进的经验学习，这些步骤贯穿于每个冲刺当中。

 

风险管理和问题管理（问题发现与解决）

风险管理

   很多项目有了风险管理过程和风险清单，但是并没有将风险管理的时间包含在项目计划中。

其中风险燃尽图这个工具，可以将项目中的高风险工作放到冲刺早期，将可以降低风险的工作放到待开发项中。

每一个发现的风险都需要在商业价值和风险之间进行平衡，研究究竟需要付出多少精力去管理发现的风险。其中风险价值分析技术方法有预期货币价值（EMV，风险发生可能性 X 2000元影响）。

   备注：探针是一种技术方法，是为了减少风险，并且探针会在整个发布中使用到。例如在学习新技术、评估、验收标准定义以及通过产品了解用户行为的流程中应用。

 

风险的探针

   试图研究一个问题而进行简短的概念验证（PO）。采用简短的实验来测试不同选项而研究项目有风险部分的方式是基于风险的探针的关键所在。如果概念验证的执行是成果了，那么便排除这个风险，并减少项目整体风险。

 

基于风险调整的待开发项

消极风险行动包括了规避、缓解和转移。积极风险行动包括了开拓、提高和共享。

积极的接受风险就是要建立风险储备，消极的接受风险就是什么都不做。

风险优先级排序有基于特性分类，也有采用预期货币价值（EMV）。当问到客户代表或客户他们最需要的特性时什么，可以从中了解他们的动机、风险和验收的标准，没有参与客户价值优先级分析的项目很有可能成为错过成功的关键因素。

 

风险的严重程度

风险管理应该是工作进度一个驱动因素。敏捷认为首先要做的事情一定是价值高的事情，即使风险很大。风险优先级会基于两个维度，一个是风险的影响，另一个是风险的发生概率。敏捷中会将风险放在卡片上，而PMBOK指南中是有风险登记册，而敏捷中是没有的。

 

问题管理

   问题往往是已发生的风险，敏捷不依赖于一种被动的问题解决方式。相反是每个冲刺结束时，会有评审和回顾，每个冲刺结束的时候都会捕获这些经验教训，知道自己的长处和短处，并确保这类问题不再发生，这是基于解决问题的基础之上的持续改进流程。

 

 

持续改进式的解决问题方法

Kaizen

来自20世纪70年代的日本，意思是变得更好，意味着持续改进。是敏捷持续改进的基础，比较关注的是对团队的鼓励。讲究的是每日都会进行改进而不是在每个冲刺结束以后。

   多层级的改进：就像剥洋葱分层，在项目多个层次上发生。从外而内依次是产品发布、评审或回顾会议、每日立会、结对编程。

   持续改进的流程：计划会随着项目、环境和相关方的更多了解而发生变化一样，如系统性思考、过程分析、价值流程图等。

   价值流分析：优化每一个流程中值得的环节，消除浪费，为客户提供更有的价值，包括识别需要分析的产品或服务；创建目前流程的价值流，识别步骤、排序、延迟、信息流；评审找出流程中的延迟、浪费和约束；为未来创建新的价值流；创建路线图；规划流程进行再次访问，以持续优化。为价值流进行独立、计划及流程改进；为了解决问题，可以邀请客户一同参与选择故事卡片。

   团队参与：敏捷的解决问题方法是基于团队，并具有包容性，不是仅仅交给客户和经理，而是由敏捷团队参与识别、诊断、解决问题，绝对不是把问题交给团队以外的人解决。

 

敏捷合同

   敏捷方法提供了很大的灵活性，但是敏捷协作方法提倡共担项目风险和共享项目奖励的关系，实现所有方共赢。设计这种动态特性的合同签署技术包括：多层结构、强调价值交付、总价增量。

敏捷合同允许管理变更需求和优先级，当有一些工作需要外包并且定义合同验收标准时，这种适应性和范围的灵活性就会带来一些问题，所以敏捷也对合同提出了一定适应性的建议。

 

费用变更合同

插入变更费用选项，在新增特性时，也可以重新将特性进行优先级排序，并将优先级最低的特性砍掉，这样就不需要增加费用了。

 

分级固定总价合同

双方分享一些进度偏差相关的风险奖励，如提前、按时、延迟。

 

固定价工作包

为每一个工作包建立固定的价格，即细化工作包，每一个工作包分别计价。

 

供应商管理

   将对于供应商的要求写在请求建议书（RFP）中，做所有决策时，都需要考虑成本、收益。如果供应商在这个项目是微不足道的，那么没有必要浪费精力去给其做敏捷课程的培训。