敏捷开发

Posted 2020-08-30 断了线的风筝～

敏捷开发与瀑布开发的对比

• 瀑布模型开发：

　　严格把软件项目的开发分隔成各个开发阶段：需求分析，设计，编码，测试，维护等，使用里程碑的方式，严格定义了各个开发阶段的输入和输出，如果达不到要求的输出，下一段阶段就不展开。

　　强调文档，在开发的后期才会看到软件的模样，在这种情况下，文档的重要性似乎已经超过了代码的重要性。既然叫瀑布，就意味着不应该走回头路，如果出现返工，付出的代价会很大。

• 敏捷开发：

　　核心是迭代，迭代周期一般为1到4周，因为最终目标是让客户满意，所以能够主动接受需求变更，这就使设计出来的软件具有灵活性，可扩展性。

　　瀑布模型需求确定，时间确定，最后实在完不成任务，可以加人；而敏捷开发时间确定，人员确定，到最后实在不行可以砍掉不是很重要的需求。

Why Agile?

软件开发中的不确定性和复杂程度决定了方法论，软件项目中的两个复杂度:简单项目=熟悉的技术+固定的需求；复杂项目=技术不确定+需求的变更；一句话，如果需求不确定，为了拥抱变化，就选择敏捷吧。

Agile 5 Core Value:openness,courage,respect,focus,commitment.

Scrum 角色

核心的三个角色：

1.Product Owner 产品负责人：

• 帮助团队理解新软件的商业元素（需求）；
• 根据商业价值，把Product Backlog中的功能/产出 划分优先级；
• 推动Backlog Grooming会议；
• 选择发布日期和内容；
• 根据需要调整功能产出和优先级；
• 接收或者拒绝工作结果。

2.Scrum Master-一个公仆型的带头人，帮助团队对自己负责，对象他们的承诺。

• 保证Scrum process被正确地应用并遵守；
• 指导团队，让团队朝字组织的道路上前进；
• 保护团队不受外界干扰，并且去除团队遇到的障碍；
• 帮助提高团队的生产率（Velocity）；
• 促进各方面密切合作，移除障碍；
• 组织会议，并且邀请相关人参加；
• 培训客户，最大化投入产出比，并且满足他们的目标；
• 改善工作环境。

3.Scrum团队

• 团队理想尺寸是5-9人（太少，能完成的工作太少；太多，难以沟通）；
• 团队选择Sprint目标，并且明确工作结果；
• 团队自我组织交付成果，完成承诺的工作；
• 团队向PO和相关人员展示完成的User Stories。

Agile Process

在敏捷转型中最难的部分，其实是团队思维方式的变化，Scrum的核心价值是：

• 时间盒；
• 优先级驱动的增量方式；
• 赋权 和 团队自我管理；
• 应该是公仆/带头促进者而不是命令/控制的管理模式；
• 信任，透明，不用担心失败；

从团队决定敏捷转型的起初6个Sprint，Scrum团队严格实施Scrum的敏捷实践。敏捷评估将由团队自己来衡量团队的敏捷有效性。团队掌握了Scrum的基本要领之后，团队可以尝试新的敏捷挑战：比如结对编程，提高完成的定义，在Sprint中实施有目的性的回归测试，在Sprint中引入自动化测试，测试驱动开发等等。

产品Backlog

Backlog是产品需求的堆叠。所有在backlog中的内容必须定义优先级。每项用户需求不能有相同的优先级。 排列在上面的的项目拥有更高的优先级。当backlog中的一项内容被完成后，它需要被从backlog中移除。在定义需求优先级时需要考虑的因素有: 商业价值；相关知识/不确定性/风险；实际可行性；相关联性。

• 最小化可市场化的功能集合 – 缩小User Story的内容集
• 商业价值优先 – 焦点放在高价值功能上
• 投入产出比优先 – 先做简单的价值高的
• 技术风险大的优先 – 不欠技术债
• 规避风险 – 在后面做困难的Story，或者永远不做。
• 投票 – 向你的用户咨询

切记很多PO只非常宏观地排一下优先级。 (考虑的内容很庞大– 需要花一个月或者更多时间来完成这些内容). 并且一旦他们被分解 – 在这个庞大的话题下的所有内容都被赋予同样的优先级， 这是彻底错误的。不是在大的话题下的所有内容都是和一个发布相关的- 有些Story可能根本不重要，应该完全从发布中剥离。记住：根据价值来定义User Story的优先级。

下面介绍一个需求优先级排序的方法，MoSCoW分区图法。 把你的Story放入4个区域中的一个，并且通过使用图中的数值来定义优先级。

 

