Scrum Practise

1、Scrum Values Individuals and interactions over processes and tools 个体及交互比流程与工具更具价值 Working software over comprehensive documentation 可用的软件比冗长的文档更有价值 Customer collaboration over contract negotiation 与客户的协作比合同谈判更有价值 Responding to change over following a plan 对变化的响应比遵循计划更有价值Scrum Values That is, while

2、there is value in the items on the right, we value the items on the left more. 也就是说，我们认可上述右边事项的价值，但我们更加重视左边的事项。 即： 个体及交互 流程与工具 可用的软件 冗长的文档 客户协作 合同谈判 响应变化 遵循计划Scrum中的角色中的角色 Scrum 定义了许多角色，根据猪和鸡的笑话可以分为两组，猪和鸡。 一天，一头猪和一只鸡在路上散步，鸡看了一下猪说，“嗨，我们合伙开一家餐馆怎么样？”，猪回头看了一下鸡说，“好主意，那你准备给餐馆卖什么呢？”，鸡想了想说“餐馆卖火腿和鸡蛋怎么样？”，“我不

3、这么认为”，猪说，“我全身投入，而你只是参与而已”。3 Roles Scrum Team由三种角色构成。1）Product Owner 2）SCRUM Master 3）Dev Team Product Owner 客户代表，决定产品的发展方向vision，对ROI负责（投资回报率return on investment），本身最好就是个customer，PO是一个人，负责给PBI(Product Backlog Increments）排序，负责维护Backlog，确认Sprint的结果（Accept Sprint Results），PO有权利决定是否产品可以发布，PO不一定写全部的用户故事，

4、PO要不断与团队沟通，PO有决定权Authority。 SCRUM Master SCRUM Master整个过程中就是一个教练、一个咨询师的角色，他实际上就是辅导你如何开始正确的Scrum各个过程、会议等等。 SCRUM Master在整个团队中起到一种老师、教练、促进的作用，要保证团队不受干扰、保证团队高效地开展工作，移除一些障碍。他几乎没有什么权利，但要有影响力。 他的主要工作是去除那些影响团队交付冲刺目标的障碍，屏蔽外界对开发团队的干扰。 Dev Team 开发团队开发团队负责找出可在一个迭代中将产品待开发事项（冲刺订单）转化为功能增量的方法。他们对每一次迭代和整个项目共同负责，在每个

5、冲刺中通过实行自管理、自组织，和跨职能的开发协作，实现冲刺目标和最终交付产品。一般由 59 名具有跨职能技能的人（设计者，开发者等）组成。 三个工件（三个工件（Artifact） 1）Product Backlog 2）Sprint Backlog 3）Tracking/Increment Product BacklogProduct Backlog = a dynamic list of features that might appear in our product. PBI=feature, A bunch of PBIs = product BacklogIt might also

6、be worth noting that PBIs dont have to be software. The Scrum framework can be applied to areas outside of software, so PBIs could be other product features as well; for example the introduction in a book, or a chapter in a book.（值得注意的是：PBIs并不一定专指软件。Scrum框架可以应用于软件之外的其它领域，因此PBIs也可以是其它产品特性，例如在出版业，可以是书

7、的一个章节；可以是一个PRD文档。）Product Backlog Product Backlog就是软件产品的功能列表，由许多PBI（Product Backlog Item）组织，一个PBI又由许多SBI（Sprint Backlog Item）组成，这个Backlog要贴在一面大墙上。 如果这个东西全用工具放在开发团队的网站首页上行不行？- 可以，但只用电子的backlog会影响开发效率，所以我们还是用大墙和便利贴，一些内容会录入到电子backlog中。 Sprint Backlog 这个Backlog可以称为任务了，通常PBI颗粒太大，无法执行，只有分解为SBI（小于2天的工作量）才能

8、开始动手做。 在Sprint Planning meeting中形成，其包含的意义是不会被分派，而是由团队成员签名认领他们喜爱的任务。任务被分解为以小时为单位，没有任务可以超过 16 个小时。如果一个任务超过 16 个小时，那么它就应该被进一步分解。每项任务信息将包括其负责人及其在冲刺中任一天时的剩余工作量，且仅团队有权改变其内容。 Tracking/Increment 在以前就是指燃尽图，现在好像说也不是必须的了，实际上Backlog也完全可以体现出项目的进展情况。 四个活动四个活动 1）Sprint Planning 2）Daily Scrum 3）Sprint Review 4）Spri

9、nt Retrospective SprintScrum就是由一堆的Sprint组成的，这个Sprint实际上就是迭代，每个Sprint最少为1天，最长为4周，由4个活动组成。 理论上没有最小的sprint长度限制，一天的sprint长度是在产品开发中最小的长度。一个sprint可以称为sprint的关键是它必须包含4个会议。 在Sprint期间，功能范围不再变化，即PBI从左侧拿到Sprint Backlog区后，不再接受新的SBI。 SBIs具有涌现性，是由团队来定义的，因此在sprint之间会出现新的SBI。也就是说，团队对于如何完成PBI已经有了深刻的理解，因此在sprint期间SBI

10、是可以变化的，但团队已经承诺的PBI不能变化。在sprint中的No Change”是指PBI而言的。 Sprint Planning 这个过程有点需求分析的作用，实际上也是一种承诺Commitment。这个会议又由2个阶段组成，第一阶段称为Selection，第二阶段称为Planning。 第一阶段由PO、TEAM参加，SM可选。对于1周的sprint，这个阶段不超过1小时。 在这一步是根据PBI的优先级拿到Sprint backlog中，对于较大的粒度，还要分解。 第二阶段由TEAM参加，PO和SM可选，但PO要随叫随到。对于1周的sprint，这个阶段不超过1小时。Daily Scrum

11、这就是著名的站立会议，要在每天相同的时间、相同的地点举行，少于15分钟。Scrum(由于它不是一个缩写单词，所以一般不用大写所有字母)的术语也是来源于橄榄球中的碰头开球仪式，在rugby这种运动中，每个运动员都是自组织的、跨职能的，需要根据场上的动态地调整计划。会上要回答3个问题：What did I get done in the last work period?What will I get done in the next period?Any impediment（障碍）?通过这三个问题，团队进行广播式的沟通，跟踪项目的进度，分享一些知识，更重要的是给团队做出一种承诺Commitme

12、nt。Sprint Review 这种回顾对于长度为1周的sprint，不超过1小时，不需要PPT，非正式的交流。整个过程也是TEAM和PO参加，SM可选。最好还要请一些stakeholder参加。 Sprint Retrospective 这个会议对于长度为1周的sprint，不超过45分钟。整个过程TEAM参加，SM和PO可选。 这个过程是为了将来的持续改进，不讲坏消息，提出1-3个改进建议，然后就是celebrate。敏捷中的一些术语敏捷中的一些术语 用户故事用户故事 估算、任务墙估算、任务墙 持续集成持续集成 用户故事用户故事 User Story并不是SCRUM中的内容，但可以用于S

13、CRUM中。 PBI相当于User Story，而SBI相当于任务Task，SBI的颗粒度要小于0.5天。 PBI要写到什么程度？DEEP原则：Detailed Appropritly 比较清晰的Emergent 涌现性Estimated 被估算的（以团队的方式来估算）Prioritized / Order 被排序的任务墙任务墙 任务板（墙）展现了我们在Sprint过程中所有要完成的任务。在Sprint过程中我们要不断的更新它。如果某个开发人员想到了一个任务他就可以把这个任务写下来放在任务墙上。 无论每日站会过程中或者之后，如果估计发生了变化，任务会根据变化在任务墙上做相应的调整。 任务墙任务

14、墙持续集成持续集成 持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。请注意，持续集成不等于持续的编译。持续集成持续集成 持续集成要素 统一的代码库 自动构建 自动测试 每个人每天都要向代码库主干提交代码 每次代码递交后都会在持续集成服务器上触发一次构建 保证快速构建 模拟生产环境的自动测试 每个人都可以很容易的获取最新可执行的应用程序 每个人都清楚正在发生