SCRUM 入门

极限编程仅适用于小型项目，而scrum适用于大中小型项目。
可以把scrum看成是极限编程的一个加强版

• scrum的核心内容是：团队架构和软件研发框架

  
  
  

  scrum基本流程

• scrum团队角色
  产品负责人 product owner、SCRUM master、开发团队；

• 产品负责人

职责：

提供愿景、提供需求的优先级；

需要注意的地方：

和开发团队沟通需求、考虑团队的研发能力；

• SCRUM master

职责：

类似教练的角色；没有行政的权利，不能fire掉团队的成员；训练团队成员用scrum原则做事；不代替团队成员做决定；

需要注意的地方：

不要替团队成员做决定；产品负责人和scrum master不建议是一个人；

• ”自组织“的开发团队

自组织的概念：

主动与产品负责人、SM沟通，个人能自我管理和主动协调工作，能从项目大局出发完成工作；

自组织团队的特点：

团队成员一起讨论需求、跨职能工作、自我管理、注重团队承诺；

• scrum的实践

scrum在需求方面的核心理念：

不要试图初期就细化全部需求；
通过用户故事来组织和细化需求；
所有成员都来参与需求讨论，明确细化需求；

• 用户故事
  eg：作为网站的所有者，我希望可以统计网站的点击次数，以便我可以知道广告的收益情况。
  由大到小将用户故事不停的拆分，然后通过讨论获得我们需要去执行的需求。

标准格式：

作为……角色；
希望系统可以……（目标）；
以便……（原因）；

难点：

发现和提炼用户故事，并对用户故事做拆分，安排故事的优先级，分派到不同的sprint中去实现；

用户故事的2大标准：

能在一个sprint中完成；
加入满意条件（用户故事的验收标准）；

满意条件：

业务流程要求；
业务数据结构要求；
可以用具体的数据、例子进行说明；

• Product backlog/Sprint backlog

product backlog:

产品代办列表，即产品需要完成的所有用户故事的合集，不同用户故事的颗粒大小有差别。

sprint backlog：

冲刺待办列表，sprint中需要完成的用户故事的合集，每一个用户故事应该对应有各自的满意条件。

• Sprint
  一个sprint就是一个小版本，建议时长是一个月。

注意

在sprint中应该很难区分需求、设计、编码、测试阶段；
所有的工作都应该是基于用户故事的讨论；
测试先行、测试驱动、单元测试必不可少；
设计也是“涌现”式的；

自组织的用户团队，用户故事的完成不是以代码的完成作为衡量标准的，必须提交可以完成预期的成品，即可以交付使用，才可以算作是一个sprint的完成（即一个用户故事的完成）；

• Burn down chart 燃尽图
  来跟踪sprint未完成工作的情况；

• Sprint中的最佳实践

1、结对编程
A写完代码，B可以来做评审，同样B的代码A也要来做评审；
同一段代码至少有两个人熟悉；
两个人在工作中可以互相的切磋和进步；
2、持续集成
可用的软件比面面俱到的文档更优；
3、测试驱动、测试自动化
需求必须是大家一起确定的，在这个基础上我们就可以把测试看成是开发，同时把开发看成是测试；
4、每日会议
对照我们每个阶段的工作计划，说出【问题】
5、经验教训总结