窦涵之谈ATDD及CI的整合

个人简介 窦涵之，目前在诺基亚西门子网络通信工作。

Shanghai Scrum Gathering是由Scrum Alliance赞助的Scrum上海聚会，已于2010年4月19日-20日在上海举办。这是Scrum Alliance官方第一次在中国举办的Scrum聚会。

   

1. 好，窦先生你好。今天很高兴您能接受我们的采访。首先您能向大家简单的做一下自我介绍吗？

好，我叫窦涵之，目前在诺基亚西门子网络通信工作。主要做一个通信产品，担当的是产品负责人（注：Product Owner，Scrum中的一个角色）的职责。目前大概有15个Scrum团队，开发的是一个网元级的产品。

   

2. 那么在这次的Scrum Gathering上，您的这个演讲 是关于ATDD（Acceptance Test Driven Development，验收测试驱动开发） 和CI（Continuous Integration，持续集成）的。为什么要把这两者放在一起呢，它们之间有什么样的一种关系？

目前就是讲ATDD，这个大家也可以看到，在很多的推广的实践当中，都在讲这个ATDD的一些做法，CI也有一定的做法，那怎么样保证就是在实践当中，我们真正的能把我们的产品，能够实际用起来？那我个人觉得呢，只有两者结合起来才能发挥他的一个作用。ATTD主要是从用户的角度，即得到的东西就是客户想要的，那CI就是Continue Integration（持续集成），主要就是保证，Delivery（交付）的东西具有完整的功能，是一个真正可用的，而不是每个独立的测试过的模块，然后并不能够完整的呈现出来客户想要的东西。因为ATDD如果在一个大的组织里边，那没有很好的应用起来的话，可能会出现：每个人都声称自己是用的ATDD，但实际上他的着眼点并不是从整个产品或者系统的角度来看待，那Continue Integration（持续集成）就保证了整个产品不管是谁开发的，只要属于这个产品的一部分，那就可以放在一起去测，然后拿到的，就是一个完整的，经过充分的客户角度验证的一个产品，这就是如果结合起来，才能够保证：不仅仅是开发，同时发布的时候是很有信心的。

   

3. 好的，那么我们也经常会提到持续的这种改善，所以有很多的团队也许不能够同一时间把所有的新的东西都放到自己的这个团队的改善中去，那么这种时候比如说在ATDD和CI之间，如果他们必须做一个取舍，那么你建议他们首先先去做哪一部分呢？

我的建议是，先去把这个持续集成建立起来。因为持续集成，只有软件集成在一起，就会暴露出很多的问题，这样为了解决这些问题，你会寻找方法去解决。比如持续集成刚开始做的时候，一般的团队来讲，都会发生，第一步你去做集成的时候，会发现你放在一起，人数一旦多了，边界都通不过，这是非常普遍的一个问题，你可能会花好长时间去解决这个边界问题。

然后可能过了一段时间之后，这个边界问题是解决了，然后更高一层的这个测试，比如基本的功能测试，这个（Testing测试）刚开始也是这样，我这个团队，比如每个团队都说，我这个团队（功能好了，那个团队（说功能也好了，大家放在一起，那放在一起发现不工作，那这又进一步。那要想使这个功能工作，那就ATDD，实际上你就会想，要让整个产品功能完成，那团队之间怎么样才团队能够合作呢？那肯定要从一个客户的验收角度来讲需求，也就是大家常说的用户故事（User story）。这个用户故事要贯穿的是整个验收层次的故事，不是说团队层次（团队层次） 的用户故事，这样的话你就会慢慢的意识到ATDD它会介入到这一块里面来。也就是说我发现有一个用户故事，然后通过测试发现这个故事不工作，比如说有三个团队（团队），其中两个团队（团队）没有问题，另外一个团队（团队）有问题，那这就需要有新的开发，或者去解决老的一些功能，把这个故事就是真正的能够通过。所以这个它们之间实际上是一个自然的一个过度。

   

4. 所以就是说其实在CI的过程中，可能自然的就会有这种ATDD的要求？那么在这样的一个过程中，其实PO的角色应该是非常非常重要的？那么这方面你是怎么理解的？

