方教练安排了任务，在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。这个就不多说了。

个人成功

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

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

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

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

---

我是有底线的