14

文/路宁

敏捷已经做得很好了,还需要研究精益吗?

精益对敏捷软件开发起着补充作用:

(1)精益理论体系完备、不落俗套、而且并不复杂,它从另一个独特的视角解释了敏捷实践和原则,让人耳目一新,也适合指导各项工作。

(2)丰田生产方式和精益中的很多工具和概念可以很好地应用到软件开发领域,补充敏捷的工具集。比如看板,其“控制在制品数量”和“拉动”的特性就非常值得敏捷的“故事墙”借鉴,可以有效地加强故事墙暴露问题的能力。价值流分析方法对于发现软件开发过程中的浪费和改进点很有帮助。PDCA(Plan-Do-Check-Act)改进循环和A3报告对于开展一个个的改进活动是个不错的指导思路。“内建质量”、“停止生产线”的做法和敏捷的测试驱动和持续集成不谋而合。“现场管理”和“自组织多功能团队”也正是敏捷推荐的做法。如此种种,举不胜举。

(3)精益被应用的范围要广的多,尤其是其在部门、组织及产业链上推广的思路有助于敏捷向部门、组织及合作伙伴间推广时借鉴。

采用精益是因为Scrum等方法已经被说得过多,作为一种新的管理风尚而吸引眼球? 阅读全文 »

标签:
阅读:10,832 次
08

自从接触敏捷以来,已经在公司里帮助建立了不少的团队去实施敏捷,也参与了不少社区的交流活动,在这些实践和交流的过程中,感觉对于敏捷,还是有很多不同的理解,其中也包含了不少对于敏捷的误解,在这里和大家一起讨论一下比较常见的几条。

敏捷就是追求速度

一次在和几个朋友聊天的时候,有朋友说最近装了有线数字电视,他觉得开发数字电视频道服务的团队应该是采用了敏捷的团队,因为每隔一段时间,就会有新的功能发布,只是系统不稳定,不得不经常的重新启动机顶盒。

这无疑是个非常有趣的关于敏捷的理解,似乎敏捷就是关注软件功能的投放市场速度,而往往忽略质量。我想这是很多有关敏捷的理解中,比较典型的一种误识。如果我们重读一下敏捷的四句宣言以及12条敏捷原则,应该不难看出,敏捷实际是关注实现客户的价值,而这一价值体现在“可工作的软件”之中,这其实是对质量的要求,它意味着交付的软件是客户需要的并且质量稳定的,是同时对需求质量和开发质量提出要求。另外,因为市场的变化会促使客户重新调整需求,以获取最大的价值,因此敏捷强调“响应变化”,迅速调整策略,以帮助客户迅速对市场变化做出响应。所以,个人的理解,敏捷真正的含义应该是 阅读全文 »

标签:
阅读:9,231 次
07

三个主要误区

第一个是重视流程忽视人。敏捷宣言开明宗义指出“人和沟通胜过过程与工具”。但是仍然有很多企业试图通过创造一个完美的流程来实施敏捷。不可否认,合理的流程对于提高团队效率有一定的作用,但是企业真正要从敏捷改进中获益必须落实到人的改变上来。

第二个是重视管理轻视工程。很多团队将敏捷等同于开开站会、做做迭代、搞搞回顾。到头来,一切流于形式。敏捷说到底是对于软件工艺性的认识回归,那么持续集成、自动化测试、设计、重构这些手艺是绕不开的。不从这些根本的手艺上解决问题,各种眼花缭乱的沟通手段实际上徒然增加了团队的成本。
第三个是重视指标轻视过程。很多团队特别是从CMM型组织转向敏捷的团队,热衷于设计所谓的敏捷度量体系。度量应该是帮助团队增强信心和持续改进,指标不应成为目的。我们要关心的不只是站在哪里,更应关心我们将走向哪里。 阅读全文 »

标签:
阅读:7,118 次
05

