• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

异地分布式敏捷软件开发 (Distributed Agile Software Development)

异地分布式软件开发（Distributed Software Development）是指由多个位于不同地理位置的团队进行同一个软件项目的开发过程。这个词越来越频繁的出现在各种技术媒体中。

异地分布式软件开发不同于外包，它建立在平等关系的两个团队之间。通常是一个公司的不同分公司或办公室间的协作，他们之间大多不存在博弈的合同关系。而外包是指一个公司将其软件系统的开发委托给另一个公司或组织完成。二者之间是合同的甲乙方关系。

但无论是异地分布式软件开发或是外包，可以接触到实际客户的一端一般称为on-site，另一端可相应的称为off-site，他们可以根据地理位 置分为三类：on-shore（在岸，指在同一个国家或同一个时区内），near-Shore（近岸，在接近的国家和地区中）和off-Shore（离 岸，通常在时差8小时以上）。如下表。

异地分布式开发的组织方式

异地分布开发的组织方式有很多种。最常见的一种是公司将完整的团队组织结构分布在两地，每个团队都有本地项目经理，需求分析师，开发者以及测试。同时公司设定项目总负责人角色，负责两地的沟通与协调。

有的公司将需求分析人员放在on-site一端，开发者、测试人员和项目经理在off-site一方，同时在本地也保持常规的需求分析师。也有公司将测试人员和开发人员分放在不同地方，一方面开发，另一方面利用时差，在夜间测试并在第二天及时反馈测试结果。

各种组织方式都有其不同的适用场合。然而他们的共同点在于，都是注重micro-management，即加强在本地团队中项目管理和协调，而不是由一个人同时直接管理两地的活动。同时，也尽量保证团队两边都具有项目协调人、本地项目经理、需求分析师等辅助角色。

基本原则：极尽交流之能事

异地分布软件开发面临的最大问题是交流问题。随着人员距离的增加，交流效率将大大降低（参见Alistair Cockburn的文章），同时交流成本将极大提高。很多时候on-site一端团队不能把正确的需求传递到off-site一端，这直接造成产品质量的下降。

为了使避免这种情况，应尽量采用一切手段来提高交流的效果。例如，项目经理和团队成员都需要了解其他人的工作状态，一个技巧是可以将你的MSN或Y!名称后缀写上你在做哪一块的需求。并可以随时和同事通过IM进行交流。

交流频度和价值图，Vincent Massol，2004

每天的定时会议将成为很重要的一个很重要的交流方式。如果团队的人数较少，大家可以按照站立会议的方式在电话会议系统中说明自己的情况和遇到的问 题。如果人数较多，一种可替代的方式是每个团队自己进行每日例会，并由个项目的项目经理和需求分析人员进行另外的会议以便协调工作。

如果两个团队时差较大，例如中国北京时间和美国东部时间时差12-3小时，想要进行直接的电话会议交流很困难。如果遇到3个处于不同时区的团队，更 是经常不可能找到一个合适的时间来进行任何的会议。在国际化的公司中，起早贪黑的进行几地的电话会议很常见，但这却不适用于整个开发团队。对这种情况，每 日的开发状态邮件是很有用的。每日开发结束后由项目经理或成员来根据团队的情况来撰写一天的总结，并发送给远端的团队。

交流的障碍经常发生在陌生人之中，如果两地的开发人员互不熟悉，可以考虑将双方人员的照片贴在墙上，以增加熟悉感。可行的话，进行可视会议和当面的会谈。尽量减少陌生感，使交流效果提升。

任何交流方式都比不上面对面的交流。异地开发时，off-site一端很容易丢失on-site一端与客户交流的语义上下文和环境。如果情况允许， 公司应该设立常规的出差和轮换制度。让一部分的团队成员到另一端，见一见一起工作的同事，了解一下客户的需求和感受一下不同的环境。

敏捷开发过程的改进

