敏捷的最佳实践-1

第一部分：敏捷的实质

敏捷开发有益于个人发展

就 测试而言，测试人员就是好比一辆跑车里的唯一的驾驶员，项目就好比这辆跑车，测试人员需要及时修正行驶方向的偏差，确保这辆车在正确的道路上稳步前行。如 果，测试人员没有具备足够的责任心和领导力，只是人云亦云，恐怕这种测试要与不要没什么分别，敏捷项目的质量也更让人担忧，而敏捷也就失去了原有的意义。 因此，作为唯一的测试人员，他（她）将拥有对测试的所有权，计划、设计并且执行所有的测试工作。而也因为拥有了更多的主人翁精神，积极的工作热情，测试人 员勇敢的面对工作中的各种挑战，学习新的知识和努力培养自己的工作技能。敏捷无疑对个人发展产生了很大的推动作用。

敏捷团队中的每个人，需定时和团队的其他成员坐下来看看团队的整体进度，计划下一步工作，并一起探讨所遭遇问题的解决方案。也需适时的寻求团队中其他成员的帮助解决时下紧要的问题。通过频繁的合作与沟通，个人的协作能力、沟通能力也得到了较大的提高。

敏捷开发培养了个人的协作能力

与 传统开发不同，敏捷开发更加侧重以人为本，发挥人的积极性，以此提高团队的工作效率。真正实现以结果为导向的职场守则。作为团队的一份子，无论是测试、开 发人员，还是设计人员，他们都将为团队成败担当不可或缺的责任。团队是高度协作的团队，个人除了做好本职工作外，敏捷开发模式要求个人能够了解和争取更多 的扩展性的工作，也能帮助团队其他成员解决他们的遇到的各种独特问题，以加快实现团队的统一目标，即在更少的时间里生产出能够推向市场的可靠产品。

这里再次提及高度协作，笔者认为高度的团队协作主要表现为以下特点：

1. 团队成员积极分享经验，知识，自我培养所需技能和自我成长；

2. 团队成员相互帮助，愿意成为他人后备队员，随时做好准备投入新的战斗，因而保障了团队的高昂士气和强大的生命力。

3. 任 何决策是团队共同的决策，工作是团队共同的工作，团队工作的最后成果因而也是来自团队中每个人的辛勤培养和贡献。而团队的失败更是整个团队的失败，绝不会 是某个人的单方面的过失。这种荣辱与共，共生共息的信念将让团队的力量超过团队各个力量之和。同时，项目团队的工作效率在团队成员技能的提升和信念的巩固 中不断提高。

敏捷开发锻炼了个人沟通能力

我 们把团队看做一个高度协作整体的同时，不可忽视的是团队内部仍存在的各种矛盾，对这些问题的听之任之将破坏团队的凝聚力、生产力。这中间反映出来的很多问 题不是敏捷方式独有，但团队成员因为敏捷，学会了自己解决各种问题。而相应的沟通能力也随着问题的解决得到很大幅度的提高。

在 过去的项目经验中，我们不难发现种种人与人之间矛盾的产生。而经典的矛盾论也让我们不得不的接受，矛盾是永远存在的，但这并没有什么可怕。而是一旦我们发 现了矛盾的存在，就要迅速找到解决办法，这也是团队的相当重要的工作。尤其是在团队组建初期，团队开始采纳新开发模式时，锻炼团队解决如下矛盾的工作非常 重要：

• 测试人员是质量的工程师，开发人员是产品的缔造者，在对质量标准的认同上常有不一致（当然，传统开发也会产生）；

• UCD 的设计实时反应用户需要，但有时不能顾及代码的可实现性；

• 开发人员而却更喜欢用想当然的理解，和习惯的方式填写代码，甚至主观的抵制接受新设计思想和拒绝新类型缺陷的修复，因此与团队的整体目标、出发点产生分歧；

• 从整个项目组织结构看来，敏捷团队之间（一个项目通常有多个敏捷团队组成，各个团队有自己的侧重点）存在设计，开发的不一致性，这使得产品在整合阶段产生额外的成本。

