Download as PDF, PPTX
Uploaded byYi Xu
银弹！银弹！ 徐毅@Italk salon 2011
文档介绍了作者在敏捷转型和测试自动化方面的经验，强调团队在Scrum中与产品负责人的互动和承诺的重要性。还讨论了任务分解、进展管理和如何有效进行每日站会，以提升团队的协作和效率。最后，提到了一些信号和工具，以帮助团队更好地应对项目中的挑战和风险。
More Related Content
银弹！银弹！ 徐毅@Italk salon 2011
- 1. * 特别鸣谢Paul Nagy！
- 2. 关于我 曾任职诺基亚西门子网络公司 全球精益及敏捷转型部门担任精益 及敏捷顾问。 专长于大型组织(>500人)的敏 捷迁徙转变。精通各种风格、类型 的黑盒测试，包括验收性测试驱动 开发、探索性测试、测试自动化等 等。在辅助一个400人的大型组织搭 建、规范化测试自动化系统及实践 之后，选择传授敏捷/Scrum以及精 益的要义，辅导其他组织进行转变。 兴趣广泛，包括但不限于各种类型 测试、敏捷/Scrum及精益。 国内敏捷会议的常客，近期的 有敏捷中国2010，Scrum Gathering Shanghai 2010，以及2009、2010 年的敏捷全球之旅中国站活动。 更多信息请看LinkedIn主页： http://cn.linkedin.com/in/kaveri
- 3.
- 4.
- 5. 产品负责人（PO）问团队: 你们能承诺做完吗？ 无人应答。 Scrum Master朝大家看了看，然 后扭头朝向产品负责人 当然，我们能！
- 6. * Scrum Master不是团队的经理。 向PO承诺的，是团队，而不是 Scrum Master。
- 7. 产品负责人问团队： 你们能全部搞定吗? 团队： 够呛，这么多恐怕我们做不完， 这样吧，我们可以都接下来， 但是特性6要作为“未承诺 ” （uncommitted） 的。
- 8. 产品负责人决定做什么（What）， 团队确认他们能否完成。 如果团队还剩下一点点儿时间没有用完，不 必强求，随它去不用理会，因为在Sprint过 * 程中，如果团队 - 已经完成承诺的所有特性 - 还剩下一定量的时间可以干活 他们还可以叫上产品负责人，再选择些特性， 利用Sprint剩下的时间继续把它们完成。
- 9. 用户故事： “作为产品负责人，我真的需要 团队按时完成。” 或是 “作为发布经理，我需要团队为 特性A和B执行集成测试。” 诸如此类。。
- 10. 独立 可测 可协商 *INVEST 用户 作为 <某类型用户> 我需要 小 有价值 <某软件特性> 以满足 <需求或动机> 可估量 Independent, Negotiable, Valuable, Estimable, Small, Testable
- 11. 用户故事： “为2.0版本产品系统 升级安全性补丁” 问：哪些补丁？ 答：团队可以决定。
- 12. 确保产品负责人参加Sprint计划会议的时候， 带来的产品Backlog状态良好： 颗粒度分布均匀，用于当前Sprint备选 的需求相关信息足够详细，例如，小颗 粒用户故事 * Backlog Grooming会议 Sprint进行到四分之三的时候举行。 产品负责人和所有团队成员都必须参加。
- 13. 将软件特性分割到任务级别的过程，有 些团队很有心得研究出一套固定招式： • 设计 • 编码（包含单元测试） • 测试 • 测试自动化 • 和团队A确认相关技术细节
- 14. 所有团队成员协同作战，在白板纸上以草稿画、 文字记录等方式，描绘出团队整体对所选软件 特性的理解，从而可以综合开发及测试等多方 面的思维来分析、理解所选特性。 *
- 15. 任务的分割 测试自动化相关的任务很难估 计完成任务所需的小时数， 但是敏捷教练告诉我们如果 任务的估时超过16个小时是 不好的，所以我们得要分割 相关任务……
- 16. 有哪些可接受性测试用例？ 是不是测试环境很难配置？ * 是否要使用外部测试设备？ 是否要开发测试辅助程序？ 是否要开发测试夹具支持？ 等等
- 17.
- 18. Scrum Master （环顾四周）张三，就从你开 始讲吧。 …… （看着王二）我看这样吧，这 Scrum Master 个事情你先继续做，回头再和 周四联系一下，把实验室地问 题解决掉。 ……
- 19. 任务分派 掌握进度 风险管理 团队 * 应对团队自己 无法处理的 障碍、拦路石 留意人际方面 关注同时并行 问题或冲突， 的任务数量 并着手解决 Scrum Master 每日站会
- 20. 团队成员： 昨天我修复了一个bug。 今天我继续修改别的bug。 或者： 今天早上我开始做测试，但是 被测系统很难连，连接很不稳 定，我叫实验室维护的人来帮 忙了。一直弄到下午我才可以 真正开始测，有点晚了，所以 还没做完呢。明天我继续做这 个测试。
- 21. 关注团队的进展 基于任务更新状态 * • 完成尚需要的时间 • 有没有遇到什么惊喜 • 是否有新的收获（相关领 域或软件系统）可以分享？ • 有什么值得一提的状况告 诉大家？ • 是否需要帮助
- 22. 团队成员 （任务A：8小时） 第一天：没有阻碍，我正在做， 再2个小时应该能做完。 第二天：调试过程遇到些麻烦， 不过我在处理，问题不大，应 该还有2个小时吧 第三天：……
- 23. 使用燃尽图 应对不如意的进度 明晰状况 • 发生了什么 • 有什么影响 • 有没有偏离 * • 该做些什么
- 24. 团队成员们希望能够将每日站会改成 每周开两次。 他们的理由很充分： •没人关注我承接任务的状况 • 我对别人的情况也没兴趣，因 为不太能理解他们所说 • ……
- 25.
- 26. 直线经理（刚刚上任） “有个团队成员被任务A（估时： 6小时）给困住了，都三天了， 他还没能完成。其他人都忙着改 bug。而任务B又依赖任务A的完 成。” “我觉得也许我们需要弄一张甘 特图，来控制任务间的依赖。” 问题：先看一下你们的燃尽图吧。 回答：那玩意儿没用，我们没用。
- 27. * • 可视化管理 • 团队身边可视化、触手可及的信息 • 让团队知晓你遇到的阻碍，并尽快地 寻求帮助以解决问题 • 利用燃尽图来暴露进度上的问题
- 28.
- 29. DONE 问题：那么这个特性已经DONE了？Conditionof Satisfaction的状况如何? 回答：这个记录在产品Backlog管理系统里的。 （打开工具……） 问题：这就是你们的Condition of Satisfaction？！！ 回答：是啊……就是写着的“系统模块验证测试完成；QC内容更新；单元测 试覆盖率高于90%。”
- 30. * Condition of Satisfaction Definition • = Confirmation of Done （用户故事3C之一） • ≈ 可接受性测试 Condition of Satisfaction 它是 • 特性的行为表现细节 • 特定场景下用户期待的结果
- 31. DONE与演示 问题：DONE了几个？ 回答：呃，都没DONE 问题：那就是没有演示喏。 回答：但这不都接近DONE吗……
- 32.
- 33.
- 34. 团队 “我们的任务估算很有问题！ 总是估少了。”
- 35. 能力不足、缺乏经验 • 和技艺娴熟的同事结对 • Backlog Grooming会有帮助 未及时发现风险 • 在每日站会上发掘潜在风险 * 任务分派 • Sprint计划会议时共同完成概要设计 团队新成员 • 和技艺娴熟的团队成员结对
- 36.
- 37. 笔记本会议 • 人们多数时间都在摆弄电脑 • 不注意听别人讲话 •并非所有成员都理解最终的决定 • 你需要和他们挨个核查情况 • 需要某人发言时必须明确地指明 向他/她提问
- 38. * • 每一个人都要表达他们的观点 • 关注会议的目的不偏离 • 推动畅所欲言的文化 • 鼓励有益的（建设性）冲突
- 39.
- 40. mailto:YI.XU@HP.com mailto:KAVERJODY@GMAIL.com mailto:KAVERJODY@MSN.com Skype : KAVERJODY 新浪微博: 徐毅-Kaveri 腾讯QQ : 17376122 http://blog.sina.com.cn/kaverjody http://cn.linkedin.com/in/kaveri http://kaverjody.wordpress.com *谢谢！