猪少爷的奋斗

今天和ThoughtWorks顾问重点讨论了一下测试。目前的阶段开发、测试都在思考一些准备性的工作。道雨兄一直对于可测性需求关注度比较高，之前和他在一个组里进行培训时，已经多次在不同场合提到这个话题，可以感受到他的疑惑。因此在当下思考测试策略的时候再次浮出水面也就不足为奇了。当客户需求将开发日程表排到溢出的时候，突然冒出来的可测性需求宛如寂静的会场上大笑数声，让大家都有些尴尬。排了也痛，不排也痛，

全天主要就测试的多个方面进行了开放式的讨论总结。先就题目进行分两组总结，然后由顾问提出ThoughtWorks的一些思考。两厢对比。所有内容本身不涉及具体的实践，只将这个领域的问题通过讨论引起大家的思考和关注。关于测试的成本，TW认为有如下因素a)无效性引入的成本：包括用例的无效、工具的无效。b)团队沟通引入的成本：比如部门壁垒引起的，异地配合产生的，不同部门的进度规划不一致造成的。c)设计依

<br />     3.0研讨会议QA过了一下敏捷实践的实施现状，结对编程这一项基本都废了。取而代之的是代码检视。最近一个月也确实不断收到来自各小组责任田的抄送的检视邀请和检视成果邮件，显示活动开展的如火如荼。不过总觉得PP和纯检视有点差异，按照XP的理解，PP就是对代码检视的极致化，一直没想明白直觉哪里出问题了。今天下班早了点，在公交上晃来晃去终于想明白了一点。PP除了即时的检视之外，还有即时的思路碰撞和讨论。这些决定了代码的实现走向。但是检视会议这种活动从历史经验来看，大多数是就代码本身而言进行的挑刺

这几天在老王的带领下仓促的飞赴深圳，马不停蹄的走访了6个部门3个老大，每次都说要控制好交流时间，每次都是一开闸就收不住了。大家都是心中有很多感受和疑惑希望从对方获得回应，可以说是宾主尽欢。 业软这边的特点是对需求之痛感受比较深，因此在FRS上投入了很大的精力，在管理优化报上也有文章。目前对特性(Feature)的定义已经达成共识：外部用户能感知到的功能。（这个定义在今天上午另一个交流中

今天的课程在迭代1回顾会议上，第3组一个学员向我抛出问题，结对编程到底有什么好处？老师你不觉得很浪费人力吗？嗯。是啊，为什么要采取这个实践呢？这个问题其实说来应该是被无数人在口头上在心底里问过了一百遍啊一百遍。 我的回答是3个：第一、思路的碰撞；第二、实时的检视，这个经典的说法就XP的“检视到极致”，嗨，人家也知道；第三、我自己的体会，人的背景不同，技能技巧有不同，在结对过