敏捷开发学习笔记

有一年多没发博客了，离开IT行业后感受技术这块快荒废了，补一篇去年为了原公司上Jira而学习敏捷开发的笔记，若有不当之处,请予指正。Jira相关的内容稍后整理发布

PS：如下除Jira外其余截图均来自网络或正版书籍，若有侵权请及时联系我删除

1、先熟悉几个敏捷概念

一、传统和敏捷的区别（这里的传统开发指瀑布开发或计划驱动开发）

（1）画一幅画

（2）造一辆车

（3）火炮和导弹

（4）概念性比较

二、Project（项目）

JIRA的项目是根据你的企业组织须要定制的，是问题的集合。例如一个JIRA项目能够是:

一个软件研发项目

一项市场推广活动

一个技术服务/帮助台系统

一个需求管理系统

一个网站需求调查系统

Jira里的项目和禅道里的项目概念并不彻底相同：禅道里，产品和项目被明确的区分开。产品主要是管理需求、计划和发布。项目主要是管理任务开发需求。禅道里，项目对应的是敏捷开发里的迭代。项目能够看作产品的迭代管理，一个项目更新产品的一个新版本。一个产品可能分解成多个小项目，由一个或多个项目组去完成。

三、Version（版本）

在一个项目上，通常会有多个版本，如：1.0alpha、1.0beta、1.0、1.二、2.0。

（1）建立问题时会涉及到两个Version（版本）字段：

影响版本：能够清晰地反映出这个问题在哪一个版本中出现错误。例如, 一个软件的缺陷可能影响了产品的1.1和1.2版。

修复版本：能够反映出报告的问题将在哪一个版本，或已经在哪一个版本中修复了。例如, 软件缺陷影响了产品的1.1和1.2版，这个缺陷已经在2.0版中修复了。注意没有修复版本的问题会被归类到'未规划'。

（2）版本能够有3个状态: 已发布,未发布或已归档。版本能够设置发布日期,而JIRA会自动将到期而尚未发布的版本高亮显示出来，并标注上'超期'标志。

后边会详细讲解如何建立版本

下图是禅道的版本页面

四、Scrum

Scrum并非构建产品的一个流程或者一门技术；而是一个使用各类流程和技术开发和维持复杂产品的框架，是一个增量的、迭代的开发过程。Scrum使你更清楚地了解产品管理和开发实践的相对有效性，从而能够对其进行改进。Scrum 是一种团队管理工做的方式，其将工做分解为较小的工做单元，并在周期性固定的时间段内持续地交付工做单元。周期性固定的时间段，称为迭代（Iteration）或者冲刺（Sprint）。较小的工做单元，称为用户故事（User Story）。

（1）Scrum和Kanban的区别

（2）Scrum包括3个角色、3个物件、4个活动、5个价值

3个Roles（角色）

1  Product Owner（产品负责人）

2  Scrum Master（敏捷教练）       Pig（源自火腿和鸡蛋的故事）

3  Scrum Team（开发团队）

其余角色：Customer（用户及相关人员）               Chicken

Executive Management（非技术管理者）     （源自火腿和鸡蛋的故事）

3个Artifacts（物件）

1  Product Backlog（产品待办列表）

2  Sprint Backlog（迭代待办列表）

3  Product Increment（产品增量）

其余物件：Burndown Chart（燃尽图）：包含Sprint Burndown Chart（迭代燃尽图）和Release Burndown Chart（发布燃尽图）

4个Events（活动）

1  Sprint Planning Meeting（迭代计划会议）

2  Daily Scrum Meeting（每日站会）

3  Sprint Review Meeting（迭代评审会议）

4  Sprint Retrospective Meeting（迭代回顾会议）

其余活动：Product Backlog Refinement（产品待办列表梳理会议）

     Project Planning Meeting（项目计划会议）

Product Release Planning Meeting（产品发布计划会议）

5个价值

1  承诺 – 愿意对目标作出承诺

2  专一 – 把你的心思和能力都用到你承诺的工做上去

3  开放 – Scrum 把项目中的一切开放给每一个人看

4  尊重 – 每一个人都有他独特的背景和经验

5  勇气 – 有勇气作出承诺，履行承诺，接受别人的尊重

PS：Product Backlog（产品Backlog）和Sprint Backlog（迭代Backlog）的区别：

（3）Scrum步骤图

（4）用代码来描述Scrum完整框架

五、Sprint（冲刺）

