2016-11-29 17:22:05 winnerwxc 阅读数 614
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10409 人正在学习 去看看 CSDN讲师

最近读了Bob大叔的《敏捷软件开发:原则、模式与实践》(下简称《敏捷》),有很多感悟,我觉得很多人对敏捷开发有一定的误解。

 

很多人推崇敏捷开发是因为他们觉得能提高开发速度。我觉得这是不正确的。敏捷开发的敏捷是Agile,这个词的意思是灵活的; 灵巧的; 轻快的; 机敏的; 和速度快没有什么关系。正如很多游戏中Agility和Speed完全是两个属性. 然而国内很多人因为种种利益,将敏捷开发鼓吹成了提高开发速度的神器.作为偷懒,规避文档、需求分析的借口.

 

正如科学上有许多守恒理论,例如能量守恒,元素守恒。软件开发其实也存在着类似的情况。在提高灵活性的情况下,开发速度应该是降低的。所以我觉得,敏捷开发会减缓开发速度。正如《敏捷》中的例子,为了完成功能,通常要编写大量的测试用例,并且敏捷开发也鼓励高频率的进行单元测试(可笑的是,有很多人将不正经八百的测试说成敏捷开发)。而且为了防止软件僵化,开发者通常需要不断思考,对已有代码进行调整。这些思考本身就需要花费大量的时间,而每次的调整又需要更多的测试,甚至需要改写测试用例。

 

诚然,敏捷开发也有提高开发速度的主张,比如放弃使用大而笨重的工具,减少学习工具的成本。但是我觉得和上述原因相比,总体上还是减慢了速度。

然而,我并不反对敏捷开发,我相信敏捷开发可以提升软件的灵活性与质量。但是这种提升大概率是提高开发成本的。想一想一个程序员说自己会把任务完成的又快又好的时候,大部分情况他是在吹牛,不是么。除了时间,另一项开发成本是开发人员的水平。敏捷开发其实有较高的门槛,为了保证灵活性,就需要你有较高的抽象能力;经常需要修改代码,就需要你有较高的重构能力。

 

读了《敏捷》后,我深深被这些编程实践所吸引.但是联想到现实,我觉得在现阶段,大部分公司是没有人力物力去完全践行敏捷开发的.比如编写测试用例,可能要花费数倍于功能的编码时间.可能我悲观了,我觉得大部分人只能是吸收敏捷的思想.只要不太"笨重"已经很不容易了.

 

别再轻易说自己是敏捷开发了.


2011-06-08 12:35:44 wengge1 阅读数 25
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10409 人正在学习 去看看 CSDN讲师
有的人对采用敏捷开发是否能真的有效提高效率并生产出成功的产品表示怀疑。他们认为,在敏捷方法中,由于没有经理的管理和约束,团队和项目必然是一团糟,仿佛越是上层越有这种想法。敏捷开发的理念是信任开发团队,信任每一个人。试想一下,如果你们这个团队对你们的项目充满激情,而老板又充分信任你们,那么你们必会将更多的时间花在如何有效地提高生产率、如何创新地完成某个功能等方面,而不是按老板的意思按部就班地工作了,这样还会节省很多时间并简化流程,例如开会、向老板报告、请示老板、等老板批准等。就像咱们刚才的那个游戏结果所揭示的那样,充分调动参与项目的人员的主动性,让他们自我组织、自我管理,由团队自身来掌握项目进度,比老板整天催促反而更有效率。
当然,敏捷开发的团队也需要管理,但这些管理是非命令式的,很多时候是战略指导和服务性质的。在敏捷开发中,管理者对团队和项目的管理表现在挑选合适的人、为团队创造一个开放而自由的工作环境、经常性的反馈、为团队建立评估和奖励机制、当团队有方向性错误时能及早发现并纠正、容忍错误的发生等
还有一种误解,认为敏捷开发就是完全不需要计划、文档和架构设计。这种看法也是不对的。敏捷开发也需要文档,也同样要计划。但我们要明白,计划赶不上变化,在这样一个不断变化的情况下要做出详细的计划是不可能的。因此敏捷方法认为不值得在这些因素上花费过多的资源,可工作的软件才是敏捷方法关注的重点。敏捷团队依靠变化来获取活力,他们更愿意使设计保持尽可能的干净、简单。基于以上的原因,采用敏捷方法的项目初始设计是比较粗略的,并需要使用许多测试手段作为辅助,这就保持了设计的灵活性和易于理解性。团队可以利用这种灵活性持续地改进设计,以便于每次迭代结束时的系统都具有最适合于那次迭代中需求的设计。摆脱一切对软件开发不合理的束缚就是敏捷。”
敏捷联盟的发起人Martin Fowler 和Jim Highsmith 曾经这样解释过:敏捷开发所追求的是一种平衡——我们也建模,但不仅仅是画几个模型图存放在少人问津的项目文档库里;我们也需要文档,但从不浪费纸张去编造那些极少使用而又没有保存价值的大部头;我们也做计划,但我们同时也认识到在这纷繁复杂的环境中做计划是困难的
但是,敏捷开发不是可以解决所有问题的银弹。在实际的项目中,受条件的限制,有些原则实施起来确实有困难,那该怎么办?要知道,敏捷并不要求你们一成不变地遵循这些条条框框,遇到困难时应该灵活地调整策略,这样才真正达到了敏捷的目的
2011-02-25 15:24:39 mykktian 阅读数 27
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10409 人正在学习 去看看 CSDN讲师
1,敏捷开发意味着可以不需要文档,设计和计划
2,敏捷只是一些优秀实践,或者是优秀实践的结合
3,敏捷只适用于小项目
4,敏捷只会对研发产生改变
5,引入敏捷只需要按照既定的步骤去做就可以了
6,敏捷是CMMI的替代品,是另一种流程
7,敏捷只注重特性的快速交付,在敏捷下框架不重要了
2009-03-30 09:44:00 shilogic 阅读数 862
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10409 人正在学习 去看看 CSDN讲师

