敏捷开发

青梅嗅
201 阅读11分钟

敏捷开发

1.瀑布模式

举例：

首先我们有一个项目。在简单了解需求之后，我们制定了项目初步计划，包括预算、人员和进度计划等等；目标是用 10 个月完成项目，包括需求调研、开发、测试、上线以及用户培训。 具体实施 我们花了 1 个月的时间来进行项目的前期筹备，包括组建团队。之后，我们花了 2 个半月 的时间做完了需求调研，又花了 3 个月做开发，开发完成后交给测试，测试花了 2 个月完 成，然后交付给客户来验收。

通俗来说：研发的整个工作流程都是按顺序进行的。项目过程中，先做需求调研，再做开发、测试、验收和上线，所有的工作都是串行的，只有达到下一步的准入标准，我们才进行下一步工作

瀑布模型缺点

  1. 研发周期过长，导致研发跟不上业务发展的节奏
  2. 研发不能很好地响应需求变化，导致客户满意度低
  3. 不能很好地管控风

2.敏捷模式

敏捷价值观

  1. 个体和交互胜过过程和工具
  2. 可以工作的软件胜过面面俱到的文档
  3. 客户合作胜过合同谈判
  4. 响应变化胜过遵循计划
  5. 虽然右项有价值，但我们更重视左项

敏捷的原则

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

敏捷中的“快”其实指的是反馈更快，反馈更及时。

敏捷的方法与实践

在提出敏捷时，建立敏捷联盟的 17 位大师所创立的敏捷方法包括：极限编程、Scrum、特 征驱动开发、动态系统开发方法、自适应软件开发、水晶方法等等，这些方法被统称为敏捷 方法。到现在还有很多关于规模化敏捷的方法，比如说 SaFe 和 Less；也有更多技术实 践，比如说测试驱动开发。可以这么说，凡是符合敏捷价值观和原则的方法论，都可以归到 敏捷的大伞下

这些方法从共性上来说都遵守了敏捷的价值观和原则，不同的是它们针对了不同的应用场景

总结

敏捷 = 价值观 + 原则 + 一系列符合价值观和原则的方法。单纯说敏捷是一种方 法，肯定是片面的；只强调敏捷的价值观和原则而不重视方法也是不对的，因为那样敏捷就 飘在空中，不能落地了

3.敏捷实践

1. 评估诊断

  • 第一步：挑选代表性项目
  • 第二步：访谈评估
  • 第三步：制定转型计划
  • 第四步：沟通

2.敏捷试点

1.试点前准备

  1. 选择试点团队
  2. 前期准备工作细则 组织和人员，管控治理规则，需求范围，架构，敏捷方法和工具，办公环境设施

2.试点推进过程

  1. 一起制订社会契约
  2. 回顾会议，引导团队的自主性
  3. 成绩墙与错题集，记录团队敏捷的成长

3.试点推广

  1. 推广主流SaFe（Scaled AgileFramework）和 LeSS（Large Scale Scrum）框架

  2. 形成自己推广方案

    • 选择合适的规模化推广策略
    • 做好敏捷文化铺垫，培养好敏捷的中坚力量
    • 搭建适合敏捷的工作环境，做好必要的工具和自动化准备
    • 组织级别的敏捷度量以及持续改进
    • 重视大型团队的敏捷导入与推广

  3. 痛点解决

    • 研发中各个环节的效率有待提升，各个角色的等待时间过长； 解决：采用Scrum
    • 敏捷走到业务那里就卡壳，业务人员参与度低； 解决：1.定制度，2.反馈机制
    • 跨团队沟通不畅，协作效率低。 解决：建立沟通机制，对齐团队目标

4.常见敏捷“填坑”指南

  1. 团队说他们不想做敏捷 深究原因：忙？没时间还是其他原因
  2. 把敏捷当作一种新的流程，而忘记敏捷的核心是持续改进
  3. Scrum 过程被严重缩减，只剩下每日站会
  4. 坑四：筒仓中的敏捷 深层次地挖掘

第一，推进敏捷时要通盘考虑整个链条应该怎么推进。组织全功能团队，除了一个一个的研 发敏捷小团队以外，还要考虑需求管理怎么推进，并想好推进策略。 第二，敏捷可以分步推进，但是推进过程中一旦识别出新的阻碍，应及时去除。像在本案例 中，我相信当产品团队没有跟随一起推进敏捷实践时，整个敏捷流程很快就会有新的问题浮 现出来，例如每个迭代前，需求条目都准备不好，在这种情况下，这个障碍就应该及时去 除。

