Scrum的英文解释为：密集争球。该词来源于英式橄榄球比赛中术语。在橄榄球比赛中出现小的犯规或因为队员受伤等原因中断的时候，一般裁判会判定争球。双方各三名前锋队员相互搂抱，半蹲顶架在一起。由有球权的队投球。投球队员投球后，双方队员互相顶推，中间的队员抢球。投球队员绕到球队的后面将球捡起，可以传球或带球跑，比赛继续进行。
密集争球，寓指整个团队攒足力量，为了一个共同的目标，一起向前冲刺
Scrum的几个核心的开发原则：
1、保持简单：Scrum本身就是很简单轻量级的流程，它能简化我们的开发流程
夜沁解读：相对于开发流程来说，Scrum对比传统的CMMI和项目管理来说，实在是太简单了。这个所谓的“简单”有好处也有坏处。好处就是这种开发流程的入门门槛很低，一个基本素质的开发人员或者项目经理也能在一次培训或者几个晚上了解它。而不好的地方就是太简单了，我们很难实施它。这个说法也许很空洞，打个比方，围棋和军旗：军旗规定了详细的行军路线、规则、各个棋的等级大小，虽然第一次上手记住难，但是记住了规则后就比较简单了。而围棋的规则就简单了，简单的落子和生存“气”规则，其他的全靠后面的局势，简单的规则造就了变化莫测的策略和局势。Scrum就想围棋，简单轻量级的流程，可以实施起来根据不同的团队不同的技能不同的心态都会完全不同的走向。需要实践Scrum就必须理解Scrum的开发流程精髓和背后的目的，结合Scrum的框架以及自身团队，走出有“中国特色的社会主义”来。
2、接受变化：Scrum鼓励将工作细分为小块。它关注的是一小段一小段时间，但是只有在这些时间段的中间，我们才可以重新调整工作的优先级
夜沁解读：需求的变化一直以来都是困恼软件开发的一大顽疾。Scrum能够接受变化，难道Scrum就是解决需求变化的“银弹”，非也。Scrum所说的接受变化并非真正的允许需求随时的改变。Scrum做的是把时间的粒度细化，在小粒度的时间范围内必须维持需求不变，在粒度之间或者总体来看允许需求的不断变化，且适应这个变化。如果做到极致，把时间粒度微小话，的确能够适应需求的随时变化，但是这显然不科学，也不现实，需求也不能无休止的变化。传统的瀑布的一个时间周期可能几个月或者一年以上，这段时间需求肯定是会变化的，显然CMMI不能适应这种需求变化。而Scrum使用Sprint来进行持续开发，每个Sprint根据实际情况2~4周不等，通过小周期持续快跑，不断调整的方式来适应需求的变化。在实际的Scrum实践中可以根据项目需求的变化周期来调整Sprint的时长，个人经验来说，建议3周实践一个Sprint
3、不断的反馈和改善：在每一次迭代的末尾，Scrum流程要求我们回顾以前是怎么做的，并且思考我们下次可以做哪些不同的事情来改善流程
夜沁解读：Scrum的一个很重要的核心要点就是随时随地的反馈，在具体的实践中，个人以为你做到反馈的极致也不为过。随时随地的沟通和反馈，随时随地的反馈和调整。通过这种方式把一个团队紧紧的结合在一起，对外仿佛是一个整体的存在。在后续的Scrum具体实践分析中，我们可以看到所有的活动都围绕着这一点在进行，整个团队也是在这种循环往复中持续前进。大桌开发、站立会议、迭代回顾、计划制定、燃尽图等等都是基于积极有效的双向反馈。
4、协作：Scrum强烈鼓励团队成员的协作和沟通。
5、减少浪费：Scrum帮助我们识别做哪些只对客户或者团队有价值的事情
好了，简单的了解了Scrum，让我们开启Scrum之旅吧
To Be Continue...
密集争球，寓指整个团队攒足力量，为了一个共同的目标，一起向前冲刺
Scrum的几个核心的开发原则：
1、保持简单：Scrum本身就是很简单轻量级的流程，它能简化我们的开发流程
夜沁解读：相对于开发流程来说，Scrum对比传统的CMMI和项目管理来说，实在是太简单了。这个所谓的“简单”有好处也有坏处。好处就是这种开发流程的入门门槛很低，一个基本素质的开发人员或者项目经理也能在一次培训或者几个晚上了解它。而不好的地方就是太简单了，我们很难实施它。这个说法也许很空洞，打个比方，围棋和军旗：军旗规定了详细的行军路线、规则、各个棋的等级大小，虽然第一次上手记住难，但是记住了规则后就比较简单了。而围棋的规则就简单了，简单的落子和生存“气”规则，其他的全靠后面的局势，简单的规则造就了变化莫测的策略和局势。Scrum就想围棋，简单轻量级的流程，可以实施起来根据不同的团队不同的技能不同的心态都会完全不同的走向。需要实践Scrum就必须理解Scrum的开发流程精髓和背后的目的，结合Scrum的框架以及自身团队，走出有“中国特色的社会主义”来。
2、接受变化：Scrum鼓励将工作细分为小块。它关注的是一小段一小段时间，但是只有在这些时间段的中间，我们才可以重新调整工作的优先级
夜沁解读：需求的变化一直以来都是困恼软件开发的一大顽疾。Scrum能够接受变化，难道Scrum就是解决需求变化的“银弹”，非也。Scrum所说的接受变化并非真正的允许需求随时的改变。Scrum做的是把时间的粒度细化，在小粒度的时间范围内必须维持需求不变，在粒度之间或者总体来看允许需求的不断变化，且适应这个变化。如果做到极致，把时间粒度微小话，的确能够适应需求的随时变化，但是这显然不科学，也不现实，需求也不能无休止的变化。传统的瀑布的一个时间周期可能几个月或者一年以上，这段时间需求肯定是会变化的，显然CMMI不能适应这种需求变化。而Scrum使用Sprint来进行持续开发，每个Sprint根据实际情况2~4周不等，通过小周期持续快跑，不断调整的方式来适应需求的变化。在实际的Scrum实践中可以根据项目需求的变化周期来调整Sprint的时长，个人经验来说，建议3周实践一个Sprint
3、不断的反馈和改善：在每一次迭代的末尾，Scrum流程要求我们回顾以前是怎么做的，并且思考我们下次可以做哪些不同的事情来改善流程
夜沁解读：Scrum的一个很重要的核心要点就是随时随地的反馈，在具体的实践中，个人以为你做到反馈的极致也不为过。随时随地的沟通和反馈，随时随地的反馈和调整。通过这种方式把一个团队紧紧的结合在一起，对外仿佛是一个整体的存在。在后续的Scrum具体实践分析中，我们可以看到所有的活动都围绕着这一点在进行，整个团队也是在这种循环往复中持续前进。大桌开发、站立会议、迭代回顾、计划制定、燃尽图等等都是基于积极有效的双向反馈。
4、协作：Scrum强烈鼓励团队成员的协作和沟通。
夜沁解读：协作对于程序员来说天天挂在嘴边，可以个人来看，这点其实难度最高，因为Scurm的协作其实动了程序员的奶酪了。首先，在Scrum的团队中已经不再区分编码、测试、设计、模块的区分，讲究的是大融合。团队中的每个人不但需要编写代码，而且也需要参与编写需求（Story）、编写测试用例、参与测试甚至写文案。在团队中只有共同的目标，没有具体的职责，所有人都是为了相同的目标而冲刺。其次，针对传统的程序员无论职责上还是思想上都有了根本的改变。任务不再是上级来分配，而是自我的来领取。调动的是整个团队的主动性，是自己对目标的承诺。最后就是协作的本身，Scrum的团队成员之间必须紧密的互帮互助，木桶原则在Scrum中体现的尤为重要。目标是个人的目标，也是团队的目标。目标没有达成就是整个团队的失败。在优先级目标面前，所有的人都必须Scrum（整个团队攒足力量，为了一个共同的目标，一起向前冲刺）
5、减少浪费：Scrum帮助我们识别做哪些只对客户或者团队有价值的事情
夜沁解读：在华为有句警句：Do right Thing，Then Do Thing Right。意思就是在正确的做事情之间想要保证我们正在做正确的事情。Product Owner和随时更新的Product Backlog就是为了保证整个团队Do Right Thing，后面我们会专门针对这些进行更为细致的分解
好了，简单的了解了Scrum，让我们开启Scrum之旅吧
To Be Continue...
389
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