虽然Sprint字面意思是短跑冲刺，但Scrum中的Sprint无对应中文翻译，一个短的"迭代"周期称为一个Sprint，这个迭代能够是一个开发阶段/小开发计划/小目标，一个个 sprint 首位相连，构成一个项目。每一个Sprint的长度最好保持一致，建议是2到4周。

（1）冲刺规划

（2）冲刺时间

下图是为何要采用2到4周这个较短Time box（时间盒）的缘由：

当到达结束时间时，每一个Sprint都要完成一个潜在可发布Product Increment（产品增量），而且要达到Scrum团队一致认同的完成定义。

（3）关于延期

要在Sprint计划中考虑可能延期的问题，而且制定解决方案，好比：

团队增长人员（Scrum不建议这么作）；

加班（Scrum不建议这么作，违背Scrum原则）；

拆分Story（Scrum不建议这么作）：将级别低的PBI从当前Sprint中移动到Backlog中，在以后的Sprint中完成（下边Story Point一节会讲到）；

由专人处理干扰Sprint的突发状况（Scrum建议这么作）。

（4）异常终止迭代

这里须要注意一个"异常终止"的概念，当有重大的经济事件发生时，Product Owner（产品负责人）能够终止这次迭代，好比竞争对手的某些举措或研发费用发生变化等缘由，但终止迭代会影响团队士气和以前迭代的Product Increment（产品增量）

六、Swimlane（泳道）

泳道最开始是在UML中出现，叫swimlane也有人叫partition，除了纵向的按照状态定义的列，还可使用横向的泳道区分，好比区分一个团队中的多个产品

下图是Jira中Sprint看板，用来展现Sprint（冲刺）和Swimlane（泳道），具体位置在【项目】-【活动的Sprint】中能够查看，竖列表示泳道，可拖拽其中的PBI（产品任务列表）。这里的【活动的Sprint】是Scrum三物件中的Sprint Backlog（迭代Backlog）

下图是Kanban中的Swimlane（泳道），操做和Sprint相似

其实GitLab中也有相似的看板和泳道

七、Time box（时间盒）

（1）概念

Time box（时间盒）是一种管理方法，即在预算时间内对完不成的功能进行删减或者延迟，而不是拖延预算的时间。用咱们熟悉的术语就是"后墙不倒"。 一个"Time box"是一个比较短并且固定长度的时间段。在这个时间段中，团队成员要为知足一个特定的目标作出努力。这个目标能够是一批功能需求或技术需求，也能够是知足一个发布目标（例如，beta测试应支持150个用户），还能够是完成一个可运行的原型，等等。Scrum中全部用到时间的地方都适用于Time box（时间盒），好比：每次迭代必须在固定的时间内完成、每一个会议必须在规定时间内结束、会议上发现的问题作出的决策必须在必定时间内完成。

（2）克服"帕金森定律"

帕金森定律是指，"无论有多少时间，工做都会扩展，直至耗尽全部的时间"。在以产品开发阶段定义里程碑的项目中，几乎总能看到帕金森定律的做用。这也被称为学生综合症 —— "必定要等到考试前一刻，才能结束功课的复习"。短的固定长度的时间盒，将迫使团队，在一段时间，聚焦在有限的功能。相比几个月后的里程碑，一到数周后的交付目标显然更容易引起重视和紧迫感。一方面，这下降了项目进度风险发生的可能；另外一方面也下降了进度风险发生时的影响，项目结束时，至少能够交付已完成迭代的内容，相对错过最终的发布周期，如期交付80%内容（一般也是最重要的80%），显然是更成功的。

八、Backlog（区分优先级的功能列表）

敏捷须要维护一份详尽的PBI。这份列表经常要求 scrum 持有人（通常是项目负责人）对全部待开发事项有深刻了解，而且可以把待开发事项分解成更为细致的任务。

Jira的【Backlog】页面中存放有全部剩余未完成的故事，包括待开发任务和任务优先级等信息，且由项目负责人维护。【Backlog】页面下方的Backlog子类并非Scrum三物件中的Product Backlog（产品Backlog），由于Product Backlog不包含"故事"（此处有详细解读：https://blog.csdn.net/cpongo4/article/details/89141979）。在任何状况下，敏捷开发中的故事是经过会话了解需求的一种行为方式（故事="卡片，会话和确认"），自己并非在列表里的一件事情。若是确实要在Jira中引入Product Backlog，须要额外使用墙贴或者Excel配合Jira使用

梳理Backlog中的PBI

九、Issue（问题）/ Epic（史诗）/ Sprint（冲刺）/ Version（版本）之间关系

