文章

巧妙使用“故事点”进行敏捷估计

克强在“敏捷中国”讨论组中引发对敏捷的估计的讨论(“Scrum sprint plan中规模估算的做法调查”,“关于story point的单位”)。我想分享一下我自己对敏捷估计方法的理解以及对于“故事点”的认识。

在敏捷开发中,团队通过两种方法对迭代做计划。

Read more

scrumworld

敏捷与精益

精益软件开发一词起源于Mary Poppendieck 和Tom Poppendieck写的一本同名书籍。这本书将传统的精益原则以一种新的方式呈现—作为22种敏捷开发实践工具之一,并且和其他工具进行了比较。 Read more

scrumcn_efficiency

敏捷开发生产率(下)

功能点估算
第一级简化

上次说到只用数据+操作就能准确计算规模,听起来够简单了,但其实还不够。

谁能在刚拿出2页纸的需求文档时(假设昨天老板在酒桌上刚从客户那记下来的),就猜出有多少个操作?而且还不遗漏?增删改查好猜,“加入角色”就不好猜了。
Read more

scrumcn_efficiency

敏捷开发生产率(中)

直接估天数或用故事点估天数,都很“程序员”。如果在项目的甚早期,面临与客户相关的报价问题,或高层领导要统计公司绩效并想进行项目乃至行业间的比较,这两种方法都很难使用。

敏捷开发内部之所以没有进化出来能做项目间比较、行业间比较、用于早期报价的估算方法,是因为敏捷的发明者和后来的实践者多数都不管这些事情。而这三样事情,比天数、故事点,在老板眼中更接近生产率绩效。
Read more

scrumcn_efficiency

敏捷开发生产率(上)

度量敏捷开发的生产率一直是个难题,确切说度量任何开发方法的生产率都是一个难题,但它实际上有答案,这个答案是本文的主要内容。

 度量敏捷生产率的目的

真正难以回答的是度量生产率的目的是什么?
Read more

scrumcn_agile

什么是敏捷(下)

破除法执之后,很容易落入空执,就是认为不存在绝对最好的方法,因此无需追寻,甘于现状。平衡空与有非常困难,这是本篇的内容。
法与空

法与空的对立统一由来已久。

吴伯凡老师举了个例子:“一切事物都是相对的”这句话有什么问题?
Read more

scrumcn_agile

什么是敏捷(上)

所谓无住,包括两个含义:不住于法,不住于空。前者比较好理解,后者会在下篇详述。

不住于法,就是不执着于具体方法的意思,就是所使用的方法应该基于实际情况作出判断,而不是认为世界上有最好的方法,必须遵守。
法执

对法的执着,称为法执。

典型的法执,是很多企业使用CMMI的方法。

本人曾经做过10多家企业的CMMI培训、咨询,所需工作日从41天~43天不等。你能想象这么多企业,起点不同,终点不同,人员不同,行业不同,能用相同的咨询工作量完成CMMI改进吗?我和我所在的公司都不是不负责任的公司,我们因此而丢失了几乎所有的要求41天之下的咨询单子,这实际上是一个下限日期,但所有企业都义无反顾地选择了它。

后来我去了欧洲的咨询公司DNV,因为这家公司告诉我他们在欧洲的咨询是150天×2年=1个CMMI级别,在欧洲本部与国外咨询师们交流时真相也是如此,因此充满了新的希望。但结果是我们的咨询业务在国内举步维艰,因为这样做的费用太高了,时间太长了。

41~43的精确性,表明即使用户不只是想要一纸证书,也幻想一定有一种大致统一的方法让企业得以改进。

从98年开始的“言必称MOTO”,到后来的学联想,学华为,到后来不知道该学什么了,请直接给我套模板吧,都是法执的体现。
敏捷法执

敏捷破掉了旧法,但也立了新法。何以见得?

“怎么知道我们敏捷了呢?”“我们这样做,算是敏捷吗?”这些问题,都表明敏捷是有法可依的,否则这些问题就无从说起。而若破除法执,这些问题也就成了伪命题,没有答案也不用回答。

之后细讲“敏捷的未来如何”的时候,会讲到“敏捷开发无论本意如何好,在推广的时候都一定会被掺杂商业利益,从而变坏。”(上次聚会一个专家的话,大家齐点头)

