浅谈敏捷开发

Posted 2021-04-25 冰岩作坊

浅谈敏捷开发

0. 开场

1. 瀑布模型

在讲敏捷开发前，我们先讲讲瀑布模型。

瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

对传统的瀑布模型加入迭代

有任何一阶段出现错误都需要回溯至该阶段修复问题

每一阶段都有严格的审批保证该阶段完成的质量，新手也可以被写出高质量的代码。

迭代过程中将会产生大量的文档（代码没写几行，怎么都在写文档？）、开发结果较晚才能知晓（拜拜佛希望结果通过验收），加大开发风险、难以适应需求变化（需求怎么又变了？）

瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃。有没有更好的方式呢？

2. 敏捷宣言

2001年2月11日至13日，在美国犹他州瓦萨奇山雪鸟滑雪胜地，17个人聚到一起，交谈、滑雪、休闲，聚餐。他们试图找到共识，最终的成果就是《敏捷软件开发宣言》（Manifesto for Agile Software Development）。

https://agilemanifesto.org/iso/zhchs/manifesto.html

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

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

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

敏捷开发的精髓是响应变化，不去控制变化，而以往的项目管理是要控制变化，以实现整个开发周期是可控的。敏捷开发产生以前，由于软件开发和传统行业天然的有着鸿沟，几乎用尽了以往所有的经验办法，都没法做到详实的很精确的控制。有人便提出了，既然不能控制变化，何不去响应这种变化，敏捷宣言也由此产生。

3. 敏捷原则

价值排序，尽早交付

敏捷原则第1条：我们第一优先的任务是，通过尽早且持续交付有价值的软件（系统）来满足客户（Our highest priority is to satisfy the customer through early and continuous delivery of valuable software）。

拥抱变化，提高优势

敏捷原则第2条：即使在最后开发阶段，也要竭诚欢迎改变需求，敏捷过程掌控变更，以维护客户的竞争优势（Welcome changing requirement , even late in development . Agile processes harness change for the customer’s competitive advantage）。

持续交付，小步快跑

敏捷原则第3条：经常交付可用的软件（系统），频率可以从数周到数月，以较短的时间间隔为佳（Deliver working software frequently , from a couple of weeks to a couple of months , with a preference to the shorter timescale）。

成果达成，衡量进度

敏捷原则第7条：可用的软件（系统）是进度的主要测量标准（Working software is the primary measure of progress）。

追求卓越，强化敏捷

敏捷原则第9条：持续专注于追求卓越的技术与优良的设计以强化敏捷力（Continuous attention to technical excellence and good design enhances agility）。

精简产品，杜绝浪费

敏捷原则第10条：精简——精髓是要尽最大的可能，排除不需要做的工作（Simplicity-the art of maximizing the amount of work not done-is essential）。

团队合作，每日互动

敏捷原则第4条：业务人员与开发者在项目进行中，必须每天一起工作（Business people and developers must work together daily throughout the project）。

信任成员，给予支援

敏捷原则第5条：项目靠积极的个人来完成，给予他们所需的环境与支持，并相信他们可以完成工作（Build projects around motivated individuals . Give them the environment and support they need , and trust them to get the job done）。

当面沟通，高效明了

敏捷原则第6条：在开发团队与团队成员之间，面对面的沟通是传播信息最有效率与效能的方式（The most efficient and effective method of conveying information to and within a development team is face-to-face conversation）。

各方成员，稳定节奏

敏捷原则第8条：敏捷过程提倡稳定持续的开发，发起人、开发者及用户都应该能不断地维持稳定的步调（Agile processes promote sustainable development .The sponsors , developers , and users should be able to maintain a constant pace indefinitely）。

同心协力，自我组织

敏捷原则第11条：最佳的架构、需求及设计皆来自于能自我组织的团队（The best architectures , requirement , and designs emerge from self-organizing teams）。

团队自省，持续改进