• M – MUST 一定要有的功能 – 没有这个功能，产品将不能满足用户要求。 
• S – SHOULD 应该有的功能– 一个重要功能, 通过一个可接受的变通方案.
• C – COULD 可能会有的功能 – 愿景列表内容
• W – WON’T 不能在当下实现的功能– 也许在将来放入’必须’，’应该’或者’可能’ 的功能集合。

如何写一个有效的User Story

 

I	Independent 独立的	User Story 应该是内包含的，也就是说不应该存在另外一个User Story和它有内在的依赖关系。
N	Negotiable 可以商榷的	直到User story被放入一个Sprint之前, 它们都是可以被改变或者被重写的。
V	Valuable 有价值的	一个User Story必须对用户有价值。
E	Estimable 可以预估的	User Story的大小应该是能够被预估的。
S	Sized appropriately or Small 大小正好的或者小的	User Story 不应该太大以至于无法针对它做有意义的计划/拆分任务/定义优先级。
T	Testable 可测试的	User Story或者它的相关描述必须提供测试和开发所需要的必要信息。

梳理产品 Backlog

梳理Backlog的目标是获取专家意见，解决业务人员与技术人员的隔阂，使需求更加清晰, 最终利用整个Scrum团队的智慧与创造力, 创建认同的,共同的责任。

在开始梳理Backlog之前,User Story是已经被排好优先级的。

• 定义或更新影响到的软件架构.
• 分解那些太大的User Story (epics) – 哪些架构需要被模块化,重构或者需要被设计?
• 定义初步的接受条件(acceptance criteria) – 指导Scrum团队理解如何设计, 如何根据既定的设计进行代码编写和测试.
• 初步预估(基于 Story Points) – 一旦架构设计被定义的足以满足团队开始工作的程度, Backlog梳理团队应该提供初步的预估.  

User Story的接受条件

团队必须清楚要产出什么样的交付物，即满足User Story描述的需要的交付物.团队与产品经理之间建立’合同’ – 在工作结束之前不会再有变化! 敏捷是拥抱变化的，但在Sprint开工后到Sprint结束前不要变化需求。接受条件的作用是：

• 定义User Story/功能的界限
• 帮助产品经理回答团队关于新功能的价值相关的问题,(这些基本上都是最小的功能点)
• 帮助团队得到一个对功能需求的认同.
• 帮助开发人员和测试人员设计测试方案.

• 帮助开发人员界定什么时候停止向一个User Story加入更多的功能.

 

接受条件应该是什么样的:

• 描述想要什么而不是一个解决方案. 例如, “用户可以选择一个帐号” 而不应该描述为 “用户可以从下拉列表中选择一个帐号”
• 可度量的
• 可被测试的
• 是一个高层次的描述,而不是具体的需求
• 对于期望结果的描述 > 实现方法
• 逐项都是可被实现的,同样也可以组合起来一起实现
• 期望(特别是针对客户的期望的描述)

什么样的接受条件是不应该的:

• 设计细节
• 实现方法
• 软件系统中的语言
• 规格描述过细以及干扰信息

以上的标准可能并不适用所有的user story. 有时一些实现细节也是必需的. 有时也需要一些软件系统的语言,. 每件事对于你的团队都是特殊的, 不同的项目有不同的特点(甚至Story和Story之间也不尽相同)这并不妨碍好的接受条件的指导思想. 放轻松, 用你最好的判断力去调整至最好.

预估User Stories大小

软件研发是一个错综复杂的过程。从逻辑上讲，尤其对于未知事物，我们是不可能计划的。你越想预估得精确，你预测得就越不准确。Scrum方法论提供 了一个更好的方式： Story Point相对大小预估。使用Fibonacci 数列 (Story Points)  - 1,2,3,5,8,13 和21来估算User Story的大小。这个办法消除了对于我们还没有理解的东西，就得做出“实质的”预估的压力。一个 “努力水平”的积累的比例，需要考虑一下几点：经验，复杂度，规模，风险。不要把它和实际工作小时直接联系在一起。既然Story Point和实际小时数没有联系，这使得Scrum Team对于完成一个Story进行抽象思考需要多少努力变得更加容易。小时预估仅适用于Task的预估。一旦我们到达那个水平，小时数会给我们现实世界的精确度。Story Points 和小时数的结合，给我们提供了在软件中与最困难的事情（预估）做斗争的利剑。 

估算User Stories – 为什么用Story Points?

