敏捷开发整理

开发宣言：

个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
虽然右项也有价值，但是我们认为左项具有更大的价值。

 

敏捷开发与测试的关系：
正因为敏捷开发的这些特征，原则，模式等等，才需要有相应的敏捷测试团队与之匹配，注重和敏捷开发团队配合，沟通，并且重要的是测试团队要理解和重视敏捷的思想，融入这样的一个大的团队当中。

遵循原则：

1. 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2. 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3. 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
4. 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5. 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
6. 在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。
7. 工作的软件是首要的进度度量标准。
8. 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
9. 不断地关注优秀的技能和好的设计会增强敏捷能力。
10. 简单是最根本的。
11. 最好的构架、需求和设计出自己组织的团队。
12. 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

当软件开发需求的变化而变化时，软件设计会出现坏味道，当软件中出现下面任何一种气味时，表明软件正在腐化。
1. 僵化性：很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其它改动。
2. 脆弱性：对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。
3. 牢固性：很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。
4. 粘滞性：做正确的事情比做错误的事情要困难。
5. 不必要的复杂性：设计中包含有不具任何直接好处的基础结构。
6. 不必要的重复性：设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。
7. 晦涩性：很难阅读、理解。没有很好地表现出意图。

 

 

敏捷测试是遵循敏捷宣言的一种测试实践：
1、强调从客户的角度，即是从使用系统的用户的角度，来测试系统。
2、重点关注持续迭代的测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。
3、建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。

 

敏捷开发的最大特点是高度迭代，有周期性，并且能够及时、持续地响应客户的频繁反馈。敏捷测试即是不断修正质量指标，正确建立测试策略，确认客户的有效需求得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。敏捷测试人员因而需要在活动中关注产品需求，产品设计，解读源代码；在独立完成各项测试计划、测试执行工作的同时，敏捷测试人员需要参与几乎所有的团队讨论，团队决策。

 

敏捷测试与普通测试的区别:

1.项目相当于开发与测试并行，项目整体时间较快。
2.模块提交较快，测试时较有压迫感。
3.工作任务划分清晰，工作效率较高。
4.项目规划要合理，不然测试时会出现复测的现象，加大工作量。
5.发现问题需跟紧，项目中人员都比较忙，问题很容易被遗忘。
6.耗时、或较难解决对项目影响不大的问题一般会遗留到下个阶段解决。
7.发现BUG能够很快的解决，对相关的模块的测试影响比较小。
8.版本更换比较勤，影响到测试的速度。
9.要多与开发沟通。
10.要注意版本的更新情况。
11.测试人员几乎要参加整个项目组的所有会议。

 

敏捷实践：

敏捷就是一些实践的集合，需要根据项目的具体情况进行选择和修改成适合本项目的一套实践。
Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。

 

敏捷方法之极限编程(XP)和Scrum区别：
区别之一： 迭代长度的不同
XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周.
区别之二: 在迭代中, 是否允许修改需求
XP在一个迭代中，如果一个User Story(用户素材, 也就是一个需求)还没有实现， 则可以考虑用另外的需求将其替换， 替换的原则是需求实现的时间量是相等的。 而Scrum是不允许这样做的，一旦迭代开工会完毕, 任何需求都不允许添加进来，并有Scrum Master严格把关，不允许开发团队收到干扰
区别之三: 在迭代中，User Story是否严格按照优先级别来实现
XP是务必要遵守优先级别的。 但Scrum在这点做得很灵活， 可以不按照优先级别来做，Scrum这样处理的理由是： 如果优先问题的解决者，由于其它事情耽搁，不能认领任务，那么整个进度就耽误了。 另外一个原因是，如果按优先级排序的User Story #6和#10，虽然#6优先级高，但是如果#6的实现要依赖于#10，则不得不优先做#10.
区别之四:软件的实施过程中，是否采用严格的工程方法，保证进度或者质量
Scrum没有对软件的整个实施过程开出养个工程实践的处方。要求开发者自觉保证，但XP对整个流程方法定义非常严格，规定需要采用TDD, 自动测试， 结对编程，简单设计，重构等约束团队的行为。

 

