目录:
敏捷开发智慧敏捷系列之一:序言
敏捷开发智慧敏捷系列之二:写不写文档?
敏捷开发智慧敏捷系列之三:做不做架构设计?
敏捷开发智慧敏捷系列之四:每日立会开多久?
敏捷开发智慧敏捷系列之五:定不定流程和模板?
敏捷开发智慧敏捷系列之六:之一~之五的小结
敏捷开发智慧敏捷系列之一:序言
本文将解决各种敏捷中需要辩证思考的问题,包括:写文档还是不写文档?拥抱变更还是迭代期内无变更?持续交付的产品因为不完整被客户鄙视怎么办?做架构设计还是不做?突出进度忽略了质量怎么办?我们不用文档就能开发但客户偏偏要文档怎么办?自动化测试费力而且测试代码可能跟应用代码一起被抛弃怎么办?……
缘起
敏捷开发中一直有几个根本问题无法回答:什么是敏捷?怎样知道我是否敏捷了?应该怎样推行敏捷?敏捷的未来会怎样?……
开始业界还有压力,因为这些问题如此难以回答。后来这些问题问得多了,大家也就释然了:“这些都是没有答案的问题。”
身为投身业界较早的一员,感觉草草收场太有点对不起那些心中一直有疑问的后来者了,那种感觉就像黑暗中侥幸躲过一块拌脚的石头,总是想停下来把它除掉。
最近在看一些业界之外的东西,才知道这些问题在很久以前就解决了。答案非常真切,能令接触敏捷很久的我一看就知道问题已经结束了。
不过,这个答案相当不容易用语言描述,憋了很久还是没能写出来,现在和最近的将来都心里明白但写不出来。
本系列不是直接描述这些根本问题的答案的,而是最近在微博、博客上又看到一些关于敏捷实践的纷争,而心里很清楚纷争的原因,所以特写此系列帮助后来者辨析一些概念,建立一些基本的思考方法。
兴许写几篇这个系列,就能帮我把那个系列写出来了呢。
题解
一直以来都有数据与信息的辨析。就是说数据是死的,要从中分析得到信息,才能对人有所帮助。
实际上完整的层次结构是:数据,信息,知识,智慧。这个是在《冬吴相对论》的很早一期中顺带提及的,但对我们推广敏捷很有帮助。
数据,基本上接近客观事实,不只是指数字,也指那些真实发生的所有事情,对应各种真实的敏捷案例。
信息,指从实际事情中提炼出来的有意义的实践,对应我们看到的各种用户故事、自动化测试、测试驱动等敏捷实践。
知识,指这些有意义的实践被文字化描述,广为传播。
智慧,指这些广为传播的实践的背后,所蕴含的真正道理。
数据与信息,都是受到“因缘”约束的。因是内因,缘是外部条件。
(这个案例不是敏捷开发的,但很直观)“在一家数字电视企业,人们大规模地做了软件仿真代替真实硬件,来防止太多环节的硬件捣乱”,这整句话就是数据,而“软件仿真”就是从中提出的信息。若把它写下来传播,就成了知识。
但是是不是哪里都适用呢?不是。
当时的内因,在于这家企业的研发团队很强(是我个人从事一线研发9年中经历过最强的),能够完成这一系列仿真,这个是追求卓越工作的内因;而外部环境中,从前到后硬件环节多达10层有余,客观上导致了不仿真是开发不下去的。
像这种实践,就存在很大的因缘成分,一旦离开因缘,很难重现。
敏捷开发中的多数实践要好得多,因为之所以被抽取出来,就是多少存在共性和可推广性。但这并不表明其可以无限超越因缘限制。
在敏捷开发中大家都很崇拜案例,因为案例是真实的,表明这件事情真正发生过。所以每当一方能指出“某某公司就是使用XX方法,从而才能……的”的时候,都会感觉非常立刻找到了答案,无需多说。
但是案例背后的问题在于:案例太真实了,以至于它们有的只能在一个地方发生,有的甚至只能发生一次。
智慧敏捷
而智慧,则是超越因缘的。(之后我们会看到其实“妙智慧”就是“般若”才真正超越因缘)
那个团队为什么使用软件仿真?因为追求卓越工作?因为要克服硬件限制?当然不是。
一家企业不会无缘无故追求卓越(尤其是这种内部技术层面的),而要克服硬件限制,加班加点多测试几次也能通过。
早在开始,团队并没有尝试软件仿真绕过硬件,也在以普通的妥协和加班来换取硬件大发慈悲,直到遇到一个最不讲理的硬件:IC卡。这东西连个显示界面都没有,不能单步运行,不能显示中间状态,就傻乎乎地以极低的速度执行极少数业务命令,其他一切无视。这是第一次被逼无奈,放弃加班加点或多和IC卡开发者沟通之类的笨方法,开始用仿真卡代替真实卡。
而在这一活动被证实简单有效后,其他几个不太讲理的硬件也被仿真了,最终系统越做越顺。曾经有一年聚会的时候,得知当时的市场占有率是60%(之后不详)。
在整个过程里边真正驱动大家改变看法的,不是“追求卓越”,而是:“到底哪种方法最快呢?”刚开始答案是“蛮干”,而后来则是“巧干”。
千万不要误解“蛮干”,在很多情况下“巧干”很容易产生需求镀金和过度设计,蛮干反而最快;但也不能总是蛮干,有时候撞上南墙,还是要巧干才行。
那到底蛮干好还是巧干好?都不好,他们都属于“信息”层面的东西,受到因缘的限制。这个问题一旦这么问,就无解了。
好的问题是:“到底哪种最快?”每次问这个问题,每次答案可能都不相同,但每次答案却总是正确的,这是智慧。
本系列会帮助辨析一些常见的问题,来探讨如何智慧地使用敏捷方法。这些。问题包括:
写文档还是不写文档?拥抱变更还是迭代期内无变更?持续交付的产品因为不完整被客户鄙视怎么办?做架构设计还是不做?突出进度忽略了质量怎么办?我们不用文档就能开发但客户偏偏要文档怎么办?自动化测试费力而且测试代码可能跟应用代码一起被抛弃怎么办?……
这些问题没有开头提的那些问题那么本质,但是也能反映出一些敏捷实践层面不好解决的问题,在智慧层面其实早有答案。
这些问题几乎都是本人在工作中碰到或培训/咨询中被问到的问题,若掌握了智慧层面的内容,这些问题即使被第一次问到而之前从没考虑过,也能在5分钟后让发问人满意而归。
每个人在理解了敏捷开发中的智慧后,都能做到这一点;或者反之:当事人之所以困惑良久而来发问,是因为一直没能超脱于因缘之外观察敏捷实践背后的智慧。
敏捷开发智慧敏捷系列之二:写不写文档?
缘起
“我们产品已经做完了,客户说要补上需求文档,可我们只有用户故事,这个文档应不应该写呢?”
“没有这个文档,客户能验收吗?”
“不能,客户要开课题评审会,这个是评审会材料之一。”
这个文档要不要写呢?写,为什么?不写,为什么?写怎么写?不写,怎么不写?
为什么敏捷不写文档?
先把话说绝点,敏捷就是不写文档。那为什么不写文档?
为了减少浪费。
敏捷认为所有中间产品,需求,计划,设计,测试用例……都缺少客户价值,客户最想要的价值,无疑是最后的可运行的软件。因此所有中间文档都应该省略省略再省略,直到不写。
不在对客户没有价值的东西上面浪费时间,这是敏捷不写文档的真实含义。
只是从实践上看,最浪费时间的无疑是那些无用的文档。但倘若文档是有用的,而且甚至是客户价值的重要部分,一切就变了。
怎样写这个需求文档?
就这个文档而言,它是为了验收所用,和开发没有关系(已经开发完了),和日后维护没有关系。
那怎么写?这个问题就不回答了,当然是按验收的写法写。
所以,所有文档的所有写法,在每个企业都不相同,不应该问“敏捷开发应该怎样写XX文档?”,而是应该问“应该怎样写上面那个文档?”,而若能这样发问,答案已经明确了。
“写不写文档”的常见做法
常见的文档虽然很多,但下面几个维度几乎永远存在,具体某个文档通过几个维度的分析,处理方法各不相同:
信息长期/短期有效的文档
长期有效比如竞争对手分析文档,架构设计文档,需求管理文档(用户故事),产品路线图……
长期文档适合详细描述,用语应完整(就是写Word那种写法),甚至可以动用图形和建模工具。
短期有效比如评审发现的问题,PO在计划会上讲解的内容等。
短期文档适合粗略描述,典型的就是用纸或Word凌乱地写一些关键内容,无需长期保存,月末一般就无用了。
不可/可被”可运行软件“替代的文档
上面举例的文档中,竞争对手、架构设计、用户故事、路线图都无法从代码中看出来,适合文档化。此外,一些科学计算的公式、复杂的设计也属于此列。
而界面设计、数据库表结构设计、流程图、伪码等,一旦软件做好了,更容易在可运行软件中看出,就不要着大量笔墨于此。
若感觉后者处于”没有就做不出软件,但做出软件又没用了“的尴尬境地时,应采用轻量级设计。
敏捷开发智慧敏捷系列之三:做不做架构设计?
缘起
甲:“敏捷不应该写架构设计,应该每个迭代都是相同的,才能达到自相似性(这是Ken Shweber说的)。”
乙:“如果不写架构设计,很容易返工,早晚还得重来。”
甲:“大不了重构,这是敏捷开发重要的实践。”
乙:“重构?重构的成本很高的,做几个迭代,后面重构都重构不过来了。”
甲:“架构设计写了很容易过度设计,而且在编码的时候还很容易全部推翻重来;。”
……
这个架构文档要不要写呢?写,为什么?不写,为什么?写,怎么写?不写,怎么不写?
为什么敏捷不做架构设计?
先把话说绝点,敏捷就是不写架构设计。那为什么不写架构设计?
还是为了减少浪费。
敏捷有两个理由认为写架构设计是浪费时间。
第一,业务需求是多变的。之前的架构写得再好,中间需求一变,架构还的改动,费时费力;很多需求可能是无用的,早期可能规划了,后期又会发现用不上,如果架构里边考虑了这些无用需求,就会过于庞大。
第二,架构设计很难判断是否正确、完备。这个本人也很有体会,本来以为很好的设计,到了编码的时候发现不是那么回事,这时候就得从头翻腾。评审一下如何?可惜,除了最终的软件,多数需求、架构、测试用例……都很难评审,评审半天,问题还是很多。
敏捷的这些假设,整体上非常普遍,可以说是在尝试“做好架构”而不得之后的妥协。
不在那些总是改来该去,还不知道是否可行的东西上浪费时间,是敏捷不做架构的出发点。
怎样写这个架构文档?
但是如果彻底不写架构设计,又可能返工,怎么办呢?当然是本着“最小浪费”原则来做架构设计。
下面是一些写和不写的内容:
写:相对稳定不变的,重构成本很高的,能看出对错的
不写:概念性的那不太准的,很容易扩展的,说不清对错的
具体要写什么不写什么,很大程度上要受到业务稳定性、技术的先进性、人员能力等各方面的影响。
所以,所有架构文档的所有写法,在每个企业都不相同,不应该问“敏捷开发应该怎样写架构文档?”,而是应该问“如果我的业务、技术、人员如此,应该怎样写架构文档?”,而若能这样发问,答案肯定可以自己找到了。
智慧敏捷的一个本质方法,是要去理解敏捷这样做的目的是什么,而不是敏捷应该怎样做。
倘若日后出现了先进的架构方法,或许架构就变成一种很容易做、很容易评审、很容易变动的东西,那时候就是另外一种说法了。但敏捷在架构设计这件事情上的本质目标却永远不变:减少浪费。
5分钟又到了,散会。
敏捷开发智慧敏捷系列之四:每日立会开多久?
缘起
甲:“我们每日立会会开不起来。”
乙:“嘿,我们每日立会开起来了,而且越开越长了,一开就是1个小时,净是些技术细节。”
甲:“别人等着他们讨论,那多耽误时间啊……”
乙:“我也觉得是,但是看他们交流得那么热烈,讨论的也是正事,到底应该打断还是不打断呢……”
为什么每日立会只开15分钟?
我们说绝点:每日立会只能开5分钟,而不是15分钟。
这5分钟说点什么呢?应该说必须开会才能说明白的东西。
先看两个团队,他们有什么是需要开会说明白的。
第一个团队,10个人,平时分工细致,各干各的,谁也不干扰谁。
这个团队,开会的时间肯定不短,因为所有交互问题都需要开会解决。
第二个团队,10个人,平时分成三个小组,小组内随时沟通,小组间有需要就沟通。
这个团队,开会的时间肯定短,因为三个小组长发言总结自己组的进展就可以了,会上只需要碰碰组间的沟通。
敏捷开发实际上在假设大家平时像第二个团队一样一直在互相沟通(即使不分成三个小组),但是却很少以整个团队的形式沟通整体进展,所以才创造了15分钟的周例会,当然也能顺便把忘了沟通的人链接一下。如果这个本来作为补充性质的周例会变成了组内唯一的沟通渠道,就出问题了。
所以,开会时间长,往往不是沟通充分的表现,而是沟通不充分,只能赶在会上沟通的表现。
团队应该怎样沟通?
团队应该随时就技术细节进行沟通,而不需要等待开会。而对于3~5个人的团队,组长如果除了开会居然不知道整个组的进展,那么沟通是极其不顺畅的,要解决的不是每日立会的问题,而是平时沟通的问题,比如采用师徒制度、松结对编程等(请参考其他系列博文)。
这种会议甚至在更大的规模上,也能淡化。
我们曾经试图在一个由销售、市场、支持三个部门15个人的组中间开周会,开了大约几次后就取消了,原因是我们仔细安排了位置,使得总监和三个经理一起坐在中间的大桌上,而其他队员则坐在四周。因此组间的沟通在大桌上随时就完成了(做了个4个人都能看到的大屏幕),而组内的沟通则一回脸就完成了。所以发现几乎所有的事情大家都知道差不多了,会上也只是重新说说而已,开或不开都可。
因此,应理解每日立会、计划会、评审会、反思会这些会议,都只是沟通过程的仪式化的补充,若沟通本身不畅,而只是指望这些会议完成沟通,肯定会陷入两难的境地。
“每日立会”的常见做法
1~4人团队
这个规模的团队,优先使用139团队结构和松结对编程方法,即由师傅(小组长)密切地与徒弟们沟通。这会涉及到沟通管理、时间管理、过度沟通、有效生产率等问题,在链接的系列博客中有所详述,都不是问题。
这个规模的团队应该不开立会,而是更密切的交流方式。它的运行方式更像XP,而非Scrum。
5~9人团队
这个规模的团队,优先划分为2~3个小组,每个团队仍按松结对编程方法运行。
由于人多了,组间难以沟通,所以开个立会是必要的,主要目的是组间进度沟通,因此不会发生技术沟通(这是组内的事情),所以也不可能超时。
小组长应把握好应该如何与对方组沟通、沟通什么的问题。
更大型的团队
更大型的团队,则推荐组长+小组长参与开超级立会,组员不参加。
这类会议也是进度沟通会,所以不会涉及技术沟通。
为何不让Scrum Master们开个会议?因为专职的Scrum Master不负责技术、进度、质量这些事情,真正对这些熟悉的,是团队组长和核心骨干。
后面两种会议,很像是“Scrum of XPs”,而不是“Scrum of Scrums”,前者的沟通性更强。
敏捷开发智慧敏捷系列之五:定不定流程和模板?
缘起
(立项时)
甲:“你们的设计文档打算怎么写?”
乙:“到时候再说。”
甲:“应该有规范的开发流程和模板,才能写好设计文档。”
乙:“预先定义的流程和模板未必适用,敏捷开发崇尚推迟决策,只有在具体工作之前才能决定是否写,怎么写最好(maximizing
the amount of work not done)。”
甲:“你们组才3个人,能比组织级定义的流程和模板还好吗?”
敏捷开发定不定流程和模板?
先把话说绝点:敏捷开发不定义流程,不定义模板。为什么呢?
因为如果预先定义了流程,比如“必须写需求,需求评审过了才能写设计……先检查测试环境,测试标准定好了才能开始测试……”以及模板,则在千变万化的项目进展中,就极有可能多写了本可以不写的文档,多做了本科避免的事情,或者虽然没有“多”,但是形式却不合适。
这个道理如此简单,为什么前人却经常喜欢定流程和写模板呢?我们来看看CMMI的情况。
CMMI是最喜欢定流程和写模板的(组织过程焦点过程域OPF负责定期不定期地发现哪里有可改进的地方,而组织过程定义OPD则负责将其制定并宣贯下去),不但如此,还派出过程与产品质量保证人员PPQA检查实际情况与过程或产品标准的偏差。
CMMI这种工作方式哪里来的呢?
原来,CMMI是美国国防部的招标标准(CMMI3级及以上才能成为其供应商)。长期以来,军工、航空航天等领域保持了非常高的质量和产量(两者都远远高于我们熟悉的消费电子和互联网行业),而其首要目标,就是继承已有的成果,也就是按已有的流程和模板做。偶然有所创新,但其价值与继承已有成果不可同日而语,所以没有人会颠覆性地采用新的未经证实的流程或模板。对质量和产量的追求,驱使其整体持有保守的态度,这甚至会影响到其供应商的研发策略,比如IBM。
而另外一些行业则正好相反,比如热销的苹果手机,多年来业务不断变化的Google等。
首先这些行业有自己对质量的定义,比如不是可靠性99.9999%,而是易用性、操控性;其次其产量也不来自于标准的规模化的生产,而是来自于其创新性引发的市场反应和用户主动追逐。尽管这不影响苹果有自己的生产规程,Google也有自己的编码规范,但其价值与随时创新不可同日而语。这就引发了这些企业一致性地采用敏捷开发方法(日后会讨论“什么是敏捷开发方法”,进而会涉及“到底NASA、Boeing、Apple、Google谁在用敏捷开发方法”的问题)。
因此,不同行业基于不同价值观产生了不同的流程和模板理念,他们没有孰优孰劣之分,只有适合与不适合之分。
我的行业/项目/团队适合不适合定义流程和模板呢?
没有人比“我”更熟悉我的行业或项目了,所以这个问题不用问。
不定义流程和模板,可能会受限于团队的能力而把本可以做好的事情做差;定义流程和模板,可能会限制发挥或导致生搬硬套劳而无功。
两害相权取其轻,自然会发现答案在哪里。
或许由于项目、团队的不同,每次会得到矛盾的答案,这不稀奇也不奇怪,每次都是最好的答案就可以了。
“定不定流程和模板”的常见做法
敏捷开发过程与模板
多数企业做敏捷开发培训与咨询的目的,都是为了形成相对稳定、统一的敏捷开发过程,因此过程与模板是应该有的。否则连Scrum
Master都不知道自己要维持的秩序是什么样子的。
但是,在使用过程与模板的时候,不应该执着,而应该灵活。
动态使用的原则
不知道大家是否发现一个规律,就是每个产品都会有出现,兴起,鼎盛,衰落……这个过程,而打败他们的,往往是另外一个新兴的但却更简单的产品。究其原因,在初期由于老客户不断的要求,新产品的功能都会不断增加;增加了功能的新产品,增强了竞争力,因而也就更热卖;但产品复杂度到了一定程度,使用这个产品的门槛也就越来越高,新用户就越来越不接受这个产品了,市场反而被简单的产品所抢走。(详情参考产品之六爻:http://blog.csdn.net/cheny_com/article/details/5872882)
过程与模板也是如此,对老团队而言,在不断改进和细化;而新团队的门槛却节节攀升,最终造成在整个企业推广的时候,面临重重阻碍。
因此组织应该分层、分阶段地部署过程与模板,而Scrum Master也要随机应变地维持秩序。
这一点对Scrum Master的要求极高,因为”随机应变“不是被动的,就是看什么能推动就推什么,而是主动的,就是发现团队有什么问题,就知道流程和模板中哪些内容是用来解决这个问题的。
敏捷开发智慧敏捷系列之六:之一~之五的小结
写多了,才发现前几篇文章中有几篇都落下个章节,就是除了“看着办”之外的一些常见做法,这里总结一下。
所谓常见做法,就是为了防止“看着办”看走了眼,而提前可以参考的方法,可以作为起点,但未必真的正好合适,更很难永远合适,所以不是终点。
为了阅读方便,在原文中也添加了,这里仅做归纳。
“写不写文档”的常见做法
常见的文档虽然很多,但下面几个维度几乎永远存在,具体某个文档通过几个维度的分析,处理方法各不相同:
信息长期/短期有效的文档
长期有效比如竞争对手分析文档,架构设计文档,需求管理文档(用户故事),产品路线图……
长期文档适合详细描述,用语应完整(就是写Word那种写法),甚至可以动用图形和建模工具。
短期有效比如评审发现的问题,PO在计划会上讲解的内容等。
短期文档适合粗略描述,典型的就是用纸或Word凌乱地写一些关键内容,无需长期保存,月末一般就无用了。
不可/可被”可运行软件“替代的文档
上面举例的文档中,竞争对手、架构设计、用户故事、路线图都无法从代码中看出来,适合文档化。此外,一些科学计算的公式、复杂的设计也属于此列。
而界面设计、数据库表结构设计、流程图、伪码等,一旦软件做好了,更容易在可运行软件中看出,就不要着大量笔墨于此。
若感觉后者处于”没有就做不出软件,但做出软件又没用了“的尴尬境地时,应采用轻量级设计。
“写不写架构设计”的一般做法
之三原文中已经写了,就不多说了。
“每日立会”的常见做法
1~4人团队
这个规模的团队,优先使用139团队结构和松结对编程方法,即由师傅(小组长)密切地与徒弟们沟通。这会涉及到沟通管理、时间管理、过度沟通、有效生产率等问题,在链接的系列博客中有所详述,都不是问题。
这个规模的团队应该不开立会,而是更密切的交流方式。它的运行方式更像XP,而非Scrum。
5~9人团队
这个规模的团队,优先划分为2~3个小组,每个团队仍按松结对编程方法运行。
由于人多了,组间难以沟通,所以开个立会是必要的,主要目的是组间进度沟通,因此不会发生技术沟通(这是组内的事情),所以也不可能超时。
小组长应把握好应该如何与对方组沟通、沟通什么的问题。
更大型的团队
更大型的团队,则推荐组长+小组长参与开超级立会,组员不参加。
这类会议也是进度沟通会,所以不会涉及技术沟通。
为何不让Scrum Master们开个会议?因为专职的Scrum Master不负责技术、进度、质量这些事情,真正对这些熟悉的,是团队组长和核心骨干。
后面两种会议,很像是“Scrum of XPs”,而不是“Scrum of Scrums”,前者的沟通性更强。
“定不定流程和模板”的常见做法
敏捷开发过程与模板
多数企业做敏捷开发培训与咨询的目的,都是为了形成相对稳定、统一的敏捷开发过程,因此过程与模板是应该有的。否则连Scrum
Master都不知道自己要维持的秩序是什么样子的。
但是,在使用过程与模板的时候,不应该执着,而应该灵活。
动态使用的原则
不知道大家是否发现一个规律,就是每个产品都会有出现,兴起,鼎盛,衰落……这个过程,而打败他们的,往往是另外一个新兴的但却更简单的产品。究其原因,在初期由于老客户不断的要求,新产品的功能都会不断增加;增加了功能的新产品,增强了竞争力,因而也就更热卖;但产品复杂度到了一定程度,使用这个产品的门槛也就越来越高,新用户就越来越不接受这个产品了,市场反而被简单的产品所抢走。(详情参考产品之六爻:http://blog.csdn.net/cheny_com/article/details/5872882)
过程与模板也是如此,对老团队而言,在不断改进和细化;而新团队的门槛却节节攀升,最终造成在整个企业推广的时候,面临重重阻碍。
因此组织应该分层、分阶段地部署过程与模板,而Scrum Master也要随机应变地维持秩序。
这一点对Scrum Master的要求极高,因为”随机应变“不是被动的,就是看什么能推动就推什么,而是主动的,就是发现团队有什么问题,就知道流程和模板中哪些内容是用来解决这个问题的。
|