一个项目团队的敏捷之旅.pdfVIP

http :/// mailto:morningspace@126.com 一个项目团队的敏捷之旅 撰文 / 莫映 题记 近日，欣闻首届“敏捷中国日”开发者大会将于六月初召开，这无疑是中国敏捷开发者的一件大 事。敏捷方法历经数年传布，以其注重实效的特质，已渐入人心，并开始焕发出勃勃生机。不少 一线团队更是早已将其用诸实际，并从中获益良多。本文讲述了一个团队改进的故事，取自笔者 近期接触的一个真实项 。希望能对那些关注敏捷方法如何应用于实际项 的读者有所帮助。文 中采用的敏捷实践主要来自极限编程（Extreme Programming），读者可以从近期出版的《解 析极限编程（第二版）中文版》中找到有关极限编程的详细介绍。 背景 不久前我接触到一个项 团队，并且作为开发过程的跟踪者介入了其中。在我进入项目时，需求 调研已于先期完成，部分模块的开发工作也已由程序员自发的开始了。但是，因为向客户承诺的 项目启动时间在一个月多前，而部门人手一直捉襟见肘，因此真正的大规模开发直到最近才展开， 客户对此却毫不知情。 先 系统：整个系统由三个模块构成，其中一个基于第三方系统开发，并且有一部分工作被外 包了出去；另一个则迫于进度压力，沿用了来自其他项 的一个遗留系统，虽然系统设计混乱， 代码维护困难，但是以往的运行记录良好；最后一个模块则要重头做起。 再 团队：由于项 中要用到Struts、Spring 和iBatis 框架，而成员们对这些框架的熟悉 程度还不够。好在先期已为他们做了简短的培训，通过一个迷你教学项 ，大家在短期内已经掌 握了如何使用“SSI”的基本技能。不过，从我对他们代码的复查情况来看，成员们的编码习惯 尚有欠缺。代码中随处可见的“Bad Smell”让人不禁心生忧虑。 看上去这是个风险颇大的项 ： ¤ 我们真正能够控制的部分，其实只占整个系统的三分之一。团队中每个成员对能否如期完 成预定的功能都没有把握，当项 经理问及系统能否如期交付时，我很坦白的回答说： 前还不知道。 ¤ 团队成员有待历练，团队过程有待改进。改进需要时间，在有限时间内还要将部分精力投 入到团队改进上，这无疑增加了难度系数。好在通过与包括管理人员在内的所有成员的沟 通中，我了解到，大家对团队改进的必要性和紧迫性都有所认同。这在一定程度上为团队 改进工作的开展创造了条件。 1 http :/// mailto:morningspace@126.com 第一个迭代周期 在和团队成员进行短暂磨合后，我开始着手规划第一个迭代周期。 ¤ 为了让这个复杂而棘手的问题尽量简单，同时也为了使我们能在力所能及的范围内做得更 好，我将大部分精力集中于指导团队实现系统的三分之一功能，就是重头做起的那个模块。 同时，这也为我们赢得了更多团队改进的时间。 ¤ 为了尽量打消包括项 经理在内的团队成员们对项 进度的疑虑，我将“迭代计划”作为 团队改进的第一个“故事” （极限编程中的概念）。从目前现状来看，相信这是团队改进 最迫切的，同时也是实施难度和阻力相对较低，最有望获得成功的。考虑到成员对敏捷方 法还较为陌生，我并不急于将诸如持续集成、测试先行一类，听起来很 “酷”的敏捷实践 放到团队的改进计划中。 ¤ 作为一项辅助措施，我让程序员在开发期间每天都向代码库提交当天完成的工作，然后在 次日复查所有昨天的代码。通过一个叫Jupiter 的代码复查工具，我把藏在代码中的“Bad Smell”逐一找出，并告知相关责任人。这么做的 的是希望通过一 时间的持续复查，在 一定程度上矫正开发者的编码习惯。在目前还无法要求程序员彼此互查的情况下，复查工 作毫无疑问落到了我的肩上。不过，常人在一天内完成的工作不会太多，因此以天为单位 来复查代码还算轻松。更重要的是，“Bad Smell” 一旦出现，会在至多一天的时间内被 发现，这样的反馈速度应该是足够敏捷了。在实际实施过程中，我发现程序员的响应速度 很快，当通知他们复查结果后，一般都能在半天到一天的时间内完成所有的代码修改。当 然，起初“复查——修改——再复