Scrum基础

1      Scrum是什么

遵循Agile宣言的一种具体的实践方法，Agile宣言如下：

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：

个体和互动高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

也就是说，尽管右项有其价值，

我们更重视左项的价值。

 

Agile宣言遵循以下原则：

1)        我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

2)        欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

3)        经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

4)        业务人员和开发人员必须相互合作，项目中的每一天都不例外。

5)        激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

6)        不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

7)        可工作的软件是进度的首要度量标准。

8)        敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

9)        坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

10)    以简洁为本，它是极力减少不必要工作量的艺术。

11)    最好的架构、需求和设计出自自组织团队。

12)    团队定期地反思如何能提高成效，并针对其中出现的问题，在后续研发中持续改进。

 

Scrum在遵循敏捷宣言的同时，也融入了XP（极限编程）的部分实践：

1)        团队协作(Whole Team)

2)        规划策略(The Planning Game)；

3)        结对编程(Pair programming)

4)        测试驱动开发(Testing-Driven Development)

5)        重构(Refactoring)

6)        简单设计(Simple Design)

7)        代码集体所有权(Collective Code Ownership)

8)        持续集成(Continuous Integration)

9)        客户测试(Customer Tests)

10)    小型发布（Small Release）

11)    每周40小时工作制（40-hour Week）

12)    编码规范（Code Standards）

13)    系统隐喻（System Metaphor）

定义：它是将整个系统联系在一起的全局视图；它是系统的未来景像，是它使得所有单独模块的位置和外观（shape）变得明显直观。如果模块的外观与整个系统的隐喻不符，那么你就知道该模块是错误的。

想想一下“拼图游戏”。

2      Scrum的流程

3      Scrum的4种角色

3.1        Product Owner

代表客户利益，最好是客户方的人或者是商务人员。如果团队内部人，必须具有如下特性：

能换位思考，能在2种不同类型的角色之间切换，作为“PO”：坚持以客户价值为导向，以高标准严格定义“Done”的标准，不能随便妥协；作为“Team Member”：需要严格按照Scrum流程完成每日工作，对自身的工作产出的要求要与其他团队成员保持一致。

3.2        Scrum Master

类似于“足球/篮球场上的教练”,职责：

1)        负责规范化流程；

2)        保护团队在不受干扰的环境下工作；

3)        解决阻碍团队前进的问题。

3.3        Team

1)        选取Product Backlog组成Sprint Backlog，将User Story拆分成Task，进行工作量估算；

2)        每日领取并按照计划完成Task；

3)        遵循Scrum Master的指导，按照规范的流程完成一次Sprint；

4)        总结团队的在每次Sprint之中的做的好与不好的地方，并实施持续改进。

 

作为Team成员，需要有如下精神：

1)        对团队承诺和履行承诺的精神；

2)        集体主义精神，按时完成自己领取的任务，不拖团队的后腿。

3.4        Stake Holder

其他与项目相关的利益相关人，如二甲方、公司管理层等，他们受邀参加项目团队的活动，例如演示会和计划会议等，他们只是团队的“外因”。

4      Scrum的4种活动

推行Scrum应具备的基本条件

团队成员都是“多面手”，既能开发又能测试，技术全面；

开发团队最好能集中在一处开发，面对面地沟通；

团队在Sprint当中要避免受其他事情的打扰，全心全意；

 

我们现在面临的不利条件：

1)        团队分隔两地，沟通不便，沟通成本高；

2)        存在管理问题，团队成员同时做几件事情的时候比较多。

5      计划扑克

“计划扑克”的使用方法：

1)        每个团队成员拿到一组卡片，包括0,0.5,1,2,3,5,8,13,20,40,?,∞,共计12张。why斐波那契？避免连续值，你真的说得清楚故事点=4和=5之间的区别？

2)        产品负责人或者一名团队成员扮演阅读者的角色，他负责阅读需要估算产品Backlog的条目，并且询问大家是否有疑问

3)        团队讨论这个条目。

4)        当团队理解了这个条目之后，每个团队成员按照自己的想法给出估算结果，并且选择对应的扑克出牌，估算结果不能告诉其他人，出牌时数字朝下扣在桌面上。

5)        所有人都出牌之后，阅读者向大家确认是否都已经确定估算结果，确认后，数大家同时展示估算结果。

6)        团队评估不同的估算结果，我们是否想法一致？我们是否存在分歧？有没有什么是我没有考虑到的？团队共同讨论估算的差异，最终达成一致。

7)        回到第二步，开始估算下一个条目。

为什么要使用估算扑克来做估算：

1)        团队的智慧要高于某一个人的智慧。

2)        真正参与工作的人做出的估计要高于其他人做出的估计。估算扑克有效还有如下几个方面的原因：

a)        “三个臭皮匠抵过诸葛亮”，况且还是”不同工作性质的臭皮匠”。

b)        在估算的过程中，团队对估算的结果进行讨论和评判，在一个高度透明的环境下，估算的结果更加真实和客观。这样也避免了很多时候过于武断，或是拍脑袋做出的决定。

c)        估算的过程也是一个知识分享和学习的过程，对某一个条目不清楚的成员通过其他成员的阐述会增加对该条目涉及到的要点的认

6      User Story&Task

User Story的写法应该遵循如下“八股文”：

As a <User Type>

I want to <achieve goal>

So that  I can <get some value>

 

User Story需要遵循的原则：

1)        Independent 独立性，避免与其他Story的依赖性。

2)        Negotiable 可谈判性，Scrum中的story不是瀑布开始某事中的Contract,Stories不必太过详细，开发人员可以给出适当的建议。

3)        Valueable 有价值性， Story需要体现出对于用户的价值

4)        Estimable 可估计性，Story应可以估计出Task的开发时间。

5)        Sized Right 合理的尺寸，Stories应该尽量小，并且使得团队尽量在1个sprint(2 weeks)中完成。

6)        Testable 可测试性， UserStory应该是可以测试的，最好有界面可以测试和自动化测试。每个任务都应有Junit Test.

 

一些经验：

1)        不要在User Story中使用And和Or，因为这是些分支词就表示分支任务，把它们拆成两个Story.

2)        团队要根据自己的几次的尝试，不断提高自己估计一个Sprint能够完成多少User Story的能力，保证在可持续工作的情况下，一直保持一个固定的节奏推进Scrum开发。

3)        User Story用于描述用户故事，不要包括任何的技术，框架等内容。Task可以包括框架，技术等内容。

7      看板

为什么要看板？

1)        来自“丰田”“精益管理”思想；

2)        信息公开和共享的渠道。

看板的典型布局：

ToDO|Doing|Done|Problem|BurnDown Chart，可选的WithDraw|Added，实际项目推进中看板的例子：

8      一页纸Scrum