朱雀雀的巴士站

版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://phoenixtoday.blogbus.com/logs/27454013.html

This is another article written by me published on the local IT magzine Programmers. Sorry my freinds in other countries, it is written in Chinese. It is about our stories in TWU. To be honesy(yeah, again and again), I miss you guys.

这篇文章可能与程序员上的略有不同，因为后来L MM 帮我改得更好了，不过这是我的Blog 所以贴出来的自然是原文

在有些人的眼中，ThoughtWorks是一群拿着卡片到处贴，到处走的奇怪人群组成的软件咨询公司。其实为什么使用卡片作为理解用户需求的主要机载体， 在我去TWU之前也很疑惑。后来，在一堂介绍如何使用卡片理解需求的课程中，终于了解到原来其中包含了这么多奥妙。首先卡片很小，这就迫使业务分析员不能 将太多的内容放在同一张卡中，由于一个迭代周期通常是两到三周，需要给用户展示一些能用的系统功能出来，这样就会引起整个团队思考许多有价值的问题，什么 是最紧要的？什么是系统的核心？我们要用多长时间来完成这些卡片上的内容？第一个迭代周期能完成多少卡片？我们的团队开发速度是多少？等等。其次，卡片在 卡片墙上是可移动的，因此它很灵活，就如下图所示，可以将卡片放置在不同的队列中，通常我们用“在分析中”、“在开发中”、“在测试中”、“结束”等一些 状态表示卡片所处的不同状态。这样，当所有团对人员，需要了解当前项目的进度状况时，只要站到卡片墙前，就可以一目了然，如果处理不同卡片的小组需要彼此 沟通，在卡片墙上，可以用最快的速度找到相应的人员，甚至，当你有疑惑的时候，卡片可以拿下来仔细研究，只要记得最后放回去就好。卡片的最后一个优点就是 对当前项目进行评估，举一个简单的例子，当一个团队的开发状态是绝大多数的卡片都集中在“在开发”的队列中，就表示当前开发团队处于业务分析员和测试人员 无事可干，但是开发人员又过于繁忙的不健康状态。什么原因导致的呢？可能是开发速度过慢或者是业务分析员写的卡片粒度过大，导致开发人员无法及时的完成。 由此，当我们站到一个团队的卡片墙之前，我们看到的不仅仅是一些简单的卡片，更是整个开发团队的开发状态的展示。一张张小小的卡片却包含了如此多的内容， 这真的是我们始料不及的。当然卡片并不是完美无缺的，对分布式团队开发就是卡片墙的致命弱点，但这些问题在ThoughtWorks的Mingle软件中 都得到了很好的解决，卡片对我们来说更是一种以用户为中心，以团队沟通为中心的开发思想，而不仅仅是一种开发方法。

针 对眼前的需求，小步前进，不做过多的设计，也是敏捷软件开发的核心思想之一。ThoughtWorks University通过一个早上的摆积木课程（Lego Game）让我们充分的理解了过多设计的弊病。这次课程的整体任务是创造未来物种，类似于造电话课程，同样分为三个迭代周期，有一位老师作为客户伴随着我 们进行开发。这一次，老师们一下给了我们许多点数不同的需求，每个需求对应一张卡，每张卡上有不同的分数表示这张卡的难度，每次迭代有五分钟的讨论，需要 确定这次迭代都要完成哪些功能，有十分钟的设计，还有十五分钟的开发过程，每次迭代后大家要讨论哪些做得好，哪些做得不好的地方。第一次的迭代往往是犯错 误最多的地方，我所在的小组向客户许诺了总共加起来十分的卡片，在设计过程中又做了许多不必要的假想，过多的专注于给未来的需求留下余地，而将自己开发的 过程束缚住。最后仅仅搭起来了动物的头和身体，可是客户要求的是一个完整的动物，所以第一次迭代我们只有零分，客户非常的失望。ThoughtWorks 就是这样，通过学员的犯错误，让我们自己体会，然后通过讨论，让我们自己总结出具体的方法，老师们则是在旁边指引，这样的感受怎么能不深刻呢？经过讨论， 我们制订了自己的方针：少许诺，少设计，好好做核心模块。就这样，最后我们创造出了未来的一个物种（还有它的孩子）。

迭代的过程也是ThoughtWorks进行敏捷过程培训的一个重要方面。还是继续我们的游戏旅程吧：这一次老师让我们分成三个小组，分别从培训大厅的一端 将气球搬运到另一端，每一组有两个人负责装运，两个人负责撑袋子，一个人负责搬运，哪一组能在最短的时间内，将最多的气球从一个口袋中运到另一侧的口袋中 就算胜利，如果过程中任何气球掉在路途中，则不可拾取。第一次的规则是只能运一次，整个过程给人的感觉就是搬运的人花了很多的时间，承担了过多的责任，而 其他的四名队员起不到任何的作用，只能边喊边焦心的等待。第二次的规则几乎与第一次一样，但搬运人可以多次的运输。结果第二次，我们不但出色的运输了所有 的气球，而且还比第一次所花的时间更少。玩完游戏的讨论过程中，我们逐渐的明白了，第一次运输就好比传统的瀑布式开发，开发人员承担了许多的压力，缺少沟 通和其他人员必要的帮助，闭门造车造出来的东西，往往并不是客户心目中想要的东西；而第二次运输就好比多次迭代的开发过程，开发人员得到更多的信息回馈以 及业务分析员和测试人员的帮助，因此能够开发出更好的软件产品。就这样，我们不但理解了迭代开发的原理，更通过亲身的体验明白了这样做是行之有效的。