正 如前面所论述，矛盾总是有能够解决的途径，敏捷项目的组织中用管理方式去干预是一种直接、快速的方式，而今天敏捷方法论者们更加推崇的是鼓励团队内部进行 很好的交流和沟通后自行解决。也正是通过不断加强团队间和团队内部的相互理解，不但矛盾得到很好的解决（解铃还须系铃人嘛），个人的交流和沟通技能也得到 了进一步提高。

敏捷开发培养了个人的创新意识

创 新能够为企业带来新发展契机，创造新价值，因此，创新对于企业还是个人而言都非常之重要。不断培养员工的创新能力、鼓励创新活动也是几乎所有企业的人才培 养战略之一。而敏捷开发恰恰就是要打破传统的模式，形成全新的敏捷开发、敏捷测试方法、实践和过程，并鼓励团队采用新技术和技术创新。因此，团队的每个人 需要能够创造性的工作，并乐于接受新事物，通过不断的改进、突破过时的做法，努力提高团队的工作效率，来适应产品的增量发展需要。

而也因为敏捷开发模式对于很多团队仍很陌生，在运用敏捷开发的过程中我们会遭遇许多新挑战、新困难。如何处理这些问题，解决方案本身就是无以借鉴的，自主创新才是唯一出路。

举 个例子，敏捷项目初期，产品停留在原型论证和底层架构初步设计中，产品功能不多，复杂度较小，一般的手动测试就可以将质量保障做好。产品的中后期，因不断 有新需求、新功能的加入，产品复杂度增大。团队倘若仍仅凭固有的手动测试方式来覆盖产品的各个功能、非功能点需求只恐怕是力不从心了。因此，考虑用自动化 测试来提高团队工作效率是可取的方法之一。但是，当产品发展到中后期，也没有富余的资源可以被抽取出来做自动化测试了。即使现招聘新人，也因为新人对产品 不了解，只怕自动化测试的效果也未如人愿。那我们是否应该在开发活动的初期就尝试自动化测试的设计、并自动化一部分功能测试呢？也未然，因为在产品开发初 期，产品的功能和界面的变动会比较大，自动化测试收入产出比异常低。因此，何时、何地、如何设计、运用自动化测试来帮助降低人力成本，提高测试效率是需要 我们大胆创新的。

敏捷方法的共性

虽然各种敏捷方法的名称、所需环境、适合的团队有很大差异，但是他们拥有相似、相同的以下几大特点：

• 拥抱变化（Embrace the change）

无 论是多么明智，多么正确的决定，也有可能在日后发生改变。因此，团队要能够充分理解我们的利益干系人（Stakeholder）和客户代表为什么经常提出 新的需求和设计要求，一句话，就是心中有数“唯一不变的是变化”。团队更要信任 利益干系人（Stakeholder）做出的每次决定和需求的调整都是将产品开发推向更正确的发展方向，新变化将进一步降低风险，实现团队最大化利益，理 解这是适应市场变化的必然行为。

而 在接受变化的同时，我们应该积极的向 利益干系人（Stakeholder）和客户代表反映实现活动中暴露出来的可能的设计缺陷和错误。在实际工作中，团队成员应该用优先级制度来划分事情和目 标先后顺序，在迭代周期内对于还没有最终决定的设计方案可以予以后来实现、测试，不用急于投入资源展开全面的开发、测试活动。这样一来，开发测试团队也会 人员也将更加适应，真正拥抱变化。

• 客户的参与（With Customer Representative on site）

首 先谁是客户（Customer），客户代表（Customer Representative） 呢？利益干系人（Stakeholder），或者我们可以理解为我们的客户（Customer），产品的最终使用者（End user），内部使用者（Insider），商业伙伴（Business Partner）。利益干系人（Stakeholder）作为团队中最了解业务（Business）的人物将帮助开发团队的快速达到目标和做出适时决策。 开发团队拥有很好的技术但在业务（Business）方面他们需要 利益干系人（Stakeholder）的帮助。而通常在敏捷的开发项目中，团队中的任何一个人若需要帮助时，只要简单的邀请大家参加一个 15 分钟会议，或一封邮件、一个电话便可以解决。

