《敏捷开发的艺术》 读书笔记 之一

方教练安排了任务,在22号之前输出一次带实操的Scrum培训。一直害怕站在讲台上,但是在这次敏捷转型过程中,要把这个短板补上。

传湘教练说站在讲台上紧张的主要原因还是准备工作不足。感觉要输出一次合格的培训,感觉至少要十倍的时间。之前给大家讲精益思想,一个半小时的交流,我准备了差不多十个小时的时间,虽然都是自己之前读过的内容,但是要能站在讲台上讲出来,还是需要系统的整理和演练的。上次自己似乎确实不紧张了,不过这次是要有实际演练的,培训压力应该更大,需要更充分的准备。

本来计划是把成长计划中和Scrum相关的书籍都看一看的,不过随手拿起《敏捷开发的艺术》来读了,我总还是改不掉坏习惯,其实应该是把《管理3.0》和《持续集成》先读完再写读后感的。另外昨天读的《看板和Scrum——相得益彰》,也懒懒的没写读书笔记。也许是因为这周传湘教练来了,这是他之前推荐的书吧。

打开发现这本书其实讲的是XP,不是Scrum,本想放下的,发现它是从Why开始讲起的,于是把第1章读完了,然后又花了一个小时写这篇读书笔记:


第1章 为什么需要敏捷

一个原因,大公司都在实践敏捷:Google,Symantec,Microsoft。它们可能不说自己是敏捷的,但是是在按照敏捷的原则做事情。不过这个原因可能不够充分。

为了提升生产率而采用敏捷开发。这个理由充分吗?作者旗帜鲜明的反对,或者说不完全赞同。

事实上,我并不主张仅为提高生产率而采用敏捷开发。敏捷开发的好处(即使是更快的发布软件的能力)都源自不同的工作方式,而不是更快地工作。尽管有个别案例证明敏捷团队拥有超出平均的生产率。那也不应该成为你采用敏捷的首要原因。你的团队将需要花一些时间来学习敏捷开发。在学习的过程中(大概需要一到两个季度)开发会变得更慢,而不是更快。此外,过于强调生产率可能会怂恿你的团队走捷径,放松工作中的要求,而这实际上会损害生产率。

感觉这句话可能会让公司高层领导失望的,但这应该是事实。敏捷从来不承诺提升质量,不承诺提升生产率,那些其实是副产品。另外,工作方法的变更和熟悉是需要投入的,通常需要6个月的时间体现出效果。这可能是在尝试敏捷开发的时候被人诟病的原因:你这个新的工作方法还不如我原来的呢。对于不能支付学习成本的团队,暂时还是不要搞敏捷转型了。王大爷说过,有火的时候先救火,不要敏捷了。

敏捷开发看起来是一件很酷的事情,以致于你想马上实施它,但这绝不是采用敏捷开发的理由。当你考虑采用敏捷开发时,关键的问题只有一个:

        敏捷开发能使我们更加成功吗?

理解成功

传统的项目成功的标准是满足范围成本进度的几个约束,即基于给定的财务预算,按照需求规格按时交付产品。著名的Standish统计给出的定义:

成功的:按时完成,费用不超出预算,而且所有特性和功能都符合原先的设计规格。

不太成功的:已完成而且可以运行,但费用超出了预算,没有如期完成,拥有的特性和功能少于原先的设计规格。

失败的:在开发周期的某个时刻项目被取消了。

问题是你永远不知道客户同意项目上线或者项目结束,是因为已经对产品满意,还是对需求的讨论和产品的不断打补丁筋疲力竭,或是对产品质量彻底失望了。对应到我们的产品,可能只有当客户通知我们被替换的时候才知道,甚至,也许,永远也不会知道。

成功不只是如期完成

作者将成功分为三种类型:

个人回报:在工作中得到乐趣,这是针对个人的;

技术优秀:包括优雅的可维护性高的代码,这是针对个人和产品本身的;

向组织机构交付价值:对于为工作提供资金的人来说,软件的价值必须超过成本。这是针对客户的,必须交付价值。

成功应该是这三者的交集。

没有个人的成功,你讲很难为自己及其他员工提供激励。没有技术上的成功,你的代码最终将被它资深的重量压垮。没有组织的成功,你的团队可能发现公司不再想要它了。

组织成功的重要性

软件开发团队更喜欢容易获得的技术成功和个人成功,因此组织成功常常被它们忽视。然而毫无疑问的是:即使你并不为组织的成功负责,更大的组织仍然会从这个层面上来评价你的团队。行政人员和高管不太会关心你的软件是否优雅、可维护,甚至也不会关心它是否被用户所喜爱;它们关心的是结果。那是它们项目投入的回报。如果你不能达到这种类型的成功,它们会设法让你达到。

当团队开发的结果不能让经理们满足,就是挥舞大刀的时候了。成本就是最明显的目标。砍掉成本有两种最简单的方法:设置非常紧迫的交付期限来缩减开发施加,或者将工作外包给一个劳动力成本更低廉的国家。或者两种方法同时运用。

这些都是笨拙的方法。过于紧迫的交付期限最终将延缓进度,而不是加快进度,而离岸外包则拥有隐性成本。

组织最重视的是什么?

除了收入和成本节约,价值还会来自以下方面:

竞争优势差异(competitive differentiation)
品牌投影(brand projection)
提高客户忠诚度(enhanced customer Loyalty)
满足监管要求(regulatory requirements)
原创性研究(original research)
策略性信息(strategic information)

不能只关注技术和技艺,想起前天阿里专家技术交流时提到的:脱离场景谈技术没有任何意义。必须解决实际问题,不能闭门造车。

走进敏捷

敏捷开发能使你更成功吗?或许可以。敏捷开发旨在获得个人、技术和组织的成功。如果你在这些当众的任何一个方面遇到麻烦,敏捷开发都可能会帮助你。

组织成功

敏捷方法通过交付价值和降低成本来获得组织的成功。

具体来说,敏捷团队通过以下方式来提高项目的价值:在团队中加入业务专家,并将开发的重点放在项目为组织带来的核心价值上。敏捷项目首先发布其最有价值的特性,并时常发布新版本。

敏捷团队在提高价值的同时也会降低成本,这部分源于优秀的技术。最佳的敏捷项目每个月只产生有限的几个bug。

美好愿景,值得追求。

技术成功

极限编程敏捷方法,特别擅长于获得技术成功。现在敏捷的技术实践基本上都来自XP,最著名的是TDD。这个就不多说了。

个人成功

一旦你习惯了敏捷,你将会喜欢它的很多方面,不论你是下面的哪一类人:

行政人员和高管,用户、利益攸关者、领域专家和产品经理,项目经理和产品经理,开发者。

这里可以注意到顺序和刚才是反的,就是说敏捷必须先满足商业价值,最后再考虑个人。


好的,现在理由够充分了,起航。


我是有底线的

推荐阅读更多精彩内容