般的敏捷过程中，都会有一个初始阶段，在这个阶段了解开发需求和制定发布计划。要进行这样的活动，最理想的办法是让所有人都出差到on-site一 端，一起了解需求和建立共识。这将会对后面的开发有很大帮助。如果由于人数或成本不可行，至少要派遣所有的需求分析师和项目经理、协调人以及部分测试人员 到场参与。对于迭代一级的计划，应该由两地的项目经理和需求分析师提前进行计划会议并做出决定。

日常的项目管理工作中，采用卡片墙的方式只适用in-house的开发。在异地开发中，为了使得每个团队都可以了解到团队任务，至少需要在两边开发室都设立卡片墙，并保持同步。可以采用在线工具帮助进行项目跟踪，例如Mingle或Trac，都是适用的在线工具，同时也是在线Wiki或共享知识库。

项目协调人，应当制定完善的交流计划和交流机制。例如前文提到的每日的例会和每日开发状态邮件，每周的需求交流计划，问题的提出和反应机制等等。这些应当制定成为团队守则来遵循，并随着实际情况的变化修订。交流不怕多，只怕不充分。

一个共享的代码版本控制系统是必须的。例如在公司内网建立一个SVN并通过VPN来使用。On-site和off-site团队可建立自己单独的持 续集成环境，但需要保持系统环境的一致。两方的开发人员都应该保证每日离开办公室前的提交通过集成。这样可以避免异地团队开始开发不至于被失败的集成所耽 搁。

基本的敏捷时间必不可缺，例如测试，尤其是功能测试。On-site的QA应当在需求确定的时候制定好验收条件。一个描写良好的验收条件会对开发人员有所帮助。尤其是在On-site一端不能及时解答问题的时候，会起到很大的作用。

每个迭代结束时，应尽量安排一个两地同步的演示会议。让所有人都在电话会议上看到这个迭代的成果。迭代后的总结与回顾也应当两地一起进行，如果人数和条件不允许，可以分别进行，并互相通报回顾结果和改进方法。

离岸团队的参与度

多团队中，处于on-site的成员由于可以接触到客户，他们的话语权可能会被放大，使得on-site一边的人倾向于命令式的消息传递，直接指派 需求和开发进度，而忽视了对需求背景情况和上下文进行介绍。这种情况可能造成off-site一端团队产生抵触心里，从而导致项目的失败。

解决方法是提高off-site团队的参与度。如制度性的进行人员轮换，让两端的团队成员有所接触，并互相熟识。定期组织两个团队的共同活动。如果 都处于一个时区，可以考虑进行每周的Learning Lunch，大家在互相能看到视频的情况下一起吃饭和听讲座。讲座内容可以是任何话题，例如一些项目相关的技术决策等等。

不要忽视offsite团队的任何意见和建议，他们在很多时候能从另一个侧面对项目提出见解。鼓励offsite团队决策和发起讨论，这样可以提高他们的参与度。

实施异地开发的最初目的是为了降低人力成本和运营成本，一些跨时区的异地开发还可以提高时间利用效率，实现全球24小时开发。然而，异地开发带来了高昂的交流和管理成本，如果处理不当将直接导致项目或产品的失败。

近年来随着国内软件公司业务的发展，异地开发项目将会越来越多。全球化的进程也会使得外国公司开展更多类似的开发。异地开发项目将会逐渐发展和普遍。可以想像，多年以后，如果一个公司没有异地开发的团队，将会是多么的令人诧异。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

敏捷界面重构 — initial idea

很多人都觉得界面的事情是细枝末节，等功能做好了，找个时间一起清理一下就好，不会占用太多工夫。很多人也都是这样做的。

这里说的界面开发是指系统的交互设计和界面可用性及易用性设计，也包括CSS的界面布局、颜色、字体等基本的视觉元素。这些问题的重要性不用多谈。

我在项目中期加入过几个项目，这时候最令人头疼也最令人兴奋的莫过于在开发中期对于界面和UI进行变更了。一个项目在初期如果没有做良好的界面设计，想要在中间来进行大的变更简直是噩梦一般。在一个敏捷团队中，做这样的事情尤其困难。