CargoSmart公司从2008年起,通过引入专业的敏捷开发咨询公司,开始由以往的RUP开发模式(User Case Base)向敏捷开发模式(Iteration&Increasement,User Story Base)转型,我们的敏捷开发转型, 是先由咨询师和一个种子团队(包括BA, QA, SA, Dev etc. 不同的role)以敏捷软件开发模式一起共同完成一个项目完整的Release Lifecycle,然后把这个种子团队的成员分散到不同的开发团队中,由此在整个组织中传播推广敏捷开发的实践。

经过两年多的实践经历,我们有所收获也有经验教训。

以下就分享一些在实践中遇到的问题和我们的认识反思,供大家学习借鉴。 阅读全文 »

标签:
阅读:11,089 次
02

不少公司在尝试实施敏捷开发,敏捷实践在中国越来越流行,但当中敏捷涉及思想和意识上的转变,容易造成各种管理和实践上的差异,笔者常见的有三种情况。

一、小瀑布开发

敏捷当然不是小瀑布开发,很多团队开始四周迭代时,都希望可以逐步改变团队以前的开发习惯,例如:单一功能团队、团队之间交接,然后就会发现团队在这四周内依然像瀑布式开发。

我们都鼓励短迭代,两周比四周能得到更快的反馈,两周迭代比四周迭代更有效打破前面提到的老习惯,而要达到两周迭代,就必需要适当的实践配合,用户故事纵向划分、敏捷建模、测试驱动开发、持续集成、验收测试驱动开发都是有效帮助团队达到短迭代的方法。

而这里又引伸到另一个问题,就是组织能投入多少时间让团队学习这项新技能,从组织的角度去看这些问题,就是这些的回报期要多久,当然,就如丰田公司也是发展了很多年才累积到今天的成果,管理者也需要耐性才可以看到成果,而招聘优秀的开发人员更是非常重要的事情,这也引伸到下一个误区。 阅读全文 »

标签:
阅读:11,172 次
01

文 / 朱少民

有一次,当开发人员完成当前Sprint 任务的代码之后,测试人员、开发人员和产品经理一起来浏览产品、从头到尾走一遍,产品经理发现了问题,认为需要对功能进行比较大的修改。这时开发人员估计需要两天时间才能完成代码,但测试人员反对这样做,我们本来只有5天测试时间,加上这次新做的功能比较多、开发代码质量不高,验收测试已经很紧张。如果再延迟两天,测试没法完成。产品经理说,你们不是在用敏捷测试方法,应该测得很快,三天应该能完成测试工作啊!

什么是敏捷测试呢?敏捷测试当然不能简单地理解为测得更快,绝对不是比以前用更少时间进行测试,也不是将测试的范围缩小了或将质量降低来减少测试任务。也有人说,只有敏捷开发,没有敏捷测试。下面我们将要讨论一下:

  • 究竟什么是敏捷测试?
  • 敏捷测试有哪些流程改进?
  • 测试人员如何面对敏捷测试的挑战?
  • 在敏捷测试中如何制定相应的自动化测试策略? 阅读全文 »
标签:
阅读:38,776 次
31

文 / 朱少民

2010年为《程序员》杂志写了一篇《敏捷测试的方法和实践》,我们可以回过头来,看看过去的一年,敏捷测试发生了哪些变化。首先,我做了一个实验,分别打开2010年和2011年的“STAREAST Conference at-a-Glance”,输入Agile,2010年显示10个结果,而2011年显示17个结果,有一个很大的增长,说明敏捷测试越来越引起大家的关注。这只是一个表面的现象,我们还需要真正了解发生了哪些实质性的变化。