Epic是Issue的一种，Sprint是一期迭代开发计划，相似PRD（产品需求文档）的做用，每期Sprint里会放各类Issue。某些Issue一块儿发布时，能够添加到一个Version用来管理这一次部署的实际内容。若是开发周期和发版周期彻底一致的话，Sprint和Version里就会有相同的Issue。一个Sprint能够属于多个Version，一个Version也能够属于多个Sprint

十、Story（用户故事）

用户故事是从须要该新功能的用户角度来说述的短小简单的描述。当一个故事很是庞大时就会变成Epic（史诗），在Jira中史诗是不会直接放入Sprint中进行开发的。故事的下一级别是任务。举个例子：拿微信产品来讲的话，用户的分享行为就是一个 Story，这个 Story 还能够被拆分为分享到朋友圈、分享给好友两个Task（任务）。

经过经典的"三段论"（见下方）描述和渐进的细节探索，用户故事实现了需求描述的敏捷化；

经过优先级排序和故事点的有效应用，用户故事实现了需求到开发的链接；

经过验收标准的渐进明确，用户故事实现了需求与测试的链接。

一个Sprint中Story不要太多，但一个Story尽可能在一个Sprint中完成，如没法完成则须要拆分这个Story

（2）故事和需求的区别

（3）用户故事三要素（"三段论"描述）

下图是一个故事模板

举个例子：做为一个"网站管理员"，我想要"统计天天有多少人访问了个人网站"，以便于"个人赞助商了解个人网站会给他们带来什么收益。"

（4）3C原则（出自Ron Jeffries 2001）

卡片（Card）：用户故事通常在小卡片上写着故事的简短描述，工做量估算等。

交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通。

确认（Confirmation）：经过验收测试确认用户故事被正确完成。

（5）用户故事的标准：INVEST原则（出自《User Stories Applied For Agile Software Development》-Mike Cohn 2004）

在现实工做中，会存在一小部分很是复杂的用户需求，很难同时彻底知足这6个原则，但至少要知足可估算、规模小、可验证，即EST>INV

（6）故事拆分方法：

路径拆分法：例如微信支付方式和过程

按接触点拆分：例如IE内核浏览器和非IE内核浏览器

按数据类型或格式拆分：例如经过CSV、XML、Excel格式导入数据

按规则拆分：例如导航分为时间最短和距离最短

按探索路径拆分：例如用原有技术和探索新技术开发用户故事

（7）可视化故事墙

就是咱们在Jira的【项目】-【活动的Sprint】中看到的【泳道】

默认只有3个状态：To Do、Doing、Done

能够根据实际状况改成：待开发、开发中、待测试、测试中、测试完成

更完善的状态：需求池、初稿、评审稿、待开发、开发中、待测试、测试中、待上线、已上线

十一、Story Point（故事点）

故事点是一个度量单位，用于表示完成一个产品待办项或者其余任何某项工做所需的全部工做量的估算结果。影响工做量的全部因素包括：要开展的工做的数量、工做的复杂度、要开展的工做中存在的任何风险或不肯定性。在用故事点估算时，必需要考虑以上每个因素。

在某些教材中故事点用于生产能力的分配：

Jira中的故事点

（1）下边是一种估算一个Sprint周期全部故事点的方式：

因为Srum团队有时会受到外界因素的干扰，好比须要处理客户反馈的一些BUG，这样就要使用"Yesterday's weather（昨日天气）"从新计算故事点：

这样得出一个合理的故事点，须要注意的是前一个迭代产生的BUG要放在最优先级解决，因此要谨慎估算目前迭代的故事点

咱们从Jira的Backlog中取出知足故事点的故事放入到本次Sprint迭代中去， 注意：从上到下优先级从高到低

具体操做是在【项目】-【Backlog】页面中将下方Backlog中的PBI拖动到上方Sprint中

（2）下边是一种估算单个故事故事点的方式：计划纸牌

计划纸牌是基于Wide band Delphi（宽带德尔菲）法的估算技能、也是以共识为基础的工做量估算技能。有时候也称为 Scrum 扑克，每每在故事点和开发用户故事中用来估算相对工做量。

斐波那契数列经常使用来衡量计划扑克的价值（即 0、一、二、三、五、8…，这个数列从第3项开始，每一项都等于前两项之和），这里会用另外一种更常见数列（?、0、1/二、一、二、三、五、八、1三、20、40、100）。

具体使用实例见这里：http://www.uml.org.cn/SoftWareProcess/201108264.asp

如下是大概描述：

