朱雀雀的巴士站

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

接触敏捷相关的知识也快有两个年头了，但是真正体会到敏捷开发或者说真正的软件开发流程，是最近的这四个月。这四个月（精确点来说还不到四个月）是我人生的第一份工作（以前在学校勤工助学和在外面作项目不算的吧），在ThoughtWorks 度过的这几个月让我真真正正体会到软件开发的正确流程，远远不是书本所能够教给我的

记得当初在实验室，由于老师的信赖，手里同时管着几个项目，平时又喜欢拿书本上才看到的软件技术和开发方法做试验，因此在实验室是应用过敏捷的。可是效果那就真得不敢说了，第一次毫无经验的去尝试敏捷，的确吸取了不少经验教训，经过这几个月的锤炼，逐渐发现自己曾经错在哪里了。趁这篇Blog 好好总结一下经验

 先说一下现在从事的项目情况：Mingle 项目是ThoughtWorks Studio 的第一个产品，历时已经超过两年了，获得广泛的好评，是很注重用户的体验和实用性的一个软件。不是我夸张，这绝对是我做得最令自己自豪的软件产品了，产品的质量控制和用户体验可以说是发挥到了极致！当然对一个新人来说，一个做了两年多的软件产品，几十万行的代码量的确是有挑战性的。Mingle 的团队是典型的分布式团队，一个团队在美国San Francisco，一个团队在北京，7 个Developer，3个Quality Analysts，2个Business Analysts 1个Project Manager 共13 个人组成。人员构成 Senior Devs 4个，Junior Dev 就我一个（汗呀），Senior BA 2 个，Senior QA 1个，Junior QA 2个，其余的都是Middle Level 的。这就引出了我的下一个敏捷重要的特点，团对人员组成，和工作方式──人的因素很重要

  Mingle 团队在我看来是一个健康的敏捷团队，在上述的分析中，可见Senior人员占绝大多数，这就使得放进去少数的几个新人，在同一时间内既可以保证项目的进度，同时也可以让新人得到很多的帮助，从而让新人非常快的成长，从而尽快的对项目作出贡献。其实这也是我这两年多接触敏捷软件开发以来一直坚信的一个原则，就是敏捷软件开发对人的素质要求非长高。一个从未有敏捷软件开发经验的团队，如果自身团队构成又是新手居多，是绝对不可能获得成功的。我想这就是为什么，有的软件公司应用敏捷软件开发喜忧参半的最终原因。这里不得不提到一个敏捷的最佳实践原则，Pair Programming，我在Mingle 团队的这两个月（其实还不到）每天都会写代码，但是不是我单独写，身边总会有一个Senior Dev 跟我一起Pair，他们不但会给我介绍一些技术上的最佳开发实践，同时也会给我介绍敏捷开发的一些思想，还会给我介绍项目本身的代码结构，同时我们还能完成项目的正常进度，真的是一举四得。跟这些Senior Pair 的同时，我不仅学到了技术相关的知识，更学到了他们的工作方式，最重要的还学到了他们遇到问题和解决问题的思考方式。这些Senior Devs 总会启发我，假如我遇到这样的问题，我自己会怎么做，然后再告诉我他们是怎么做得。这样的后果就是，导致我每天都很累（大脑高负荷运转，哈哈），当然每天也都很有趣。其实，这还只是开发者的部分，仔细想想，团队中Senior BA 和QA 给Devs 的支持是非常有效果得，例如我们在做一个Story 的时候，我们小组的Senior BA 给我们分的任务就很清晰，考虑很周到，系统什么最重要，要多长时间来完成，具体的细节要注意哪些，都非常清晰，这就使得我们总是知道下一步要做什么，而Senior QA 总能即时的发现Bug，从而减少了代码发臭变腐的周期，使得代码和软件总是处于一种比较健康的状态。仔细思考一下，在学校作项目的时候，我和师弟师妹们Pair 的时候，有的时候总是不知道如何下手，一方面这真的跟经验有关，另一方面，由于团队的构成基本上任何人都是BA、QA同时又是Dev，所以划分Story的能力实在是不敢说，总是处于，一种不知道什么重要，不知道下一步该怎么办的状态，大部分有价值的时间都被困惑过去了。果然呀，21世纪啥最重要？人才！同样适用于敏捷团队的构成