PO吗，作为一个产品的负责人，那我个人一直理解，PO不仅仅是，将比较大的高层次的需求告诉团队（，作为什么什么，比如说作为产品负责人，我希望什么，不仅仅是如此，就是说整体上对这个产品的愿景，比如说，今年开发，明年开发，实际上，产品负责人应该具有长期的愿景，这个产品最终要做成什么样子，虽然PO不是产品架构师，但要理解整个产品走向是什么，那这样的话，就是说PO能够真正的理解用户要的是什么，然后把它分解成相对短期的一步步的目标。

   

5. 对，所以就是说它其实是一个很关键的角色，它控制整个的大局？

是的。

   

6. 好的，那么在您的这日常的实践中，现在使用在ATDD和CI的这个项目大概是有多大，大概有多少人？使用多少？

现在是100个人左右。

   

7. 在15个Scrum团队？

对，15个Scrum 团队，100个人左右。然后这些团队，因为人比较多，Scrum 团队也比较多，也不是由我统一管理所有的这15个团队，团队那我们有一个Product Owner的团队。目前这个团队是这样组成的，那我作为整体上的产品负责人团队主管领导这个小的产品负责人团队，那我自己也带了有几个Scrum 团队。然后另外有两个产品负责人他们也是带团队（团队）的，每个人都带几个团队Scrum 团队，还有两个也在产品负责人 团队里边的，一个呢，我们可以叫他是首席架构师（Chief Architect），负责整个产品的软件架构。另外一个呢，就是比较侧重于这个软件测试方面的。那这样，我们组成一个团队，不仅仅说产品负责人 团队里面的都是带团队的。那这样，至少在目前这个环境下，整个产品负责人 团队不仅仅只是把需求搞清楚了，整个产品的架构，包括测试、战略都是在一起讨论清楚，然后其他的所有人都在Scrum 团队里面，通过一些网络或者我们叫实践社区（Community of Practice）这种方式联系起来。

   

8. 那么其实就是说产品负责人 团队，您是在最上面负总责的，一定还是有这样一个人，因为有些人认为这个产品负责人 的委员会是无效的，最终会不会出现这种问题，比如说其他的产品负责人之间有一些意见相左的时候，那么最终需要你来决定的？

这个肯定是这样的，不管怎么样一个团队，它肯定是有这种各种各样的冲突，各种各样不同的意见，实际上这是一件好事情，因为是从不同的角度看待这个问题。如果大家意见都是始终是一致的，实际上就说明你这个不需要一个团队了，一个人就够了，团队是多个不同的角度去思考这个问题，那才会带来好处。我们会有定期的会议，包括眩晕（dizziness） scrum，比如说在出现问题比较多的情况下，变化特别频繁的时候，那我们这个产品也是这样，这是不同的硬件，然后真正的产品的话，也是不同的产品发布出去的时候，那变化很多了。这个变化每个人理解也会有一定的不同了，那我们通过这种定期的会议，定期的scrum，dizziness scrum，短桥短会来沟通这些问题。

   

9. 好的，那么我不知道您在其他的一些环境中有没有说利用过这个ATDD或者CI的这种模式，包括我本人，比如说我是在这个数据仓库的这样一个行业里，那么可能与这种做编程的就不是很一样，那么你有什么这样的建议呢？

我以前在其他公司工作过，也做过一些相对比较小的，也做过一些数据库方面的一些东西，包括这种所谓的Client/Server这种架构的三层体系，像这种东西，不管每个产品，我理解的话，都是说，他都有不同的层次，就是比如说商业逻辑在某一层里面，然后表现层那可能是不同的形式，那这个集成呢，取决于你的风险在那里，比如说风险是经常的，比如说数据仓库、数据挖掘、算法什么之类的，有可能引入新的这种算法，对老的算法也会有一定影响；比如说你可能会废止老的这种功能，在这种情况下，在这一层里面，这一部分集成在一起，那就会带来很大的好处。那有的部分它变化特别快，然后每次比如说真正的集成在一起，互相之间也确实没有太大联系，这种情况之下，价值到不是很大，我觉得整个敏捷或者Scrum整个模式来讲，比较注重投入产出，要基于风险去衡量采取那种方式是最有效的。

   

