《SCRUM敏捷软件开发》读书笔记（第一章）

关键词：《SCRUM敏捷软件开发》，(美) Mike Cohn著，清华大学出版社，2011版，读书笔记（第一章）

 

第一章     为什么敏捷转型难（但值得）

 

本书的目的：

一、如何很好的向敏捷转型。

例如：如果认为SCRUM变革仅限于软件开发团队而不考虑对销售人员、销售部门和财务部门的影响，那么组织的惰性会把整个公司重新带回原点。

二、如何获得长久的成功。

例如：如果只在形式上推行了SCRUM的变革，但是没有把持续改进纳入变革，那么SCRUM变革带来的回报将大大少于本应该得到的。

 

为什么转型困难

一、成功的变革不是完全的自上而下或者自下而上

1. 无论是自上而下还是自下而上，对于大多数成功的变革来说，两者都需要
2. 引入变革的最佳方式是自下而上的，同时需要管理层再适当的时候给予支持，包括基层和更高层的。

1)  自上而下需要强势的领导。移除跨部门的障碍和困难，需要自上而下的支持。这时阻力往往来自各个受影响部门的中层管理者，会为了保护自己的部门而剔除SCRUM带来的变化。

2)  自下而上需要工作主体的参与。这时阻力往往来自个人对工作安排的抵制。团队成员是工作的主体，他们才知道如何使SCRUM在企业内变得更有效。假如一个团队或一些个人决定需要进行变革，就会着手促成其发生，一些团队采用自下而上的变革时可能的态度和方式有：a) 期望事后谅解（低调转型）   b) 打破规则（高调转型） c) 尝试钻空子（灵活转型）

 

二、结束状态是不可预知的

1. SCRUM转型不可能照葫芦画瓢一蹴而就，而是需要正确的创造活动。敏捷转型也许会有一个很好的开始，但是具体的过程还是需要根据每个独一无二的组织情况、人员情况、以及行业情况进行不断的调整。若照搬某种单一的敏捷方法论，则十之八九将不适合你的组织，无论是极限编程XP还是SCRUM, 或者其他敏捷过程方法论。
2. SCRUM即便有大家共同认可的愿景，也是一个没有终点的过程，需要持续的改进：

1)  对于特定的某个组织机构，我们无法预见其SCRUM转型的结束状态。如果不能预见SCRUM转型的结束状态，那么“差异分析”只能确定持续改进后的中间状态与改进前的状态之间的所有差异。

2)  对希望通过差异分析进而解决具体差异的传统方式向SCRUM转型的组织来说，“不能预见SCRUM转型的结束状态”就成了一个问题。如此一来，差异分析驱动的变革就不奏效了。

3)  由于“差异分析驱动法”无法克服上述问题，那么就只能用“刺激和观察法”：组织可以被比喻为一个生态系统，而生态系统是绝对不可以管理的，只能被干扰。只能先进行尝试，拿一个可能产生一些影响的实验来驱动这个系统，然后静观其变，看是否能驱动我们逐步靠近中间部分有改进的状态，如果见效，则进一步尝试。这些刺激和促进是根据经验、知识和直觉精挑细选的，旨在驱动着组织机构实现SCRUM转型。

 

三、SCRUM是无处不在的

1. 若影响越大，则阻力越大。假如只是推行一项孤立的变革，例如单单增加一个代码检查的动作，这时候大多数工作不受影响，那么阻力相对小。
2. 对软件开发团队内部而言，开发人员向SCRUM转型，并非只是孤立的变革，而是贯穿一切有关的开发人员的日常工作，是工作模式的根本性变化，这种根本性变化是困难的：

1)  开发人员需要为新写的每段代码编写自动化测试

2)  测试驱动开发的情形下，可能需要采用交替的方式写测试代码和程序代码

3)  结对编程的时候，可能需要关掉耳机来做所有事情

3.对组织机构而言，实施SCRUM转型则更加影响深远。因为跨团队变革是必需的，这将导致影响更多的群体，从而使得SCRUM转型比其他变革更加困难：

例如在实施SCRUM的情况下，引入“操作准备就绪检查”这个变革，不单只影响开发部门，而且必然会影响财务、销售或其他的非开发部门，遭遇更多阻力和误解：