对开发流程使用正确的控制手段也非常的重要。以前在学校开发的时候，一个团队坐在一起，先划分用户素材，我们使用Mind Map 作为记录头脑风暴结果的工具，但是记录后的结果就是放在那里，照模照样的开发了，忘记了这些素材是有状态的，它们是可以在不同的状态之间进行迁移的，我们也需要对这些状态进行控制。加入ThoughtWorks 之后，发现大家都使用卡片作为载体，卡片通常分为New, In Analysis, In Dev, In QA, Ready for sign off 等一些状态，这就是把一个庞然大物的软件，分成许许多多细小的部分，而每一个部分都是可以展示，都是可以运作的。非常的合理也非常的巧妙，而这些卡片在迁移的同时，也表示了你这个团队当前的状态，及时的反映了团队健康与否。在开发流程的控制中，还有一点给我印象非常深刻，就是持续集成。在学校的时候，SVN就意味着持续集成，现在才逐渐明白了什么才是真的持续集成。最简单的持续集成是什么？是你每次将你的测试通过后，提交的那些代码，这个流程通常是这样的（以RoR开发为例），我们从Story 中找到一小块功能，像播洋葱一样，从外到里，先写一个Controller 测试，描述或暴露出需要完成的问题，这就导致了Model 层会引起一系列的变化，这时候我们添加Model 测试来继续细化这个问题，好了，到此测试部分完成，但是都没通过，剩下的任务就是写代码来通过测试了。当所有测试通过了，你可能修改了以前的代码，怎么能保证软件仍旧处于可用的状态呢？你需要从SVN（或者别的版本控制工具）下载当前最新的代码（注意，服务器上的一定是能工作的），然后在你本地跑测试，确保原本的功能，和你新增的功能都正确无误，那么可以将你的系统同步到服务器上了。这是最基本的持续集成，其实还包括对数据库的持续集成等等。持续集成的下一个环节，是使用Cruise来进一步运行测试。这时候就有疑问了，我们本地测试都通过了呀？为什么在服务起上还要运行一次？正确答案是，你的开发环境并不代表使用环境，我们开发环境都是Mac 的开发环境，可是用户很可能使用Windows；我们使用的浏览器是Firefox，但是偏偏那么不好用的IE 占据市场绝大多数的份额，还有人喜欢使用Safari；如果你的软件又要支持多种数据库，那么就有更多的运行环境了（这就2*2*2=8 了不算Safari）。所以，我们怎么能让21世纪最重要的人才来手动处理这些事情呢？当然使用自动Build 的软件啦！这就是持续集成很重要的第二个环节，其实在Cruise 上还会运行你本地所无法跑得Acceptance 测试，比如说Selenium 的测试，这些是利用行为方式来进行测试的，很费时间，却代表了用户最终的使用价值，因此重要而必须，我们完全可以让服务器来帮我处理这件费时费力的事情。持续集成的第三个环节其实就是短期的Showcase 和Swich Pair 保证团队每个成员的知识体系也是持续集成的──代码共有和对系统的整体认知。

健康敏捷团队的最后一点──回馈信息。无论是在TWU 的日子，还是回国后的工作，回馈信息绝对是敏捷开发团队健康发展最重要的因素之一。软件开发是高脑力劳动，也是当前世界上聪明人最多的一个行业，大家对一个软件开发的流程和技术，都有很多思考，也有很多的价值，及时地团队交流和信息回馈，就会创造一个大家乐于工作，乐于开发的环境，人开心了，代码质量自然就上去了，是不是？

看吧，这篇Blog 就不是一个持续集成的好例子，长时间不总结自己，结果要说得东西太多，步子太大，又都没讲清楚！哈哈哈！

 好了，今天就写到这里吧！