开发管理 CheckLists(19) -敏捷开发 Scrum Sprint计划会议二

注： 开发管理 CheckLists-系列文章是从本人   Iteye博客中移植过来.后续会直接在此更新     开发管理 CheckLists   专栏

本文主要是为了检测你对SCRUM Sprint 计划会议二的了解和使用程度,

通过本文你可以检测一下 
    1、你们的SCRUM Sprint 计划会议二的过程和步骤
    2、SCRUM Sprint 计划会议二的输出结果

该会议是在Sprint 计划会议一的基础上进行的.

一、会议目的 

    该会议的工作以设计为主。产品开发团队可以为他们要实现的解决方案完成设计工作。在会议的结束，团队知道如何构建他们在当前 Sprint中要开发的功能  
    1.  确定 sprint 长度
        时间短就好。公司会因此而变得“敏捷”，有利于随机应变。短的 sprint=短反馈周期=更频繁的交付=更频繁的客户反馈=在错误方向上花的时间更少=学习和改进的速度更快，众多好处接踵而来。
    2.  确定 sprint 目标
        出于某些原因，制定 sprint 目标确实很困难。但我发现即使是像挤牙膏一样把它挤出来，那也是值得的。半死不活的目标也比啥都没有强
    3.  决定 sprint 要包含的故事
        决定哪些故事需要在这个 sprint 中完成，是 sprint  计划会议的一个主要活动
    4.  定下每日例会的时间地点
    5.  确定 Backlog 中各项的大小. 
    6.  团队成员可以从会议中知道项目接下来的阶段会发生哪些事情。 
    7.  修整Backlog内容：以合理方式分解Backlog各个项目，从而获得更深入的理解  
二、会议时间 

     在 Sprint 中，每周该会议占用时间为 60 分钟。在 Sprint 规划会议第一部分完成后，召开该会议。可以将午餐作为两次会议一个更长久的休息。但是要在同一天完成 Sprint规划会议第一部分  

三、会议准备 

    1. 邀请与会者：
          产品负责人
          Scrum Master
          团队所有成员  
    2. 任务规划时可以参考既定产品 Backlog 
四、会议进程 

    1.  从第一个 Backlog条目开始。  
       确定对于客户的需求理解正确。 
       围绕该Backlog 条目进行设计，并基于下列类似问题： 
       (1)、我们需要编写什么样的接口？ 
       (2)、我们需要创建什么样的架构？ 
       (3)、我们需要更新哪些表？ 
       (4)、我们需要更新或是编写哪些组件？  
       (5)、确保考虑到工作中所有的细节
            编码
            测试
            代码评审
            会议
            学习新技术
            编写文档
       (6)、如果任务需时超过一天,尝试把该任务分割成几个小任务


    2.  当团队明确知道自己应该如何开发该功能后，就可以转向下一个 Backlog 条目了。  
       在会议的最后 10 分钟，团队成员使用即时贴写出初步的任务。这能帮助团队成员知道接下来的工作从哪里开展。将这些任务放在任务板上。不要估算这些任务         
五、会议结果 

    1. sprint 目标。 
    2. 团队成员名单（以及他们的投入程度，如果不是 100%的话）。 
    3. 经过估算的Product Backlog即 sprint 中包括的故事列表）。 
    4. 确定好 sprint 演示日期。 
    5. 确定好时间地点，供举行每日 scrum会议。 
    6. 需要澄清的问题。   

    7. 公司的所有人员都要获得这个已经评估的backlog

       <开发管理 CheckLists> by dyllove98 @开发管理 CheckLists