Scrum敏捷软件开发学习笔记
一、渐进敏捷
1.企业转型社区（ETC）
为了营造一种文化及氛围，对企业成功饱含热情的人尝试作出改变，这些人的成功又鼓励了更多的人产生更大的热情。通常不超过12人，来自参与Scrum转型的最高级别人员，ETC最重要的职责是围绕Scrum实施而创造活力。
清楚表达背景鼓励对话提供资源设置合适的目标人人参与预料和处理人们的问题预计和消除阻碍鼓励对实践和原则的同时关注
2.改进社区（IC）
由一群具有相似思想，类似技能而聚焦在一起，协同工作的小组
二、试点项目
理想试点项目的4个属性持续时间：企业内项目普通持续时间的一半左右，一般这个周期在3~4个月左右
规模：只选择只有一个团队的项目作为开始
重要性：选择重要性高的项目
发起人的保证：拥有一名来自商业上的并且愿意与团队一起工作的人是很重要的
选择合适的时机启动项目
团队通常只有在目前已创建所有已知功能的产品Backlog才启动第一个Sprint.
选择试点项目团队 Scrum说客积极的乐观者公正的怀疑论者 设定和管理期望 大部分团队会过度高估在第一个Sprint中取得的成绩大部分团队可以更有用关注是否能预测团队可以在多长时间内完成项目（已稳定适度的步伐），大部分团队在3-4个Sprint稳定下来。关于对Scum的态度，常见抱怨如下：
（1）每日站会浪费时间
（2）既然产品不是频繁发布，就不应该浪费时间确保每个Sprint的产品经过精心测试
（3）没有创建足够的维护和支持文档，导致系统在发布后不好维护
三、克服抵触
预见抵触| 排名 | 员工 | 管理人员 |
| — | — | — |
| 1 | 缺乏意识 | 害怕失去控制和权力 |
| 2 | 对未知的恐惧 | 缺少时间 |
| 3 | 缺乏职业安全感 | 不清楚对他的好处 |
| 4 | 缺少支持 | 没有参与解决方案的设计 |
2.哪些人会抵触
保守主义者：喜欢在保持现有结构的情况下变化；遵守传统和公认的实践
实用主义者：更关注结果
创新主义者：喜欢能对现有的结构发起挑战的改革
3.个体抵触的方式和原因
抵触Scrum的原因分为2大类：
他们安于现状他们不喜欢Scrum
| 顽固分子 | 追随者 |
| — | — |
| 怀疑者 | 破坏者 |
怀疑论者：
（1）顺其自然
（2）提供培训
（3）获得同伴的趣闻
（4）任命怀疑论拥护者
（5）促进问题的解决
（6）建立认识
破坏者：
（1）成功
（2）持续的重申和强化承诺
（3）把他们支走
（4）解雇
（5）确保正确的人在讨论
顽固分子：
（1）同步激励机制
（2）制造对现状的不满
追随者：
（1）改变团队的人员组成
（2）表扬正确的行为
（3）让他们参与
四、新角色
## 五、角色转换
Scrum团队的自组织特性淡化了技术领导这一角色，个体需要跨越本身的专业之去想办法帮助团队成员，团队从强调编写需求文档转变为广泛参与需求讨论。
1.需求分析
在传统团队中，他们的工作是尽早完成需求分析，在Scrum团队中，实时分析是他们的目标。
2.项目经理
在Scrum项目中，这个角色是没有必要存在的，“自组织”是Scrum团队的一个核心原则，他的角色工作可以由整个团队承担。
3.架构师
产品架构方面的的需求和业务目标一起用来排列产品Backlog的优先级，架构师需要把精力和注意力集中在应用架构上的不确定因素。在敏捷开发中，架构师的职责是考虑变化和复杂性，其他开发人员关注下一步的交付。
4.普通开发人员
做编程，做设计，做设计，做测试，在很多方面来帮助团队提高产出。同时也要共享产品整体成功的责任，花更多时间与同事沟通。
5.测试
Scrum团队的焦点从编写需求文档转变为广泛参与需求讨论，与产品负责人交谈成为测试弄清楚某个特性如何表现的主要反思方式，需要适应频繁且有意义地和合作者交流。逐渐偏重于自动化测试。
6.用户体验设计师
跨职能概念是Scrum的一部分，UI设计师的主要工作是确保完成在当前Sprint中承诺的所有东西，由于当前需要完成的东西不会占据全部时间，因此在完成后，花一些时间提前准备未来一两个迭代中将构建的东西。
六、技术实践
1. TDD(测试驱动开发)
把TDD作为一个设计实践和作为一个编程实践等同对待是合理的。选择单元测试并对它们进行排序，今早解决功能特性的 不确定性。研究表明，做TDD比不做TDD多花费大约15%的时间，但是可以通过降低缺陷修改个维护的时间弥补多花费的时间
2. 重构
在敏捷中，让设计简单化，然后变得成熟，重构是实现这一目标的唯一方式。重构只改变代码的结构，不改变代码的行为，系统需要维护，选择重构，一次只做一点点，小步快走，风险小，成本低，不用刻意安排太多时间集中重构。
3. 集体所有权
一个采用集体所有权的团队能写出更干净的代码，产生更少的缺陷。
确保开发人员不会变的太专，以至于只能在一个方面做贡献确保没有一个地方因为太复杂以至于只能依靠一个开发处理和完成工作。
4. 持续集成（CI）
为产品创建正式的每日构建是敏捷的最佳实践，是一个Scrum团队每日必须的工作，是敏捷团队的最低要求。
5. 结对编程
Brooks定律—给延期项目增加人手，只会使得其进一步延期。结对编程会使得项目周期变短（总体工作量增加）
6. 有意的而又是涌现式的设计
敏捷转型的一个重要方面是在预见性和适应性之间取得一个合理的平衡。Scrum的差异不是扔掉有意的设计，而是通过增量的方式来完成。对于未来未知的需求，最好的方式就是在他们发生的时候适应它。优秀的Scrum团队在预测性和适应性之间更注重适应性。
习惯于不做大型设计
计划更困难在团队和个体之间分割任务更困难没有完成设计会感觉不舒服返工不可避免
在开发过程中，缺陷越晚发现，修复的成本越大。但是通过使用良好的技术实践，通过频繁地修改系统代码，可以用更低的成本适应客户的需要。一个Scrum团队追求技术进步，保持代码的良好构造，尽可能简单的设计，有一个用于回归测试的自动化测试工具，虽然变更的次数多，但是对整体只产生很小的影响。
传统方式忽略了一个很重要的点，一旦需要修改，成本高昂，因为这个变更明显违背了设计的假设前提——很大程度上无需变更。
七、团队结构
1.设计团队的关键性因素
保持小团队每个团队基本省可以交付端到端、用户可见的功能团队规模，普遍的建议是在5-9人，更好的指导方针是“两个披萨的团队”，团队的做法。研究表明5-7人的团队能花费更短的时间完成同等规模的项目。
特性团队：贯穿整个架构的所有层次
组件团队：一个团队开发软件给项目的另外一个团队
**
2.自组织不等于随意组合
自组织团队是民机宣言的一个关键原则，使用集体的智慧通常是组织方式最好的方式。
ScrumMaster的职责是支持团队，二不是为团队做决定
八、团队协作
高效能Scrum团队的首要目标是接收团队责任制，抛弃“一包到底”的观念。
为团队注入活力的最佳时间是注意到团队已经失去方向感或者能量下降的时候。
影响自组织团队：
选择合适的成员创造开放的工作环境鼓励县城反馈建立基于团队的绩效评估与奖励系统
九、产品Backlog
产品backlog包含所有带添加的功能，由产品负责人维护，根据优先级按顺序保存。
1.从文档到讨论的转变
书面文档会让我们暂停作出判断有了书面文档，我们就不能像平时那样反复声明要表达的意思文档不利于团队责任制的实施，书面文档倾向于有顺序的任务传递，会让团队丧失作为一个整体的目的，整个团队的讨论会带动所有成员的广泛参与。尽量消除不需要的文档，其他保留的文档尽可能简短，敏捷的目标是找到文档和讨论之间的平衡。当文档用于任务交接时，是罪恶的；只有用于捕捉交谈记录使其不被忘记，则是有价值的。
2.持续提炼需求
无论在项目开始阶段怎么努力确认所有需要的功能，都不能成功，总有有些功能在系统成型后被用户会开发想到的东西。Scrum非常强调每个Sprint结束后有可运行的代码，其中一个原因是创造一个环境，可以让涌现的需求被更早的发现。
3.backlog冰山
一个黄金法则是我们应该花费每个Sprint10%的时间梳理backlog列表，为将来的迭代做准备。优秀的Srum团队不需要在开始实现某功能时就已充分理解他，，我们需要一种准时和恰到好处的方法来理解列表中的功能需求，而不是在前期竭尽所能理解所有需求。
### 4,创建Deep的产品backlog
详略得当（Detailed Apppropriately）
充分理解列表中计划实现的用户故事，不着急开发的用户故事不必太详细。
做过估算的(Estimated)涌现的(Emergent)用户故事会增加，移除或重新排列优先级排列优先级的(Prioritized)
应该根据顶部到底部按照条目的价值从最高到最低进行分类，是开发价值实现最大化
十、Sprint
1.每个Sprint应交付可工作的软件是团队需要克服的最大挑战之一。
可工作的定义：（1）高质量的（2）经过测试点（3）可潜在交付的
### 2.每个Sprint交付一些有价值的东西
3.在当前Sprint为下一个Sprint做准备
在每个迭代中预留10%的时间为下一个Sprint做准备，确保只在一个迭代中塞入能完成的东西
4.在每个Sprint中始终保持协作
有经验的团队始终需要保持深度协作，跨职能团队一起工作，团队的目标是
完成当前Sprint准备下一个Sprint
5.保持时间箱定期性和严格性
建议最好将周五作为每个Sprint的开始，做Springt评审、回顾和计划会，将开始放在周一会让我们更加恐惧周一。
绝不要延长迭代时间，严格保持时间箱能强化持续推动项目前进的想法。也不要改变目标，实在非改不可，团队宣布这个迭代异常终止，立刻计划一个包含新的具有高重要性的需求的Sprint。
十一、做计划
1.逐步完善计划
### 2.不要用加班来赶计划
可持续的步伐对Scrum团队来说至关重要：团队大部分时间按照良好的、匀速的速度运行，偶尔加班不违反可持续步调工作的目标，最长不超过二周。如果两周好不能解决，那就是遇到了一个已经不能通过加班来解决的问题。
3.支持改变范围
质量是一跟不能触碰的红线，在按照优先级顺序工作的前提下，我们需要调整范围去适应可用的资源和进度，降低质量是短视的，快速前进的最好方式是开发过程中保持系统的高质量，通过降低质量是不可预测的。
4.区别对待估算和承诺
估算+信心=承诺，有一个好的估算，需要以下两个关键的问题：
需要完成的工作的规模对团队完成这个工作的进度的预期
至少需要5个Sprint的数据计算一个90%的置信区间。
例：
从小到大排列 ：29、34、35、38、39、41
90%的置信区间是34-39。
以此预测2个迭代能完成的工作：
几乎可以确定完成（2*29）平均速率可以完成（2*35）最多可以计划那么多（2*41）
## 十二、质量
1.把测试集成到流程中
Scrum把测试作为一个主要的实践，并把测试作为开发过程的一部分，而不是作为开发工作完成后才做的事情
### 2.不同层次的自动化
传统团队很难做自动化测试的原因：
没有尽早做，在代码写了很多之后才开始做自动化测试，就会失去自动化测试的很多价值忙碌开发代码的 时候，代码变化最频繁，是自动化测试发挥作用的最佳时机。
3.验收性测试驱动开发（ATTD）
COS:仅仅是在Sprint阶段完成用户故事时要满足的内容的概要说明，用来判断用户故事是否被正确完成了。满足条件通常比验收性测试高一个层次。
4.偿还技术债务
技术债通常由于赶工所致，三个步骤降低测试技术债务：
止血：防止事态原来越遭，找到方法自动化现有的一些手工测试维持现状：新增功能，开发自动化测试还债：偿还额外的未偿还测试债务
十三、总结与思考
敏捷宣言中提到“工作的软件高于详尽的文档”，但是并不意味着没有文档，结合自身的敏捷实践，笔者认为对于一些复杂的业务功能，核心的设计文档必不可少，因为在故事拆分时，虽然已经把复杂的业务独立分拆为较简单的故事，但是整体的复杂度，依然不变，开发缺少对整个流程的理解，仅仅熟悉局部，久而久之，大家对整个功能模块都变得没那么熟悉，后续不利于扩展和维护。
敏捷开发还提倡涌现式设计，首先实现业务功能，后面不断地迭代中改进，优化设计，但是对于绝大多数工程师来说，功能正常的代码，很难有动力去修改，由很多简单业务功能组合而来的业务模块，将变得不简单，想在迭代中优化，就变得过于理想化。