敏捷开发中的一个实践，是需要客户的协作和参与，及时由客户认可做完的需求以及由客户决定下一步的开发。这种客户享有决定权能够使开发变得更顺畅，客户关系变得更融洽，是一个很好的实践。

但是，这种实践给界面的改进带来很大的麻烦：如果在项目中期打算进行界面的变更，自然要写出很多跟界面相关的需求，而客户按照需求的价值决定优先 级，他们有时候不理解这样的界面改进如何带来价值，为什么改善一些文字描述和交互方法还要占用开发时间，他们更希望在有限的时间内增加更多的功能和修复更 多的BUG。这时候，这些界面调整的优先级就被排的很低，在几个开发周期内都没有得到采纳。

我们先后尝试了几种方法来改进这个过程，例如给客户培训交互设计和可用性知识；将开发人员分为两组，其中一组专职负责界面改进；或者将界面改进需求单独分成一组，要求客户每个迭代从其中选择一部分等等。但这些办法都不是很理想，没有达到预期效果。

事后总结原因，觉得最大的原因还是在于：客户不是用户。他们虽然负责对项目功能验收，但他们并不最终使用系统。系统使用上的问题不是他们最关心的。他们需要得到投资回报，因此选择了回报更快的功能开发。从这方面看，客户的选择是无可厚非的。

理想的解决方案应当是在一开始就对界面及UI进行控制和把握，并进行持续的度量和改进，或者称为：界面重构。将界面重构和代码重构等同到同样地位，在开发过程中持续随时的进行改进。

我们都知道，代码重构是在不改变代码行为的基础上，改变其内部的结构。通过一系列小的步骤进行重新构造，系统不会因为这些小步骤的改变而停止运转， 仍然会保持顺利正常的运行。重构的结果是一套良好可读的代码，它不仅能够对我们扩展功能有帮助，也是我们适应变化的基本手段之一。

我们将其类比到界面的开发过程中：我们需要在不改变界面功能的情况下，通过一系列细小的步骤，来改变界面的交互行为和可用性。最终结果，不仅仅是一套良好的界面，也是保证我们扩展新的功能和适应变化的基础。

重构的一个要点是测试。测试可以保证重构的正确。而界面开发的过程中，测试工具的缺乏导致我们不得不采用其他的方式来保证功能的正确。一种可行的办 法是维护一个界面原型，纸质或电子形式均可。在不停地开发过程中，不断的维护这个原型，使之先于实际实现被用户感知和体验，提前获得用户的反馈和客户的认 可，并将原型用于指导团队的开发。这种不断的用户体验和用户测试过程，可以在一定程度上保证界面重构的正确性。BA阐述需求或QA进行验收测试的时候，也 不妨考虑使用界面原型作为一个验收条件来展现给开发者。

重构的另一个要点是要经常不断的进行，每当写新代码之前，先进行一点重构，使旧的代码更好阅读。界面重构也应该是这样。对每一个开发完成的需求，提 高界面验收的标准。不仅仅是完成功能就可以，还需要达到一定程度的可用性和可维护性要求。例如必须遵循提前制定的UI Guideline等等。避免因为界面开发的涣散导致的破窗户，这种疏于整理的小细节可能最终成为最头疼的问题。

比如，我们在开发的过程中，以前只以60分作为界面的验收标准，等积累一段时间后再批量修改界面一次，但可能这次修改只能达到80分。现在我们需要 改为以80作为验收标准后，在开发的过程中多花点时间来重构一点点，一直保持80的水平。这样如果我们需要进行更大的改进，可能很容易就能改到90或 100分，从而达到我们最终的目标。

由于开发团队的人员多数不太擅长界面的知识，并且界面的测试和度量工具缺乏所致，界面的持续改进在项目中较难做的很好。这些实践又要求BA或QA能 够有相应的交互设计能力和可用性工程的经验，也限制了其在项目中的实践。但这些确是在一个项目中长期被忽视地方，应当进行一些加强和发展。

总而言之，敏捷过程和界面设计并不是矛盾的，将敏捷的思想应用于界面开发和交互设计的过程中，我们可以获得更多更广泛的想法。

