过程改进日记之学习Scrum2010-9-30：Sprint4最后一天，思考Bug看板的应用价值

今天的“Sprint4”最后一天，先说下这几天晨会的情况

   第一天：严重程度为1、2级的Bug做为任务上看板，我们觉得效果很不错，工程师讨论bug有明确的针对性。
   第二天：UI方面的Bug、优先级在3级以上的Bug更新到看板上，虽然抄写量并不大，但是下班前抄一次，晚上工程师加班又增加了一些，加上状态变更，次日晨会看板上就不是最近信息了。

   第三天：UI这边的问题没有变更，另外一主要工程师请假。看板逐渐失去作用。

   今天，又一主要工程师请假，PM家里有事请假，Test生病了要晚些到。剩下的工程师有两个说昨天收工了。

   看这样子今天真的可以空下来了。另外请假工程师一份必须完成的修改转移给另一工程师。今天要把产品交付给客户，因此，没把握的修改就不做了。

 

 

这次是Scrum实践以来，第一个没有达到预期目的的动作，出现的情况在上面写着了。

这次“Sprint4”并非真正的Scrum实践，他没有经过完整的计划和任务分解，只是使用了看板。

 

从效果来看来说，Sprint4的看板第一天有不错的效果，后面效果越来越弱，说明以bug来做为任务标杆，存在一个问题，就是变化频率太高，一个bug可能是当天发现，当天修复，而看板的更新周期是24小时，这样一来，看板的更新更不上节奏了。

 

仔细看了下《硝烟中的Scrum和XP》， 第14章，我们怎么样做测试。

呵呵，有几句话很有价值，我节选一部分

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

“ 这是最困难的部分。我不知道它到底是只是  Scrum  中最困难的部分，还是在软件开发中通常都是最困难的部分。”

“ 在不同组织的各种开发活动中，测试可能是差异最大的。它依赖于你有多少个测试人员、系统类型（只是服务器+web 应用，还是交付完整的软件？）、发布周期的长短、软件的重要性（博客服务器vs.飞行控制系统），等等。”

 

验收测试应该作为 sprint 的一部分么？

我们在这里分歧较大。有些团队把验收测试当成了 sprint 的一部分。
但大部分团队都没这样做。原因主要有两点：

1. Sprint 是有时间盒限制的。验收测试（在我的定义中，它要包括调试和再次发布）的时间却很难固定。如果时间用完了，你还有一个严重的 bug 怎么办？是要带着这个严重 bug交付上线，还是等到下个 sprint  再说？大多数情况下，这两种解决方案都是不可接受的。所以我们把人工验收测试排除在外。
2.  如果有多个团队开发同一个产品，那就得等所有团队的工作成果合并以后，再进行人工验收测试。如果每个团队都在 sprint  中进行人工验收测试，最后还是要有一个团队测试最终版本，而且这个版本集成了全部团队的工作。

这个解决方案不算完美，但对我们来说，已经可以满足大多数情况的需要了。 

……

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－  

这些其实我看到过，只不过看得时候觉得理所当然，没有去思考，现在走过了一遍，觉得这里面有很多不确定的。

一、测试阶段的开发人员的任务如何定义

假设开发人员完成了开发（含代码检查、单元测试等等），后面就是等测试人员发现问题并修改了，那么，如何编写开发人员的任务？

在bug积压较多的情况下，比较容易计划，但如果手头Bug不多，或者随时可以响应测试人员的Bug。是否还有必要按照Scrum的方式管理。

二、如何减少回归次数

理论上通过自动化测试可以提高回归测试的速度，但系统测试阶段要经历几轮回归测试才可以却是个无解的命题，和一切资源、能力都相关。

我之前觉得使用Scrum有助于减少回归次数，我遐想给Bug一个合理的修改顺序，就象任务的依赖项一样，可以用更优路径，来执行回归测试，来验证更多Bug。

但从实践看，是否选择更优的回归测试，重要的并不是立会、看板这些形式，而是对软件更好的把握。

明天就是10.1假期了，昨天发了培训通知，居然无一报名，受伤了

下周等这帮家伙回来，挨个去刺激下那些号称努力想寻求改变的家伙们……