[  /goto.php?  /1822.html]IT民工 or IT精英[/url] 2014年02月23日
      经过软件行业几十年的发展，软件系统变得越来越复杂，传统的软件工程理论使“软件危机”越来越严重。过长的开发周期、超出预算的开发成本、令人担忧的软件质量、频繁流动的开发人员、官僚的体系制度、迅速变化的市场环境等因素，让繁冗、笨重的软件开发过程越来越不能适应现实的需要，软件项目的失败率很高。敏捷开发就是在这种背景下应运而生的。敏捷是一种关注价值、消除浪费、以人为核心、迭代、循序渐进的开发方法。

       敏捷开发是一种面临迅速变化的需求快速开发的能力，它有四个核心思想：
       第一是强调面对面的沟通，也就是说沟通很重要，人和人的相互交流胜于任何流程和工具；
       第二是要把精力集中在可执行的程序上，可以运行的产品胜于编制综合性文档，也就是强调了原型、模型、Demo等的重要性；
       第三个是团队合作和团队激励，合作胜于谈判，敏捷开发能将需求、开发、测试等全部团队成员融合成一个整体，大家都是一条线上的蚂蚱；
       第四个是超强的适应能力，适应变化胜于按部就班，敏捷开发的特点就是快速；

       敏捷软件开发团队就好比一支橄榄球队：他们有明确的最高目标，而且每时每刻都朝着目标努力；他们熟悉最佳实践，高度自我管理，高度协作，高度灵活地面对各种挑战。大量的调查统计表明，敏捷开发确实大大提高了软件开发效率和软件质量，帮助软件企业提高了效益，并更利于个人的成长。
       敏捷开发能够缩短项目的反馈周期，因其将项目分成了若干个迭代周期，每个迭代周期结束都能立即反馈。且通过不断的沟通，还能减少理解上的偏差，配合反馈，减少误解，从而降低修正错误的代价。且每个迭代周期的结束都能接受验证，从而能快速的适应变化，及时的适应新的需求，保证产品的正确性。


敏捷开发流程

那么如何进行敏捷开发呢？敏捷开发的体系建设主要有如下五个方面：
       1、组织建设，也就是团队建设，建立以产品经理为主导，包含产品、设计、前后台开发和测试的团队，快速进行产品迭代开发；扁平化的团队管理，大家都有共同目标，更有成就感；
       2、敏捷制度，要找准适合自身的敏捷开发方式，主要是制定一个完善的效率高的设计、开发、测试、上线流程，制定固定的迭代周期，让用户更有期待；
       3、需求收集，这个任何方式下都需要有，需求一定要有交互稿，评审通过后，一定要确定功能需求列表、责任人、工作量等；
       4、工具建设，是指能够快速完成某项事情的辅助工具，比如开发环境的一键安装，各种底层的日志、监控等平台，发布、打包工具等；
       5、系统架构，略为超前的架构设计：支持良好的扩容性和可维护性；组件化基础功能模块：代码耦合度低，模块间的依赖性小；插件化业务模块：降低营销活动与业务耦合度，自升级、自维护；客户端预埋逻辑；技术预研等等；

       要推行敏捷开发，还有两个重要的角色不可缺少，那就是产品负责人和敏捷专家。

       敏捷开发中的产品负责人（Product Owner），即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员，一般可由产品经理担任，也可由熟悉业务的开发人员担任。产品负责人需要把握产品整体的需求功能列表，清楚每个需求功能和其所产生的业务价值。
      
       敏捷开发中的敏捷专家（Scrum Master），即熟悉敏捷开发模式及敏捷实施流程的人员，一般可由敏捷团队当中的开发负责人担任，部分能力很强且懂技术的产品经理也可担任这个角色，因涉及到工作量评估和分派等工作，最好都是由技术能力较强的人员担任。该角色需要接受敏捷开发模式的培训，要非常熟悉敏捷开发的流程。