4月23日，和Erik谈 了谈这个想法，他也认同这类做法，但觉得由于目前没有一个显然的Vision，或者说，不像Code Refactoring那样有良好的OO设计准则和可读性在前方可以到达，这样的UI重构的准则不是很明显。原因可能还是由于Developer大多缺乏 这方面的Sense。路还很长。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

有一天，这个年轻的程序员在客户处外勤，跟客户交流的时候，讨论到了系统某一块儿的功能。年轻的程序员基于他的工作热情，向客户提出，如果这么这么 做，那可能会给你带来更好的功能。客户听了挺高兴，觉得可行，这小伙说的不错。于是就反映到了项目经理处，说这小伙干的不赖，表扬表扬。这项目经理听到客 户的表扬，也附和的说，他确实很上进，回头我再给他当众表扬一下。

项目经理回到了公司，就把这程序员单独叫来聊了一下，他说，你给客户提建议，这样多思考挺好的，不过，咱们给客户开发，要一单一单的做。你说的那个 功能我早就想到了，但我没提，主要是考虑这个功能实现起来很容易，我们可以放在下一期，我们引导客户一下，让他们提出，我们再把它说的复杂艰巨点，这样咱 们很容易就能完成任务，下一期时间更充裕，而且还能收更多的钱。所以以后有想法咱们内部讨论，先别跟客户说。程序员点头称是。

这样的事情在很多公司都很常见。他们把客户视作敌方阵营，利用自己对IT知识优势了解，努力在一些地方上欺瞒和糊弄客户。

与客户成为敌对的关系，就难免要进行谈判。客户希望用低廉的价格买到他希望的功能，或者说，在一定价格内实现更多的功能。而公司希望提高价格，降低成本。两方表面上达成共识，实际上都在暗地博弈，要在边边角角上沾点小便宜。而这种博弈结果，就是双方都不能达到最好的情况。就像著名的囚徒困境，结局就是纳什均衡(Nash equilibrium)，或非合作均衡。

软件开发的最终目的是要给用户交付价值，要达到客户的商业目标，从而完成公司目标。而为了实现客户和公司的双赢，咨询公司采用了加深客户协作的方式 来达成目标。咨询师会和客户一起工作，了解和认识客户，提出针对性的建议，帮助客户发现和识别业务价值，改进目前的系统。咨询师会站在和客户同一方的阵 营，和客户一起思考、学习和成长。虽然说起来很粗泛，但我所认识的每个咨询师确实都在认认真真的为客户考虑。

另一个会产生非合作均衡现象的是按时收费的单价合同和固定价格固定范围合同的问题。一般PM书籍上都会讲FFP合同对买方的风险比较低，而单价合同对于买方风险可高可低，取决于内容和项目性质。

如果签订固定价格合同，通常的，由于价格固定，客户会倾向于在这个价格内挤入更多的需求，有些人甚至不顾质量而要求更多的特性，反正完成不了都是开 发方的责任。而相对的，开发公司会希望在这里面减少成本，或者是人，或者是需求范围，甚至是不惜牺牲质量。最终两方博弈的结果就是项目出了问题。

这种情况下，更好的办法是单价合同，或者具体说，就是确定阶段时间内的开发力量，但不确定开发范围的收费方式。按照客户需求的优先级来开发，双方合 作，尽最大的努力，频繁交付。这种做法的好处是，客户可以控制项目的长短。可以不停的做下去，也可以立即随时终止。由于双方的协作，开发公司也会按照自己 的能力，尽最大可能来保证质量和进度。另一种改进过的单价合同，是基于开发方对项目的理解和估算，报出一个固定价格。在合作共赢的前提下，双方信任并接受 这个契约。这种情况好像更加适合国内的甲方。

前些天，一个原来的同事电话我，她以前是负责销售的，现在自己开了家公司。她雇佣了一个公司给她开发软件，开发了两个多月了还没见到是什么样子。眼 看就要到交付期限了，她想去看看，就问我应该怎么样去中期查验这软件。我告诉她，要怎么怎么样才能看出这系统到底能不能做完，怎么看出到底做的质量如何等 等。

