敏捷开发的改进

酝酿这个改进已经很久了，但一直没有找到合适的时机，另一方面，这样的测试策略，颠覆了传统的测试模式，是否要应用这么大的改动，我自己心里挣扎了很长的一段时间。同事看出了我的犹豫，对我说：“改革，是需要有勇气的。”我知道，我的开发同事们都非常乐意看到这样的改变，与他们聊天，几乎每个人都无法忍受旧的测试策略，一听到要这样改，每个人都喜形于色。但，从传统的测试角度来说，这样的变动几乎颠覆了我在以往项目的测试理念。打电话跟朋友聊了很多次，他对我说：“大家的呼声这么高，总是要试一试，试过才知道对错。”是的，传统的测试理念总是要试着去打破的，固守着一种理念一种策略，自然不会有错，但绝对不会有质的变化。

改进，不能因为要改而改，也不能因为上面或周围的压力而改，既然要改，就一定要看到改的理由和效果。于是，开始查阅 agile testing 的资料，原来，我们一直在用传统的测试模式做敏捷开发的测试，很有意思的是，自己的一些想法居然与书上的经验不谋而合；更有意思的是，原来测试人员可以在敏捷测试中承担更多的责任，在以往，很多人，特别是老板们，会以为在敏捷开发中不需要测试人员。在过去，我经常被问到一个问题：“开发也能做测试，为什么还需要测试呢？增加测试人员，无疑会增加成本，与其这样，为何不让开发承担测试的责任？至少我们可以减少了测试与开发之间的沟通成本，我们不能再回到以往的需要大量的测试人员的模式。”听到这样理直气壮的反问，我真的有点气短，这样的气短，归根到底是自己没有这方面的经验和理论做支撑。现在，如果再有人会这样反问我，我一定也会理直气壮的回答他在敏捷开发中测试所扮演的重要角色。至于测试人员在敏捷开发中应该承担怎样的责任，可以发挥怎样的作用，先卖过关子，等实践证明起作用了再来总结 ：）

对于每个改变，我总是习惯从 team 中收集意见，也习惯将自己的想法与他们去讨论，因为，任何的改进，如果没有大家的支持，开展总是很难的，这就是所谓的群众基础。很感谢这些可爱的同事们，在将近下班的时候被我抓住，然后给了我很多很好的启发。在过去的半年，我们相互挑剔相互改进。有时，事情不能往预期的方向发展，压力大了，我对着他们中的某个人说：“哎呀，我的压力很大呀，被你们 challenge 得不行了。”他们中的某人会马上反驳：“是我得压力大，被你 challenge 得不行了好不好？”有时候，愁眉苦脸的对着另一个人说：“我真的从来没有那么大的压力，你看我的黑眼圈，都是被你们害的。”“大家都只是想事情往更好的方面发展，大家说出来才好，不然哪有改进的空间？质量不是你一个人的问题，你压力大什么。”很的很感谢这些同事，虽然给了我压力，也给了我提高的空间。其实，所谓的极致，就是一个追求完美的人与一群挑剔的人的碰撞。

花了整整一周，草稿敲定。有了上次 presentation 失败的教训，与同事一起，花了整整两天，将草稿整理成一份漂亮的 PPT 。这几天的会议特别多，终于在夹缝中挤出了时间与 partner 一起给负责 improvement 的 manager 展示了我们的想法，我们的 manager ，很细致的跟我们讨论了具体的测试策略，大体上我们达成了一致的意见。当然，我们还是有些东西需要改进，不过，总体的思路得到认可。因为要到外地培训，周末跑回公司，花了一个晚上再把 PPT 好好的改了一下，培训完马上又飞了回来。多得 manager 的细致和专业，在向 management team 做 presentation 之前，我们内部做了多次的讨论和改进，直到开会的前两分钟，我们还在讨论如何可以做得更好。这也是另一种极致，我喜欢。

好了，前面做了那么多的准备，终于到了见老板们的时候了。因为准备得比较充分，很自信的开讲了，虽然英文还是没有讲得太好，但至少把新的测试策略清楚的展示了出来，对他们的提问和 concern ，也一一做了解答。这次的改进，终于没有像上次的那样，在 meeting 中遭遇 challenge ，而是被认可了。接下来，就是在项目中实践这些新的策略了，是否能有意想不到的收获，拭目以待。

下班走在回家的路上，人虚脱了的累，才想起中午忙得连午饭也还没吃，虽然是短短的两个小时的 presentation ，花的心思的时间是两小时的 N 倍。

 

 

 

                     Written by smilings in GuangZhou, December 2, 2009