敏捷开发流程当中有四个会议：

       迭代计划会议：在每个迭代开始前，由产品负责人讲解需求，并由开发团队进行工时估算的计划会议。 在会议上需要排列需求优先级；分析和评估产品需求列表的工时，并确定迭代目标。

       每日站会：团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名，团队成员通常会在会议上讲述如下3点内容：1) 昨天我做了什么；2) 今天我计划要做什么；3) 我遇到了什么问题，妨碍了我尽可能有效地工作。敏捷专家记录会议上提出的问题，但是不要在会议上讨论和解决问题，而是要会后在找相关人员进行讨论和解决。

       迭代评审会议：在迭代结束前给产品负责人及客户演示本迭代开发完成的功能并接受评价的会议。

       迭代总结会议：在迭代结束后召开的关于自我持续改进的会议，围绕如下三个问题进行讨论：1) 本次迭代有哪些方面做得好；2) 本次迭代在哪些方面还能做得更好；3) 下次迭代准备改进哪些方面。团队确定问题优先级，并讨论问题的解决措施，分配责任人进行跟踪。

       在日常的敏捷开发工作当中，产品负责人会维护一个按优先级排序的产品需求列表，在每次迭代开始的第一天，召开迭代计划会。产品负责人会挑选最高优先级的部分进行讲解。团队可就需求细节、完成标准等进行询问，并逐条估算工时，放入本次迭代的开发任务中，直至任务量饱和。一旦迭代开始，这些任务将不会发生大的发化。
      
       在迭代执行期内，团队将决定任务分配、所需的技术等，逐一完成任务。每天团队会进行一个简短的会议，即每日站会，沟通当前进度、下一步任务和当前存在的问题，以借助团队的力量解决。团队还维护一份任务执行进度列表，标示所有任务的剩余时间，以观察和预测所有任务是否会按期完成。
      
       在每个迭代的最后一天，团队会召开迭代评审会，邀请产品负责人、客户等参加，对已经完成的产品功能条目进行评审，后者做出判断并给出改进反馈。当天还会召开迭代总结会，对本次迭代的成功与失败之处做出总结，并在以后迭代中进行改进。

       敏捷开发的过程不仅仅是一个项目快速完成，而是对整个产品需求的高效管理；敏捷不仅仅是简单的快，而是短周期的不断改进、提高和调整；敏捷不仅仅是开发完成快速就上线，而是快速形成原型、全员测试反馈修改提高；敏捷不仅仅是一个版本只做几个功能，而是突出重点、果断放弃当前的非重点；敏捷不仅仅是随时增加需求，而是每个迭代周期对需求的重新审核和排序。

       1、重点明确，及时调整。通过分析需求的紧急性和重要性，做出优先级的判定，优先级排列没有重复；迭代中严格按照优先级顺序开发，即使最后时间不够，也能保证最需要的功能开发完成；每次迭代前重新调整需求的重要性，及时加入重要的业务需求和用户需求，将重要性不高的需求往后调整。

       2、倾听用户的声音。在迭代中充分关注已发布版本用户的使用反馈，并且主动联系用户了解，在当个迭代或下个迭代快速优化；通过对用户反馈的及时响应获得用户的认可和口碑。

       3、勇于创新、小步快跑。在迭代中勇于创新，快速实现创新想法，并在后续的迭代中不断优化。

       4、持续不断地发现问题，解决问题。通过团队在每日立会上做出的描述，测试和验证功能的开发程度，对于功能的实现第一时间给出反馈，并能快速调整，而不会像瀑布模式那样要等到开发末期才发现实现上的问题。

       5、持续提升整个团队的能力。专门的团队面向一个产品领域，持续优化用户体验和产品流程，通过迭代的持续保持团队的用户和市场敏感度，提高团队的产品意识，伴随业务而成长，获得更高的成就感。


       介绍到这里，相信大家已经对敏捷开发模式有了一定的了解，在现在这个SOA 和Web 2.0 当道的时代，迫切需要敏捷开发模式，然而实施敏捷的阻力主要在于人。因为敏捷的核心就是“以人为本”，人的问题上升到了企业管理、企业价值观和文化的层面。片面地关注具体实践是不会取得好结果的。所以说，敏捷决不是一个简单的软件开发过程。

        [  /goto.php?  /1822.html]IT民工 or IT精英[/url] 2014年02月23日
      经过软件行业几十年的发展，软件系统变得越来越复杂，传统的软件工程理论使“软件危机”越来越严重。过长的开发周期、超出预算的开发成本、令人担忧的软件质量、频繁流动的开发人员、官僚的体系制度、迅速变化的市场环境等因素，让繁冗、笨重的软件开发过程越来越不能适应现实的需要，软件项目的失败率很高。敏捷开发就是在这种背景下应运而生的。敏捷是一种关注价值、消除浪费、以人为核心、迭代、循序渐进的开发方法。

       敏捷开发是一种面临迅速变化的需求快速开发的能力，它有四个核心思想：
       第一是强调面对面的沟通，也就是说沟通很重要，人和人的相互交流胜于任何流程和工具；
       第二是要把精力集中在可执行的程序上，可以运行的产品胜于编制综合性文档，也就是强调了原型、模型、Demo等的重要性；
       第三个是团队合作和团队激励，合作胜于谈判，敏捷开发能将需求、开发、测试等全部团队成员融合成一个整体，大家都是一条线上的蚂蚱；
       第四个是超强的适应能力，适应变化胜于按部就班，敏捷开发的特点就是快速；

       敏捷软件开发团队就好比一支橄榄球队：他们有明确的最高目标，而且每时每刻都朝着目标努力；他们熟悉最佳实践，高度自我管理，高度协作，高度灵活地面对各种挑战。大量的调查统计表明，敏捷开发确实大大提高了软件开发效率和软件质量，帮助软件企业提高了效益，并更利于个人的成长。
       敏捷开发能够缩短项目的反馈周期，因其将项目分成了若干个迭代周期，每个迭代周期结束都能立即反馈。且通过不断的沟通，还能减少理解上的偏差，配合反馈，减少误解，从而降低修正错误的代价。且每个迭代周期的结束都能接受验证，从而能快速的适应变化，及时的适应新的需求，保证产品的正确性。


