文档介绍：敏捷开发智慧敏捷系列之一:序言
本文将解决各种敏捷中需要辩证思考的问题,包括:写文档还是不写文档?拥抱变更还是迭代期内无变更?持续交付的产品因为不完整被客户鄙视怎么办?做架构设计还是不做?突出进度忽略了质量怎么办?我们不用文档就能开发但客户偏偏要文档怎么办?自动化测试费力而且测试代码可能跟应用代码一起被抛弃怎么办?……
缘起
敏捷开发中一直有几个根本问题无法回答:什么是敏捷?怎样知道我是否敏捷了?应该怎样推行敏捷?敏捷的未来会怎样?……
开始业界还有压力,因为这些问题如此难以回答。后来这些问题问得多了,大家也就释然了:“这些都是没有答案的问题。”
身为投身业界较早的一员,感觉草草收场太有点对不起那些心中一直有疑问的后来者了,那种感觉就像黑暗中侥幸躲过一块拌脚的石头,总是想停下来把它除掉。
最近在看一些业界之外的东西,才知道这些问题在很久以前就解决了。答案非常真切,能令接触敏捷很久的我一看就知道问题已经结束了。
不过,这个答案相当不容易用语言描述,憋了很久还是没能写出来,现在和
最近的将来都心里明白但写不出来。
本系列不是直接描述这些根本问题的答案的,而是最近在微博、博客上又看到一些关于敏捷实践的纷争,而心里很清楚纷争的原因,所以特写此系列帮助后来者辨析一些概念,建立一些基本的思考方法。
兴许写几篇这个系列,就能帮我把那个系列写出来了呢。
题解
一直以来都有数据与信息的辨析。就是说数据是死的,要从中分析得到信息,才能对人有所帮助。
实际上完整的层次结构是:数据,信息,知识,智慧。这个是在《冬吴相对论》的很早一期中顺带提及的,但对我们推广敏捷很有帮助。
数据,基本上接近客观事实,不只是指数字,也指那些真实发生的所有事情,对应各种真实的敏捷案例。
信息,指从实际事情中提炼出来的有意义的实践,对应我们看到的各种用户故事、自动化测试、测试驱动等敏捷实践。
知识,指这些有意义的实践被文字化描述,广为传播。
智慧,指这些广为传播的实践的背后,所蕴含的真正道理。
数据与信息,都是受到“因缘”约束的。因是内因,缘是外部条件。
(这个案例不是敏捷开发的,但很直观)“在一家数字电视企业,人们大规模地做了软件仿真代替真实硬件,来防止太多环节的硬件捣乱”,这整句话就是数据,而“软件仿真”就是从中提出的信息。若把它写下来传播,就成了知识。
但是是不是哪里都适用呢?不是。
当时的内因,在于这家企业的研发团队很强(是我个人从事一线研发9年中经历过最强的),能够完成这一系列仿真,这个是追求卓越工作的内因;而外部环境中,从前到后硬件环节多达10层有余,客观上导致了不仿真是开发不下去的。
像这种实践,就存在很大的因缘成分,一旦离开因缘,很难重现。
敏捷开发中的多数实践要好得多,因为之所以被抽取出来,就是多少存在共性和可推广性。但这并不表明其可以无限超越因缘限制。
在敏捷开发中大家都很崇拜案例,因为案例是真实的,表明这件事情真正发生过。所以每当一方能指出“某某公司就是使用XX方法,从而才能……的”的时候,都会感觉非常立刻找到了答案,无需多说。
但是案例背后的问题在于:案例太真实了,以至于它们有的只能在一个地方发生,有的甚至只能发生一次。
智慧敏捷
而智慧,则是超越因缘的。(之后我们会看到其实“妙智慧”就是“般若”才真正超越因缘)
那个团队为什么使用软件仿真?因为追求卓越工作?因为要克服硬件限制?当然不是。
一家企业不会无缘无故追求卓越(尤其是这种内部技术层面的),而要克服硬件限制,加班加点多测试几次也能通过。
早在开始,团队并没有尝试软件仿真绕过硬件,也在以普通的妥协和加班来换取硬件大发慈悲,直到遇到一个最不讲理的硬件:IC卡。这东西连个显示界面都没有,不能单步运行,不能显示中间状态,就傻乎乎地以极低的速度执行极少数业务命令,其他一切无视。这是第一次被逼无奈,放弃加班加点或多和IC卡开发者沟通之类的笨方法,开始用仿真卡代替真实卡。
而在这一活动被证实简单有效后,其他几个不太讲理的硬件也被仿真了,最终系统越做越顺。曾经有一年聚会的时候,得知当时的市场占有率是60%(之后不详)。
在整个过程里边真正驱动大家改变看法的,不是“追求卓越”,而是:“到底哪种方法最快呢?”刚开始答案是“蛮干”,而后来则是“巧干”。
千万不要误解“蛮干”,在很多情况下“巧干”很容易产生需求镀金和过度设计,蛮干反而最快;但也不能总是蛮干,有时候撞上南墙,还是要巧干才行。
那到底蛮干好还是巧干好?都不好,他们都属于“信息”层面的东西,受到因缘的限制。这个问题一旦这么问,就无解了。
好的问题是:“到底哪种最快?”每次问这个问题,每次答案可能都不相同,但每次答案却总是正确的,这是智慧。
本系列会帮助辨析一些常见的问题,来探讨如何智慧