10. 好的，那么就是说在您的这个演讲当中，针对这个产品 的修饰或者提炼，您也提到了要采用一种六顶思考帽的模式，这个其实是一开始提出的时候，可能是在完全不同的领域，所以这也是一个非常有创新性的一种结合。那么是怎么样想起来去使用这样的一个模式，然后你有什么样的一些经验可以分享的？

这个模式主要是解决一个比较现实的问题，大部分人在他考虑问题的时候，比较倾向于经常发生的事情。你比如说一个用户故事，包括大家也经常讲的，ATDD里面讲用户故事。用户故事也是一句话，基本上都是从正面的这种角度来看，我希望你出现什么结果。但问题是实际之中，往往是小概率的事件造成大的问题，很多负面的这个东西，不同的场景。比如说ACD三个按钮，可能隐含按照ABC的顺序的去点击。那假如说，点击C，就有可能让整个系统发生很大的问题。那这种情况下呢，你的思维方式尽量从多角度去看，但是呢，我就考虑到，因为我们团队也会出现这种情况，所谓的正常逻辑，正常逻辑过了，就是其他的那种异常逻辑，或者或者说无效（inactive）逻辑，这种就觉得不是很重要，正常逻辑过了这个挺高兴，实际上就是经常产生非常大的问题在这个上面。那我就想这个怎么样能够比较有计划的，按照一定的这种多角度的思维方式，因为六顶思考帽这种方式以前也培训过，也知道这种方式，就尝试引入这个，然后结合软件开发里面，就尝试从在一个时间段里面，那从不同的角度去看这个问题，有时候你光看一个故事，那价值在哪里呢？没有价值你干吗要做它呢？无效，如果东西用户不按你的这个方式来操作，或者是在很多环境变化，这种各种各样的比较不常见的场景之下，那你的软件是不是工作了？你这个至少要想清楚，是让它工作还是不让它工作，至少系统不应该出现大的问题，那从各个角度去想，这个就想到了这个六顶思考帽这种方式，因为是并行思维，多角度去思考问题。

   

11. 从您的回答中，我刚才和包括现在，我就是理解就是要充分发挥这个团队的力量，集思广益，大家都能够参与进来，然后用不同的角度来思考问题？

您说的对，也就是这个革命不仅仅是说我一个人去，有一个声音，那大家在一起之后，正好也充分了利用了这一点，不仅仅是不同的视角，然后不同的人，他的想到的地方也不一样，特别是这种所谓的非正常的，这个一般来讲，一个人很难想得很全的，那大家集中在一起，就基本上能看到绝大多数的情况。

   

12. 好的，其实好像这个听起来有一点民主集中制的意思，一开始大家先讨论，但是最终可能PO最后还是要有一个人来做最后的决定，和最后的拍板，应该是这样？

一般来讲，PO也是跟团队一起工作的，除非是，比如说有些东西的价值，这个一般来讲就是PO做决定的，因为PO要负责整个产品的吗，有些是可能技术上面做一个东西特别好，但有时候，有所谓的计划的压力，比如说下个星期就要一个什么东西，那做这个东西要花一个月，然后可能客户要从投入产出的角度来看，做一个月，客户就付一点点钱，或者是说他要不要无所谓，你给他不给他，他可能稍微高兴一点点，在这种情况下你可能还是要PO做一定的协调。但大多数情况下，还是尊重整个团队集体的智慧，因为团队（团队）毕竟想的更全面，比一个人更全面。

   

13. 好的，然后在您的这个演讲当中，时间段（Timing）的这样的一个概念，这个概念好像很多人也不是特别熟悉，您能再给大家介绍一下吗？

这个其实就是解决多个团队（，比如说要持续集成，那持续集成就是软件要放在一起。那放在一起什么时候放，这就是一个问题，有没有控制，比如说一个规模比较小的团队大家往里嵌入代码就是了，有问题的话马上通知这个人，他很快就解决掉了。但团队数目一旦多起来，这个问题就复杂了，比如说如果没有控制，同时可能有20个人提交代码，同时进行持续集成，软件集成在一起，然后再测，测试用例也在那跑，如果失败了，怎么办？这是一个问题。经常会发生，比如说失败了，有一种方式，失败了可以放下手头工作去解决问题，然后去解决。但是已经有20个人在嵌入，代码都在里面，你去解决，这个会花的时间很长，首先团队之间会有不同的争论，就说都认为我的是好的，你的是有问题的，总之，要花很长的时间去找到这个问题根源。