• 因为通常情况下越大块儿的工作，复杂度越高，引入的风险也越高， 我们把它细化成小的模块级别的部分 （通过这样把不可预估的东西变成小的相对可预估的东西）– 当然，仍然可能有一些其他的一些悬而未决的决定，会对完成这个任务所需要的工作量的级别产生影响。
• 任务越大, 你能够准确预估为了完成它所需要的确切分钟或者小时数的可能性越小。例如：电话打断, 与领导的单独谈话, 推迟的会议, 向上反映问题, 等等……
• Story Points 能够衡量我们无法用小时数衡量的东西 – 例如 将来要做的工作的复杂度，风险，大小和经验。
• 通过 Story Points 来做预估，给你提供了一种方法,让你把你虽然在现阶段不能十分确定的，但是却能凭直觉感觉到的一些不可见的各种因素考虑在内。

进行Story Point预估的考量和方法

 

因素	Development	QA
经验	没有经验13	没有经验 13
复杂度	不复杂 8	非常复杂 21
规模	少的代码改动 5	很多测试用例 21
风险	风险大13	风险大 21
Story Point 预估	8	21
团队最终预估	21

• 复杂度 – 如果有可能, 参考与现在做的user story类似的工作.  比较两者之间的复杂度。从架构角度看，哪一个更加复杂: 模块和子模块? 识别代码相互作用和依赖性。
• 大小 – 先考虑测试 – 需要写多少新的手动测试用例？  现在预测可能需要改变的代码行数。
• 风险 – 代码变化是如何蔓延的; 受影响的模块的缺陷历史是怎样的？
• 经验 – 我们以前做过么？经验是一个很棒的老师 – 一旦能用，就用。但是，如果工作是全新的，因为有不确定性，所以建议提高Story Point。

Sprint计划

Sprint 计划会议

Spring的第一天, 所有团队成员聚集在一起召开Sprint计划会议。Sprint 预计划和Sprint计划是有区别的。Sprint计划会议在Sprint 预计划之后, User Story的接受条件和预估已经由团队完成.  团队的初步的生产力(capacity)已经确定，足以让我们了解需要的人员和工作量 (70-80 %). 团队从最高优先级的User Story开始, 根据团队的速率(Velocity),将相应Story Points的User Story从Product Backlog中移至Sprint Backlog.团队的速率(Velocity) 是4个以上历史Sprint完成Story Point的平均值。Sprint计划会议不需要PO参与，因为这是任务分解的时候，需求澄清工作已经在预计划阶段完成。PO并不做编程和测试的工作，所以任务分解PO也帮不上忙。团队紧密合作, 为每个User Story列出所有已知的任务。我们不是算命先生, 没有人可以准确的预测未来. 参考DoD定义，列出当下已知的工作。每个任务应该可以在一个工作日内完成。如果任务需要12 小时. 在你的团队日平均工作量为8小时的情况下, 那么这个任务应该被分解为2个任务.  只有这样做,才能够基于天为单位来跟踪团队的进度. 进而更快的达到最终的完成.

Sprint预计划会议

在会议之前, Product Owner 把product backlog中的故事定义优先级。同样在会议之前, Product Owner 定义下个sprint的Sprint Goal. 使用team的velocity, 计划下个sprint可以放入哪些User Story

每个user story 应该包括:

• 标准描述(角色, 功能和益处) –  “作为一个<类型的用户> 我需要 <一些功能> 以便得到<益处>”；
• 接受标准；
• 预估– 使用story points method, 预估这项工作需要的工作量
• 生产力 (人员的分配).
• 确定好优先级的product backlog
• 重新审视并且更新(DoD).

速度 Velocity – 在一个Sprint中完成的工作

速度是一个有效的用来衡量长时期内个个Sprint完成工作工作量的指标。速度不是针对于每个sprint所完成工作量的度量。速度是使用团队对Product backlog项目进行预估时的单位来度量的. 通常为StoryPoint.

 

使用Velocity进行发布计划的好处是：

• 容易度量
• 纠正预估的错误
• 容易反映项目的状态
• 做计划的主要参数

上图展示了一个团队的三种平均速度:

• 长期平均值, 指的是最近的8个sprint的平均值。
• 最差情况平均值, 指的是在最近的8个sprint中选出的最差的3个的平均值。
• 最好情况平均值, 指的是在最近的8个sprint中选出的最好的3个的平均值。

每日例会Daily Standup 会议

会议目的是根据Sprint目标, 跟踪每日Sprint进展。要使日例会进行得高效，使会议进程快速而专注。好的stand-up会议是令人感到被互相支持的而且是团队能够自我管理的。一旦声称完成了意味着定义的工作项,流程全部完成了.  

会议模板:

