我看Scrum(1)

周三下午拿到《Scrum敏捷软件开发》，周五晚上十一点看完最后一章，联想起自己的项目经历，不禁产生很多的感触，对于作者的观点大部分是深有体会而赞同，有些也是不以为然的。又想起前端时间陈皓翻译的那篇《为什么Scrum不行》，这里系统的说说自己对Scrum、敏捷的看法，也作为对这本书的书评，如无特殊说明，下面的例子都是自己的经历。

软件开发的四个维度：人、过程、产品和技术。

一、人

关于人，最著名的书就是《人件》，我们都对这么一句话不会陌生：具有不同深度和广度的开发人员的生产效率差异能够超过10:1。但另外一个统计同样不能忽视：具有相同水平经验的开发人员的生产效率差异同样能够达到10:1。

人的因素包括了人的激励、团队的组织结构、团队成员的选择、团队合作和培训等等。

很清楚，人件极大地影响着生产效率，它也应该排在过程、产品、技术之前进行考虑。但是，这只是表明个体能力、个体激励、团队能力和团队激励的作用大于其他因素，并不是说一个团队只要有了T恤衫、免费的碳酸饮料、有窗户的办公室、游戏机和漂亮的测试MM就能达到激励的目的，这只是必要而非充分条件。真正的激励来自于项目进行中。

二、过程

关于过程，包括了管理和技术两部分。包括了项目的计划（项目生命周期模型，迭代开发是其中一种）、跟踪、度量、质量保障、风险管理等方面。

有些人认为注重过程会让工作变得呆板和效率低下，存在这样的现象。但过程滥用最常见的现象是忽略过程。

三、产品

关于产品，包括了产品规模（需求范围）和产品特性（非功能性需求、性能、稳定性、可靠性）。

注意到对产品规模和产品特性的关注，意味着巨大的缩短开发时间的机会。合理消减产品功能，能够缩短产品的开发周期。这里面存在2/8原则。

四、技术

关于技术，其基本原则包括了需求管理、系统设计、系统构建和配置管理。具体内容则包括了实现技术栈的选择，开发语言的选择、开发平台的选择、框架的选择、开发工具的选择等等。

先来看人

一、人员角色

Scrum团队有两个重要的角色，分别是教练（迭代经理）和产品负责人，一个对内，一个即对内也对外。对于教练，他的职责是为团队提供一个好的不被过分打扰的工作环境，促进团队的持续改进。这谁都明白，最重要的是他的权力不能超过开发流程的范围，他不能跨过流程为团队做决定。

在我经历过的两个项目里，技术出身的迭代经理都有替程序员做决定的习惯。一个迭代经理审核每个程序员的设计，另外一个迭代经理每天站会结束后都会花上很多时间和程序员探讨故事实现的具体细节并提出自己的观点。

迭代经理做决定的行为实际上表达的是对团队的不信任，不可避免，他们的行为不管最初出于什么样的良好愿望，最后都会影响团队的积极性。在后一个项目里，甚至有程序员站起来递过键盘对迭代经理说，好吧，你来实现。

迭代经理不能越界并不是说他不能施加影响，他的影响应该是间接的。

至于产品负责人，他的存在除去产品需求，最重要的一点在于确保产品的方向、需求只能有一个人做决定。

在我曾经的一家公司里，有四个股东，所有事情都要集体讨论做决定。当我老婆第一次听说我们公司的组织结构时，她笑了，说，你们公司注定是小公司的命。

在我曾经的一个项目里，客户产品经理和客户运维团队为需求争论不休，没有一个一致和统一的产品发展方向，导致了大量的浪费。

二、团队规模

在经典的管理学书籍里，一个人能够直接有效管理的人不能超过5人，当然随着流程标准化的进行，这个数目已经大大扩张。在以非正式沟通为主的开发团队里，5人的标准依旧适用，一个5-7人的小团队是合适的，小团队的优点在于减少沟通协调，促进凝聚力。

在一个项目后期里，当人员由最初的8人扩展到14人后，每日站会的时间大大延长，每个人都不知道别人在说些什么，说话的人太多就失去焦点了。

但是正如1个人不能完成阿波罗登月一样，小团队的问题在于尽管生产率提高但总的产出不够。对很多项目来说，大团队不可避免，关键在于对大团队的拆分，将大团队拆分成很多的小团队，至于这些团队间的协调有多种方法，成本最低的莫过于对系统进行合适的分解，典型的如现在的新浪微博平台，第三方插件开发商和新浪微博团队是完全解耦的，系统分解的目的在于尽量减少小团队之间的交互沟通。管理上的方法则包括了组建系统集成团队，团队之间的人员流动等。

三、特性团队还是组件团队

Scrum提倡特性团队，而我感触最深的却是特性驱动开发。

在一个工作流产品的开发里，我采用的是分层开发，最开始团队的精力全部放在工作流引擎的开发上，管理控制台、集成组件、设计器的开发任务被放置在引擎完成之后。结果因为迟迟无法向公司提供可以演示的版本以反映进度再加上公司资金紧张，导致项目的取消。团队所有人都感到可惜，因为那是我们感到得意的引擎，它支持了全部的21种工作流模式。

只要有可能，就应该组建特性团队，而不是组件团队。这是书中的观点，我的观点和其有些不同，我的观点是，如果是项目级别，那么毫无疑问，应该组建特性团队，但是上升到公司级别，则必须做到组件沉淀和积累。

作为一个正面的例子，在曾经一家公司里，因为协同办公业务平台的存在，基本上所有协同办公项目的实施都控制在3个月左右。当然，这个平台是在公司很多项目基础上的抽象和积累，平台团队的人员同时也参与项目的开发。

作为一个反面的例子，另一家公司里，团队成员为一个个技术问题争论不休，甚至一个分页组件都要重写两遍，产生了很多的浪费。公司没有注意到技术公共部分的积累。精益里一个重要的原则-标准化被有意忽视了。

四、团队协作

五、全功能团队

六、不要分布式团队

过程

一、估算

二、计划

三、文档

四、迭代式项目生命周期

五、质量

六、风险

产品

一、简化项目是成功的唯一出路

二、多团队同一个任务列表

技术

一、测试驱动开发

二、重构

三、集体所有权

四、持续集成

五、结对

六、简单设计与过度设计