那我们就想到一个方法，那大家就是说有一个时间段，不管是安排一个比较固定的时间段，还是说通过排队的方式。在这个时间段里面，就控制就是说少数的人，比如说一个团队，假如说最严格情况下，就认一个团队里面可以把你的新做的功能加进去，加进去之后呢，我就运行你这个测试用例，如果失败了，马上决定你能不能在短时间内的解决掉，如果能快速的解决，那你可以去快速的解决，如果不能快速地解决掉，你这一部分就把代码回滚，让别人可以代码库里提交代码，那这样因为你每个团队里面就是往里面是持续的往里面加新的功能，虽然你这个团队里面没有加进去，但其他的团队的功能加进去了。然后整个产品也是有不断的新的功能在往里边加，这个失败的团队呢，团队在自己的环境下面，跟整个测试的环境去同步，然后去在自己的环境下面去找到问题根源，之后解决掉它，然后再去集成。所以这个时间就是污泥滞留时间（time sludge）。用这种方式去控制，否则团队一多很容易就失控。

   

14. 这个更多的是应用在有很多团队？

对，很多团队。

   

15. 环境比较大、人比较多的这种情况？然后你还提到了有关物件箱（Item Box）和时间箱（Time Box）之间的这样一个对比，物件箱等于也是一个很新的一个概念。那么它是对于Scrum的一个扩展呢，还是我们有的时候会说到Scrum??，您是怎么理解的？

物件箱，想到这点呢，主要还是跟持续集成有关系，比如说Scrum 团队很多的情况下，大家都往里边集成，就是刚才我们也提到污泥滞留时间这个持续集成构建失败，但你要拿到这个令牌（token），也就是说，不管通过排队的还是固定的时间，至少要有一定的资源分配给他，那如果这个sprint，一般来讲，比如说很多的团队要同步的，比sprint开始时期，结束的日期都在一起。一般情况下，为了管理的方便，都是要同步的，还有很多环境的问题，都需要同步。一般团队来讲，都会接近于这个sprint的结束的时候，把他那部分功能做好，这就产生了一个问题，也就是最后几天大家都要往里边签入代码，然后就是有些团队（肯定拿不到了，你想这个时间有限，时间也是非常重要的资源，他拿不到这个令牌就放不进去，可能要排很长的队。后来就想到一点，为什么不把这个时间拉开呢，也就是说任何时间点，在一个sprint，比如说我们四个星期，假如说，那你每个星期都有新功能进去，这个时候比如说一个print刚开始的时候，可能很少有团队（团队）真正的往里放功能。那自然就是比较从容了，不是说最后几天大家这个时间很有限，然后一旦失败了，这个就，等于说，甚至陷入一个挂起状态了，失败了，你怎么办，很多东西两难，硬着头皮往前冲，还是我让一个团队后退，让另外一个团队去进，不管怎么样都会碰到很多问题，那就物件箱，那就尽量的在这个Scrum框架里面，一个sprint里面，物件什么时候能够真正的完成，这个有一个比较好的计划，有一个估计，不是说一定要在某一天，但要有估计，因为我们这个团队团队有一个特点，至少在我们产品里面，一个Scrum 团队在一个sprint里面，不是说只做一个物件，一般情况下都有这个三到五个这个样子，这个物件之间怎么样去集成，还有一些是遗留下来的物件，因为这个物件箱，就是说我们是尽量的把物件拆细到一个sprint可以做完，你不要说一个sprint，连续多个sprint，那这样就给Scrum设计有一定的冲突了。那我们还是在一个解决一个sprint里面，把这个物件，比如说整个团队（团队）去做这个，只需要一个星期，那你在第一个星期里面就把这个完成掉，真正的集成在一起了，就说完整的集成在一起了。

   

16. 所以其实反而可能是更加的敏捷？

对，更敏捷一点。

   

17. 而且你已经把有一些资源增强的这种情况避免了，把工作平均分担到整个的sprint当中？