• 我昨天做了什么? – 基于昨天承诺过要做什么, 这是我的进展；
• 今天我将要做什么? – “准备开始”, “尝试当天完成”, “继续进行的”, 这些不是对工作的承诺. 而是类似 ”我今天将会完成xxx任务” 的承诺.  这是你对其他成员的承诺; 而不是对Scrum Master的承诺. 如果一项任务需要很多天来完成, 请将它细化到天.  这将有助于做出以天为单位的承诺,也更容易来跟踪每天的进展；
• 有什么阻碍 – 今天承诺将解决的困难. 
  • 需要什么样的帮助? 
  • 有没有及时在当天与整个团队沟通你遇到的困难?
  • 有没有及时记录你的困难,谁来帮助解决困难,有什么样的计划解决困难?

参考团队的燃尽图,并及时检查Sprint是不是有任何延迟,能否按时交付. Sprint进度评估应该每天都在进行。

完成的定义 Definition of Done

设定团队任务完成的定义的目的是为了量化的衡量交付的软件质量。

• DoD 必须是现实的, 在sprint中可以达成的。
• 保证工作的软件的质量
• Done 就是完成了! 没有妥协的余地.
• 提高DoD用以满足不断变化的产品需求= 对产品的高质量的追求是永无止境的

可借鉴的User Story 的DoD 检查表:

1. 代码完成 (所有要做的内容的编码工作都完成了)
2. 代码注释完备, 提交并且在最近的版本上能够运行。
3. 通过伙伴评审 (或者通过结对编程实现) 并且满足开发标准
4. 编译中没有错误
5. 单元测试被编写，并且测试通过。
6. 部署到系统测试环境中，并且通过系统测试。
7. 通过用户接受性测试，（用户）签署达到了需求。
8. 任何版本/部署/配置变化都是被实施了的/通过文档记录的/沟通过的。
9. 相关的文档/图标都被提供和更新了。
10. 相关任务的剩余时间设置为零，并且任务被完成。
    

进度跟踪

每天:

所有的Scrum团队都需要每天开15分钟的 daily standup 会议, 在Rally中填写任务/责任人/耗时, 在每个sprint结束前，填写defects并且修复S1-2的缺陷, 使用burndown chart （燃尽图）来跟踪任务和问题, 使用burnup chart （燃耗图） 来跟踪已经完成的user stories的情况.  Scrum Master帮助移除前进中的障碍. 

每周:

• 为了在多个团队中共享宏观状态，需要召开一个Scrum of Scrums 会议 (至少每周一次) 。召开频度根据需要而定: 每周一次，或者最多一周三次.
• 通过预计划会议来更新当前发布的计划， 同时计划下个软件发布。
• 每一个Scrum team都要进行预计划会议, 为下一个或者下下个sprint夯实基础。

Sprint状态报告:

Scrum Master 帮助Scrum团队跟踪sprint进度(至少去更新维护燃尽图和燃耗图)。将会有专人负责帮助管理层提供研发进度报告。

Sprint状态关键指标：

• Daily burndown chart – 跟踪打开的和关闭了的问题和任务
• Burnup chart – 跟踪接受了的user stories (为团队, PO 和管理层提供信息)

Scrum of Scrum:

目标: 1. 移除障碍 2. 解决或者移除团队之前的依赖 3. 快速的文档跟进。

细节:

• 你的团队自从我们上次会议以后，做什么了?
• 到下次开会前，你的团队打算做什么?
• 有什么让你的团队效率变低，或者有什么阻挡你们的团队前进么?
• 你是打算把一些事情放在其他团队前进的路上么?

参与者:

发布经理Release Manager, 相关Scrum 团队代表和Scrum Master。

Sprint 审查 - Review

Sprint审查的目的是在Sprint回顾过程中，以Sprint 计划会议中设定的Sprint目标为参考评估项目。理想情况下，团队已经完成了Product Backlog中，引入到本Sprint中的所有项目，但是更重要的是他们已经完成了这个Sprint的整体目标。

Sprint review要保证:

• 保证所有的User Story都完成了 – 以DoD标准来衡量任务是否完成; 以接受标准来衡量User Story是否完成.
• 没有Open状态的S1或者S2缺陷的存在.
• 更新JIRA中的内容– 关闭进行的讨论, 记录最终的burndown和burnup图, 正式结束这个Sprint.

Sprint审查的参与者：

一般包括：PO, Scrum Master和Scrum团队，以及经理，客户和其他项目的工程师。

回顾 Retrospective － 持续改进的关键

• 哪些方面在上个Sprint中我们做的好的，需要在以后的工作中继续 ？在上一个Sprint中，那些好的实践，应该被识别出来，并且在以后的Sprint中保持。
• 哪些在上个Sprint中做得不好的，需要在以后工作中杜绝? 团队或者客户应该识别出，在上个Sprint中，哪些实践是有悖于团队的，并且应该把注意力放在如何在接下来的Sprint中杜绝。
• 我们应该开始做什么?团队识别出可以在下一个Sprint应用, 能够帮助团队更好地协同工作的最佳实践。