角色
产品负责人 Product Owner： 负责维护产品订单的人，代表利益相关者的利益。
Scrum主管 Scrum Master： 为Scrum过程负责的人，确保scrum的正确使用并使得Scrum的收益最大化。一般不翻译。
开发团队 Team: 由负责自我管理开发产品的人组成的跨职能团队。
工件
产品订单 Product Backlog：按照优先级排序的高层需求。
冲刺订单 Sprint Backlog：要在冲刺中完成的任务的清单。
冲刺燃尽图 Burndown Chart：在冲刺长度上显示所有剩余工作时间逐日递减的图，因整体上总是递减而得名。
活动
计划会 Sprint Planning Meeting：在每个冲刺之初，由产品负责人讲解需求，并由开发团队进行估算的计划会议。
每日立会 Daily Standup Meeting：团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名。
评审会 Review Meeting：在冲刺结束前给产品负责人演示并接受评价的会议。
反思会/回顾会 Retrospective Meeting：在冲刺结束后召开的关于自我持续改进的会议。
其他
冲刺 Sprint: 一个时间周期（通常在2周到1个月之间），开发团队会在此期间内完成所承诺的一组订单项的开发。

 

用户故事：

敏捷开发，首先是基于用户故事的。在实际制定用户故事的时候，需要注意的是用户故事的粒度和其相对独立性。我们在实际执行中，往往会出现用户故事规模估计偏差大，或者故事做到一半发现依赖其他模块的情况。这些问题相信实际进行敏捷开发的同行们都会遇到。开发者往往会因为偏差大而贬低敏捷开发的管理作用，我们的原则是：先僵化、再固化、最后才灵活化。只有这样才能保证敏捷的正常推行。当一切步入正轨之后，再来谈改良的问题。当然对于偏差，我们也采取了一些措施，对评估用户故事规模的人形成反馈，使准确度逐步提高。

统一团队：

敏捷开发之所以敏捷，原因就是统一团队（个人理解）。统一团队包括了开发中各种角色的人员，包括SE、UE、UI、QT。这些人员在同一个团队中能很好的交流，就减少了出正式文档的时间成本，误解能第一时间得到纠正。实际执行过程中发现，虽然名义上是一个团队，但不同角色人员的立场不同，有时很难保证真正的“统一”。这就需要各个组的管理者真正站在项目的角度，给执行者更大的自由度，并且平时减少矛盾，多组织团体活动增进默契。

迭代化开发：

迭代化就是说将开发时间分成一个一个固定时间长度的小阶段，每个迭代完成相应的用户故事，新的需求与改动按照优先级情况排在下一个迭代以后。迭代化开发基本就是我们实际开发工作中执行敏捷理念的日常流程，与我们的开发工作有着非常密切的关系。每个迭代之初，会进行迭代计划，按照需求的优先级，由敏捷小组成员自己领取适合自己规模的故事。然后，进行用户故事澄清，分解用户故事为一个个精确到 人×天 或者 小时×天 的任务，方便管理者掌控进度。每个迭代完成的时候，会有一个迭代回顾会议。迭代回顾会议上，总结完成的故事点数，演示这个迭代的成果，听取组内成员的意见，以持续改进，增进默契。刚开始推行时，每轮迭代回顾会议上会发现许多问题。而会议本身只能暴露问题，并不能解决问题。所以我们在每次迭代回顾会议上，会制定一个迭代改进计划，并在下一次迭代回顾时，对上一个迭代制定的迭代计划的进展情况进行汇报。个人感觉这种方式，取得了较好的效果。

状态栏的维护：

为了将迭代化开发的进展情况更直观让领导者清楚。我们会将每个迭代的计划完成故事、分解成的任务以及各故事和任务的状态贴到一张白板上展示。每日敏捷小组成员进行站会，回顾前一工作日所做工作，今天计划要做的工作，遇到的问题和风险，会后更新状态栏，确认哪些工作计划做，哪些工作正在做，哪些工作已经做完。整个组的情况，最后会形成一个燃尽图，以反映这个迭代的剩余工作量再逐步减小，直到迭代结束，理想情况下燃尽图应该“燃尽”。实际过程中，往往出现状态栏更新不及时，本来应该给领导者表现好的情况，结果让领导者更郁闷。。。好的做法是每轮迭代专人负责跟进状态栏更新情况，做到及时。另一个问题就是燃尽图上涨与燃不尽的问题。少量上涨和剩余工作量小的情况属正常，主要是因为预估工作量偏差或者遇到了其他紧急的事情影响了进度。这要根据具体情况具体分析，不过出现好几轮迭代燃不尽的情况，需要引起管理者重视，及时分析原因，防止情况恶化。我们组就出现过初期没有引起很高的重视，导致后来燃尽图到迭代结束时还没过半的情况。

 

参考：

百度百科

http://www.cnblogs.com/qq78292959/archive/2011/07/25/2116119.html