敏捷开发心得.doc

敏捷开发心得 敏捷开发，曾经对它的理解就是没有文档的快速开发。众所周知，写软件开发文档是一件很痛苦的事情，所以越来越多的人因为这点去使用敏捷开发。但是经过这一段时间的学习之后，我对敏捷开发有了一些新的理解。 首先，对敏捷开发下个定义，借用下百度百科的定义。简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 这个定义只从表面上解释了一下敏捷开发，没有具体说明怎样使用敏捷开发。下面讲一下我对敏捷开发的具体心得。 架构师的重要性 首先，敏捷开发对于个人能力的要求是十分高的，尤其是领导人的能力。领导者及架构师是个举足轻重的角色，需要有深厚的行业背景、创新能力，以及架构能力。一个好的架构师，必须能考虑到产品当前使用模块，产品可以继续发展的模块以及下一代产品的方向。只有考虑到这三种模块和特性，这样的产品才能保持长期的生命力。敏捷开发也强调拥抱市场变化，这对产品架构师提出了很高的要求——深厚的业务背景、创新能力、技术洞察力和架构思想。 不断加强自己的技能 敏捷开发对于个人适应变化的能力要求非常高，所以对于普通员工来说，就必须不断加强自己的技能。不断的关注优秀的技能和好的设计会增强敏捷能力，很多原则、模式和实践也可以增强敏捷开发能力。 结对编程 结对编程，简而言之，就是两个人同时坐在同一个电脑面前，一个人编程，另外一个人检查并给予一定的帮助，过一段时间可以交换工作。很多公司不愿意使用结对编程，因为这样得额外支付一倍工资。但是，结对编程也有它的优点。在工作效率上说，两个人同时工作就避免了单独工作时出现的没事上QQ聊天和浏览休闲网站的情况，这样会提高工作效率，结对编程一天的产出不一定小于两个人分别工作时的工作量。而且结对编程因为有另外一人的检查，出错率会大大降低。众所周知，错误发现的???早，系统维护起来所需要的代价越小。而且在我理解，这样还可以增加同事间的友谊，在工作其他方面会有意想不到的好处。 面对面交流 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。在十几或者二十几个人组成的大团队中，文档是一种比较合适的传递知识和交流的途径。而敏捷团队一般不会很多人（大团队实施敏捷时也会分成多个小的敏捷团队），所以大量的文档交流其实并不是很经济的做法。此时面对面的交谈反而更快速有效。 经常性的交付软件 经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。只要我们可以保证交付的软件可以很好的工作，那么交付时间越短，我们和客户协作就越紧密，对产品质量就更有益。虽然我们多次迭代，但并不是每次迭代的结果都需要交付给用户，敏捷开发的目标是让他们可以交付。这意味着开发小组在每次迭代中都会增加一些功能，增加的每个功能都是经过编码、测试，达到了可发布的质量标准的。 严格执行单元测试 所有编程人员都知道需要做单元测试，但是有多少人可以认真对待。很少人是真的想尽办法构建测试案例，大多数人都是应付了事。所以要认真对待单元测试，无单元测试的代码严禁提交。甚至于在条件允许的情况下，实施测试驱动开发。即先有单元测试，后有代码。 开发人员和业务人员天天在一起工作 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。软件项目不会依照之前设定的计划原路执行，中间对业务的理解、软件的解决方案肯定会存在偏差，所以客户、需求人员、开发人员以及涉众之间必须进行有意义的、频繁的交互，这样就可以在早期及时的发现并解决问题。 轻文档但非无文档 敏捷开发强调沟通的重要性，而轻冗余文档。但敏捷开发并不意味着无文档。在敏捷开发过程中，适量的文档还是很有帮助，有助于整理思路，加快沟通和讨论。以前我们都用需求规格说明书或者用例来编写详细的需求，敏捷使用用户故事来罗列需求。使用基于用户故事的需求分析方法时，仍可能需要原型和编写文档，只是工作重点更多的转移到了口头交流。 反省会议 每隔一定时间，团队成员应该对最近的工作进行反省，然后相应地对自己的行为进行调整。由于很多不确定性因素会导致计划失效，比如项目成员增减、技术应用效果、用户需求的改变、竞争者对我们的影响等都会让我们作出不同的反应。对以上这些变化，小组通过不断的反省调整来保持团队的敏捷性。 有组织的团队 大家都知道，最好的构架、需求和设计出自与自组织的团队。敏捷中有很多种实践，其中迭代式开发是主要的实践方法，而自组织团队也是主要的实践之一。在自组织团队中，管理者不再发号施令，而是让团队自身寻找最佳的工作方式来完成工作。 要形成一个自组织团队其实比较难。首先自组织团队的第一个