敏捷管理（4）- 常见的敏捷问题、其他敏捷方法论

常见的问题敏捷是如何解决的？

敏捷痛点及解决方式

问题	解决方式
团队目标或任务不明确	敏捷章程愿景、使命和使命测试
团队工作协议不明确	敏捷章程价值观、原则、工作协议
团队环境不明确	敏捷章程边界、承诺和前瞻性
需求不明确	用户故事地图和影响地图来构建产品路线图
用户体验不佳	设计阶段就让客户尽早参与
估算不准确	分解故事让故事变小
工作分配或工作进展不明确	自我管理工作、每日站会、看板查看进展
团队面临障碍	仆人式领导，如还是无法消除则聘请教练或上报故事
产品待办事项列表不够完善，导致延误或超时	PO和团队一起研讨故事，考虑分拆故事以使用更小的故事
缺陷或BUG	结对工作、产品集体负责制、普适测试
工作未完成	确定故事完成的定义，包括验收标准、发布标准在内
技术债务（代码质量降级）	重构、敏捷建模、普适测试、自动化代码质量分析、完成的定义

 

产品复杂性过高及解决方式

问题	解决方式
团队合作过程进展缓慢或没有改善	每次回顾中，改进项目不要超过三个，仆人式领导帮助团队学习怎样去整合这些待改进项
前期工作过多导致返工	刺探学习、并不需要设计，只需要交付价值。缩短迭代，并创建一个稳健的完成的定义
错误的开始，前功尽弃	让PO成为团队不可分割的一份子
产品代办事项列表杂乱无序	按价值排序
仓促或等待，不均匀的工作流程	不是超出能力所及，并且成员不能多任务，必须要专注
相关方要求无法满足	仆人式领导与这个相关方一起工作
意想不到或不可预见的延误	更频繁的检查，使用看板面板检查工作流，了解需求对团队或产品的影响
孤立的团队，而不是跨职能团队	项目人员作为跨职能团队自我组织

 

扩展-其他主流的敏捷方法论

特性驱动开发（FDD）

   为产品开发一个整体的模型，构建特性列表和工作计划；团队对开发的特性进行设计和构建。

FDD实践

   领域对象建模：描述问题领域中重要对象的类型及其相互关系，为系统设计提供一个整体框架，其中包括构造类图等。这个在数据仓库设计的应用较多。

   按照特性开发：将需求问题分解成可以解决的小问题。

   类（代码）所有权：指定某个人负责某个类的代码一致性、性能和概念的完整性。

   特性小组：组长更像是教练去做协调，而不是超级开发人员。

   配置管理：设计、测试用例、脚本等等也应该受到版本控制。

   定期构建：更容易的创建演示程序。

   可视化的进度报告：如白板。

FDD小结

   特性驱动开发（FDD）就是将需求化成小问题。

   FDD实践：领域对象剑魔、按照特性开发、特性小组、配置管理、定期构建、可视化的进度报告。

 

 

动态系统开发方法（DSDM）

   也称为业务中心框架开发方法，是敏捷方法的一种。倡导以业务为核心，快速而有效的进行系统开发。重点在于快速交付并补充如何应用这些控制的指导原则框架。

DSDM提倡20%的时间完成80%的功能，已经在数据仓库、组件开发、原型业务等应用。

 

DSDM开发周期

   项目准备阶段：确保启动、建立正确的项目，可行性研究阶段和业务阶段都是顺序进行的，为后续的冲刺、增量式开发，制定了基本规则。

   可行性研究阶段：侧重评估DSDM方法是否适用于本项目，以便确定这样做是否值得；在制定一份全面的可行性报告，还需要提供应对和控制风险的策略，如果对业务叨叨足够的理解了就可以了，即足够就好，无需过多。

   业务研究阶段：对业务流程进行分析和定义。功能性需求还是非功能需求分类，并且划分对应的优先级。所有制定优先级的原则也必须要以业务为导向，把技术上要求先实现的功能作为高优先级。这个开发计划应该包含功能建模阶段和设计编程阶段的开发策略、测试策略和配置管理计划。

   功能建模阶段（冲刺式）：深入分析业务区定义的功能并进行细化，在分析原型的基础上构建软件模块，将创建的原型交付给用户评审；评审后，进一步的充实和改进。这样不断的冲刺，使得原型逐渐演化成可工作的软件。产出物带有优先级的功能、功能性原型评审文档、非功能性需求、实施计划（业务方案、培训计划、各种知识和技术的准备等）。

   系统设计编程阶段（冲刺式）：根据功能建模的标准建造实际的系统并通过测试，测试应该是贯穿于整个功能建模和设计编码过程的。

   实施阶段：培训用户，完成系统开发环境向生产环境的移交。

   项目后期：评审当前使用的方法并评估是否达到预期的结果。

 

