敏捷开发心得范文.doc

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