敏捷开发个人体会和分享报告.docVIP

敏捷开发个人体会和分享报告 敏捷开发，曾经对它的理解就是没有文档的快速开发，先做原型，针对原型面对面交流，按照大家认可的原型再做快速开发，多次的面对面讨论原型，不断迭代原型，针对每次迭代的原型进行快速开发。众所周知，写软件开发文档是每一个程序员都懒于做的事情，认为比较痛苦的事情，所以越来越多的人因为这点去使用敏捷开发。但是经过培训学习之后，我对敏捷开发有了一些新的理解。 首先，对敏捷开发下个定义，借用百度百科的定义。简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 这个定义只从表面上解释了一下敏捷开发，没有具体说明怎样使用敏捷开发。下面讲一下我对敏捷开发的具体心得。 1、架构师的重要性 首先，敏捷开发对于个人能力的要求是十分高的，尤其是领导人的能力。领导者及架构师是个举足轻重的角色，需要眼观大图，并关注最终成果，这就要求领导者及架构师有深厚的行业背景、创新能力、以及架构能力。一个好的架构师，必须能考虑到产品当前使用模块、产品可以继续发展的模块以及下一代产品的方向。只有考虑到这三种模块和特性，这样的产品才能保持长期的生命力。敏捷开发也强调拥抱市场变化，这对产品架构师提出了更高的要求——深厚的业务背景、创新能力、技术洞察力和架构思想。 2、能够随时应对变化的结构，适应需求变化，并能驾驭需求变化 能够随时应对变化的结构，比遵循计划更重要。计划不要考虑太远，因为各种环境都在发生变化，随着软件的提交，需求也许会发生变化。完美的甘特图能够体现对项目的整体控制力，但是详细的甘特图也是不切合实际的。感觉一般做一周的计划，是最切合实际的。 3、尽早地、持续地交付有价值的软件来满足客户需求 经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时 间间隔越短越好。只要我们可以保证交付的软件可以很好的工作，那么交付时间越短，我们和客户协作就越紧密，对产品成果就更有益。虽然我们多次迭代，但并不是每次迭代的结果都需要交付给用户，敏捷开发的目标是让他们可以交付。这意味着开发小组在每次迭代中都会增加一些功能，增加的每个功能都是经过编码、测试，达到可以交付的标准。 4、严格执行单元测试 所有编程人员都知道需要做单元测试，但是有多少人可以认真对待。很少人是真的想尽办法构建测试案例，大多数人都是应付了事。所以要认真对待单元测试，无单元测试的代码严禁提交。“Y23理论”教导我们不要忽视细小的错误，如果不把细小的错误消灭掉，它会给你带来毁灭性的重创。 5、每日站立会议，面对面交流 各团队成员的工作相对比较独立，对其它成员的工作了解不多，不利于整个项目的发展，每个成员容易歇入研究的死胡同。所以在团队内部，每日站立会议、面对面交流是最具有效果并且富有效率的传递信息的方法。每日站立会议要求每个人必须定点进入会议状态。每日会议前每个人要更新自己的任务面板。每日会议中决定要签出的任务，并在会议后更新任务面板，并在任务便签上注明任务的签出人。 6、关注成果，把工作按照重要性和紧急性进行分类，权衡工作重点 团队成员围绕“眼观大图，关注成果”这一导向，把自己的近期工作按照重要性和紧急性进行分类，分为四类：1、重要、紧急 2、重要、不紧急 3、不重要、紧急 4、不重要、不紧急。根据四类情况对自己的近期工作进行权衡，把握工作重点，紧扣要事，使近期工作得以顺利开展，使远期工作也得以顺利进行。 现在社会工作的节奏越来越快，相信敏捷开发的使用者也越来越多。通过不断的对敏捷开发方法进行改善，我相信，以后不只那些中小型项目会使用敏捷开发，而且一些大的项目也会使用。总有一天，人们使用敏捷开发时会做到驾驭自如！