DSDM小结

   提倡20%的时间，完成80%的功能。

   开发周期：项目准备阶段、可行性研究阶段、业务研究阶段、功能建模阶段（冲刺式）、系统设计编程阶段（冲刺式）、实施阶段、项目后期。

 

水晶（Crystal）

   水晶方法体系与XP一样，都是以人为中心的理念，但实践上有所不同。水晶方法考虑到人们一般很难遵循一个纪律约束性很强的过程。因此，与XP的高度纪律性不同，水晶方法体系探索了用最少的纪律约束而仍能产出成果的方法，从而在产出效率上与易于运作上达到纪律约束而仍能产出成本的方法，从而在产出效率与易于运作上达到一种平衡。虽然水晶系列不如XP那样产出效率，但是会有更多人接受。

 

Crystal开发方法

   透明水晶（Crystal Clear）、黄水晶（Crystal Yellow）、橙水晶（Crystal Orange）、红水晶（Crystal Red）分别适用于不同的项目。

 

Crystal重要性

   根据项目的错误引发后果分为：

   不舒适（C-Loss Of Comfort）；

   经济损失（D-Loss Of Discretionary Money）；

   严重经济损失（E-Loss Of Essetial Money）；

   生命危险（L-Life Critical）；

 

水晶与敏捷相同的原则

   频繁交付：增量构建、检查验收。

   反思改进：及时反思和改进。

   渗透式沟通：同一空间。

   个人安全：不会受到惩罚。

   焦点：确定首先要做什么，然后按照时间，以平和的心态去开展工作。

   与专家用户建立方便的联系：例如质量快速反馈、设计理念快速反馈。

   配有自动测试：允许人们不同步的对工作进行检查、可撤销更改、还原系统设置等。

 

Crystal小结

   开发方法：透明水晶（Crystal Clear）、黄水晶（Crystal Yellow）、橙水晶（Crystal Orange）、红水晶（Crystal Red）

   重要性：不舒适（C-Loss Of Comfort）；经济损失（D-Loss Of Discretionary Money）；  严重经济损失（E-Loss Of Essetial Money）； 生命危险（L-Life Critical）；

   与敏捷相同原则：频繁交付、反思改进、渗透式沟通、个人安全、焦点、自动化测试等。

 

精益开发

   敏捷和精益的价值观是紧密相关的。精益的一系列原则是从精益生产中来的。精益带给开发人员一些技术和概念，如价值流向图、浪费的7种形式、拉动系统及在制品。

 

精益核心概念

   消除浪费：要最大化价值，必须最小化浪费。

   构建质量：不会试图在结束的时候测试质量。相反，开发人员在整个开发过程中会构建产品质量和持续的确保质量，通常使用的技术有重构、持续集成和单元测试。

   创建知识：尽早和频繁的使用沟通技术，尽可能快的得到反馈。尽可能持续的保持学习状态。

   推迟决策：决策太早使你不能获得足够的信息；决策的太晚会使你承担更高的成本风险。所以开发人员要在两者之间找到平衡。

   快速交付：快速交付软件已最大化软件的价值（ROI）在快速的冲刺过程中，也可以找到更好的解决方案。

   对人尊重：尊重管理层和员工，开发过程中允许他们具有灵活性，并持续的改进过程，以期吸引和留住高素质员工。

   整体优化：尝试优化时，应该试图包含尽可能多的价值流。局部的优化若不能带来整体的改善是没有价值的。

 

精益小结

   精益是日本丰田实践而来的，敏捷是学习了精益的部分思想。

   核心概念：消除浪费：构建质量、创建知识、推迟决策、快速交付、对人尊重、整体优化。

 