其实在敏捷界早有纷争,各说各的流派好。这些都是因为大家在推广不同的法,自然就会出现纷争。

而实际上,诸法平等无有高下,只有因缘(内因,外缘)的差别,导致不同场景应该使用不同的方法,甚至什么方法都不用而用自创的新的方法。这个在智慧敏捷系列中已有描述。

所以下面这些问题,作为敏捷语境的交流可以,但作为立意的出发点,就有问题:

1. “我们每日立会还开不起来,下个月想推一下”

2. “现在的自动化测试覆盖率是80%,争取做到90%”

3. “我们现在的迭代周期是2周,争取做到一周”

把法当作达到目的的方法,而不是目的,是破除法执的关键。而所谓无住,就是破除了法执,不执着地停留在固有之法上。

破除法执之后,很容易落入空执,就是认为不存在绝对最好的方法,因此无需追寻,甘于现状。平衡空与有非常困难,这是下篇的内容。

 

作者:陈勇

本专栏经作者授权开设,专栏文章未经许可不得转载

scrumcn_teamwork

敏捷开发与本能反应

经常听到有人提到敏捷开发与“本能反应”非常近似,比如凡事都需“看着办”,比如“不拘泥于形式”,比如“直击代码,不写无用的文档”等等。

那么敏捷开发与本能反应之间的差别是什么呢?

简单地说,敏捷开发就是无我状态的本能反应。
无我,无人(无我,无人,无众生)

按理说,本能反应是最接近最佳路径的,一线人员,工作现场,当下的问题,一定能在事先预定的路径之外找到更好的方法,除非有个“我”字。

1. 比如测试人员最近的工作繁忙,需要多调度几个测试人员过来,才能保证测试不延期。如果按照本能反应,开发人员中的一些人极有可能过来帮忙测试,或帮助编写一些节省人工的自动测试代码(后者是01年我们团队的做法,最终结果是25个开发人员只需要1个测试人员就能完成测试);但如果“我们是开发人员,他们是测试人员”,尤其是“每发现一个缺陷,他们得10元,我们扣10元”,这件事情多半就办不成。

2. 比如有一个人在每日例会上说遇到了困难,而另有人对此有非常容易解决的方法。如果按照本能反应,可能一句话就能帮助节省几个小时;但如果“我有我的工作,他有他的工作”,尤其是“如果帮助了他,我的工作可能完不成”,这件事情也多半办不成。

3. 比如某个文档在这个产品中的确不需要写,但是“如果他们不写,做CMMI评估的时候我们EPG组就会比较难办”,那么这个文档到底要还是不要写就真成了一个问题。

这些我与别人的分隔,使得很难在事情上走最佳路径,而多半会在人和分工上走最佳路径,尤其是按“我”的利益来走最佳路径。在这种情况下,本能反应就是错误的。

无现在的我,无未来的我(无寿者)

一个人的时候,也会出问题。

1. 一个设计非常复杂,按本能反应,怎么也应该记录下来点东西。但是如果“我现在心里清楚设计不用写,未来也不一定是谁在维护这些代码”,那么就很容易不写这个文档,却在未来产生很大的麻烦。

2. 一个代码这样写未来可能产生缺陷,但是这个版本这样写最快。如果“我要按最快的方法写,管他未来是谁”,那么多半代码就会很烂。

如果一个人说:我不写文档的原因是“我把设计表达在代码里”,如果代码很漂亮则的确如此,如果代码又很烂,就可见前者只是一个借口。

说实话多数吆喝“代码即设计”的程序员代码都很烂。
创造无我的环境

在多数有我的环境中,对某件事情而言,每个人提出的解决方案都不相同,而且没有一个是与这个事情的最佳解决方案重合的,因为每个“我”都按自己的利益行事。

最终的结果,是为了让这些我能凑在一起工作,创造出无数的部门规范、工作流程、中间文档、计划、中间文档的评审标准等等,用来约束每个我的工作。本能反应也就被压抑了。

“如何创造一个无我的环境?”这个问题在每个具体环境中,都有具体的最佳答案,受到具体人、事、物的限制,很难一概而论。