敏捷原则第12条：团队定期自省应如何更有效率，并据以调整与修正行为（At regular intervals , the team reflects on how to become more effective , then tunes and adjusts its behavior accordingly）。

敏捷开发实际上只是个概念，而怎么落实这个概念呢，怎么转变成敏捷团队呢，就需要运用敏捷的各种方法论和实践。敏捷的方法论有很多，例如，源于丰田公司的精益软件开发，新兴测试方式-探索性测试，测试驱动开发等，而敏捷有一个很重要的一个方法流派就是Scrum。

4. Scrum

Scrum是敏捷开发的一种流派，是一种以人为本，迭代式增量软件开发的过程，以英式橄榄球争球队形（Scrum）为名，Scrum开发强调沟通，要求团队所有人员坐着一起工作，通过高效的沟通解决问题。

开发流程

角色：PO (Product Owner 产品经理)

SM (Scrum Master 敏捷教练)

Team (开发团队)

PO：保证团队做正确的事情，负责需求分析和整理、分解验收story、对需求进行优先级排序、维护Product backlog等

SM：保证团队正确地做事，他要负责主持会议、协助团队内部成员解决困难、解决外部对团队内部的过分干扰、和外界的主要沟通工作等。

Team：整个开发和测试团队

四个会议：Sprint Planning、Daily Scrum Planning、Sprint Review、Sprint Retrospective

• Sprint Planning：迭代计划会议，这个会议上，需要得出以下结论：

• 全员明确清晰的迭代目标
• 澄清所有的需求及技术实现风险
• 以相对估计法评估需要的工作量，以及需要投入的人员
• 确定出所有最终需要发布的功能集合及工作量

• Daily Scrum Planning：每日站会，站着开会，大家围成一个圈或者半圈。站会的目的有以下3个：

  站会的时间，不超过15分钟，只描述状态和任务，不讨论技术细节，另外，每个人围绕以下3个话题来简单描述自己的进展：

• 昨天完成了什么？
• 目前有什么困难，需要帮助的？
• 今天准备做什么？
• 确认个人是否完成昨日的目标
• 培养团队文化
• 了解项目进展：团队中每个人都应该了解其他人在做的事情，以及当前团队的进展和风险。最实际的好处就是这样可以清楚的知道别人做的事情是否对自己有影响，或者自己是否可以提供帮助等。

• Sprint Review：迭代评审会议，此次会议的主要内容是相关利益者及团队成员展现本次迭代的功能增量，需要注意的是不展示未完成的功能。

• 可以让团队的成果得到认可，提升团队的自我价值感
• 其他人可以了解团队在做的事情
• 可以吸引一些利益相关者的注意，并得到一些反馈
• 演示能够对团队成员造成的一定的压力，迫使团队认真完成工作

• Sprint Retrospective：迭代回顾会议，会议主要是回顾此次迭代的整体情况，一定要全员参加，一起回顾此次迭代做的好的地方，以及需要改进的地方，并对这些需要改进的点，提出改进措施。

User Story：即用户故事，是一个解决用户某个问题的，对用户有价值的，某个功能的，一目了然的描述。这里有一个理念需要注意，即多个小故事胜过一个庞大的故事，因此User Story的描述非常重要，好的用户故事具备INVEST原则：

Independent：可以独立开发

Negotiable：可以协商

Valuable：有价值

Estimable：大小可评估

Sized appropriately：合适粒度

Testable：可测试验证的

三个要素：角色，功能，价值。即作为xx角色为了xxxx需要xxxx。

例子：作为一个老板，为了更好地利用我的时间增加财富，我需要有一个能记录小目标的笔记本。

白板

白板反映了开发的进程。

白板上要将Task以便贴的形式按照状态贴在三个区域：需要做、正在做、完成。

同时要在白板上画出燃尽图，燃尽图指示的是当前剩余的工作量。

End

推荐阅读

注：部分图片来自互联网