看板开发

   近年来最热门的敏捷和精益开发方法之一，能够改善协作、优化管理、显著的提高交付速度、质量和灵活性。规则简单，其有效实施依赖于对原理的理解、对高质量的坚持和实践的应变。

   限制了在制品（WIP）的数量，这样可以帮助识别在开发过程中产生的问题和最小化浪费，以及与成本相关的变更，并使用一个拉动系统工作。

 

核心实践

   可视化工作（价值）流：产品开发的加工对象信息是抽象和不可见的。看板开发方法把可视化工作流作为基础实践，先让价值和价值流动具体可见，然后才是管理和优化。

   限制在制品（WIP）数量：即每个冲刺所要完成的工作是有限制的。

   度量和管理流动：快速，顺畅的价值流动是看板开发方法的目标。快速流动带来快速的价值产出和快速反馈。顺畅流动意味着稳定和可预测的价值交付能力。度量为改善价值流动提供方向参考，同时为改善的结果提供反馈。

   协同改进：发现问题还不够，重要的是如何去解决这些问题。

   显式化流程规则：明确定义和沟通团队所遵循的流程规则。定义了一个价值项从一个阶段进入下一个阶段所必须达到的标准。定了从分析阶段进入开发阶段所必须达到的条件。这与精益制造中内建质量的思想是一致的。

 

小结

   核心实践：可视化工作（价值）流、限制在制品（WIP）数量、度量和管理流动、协同改进、显式化流程规则。

 

Scrum Of Scrums

是大规模敏捷框架，采用经济视角、应用系统思维、为可能性预留方案、快速整合学习周期进行增量式构建、客观评估设定里程碑、解锁成员内在动力、决策分散。

 

大规模敏捷开发（LeSS）

是以扩展Scrum方法为共同目标来组织多个开发团队的框架。系统思维、整体产品专注、透明等。

 

总结

敏捷永恒不变的真理：检查、适应和透明度是成功交付价值的关键因素。没有适应检查只是浪费精力。

有价值的软件使得客户满足、欢迎变更、经常交付可用的软件、协力协作、激励项目人员、面对面的交谈、可用的软件是衡量进度的标准、可持续的开发、不断完善、简洁、定期反省。

最佳架构、需求和设计将出自于自组织团队

规范敏捷（DA）：以人为先、面向学习、完全交付生命周期、目标驱动、企业意识、可扩展。

评估变更的理想方式是首先尝试一个或两个迭代，然后通过回顾和重新评估来反思。

透明是需要勇气的，可以通过使用状态板或白板。

不要盲目的使用敏捷方法，授权经验不足的自组织团队解决一切问题。

缺乏管理层支持时，要找到共同点和改进之处。

较小的不太关键的项目应采用简单的方法并实施较弱的控制。大型任务或生命关键型项目建议使用更高的严格程度和验证级别。

适应性评估模型：（越靠近中心点越敏捷，预测型、混合型、敏捷型）

文化：支持、信任度、决策能力

团队：规模、经验水平、客户或业务联系程度

项目：变更可能性、产品或服务关键性、增量交付

 

我为什么要学习敏捷？敏捷究竟对我有什么好处？

   在国内职场有一句话很经典，要想涨工资，请选择跳槽。这背后说明了，国内公司还处于一个矮子里挑高个。敏捷不提倡加班，在国内的公司99.99%都出现敏捷是一种新的压榨方式。但是国内每一个公司都知道国外的公司都在使用敏捷，如果自己还不使用的话，可能会给市场淘汰了。虽然在使用的敏捷都是假敏捷，但是还是想要以此来充实自己的公司，也以便更好的在资本市场上讲故事，这就如同17年的人工智能、大数据那般，可惜现在大家对人工智能、大数据这类东西摸透了，也看透了，以及国内真正做的起大数据的公司就头部那几家，其他公司大多数都是在使用大数据技术应用层面，仅仅用来存储数据，这也是为什么现在大数据公司在资本市场上不在像17年那般受到疯狂的追棒。

   现在的敏捷时代，这个情况有点类似17年的人工智能、大数据那般。如果作为管理人员的你掌握了敏捷，你应用过敏捷，能够吹一吹，你会发现Off拿到的可能性更高了，可谈的薪资更高了。

   另外敏捷是一种思想，也是一种方法论，对于个人在做事方面，未来国内企业环境不再是以加班，而是更人性化的方式时，你的价值就更大了。

   要想涨工资，请选择跳槽。

   要想涨更多，请学习敏捷。