日志
过程改进日记之学习Scrum2010-12-10 缺陷菜场
热度 4 ||
有一段时间没更新了，年休外加工作一忙耽误了，于是热情就削减了，感谢老漂和诸多思友的督促，先为自己的懒惰认个错，我不应该偷懒的，谢谢监督我的童鞋。
N产品－成果和新目标
N 产品上个月通过给客户的DEMO，获得了客户的一部分研发费用。Team接下来的目标是更稳定的产品，这样可以向更多目标客户发放评估版本，便于客户在CES2011中展示N产品的运行效果。
老大及时的把这些公开发布给事业部全体，Team在某个工作日下午在老大的亲自带队下提前下班一起去桌游吧玩了把（桌游的好处是跨界头脑风暴，补脑，强烈推荐）。
开心之后，继续投入工作，新的Sprint目标是产品化，质量标准从DEMO到Eval（DEMO是我们操作给客户看，Eval是客户自己评价）。
产品化包括安装、自动更新、整合驱动，以及更多用户交互逻辑优化、界面文字校验等等，有一些相对完整的处理机制，但另一方面，质量标准的提高意味着更多的缺陷需要被修改。
缺陷菜场
以前的实践是把高优先级的缺陷抄写出来，做为任务处理，按照Not Check Out→Checked Out→Tobe Verified→Done的生命周期操作。
这个实践虽然虽然缺陷比较多，抄写起来费劲了点，效果还是不错的，之前有几篇日志都讲述了这个过程。在Sprint5和Sprint6两次迭代，累计修改的bug超过100个。
－－－－－－－－－－－－－－－－－－－－
但这次情况还是有些超出我的预料，早上立会，QA拿出厚厚一叠抄写着bug的便贴纸（顺便夸一下Tester，主动抄写bug，再也不劳烦我们了），QA已经为每个缺陷指定了开发工程师。我事后查询了一下禅道系统，所有优先级为1、2级的bug加起来有70余个，其中不乏之前来不及啃掉的硬骨头。
开发工程师们也顾不上排队一个个讲了，干脆各自拿了一部分一张张看，有些看不明白的就抓住测试工程师问，也有不了解如何修改的问DPM、交互相关的也问PM，光这个过程就持续了将近15分钟，而且非常投入的捉对讨论。
这已经不是立会的秩序了，SQA MM在之前已经告假去准备C Team的看板去了，我留守在N Team，看着他们投入的讨论，真是有点无序的感觉，我突然想到了一个词“缺陷菜场”
这个场景太像菜场，工程师们在看板前挑拣着Bug，并提出各种问题来获得更多信息，以便更好的甄别Bug的价值，以及需要修改的代价。而QA、PO和DPM的表现则混合着菜贩、工商、资深马大嫂的特征。
那我应该制止这种行为并让大家回复到Scrum立会的典型模式－一个个有序汇报？
这样的话，那我的行动岂不是类似于－城管？
再次思考－Scrum之于系统测试阶段
Scrum框架是否适合系统测试阶段？
我的想法是：
- 第一：Scrum的行动特征本质上是PDCA，只不过为PDCA增加了一个TimeBox的约束，无论项目有什么样的差异，没有理由不适用PDCA。因此，我认为并没有什么特殊性使得Scrum实践给项目带来负面作用。
- 第二：每个人掌握的信息不同，Scrum的立会的核心目标是使得所有人的信息能够在这个平台上获得同步和汇总，比如PO来自市场的信息、各任务的进度、产品的质量情况等等。信息传输和同步的效率是立会需要关注的，而形式上的秩序则不必过于介意。
Scrum立会中大量的讨论，先问一些为什么，以便帮助思考
- 为什么出现集中讨论的场景－因为之前大量的缺陷并没有得到足够的讨论。
- 为什么之前没有得到足够讨论－因为做DEMO的时间很紧张。
- 为什么做DEMO的时间很紧张－因为有更多不确定的问题
- 为什么不确定问题很多－因为这是全新产品，积累不够，未知因素很多
那么，N 产品下一个半年，应该不是新产品了，会出现这样的情况吗？我对这些原因推断觉得不可信，因为我们的观察对象太少了，这个问题留待将来再观察。
需要继续思考系统测试阶段的工作，如何更敏捷些。寻找真正的规律和方法