1)  财务部门将不得不使公司资本运作和花费相关的政策与SCRUM项目运作的方式保持一致

2)  销售部门将考虑改变他们传达日期和范围的承诺方式，并且可能改变他们的合同结构。

 

四、SCRUM是截然不同的

1. 测试人员要考虑符合用户需求而不是仅仅按照说明书进行
2. 程序员要知道编写代码之前并不一定需要有经过深思熟虑的设计，要习惯“涌现式设计”（将在第九章讨论“涌现式设计”），要习惯于“简单设计”（有时候当前的设计不但未深思熟虑，甚至并不可取）。反之，如果坚持认为没有全面细致的设计就不能进行开发，那么在当今时代就会成为一个不合格的开发人员。
3. 人员既有的培训和工作经验，会导致变革并不容易推动。例如“测试驱动开发”（将在第九章讨论“测试驱动开发”）这种变革可能很难快速推动，而虽然“先写测试用例”相对容易推动，但是可能很多人仍然无法丢弃长期的前期设计阶段。

 

五、变化来得比以往更快

1. “未来冲击”的两面性：越来越卷（“未来冲击”是指：员工多年来忍受的不得不做太多改变的折磨： 更少的人更多的活儿，外包、分布式团队越来越普遍，开发模式的迅速转向：应用程序->CS模式->Web->基于服务的模式等，技术变化如新的语言、新的工具、新的平台），人们应对“未来冲击”的能力是有限的（无论人和企业，进行改变的能力是有限的），压力和迷惑会接踵而至。
2. 过渡到SCRUM也被人们视为一种未来冲击式的变革
3. SCRUM变革导致人们工作和交互方式根本性变化，面临触发未来冲击效应的风险

 

六、最佳实践是危险的：

1. 团队成员可分享新发现的理想工作模式
2. 但是应该抵制制定最佳实践或标准工作的做法。最佳实践会让我们放松，从而停止对精益（持续增量）的改善的努力。
3. 不要把敏捷当做微管理或针对项目、团队、成员的更强的监控

 

为什么值得投入：

一、敏捷带来更高的生产力及更低的成本

1. 衡量手段：代码行数、功能点，合理的假设代码行数和功能点没有造假（不考虑代码可复制、不考虑功能点可复用、忽略特性或功能点大小不一的情况）
2. 敏捷sprint方式（频繁反馈、时间箱式、每个sprint重新排列优先级）比瀑布更能防止开发用户不再需要的功能，只开发用户真正需要的功能

二、敏捷让敏捷团队中的员工参与度、工作满意度更强，更好的提升士气。员工参与度增强能使企业获得更多利益。

1. 更少加班
2. 让日常工作具有更好的可控性
3. 习惯更快的看到自己的工作成果
4. 与同事更紧密的协作
5. 制造的产品更有可能满足客户和用户的期望
6. 对自己和雇主更满意的员工会更好的参与工作

三、敏捷能缩短产品上市时间

1. 高生产效率使得能更快的开发功能
2. 更有可能增量发布
3. 项目干系人意识到每个sprint都能产生有价值的功能时，可以决定不需要等着爆炸性的一次性交付。

四、敏捷让产品有更高的质量

1. 按照可持续的节奏来工作，质量得以提高
2. 不受遗留的缺陷所拖累
3. 工程技术实践：结对编程，重构
4. 强调更多更早的自动化测试

五、敏捷使客户满意度得到提升，也让员工有更高的热情，形成良性循环。

1. 敏捷能更友好的应对和更好的管理优先级的变化，提高了企业管理不断变化的优先级的能力，也让参与者体会到变化带来的影响（SCRUM过程让我们更多的参与每日评审和讨论，对变革有更多的了解，更早建立责任感）
2. 敏捷让技术团队和商业团队更容易达成共识（IT人员和商业人员目标一致性增强）
3. 敏捷降低了项目的风险
4. 敏捷有助于提高项目的可见度（完全可见的交付、完全透明、令人难以置信的生产效率）

六、瀑布的做法不再有效

1. 更彻底的计划分析文档签字只会让事情更糟糕
2. 惯性思维导致错误假设——只要更彻底的瀑布就能让项目更成功的交付？这个假设不成立