5.如何避免敏捷变为“小瀑布”

敏捷并不是将大需求切割成小需求，按照“需求 - 设计 - 开发 - 测试”流程来做，而是在拆分小需求之后，可以并行工作，测试完成之后，不用等待其他小需求结束，可以独立上线。如何合理拆分需求很重要

我们工作的结束点不应该是把之前所有计划的工作做完，而是把客户需要的工作做完

4.培养敏捷教练

教授（Teaching） 引导（Facilitation） 辅导（Mentoring） 教练（Coaching）

graph LR

A(基础培训)  --> B(安排实战工作坊) --> c(线上活动加力) --> d(一对一的教练服务)

辅导过程

  1. 签署教练协议
  2. 进行评估
  3. 一对一的教练服务
  4. 成果展示

5.服务型领导者

  • 给员工建立心理安全机制
    1. 信任是必不可少的。要支持员工和他们的决定，在工作和工作之外都照顾好团队成员；
  1. 培养健康的分歧环境。允许分歧存在，在有分歧时虚心听取不同的意见；
  2. 建立正确的失败文化。失败是可以接受的，只要从失败中吸取教训，能够改进就好。
  • 掌握情境领导能力

领导者能在不同的情境下运用不同的领导力来指导和支持团队成员完成目标或任务。

各种不同情景

  1. 能力低、承诺高 --> 热情的初学者
  2. 能力不是很高，承诺很低 -->幻灭的学习者
  3. 能力处于中上等、承诺很低 -->有能力但谨慎的贡献者
  4. 能力高、承诺高 -->自力更生的成功者

对应指导性，支持性行为

  1. 指导。高指导行为和低支持行为
  2. 教练。高指导行为和高支持行为
  3. 支持。低指导行为和高支持行为
  4. 授权。低指导行为和低支持行为

用好情境领导力

  1. 设定目标
  2. 协同诊断
  3. 学会匹配

附录：scrum（迭代的增量化过程）

1、SCRUM理论基础

Scrum以经验性过程控制理论（经验主义）做为理论基础的过程。经验主义主张知识源于经验, 以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。

Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应。Scrum的三大支柱如下：

第一：透明性（Transparency）

透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。

第二：检验（Inspection）

开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。

第三：适应（Adaptation）

如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。

Scrum中通过三个活动进行检验和适应：每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。

2、SCRUM框架

Scrum框架包括3个角色、3个工件、5个事件、5个价值：

3个角色

产品负责人（Product Owner）： Scrum Master 开发团队 3个工件

产品Backlog（Product Backlog） SprintBacklog 产品增量（Increment） 什么是产品Backlog? 什么是Sprint Backlog?

产品Backlog 指根据初始需求分解出的任务列表，包括功能性的和非功能性的所有功能，由Product Owner 为Product Backlog 中的任务确定优先级别，当开发团队开始某个任务的时候，再精确定义和分解这个任务。 产品Backlog 是产品所要具备的所有功能的总纲。当一个项目刚刚开始时，没人能够事先预见到所有的任务和需求，并为之制定一个充分、详细而又包罗万象的计划。可行的方式是，先为一个项目写下所有它应该具备的显著特征和功能，数量不必很多，最好够让团队的第1 个Sprint 有活可干。 随着Sprint 的进行，生产出可发布的产品增量，客户对产品的直观认识也会随之深，他们可以据此建议更改或者添加产品Backlog 中的任务。在Sprint 计划会议上，产品负责人为产品Backlog 中的任务确定优先级，并向Scrum团队描述这些任务。Scrum 团队随后根据团队整体情况，确定他们能在这个即将到来的Sprint 中要完成哪些功能，并把它们挪到Sprint Backlog 中去。

5个事件

Sprint（Sprint本身是一个事件，包括了如下4个事件） Sprint计划会议（Sprint Planning Meeting） 每日站会（Daily Scrum Meeting） Sprint评审会议（Sprint Review Meeting） Sprint回顾会议（Sprint Retrospective Meeting） 5个价值

承诺 – 愿意对目标做出承诺 专注 – 把你的心思和能力都用到你承诺的工作上去 开放 – Scrum 把项目中的一切开放给每个人看 尊重 – 每个人都有他独特的背景和经验 勇气 – 有勇气做出承诺，履行承诺，接受别人的尊重

avatar
文章
阅读
粉丝