然后还带来一个好处，假如说团队习惯了这点，比如说我们sprint，一般Scrum不太提倡，在一个sprint里面去改变需求，但实际上，在我们的实践当中，发现在sprint里面需要改变的还是蛮多的，如果这种模式也带来一个好处，相对比较习惯了，假如在中间去加入一个东西，或者调整一下优先级，也是可以接受的，因为这个不仅仅是说，我这个sprint 计划就完成了这个，然后都是到最后几天把这个事情做了。相对比较灵活一点。

   

18. 好的，然后最后一个问题，我看到你自己的自我介绍中也提到，您是一个业余的马拉松爱好者等等，也就是说其实兴趣爱好非常广泛了。那么我们也说Scrum 团队应该是一个有趣的 团队，就是说您是在工作中如何处理这个工作与生活的平衡，以及如何去让这个团队（团队）真正成为一个有趣的 团队？

我提到这一点，一个方面，比如说马拉松，有一句话叫做生活不是这个sprint，不是冲刺，它是个马拉松，其实我们这样，我们用的sprint，实际上你要考虑的是一个长期的一个稳定的一个速度，比如说马拉松，你不能说你跑，比如说42.19公里，那你比如说时快时慢，这样的话很快你就完蛋了，这肯定是不行的。你要有一个持续的速度，其实这个跟sprint跟Scrum还是有比较好的联系的，比如说，一个sprint里面，里面内容比较多，大家狂冲，那结果就是说你冲的太猛了，就说下一个sprint，大家都很累，那做不了什么东西，这个况且是有些情况下，特别是在我演讲中提到了，一个sprint和一个sprint之间，现在我就发现，比如说一个Scrum运行时间比较久了之后，Scrum 团队就是不是特别重视，刚开始的时候大家肯定挺重视的，挺有意思的，一起讨论什么那个，到后面就变得，敷衍了事，可能大家随便聊聊这个。实际上英文我觉得它是Scrum一个精髓，它是让你持续改进的一个方式，也就是说要改进这个东西，要着眼于从工作方式上面去改进，提高知识基础上去改进，不要去从那个我多加加班，这种方式你就很难持续了，况且你这个团队比如说他很累，没时间学习，虽然在短时间之内，好像产出挺多的，但到后面可能这个生产效率越来越低，它本身也没有，一个是它本身的这个知识基础没有提高，另外一个实践也没有提高，重视相对长期的一个。

   

19. 所以好像有一种误解说，说Scrum其实是压榨员工的一种办法，你是完全不同意的？

我不同意这一点，光靠压的话是不行。主要我们还是说，但Scrum本身也意识到这点，改进工作方式才是一个能够提高生产率的更可持续的提高产出的一种方式，不要因为经理催的急，那就多加加班这种方式，这种方式长期以来会有不好的，至少，在每个sprint，我就提到这个，比如说游泳，那你有一个提到所谓的全新方式，他有一个理念，每次你要享受你滑水的每一下，我们sprint也是一样的，你要享受，你在这个sprint所做的这一切，你要能享受什么呢？你要用正确的方式去做，不要很累，然后每个人都感觉很累，然后压力很大，然后又不知道自己做的方式对不对，这时候如果不能确定的话，你不要练习挣扎，我觉得你要是拼命加班的话，你就在练习挣扎，企图通过这种很累的方式来提高生产，提高产出，那这个很不持续的。你要通过提高你的实践，或者提高个人能力，这种方式来提高，逐步的就能够产出越来越多，同时团队也比较和谐，你跟各个经理之间的关系也都会比较好一些。刚开始可能会有一定的压力，我觉得一样的，不光是产品负责人还是说Scrum 团队，一定就是说也要有一定的自己的一个指导思想，不能别人给一个压力，你就顺着这个方向走。给另外一个方向的压力，你又转向另外一个方向，这样就很难，也就说敏捷，有基本的原则，我觉得这个原则都是非常好的。要看你自己的做法是不是符合这个原则。不符合的话你就想一下为什么不符合，是真的环境导致呢，还是说你没在这方面想更进一步的提高。

   

20. 好的，今天再次感谢您接受我们的采访，谢谢。

谢谢！