但 是，如果利益干系人（Stakeholder）各执一词怎么办呢？为解决这个问题，将 Product Owner 引入到讨论中来，作为 Product Owner 他可以作为是 利益干系人（Stakeholder）的代表，能够在分歧中做最后抉择。因此，通过这样的客户代表的参与，团队更好的了解了所做事情的价值和意义，其工作 效率也因而得到很大提高。

利益干系人（Stakeholder）能够帮助团队中的每一个人更好，更快的完成了工作，他们的直接参与成为了敏捷开发、敏捷测试的重要前提。

• 较少的文档（With less documents）

敏捷开发更重视生产出可用的产品而不是详细文档。而时常有发觉文档又是无论敏捷还是传统开发、测试不可或缺的一部分。笔者认为，传统开发的文档在敏捷开发里仍有大用，只是原来十来页的内容精炼到现在的一页半页。

敏 捷主义者相信文档不是最佳的沟通方式，他们鼓励通畅的交流和沟通，要求避免和减少陈词滥调和空头支票。尤其是复杂的文档说明只是增加了沟通成本，因而敏捷 开发、测试的文档不需要长篇累读，需要的是简洁，清晰。任何一段清楚的文字，甚至一张图片，照片，一封记录着会议记录的邮件都是我们认可的敏捷文档。因为 是无论是通过文字板书的文件还是其他的沟通方式和载体都是为了帮助团队进行更高效的交流和沟通。只有团队保持着沟通上、理解上的一致后才能够充分发挥出团 队最佳战斗力。但凡这是帮助团队有效沟通的方式，敏捷开发是不会放弃的。

• 最大化的生产力（Maximize Productivity）

敏 捷开发模式要最大化的提高团队的工作效率。无论是依靠剪除冗余的文档工作，还是提供民主的、通畅的沟通平台都是为了帮助团队能够集中有限的精力处理有意义 的问题。据调查，通常人会在两个、多个任务并行的情况下产生出出最高工作效率。而敏捷也恰恰使用了各种方法得到团队的最大生产力。

敏 捷开发的 Scrum 模式，要求在计划阶段，团队成员主动定制迭代周期的所有工作任务，因此，本身从团队开始迭代活动的那时起，已经在在多重工作的压力下紧张工作了。而在日常 的迭代生产活动里，各个成员需要当众简单汇报当天的工作进度和承诺下一个 24 小时的工作计划。因此，通过增加敏捷人员的工作的透明度，无形之中，团队成员的生产力进一步得到提高。

• 测试驱动开发（Test Driven Development）

测试驱动开发，是让开发人员在编写功能代码之前，根据对需求的理解先设计和编写单元测试代码。先思考如何对将要实现的功能进行验证，再考虑功能的实现。然后迭代的增加新功能的单元测试和功能代码编写，直到完成全部功能的开发。

• 自动化冗余工作（Automate the redundant work）

将团队成员从冗余的劳动中解放出来，无论是自动化的测试还是自动化工具的开发只要能够节约成本都是敏捷开发、敏捷测试的目标。

• 民主的团队（Democracy in team）

敏捷团队是一支民主的团队，团队关系是平行的，每个团队成员能够平等的参与讨论，决策。传统开发的垂直的官僚机构在敏捷开发中已是过时的。

• 尊重团队（Respect to team）

敏 捷团队的决定权交有团队自己，决定是团队统一制定。无论是产品设计方案还是产品的功能实现都是的最佳结果。团队脱离了任何一个成员的工作都是不完整的，所 以我们应当足够尊重其他成员的劳动果实和表达对其他成员的充分信任。尊重团队，尊重团队中的每一个成员都是敏捷开发的原则之一。

你敏捷了吗？

1. 项目中有利益干系人（Stakeholder）的参与

2. 团队拥有并且可随时执行的回归测试

3. 关注产品自身而不是冗余的文档

4. 项目开发拥有严格的源码管理、版本控制

5. 开发能够积极面对和响应项目需求变化

6. 团队作为整体直接担负项目责任

7. 能够自动化重复性的活动

   转载：http://blog.csdn.net/star890124/article/details/46459265