1、项目背景
2、组织团队
3、每天出席鸡尾酒会
上面的会议通常持续10-15分钟，由团队主管(ScrumMaster)主持，一般问就下面3个问题展开。
- 我昨天做了什么工作？
- 今天打算做什么?
- 遇到了什么麻烦？
所有测试人员都聚拢在测试状态板前，讨论如何最好地利用当天的时间。隶属于具体功能开发团队的测试人员刚刚跟各自所属的团队开完立会，所以他们可以分享各个团队的最新进展。
与此同时，需求分析团队则在开他们自己的同步立会。刚刚跟功能开发团队开完立会的分析人员也来参加会议，他们有最新的信息可以向整个需求分析团队汇报。
参加项目同步立会的人员被称为交叉型团队。我们在这个项目里，就是每个专业派一个代表，每个功能开发团队派一个代表，再加上其他几个人，比如项目经理、配置经理和我自己。
我们在项目同步立会上审视整个项目的状况，主要关注从需求分析到投入生产的各个工序是否正常运转：
- 每个团队今天在做什么？
- 现在有什么问题阻塞了我们的流程？
- 瓶颈在哪里？
- 如何消除瓶颈？
- 下一个瓶颈会出现在哪里？
- 我们的发布计划进展是否顺利？
- 有没有人不知道今天要做什么工作？
4、项目进度板
这个体系看上去很像瀑布开发模式。其实不然，在看板系统中，这些不同的阶段都是并行的。
不能把所有的任务板塞满。
用警车标出需要特别快速处理的紧急事项。
用粉红色便利贴来标示障碍。
5、扩展任务板
随着项目成员增加，每个团队成员都有自己的任务看板，显示团队自己的工作进度。但是却不清楚项目的整体状况。
- 项目整体进展如何？
- 现在的瓶颈在哪里？接下来会有哪些新功能？
- 到这次版本发布的时候，哪些功能可以按时完成？
6、跟踪总体目标
如果人人都清楚总体目标是什么，就会更关注总体目标。
7、定义“可供”与“完成”
最重要的两个定义是“可供开发”和“可供系统测试”，因为这两处是我们以前出现问题最多的地方。一个功能进入可供开发状态，就必须具备以下特点:
- 必须有一个ID。
- 必须有一个联系人。
- 必须对客户有价值。
- 必须经由团队估算。
- 必须将验收测试情景写在功能卡背面，即描述典型测试情景的具体步骤。
可供系统测试：
- 验收测试自动化。端对端功能层次的验收测试或继承测试已自动化。
- 通过回归测试：对现有功能运行的所有自动化测试都要通过。
- 已演示过。
- 清楚填写签入注释。
- 在开发环境中测试过。
- 已与代码主干合并。
8、处理技术事故
9、处理Bug
10、持续改进流程
- 透明度：在显眼的地方设置看板，向所有人展示项目工作进展。交付物目标明确，人人都能明白。
- 沟通：各个团队内部以及跨团队层面定期召开流程改进研讨会(每周或每两周)。
- 数据：跟踪一些简单地衡量标准，看流程是否有改进。我们衡量的是速率和周期时间。
流程改进提案示例
11、管理在制品
只有4栏work in process。
12、捕捉并使用流程度量
流程度量非常有用，可以找出哪里需要改进，看出我们所作的变更是否带来了积极的效果。对于从宏观上规划版本发布大纲也很有用。我们追踪以下两个流程度量：
- 速率(每周功能数)
- 周期时间(每个功能的开发时间)
- 可将其用作现实检查工具，检验版本发布计划是否切实可行。
- 根据这一数据来预测截至某个时间点大致可完成的功能数。
- 稳定速率：每周的速率应大致相同，而不是分布不均。
- 提高速率：我们目前的平均速率是3，目标是5。
- 缩短周期时间：我们的平均周期时间是6周，目标为2周。
13、Sprint版本发布规划
- 需求清单梳理
- 挑选前十个功能
- 商业价值
- 知识
- 资源利用
- 依赖关系
- 可测试性
- 为何将需求清单梳理工作移出Sprint规划会议
- 规划版本发布
14、我们如何做版本控制
主干无垃圾
团队分支
系统测试分支
16、经验教训
- 了解目标
- 不断实验
- 拥抱失败
- 解决真正的问题
- 拥有专职的变革推动者
- 让人们参与进来
看板管理典型的一天
时间： 2024-10-13 11:30:17