标签：客户 分配 开放性 紧急 编程 决定 back 使用 一个
Scrum是一种轻量级敏捷开发框架，用来管理软件和产品。使用各种流程和技术来解决复杂的适应性问题，同时以高效生产力、创造性方式交付价值最大化的产品。
Scrum不适合非常简单的或异常复杂与混乱的项目。
敏捷宣言：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
Scrum有三个属性：轻量级、简单易懂、十分难以掌握。
Scrum依赖固定节奏的迭代周期，称为Sprint，每个Sprint以计划会议开始。
Scrum的特征是团队内外的反馈和透明，它的短周期和协同的本质使其相当适应于快速变化或者有紧急需求的项目。
Scrum框架：
3种工件：产品backlog、Sprint backlog、完成标准
3种角色：产品负责人、敏捷教练、团队
4种会议：计划会议、每日站会、评审会议、回顾会议
5个价值观：承诺、勇气、专注、尊重、开放性
使用Scrum必须做出改变：
1. 理解Scrum的基本价值观
2. 往往要经历巨大的思维方式的转变
3. 准备变化的发生并适应变化
4. 处理新暴露出来或新冒出来的问题
5. 引入敏捷工程实践
1. scrum的基本价值观：
承诺：说到做到，不轻易许诺
勇气：敢于尝试新的方法、敢于提出问题，敢于拒绝say no、敢于承担责任，主动担起任务
专注：不要被其他事情所打扰，传注当前事项与工作
尊重：互相尊重，彼此信任
开放性：开放的思想，吸收新的思想观念和方法，吸取各种经验教训
2. Scrum需要转变思维方式：
成功的Scrum最大的障碍就是不具备转变思维的能力，或者说不具备使用新的思考方式来解决问题的能力。
如果没有按照它的指令来使用，特别会在最初的时候，Scrum可以使用你的项目很快变得很糟糕。很多团队浅尝辄止，自以为懂得更多了，认为他们的实际情况有所不同，于是按照自己的方式来应用。
在决定定制Scrum之前，一定要先理解Scrum。按照它本来的意图，不做修改直接拿来应用。花一些时间尽你所能好好学习它。
不要再一开始尝试把Scrum和你熟悉的其他一些工具组合使用，现在还不是时候。只有掌握了一种工具之后，你才能够学会把它和其他工具成功结合在一起使用。
3. 准备变化的发生，并适应变化
传统的软件开发方法是基于项目计划来开发的，先将计划的功能全部开发出来以后，再进行校验然后修正问题。越迟发现问题，要改动的地方越多（甚至软件架构），这样就会造成工作量成倍增加，工期延期等问题。
而敏捷开发，是基于价值来计划开发的，以阶段性完成有价值的故事为目标进行的，每个阶段都会去验证，根据需求的变化去调整阶段性计划，越早完成的计划是越有价值的计划，这样持续性将价值功能交付给客户，也有利于客户提早发现问题，进而修正问题。
4. 处理新暴露出来或新冒出来的问题
Scrum可以暴露长期以来被掩盖或者忘记的问题，它也会暴露新的问题，这些问题不局限于开发和团队合作
Scrum挑战组织规范，迫使管理层做出艰难的选择：解决这些问题或者忽视这些问题
5. 引入敏捷工程实践
a. Scrum是一个项目管理框架，它讲的是如何管理项目，但是它不包括特定的、可以让你每两周就提交潜在交付软件的工程实践。因此你需要它的最佳搭档：极限编程（XP）
b. 尽管单靠Scrum也对团队有所帮助，但把Scrum和XP结合在一起会产生显著的效果
c. 一旦你的团队对Scrum的角色、工件以及会议有丰富的经验，他们就可以准备集成XP的实践
d. 项目必须有以下XP实践：
可持续的步伐：团队成员尽量是专职的，不被打扰的；在做sprint时，针对旧系统的维护工作如果占用较多时间，可考虑启用专职维护团队来进行，维护旧系统时使用良好的工程实践来改进遗留代码。
代码集体所有：避免增加与团队文化不协调的新成员，文化的冲突可能会导致项目开发效率低下，甚至失控。
结对编程与测试驱动开发
持续集成：每天至少提交一次代码，努力争取每天回家的时候持续集成都是绿色的
编码标准：没有编码标准会对代码集体所有造成巨大的破坏
重构：没有重构会让需求的改变无法适应业务变化的系统设计
成功秘诀：开放的学习Scrum
1. 改变规则是很危险的，团队必须理解Scrum的规则
2. 团队成员必须学习Scrum的基本机制
3. 给予足够的时间
4. 不要在项目中途使用Scrum
5. 保证为持续学习分配时间
标签：客户 分配 开放性 紧急 编程 决定 back 使用 一个
原文地址：http://www.cnblogs.com/EmptyFS/p/7755680.html
