软件工程 敏捷的酒后问答

发表于:2012-05-07来源:SoftwareTeacher作者:SoftwareTeacher 标签:敏捷测试
王屋村移山公司的程序员果冻最近请假参加了一系列敏捷的培训, 有好事者传言他和 “a-girl”勾搭上了, 其他年轻同事有点坐不住了, 也表示要参加此类活动。 几天后, 果冻回到公司, 给所有人发了一枚写有 “Agile” 的胸章。 他纠正大家的发音, 这个词不是发 “a

  王屋村移山公司的程序员果冻最近请假参加了一系列敏捷的培训, 有好事者传言他和 “a-girl”勾搭上了, 其他年轻同事有点坐不住了, 也表示要参加此类活动。 几天后, 果冻回到公司, 给所有人发了一枚写有 “Agile” 的胸章。 他纠正大家的发音, 这个词不是发 “a-girl”, 而是“爱脚儿”! 果冻希望大家一起在公司里掀起一股爱脚儿的热潮, 把公司的软件工程质量从 CMM5 再提高一个档次。

  小飞给他讲了一个笑话:

  软件团队开会, 领导说: 我们要采用敏捷的开发流程. 很简单, 就是木有计划, 木有文档, 马上写代码, 随时发牢骚。

  工程师问: 培训有木有?

  领导说: 有, 刚才就是培训. 散会! 现在可以写代码和发牢骚了.

Dilbert.com

  以上图片从 dilbert.com 提供的链接得来

  果冻说, “我不觉得可笑, 我认为敏捷是瀑布模型发明以来的另一个巨大的进步。”

  大家笑完之后, 问那 爱脚儿模式到底是什么玩意儿? 能管用么? 能挣更多的钱么?

  果冻说, 大家稍等几天, 多种敏捷大会的 PPT 就上线了. 到时大家就敏了!

  晚上大家在顶球酒吧喝酒的时候, 碰到阿超, 于是就有这样的问答:

  问: 爱脚儿 - 敏捷到底是什么东东? 好像有很多名词, 缩写和传说…

image

  答: 敏捷 (Agile) 是一股思潮, 它包括了好几种软件开发的方法论 (methodology); 这些方法论又是建立在许多业界证明行之有效的最佳实践方法 (best practices) 上面的。 如图所示:

image

  问: 敏捷的思想是从天上掉下来的么?

  答: 不是, 是人们自己总结出来的。

  问: 敏捷的方法论有哪些?

  答: 比较有名的是:

  爱抚弟弟 (FDD)

  史克朗姆 (SCRUM)

  极限编程 (XP)

  问: 那比较有名的最佳实践是什么?

  答: 这就太多了, 你把任意三个字母组合一下, 说不定就是一个最佳实践, 例如 TDD (踢弟弟) 就是一个最佳实践。很多程序员老大哥都很喜欢踢弟弟。

  问: 为什么人们以前没有总结出来敏捷, 而是最近这几年才醒悟呢?

  答: 这个… 当原始人没有东西吃的时候, 为什么他们不知道吃方便面? 稍稍正经一点来说 - 有几个原因导致敏捷在互联网时代出现:

  最初的软件 (20 世纪60-70 年代) 的顾客都是大型研究机构, 军方, NASA 这些, 他们需要软件系统来搞科学计算, 军方项目, 和登月项目等, 这些系统相当庞大, 对准确度要求相当高。

  20 世纪 80年代到90年代中, 软件进入了桌面软件的时代, 开发的周期明显缩短, 各种新的方法开始进入实用阶段. 但是软件发布的媒介还是软盘, CD, DVD, 做好一个发布需要较大的经济投入, 不能频繁更新版本。

  互联网时代, 大部分的服务是通过网络服务器端实现, 在客户端有各种方便的推送 (push) 渠道. 由于网络的转播速度和广度, 知识的获取更加容易, 很多软件服务可以由一个小团队来实现。 同时技术更新的速度在加快, 那种一个大型团队用一个固定技术开发2-3 年再发布的时代已经过去了。 用户需求的变化也在加快, 开发流程必须跟上这些快速变化的节奏。

  问: 什么样的牛人一夜之间想出了这么多敏捷的东东?

  答: 首先, 很多方法已经在实践中运用了很多年, 不是牛人们一夜之间想出来的; 其次, 很多方法论把原来单个的实践方法结合起来, 运用到极致, 吸引了不少眼球。 不过, 一些牛人的确在几个晚上搞出了一个 “敏捷宣言”:

  2001年2月,17 位软件绿林好汉聚集在美国犹他州的滑雪胜地雪鸟(Snowbird)雪场。白天除了滑雪, 没啥鸟事; 晚上除了喝酒侃大山, 鸟没啥事… 但是他们都感觉世变时移, 变法宜矣。 经过讨论,《敏捷宣言》应运而生:

  敏捷思潮的价值观:

  Individuals and interactions over processes and tools

  个人和交互 重于 过程和工具

  Working software over comprehensive documentation

  可用的软件 重于 完备的文档

  Customer collaboration over contract negotiation

  和客户协作 重于 合同谈判

  Responding to change over following a plan

  响应变化 重于 遵循计划

  后者并非没有价值,只是我们更加关注前者。

  敏捷的原则中文版在这里。

  问: 为啥很多研究都证明敏捷很有效果?

  答: 大多数被测试, 被研究的新东西都很有效果, 这是 Hawthorne 效应。例如你可以测试 “给每一个程序员发毛绒玩具 - 然后测试劳动生产率“, 你会发现劳动生产率提高了!

  问: 敏捷是万能的么? 我上学的时候老师教我们 “形式化的软件开发方法 (Formal Method)”, “里程碑式的开发 (Plan-driven development)”, 它们都被淘汰了?

  答: 不是, 和任何武功和战术一样, 敏捷有它最适用的范围, 我借着酒劲, 画一个表:

客观因素\最适用方式 敏捷 (Agile) 计划驱动 (Plan-driven) 形式化的开发方法 (Formal Method)
产品可靠性要求 不高, 容忍经常出错 必须有较高可靠性 有极高的可靠性和质量要求
需求变化 经常变化 不经常变化 固定的需求,需求可以建模
团队人员数量 不多 较多 不多
人员经验 有资深程序员带队 以中层技术人员为主 资深专家
公司文化 鼓励变化, 行业充满变数 崇尚秩序, 按时交付 精益求精
实际的例子 写一个微博网站; 开发下一版本的办公软件; 给商业用户开发软件 开发底层正则表达式解析模块;
科学计算; 复杂系统的核心组件
用错方式的后果 用敏捷的方法开发登月火箭控制程序,  前N 批宇航员都挂了。 用敏捷方法,  商业用户未必受得了两周一次更新的频率。 敏捷方法的大部分招数都和这类用户无关, 用户关心的是:  把可靠性提高到 99.99%,  不要让微小的错误把系统搞崩溃! 

原文转自:http://www.ltesting.net

评论列表(网友评论仅供网友表达个人看法,并不表明本站同意其观点或证实其描述)