加载中…
正文 字体大小:

对于敏捷开发的误读

(2010-03-06 20:04:50)
标签:

杂谈

分类: 团队管理

最后修改:Monday, April 26, 2010 5:04 AM

敏捷开发,在当下也算是个时髦话题,虽然其发展也已很多年了。但是对于新手甚至于用过几年的人来说仍然存在着一些不同程度上的误解。

1.敏捷开发将比以前的开发方式开发时间更短。

敏捷开发并未做出如上承诺。敏捷Agile一词描述的是软件或项目本身对于需求的变更可以从容迅速的适应。在刚接触敏捷开发的时候,过去的项目经理随口问我敏捷开发和我们以前的开发方式有什么区别?这里稍微讲解一下我们两个曾经共事过的一个团队,一个在国内颇有名气的网络服务商,主要业务是网络营销,包括代理Google和Baidu的关键字等业务。该公司也有一支网建部门,当时约40人,分为数个小团队对客户进行定制化的企业网站开发。开发流程如下:公司内部有一套用了很多年的asp模板(说的好听点叫模板,难听点就是将这个网站的程序按照需要复制到新项目中,再稍作修改)。从业务上来讲确实很迅速,对于一些小客户,程序员甚至可以一天"开发"一个。

当项目经理问我的时候我确实不知道该如何回答,虽然能够感觉到敏捷开发绝对不止是这样。那这样复制修改岂不是比敏捷开发更快很多?随着学习的加深,我开始深刻理解到敏捷开发并不是让我开发速度更快。而且过去的开发方式事实上称为"部署"-"维护或二次开发"更合适。

2.敏捷开发对于开发人员的能力要求比传统开发方式低,所以门槛也低。

一些开发团队认为自己能力并不强,所以选择敏捷开发的方式比较好。事实正相反。

3.敏捷开发不需要事先设计

经验丰富的架构师和开发人员可以使项目从开始就更接近于成功。

4.敏捷开发适合比较小的团队

并非如此,这只是管理问题。

5.鼓励所有开发人员都有权限修改源文件。

这个不是误解,但是在很多团队中却不允许这样做。在写下这篇文档的时候,所在的开发团队即是如此。该团队既无敏捷开发的思想也没有传统开发的严谨,对于代码使用一个简单的工具进行复制再加以修改,并将此流程美其名曰Bug Fix,严格禁止任何人对代码的优化或重构,除非用户发现问题。对于该团队的失败,我归结为缺乏有经验且严谨的架构师及技术总监。很多文件都是几千几万行,一些方法本身都超过几千行,拥有几十个参数的方法很常见,最多达到100个左右的参数。对于这样的代码,即使有数年开发经验,依然有如大海捞针。

曾子曰:"吾日三省吾身"。不论省的内容是什么,在软件开发中,重构就是这样一个过程。而且在新的迭代开始之前先进行重构可以更好的支持你接下来的工作。重构的目标是"改善既有代码的结构",理论上说重构不会也不应该更改接口,至少不应更改可控范围之外的接口(当你重构一个内部组件的时候,如果能够保证所有调用之处都能得到更新那么视为可控范围内。对于公开给其他开发团队的接口可能需要通知更新并保持一段时间的兼容期,通常情况下,保留旧的接口,标记为过时的并提供替代接口的提示,待缓冲期过后,全面废除老接口。而对于开放给更大范围的公众的接口则要困难得多,通常会提供比情况二长的多的缓冲期,并提供一个长时间有效的帮助文档,同时对现有客户提供升级服务,有时甚至是免费的。严格的说,情况二、三已经脱离重构的范畴)。重构不会改变接口,也不应该改变程序的特性。但是在实际的过程中,如果因为对程序的修改造成了新的bug也是不可避免的。在上述的开发团队中,经常对于工作中更改代码带来的新bug进行严厉的责任追究,这是无意义的,且带有负面影响的。我们常常听到这样的话:我知道你的本意是好的,但是…;这个人虽然…,但是他本质还是好的。这些话的无意义之处在于暧昧的婉转的表达了原本想要表达的意思,并不会让人更容易接受。事实上,直接的指出向要表述的意思更重要,领导者的口才并非总是有作用。以上扯远了。一个开发者当其出于好意而对程序进行更改,应该得到支持并提供帮助,这种帮助包括可行性研究、结对编程、测试等措施。(至于有没有实质性的奖励这不在我讨论范围)对于重构结束后发生的问题除了在发布上或许需要回滚外,最重要的措施是对于这次重构产生的问题分析,是这次重构本身不可行还是仅仅是重构过程中发生的bug。如果重构本身不可行,那么回滚操作是必然的,将此次重构记录下并产生分析文档,对于不可行的原因进行归档,或许在日后可以解决,或许可以在下次类似的问题上避免。对于重构过程中发生的bug,不必急于回滚至前一版本,有时候成功就在不远处,但是因为一时的胆怯而放弃了提升的机会。面对这种情况,要分析好问题的原因,而不是马上进行指责。只要做好了版本的隔离,不要成为"愤怒的猴子"。在行政上,管理人员不应该对于一次这样的更改让开发人员自己承担责任,有时候在团队中会听到类似的话"出了问题你负责"。作为一个团队,让每一个开发人员有权修改代码就是使每个人平等地承担整个项目的责任。作为管理者还是应该鼓励开发人员科学的大胆的对项目进行重构。只要做好测试工作以及版本隔离,是可以最大限度的避免问题的产生的。

6.将项目分割成一小部分一小部分,就是迭代。

这样对迭代的解释是偷换概念,简单形象地比喻的话,只是将项目分割开来形成的周期是横向的。而迭代是纵向的,每一次新的迭代都以前一个迭代为基础呈螺旋上升状。

还记得高中的时候,我的母亲告诉我的英语复习方法,第一天花一小时背第一课的单词,第二天先花少量时间(也许15分钟)复习一下之前的内容,然后背第二课。之后每天都如此,在休息日对之前的所有内容做一个总的复习。

7.现在写成什么样并不重要,反正我们会安排一个专门的迭代来重构的。

拥有重构这样的强大工具并不是给你忽略目前开发质量的借口。你思考的越详尽,重构之时工作量越少。将主要精力放在何处是个平衡问题,按照80-20原则,用20%的精力将80的工作完成在前期,剩下的20%的优化放在后期。不过这只是个抽象概念,由于具体的开发人员水平高下以及项目提供方对于需求变更的频繁都将导致初次开发时达不到这个百分比甚至低于50%也是有可能的。这个属于正常现象。

0

阅读 评论 收藏 转载 喜欢 打印举报
  • 评论加载中,请稍候...
发评论

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 电话:4006900000 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有