本文作者:sodme
本文出处:http://blog.csdn.net/sodme
声明: 本文可以不经作者同意, 任意复制, 转载, 但任何对本文的引用都请保留文章开始前三行的作者, 出处以及声明信息. 谢谢.
引言:
“实践、总结,再实践,再总结”,我的很多研发观念,都是在这样的过程中不断形成和改进的,而我之所以能坚持这样不断作下去,是因为我想把一件事不断的作得更好,一直逼近我自己想要的极致。而事实上,因为每位开发者所在的领域、所掌握的工具、所面对的客户都可能有所不同,采用不同的开发方式本身就是非常自然而然的。其实,我的这个系列文章,有一部分是在说研发,而更重要的一部分是在说我们应该以什么样的思想、什么样的态度,以及什么样的方法来作事,而无论“这件事”是研发,还是销售,是产品,还是公司,我想,很多的东西,都同样适用。经过前面一虚一实的两篇文章后,下面引出的这篇文章仍然偏向于“虚 ”,仍然偏向于方法论,至于对大家有没有用,要看大家思考的深度和探索的力度。
正文:
"敏捷开发"中的"敏捷"二字, 其最本质的含义是: 对用户需求的快速响应. 而其产生, 发展乃至壮大的前提是: 随着信息化进程的不断推进, 有信息化需求的企业和用户, 也在不断提高自己提出IT需求的能力, 他们的需求不仅越提越专业, 而且, 也越提越快, 经常变化和更新. 作为一个系统实现者, 作为这个商业生态圈的服务提供者, 你无法否决用户提出的需求, 你所能作的, 很多的时候, 也最多是建议用户多给你点时间来完善, 让用户多交点钱. 而你, 该作的, 还是要作. 推而论之, 在这种情况下, 谁家能更快更好的响应用户不断变化的需求, 谁就能争取到用户.
从本质上说, 敏捷开发, 是一种非常务实的开发方式. 这种"务实"可以通过以下方面表现出来:
1. 它强调对于用户不断变化的需求一定要尽快的快速响应, 虽然用户需求的频繁更改是让开发者最为恼火的, 但是, 没办法, 作为一个商业行为, 无论你的用户提出什么修改需求, 你都要尽量满足, 只有这样你才能争取到用户, 才能让项目带来利润.
用户关注的是"他自己是否能用这个系统给自己带来好处", 用户始终不会关心"开发者因为这项修改将付出多大的代价". 虽然不近人情, 但作生意就是这样.
2. 敏捷开发的兴起, 是因为创建者们发现很多用户的很多需求在很多的情况下是无法事先全部预想好的, 是在开发过程中不断完善起来的. 传统的瀑布开发模型, 强调在开发之前先建立完整以及完备的开发计划和开发内容, 强调"先规划再开工", 是一种先全部计划好了, 然后再按步就搬进行操作的方式. 而敏捷开发, 更相信世界上根本不存在多么周详的计划能把所有的事情在事前全部计划好, 它相信, "需求变更本身就是需求存在的一种形式".
所以说, 传统的瀑布开发模型与敏捷开发模型相比较, 在形式上, 可能是一个先全面计划再执行, 而另一个是先计划一部分然后即刻开工, 在开工中不断完善; 但是在本质上, 这两种开发模型却代表了两种完全不同的开发世界观, 甚至就是开发者的世界观的反应:
前者假设世界太美好, 假设自己太强大, 假设团队太牛B, 一切都能搞得定, 所以, 他们设想着所有的东西只要列得出来, 就能按计划完成;
后者假设自己并不强大, 假设团队也不是万能的, 假设用户需求肯定是会变化的, 假设用户本身还需要不断学习和提高, 假设用户自己可能都搞不清自己想要什么样的系统, 假设要想作出用户想要的系统只有在作的过程中与用户不断交流与确认, 假设这种交流是不可能一次性完成而是一项长期的任务, 长期到甚至在软件交付了以后也仍然需要不断追踪用户需求的最新变更.
瀑布开发, 假设世界是无限美好的, 一切尽在掌控中; 而敏捷开发, 则假设世界本身是有缺点的, 而且, 有不少东西是我们只能影响但掌控不了的. 相比较而言, 敏捷开发的开发思想就要来得更为务实和坦率.
在瀑布模型中, 一旦发生需求变化, 给项目带来的风险是巨大的. 而如果不变, 那很可能作出来的东西就不是用户想要的东西, 那这个东西对于用户而言还有什么意义? 所以, 在瀑布开发模型中, 不管开发团队愿意不愿意接受需求变更, 这种变更的客观事实已经给项目本身带来太多的风险.
而敏捷开发呢? 是不是就没有瀑布模型的那些开发步骤: 需求提出-->需求冻结-->需求实现-->实现评估? 答案是否定的, 敏捷开发当然也会有这些过程, 但是, 敏捷开发对于瀑布模型最大的改进在于: 把瀑布模型中的大版本切成敏捷开发中的一个个小版本, 从而大大缩短软件发布小版本的时间周期, 始终坚持尽最快速度向用户提交一个最新功能的版本, 让用户在体验中不断与开发团队共同完善.
而不是象瀑布开发模型那样, 用户提出了需求后, 开发团队闷头作一两年, 发布一个很大的很全的但可能是不合用户本意的系统. 敏捷开发的发布周期通常是两周到两个月, 它不要求每次都要发布很多的内容, 但它要求最好要向你的最终用户频繁发布你的最新版本.
所以, 从这一点来看, 敏捷开发与传统开发, 最大的不同点正是在于"敏捷"二字, 而其对用户的具体表现就是: 用户可以拿到新版本的周期由一两年大大缩短到了两周到两个月。
分享到:
相关推荐
在本书中,享誉全球的软件开发专家和软件工程大师Robert C.Martin将向您展示如何解决软件开发人员、项目经理及软件项目领导...这本综合性、实用性的敏捷开发和极限编程方面的指南,是由敏捷开发的创始人之一所撰写的。
敏捷开发--用户故事参考.pdf
敏捷开发是一种以人为核心、迭代、逐步进行的软件开发方法论,强调灵活性和响应变化的能力。在"敏捷之道"中,我们深入探讨了敏捷开发的哲学、实践以及如何在实际项目中应用敏捷原则,特别是在 GTLD(可能是某个特定...
敏捷开发-敏捷软件开发:原则、模式与实践(全).pdf
通过以上步骤,我们可以看到敏捷测试不仅是一种测试方法,更是一种工作态度。它强调灵活性、持续改进以及团队之间的紧密协作。只有这样,才能确保软件产品能够在快速变化的市场环境中保持竞争力。
在这样的背景下,一种新的开发方法——敏捷开发应运而生。 #### 二、敏捷开发概述 敏捷开发是一种关注价值创造、减少浪费、以人为中心、迭代和逐步推进的开发方式。它强调灵活性、响应变化的能力以及团队成员之间...
敏捷开发-敏捷软件开发:原则、模式与实践 .net.pdf
3. 基本的敏捷测试原则、实践和过程 - 传统测试与敏捷测试方法的不同:传统测试通常在开发之后进行,而敏捷测试是迭代和并行于开发的。 - 测试和开发活动:在敏捷项目中,测试人员要与开发人员紧密合作,频繁进行...
敏捷开发工具 -- mingle 敏捷开发工具 -- mingle 敏捷开发工具 -- mingle
敏捷教练-如何打造优秀的敏捷团队
该书主要围绕“认识自我”和“管理自我”两个方面展开,旨在帮助读者提升自我管理能力,并采用敏捷思维来指导个人的成长和发展。 #### 二、个人敏捷结果系统 个人敏捷结果系统是一种结合了敏捷开发理念和个人成长...
在敏捷团队中,每个成员都应具备高水平的专业精神,这不仅是技术能力的表现,更是对待工作的态度和价值观的体现。 - **自动自发**:自动自发意味着团队成员能主动发现问题并寻求解决方案,而不是被动等待指令。这种...
Scrum敏捷方法一分钟扫盲 Scrum敏捷方法丨的工作产品 Scrum敏捷方法丨的觇色 猪不鸡的故亊 Scrum过程 读前预习内容 创建和维护产品待开収项(Product Backlog) 迭代计划会 产品负责人准备什么?...
- **支持价值观**:阐述了如何在实践中落实敏捷宣言中的价值观。 #### 总结 《敏捷软件开发》这本书不仅提供了一套新的软件开发方法论,更重要的是它改变了许多人对软件开发本质的看法。通过强调团队合作、快速...
11.敏捷回顾-团队从优秀到卓越之道, 注意1页2个图片,带目录,整理的PMI-ACP考试的第11本书。共12本
- **价值观**:敏捷个人借鉴了Scrum中的核心价值观,如勇气、开放、尊重等,这些价值观对于个人成长至关重要。 - **管理活动**:作者提出了一系列具体的管理活动,如每日反思、目标设定等,以帮助个人更好地进行自我...
【敏捷个人——认识自我,管理自我】是一种个人发展与自我管理的理念,源于敏捷开发思想,旨在帮助个体在快速变化的工作环境中提升效率、适应性和创新能力。敏捷个人的核心是将敏捷开发的原则应用于个人生活和工作中...
敏捷建模-极限编程和统一过程的有效实践
敏捷个人-认识自我,管理自我 v0.2 周金根大大的敏捷管理,非常不错,此为完整版!