拖了那么久，感觉不能再拖了。正好最近2018年Q1季度结束，对Q1季度的敏捷开发实践做了系统性的回顾，总结了一下经验教训，那就接着上次提到的，这次来介绍一下敏捷开发的基本概念吧。
毕竟Jira只是敏捷开发的管理工具，想要正确的使用，需要具备基础的理论知识。
瀑布流模型
开始介绍敏捷开发之前，先介绍一下敏捷开发方式提出之前的开发方式：瀑布流模型。
瀑布流模型将软件开发和交付划分为几个相互独立的阶段：
- 需求收集
- 设计
- 编码
- 测试
其中每一步都需要等前一步完成之后才能进行，必须从上向下，也因此得名“瀑布”。瀑布流模型的理念有点“人定胜天”的意思，意图在开发之前就确定好一切细节——有经验的开发者都知道这是不可能的。在传统行业如建筑业中，受限于交付物的体量以及改动成本，而不得不采用瀑布方式，毕竟房子盖好了只能简单改改格局，其他想改只能推到重建。而对于软件开发特别是互联网软件开发来说，对已经交付的软件进行改动简直不能再简单了。
敏捷开发
2001年，十几位很厉害的开发者们聚在一起，经过一翻交流之后，发起了敏捷运动，还撰写了一份宣言——《敏捷宣言》。现在这份敏捷宣言还托管在GitHub Pages上，有兴趣的可以去http://agilemanifesto.org看一看：
图中靠下的位置就是当时的十几位开发者。搜一下会发现他们各自写了很多软件开发领域的教科书级书目。
敏捷宣言的主要内容，翻译一下是：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划也就是说，尽管右项有其价值，
我们更重视左项的价值。
敏捷开发也存在需求、设计、编码、测试4种职能，不过敏捷开发并不是小型瀑布流，4种职能之间是紧密结合、彼此交融、相互依赖的，不存在瀑布流的“职能筒仓”问题。文档、开发、测试往往是同步进行的。基于敏捷开发的理念，衍生出来精益开发、极限编程、测试驱动开发（TDD）等等具体方法，而Jira所支持的Scrum就是其中的方法之一。
Scrum在英语是橄榄球运动中列阵争球的意思。就我看过为数不多的球赛里面，2012年欧洲杯决赛西班牙队4：0血虐意大利队的战术，也有不少scrum的意思，小步快传，全队皆锋。
Scrum角色
在Scrum团队中有3种角色：
1、产品负责人Product Owner，定义需求列表及优先级、验收标准，代表业务需求方，也就是我们常说的产品经理。不过产品经理往往身兼更多职责如项目管理、交互设计、用户调研等。
2、敏捷教练Scrum Master，保证团队按Scrum的方式良好运转下去，在没有专职人员的情况下，一般由研发经理担任比较合适。如果由产品经理负责，需要对软件开发技术有一定的了解，并且能够清晰剥离出自己Product Owner与Scrum Master的职责，在正确的时机做正确的事，因为这两个角色之间的关系基本是相互对抗的。
3、团队成员Team Member，真正做编码和测试的人员，对故事和任务工作量做估算，并交付最终可用的产品。
Sprint周期
Sprint（冲刺）周期是执行Scrum的基本节奏。每一个Sprint周期都是一个固定的时间盒。在这个时间盒内，要做的故事和任务（也就是产品需求）是确定的。当周期结束时，不管需求有没有全部完成，这个时间盒都会结束，并准备启动下一个时间盒。如此循环，通过快节奏的迭代冲刺，不断交付有价值的产品并且不断修正产品。
在一个Sprint周期中，有几个主要会议：
1、Sprint规划会议，在会上产品负责人、敏捷教练、团队成员会坐在一起，共同决定这次的Sprint要完成哪些用户故事，并将故事分拆为任务，然后对任务进行估算。
2、Scrum日会/站会，找一个每天固定的时间，团队成员站在一起，每个人轮流陈述上一次日会之后已完成的内容、下一次日会之前期望完成的内容，然后对比前一次日会的“期望”与本次例会的“完成”，如果不符合，可以立即发现并寻找原因加以解决。
3、Sprint评审/演示，在Sprint结束的时候对完成的内容进行演示，或者叫验收。团队成员从用户的角度演示本期Sprint交付的故事如何被使用。这里有个经验，对于无法演示的内容，比如提高页面的平均加载速度至3s以内，拿出相应的证据进行“演示”即可。
4、回顾总结，可能都觉得没什么用，甚至团队成员在会上不知道说什么。我拿实际经验告诉你，坚持下去，很有用！对团队来讲长期收益巨大！团队会慢慢变得更有干劲、更有效率，输出的代码质量也会提高。如果没人发言，一定要逼着他们说。
Story & Task
说了这么多，终于到了跟Jira高度相关的部分了。在（一）中我们只简单提了Story是用户故事，现在是时候详细说明一下了。
用户故事，是从业务及用户角度出发，描述产品可以完成哪些事情的简要说明，每一条用户故事都应具备用户价值。书写正确的用户故事，是进行敏捷开发的重要一步。缺乏经验的产品负责人往往把用户故事当成团队成员要做的事情，而不是用户要做的事情。
举个例子，一个不合格的用户故事：
“在数据库中增加一个卖家联系方式字段并展示在前台页面上”
这个做了给谁用的？怎么用？有什么用？
对比一下合格的写法：
“卖家可以在管理后台填写联系方式，让使用App的买家在遇到问题时能及时联系专家”。
在这个合格的用户故事中，包含了3个要素：用户、行为、目标/价值。“某人可以做某事以达到某种目标”，或者“某人可以做某事以创造某种价值”。
用户故事言简意赅、目标清晰即可，不需要、也不应该写得非常详细。只要能达到目标/创建价值，在细节上采取什么方式都不重要，团队成员要做的是以用户故事作为指引，协力找出投入产出比最高的解决方案。太详细的用户故事，只会限制团队的创造力，并把团队的注意力吸引到“执行命令”而非“创造用户价值”上。
Task则是将用户故事分解之后得出的任务。比如刚刚举的用户故事的例子，就可以分拆成以下几个任务：
- 后端增加联系方式字段，并提供API供前端读写
- Web前端增加填写联系方式的表单
- App中显示相应卖家的联系方式
一些不涉及用户故事，但对团队有价值的工作，也可以列为“技术”任务。如“编写测试环境部署脚本，让测试人员可以主动选择测试分支”。
估算
把估算单独拿出来说，是因为在通过Jira实践Scrum敏捷开发时，估算是相当重要却又很容易被误用的一环。
对任务做估算的目的是为了对工作量有大致的预判，从而在有限的时间内交付尽可能多的用户价值（而不是开发工作量），更不是为了对项目的时间节点进行精确的控制。团队的生产速率基本是固定的，而具体到每个开发任务的工作量也都是基本固定的，所以只要团队都在持续且高效的输出价值就足够了。妄图以强制的deadline让团队成员持续加班，结果只能是幸福感降低，然后是效率降低，然后要么是交付物的质量下降要么是交付物的范围缩减，最后团队分崩离析。
估算一般有3种方法：小时数，点数，任务数。小时数过于精细，而且容易陷入精打细算的误区；任务数过于笼统，对任务分拆的粒度有较高的要求；点数即Jira中的Story Points，也是实践下来比较推荐的估算方法。
点数的是为了比较出开发任务之间的相对大小。随便选一个看起来工作量比较小的任务作为1，然后看其他任务是这个任务的几倍，遇到比这个任务还要小的就算0.5。在估算点数的时候，只能在0.5/1/2/3/5/8/15/20/30中选择，甚至30都不应该被使用，当一个任务的工作量是另一个任务的30倍的时候，这个任务一定可以被分解成更具体的任务。这么规定的原因还是因为我们要比的是相对大小，在估算时一个任务是18点还是19点，没有什么区别。
可以看到点数只是一个相对值，没有单位。在实践中，团队成员刚开始进行估算时很容易陷入1点 = xx小时的误区，先估计小时数，然后再把小时数换算成点数。作为Scrum Master，要么努力纠正这种误区并引导建立正确的观念，要么就让团队成员用人天当单位估算吧。
关于敏捷开发的基本概念和基础知识介绍的差不多了，其他一些像燃尽图、控制图、任务板之类的等用到再说吧。
微信公众号：三角规（ID：coding-designer）
