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、经验教训
-
了解目标
-
不断实验
-
拥抱失败
-
解决真正的问题
-
拥有专职的变革推动者
-
让人们參与进来
看板管理典型的一天
版权声明：本文博主原创文章，博客，未经同意不得转载。