敏捷开发流程

那么如何进行敏捷开发呢？敏捷开发的体系建设主要有如下五个方面：
       1、组织建设，也就是团队建设，建立以产品经理为主导，包含产品、设计、前后台开发和测试的团队，快速进行产品迭代开发；扁平化的团队管理，大家都有共同目标，更有成就感；
       2、敏捷制度，要找准适合自身的敏捷开发方式，主要是制定一个完善的效率高的设计、开发、测试、上线流程，制定固定的迭代周期，让用户更有期待；
       3、需求收集，这个任何方式下都需要有，需求一定要有交互稿，评审通过后，一定要确定功能需求列表、责任人、工作量等；
       4、工具建设，是指能够快速完成某项事情的辅助工具，比如开发环境的一键安装，各种底层的日志、监控等平台，发布、打包工具等；
       5、系统架构，略为超前的架构设计：支持良好的扩容性和可维护性；组件化基础功能模块：代码耦合度低，模块间的依赖性小；插件化业务模块：降低营销活动与业务耦合度，自升级、自维护；客户端预埋逻辑；技术预研等等；

       要推行敏捷开发，还有两个重要的角色不可缺少，那就是产品负责人和敏捷专家。

       敏捷开发中的产品负责人（Product Owner），即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员，一般可由产品经理担任，也可由熟悉业务的开发人员担任。产品负责人需要把握产品整体的需求功能列表，清楚每个需求功能和其所产生的业务价值。
      
       敏捷开发中的敏捷专家（Scrum Master），即熟悉敏捷开发模式及敏捷实施流程的人员，一般可由敏捷团队当中的开发负责人担任，部分能力很强且懂技术的产品经理也可担任这个角色，因涉及到工作量评估和分派等工作，最好都是由技术能力较强的人员担任。该角色需要接受敏捷开发模式的培训，要非常熟悉敏捷开发的流程。

