在一家以敏捷开发和咨询著称的公司工作了一年了,以下是我当前对敏捷的认识:
1. 敏捷宣言:
个体与交互 胜过 过程与工具
可以工作的软件 胜过 面面俱到的文档
客户协作 胜过 合同谈判
响应变化 胜过 遵循计划
以上是大家熟悉的四句箴言,但还有一句话也许常被忽略:“即,虽然右侧条目有其价值,但我们更重视左侧条目”。这句话也放在了宣言不显著的地方。宣言的官网背景是几位敏捷先贤讨论问题的画面,中间的大胡子应该是老马(Martin Fowler)。这副背景画颇有宗教油画的风格。
2. CMMI
一个叫德里克·布鲁克斯的人曾经领导开发过一个失败的大型计算机操作系统:System/360。他离开这个项目后写出了古典名著《人月神话》。接替布鲁克斯来擦项目屁股的人叫做瓦茨·汉弗里。汉弗里惊讶的发现这么大的项目居然没有正式严格的计划,不知道汉弗里到底经历的多少麻烦,他退休后加入了一个五角大楼开办的软件工程学院,在那儿他和同事们建立了软件成熟度模型(CMM),其中最有名的是其五个台阶:
台阶一:组织基本没做啥
台阶二:组织做一些计划,跟踪,配置管理工作,也讨论质量保证等话题
台阶三:组织为各种活动定义了过程
台阶四:组织有了准绳,活动可以跟踪和度量
台阶五:组织有持续改进的过程
有时,敏捷和CMMI被人们一起谈论作对比,从我对它们目前的了解来看,两者似乎没太多联系。而且CMM5的“持续改进的过程”似乎比“敏捷”还敏捷。
3. Scrum
我第一次真正对敏捷产生兴趣是两年前听说了这个词,随后参加了公司的Scrum的兴趣小组,也读了些Scrum的书,其中对这本印象深刻。有一阵子还傻乎乎的自己给自己写Backlog,Sprint和Story,还关注下Burning down chart。对于很多人,或许Scrum就是敏捷,敏捷就是Scrum。依我看来,Scrum像是CMM3 + 敏捷,或者是基于敏捷理念的开发流程。有趣的是:几乎每本Scrum的书和文章都要提到一鸡和猪的故事。Scrum之所以流行可能是其提供一整套可操作的过程,容易上手,如同方便面一般方便。但是教条的执行Scrum我看还真一点都不敏捷。
4. 极限编程(XP)
极限编程的名字起得颇有邪教的感觉。XP要比Scrum历史悠久,但没有Scrum那么流行。XP中的TDD和结对编程常常引起很大的争议。在我一年的XP实践中,我却很对这两个玩意产生了极大的兴趣。、
反感TDD的人往往是没有真正尝试过TDD的人,想玩玩TDD的最佳方式也许是跟一个熟悉TDD程序员结对一会儿。很多场合下,用TDD开发非常有趣并且能写出高质量的代码。但是任何时候都教调的使用TDD不一定能带来多大好处,测试代码也有维护成本的。
对于结对编程,大多数人都是很难理解的。有些拥有结对编程经验的程序员对它又爱又恨。结对最大的好处或许是知识传播,想学习某种技术时和一个高手结对是效率非常高的方式。新人加入团队,和老成员结对能非常迅速的进入状态。但是两个水平差异不大,但开发习惯迥异的人坐在一起结队是一种煎熬。一个经常发生的事情是:经过长时间无意义的讨论甚至争吵后,双方妥协写出一段折中的代码,这段代码仅仅是折中的而不是最好的代码。
5. 精益(Lean)
敏捷宣言已经发布十年了,已经不是新鲜玩意了。业界需要点新潮点的词汇。精益来自于丰田公司的生产模式。在朝鲜战争时期,丰田汽车公司为了为美军提供更多品种的汽车,来自丰田纺织公司的大野耐一根据以往的经验并通过不断的实践发明了丰田生产方式。这种生产方式在学术界被称为精益生产。精益生产中有不少实践跟一些敏捷开发实践不谋而合,如自动化,可视化等。但是生搬硬套精益思想中的一些理念到软件开发中多少有些别扭。
6. 敏捷实践
以下是我接触过的敏捷实践:
结对编程:尤其适合老人带新人,和老艺人传帮带很像,和高手结对真是职业生涯的幸事
TDD:有趣,值得尝试
站立会议:不错的交流方式,站会讲究简短不展开,有问题会后交流
故事卡:一种很有效的需求分析方式
故事墙:可视化项目进展,很有趣,但我个人认为作用不大
燃烧曲线:没感觉,或许客户喜欢看
回顾会议:回顾会议的召开需要些技巧,需要个好的主持方式,确实能暴露问题
Show Case:需要客户配合才有作用
重构:啥也不说了,最爽的事
迭代开发:讨厌僵化的迭代开发,迭代计划还是有弹性的好
看板方式:来自精益生产,能够取消迭代,减少浪费,赞
持续集成:见7
7. 持续集成
每当Build成功,就有小鸟唱歌;Build失败就是一声闷雷,团队中必须有人站出来为此负责。这种开发模式我去年才刚刚接触到,但恐怕我的职业生涯会离不开它了,我认为它是最有用的敏捷开发实践。甚至有些同事对持续集成的评价是持续集成就是敏捷。
8. 传说中的敏捷团队
传说中的敏捷团队,每个人都是多面手,沟通畅通,有效协作,共同成长并且持续改进,心心相通,众志成城,快速响应变化,为客户带来最大的价值。我相信这样的团队是存在的,因为我现在所处的项目团队已经让我看到了敏捷团队的雏形。
9. Martin Fowler
有幸和老马有了一次面对面的交流,和老马介绍了下我们的项目,但他也没有给出什么建议。
最后我问了两个问题:
我:您是我的偶像,请问我如何才能成为一个像您这样的软件开发高手?
老马:我无法回答,我不是开发者了,我只是个演说者。
我:项目中和客户交流,客户说你们不用搞太多测试和TDD之类,我们希望你们做的更快些,多实现功能为主。我认为我们的主要目的是为客户多交付价值,所以我们确实应该减少测试的力度,您怎么看?
老马:你需要权衡(Trade off),但在我看来写测试只会让我更快些。
10. 对敏捷的质疑
一篇对敏捷讽刺的帖子,的确,如果教条的使用一些敏捷实践恐怕没什么好处。在公司内部,也有很多质疑敏捷的声音,我想如果没有质疑和反馈来促使改进,敏捷就不是敏捷了。
11. 技术 > 任何方法论
我到现在还一直持有这个偏激的观点:软件开发不是工程而是艺术,开发者的技术水平决定了软件的水平。敏捷实践能够帮助优秀的发者们做的更好更快。但追求更高的技术才是软件开发的王道。
分享到:
相关推荐
敏捷测试请大家多多指导,根据自己实际经验写作!
关于敏捷开发的一本好书,不过是英文版的,希望能和大家分享
关于敏捷开发中的测试《敏捷测试最佳实践》
关于敏捷开发的Scrum方式介绍,详细了解Scrum
关于敏捷开发的26个心得.docx
CMMIV1.3中关于敏捷方法的注解[参考].pdf
最近抽出时间,看了一本关于敏捷的书籍,其中以生动的例子讲解了 scrum 的相关知识 , 让我映象很深刻,当然也受到了不少启发,在此,小弟不才,和大家一起分享下。 关于敏捷,这个大家百度一下就知道了,我就不废话...
关于敏捷测试的关于敏捷测试的关于敏捷测试的
关于敏捷开发如何保证软件质量的讨论!本文是基于敏捷之旅2012北京站的开放空间讨论所做出的总结。1.敏捷开发提高软件质量 本文是基于敏捷之旅2012北京站的开放空间讨论所做出的总结。 1.敏捷开发提高软件质量 ...
敏捷个人学习
敏捷开发基本概念,一些关于敏捷开发的基本概念的说明。如 敏捷宣言,敏捷开发和其他开发模型的比较,和适用性。
难得的一本关于敏捷落地指导的书,完全可以参照手册在团队中开始尝试敏捷
此外,本书还深入讨论了关于敏捷方法和用户体验设计之间的有争议的关系。 Cockburn讨论了为团队建立敏捷方法学这一实践上的挑战,解释了如何对方法学进行调整并持续地再创造,以及如何管理不完全的沟通。 第2版...
某大型公司关于敏捷流程及角色定义的PPT 是敏捷开发的宝贵实践总结
自己总结了一下关于敏捷开发中站会的注意点。
这个是我在网上找的 关于敏捷开发的东西 但是不知道怎么样说实话所以拿出来让大家一起看看 学习 有什么好的建议和资料可以大家一起学习的哦 呵呵
关于敏捷建模软件等 随着软件工程快速的发展和深入,软件需求分析以及软件需求管理逐渐成为 软件开发过程中非常重要的活动。需求分析的质量对后续的软件开发各阶段有着 深远的影响。面对客户日益复杂多变的需求,...
很好的关于敏捷开发项目的项目管理技术章节
1. 关于敏捷开发模式(历史,介绍,比较) 2. 敏捷宣言 3. Scrum详解 4. Scrum四种会议 5. Scrum三种角色 6. Scrum两种工具 7. Scrum中常见的问题
关于敏捷开发模式(历史,介绍,比较) 敏捷宣言 Scrum详解 Scrum四种会议 Scrum三种角色 Scrum两种工具 Scrum中常见的问题 以及在携程在驴妈妈的一些日常工作的经验