我曾经参与一个软件产品开发,高层管理者(兼系统分析员)每天都有新的Feature源源不断地交给开发人员。而且要求在很短的时间内实现新Feature(往往就是一天)。

好处是高层管理者每天都能看到项目的进展(每天新功能都被加到产品里),但是开发人员压力巨大,疲于奔命,怨声载道。高层管理者说这是 敏捷开发。 因为产品每天都在“敏捷”地变化和前进。

 

真的是这样吗?

拥抱变化是敏捷开发的特征,并不是说想怎么变就怎么变。

 

敏捷开发中,特别强调软件设计的可扩展性,例如软件设计要符合开闭原则。

设计的时候要能预先考虑到某一个方向的变化,这样才能留出相应的接口,才能抽象出容纳变化的整体框架(往往表现为接口或者抽象类)。

 

如果发生了预先没有考虑过的方向上的变化,往往得重构代码,重构接口,抽象类,基类等,以容纳新的变化。这种重构在时间进度不是很敏感的情况下,项目技术负责人和开发人员有时间做重构,这没有问题。

但是现实情况往往是:

 1、进度压力很大,开发人员没有时间去重构。只能用打补丁的方法去容纳新的变化,在代码中往往就是在原来的代码里嵌入比较多的 if 条件判断语句。

 2、久而久之,if 语句越来越多,条件判断越来越复杂,程序结构越来越难以理解,等到即使有时间的时候,开发人员也不愿再去重构了。因为重构的难度太大了。

 3、重构和人的责任心,管理的控制力度,软件设计能力,甚至是人当时的情绪有关系。

  有很多情况下,限于时间和人力因素,可能没有人去review代码,那么程序的结构和代码的质量完全掌握在 写代码的人手里,如果这个人的责任心不强,或者 这个人当时的情绪被外界影响,或者软件设计能力不强,他就不会去重构代码,那么隐患就隐藏在里面了。

 4、管理人员市场人员只看功能和界面,不管程序内部的结构。

  的确,用户根本不管程序内部的结构,用户只管使用软件,但是软件的结构的影响却很深远,虽然一时半刻看不出来,但是随着用户使用的深入,需求的变化,结构混乱的程序维护成本急剧上升。并由此特定情况下数据不准确,用户的抱怨,人员流动,士气低落,不断地救火。所以从本质上看,程序的结构和客户,公司管理层甚至是公司的每个人的利益也密切相关,理解了这个道理, 对于不断地提出需求变化,并要求立刻响应的高层管理者,也应该对此三思而后行。

  5、每天不停地讨论和研究新Feature非常浪费开发人员的时间。

  在我参与的项目中,基本上每天都要花上午最宝贵的2-3个小时去讨论新需求,新Feature。严重占用了本应该用来开发的时间。造成不断地加班。

 

不论多么敏捷,必须要给开发过程一个阶段,即在一个阶段中(1周-1个月)之内,需求相对稳定,即使需求变化,也是在软件框架内可以 “容纳”的变化,而不是想怎么变就怎么变。

有了稳定的阶段,开发人员才有整块的时间去写代码和单元测试代码,去重构软件,而这才是提高开发效率,加快开发进度的关键。

 

2008-07-30 09:43:00 ibmjournal 阅读数 442
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10409 人正在学习 去看看 CSDN讲师

IBM® 敏捷开发实践领导者 Scott Ambler 在这个 Podcast 里阐述了敏捷开发这种迭代和增量的开发方法,展示敏捷开发的业务实例,并且澄清对于敏捷开发过程的一些误解。

Podcast 是什么? 了解更多

Podcast 内容简介

Scott Ambler,是 IBM Rational® 敏捷开发实践的领导者,他这样阐述敏捷开发:“一种以高度协作方式执行的迭代的和增量的(演进的)方法,在满足涉众不断变更需求的一定成本和时间下,产生高质量的软件。”在这段 20 分钟的播客中,Ambler 阐述了敏捷开发的含义,并着眼于为什么敏捷开发越来越有意义,并且越来越多地被采用。他与众多的传统软件开发方法进行了对比,并消除了许多常见的荒谬说法。

收听 (19:45) (点击收听或右键点击 另存为 进行下载)

阅读脚本阅读脚本英文原文


关于嘉宾请




本文转自IBM Developerworks中国

      请点击此处查看全文


 

对敏捷开发的误解

阅读数 479

没有更多推荐了,返回首页