敏捷开发模型（Agile Software Development）
Posted 测试小咖汇
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了敏捷开发模型（Agile Software Development）相关的知识，希望对你有一定的参考价值。
但互联网行业和传统行业不一样，产品研发周期短，一个项目可能一个月就发布了，有的可能只需要半个月，而更甚的是一周就可能要更新迭代一个版本，这就要求研发过程更加精简，所以互联网行业推崇的是“快”。
所以敏捷开发模型是
目前软件公司最喜欢的，传统的瀑布模型（如下图所示）不适合我们了。
敏捷都是被逼的。被客户逼的；被老板逼的；被市场逼的。
敏捷开发中，最有名的一种迭代式增量软件开发过程叫Scrum。
Scrum的英文意思是橄榄球的专业术语，表示“争球”的动作，引用在软件项目上，寓意是在做项目的时候，大家像打橄榄球一样迅速、富有战斗力、人人你争我抢的快速完成任务。
（1）在Scrum中，使用Product Backlog来管理产品的需求，这是一个按照商业价值排优先级顺序的需求列表，一个列表称为一个User Story（用户故事）。
（2）Scrum团队要先开发对客户具有较高价值的需求。她们会从Product Backlog中挑选最高优先级的需求进行开发。对任务需求进行工作量的预估和调整排序。
（3）挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，称为Sprint Backlog。细化工作量，不超过2人天，方便任务看板上小纸条的挪动。时间太长的话，会发现一张任务纸条在同一栏中好几天不变化，让人看不到完成度。
（4）整个开发过程由若干个短的迭代周期组成，一个周期称为一个Sprint，每个Sprint的建议长度是2到4周，有的迭代周期只有1周。Scrum过程中有2个特色：Daily Meeting（每日站会）和Sprint Burn Down（燃尽图）。
（5）在增量完成时，Scrum团队会开一个产品演示会，称为Sprint Review Meeting。递交潜在可交付的产品增量。
（6）在迭代结束时，开一个Sprint Retrospective Meeting，回顾会议或者叫茶话会，让大家可以对过去进行总结，对未来进行预期。
在Scrum中，严格区分2类人，一种是“鸡”的角色，一种是“猪”的角色。这起源于一个古老的笑话：
“猪”：代表的是全身心、倾其所有地投入到项目当中，一般是项目的核心成员。比如：产品经理、项目经理、Scrum团队（包括开发、测试、运维）。
“鸡”：他们不是Scrum的一部分，但必须要考虑他们。比如：用户、客户和高层管理者。
注意：
在一个项目中，伸手过界的鸡不能太多，今天来个领导说这样做，明天来个领导说那样做，团队成员就不知道该怎么做了。
Scrum有三大角色、三大支柱、三大工件、五个活动，另外还有两大特色：任务看板和燃尽图。
也就是产品经理，产品相关的内容需要他来做全局统筹和规划。
可能会有一些委员会向Product Owner提出建议或影响他的决策，但要想改变某个需求的优先级必须先说服Product Owner。
为了保证项目的成功，团队中所有人员都必须尊重他的决定。
任何人都不得要求团队按照另一套优先级开展工作，哪怕是一些带有威胁恐吓性的指令。
-
-
-
-
-
-
在Sprint结束时接受或拒绝接受开发团队的工作成果。
Scrum Master作为Team Leader和Product Owner紧密地工作在一起，他可以及时地为团队成员提供帮助。
类似于牧羊犬的角色，他要保证羊群不会跑丢，也要保证羊群中不会混入其他羊群的羊。
-
-
-
-
-
保证开发过程按计划进行，组织DailyMeeting、Sprint Meeting和Sprint Review Meeting；需要清楚三种状态的任务分别有哪些（To do、Doing、Done），需要更新燃尽图（urn DownChart）；
-
最小化每个任务，以实现精益生产率的收益。
Scrum Team是在每个Sprint中将产品Backlog中的列表转化为潜在可交付的功能增量。
-
如果少于5人，团队生产力可能会下降或者受到技能限制导致无法交付可发布的产品模块；如果多于9人，就需要太多的协调沟通工作，复杂、不便于经验过程控制。
对于大型项目来说，可采用多个小的Scrum团队，通过Scrum of Scrums解决团队间的沟通协调问题。
-
比如：开发、测试、业务分析、架构师、UI和数据库设计等的专业技能，还要有一定的表达沟通能力。
在Scrum团队中没有头衔的概念，每个人都必须尽心尽力完成Sprint目标。
团队中不允许包括测试或业务分析等在特定领域工作的子团队。
-
如何将产品Backlog转化为可交付的功能增量，是由团队自己确定的。
团队的构成在Sprint结束时可能会发生变化，每次团队成员的变化，都会降低通过自组织而获取的生产力。
Scrum以经验主义作为理论基础的过程，主张知识源于经验，以及基于已知的东西做决定。
Scrum采用迭代、增量的方法来优化可预见性并控制风险。
Scrum三大支柱支撑起每个经验性过程控制的实现：透明性、检验和适应。
Daily Meeting：通过每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作量；
Sprint Review Meeting：通过Sprint评审和计划会议检验发布日期的进展，做出调整，从而优化下一个Sprint的工作价值；
Sprint Retrospective Meeting：通过Sprint Review Meeting回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。
在Scrum中，主要有Product Owner整理和维护Product Backlog 。
Product Backlog是Scrum中维护需求的主要工件，也是做好Scrum的第一步。
一般来讲，Product Backlog可能包括的内容是：
新特性、改进项、缺陷修复和文档需求等。
从Product Backlog中挑选的当前Sprint要完成的需求列表，以及细化后的任务组成。
要明确当前Sprint的目标，团队根据这个目标以及Product Backlog的排序来进行挑选。
也就是说：Sprint Backlog的内容、具体的工作方式和实现方式，都是由团队自己来决定的。
这体现了团队的自组织能力。
产品增量是Scrum中非常重要的工件，因为这才是最终交付给客户的内容。
开发团队通过不断地交付产品增量，给团队本身和利益相关的人以信心，促使产品最终发布。
团队进展还有其他常用的标识，是燃尽图和任务看板，一般使用燃尽图和任务看板时，是为了使当前的进度公开给更多的其他团队或干系人。
完成定义，指的是当产品增量完成时，必须是团队成员共同理解的完成，而不会出现歧义。
并且是高质量的，潜在可发布的。也就是说，如果Product Owner想发布的时候，马上就可以发布出去。
完成的定义，是团队根据团队当前的情况，共同协商制定的，共同同意并理解的。
不过，完成的定义也不是一成不变的，随着时间的推移，团队倾向于更加严格的定义，比如把更多的内容添加到完成的定义中。
（1）产品待办事项列表梳理（Product Backlog Refinement）
这个通常很大，也很宽泛，而且想法会变来变去、优先级也会变化，所以它是一个贯穿整个Scrum项目始终的活动，包含但不限于以下的内容：
梳理他的一个好处就是为即将到来的几个Sprint做准备。
需要考虑不少因素。理想情况下，下一个Sprint的备选事项都应该提升“商业价值”。
开发团队需要能够在一个Sprint内完成每一个事项。
产品开发决定了有可能需要其他的技能和输入，因此，产品待办事项梳理最好是所有团队成员都的活动，而不单单是产品负责人。
（2）Sprint计划会议（Sprint Planning Meeting）
每个Sprint都以Sprint计划会议作为开始，这是一个固定时长的会议。
在会议中，Scrum团队共同选择和理解在即将到来的Sprint中要完成的工作。整个团队都要参加Sprint计划会议。
针对排好序的Product Backlog，Product Owner和Scrum Team讨论每个事项，并对该事项达成共识，包括根据当前的“完成的定义”，为了完成该事项所需要完成的所有事情。
所有的Scrum会议都是限定时间的，如果一个Sprint包含2周，那么建议会议时长为4个小时或者更少。
因为会议是限制时长的，所以Sprint计划会议的成功十分依赖于产品待办事项列表的质量。
在Scrum Planning Meeting中有两部分内容：
开发团队需要对每一个分解的任务进行工作量评估，分解的粒度最好是以1人天为单位，最多不超过2人天。
在评估的时候，可以采用白纸方法。
（3）每日站会（Daily Scrum Meeting）
开发团队是自组织的。他们通过每日站会来确保完成Sprint目标，注意是站立会议。
这个会议每天在同样的时间和地点召开，是限定时长的，一般不超过15分钟。它能帮助快速发现问题，并促进团队的自组织和自立。
站立会议时，大家每天轮流主持，每个团队成员都需要发言，提供以下信息：
每日站会上可能有简要的问题澄清和回答，但不应该有任何话题的讨论。
每日站会既不是向管理层汇报，也不是向产品负责人或者Scrum Master汇报。
它是开发团队内部的沟通会议，来保证他们对现状有一致的了解。
在必要时，开发团队会基于会议中的发现重新组织他们的工作来完成Sprint的目标。
（4）Sprint评审会议（Sprint Review Meeting）
Sprint结束时，团队相关人员一起评审Sprint的产出。
如果一个Sprint包含了2周，那么会议推荐时长是2个小时。
由于Sprint的产出会涉及到一些人的“利益”，所以一个明智的做法是邀请他们参加这个会议。
在会议上，通常会演示产品增量，帮助大家了解项目进展，并讨论下一步计划。
当然，产品负责人会做最终的决定，并适当地调整Product Backlog。
通常，在Sprint评审会议中都会调整ProductBacklog。
（5）Sprint回顾会议（Sprint Retrospective Meeting）
在每个Sprint结束后，Scrum团队开会回顾一下团队在流程、人际关系以及工具方面做的如何。
团队识别出哪些做的好，哪些做的不好，并找出潜在的改进事项，为将来的改进制定计划。
同样，一个Sprint包含2周的话，推荐会议时长是2个小时。
Scrum团队总是在Scrum的框架内，改进他们自己的流程。
在Scrum中，通过可视化的任务看板来实现团队协同和透明化管理是必不可少的一个实践。
敏捷的任务看板通常每个迭代一个，看板的结构通常包括如下几列：
Story：
用户故事。这是需求的表达方式，每个Story代表了从产品的用户视角表达的一条用户需求。这些Story加在一起就是这个迭代的目标。通常按优先级从上到下排列。
Todo：
待办任务项。Story会被分解为对应的技术任务，这些待办的技术任务放到To do列。
Done：
已经完成的任务，放已经完成的任务和Story。
在任务看板上，除了这4列之外，还要为每个Story建立一个泳道，通过泳道来管理Story和任务的对应关系。
-
可视化管理团队的目标。项目需要做什么，团队成员一目了然。
-
可视化管理任务的进展状况。谁做了什么，正在做什么，还有待做什么，一目了然，如果有人的小纸条几天不动，就很容易发现他的进度拖延了。Master也可以及时的寻求解决方案，以防影响项目进度。
-
领导或者其他人如果想知道项目的进度，不需要特别汇报，只看任务看板就可以窒息一切。
燃尽图是在项目完成之前，对需要完成的任务工时的一种可视化显示。
理想情况下，该图表是一个向下的曲线，随着剩余任务的完成，燃尽至零。
燃尽图的目标是完成迭代的目标，也就是按Product Owner的要求，交付Story。这个定义有它的狭隘之处，潜在的问题包括：
如果燃尽图按时完成，有可能是为了按时完成，同时牺牲了所有Story的质量，换取了进度；
如果燃尽图未按时完成，有可能不是一个Story没有完成，而是所有Story都剩下一点没做完，导致所有故事都无法支付；
如果燃尽图未按时完成，没有完成的Story中，有可能包括了极其重要的一些。
只从燃尽图形态看，是无法提前识别这三者的，也就因此带来了很多的风险，到迭代的末尾让人大吃一惊。
现在比较常用的就是微信群、QQ群这些及时通信工具进行沟通；
另外，建议在项目开始之初就整理好团队成员的邮件列表和联系方式，把重要任务进行定时提醒；
也可以把一些文档地址、测试地址和工具地址张贴在公告板上，项目组成员一抬头就能看见，不用再到处去翻；
每日站会也可以代替周报，任务看板代表了Sprint的整体进度，都是很好的敏捷沟通方式。
当然，如果大家都在一起办公的话，最简单的沟通方式就是“吼”。吼一声就能快速得答案，不需要再邮件来邮件往的耽误时间啦。
相信通过以上的介绍，你已经对Scrum有了一定的了解。
Scrum是一种管理流程，流程的作用就是：人不在，事还能做，它减少了特定的人对事的影响。
以上是关于敏捷开发模型（Agile Software Development）的主要内容，如果未能解决你的问题，请参考以下文章
敏捷软件开发（Agile Software Development）的上位史
敏捷软件工程(agile software development) VS传统软件工程(traditional software development)
敏捷开发学习笔记-Agile development（AM）
自适应软件开发过程思想自适应软件开发 - 简介 Adaptive Software Development Introduction（中英文）
自适应软件开发过程思想自适应软件开发 - 简介 Adaptive Software Development Introduction（中英文）
GXP环境下，对敏捷开发及验证的思考
