测试 - 敏捷开发

测试 - 敏捷开发

about

敏捷开发的思想是从20世纪90年开始，逐渐引起人们的广泛关注的一种开发方法，并不是一门技术。

重点需要记住：

• 敏捷开发的概念
• 敏捷开发的流程
• 敏捷开发的适用原则

敏捷开发的相关概念

什么是敏捷开发？

是一种以人为核心、迭代、循序渐进的开发方法。强调以人为本，专注于交付对客户有价值的软件。是一个用于开发和维持复杂产品的框架。该方法会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发。

为什么说以人为核心？

我们大部分人都学过瀑布开发模型，它是以文档为驱动的，为什么呢？因为在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。

什么是迭代？

迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

什么是Scrum？

Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。

而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。

Scrum开发流程中的三大角色

• 产品负责人（Product Owner）：主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。
• 流程管理员（Scrum Master）：主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
• 开发团队（Scrum Team）：主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。

如何进行Scrum开发？

来补充一个单词：Sprint，是短距离赛跑的意思，这里面指的是一次迭代，而一次迭代的周期是1个月时间（即4个星期），也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为Sprint。

1、我们首先需要确定一个产品需求列表（Product Backlog，按优先顺序排列的一个产品需求列表），这个是由产品负责人负责的；

2、开发团队根据产品需求列表，做工作量的预估和安排；

3、有了产品需求列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个任务作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个任务进行细化，形成一个任务列表（Sprint Backlog）；

4、任务列表（Sprint Backlog）是由开发团队去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；

5、在开发团队完成计划会议上选出的任务列表过程中，需要进行每日站立会议（ Daily Scrum Meeting），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；

此时，当开发人员开发一个任务时，测试也可以介入了，开发可以向测试人员讲解任务的具体功能，以便测试人员和开发人员对产品的功能有一个一致性的理解，然后测试人员这个时候可以编写相应的测试计划，或者提炼一些测试点。

6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；

7、当一个任务完成，也就是任务列表被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；

8、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；

PS：TFS（Team Foundation Server）是一个高可扩展、高可用、高性能、面向互联网服务的分布式文件系统，主要针对海量的非结构化数据，它构筑在普通的Linux机器集群上，可为外部提供高可靠和高并发的存储访问。TFS为淘宝提供海量小文件存储，通常文件大小不超过1M，满足了淘宝对小文件存储的需求，被广泛地应用在淘宝各项应用中。它采用了HA架构和平滑扩容，保证了整个文件系统的可用性和扩展性。同时扁平化的数据组织结构，可将文件名映射到文件的物理地址，简化了文件的访问流程，一定程度上为TFS提供了良好的读写性能。

敏捷开发的流程

来看两个敏捷开发的流程图作为参考。

我们来简要说说相关流程。

1、产品负责人将整个产品设计成产品待办列表（需求列表）。

2、召开产品迭代计划会议，确定哪些需求是要在第一个迭代中去完成的，评估迭代的时间（一般为2~4周），得到相应的迭代周期任务列表。另外，该会议提倡所有团队人员参与。

3、把迭代的功能需求写在便签纸贴在任务墙上，让大家认领分配（任务墙就是把未完成、进行中、已完成的工作状态贴到墙上，便于观察任务的状态）。任务看板包含 未完成、正在做、已完成 的工作状态，假设你今天把一个未完成的工作已经完成，那么你要把小卡片从未完成区域贴到已完成区域。

4、举行每日站立会议，让大家在每日会议上总结昨天做的事情，遇到什么困难。任务看板要保证让每个人看到，当每个人发言完后，要走到任务版前更新自己的燃尽图（上图右侧）。今天要做什么，一般该会议时间控制在15分钟左右。

5、评审会议（演示会议）是在迭代完成时举行，要向客户演示自己完成的软件产品，并获得客户的反馈。其实，很多用户对于软件开发没有概念，他只是提出自己的需求（有时候，用户对于需求也是模糊的），所以，我们就要通过不断地让用户看到产品的模型， 加以引导，这样用户才会逐渐的对产品和需求有清晰的认识。

6、最后就是总结会议，以轮流发言的方式进行， 每个人都要参与发言，总结经验教训，落实到后续的开发测试活动中，要注意，不要流于形式....

敏捷开发的原则

1-我们的最高目标是通过尽早和持续第交付有价值的软件来满足客户；

2-欢迎对需求提出变更 - 即使在项目开发后期，要善于利用需求变更，帮助客户获得竞争优势；

3-要不断交付可用的软件，周期从几周到几个月不等，越短越好

4-项目过程中，业务人员与开发人员必须在一起

5-要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务

6-无论是团队内还是团队间，最有效的沟通方法是面对面的交谈

7-可用的软件是衡量进度的主要指标

8-敏捷过程提倡可持续的开发，项目方，开发人员和用户应该能够保持恒久稳定的进展速度

9-对技术的精益求精以及对设计的不断完善将提升敏捷性

10-要做到简洁，尽可能减少不必要的工作，这是一门艺术

11-最佳的架构，需求和设计出自于自组织的团队

12-团队要定期反省如何能够做到更有效，并相应调整团队的行为。

敏捷开发技术的适用范围及优劣势

敏捷开发技术的适用范围

1.项目团队的人数不能太多

2.项目经常发生变更

3.高风险的项目实施

4.开发人员可以参与决策

根据以上几点，大体可以总结出：

优势：

敏捷确实是项目进入实质开发迭代阶段，用户很快可以看到一个基线架构版的产品。敏捷注重市场快速反应能力，也即具体应对能力，客户前期满意度高。

劣势：

但敏捷注重人员的沟通，忽略文档的重要性，若项目人员流动大太，又给维护带来不少难度，特别项目存在新手比较多时，老员工比较累。

---

欢迎斧正，that's all see also：[敏捷开发12个原则]() | | [敏捷开发和迭代开发]() | [论敏捷开发的优缺点](https://blog.csdn.net/devopscsdn/article/details/73498084)