日志
过程改进日记之学习Scrum2010-9-30：Sprint4最后一天，思考Bug看板的应用价值
热度 2 ||
今天的“Sprint4”最后一天，先说下这几天晨会的情况
第一天：严重程度为1、2级的Bug做为任务上看板，我们觉得效果很不错，工程师讨论bug有明确的针对性。
第二天：UI方面的Bug、优先级在3级以上的Bug更新到看板上，虽然抄写量并不大，但是下班前抄一次，晚上工程师加班又增加了一些，加上状态变更，次日晨会看板上就不是最近信息了。
第二天：UI方面的Bug、优先级在3级以上的Bug更新到看板上，虽然抄写量并不大，但是下班前抄一次，晚上工程师加班又增加了一些，加上状态变更，次日晨会看板上就不是最近信息了。
第三天：UI这边的问题没有变更，另外一主要工程师请假。看板逐渐失去作用。
今天，又一主要工程师请假，PM家里有事请假，Test生病了要晚些到。剩下的工程师有两个说昨天收工了。
看这样子今天真的可以空下来了。另外请假工程师一份必须完成的修改转移给另一工程师。今天要把产品交付给客户，因此，没把握的修改就不做了。
这次是Scrum实践以来，第一个没有达到预期目的的动作，出现的情况在上面写着了。
这次“Sprint4”并非真正的Scrum实践，他没有经过完整的计划和任务分解，只是使用了看板。
从效果来看来说，Sprint4的看板第一天有不错的效果，后面效果越来越弱，说明以bug来做为任务标杆，存在一个问题，就是变化频率太高，一个bug可能是当天发现，当天修复，而看板的更新周期是24小时，这样一来，看板的更新更不上节奏了。
仔细看了下《硝烟中的Scrum和XP》，第14章，我们怎么样做测试。
呵呵，有几句话很有价值，我节选一部分
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
“这是最困难的部分。我不知道它到底是只是 Scrum 中最困难的部分，还是在软件开发中通常都是最困难的部分。”
“在不同组织的各种开发活动中，测试可能是差异最大的。它依赖于你有多少个测试人员、系统类型（只是服务器+web 应用，还是交付完整的软件？）、发布周期的长短、软件的重要性（博客服务器vs.飞行控制系统），等等。”
验收测试应该作为 sprint 的一部分么？
我们在这里分歧较大。有些团队把验收测试当成了 sprint 的一部分。
但大部分团队都没这样做。原因主要有两点：
但大部分团队都没这样做。原因主要有两点：
- Sprint 是有时间盒限制的。验收测试（在我的定义中，它要包括调试和再次发布）的时间却很难固定。如果时间用完了，你还有一个严重的 bug 怎么办？是要带着这个严重 bug交付上线，还是等到下个 sprint 再说？大多数情况下，这两种解决方案都是不可接受的。所以我们把人工验收测试排除在外。
- 如果有多个团队开发同一个产品，那就得等所有团队的工作成果合并以后，再进行人工验收测试。如果每个团队都在 sprint 中进行人工验收测试，最后还是要有一个团队测试最终版本，而且这个版本集成了全部团队的工作。
这个解决方案不算完美，但对我们来说，已经可以满足大多数情况的需要了。
……
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
这些其实我看到过，只不过看得时候觉得理所当然，没有去思考，现在走过了一遍，觉得这里面有很多不确定的。
一、测试阶段的开发人员的任务如何定义
假设开发人员完成了开发（含代码检查、单元测试等等），后面就是等测试人员发现问题并修改了，那么，如何编写开发人员的任务？
在bug积压较多的情况下，比较容易计划，但如果手头Bug不多，或者随时可以响应测试人员的Bug。是否还有必要按照Scrum的方式管理。
二、如何减少回归次数
理论上通过自动化测试可以提高回归测试的速度，但系统测试阶段要经历几轮回归测试才可以却是个无解的命题，和一切资源、能力都相关。
我之前觉得使用Scrum有助于减少回归次数，我遐想给Bug一个合理的修改顺序，就象任务的依赖项一样，可以用更优路径，来执行回归测试，来验证更多Bug。
但从实践看，是否选择更优的回归测试，重要的并不是立会、看板这些形式，而是对软件更好的把握。
明天就是10.1假期了，昨天发了培训通知，居然无一报名，受伤了
下周等这帮家伙回来，挨个去刺激下那些号称努力想寻求改变的家伙们……