但如果没有任何前提条件地回答这个问题,倒也有一个“般若”一点的答案,就是“共振”。

所谓共振,就是在能控制的范围内先取得一些成效,以此换取他人及未来的共鸣,从而推广下去的方法。世界上的各种伟人,无一不是以这种方法工作的,影响力能远达万里、千年。

作为个人,首先可以破除现在的我;作为小团队(比如3个人),可以小范围破除我人之分,共进退;作为开发组,可以局部破除分割和个体考核;作为研发部,可以在部门内部推行新的绩效考核体系,等等。

尽管这些事情看起来都有其困难之处,但与那些“万里、千年”的事情相比,却微不足道,几乎可以说基本上只要去做,没有做不成的。

不过共振的原理,就是不谋求一说就通,一做就成,而是找到事物推广的固有频率,走得太快了,难免做不成先驱,反而成为先烈。

本人曾经在10年里频繁地更换工作,目的是找到一个可以“大展宏图”的地方,但都失败了。直到在一家企业固守了3年,结局令我大吃一惊,原来每个企业都是很容易被推动的,唯一要判断的其实只有一个问题:“这个企业值得推动吗?”

共振的内容,在本系列的以后会有2篇以上的文章还会提及。

 

作者:陈勇

本专栏经作者授权开设,专栏文章未经许可不得转载

scrumcn_cmmi

重新认识敏捷与CMMI

重新认识CMMI

CMMI其实是一种敏捷开发方法,何以见得?

CMMI是由美国军方的甲乙双方密切配合产生的国防部招标标准,在美国国防部招标的时候使用这个标准,既没有多余的让某方别扭的,也没有缺少的让某方担心的。

CMMI还是不断改进的,一个涉众如此之广的产品能以这个速度改进,已经很难得了。在招标过程中发现问题,随时都会提交到变更委员会。

所以在CMMI里边,充满了无我之心,无住之法。但是,那里的我和那里的法,不是我们身边的我身边的法。

互联网行业、消费电子行业把CMMI当作起点寻找适合自己的终点,就像北京人去天津旅游的时候绕道上海一样。
CMMI与敏捷能融合吗?

不能。

本人在国内还算是少数CMMI和敏捷客户都是两位数的咨询师,这里断言为不能,不是笔者不知道CMMI中增加了敏捷的内容,也不是笔者不知道双方可以互相借鉴,也不是笔者不认为CMMI与敏捷无法在一个企业中共存。

所谓融合,就是两个体系中其中一个消失,而被另外一个完全包括;或者两个都消失,而合并为一个。

原生态的CMMI与原生态的敏捷开发适应的行业差别很大,这两个行业的业务差别很大,面临的问题和其自身规律差别也很大。在这些行业、问题、规律本身融合之前,方法上的融合只是表面上的。

在未认清两者为何要共存于一处,各自来解决什么问题时,把他们拉到一起来很容易让开发者和企业困惑。

第一段还“其实是一种敏捷开发方法”的CMMI怎么就突然又不能与敏捷融合了?

很简单,这就像适合你的敏捷开发,都无法与适合我的敏捷开发融合一样。你我不同,融合它们两个干嘛。
CMMI与敏捷能共存吗?

能。

这就像桌子和椅子,没有融合的必要,但摆在一起还是挺搭配的。

但是桌子是桌子,椅子是椅子,各有各的用途。

如果觉得吃饭只有桌子不舒服,可以搬椅子来坐;如果觉得干坐在椅子上玩电脑不舒服,可以买个电脑桌。

但如果偏偏用敏捷开发管理军工项目,用CMMI管理互联网产品,就有点碗筷、电脑房子椅子上,人坐在桌子上一样,似乎可行,又无比别扭。

 

作者:陈勇

本专栏经作者授权开设,专栏文章未经许可不得转载

 

scrum_agile_future

敏捷的未来会怎样?

正法,像法,末法

任何事物,都会经过这三个阶段,有的短至几年,有的长达几千年。

正法时代一般是原创者掌握话语权的时期,因此能正确地解释和传播。

正法时代传播的是智慧和般若,而不是知识(方法,具体的实践等)。
Read more