Scrum Notes

/** this blog is the notes for the scrum, the references are as follows:

* http://blog.csdn.net/cheny_com/article/details/6616794

* http://zh.wikipedia.org/wiki/Scrum

* http://www.cnblogs.com/zhoujg/archive/2009/08/08/1541991.html

*/

 

Scrum

• 兼顾计划性与灵活性的敏捷开发过程
• 将整个开发过程分为多次迭代(sprint),一般2~4周

• values 核心价值观
  • commitment 承诺
    不只是把一项工作分配给团队, 也不是简单的答应去完成. 是建立在目标之上的来自内心的接受和应许, 只有"做"和"不做", 没有"让我试试"
  • focus 专注
    把精力全部集中在承诺的事务上, 不相关的邮件和会议都是常见分散注意力的事情.
  • openness 公开
    保持一直让任何有兴趣的人员都可以在墙上, wiki或仪表盘工具上获知项目当前状况, 能够了解多少功能已经完成, 哪些正在做, 每次迭代和发布的目标是什么
  • respect 尊重
    团队成员都必须被尊重, 一起指定工作规范
  • courage 勇气
    为了接受并负责任的交付产品, 团队成员必须有足够的勇气来对大家说"不", 比如不能承诺时, 对纳入sprint 的故事说"不".

Scrum的工作产品

• product backlog 产品待开发项
  从客户价值角度理解的产品功能列表
• sprint backlog 冲刺待开发项
  从开发技术角度的迭代开发任务
• working software 可工作软件
  可交付的软件产品, 可能包括使用文档

Scrum中的角色

• Product Owner(PO)
  负责产品需求的提炼,条目化, 优先级排序
  必须对产品有长远的规划和深入的理解. 人选:部门经理, 产品经理,策划人员
  大型产品常使用有层级的产品负责人团队来解决广度和深度的矛盾, 如产品总监-产品经理/主策划-策划团队
• Scrum Master(SM)
  维护scrum的秩序, 并协助解决非技术问题.
  工作方式是靠领导力而非权力工作,因此首先应服务于团队
  一种人选来自项目经理转型, 保留原有的管理和技术职能, 弱化指派任务,下达时间点指令等内容, 增强组织协调能力
  另一种人选是企业原有的过程改进人员, 协助不太了解scrum的项目经理按照scrum的方法工作, 可以每人负责多个项目, 接近全职的scrum master.
• Team
  "自组织"的相对扁平方式进行管理, 负责完成开发工作.
  项目经理,小组长的领导,指导,协同职能大于其指令职能.
• Stackeholders(SH)/customers
  These are the people who enable the project and for whom the project will produce the agree-upon benefits, which justify the production.
  They are only directly involved in the process during the sprint reviews.
• Manager
  People who will set up the environment for product development.

PO, SM, Team are the core roles in scrum teams and they are committed to the project in the scrum process - they are the ones producting the product (objective of the project)

SH, Manager are the ancillary roles which are no formal role and infrequent involvement in the scrum process - but nonetheless, must be taken into account.

 

Scrum过程

• 创建和维护产品待开发项
  product backlog必须条目化管理, 以用户价值角度描述, 语法为"作为一个....可以....以便...."
  优先级: 必须完成(Must), 应该完成(Should), 可以完成(Could),/*不用完成(Would not)*/
• 迭代计划会
   一般一个团队只有70%的工作可以正式工作, 因此每个人月安排15人天左右即为饱和, 新团队则可能低至10人天.
  共同估算: 以接收故事的小组为单位集位估算,对"做什么,怎么做"达成共识. 
  共同估算是共同跟进的基础
• 日常活动与每日立会
  每人汇报三个问题: 昨天做了什么,今天要做什么,遇到了什么困难.
  燃烧圈:横坐标是时间,纵坐标是本次迭代所有开发项的剩余时间,若时间达到终点而剩余时间也趋于零,则迭代顺利完成.
• 评审会(review meeting)
  采用时间盒的方法,既定时间而不限定范围.迭代不会延期, 因为迭代终点会放弃未完成的故事.
  评审的标准是整个故事是否已经达到交付标准, 而不是从其中分解出来的任务完成了多少.
  发现的问题和改进将被累积到product backlog, 也不会马上或下一个迭代中开发, 而是由优先级排序决定时间开发.
• 反思会(retrospective meeting)
  讨论三个问题: 上一个迭代有哪些事情做的好希望继续, 哪些事情做得不好希望改进,有何改进计划
  每次仅就1~3个关键问题做可行的解决方案,在下一个迭代执行改行.  可行标准:方法简单,影响面小,见效快;不要激进,现实,积少成多.
  如有必要可以执行领导回避制度,有管理职能的人不参加反思会,哪怕这些人是PO,PM,SM

P.S
靠谱顺序

1. 经验事实: 我们以前做过... 我们有个类库.... 那个方法我试过不可行...
2. 蛛丝马迹: 谁还记得上次... 听说隔壁.... 与上次相比.... 你以前不是....
3. 逻辑推理: 理论上说.... 我觉得...