当一个故事估算出故事点后，再用"相对估算法"估算其余故事的故事点

PS：几个问题

Q：修 Bug 算不算工做量？

A：这点不一样团队的处理不一样。比较激进的 Scrum 团队认为修 Bug 不该该算点数（Point），由于 Bug 原本是不该该存在的，是开发的失误致使了 Bug。而在评估一个功能点时，所给出的点数，是指将此功能点开发至正确提交时的所有投入，修 Bug 已经包括在里面了。这样说虽然有必定道理，不过在实际操做中很难实现。具体是否算点数，是否把修 Bug 放在每一个 Sprint 的计划中，还要团队本身定夺。

十二、Definition of Done（完成的定义或标准）

"完成"的定义通常在在Sprint Planning Meeting中由整个团队肯定。"完成"涉及到Scrum的方方面面。下边大致说明一下"完成"的定义。

（1）Sprint的DoD：

全部完成的用户故事获得PO的内部验收

全部代码获得静态分析，纠正最高级别的不符合项

全部新增代码获得人工评审

全部完成的用户故事都有对应的测试用例

（2）每日的DoD：

搭建每日构建环境，晚上自动静态代码检查、编译、部署和测试，每日修复前一日构建和测试发现的缺陷和问题。

天天下班前，至少checkin代码一次，checkin的change-log要填写清晰

当天的代码必须在当天或者第2天进行人工评审

checkin的代码有通过自动化单元用例

当天持续集成、构建环境中的问题，请当天解决

（3）Story的DoD

用户故事最终的描述符合INVEST

用户故事获得测试用例的对应覆盖

用户故事获得对应的自动化测试用例

用户故事获得用户表明试用并初步承认

用户故事获得PO的内部验收

（4）项目的DoD：

注意看下边的Sprint看板，绿色的Story（故事）TEST-6已经被划掉，由于其中的Sub Task（子任务）TEST-7已经处于完成状态，而故事TEST-10因为其中的子任务没有所有完成，因此还处在迭代中

DoD总结成三条：

代码写完了没？

Bug除光了没？

产品能够上线了没？

1三、Burndown Chart（燃尽图）

Scrum三物件中的一个，是在项目完成以前，对须要完成的工做的一种可视化表示。燃尽图有一个Y轴（工做）和X轴（时间）。理想状况下，该图表（这里使用了Story Point做为参考值）是一个向下的曲线，随着剩余工做的完成，"烧尽"至零。

以冲刺燃尽图为例：燃尽图的元素有

横坐标：sprint的工期（以天计算）。

纵坐标：sprint 内剩余任务的总预计工时（以小时标记）。

计划曲线：理想状况下的任务进展曲线（图中的黑色线），做为参考之用。

实际曲线：任务的实际进展曲线（图中的红色线）。

燃尽图就是天天将项目中全部任务剩余工时的总和计算一下，造成坐标（图中的红色点），而后逐次把点链接起来，造成剩余工做量的趋势线。

燃尽图的解读规则：

（1）若是实际曲线在计划曲线如下，说明进展顺利，有比较大的几率定期完工；

（2）若是实际曲线在计划曲线以上，说明有比较大的几率延期，这是就须要关注进度了。

Burndown Chart（燃尽图）和Gantt（甘特图）的区别：

甘特图须要严格的设置过任务的起止时间和前置关系，是一种控制式的管理，因此非敏捷项目也可使用甘特图。而燃尽图则更关注于作完总体的项目还剩下多少时间，因此燃尽图是敏捷独有的概念。甘特图适用于项目初期和中期，用于计划和检查进度的完成状况。燃尽图用于项目开始到项目结束，用于提醒你们项目进度和要完成的任务。

1四、Information Radiator（信息发射源）

在现实中，敏捷团队工做空间的各类颜色的便笺，白板，各类图表等，称为信息发射源 Information Radiator，它能够很好的用于项目的沟通、展现项目的状态。在Jira中的表现形式就是Sprint中的泳道（见前述）、项目的报告（以下图）

1五、松散敏捷

"松散敏捷"并不是一个术语，它用来形容那种"非纯"敏捷团队。因为"纯度"不一样，不一样团队从 Scrum 中汲取的内容不一样。不过通常而言，只要声称 Scrum 的团队，必定会有站会（Stand Up Meeting）。配合站会，就会有 Backlog 和 Dashboard。其余的会议、工具，甚至角色分配，就不必定了。不少"松散 Scrum"团队，根本没有 PO，SM 概念，也不关心猪和鸡的区别。