|
正如前面所论述，矛盾总是有能够解决的途径，敏捷项目的组织中用管理方式去干预是一种直接、快速的方式，而今天敏捷方法论者们更加推崇的是鼓励团队内部进行很好的交流和沟通后自行解决。也正是通过不断加强团队间和团队内部的相互理解，不但矛盾得到很好的解决(解铃还须系铃人嘛)，个人的交流和沟通技能也得到了进一步提高。项目管理者联盟
敏捷开发培养了个人的创新意识项目管理者联盟
创新能够为企业带来新发展契机，创造新价值，因此，创新对于企业还是个人而言都非常之重要。不断培养员工的创新能力、鼓励创新活动也是几乎所有企业的人才培养战略之一。而敏捷开发恰恰就是要打破传统的模式，形成全新的敏捷开发、敏捷测试方法、实践和过程，并鼓励团队采用新技术和技术创新。因此，团队的每个人需要能够创造性的工作，并乐于接受新事物，通过不断的改进、突破过时的做法，努力提高团队的工作效率，来适应产品的增量发展需要。项目管理者联盟
而也因为敏捷开发模式对于很多团队仍很陌生，在运用敏捷开发的过程中我们会遭遇许多新挑战、新困难。如何处理这些问题，解决方案本身就是无以借鉴的，自主创新才是唯一出路。项目管理者联盟
举个例子，敏捷项目初期，产品停留在原型论证和底层架构初步设计中，产品功能不多，复杂度较小，一般的手动测试就可以将质量保障做好。产品的中后期，因不断有新需求、新功能的加入，产品复杂度增大。团队倘若仍仅凭固有的手动测试方式来覆盖产品的各个功能、非功能点需求只恐怕是力不从心了。因此，考虑用自动化测试来提高团队工作效率是可取的方法之一。但是，当产品发展到中后期，也没有富余的资源可以被抽取出来做自动化测试了。即使现招聘新人，也因为新人对产品不了解，只怕自动化测试的效果也未如人愿。那我们是否应该在开发活动的初期就尝试自动化测试的设计、并自动化一部分功能测试呢?也未然，因为在产品开发初期，产品的功能和界面的变动会比较大，自动化测试收入产出比异常低。因此，何时、何地、如何设计、运用自动化测试来帮助降低人力成本，提高测试效率是需要我们大胆创新的。项目管理者联盟
敏捷方法的共同点项目管理者联盟
以上我们通过商业、个人发展两个方面讲述了敏捷开发的价值和意义。那什么才是敏捷开发呢?在业界又有那些方法是敏捷开发的具体实现呢?各种方法有什么共同点吗?通过下文对各类敏捷方法的共性分析，我们也将进一步了解敏捷的实质。项目管理者联盟
敏捷方法项目经理博客
业界流行的敏捷开发的方法有许多(要了解各类敏捷方法和分类请参阅本文参考资料中文献)，我们需要根据项目大小，性质来选择合适自己的敏捷方法。比如说 XP(极限编程，eXtreme Programming)更加适合小型项目 3-5 人的团队。Scrum，DSDM (Dynamic Systems Development Methodology) 等更加适合大型团队的项目开发。而敏捷开发也不是一成不变放之四海皆准的准则，而是一个方法的最佳实践。各个团体和企业也不断定制着自己的最佳游戏规则。VersionOne 的敏捷开发的调研报告中很好的对比了各个方法被业界采纳的比例(见下 图 3)。这个图表就是 2007 年对来自 71 个国家 1700 多人的调查结果的说明。项目管理者联盟
项目管理者联盟
图 3. 流行的敏捷方法talent.mypm.net
除了图例中的方法外还有 Crystal, Lean Software Development, Feature Driven Development, Xbreed, RUP 等等。项目管理培训
敏捷方法的共性项目管理者联盟
虽然各种敏捷方法的名称、所需环境、适合的团队有很大差异，但是他们拥有相似、相同的以下几大特点：项目管理论坛
拥抱变化(Embrace the change)service.mypm.net
无论是多么明智，多么正确的决定，也有可能在日后发生改变。因此，团队要能够充分理解我们的利益干系人(Stakeholder)和客户代表为什么经常提出新的需求和设计要求，一句话，就是心中有数“唯一不变的是变化”。团队更要信任 利益干系人(Stakeholder)做出的每次决定和需求的调整都是将产品开发推向更正确的发展方向，新变化将进一步降低风险，实现团队最大化利益，理解这是适应市场变化的必然行为。项目管理者联盟
而在接受变化的同时，我们应该积极的向 利益干系人(Stakeholder)和客户代表反映实现活动中暴露出来的可能的设计缺陷和错误。在实际工作中，团队成员应该用优先级制度来划分事情和目标先后顺序，在迭代周期内对于还没有最终决定的设计方案可以予以后来实现、测试，不用急于投入资源展开全面的开发、测试活动。这样一来，开发测试团队也会人员也将更加适应，真正拥抱变化。pmp.mypm.net
客户的参与(With Customer Representative on site)项目管理者联盟
首先谁是客户(Customer)，客户代表(Customer Representative) 呢?利益干系人(Stakeholder)，或者我们可以理解为我们的客户(Customer)，产品的最终使用者(End user)，内部使用者(Insider)，商业伙伴(Business Partner)。利益干系人(Stakeholder)作为团队中最了解业务(Business)的人物将帮助开发团队的快速达到目标和做出适时决策。开发团队拥有很好的技术但在业务(Business)方面他们需要 利益干系人(Stakeholder)的帮助。而通常在敏捷的开发项目中，团队中的任何一个人若需要帮助时，只要简单的邀请大家参加一个 15 分钟会议，或一封邮件、一个电话便可以解决。service.mypm.net
但是，如果利益干系人(Stakeholder)各执一词怎么办呢?为解决这个问题，将 Product Owner 引入到讨论中来，作为 Product Owner 他可以作为是 利益干系人(Stakeholder)的代表，能够在分歧中做最后抉择。因此，通过这样的客户代表的参与，团队更好的了解了所做事情的价值和意义，其工作效率也因而得到很大提高。项目管理者联盟
利益干系人(Stakeholder)能够帮助团队中的每一个人更好，更快的完成了工作，他们的直接参与成为了敏捷开发、敏捷测试的重要前提。项目管理者联盟
较少的文档(With less documents)项目管理者联盟
敏捷开发更重视生产出可用的产品而不是详细文档。而时常有发觉文档又是无论敏捷还是传统开发、测试不可或缺的一部分。笔者认为，传统开发的文档在敏捷开发里仍有大用，只是原来十来页的内容精炼到现在的一页半页。项目管理者联盟
敏捷主义者相信文档不是最佳的沟通方式，他们鼓励通畅的交流和沟通，要求避免和减少陈词滥调和空头支票。尤其是复杂的文档说明只是增加了沟通成本，因而敏捷开发、测试的文档不需要长篇累读，需要的是简洁，清晰。任何一段清楚的文字，甚至一张图片，照片，一封记录着会议记录的邮件都是我们认可的敏捷文档。因为是无论是通过文字板书的文件还是其他的沟通方式和载体都是为了帮助团队进行更高效的交流和沟通。只有团队保持着沟通上、理解上的一致后才能够充分发挥出团队最佳战斗力。但凡这是帮助团队有效沟通的方式，敏捷开发是不会放弃的。项目管理者联盟
最大化的生产力(Maximize Productivity)项目管理者联盟
|