瞧瞧，怎么样，客户也不是很好糊弄的嘛。你糊弄客户，焉知客户不会另请人来对付你？所以，在商业的博弈中，合作才能双赢。这就是为什么客户协作 over 合同谈判的原因了。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

敏捷软件开发图书概览

“敏捷软件开发宣言：我们正在通过亲身实践和帮助其他人实践，揭示更好的软件开发方法，通过这项工作，我们认为：

人和交流胜过过程和工具

可工作的软件胜过面面俱到的文档

客户协作胜过合同谈判

响应变化胜过遵循计划

虽然右项也有价值，但是我们认为左项更重要。”

—— Kent Beck，Mike Beedle，Arie van Bennekum，Alistair Cockburn，Ward Cunningham，Martin Fowler，James Grenning，Jim Highsmith，Andrew Hunt，Ron Jeffries，Jon Kern，Brian Marick， Robert C. Martin，Steve Mellor，Ken Schwaber，Jeff Sutherland，Dave Thomas

敏捷软件开发这个词在2006年的中国软件界听起来仍然显得有些陌生。自2001年敏捷联盟被发起以来，敏捷方法的实践经验和理论研究都在不断的更新。而我国的大多数程序员还是只能在书本上读到敏捷的好处，很难在项目中进行实践。这其中的原因，主要是缺乏拥有实际敏捷项目经验的人来带领实施敏捷。虽然敏捷开发是种实践行为，很难从书本上直接学习，不过多数程序员了解敏捷，却都是先从书本开始的。无论结果怎样，从认识到实践的过程是免不了的。

敏捷软件开发之方法论篇

大家都知道敏捷软件开发方法包括了多种方法论，主要有：SCRUM，Crystal,特征驱动软件开发（FDD），自适应软件开发（ASD），以及最著名的极限编程(XP)。这些方法论分别在不同的著作上专门论述过：

SCRUM：《Agile Software Development with Scrum》 by Ken Schwaber, Mike Beedle，《Agile Project Management With Scrum》by Ken Schwaber

FDD:《Java Modeling in Color with UML》by Peter Coad, 《A Practical Guide to Feature-Driven Development》(特征驱动开发) by Stephen R Palmer, John M. Felsing,

Crystal: 《Crystal Clear》by Alistair Cockburn

ASD: 《Adaptive Software Development》（自适应软件开发）by James A. Highsmith

其中尤以XP系列的书籍居多。人民邮电出版社的一系列极限编程系列丛书，在国内引进较早。在还没有统一敏捷词汇的情况下，引发了一批敏捷先锋人士的热情，是我国程序员的敏捷启蒙教材。这些书包括《Extreme Programming Explained》（解析极限编程），《Extreme Programming Examined》（极限编程研究），《Extreme Programming Installed》(极限编程实施)，《Extreme Programming Explored》（探索极限编程），《Extreme Programming Applied》（应用极限编程）《Extreme Programming in Practice》（极限编程实践），《Planning Extreme Programming》（规划极限编程）等，这些书有的是作者的XP实践论文，有些是对XP项目的介绍，其中，值得推荐的是下面两部著作。

《Extreme Programming Explained: Embrace Change》by Kent Beck

第一版中译版：《解析极限编程：拥抱变化》，唐东铭，人民邮电出版社

第二版中译版：雷剑文，电子工业出版社

作为XP的开山之作，目前已经出版了第二版。在第一版中，Kent Beck对XP作了详细的描述。从当前软件开发的现状和问题谈起，从需求的变化到如何拥抱变化，给出了XP的四项价值观和十二项实践。对于想了解敏捷的来龙去脉的人，此书属于必读之类。在第二版，Kent根据几年来的实践，为XP增加了一项价值观：尊重，并增加了原则的概念，同时增加和删改了一些实践。

