文章

时间是竞争优势

在1988年的时候,我曾经阅读过一篇文章,直到现在我仍然对它念念不忘。那篇文章是George Stalk发表于《哈佛商业评论》的《时间——下一个竞争优势的来源》。文章发表时,正处于各个公司都在拼命寻找竞争优势以取得比竞争对手更快的成长速度的年代。
scrumcn1309442707
当然,那时也是敏捷开发流程开始盛行的年代,当中包括Scrum。这些敏捷流程变得流行的原因是他们能够帮助公司更快地交付产品。 Read more

Ken Schwaber: 敏捷与PMI

PMI(项目管理协会)最近宣布,将敏捷同他们的管理项目相结合的那么一个项目。
我自然很欢迎这一举措,同时也期待着项目管理协会 (PMI)能从之前的模式转变成敏捷模式。自然该项目的成功将和这项检测的原则紧紧联系。在过去, 他们预测性方法的成功 (或收益) 低于项目的50% (按天,按时, 以及带有预期功能 。) 大部分敏捷方法有更高的成功率,其中包括尽早取消低回报投资项目的成功。我们将可看看运用PMI和敏捷相结合的方法是否能去的这样的成功,或者至少是有个 50%的提高1,2,3。 Read more

战壕里的敏捷用户界面设计和信息架构师

六年前,我是一家大型网络设计公司的技术总监,他们没能够成功应用Scrum。 当时管理当中存在相当多的障碍,尽管如此,富于创意的经理是最坚持的。起初,只是不想让架构企业软件的现实阻碍他们当时在做的图像处理 (Photoshop) 或平面设计 (Illustrator)的美好设计。自然,在开发阶段当这些人工产品与现存企业构架相碰撞的时候会有许多问题。 这种障碍导致了延期,高强度压力,低质量编码,以及每年40%的雇员流动率(和漂亮图表)。这家公司激励了我对于UX和敏捷的兴趣, 我也因此而找到做敏捷的基本方法。 迄今为止,在编程尤其是网站的所有修炼中,UX人是最坚持也最好的应用敏捷并投入实践。 Read more

精确度错觉

对于我来说,敏捷开发最吸引人,但是又没有明确说明的部分,就是去分析设计正好合适的要完成的工作量,从而使得我们能开始工作。你可以在需求梳理和在垂直 功能部分的概念中找到具体例子。 “明白一点,再做一点,再明白一点,再做一点”大多数情况下这都是很有效的,这种概念是最为基础的,当最终我真正明白他的含义的时候,它让我顿时茅塞顿 开。但是,明白了这个概念之后,我发现我自己又在另一个问题中挣扎。
为什么我们要花费多余的精力和金钱,去做那些过于精确的估计(准确来说是几个小时或者几十分钟)?去估计那些无论我们投入多少都不可能被完美定义的特性? Read more

让管理层害怕的 8 个敏捷理解

敏捷体系中,有许多种不同的开发方法。各类敏捷开发方法中,较成体系的有 XP、FDD,只说明管理框架的有 Scrum,只说明建模的有敏捷建模,具体的技术实践包括 TDD 测试驱动开发、持续集成、结对工作、快速迭代等等。敏捷涉及面非常广泛,不同的人当然有一些不同的理解和解释。也许由于敏捷开发方法首先发端于程序员,不 少的理解可能来自于程序员。本文试图来整理当前主要的让管理层害怕的敏捷理解,而不论这个理解是否正确。本文所指管理层是指团队以上的管理者们,不包括项 目经理和项目团队领导。
Read more

Just enough(刚刚好)的软件开发文档什么样?

在今年与多个软件开发单位的交流中,补文档的问题多次提到,试图通过本文谈谈文档的价值,如何写刚刚好的文档。

软件开发所需要的文档在传统的瀑布型生命周期下典型的有:开发计划,需求规格说明书,设计书(有分成基本设计书、详细设计书;也有分成High Level Design、Low Level Design;或者概要设计、详细设计), 测试计划(测试用例),测试报告,结题报告。其中的需求规格说明书和设计书是过程中最重要的两份文档,往往多达数十页,甚至数百页。 后期,文档与实际软件的一致性问题是比较突出的,往往出现软件已经修改,而文档还没有修改,两者不一致。
Read more

scrumline

浅谈“排队”

四月份在QCon北京分享了我们团队在翻译“User Story Applied”项目中的一些经验(Slide已经上传到SlideShare上)。其中主要应用了排队理论。我在演讲过程中做了一个调查,令我吃惊的是,听众中只有三个人听说过排队理论。由于排队理论是敏捷开发的一个重要理论基础,因此我觉得很有必要在这里介绍一下排队理论及其应用。 Read more

CMMI PK 敏捷

敏捷开发是一种轻量级的软件开发方法学,它有多种不同的形式,如XP、Scrum、Crystal Methods、FDD等,它的基本特征是迭代的、增量式的开发;强调自主性和积极主动的团队精神;强调效率、质量和沟通。CMMI是一个开发过程参考模型,现已成为评价软件开发组织过程能力的标准,它为组织提供了实现高效的过程所必需的基本元素,可以用来指导一个项目、一个部门甚至整个组织的过程改进。CMMI能帮助我们整合以往各自为政的组织功能,建立过程改进的目标与优先级,指导我们进行质量改进,还提供了评价现有过程的参照点。
多年来网络上存在一些对 CMM、敏捷似是而非的观点,CMMI 到底与 Agile 有何不同? 它们是水火不相容还是可以彼此借鉴,扬长避短、互补融合?

什么是真正的目的?

随着敏捷开发的成功案例越来越多,越来越多的公司开始关注敏捷。连IBM和微软这样的大公司也开始关注敏捷开发。IBM已经有25%软件项目开始使用敏捷。微软著名的Pattern&Practice团队很早就在使用敏捷方法和实践,甚至微软vSTS团队在全球开发VSTS 2010项目中也在使用Scrum等敏捷方法。越来越多的公司和团队开始关注敏捷,讨论敏捷,导入敏捷,敏捷渐渐成了一种时尚。于是我们听到了越来越多导入敏捷失败的案例。我听说很多公司的高层听了Scrum介绍后感觉不错,马上吩咐下属去制定计划导入Scrum。下属人员或者去参加Scrum课程,或者去读了Scrum的书,然后就开始在团队里面推广实施。不出意外,很多失败了。也有很多即使没有失败也是只是借用了Scrum的一些形式,其实实质上还是在继续原有的方法体系。我曾经面试过一个在某最著名公司里做了两年ScrumMaster的应聘者。在面试中他告诉我他们团队一直在用Scrum框架,迭代开发,有sprint 计划、每日站立会议、demo等等,可是令我吃惊的是他告诉我两年内他们的Scrum从来没有发生过变化。Scrum的一个重要的原则是”审查和调整”。而这个Scrum团队,这个ScrumMaster在做Scrum的两年中,竟然没有进步,这绝对不是Scrum,绝对不敏捷! Read more

对“准备”,“射击”,“瞄准”看法的反驳

早期一个对于敏捷开发非常流行的批判总结下来是这句话:准备,射击,瞄准。这句话的意图是来刻画像XP和Scrum这样的敏捷方法是多么的愚蠢 — 一些完全不合常理的做法,它们不可能成功。这句话的核心是,它建议一个长期的计划(“瞄准”)必须先于开始工作(“射击”),其他的任何做法可能永远不会成功,应当避免。

Read more