敏捷开发

Posted 2020-11-01

背景

过去我们用合同死死地固定住需求，然后乙方千方百计的只按照合同办事，没有发挥更大的创造力，而甲方在固定的成本面前，不想多花一分钱，却不停的要求新功能。那么甲乙双方就形成了矛盾的局面，甚至是敌对的局面。如何破除这种局面呢？这就是本期要讲的敏捷开发。

敏捷的起源

硬件领域有摩尔定律，即每隔18~24个月，每1$能买到的电脑性能将翻翻一倍以上。而软件行业却没有相应的规律。那么软件行业如果提高生产率、质量、价值等。而目前软件公司是如何提高生产率、质量呢？实际上很多传统的企业仍然靠加班、流程和工具、合同和文档的约束，而且沟通困难是导致bug、延期的重要原因，这里的沟通包括开发团队和甲方的沟通，团队之间的沟通，团队和管理者的沟通等等；在瀑布式开发模式中，我们会做大量的前期需求分析和详细设计，我们自认为我们这些努力会保证交付的软件会是客户期望的，但是事实并不是如此。另外，所有的软件开发者都是知识工作者，那么知识工作者的主管能动性和创造力是管理人员管控出来的吗？

上述这些软件行业中的痛点，并不是新生的，早在1987年Fred brooks就在《没有银弹》中提到没有任何一项技术或方法可以能让软件工程的生产率在十年内提高十倍。软件开发本身具有复杂性、不可见性、可变性以及一致性，使得软件开发难以管理，所以将它比喻成" 狼人"，但是没有一项技术或方法来解决它，即没有银弹。

而敏捷开发正是解决软件开发冲存在的问题的。

瀑布模型

在具体介绍敏捷开发之前，先介绍"不敏捷"的开发模式，即"瀑布模型"，这套方法论分为5个阶段：需求分析、设计、编码、测试和维护。需求分析阶段通常定义系统需求；设计阶段通常确定系统使用什么数据库，系统模块的划分，各个模块的功能；编码阶段用编程语言实现设计阶段的功能；测试阶段主要测试功能是否实现；维护阶段是根据用户新的需求重新修改系统，使系统运行正常，更加稳定。

瀑布模型的局限性非常明显，比如对市场变化和用户需求的响应比较慢，更改成本高，甚至可能出现产品一退出市场就宣告失败。

敏捷开发

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：

• 个体和互动 高于 流程和工具
• 工作的软件 高于 详尽的文档
• 客户合作 高于 合作谈判
• 响应变化 高于 遵循计划

敏捷开发宣言

1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意
2. 欣然面对需求变化，即使在开发后期也一样，为了客户的竞争优势，敏捷过程掌控变化
3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外
5. 激发个体的斗志，以他们为核心搭建项目，提供所需的环境和支援，辅以信任，从而达成目标
6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面交谈
7. 可工作的软件是进度的首要度量标准
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够同步维持其步调稳定延续
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强
10. 以简洁为本，它是极力减少不必要工作量的艺术
11. 最好的架构、需求和设计出自组织团队
12. 团队定期地反思如何能提高成效，并以此调整自身的举止表现

敏捷开发的原则

1. 凝聚人的力量，紧密协（合）作。包括业务负责人、开发团队、客户、管理者之间的关系，所有这些关系在以前都是造成项目危机的原因之一，那么，在敏捷时代，我们需要这些角色 紧密合作，最大限度的发挥各个角色的力量
2. 聚焦客户价值，消除浪费（如何聚焦用户价值，即频繁的交付用户可工作的软件，快速收到用户反馈）
3. 除了有人和有价值，我们还需要持续地学习与改进，因为这个世界变化的太快了。

敏捷团队

敏捷开发的价值观和原则看起来很美，但是如何落地呢？首先它需要组建一个敏捷团队。相交于传统团队，敏捷团队具有以下特点：

• 团队要求团队小，通常是个位数的人数（3-9人）
• 全职专注，必须是全职人员
• 跨职能
• 被授权自组织

敏捷团队运作机制

1. 一个团队有自己的×××事项，对×××事项进行拆小
2. 按客户价值进行优先级排序，产品经理负责价值排序
3. 团队成员的工作不是被主管推动的，而是自己拉动工作
4. 小而稳定，跨职能团队
5. 多个团队松耦合（依赖性比较低），对齐迭代时间和战略目标

关键的团队角色

• 产品负责人
• Scrum主管（流程主管）?
• 开发团队

产品负责人（Product Owner）

• 负责管理产品backlog（×××事项）的唯一负责人
• 代表客户/项目如责任人
• 定义产品的所有特性
• 负责产品的投入产出
• 管理干系人和他们的利益
• 接受或者拒绝迭代的结果
• 维护正好够的，准时生产（Just -in-Time）的特性细节
• 跟团队共享成功
• 负责最大化产品和开发团队工作的价值

Scrum Master（流程主管）

• 起到教练的职责
• 领导团队完成Scrum的实践以及体现其价值
• 排除团队遇到的困难
• 使得团队紧密合作，使得团队个人具有多方面职能的工作能力
• 确保团队能胜任其工作，并保持高效的生产率
• 保护团队不受到外来无端影响

  开发团队

• 团队拥有3-9人
• 团队成员跨职能，多面手
• 团队成员都全职工作
• 团队自我组织和管理
• 团队关系在一个迭代周期中应该是固定的，个人的职能可以在新迭×××始时发生调整

关键的团队活动

• 每日站会
  每日站会每天都会召开，时间维持在15分钟内，站着开会，所有相关人员都需要参加，避免无关问题的讨论。

• 评审会
  需要在迭代周期的最后一天召开，1个小时左右就可以了，需要客户出席，如果客户不能出席，则需要产品经理出席
• 迭代回顾会
  迭代回顾会是在每个迭代结束时进行，总结工作中的经验和教训，时间维持在30-60分钟内，整个团队都需要参加（Scrum Master、Product Owner、开发团队以及客户）。迭代回顾会包括两部分，第一部分是定量分析，第二部分是定性分析。其中定量分析又包含团队是否完成了迭代目标，收集并评审迭代度量指标（包括速率、迭代燃尽图、迭代计划故事和实际完成故事、计划发布日期与实际发布日期、客户满意度、团队满意度、生产环境Bug数、生产Bug解决时间、用户故事等）。定性分析包含哪些工作良好（应该继续保持），哪些做的不好（应该停止）？哪些可以改进（团队选出１－２条在下一个迭代实现）？

最常用的敏捷方法和实践

• Scrum
• XP

---

欢迎关注微信公众号：木可大大，所有文章都将同步在公众号上。