有一年多没发博客了，离开IT行业后感觉技术这块快荒废了，补一篇去年为了原公司上Jira而学习敏捷开发的笔记，如有不当之处,请予指正。Jira相关的内容稍后整理发布
PS：以下除Jira外其他截图均来自网络或正版书籍，如有侵权请及时联系我删除
一、先熟悉几个敏捷概念
1、传统和敏捷的区别（这里的传统开发指瀑布开发或计划驱动开发）
（1）画一幅画
（2）造一辆车
（3）火炮和导弹
（4）概念性比较
2、Project（项目）
JIRA的项目是根据你的企业组织需要定制的，是问题的集合。例如一个JIRA项目可以是:
一个软件研发项目
一项市场推广活动
一个技术服务/帮助台系统
一个需求管理系统
一个网站需求调查系统
Jira里的项目和禅道里的项目概念并不完全相同：禅道里，产品和项目被明确的区分开。产品主要是管理需求、计划和发布。项目主要是管理任务开发需求。禅道里，项目对应的是敏捷开发里的迭代。项目可以看做产品的迭代管理，一个项目更新产品的一个新版本。一个产品可能分解成多个小项目，由一个或多个项目组去完成。
3、Version（版本）
在一个项目上，一般会有多个版本，如：1.0alpha、1.0beta、1.0、1.2、2.0。
（1）创建问题时会涉及到两个Version（版本）字段：
影响版本：可以清晰地反映出这个问题在哪个版本中出现错误。例如, 一个软件的缺陷可能影响了产品的1.1和1.2版。
修复版本：可以反映出报告的问题将在哪个版本，或已经在哪个版本中修复了。例如, 软件缺陷影响了产品的1.1和1.2版，这个缺陷已经在2.0版中修复了。注意没有修复版本的问题会被归类到'未规划'。
（2）版本可以有3个状态: 已发布,未发布或已归档。版本可以设置发布日期,而JIRA会自动将到期而还没有发布的版本高亮显示出来，并标注上'超期'标志。
后边会详细讲解如何创建版本
下图是禅道的版本页面
4、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完整框架
5、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（产品增量）
6、Swimlane（泳道）
泳道最开始是在UML中出现，叫swimlane也有人叫partition，除了纵向的按照状态定义的列，还可以使用横向的泳道区分，比如区分一个团队中的多个产品
下图是Jira中Sprint看板，用来展示Sprint（冲刺）和Swimlane（泳道），具体位置在【项目】-【活动的Sprint】中可以查看，竖列表示泳道，可拖拽其中的PBI（产品任务列表）。这里的【活动的Sprint】是Scrum三物件中的Sprint Backlog（迭代Backlog）
下图是Kanban中的Swimlane（泳道），操作和Sprint类似
其实GitLab中也有类似的看板和泳道
7、Time box（时间盒）
（1）概念
Time box（时间盒）是一种管理方法，即在预算时间内对完不成的功能进行删减或者延迟，而不是拖延预算的时间。用我们熟悉的术语就是"后墙不倒"。 一个"Time box"是一个比较短而且固定长度的时间段。在这个时间段中，团队成员要为满足一个特定的目标做出努力。这个目标可以是一批功能需求或技术需求，也可以是满足一个发布目标（例如，beta测试应支持150个用户），还可以是完成一个可运行的原型，等等。Scrum中所有用到时间的地方都适用于Time box（时间盒），比如：每次迭代必须在固定的时间内完成、每个会议必须在规定时间内结束、会议上发现的问题做出的决策必须在一定时间内完成。
（2）克服"帕金森定律"
帕金森定律是指，"不管有多少时间，工作都会扩展，直至耗尽所有的时间"。在以产品开发阶段定义里程碑的项目中，几乎总能看到帕金森定律的作用。这也被称为学生综合症 —— "一定要等到考试前一刻，才能结束功课的复习"。短的固定长度的时间盒，将迫使团队，在一段时间，聚焦在有限的功能。相比几个月后的里程碑，一到数周后的交付目标显然更容易引发重视和紧迫感。一方面，这降低了项目进度风险发生的可能；另一方面也降低了进度风险发生时的影响，项目结束时，至少可以交付已完成迭代的内容，相对错过最终的发布周期，如期交付80%内容（通常也是最重要的80%），显然是更成功的。
8、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
9、Issue（问题）/ Epic（史诗）/ Sprint（冲刺）/ Version（版本）之间关系
Epic是Issue的一种，Sprint是一期迭代开发计划，类似PRD（产品需求文档）的作用，每期Sprint里会放各种Issue。某些Issue一起发布时，可以添加到一个Version用来管理这一次部署的实际内容。如果开发周期和发版周期完全一致的话，Sprint和Version里就会有相同的Issue。一个Sprint可以属于多个Version，一个Version也可以属于多个Sprint
10、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
可以根据实际情况改为：待开发、开发中、待测试、测试中、测试完成
更完善的状态：需求池、初稿、评审稿、待开发、开发中、待测试、测试中、待上线、已上线
11、Story Point（故事点）
故事点是一个度量单位，用于表示完成一个产品待办项或者其他任何某项工作所需的所有工作量的估算结果。影响工作量的所有因素包括：要开展的工作的数量、工作的复杂度、要开展的工作中存在的任何风险或不确定性。在用故事点估算时，必须要考虑以上每一个因素。
在某些教材中故事点用于生产能力的分配：
Jira中的故事点
（1）下边是一种估算一个Sprint周期所有故事点的方式：
由于Srum团队有时会受到外界因素的干扰，比如需要处理客户反馈的一些BUG，这样就要使用"Yesterday's weather（昨日天气）"重新计算故事点：
这样得出一个合理的故事点，需要注意的是前一个迭代产生的BUG要放在最优先级解决，所以要谨慎估算目前迭代的故事点
我们从Jira的Backlog中取出满足故事点的故事放入到本次Sprint迭代中去， 注意：从上到下优先级从高到低
具体操作是在【项目】-【Backlog】页面中将下方Backlog中的PBI拖动到上方Sprint中
（2）下边是一种估算单个故事故事点的方式：计划纸牌
计划纸牌是基于Wide band Delphi（宽带德尔菲）法的估算技能、也是以共识为基础的工作量估算技能。有时候也称为 Scrum 扑克，往往在故事点和开发用户故事中用来估算相对工作量。
斐波那契数列常用来衡量计划扑克的价值（即 0、1、2、3、5、8…，这个数列从第3项开始，每一项都等于前两项之和），这里会用另一种更常见数列（?、0、1/2、1、2、3、5、8、13、20、40、100）。
具体使用实例见这里：http://www.uml.org.cn/SoftWareProcess/201108264.asp
以下是大概描述：
当一个故事估算出故事点后，再用"相对估算法"估算其他故事的故事点
PS：几个问题
Q：修 Bug 算不算工作量？
A：这点不同团队的处理不同。比较激进的 Scrum 团队认为修 Bug 不应该算点数（Point），因为 Bug 本来是不应该存在的，是开发的失误导致了 Bug。而在评估一个功能点时，所给出的点数，是指将此功能点开发至正确提交时的全部投入，修 Bug 已经包括在里面了。这样说虽然有一定道理，不过在实际操作中很难实现。具体是否算点数，是否把修 Bug 放在每个 Sprint 的计划中，还要团队自己定夺。
12、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除光了没？
产品可以上线了没？
13、Burndown Chart（燃尽图）
Scrum三物件中的一个，是在项目完成之前，对需要完成的工作的一种可视化表示。燃尽图有一个Y轴（工作）和X轴（时间）。理想情况下，该图表（这里使用了Story Point作为参考值）是一个向下的曲线，随着剩余工作的完成，"烧尽"至零。
以冲刺燃尽图为例：燃尽图的元素有
横坐标：sprint的工期（以天计算）。
纵坐标：sprint 内剩余任务的总预计工时（以小时标记）。
计划曲线：理想情况下的任务进展曲线（图中的黑色线），作为参考之用。
实际曲线：任务的实际进展曲线（图中的红色线）。
燃尽图就是每天将项目中所有任务剩余工时的总和计算一下，形成坐标（图中的红色点），然后逐次把点连接起来，形成剩余工作量的趋势线。
燃尽图的解读规则：
（1）如果实际曲线在计划曲线以下，说明进展顺利，有比较大的概率按期完工；
（2）如果实际曲线在计划曲线以上，说明有比较大的概率延期，这是就需要关注进度了。
Burndown Chart（燃尽图）和Gantt（甘特图）的区别：
甘特图需要严格的设置过任务的起止时间和前置关系，是一种控制式的管理，所以非敏捷项目也可以使用甘特图。而燃尽图则更关注于做完整体的项目还剩下多少时间，所以燃尽图是敏捷独有的概念。甘特图适用于项目初期和中期，用于计划和检查进度的完成情况。燃尽图用于项目开始到项目结束，用于提醒大家项目进度和要完成的任务。
14、Information Radiator（信息发射源）
在现实中，敏捷团队工作空间的各种颜色的便笺，白板，各种图表等，称为信息发射源 Information Radiator，它可以很好的用于项目的沟通、展示项目的状态。在Jira中的表现形式就是Sprint中的泳道（见前述）、项目的报告（如下图）
15、松散敏捷
"松散敏捷"并非一个术语，它用来形容那种"非纯"敏捷团队。由于"纯度"不同，不同团队从 Scrum 中汲取的内容不同。不过一般而言，只要声称 Scrum 的团队，一定会有站会（Stand Up Meeting）。配合站会，就会有 Backlog 和 Dashboard。其他的会议、工具，甚至角色分配，就不一定了。很多"松散 Scrum"团队，根本没有 PO，SM 概念，也不关心猪和鸡的区别。