该书第一版是程序员的宣言，这和Kent的背景很有关系。随后XP经历了五六年的发展和实践，Kent自己也逐渐意识到，这样的观点太狭隘了。因此就有了第二版，与其说这是技术书籍，到更像是纯粹意义的软工书籍。期间也可以看出XP的体系更加完备。这其中尤为突出的是把人放到了更为重要的地位。

《Extreme Programming in Practice》by James Newkirk, Robert C. Martin

中译版：《极限编程实践》，王钧，人民邮电出版社

读过了一些列的XP书籍，程序员们都会觉得XP非常好，但到底如何才能开始实施XP呢？还不是太清楚。本系列中的这本书用一个完整的小项目作例子，从头到尾教给人如何敏捷开发，是一本不可多得的实践教材。如果想直接实施XP开发，这本书可以给你很大启示。

敏捷软件开发之实践篇

一、极限编程最佳实践

由于极限编程是如此的流行，多数敏捷团队都会或多或少的借鉴一些XP中的敏捷实践，而XP的每一个敏捷实践也确实值得大书特书，而其中最著名的是测试驱动开发和重构实践：

《Test-Driven Development》 by Kent Beck

中译版：《测试驱动开发》，崔凯，中国电力出版社

测试驱动开发是Kent Beck另一部力作。“Clean Code That Works”是敏捷开发的目标之一，那么如何达到这个目标？TDD给出了一种方式。测试实质上是需求。由需求产生出的代码肯定是能够工作的功能代码，而要实现Class本身的可测试性，就不得不写出高度解耦合的Clean的代码。本书从一个Money的例子入手，从最初的一点需求开始，逐步增加需求，完成整个货币系统的代码。后面又给出了Unit Test中的一些最佳实践和模式供参考。

然而，本书的教导意义比其实践意义更突出。作为一本TDD的教程或入门教材，这本书无疑是最佳的，其中提出的一些最佳实践更是值得经常阅读来温习。本书面向的是单元测试，而实际开发中面对的数据库测试，Web测试等问题并不属于单元测试的范畴。因此读者并不能从中直接进入到实战。

另一本同名书《Test Driven Development: A Practical Guide》由Davis Astels撰写，他将该书看作是Kent著作的补充，重点阐述利用TDD开发所必要的技术和工具上，因此对实际开发更具实用性。

《Refactoring: Improving the Design of Existing Code》by Martin Fowler

中译版：《重构：改善既有代码的设计》，侯捷，熊节，中国电力出版社

重构这本书的意义在于，他提供了一种让你写出更加优美代码的能力。在测试的保证下，重构能够发挥强大的威力。敏捷团队中，不断的重构出简单且高效的代码才能够保持拥抱不断变化的需求。后来的一本书《Refactoring to Patterns》（从重构到模式）by Joshua Kerievsky，更是将重构的威力发挥到极限。

重构曾被称为软件开发图书的双璧，另一本书是《Design Patterns》(设计模式) by GoF。当然，对现在的软件开发这二者已经不是最重要的。ThoughtWorks的首席科学家Martin Fowler总结了朋友们的各种实践心得，写出了这本书。从几年后的目光来看，这本书中的多数实践都被各种IDE做到了操作菜单中。虽然IDE提供了大量重构功能，但仅靠IDE是无法写出简洁美妙代码的，多数的敏捷团队重构工作做得还是不够。

另外有一本专门介绍结对编程的书，《Pair Programming Illuminated》（结对编程技术）by by Laurie Williams and Robert Kessler，指出了为什么要结对？并从各种不同水平不同性格的程序员结对情况来讨论该实践的优劣。对此有兴趣的程序员不妨一读。

二、敏捷软件开发实践

自从2001年敏捷联盟成立以来，单独推广极限编程的书变少了，而统一口径推广敏捷的书变得越来越多。两本同名的敏捷软件开发都是不可多得的好书，

《Agile Software Development：Principles, Patterns, and Practices》by Robert C. Martin

中译版：《敏捷软件开发：原则，模式与实践》，邓辉，清华大学出版社

