(二) 产品负责人PO

　　1、PO 是一个人并只能由一个人来担

　　2、负责管理产品待办事项表(Product Backlog)并保证其 对于客户和团队保持透明度

　　3、对产品代办事项表进行优先级排序

　　4、与团队一起来进行工作量估算

　　5、对于项目的成功负责并保证投资回报率(ROI)

　　给PO的一些建议：

　　1、 客户项目：佳的PO人选应该由客户的代表来担任

　　2、 内部项目：佳的PO人员应该由业务经理担任

　　3、 PO可以由团队成员担任，但永远不能由ScrumMaster担任

　　(三) 团队Team

　　1、 佳团队大小：5-9 人

　　2、 多功能团队：程序员，测试人员，设计师，数据库管理员和架构师

　　3、 保证团队成员全职参与开发

　　4、 自我管理，没有头衔之分，不组建子团队

　　5、 成员更替只能在迭代之间进行，佳方式是在发布之间进行

　　需要注意的是，第三点提到的全职参加是指完成了分配到的任务额即为全职参加。并不是指全程参加。

　　五、在每次迭代过程中包含的内容

　　(一) 每日站立会议

　　1、 站立进行

　　2、 在固定的时间，固定的地点

　　3、 问题：

　　你昨天完成了哪些工作?你要完成哪些工作?遇到了什么困难?

　　4、 仅仅作为信息沟通用途，不解决任何问题

　　5、 不向任何人汇报

　　6、 15分钟

　　(二) 发布计划会议

　　进行产品规划

　　1、仅对启动项目所必须的内容进行规划

　　2、在开发过程中适时进行进一步的规划

　　可交付物

　　1、针对产品特性和功能的整体规划

　　2、下一个发布的目标

　　3、主要任务

　　4、按优先级排序的产品待办事项表

　　(三) 迭代计划会议

　　1、进行迭代规划

　　2、PO向团队介绍产品待办事项表

　　3、团队在PO的协助下充分了解产品待办事项

　　4、确定迭代目标和迭代合约

　　迭代合约包含的内容有：

　　1)团队组成(成员列表、角色分配)

　　2)完成规范

　　3)团队对迭代目标的承诺

　　4)迭代长度

　　5)迭代代办事项的估算

　　6)迭代评审和下一次计划会议的时间和地点

　　5、对产品待办事项进行细分并创建迭代待办事项

　　(四) 迭代

　　解释：团队用来实现迭代目标(可发布产品)的时间区间。

　　时间区间：1-4周，佳2周。

　　关键词：时间长度决定何时结束迭代，而不由工作量的完成来决定。

　　优点：为团队提供保障。

　　(五) 迭代评审会议

　　1.团队展示完成的功能并收集反馈

　　2.对未完成的功能进行描述并说明原因

　　3.PO接受/不接受当前迭代

　　4.邀请所有人，包括客户参与

　　5.4小时

　　(六) 迭代回顾会议

　　1.那些做的好?

　　2.那些做的不好?

　　3.那些可以改进?

　　4.仅团队成员参与

　　5.4小时

　　六、定义需求

　　用户情景应该包括：作为……我需要……从而……，以及用户接受标准。

　　用户情景应该理解为用户+情景，不能仅仅考虑用户本身，所有的用户情景都应该从某类用户开始。

　　用户情景佳实践：

　　1、纵向分配原则-对于采用分层设计的业务用例实现尽可能 由一个开发人员完成所有的层次的组件实现(界面/逻辑/数据)

　　2、 任务的划分粒度到1个工作日内完成

　　3、 对于任务而言，只有完成和不完成两种状态

　　4、 业务用例的工作量使用的相对值，表明的是一种对于用例工作量和评定