敏捷开发流程当中有四个会议：

       迭代计划会议：在每个迭代开始前，由产品负责人讲解需求，并由开发团队进行工时估算的计划会议。 在会议上需要排列需求优先级；分析和评估产品需求列表的工时，并确定迭代目标。

       每日站会：团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名，团队成员通常会在会议上讲述如下3点内容：1) 昨天我做了什么；2) 今天我计划要做什么；3) 我遇到了什么问题，妨碍了我尽可能有效地工作。敏捷专家记录会议上提出的问题，但是不要在会议上讨论和解决问题，而是要会后在找相关人员进行讨论和解决。

       迭代评审会议：在迭代结束前给产品负责人及客户演示本迭代开发完成的功能并接受评价的会议。

       迭代总结会议：在迭代结束后召开的关于自我持续改进的会议，围绕如下三个问题进行讨论：1) 本次迭代有哪些方面做得好；2) 本次迭代在哪些方面还能做得更好；3) 下次迭代准备改进哪些方面。团队确定问题优先级，并讨论问题的解决措施，分配责任人进行跟踪。

       在日常的敏捷开发工作当中，产品负责人会维护一个按优先级排序的产品需求列表，在每次迭代开始的第一天，召开迭代计划会。产品负责人会挑选最高优先级的部分进行讲解。团队可就需求细节、完成标准等进行询问，并逐条估算工时，放入本次迭代的开发任务中，直至任务量饱和。一旦迭代开始，这些任务将不会发生大的发化。
      
       在迭代执行期内，团队将决定任务分配、所需的技术等，逐一完成任务。每天团队会进行一个简短的会议，即每日站会，沟通当前进度、下一步任务和当前存在的问题，以借助团队的力量解决。团队还维护一份任务执行进度列表，标示所有任务的剩余时间，以观察和预测所有任务是否会按期完成。
      
       在每个迭代的最后一天，团队会召开迭代评审会，邀请产品负责人、客户等参加，对已经完成的产品功能条目进行评审，后者做出判断并给出改进反馈。当天还会召开迭代总结会，对本次迭代的成功与失败之处做出总结，并在以后迭代中进行改进。

       敏捷开发的过程不仅仅是一个项目快速完成，而是对整个产品需求的高效管理；敏捷不仅仅是简单的快，而是短周期的不断改进、提高和调整；敏捷不仅仅是开发完成快速就上线，而是快速形成原型、全员测试反馈修改提高；敏捷不仅仅是一个版本只做几个功能，而是突出重点、果断放弃当前的非重点；敏捷不仅仅是随时增加需求，而是每个迭代周期对需求的重新审核和排序。

       1、重点明确，及时调整。通过分析需求的紧急性和重要性，做出优先级的判定，优先级排列没有重复；迭代中严格按照优先级顺序开发，即使最后时间不够，也能保证最需要的功能开发完成；每次迭代前重新调整需求的重要性，及时加入重要的业务需求和用户需求，将重要性不高的需求往后调整。

       2、倾听用户的声音。在迭代中充分关注已发布版本用户的使用反馈，并且主动联系用户了解，在当个迭代或下个迭代快速优化；通过对用户反馈的及时响应获得用户的认可和口碑。

       3、勇于创新、小步快跑。在迭代中勇于创新，快速实现创新想法，并在后续的迭代中不断优化。

       4、持续不断地发现问题，解决问题。通过团队在每日立会上做出的描述，测试和验证功能的开发程度，对于功能的实现第一时间给出反馈，并能快速调整，而不会像瀑布模式那样要等到开发末期才发现实现上的问题。

       5、持续提升整个团队的能力。专门的团队面向一个产品领域，持续优化用户体验和产品流程，通过迭代的持续保持团队的用户和市场敏感度，提高团队的产品意识，伴随业务而成长，获得更高的成就感。


       介绍到这里，相信大家已经对敏捷开发模式有了一定的了解，在现在这个SOA 和Web 2.0 当道的时代，迫切需要敏捷开发模式，然而实施敏捷的阻力主要在于人。因为敏捷的核心就是“以人为本”，人的问题上升到了企业管理、企业价值观和文化的层面。片面地关注具体实践是不会取得好结果的。所以说，敏捷决不是一个简单的软件开发过程。