《敏捷开发理论探究》4500字（论文）

敏捷开发理论研究目录TOC\o"1-2"\h\u272471敏捷概念界定 139651.1敏捷软件开发 1219341.2敏捷开发的好处 218501.3敏捷开发精髓 2147651.4敏捷与瀑布开发的比较 348031.5敏捷开发价值观 395082Scrum介绍 421202.1Scrum简介 4303262.2如何进行Scrum开发 4291302.3Scrum实现的四大支柱 5184703Scrum在实际中的经验和教训 5241263.1力争获得公司高层的支持 5148183.2加强对员工的敏捷培训 5207023.3避免形式化Scrum 617184参考文献 6摘要：在当前移动互联网蓬勃发展的大潮中，用户的需求瞬息万变,企业面临着越来越多的问题和挑战。这些挑战集中体现在技术快速变革、市场竞争加剧、用户需求变化莫测。特别在软件开发领域，用户的需求变化快、系统的复杂度高、客户的交付标准高。自从二十一世纪初著名的"敏捷宣言"签署以来，敏捷开发至今已经进入近20个年头了。目前敏捷在行业内已经逐渐流行起来，越来越多的企业开始实施敏捷方法。敏捷理念和组织管理很大关系，因此敏捷的落地也是组织管理调整的机会。Scrum是一种主流的敏捷方法，目前在世界500强企业中的得到广泛应用。Scrum敏捷开发相对于瀑布开发能够更好适应需求变化的组织团队，其包含了预定义的角色过程框架，具有开发流程简单、人员沟通紧密的特点；其自组织自管理的理念，在团队协作、人员激励等方面有明显的优势。然而，Scrum包含实践少只有少，因此企业需要Scrum理念与工程实践相结合。关键词：敏捷开发；项目管理；Scrum1敏捷概念界定1.1敏捷软件开发敏捷，英文"Agile"，原意是敏捷的、灵活的、机制的。最早是由"敏捷软件开发宣言"中开始推广，宣言定义了敏捷的价值和原则。之后敏捷软件开发的框架不断的发展，目前两个最广泛被使用的是Scrum与Kanban。敏捷软件开发(AgileSoftwareDevelopment)，或者被称为敏捷开发，是自二十世纪九十年诞生的一种全新的软件开发方式，二十多年来在行业内已引起巨大变革。区别于传统的类似于工业生产流程的开发模式，敏捷更强调快速响应变化。它定义了有特定的术语和概念，更强调团队成员之间、团队和客户之间的紧密合作。通过采用多元的交流方式提高沟通效率排除理解偏差，然后通过小而快速的迭代，频繁交付新产品，以适应快速变革的市场。敏捷管理是在软件开发的基础上诞生了全新的项目管理方法，和传统教科书的项目管理不同，它可以应对快速的需求变化，更强调研究团队和业务专家的协作、面对面的沟通、频繁的版本交付、紧凑的端对，以及更重视人在整个团队中发挥的作用[8]。1.2敏捷开发的好处一是尽早快速交付。敏捷开发可以尽早交付，从而大大降低财务成本。助力产品上线，加速财务回款，提高投资回报率ROI。传统模式下一个项目要开发一年甚至多年才能正式发布，公司的前期持续投入巨大，财务压力大。使用敏捷开发后，可以根据客户的需求，先完成基本功能，然后根据客户反馈不断丰富和完善，这样每个版本的发布都有持续的现金收益，公司财务压力就大大减轻了。二是降低风险。敏捷开发可以不断试错，通过小迭代、小版本随时调整，及时了解市场变化和客户真实需求，识别出对业务至关重要的功能，然后调整软件开发方向，从而大大增加了产品成功的可能性，降低产品不适用的风险。一般情况下先开发出原型产品，用来检验市场，通常能少走弯路。很多公司一开始都是投入大量财力，花费数年时间开发出的东西，结果根本经不起市场检验。在大众创业的号召有，身边就有同学投入两百万开发了技能交换平台，虽然立意新颖，结果APP上线半年根本如人问津，前期投入血本无归。这就是没有采用敏捷开发获得及时反馈的的后果。1.3敏捷开发精髓一是迭代开发。迭代开发(IterativeDevelopment)是敏捷的核心概念。Iterative本含意是迭代，在科学领域就是重复反馈的过程。具体实施就是先快速发布一个可用但不完美的简约版本，然后持续优化产品，修改缺陷并增加新特性。通过频繁的发布，以及上次迭代的反馈的跟踪在此过程中并不断的调整和优化，最终交付近乎完美的产品。传统模式下，对于大的项目，比如伟大的曼哈顿或者阿波罗登月工程，如此巨大的工程，通常需要准备很久和预研很多年，实施很多年，逐步推进。区别于传统模式，大开发变成小迭代，每次迭代都是同样的流程。就如SpaceX发射猎鹰火箭一样，试验期内不断发射，不断改良，最终获取成功。二是增量开发。增量开发(incrementaldevelopment)是根据和客户的协商以及对客户交付承诺，在每个可发布版本中会包含一个新增完整功能或者是对已知问题的修复。迭代通常通过增量开发开区分和定义。开发团队必须拥有持续集成和自动化的能力才能快速识别增量的交付是否引入问题，及时反馈增量部分的质量和对既有功能的影响。1.4敏捷与瀑布开发的比较传统的瀑布开发模型以过程管理为核心，为了提高产品的质量需要对开发流程和开发规范进行严格限制规范和定义。瀑布开发模型将更多精力投放在需求调研计划安排上，并且在开发过程中对每个阶段的输出文档都有严格的要求。和瀑布模型不同的敏捷开发方法则更加灵活，它的口号就是拥抱变化，更多聚焦在于沟通和协作上。通过建立更加扁平化的组织架构，团队氛围更加活跃。然后在组织内开展高效的沟通，最终达到减少流程管理成本的目的。以人为中心，强调沟通是第一位的，客户深度参与产品开发，从需求收集到迭代验收，甚至在更加具体的会议上客户代表也可以参加。过程对客户透明，排除客户对产品的疑虑和不断提升用户体验，及时反馈客户的需求变更，最终提高了客户满意度。1.5敏捷开发价值观1.5.1个体和互动>流程和工具个体的积极主动、互动使人们合作共赢。个体与互动需要以平等的文化为基础。个体与互动的障碍是命令与控制的文化。在命令与控制的文化之下，人们处于压抑状态，聪明才智无法发挥。自我组织和动机是重要的，共同定位和开发，这样作业模式中的沟通是重要的。创建一个良好的沟通和协作的开发团队，优于一个孤立运行的专家团队。沟通是一个基本的概念。1.5.2可工作的软件>面面俱到的文档工作的软件背后是全局优化，详尽的文档背后很可能是部门墙。这样的文档形成过程漫长，而且花了很多时间在一些拿来推卸责任的内容上。工作软件比在会议中向客户呈现文件更有用并更受欢迎。最好的做法是和代码一起评论，保持外部文件的轻量化，而不是沉重的文件，后者需要花费很大的精力，且很快就会过时。1.5.3客户协作>合同谈判客户合作的障碍是不信任，以至于花了太多时间在工作量的计量上，反而无暇顾及价值和质量等。在软件开发周期的初始阶段，需求无法完全收集，所以最好直接涉及到付费客户、最终用户或者代理，以便在反馈的基础上逐步阐述和调整详细的需求。1.5.4拥抱变化>遵循计划遵循计划带来的是虚假的安全感，背后的担心是如果不遵循计划，自己的诉求将无法被满足。敏捷软件开发方法的重点是快速响应变化和持续发展。2Scrum介绍2016年的Scrum联盟会员调查显示，曾经只用在软件开发领域的Scrum和敏捷实践，在IT行业之外也取得重大进展，并在非技术行业中也获得认可。这项调查结果反映了目前的一种趋势——各类公司都在使用Scrum和其他敏捷框架来进行创新和保持竞争力。89%的受访者表示，在他们公司使用Scrum作为实施敏捷的方法。92%的受访者使用各种形式上的Scrum。Kanban是第二常见的，接下来就是Hybrid，然后是传统的瀑布模式。前三位的排名2015年是21%，在2016年已降至17%。2.1Scrum简介Scrum英文原本是橄榄球运动的一个专业术语，指在联合式橄榄球比赛中因轻微违例进入死球状态，由双方相互推挤争球。Scrum过程框架理论基石包括如下三个方面：一是透明性(Transparency)。透明度是指在Scrum软件开发过程中的各个环节和交付件，对于项目团队的所有成员保持高度可见，团队成员可以随时审查和监督整个过程资产和进度。这样也在某种程度上消除了作为管理层对于项目进度和风险的疑虑。二是检验(Inspection)。为了在Scrum项目开发过程中避免重大偏差带来的风险，需要在实践中频繁地检验过程，以确保和客户需求吻合，避免需求膨胀，甚至泛滥。同步不停的检验来及时识别偏差，移除或者规避风险，保持稳定和高质量的交付可用产品。三是适应(Adaptation)。如果测试人员测试或者验收的时候发现过程中某些功能不满足或者不能完全满足验收标准，那么项目团队便需要其进行及时调整，避免进一步的偏差。2.2如何进行Scrum开发一是在迭代未开始之前，先由产品负责人确定一个具有优先级的产品需求列表；二是团队成员根据需求列表，对每一项需求做出规划并增加StoryPoint；三是通过计划会议，团队从产品需求列表中抽取用户故事作为本次迭代任务，然后增加细节描述和验收标准，增加子任务，形成一个迭代任务列表；四是在团队开发Story的过程中，需要进行站会，汇报进度和识别风险，并更新SprintBurnDown燃尽图；五是当迭代的所有的用户故事都关闭，意味着迭代结束，这时需要进行评审会；六是回顾会，也称总结会，大家逐一发言，讨论本次迭代做的好和不足地方，指定改进责任人。2.3Scrum实现的四大支柱一是迭代开发。通常迭代的周期是固定的，Scrum团队一旦选择了迭代周期，那么在整个产品开发生命周期内，每个迭代长短都是相同和固定的。在Scrum敏捷开发模式下，通常开发周期分成以周为最小单位的周期，在每个迭代内都交付一些增量的可工作的功能。二是增量交付。增量就是一个迭代内用户故事的汇总，它意味着是从用户的角度可感知的功能。在sprint结束的时候，新的增量必须完成，无论产品负责人是否决定真正发布它，增量必须可用。三是自组织团队。区别于传统命令与控制式的以项目经理为核心的项目运作模式，团队只有执行任务的权利，Scrum团队却是一支自组织团队，强调人员的积极主动和沟通，团队的独立性强，有统一的口号和团队精神，具有完成任务的一切技能和方法，这样对团队成员的素质要求高，成员要持续学习和提高自己。在团队和项目内部，团队有权自主设计、计划和执行任务，实行自我监督和自我管理机制，主动监控项目过程和进度，预测和识别和规避风险，自主协商决定团队内的分工与协作。四是高优先级的需求驱动。迭代开发的时候，团队始终从产品需求列表最上层的需求着手，为客户和企业创造更大的价值。3Scrum在实际中的经验和教训3.1力争获得公司高层的支持由于Scrum的实施理论上是削弱传统的PM、开发经理、产品经理、QA经理的权限，因此在实践中各个层级的Manager是比较抵触。开发团队内有开发经理、QA经理，但是在Scrum引入以后，强调员工的自我管理，虽然个人的汇报路线没发生变化，但是作为开发经理和QA经理感觉权限被削弱。大家都主动去认领UserStory，每天的站立会议都能及时分享，遇到问题ScrumMaster也及时协调解决，组内的协助更加积极主动，这样需要经理协调的必要性就降低了。另外，开发经理和ProductOwner、QA经理经常缺席每日站会，虽然开发经理和QA经理作为团队成员有些时候也认领了UserStory，但是往往后续又重新分配给自己的下属，造成工作量统计和管理的混乱等。3.2加强对员工的敏捷培训由于之前公司请的外部咨询公司使用英文对大家进行了一周的培训，但是对于一个全新的术语的Scrum，由于语言和文化背景的差异，大家理解不到位，只停留表面含义，对于具体如何落地和实施也是一知半解，对于新流程和目前的工作模式的差异不理解，大家还是按照过去的模式工作和沟通。因此建议公司将来请中文Scrum专家进行培训，从理论到业界的最佳实践，并结合当面业务进行辅导。3.3避免形式化Scrum由于团队是跨地区的，ScrumMaster较难以推动各地的员工。很快每日站立会议就流于形式，很多时候有些团队成员固定缺席，甚至refinement甚至回顾会议都不参加，遇到这中情况ScrumMaster应该及时督促大家参加。参考文献[1]Highsmith，J.敏捷项目管理[M].北京：清华大学出版社.2010：7[2]DeanLeff