举一个例子,《敏捷测试:测试人员和测试团队的实践指南》的作者Lisa Crispin在StarEast 2011上有一个演讲——Agile Testing: After the First Year, What’s Next? 其中提到,我们从传统开发方法转向敏捷方法,由于开发人员掌握了测试驱动开发(TDD,Test Driven Development),而测试人员部分地实现了验收测试和回归测试的自动化,所以我们活下来了,但我们在接下来深入实施敏捷测试时,还会面临新的挑战,甚至要克服更大的困难。当测试人员有了一年的经验,并拥有了敏捷方法的价值观、原则和实践之后,我们还不得不考虑如何不断改进持续的发布、如何有效地管理技术债务、如何对客户的需求有更好的理解,这就要求我们掌握更深的敏捷测试技术,例如将“精益(Lean)方法”用于改进敏捷测试的绩效,以及重构自动化测试的设计或脚本以提高投入产出比。 阅读全文 »

标签:
阅读:27,092 次
30

文 / 蔡煜

敏捷软件开发绝不再是一个新名词了,但理解还是时时有偏差。敏捷宣言中的第一条“个体和互动高于流程和工具”,有人就误读为“有了沟通,一切都迎刃而解” ,因此花费大量精力整顿团队合作,却轻视了工具(技术)。其实宣言中的意思只是想强调个人和沟通更重要而已。

实际上,既然是软件开发,在所难免得面临工具的选择,而且很多优秀软件实践离开强有力的工具支持都玩不转。在如今的软件开发世界中,工具(这里谈的是软件工具)层出不穷,数不胜数,那么到底该怎么去选择适合的工具呢?

本文将根据我十几年的企业级软件开发经验给出一点建议,和大家一起来探讨敏捷和工具(特别是在企业实施中的工具)这个话题。

为了避免不必要的麻烦,文中尽量用开源软件作为介绍,但这并不是说我排斥商业软件,恰恰相反,在很多时候,只有商业软件才提供了你需要的功能(当然大部分情况下开源软件会很快迎头赶上)。

阅读全文 »

标签:
阅读:17,603 次
05

关注敏捷开发领域的程序员,对Fred George并不陌生,他是有近40年经验的国际敏捷领域大师级专家、咨询师、架构师。2011年3月中旬,他再次来华访问。值此良机,《程序员》杂志采访了Fred George,让我们一起分享他关于敏捷开发的精彩见解。

《程序员》:很多人为了编写易变更的代码,在采用敏捷时,抛弃许多习惯用法,由你的经验出发,这样做是否属于重造轮子?

FredFred George:这一行为实际是从传统编程转向面向对象编程。我目前的编程方式也有所不同,并且这个新方式与敏捷方式是兼容的。比如我曾经写过大的Java应用程序,那里面平均一个方法只有不到3行的实际代码,平均一个类使用不到25行的实际代码。我也曾经用有1400个类的新系统来替换只有72个Java类的系统。这只是不同风格的编程方式罢了。

因此,如果你打算写大的类和大的方法时,你会发现它们将很难被改变,这也往往会阻碍敏捷程序的进展,让程序员感到沮丧,导致项目失败。如果你写小的类,每个类只做一件事情,并且不允许其他的类插手这一事情,那么程序修改起来就会变得更加容易。任何变动都不会触及其他类,它们将在修改中完好如初。 阅读全文 »

标签:
阅读:16,878 次
05

文 / 姚冬

本文介绍了集统一软件开发和敏捷开发方法优点于一体的新型软件开发方法——模型驱动开发。

当今是一个快速发展的时代,软件的功能更强大,应用更广泛,系统架构更复杂。与此同时,软件开发的难度也越来越大,软件质量难以得到保障。在与业界同行交流的过程中,我感受到更多的不是自信,而是对软件质量的无可奈何与力不从心。为了解决软件开发存在的问题,业界不断涌现出许多开发方法、过程以及模型,试图从方法论、工程学等角度对软件开发过程进行改进和管理。其中最为知名的,要数RUP(Rational Unified Process,统一软件开发过程)和近十年涌现的各种Agile(敏捷)开发方法了。但从实际效果来看,似乎都没有达到预期的目的。 阅读全文 »

标签:
阅读:56,276 次
preload preload preload
京ICP备06065162