被业内人士称为Uncle Bob的Robert C Martin在沉寂几年后写出了这部书。该书可以算是从软件开发角度对敏捷方法阐述的最详细和全面的一本。之前的敏捷书籍多是关注于过程改进，而对如何从技术角度实施讲的比较少。本书一开始先介绍了敏捷联盟和敏捷开发过程。之后详细论述了面向对象设计的原则，这些原则是本书的精华之一。后面通过几个项目介绍了如何将设计模式应用于项目中。

Uncle Bob不愧是实践的大师，写出来的书也是拥有很强的实践意义。在敏捷团队的办公桌上，应当常备此书，一来可作为参考查询，二来可以作为新成员的必读书目。

《Agile Software Development》by Alistair Cockburn

中译版：《敏捷软件开发》，俞涓，人民邮电出版社

这本书更加适合管理者来阅读。Alistair从项目人数和交流难易程度，将敏捷的各种方法划分了其适用范围。人数多的或分布式项目就需要靠其他手段来加强交流，人数少的就可以靠pair programming等进行面对面的交流。交流和反馈是敏捷的核心。同时Alistair也介绍了一下他提出的Crystal方法族。

三.敏捷项目管理和敏捷需求分析

在推广敏捷一段时间后，敏捷社群也意识到，多数书籍更像是面向开发人员，过于技术化，难以吸引项目经理或主管。因此，一批面向管理者视角的书也开始浮出水面，这些书包括：

《Agile and Iterative Development》（敏捷迭代开发）by Craig Larman

《Lean Software Development》（敏捷软件开发工具—精益开发方法）by Mary Poppendieck

《Agile Software Development Ecosystems》（敏捷软件开发生态系统）by Jim Highsmith

书中从各种角度比较和分析各种敏捷方法的优劣，异同，起源，适用范围等。这些书对于一个项目主管决策使用何种过程来在自己的团队中实践敏捷有很好的参考作用。

近两年，人们开始逐渐意识到敏捷开发的侧重点不仅仅是开发过程和开发实践，还包括对需求和项目管理等其他相关方面的实践。一些相关的书籍也悄然出现在人们的视野：

《Agile Project Management》（敏捷项目管理）by Jim Highsmith

《User Stories Applied》by Mike Cohn

《Agile Estimating and Planning》by Mike Cohn

《Agile Requirements & User Stories》 by Louis Molnar

这些书不同于以往强调新方法，新过程的书目。敏捷项目管理类的书主要介绍如何管理敏捷团队，如何计划要开发的需求，如何为客户提供最大的价值。介绍敏捷需求分析的书主要帮助商务分析师或项目经理挖掘和分析用户需求，写出用户故事，评估和计划用户故事等。人们已经意识到，各种方法论的实质是相同的，都是提供商业价值，减少浪费，增加交流，快速反馈。因此不需要着重于区分是使用了那种方法。对项目经理来说，不同的项目或团队应当采用适应其特殊情况的方法，而这些方法的基本原则是相同的。

四.敏捷软件开发新方向

对架构师或程序员来说，近年来的技术进展，也使得敏捷开发有了新的研究方向：

《Agile Web Development with Rails》by Dave Thomas, David Hansson, Leon Breedt, and Mike Clark

该书是获得2006JOLT奖的书，讲得是采用Ruby on Rails这个Web开发工具新贵来快速开发Web项目，从而达到快速反馈拥抱变化的目的。

《Refactoring Databases》by Scott W Ambler

此书是Scott的新作，延续和继承了《Agile Modeling》（敏捷建模）和《Agile Database Techniques》（敏捷数据）的思想。在敏捷开发过程中，作为持久化最常见技术的数据库如果不能够敏捷，怎么能够适应一次次迭代和一次次发布的修改呢？书中介绍了如何进行数据库演化，如何保证升级后数据库数据的正确性，以及最佳实践。

我们可以看到，随着敏捷方法和市场的不断成熟，敏捷的书籍也从理论性转向了实用和最佳实践类型。然而，不可否认的是，一个团队的敏捷化很难仅靠阅读书本来完成，由成功实践过敏捷的开发者手把手的带领，才是最好的方法。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师