冰云@Blogging

敏捷的弱点是什么？

“敏捷的弱点是什么？”，一个刚接触敏捷的朋友如是问。

敏捷方法是一种适应性方法，换句话说，由于它本身的适应性，他可以去适应各种情况，并且可以根据实际的效果来调整自身，从而改善它的适应程度。因此，首先我们说，敏捷的弱点或者优点这样的问法是不妥的，应该问，在什么情况下敏捷适用性不好？

敏捷的产生主要是来自于开发团队，开发团队发现他们在进度、质量等方面的能力无法满足业务需求，于是提出要加强交流，增进反馈，避免各种内部浪费。于是开发团队在实践上采用测试、迭代、提高交流效果等等，最终在效率上得到了很大提升。

但是，很快的，这个团队意识到，光提高开发的质量还不行 。开发测试之外的很多东西也需要敏捷才可以，尤其是在发布一个新版本的时候，旧有的发布方法没法满足开发的速度要求。他们于是提出了敏捷的需求管理，要求和业务部门之间建立专门的业务分析来进行沟通；数据库重构技术，要以往DBA所负责的部分也能够变得敏捷，适应开发的需要；部署和发布方面也需要一套高效的方法来适应快速发布，快速反馈的需要。于是，整个IT部门变得更敏捷，从需求到发布的整个软件生命周期都得到了很大的改善。

然而，这个部门很快又遇到了问题。虽然IT部门的开发很高效，但他们和其他的业务部门之间总遇到难以解决的问题。或者是业务变化跟不上，或者是售后支持没法及时反映。于是，由CIO带领，公司开始了整个的组织转型，将一个组织敏捷/精益化，建立敏捷业务和精益企业。让IT部门的价值得到最大的提升，由新的IT系统来促进业务的发展。

不过，问题又来了。由于业务的发展，公司需要和其他的公司之间进行数据交换，共同开发通讯接口。合作公司的反应速度和开发效率极低，大大的降低了合作的效果。于是，公司派出咨询师，帮助合作公司进行过程的改进。最终达到共赢。

这一整套过程下来，敏捷/精益的思想得到了贯彻，开发效率和业务效率得到很大提升，公司获得了很大的企业价值。然而，如果这一切都无法顺利的完成呢？

在某些公司，由于各种原因，一个团队的敏捷程度完全取决和他们合作的部门或公司的敏捷程度。在一个项目中，我的一个同事所在的团队需要和数据库部门以及另一个开发部门协作，从而完成一个系统集成应用，然而，他们没有数据库的操作权限，同时另一个部门的API尚未就绪。他们很快就开发完毕自己所分配的部分功能，在等待中不断的催促和协调另外的部分。一个几周的工作，硬生生的被拖到了三个月。

综上， 敏捷什么情况下适用性不好呢？答案是，当你没有办法改变你周边的人、部门、公司做事方式的时候。

不过，我认为，改变一个人虽然困难，但我们可以去影响他们。只要从基本的实践处做起，逐渐的，周边的人会被带动，从而可以推动整个部门的改变。一个部门改变了，公司领导会很快意识到这种变化，变化也有可能影响到其他部门。只要我们坚持去做。

Tags: Agile 敏捷, consulting

Posted in Agile 敏捷, Consultant 咨询, ThoughtBlogs, 思考 | No Comments »

商业智能不智能

今天在帮助同事翻译Mingle正式发布的文章时，看到Mingle的宣传词是: Project Intelligence. Powerfully Simple. 一直以为这里的Project Intelligence是说项目智能，虽然一直不知道啥意思，不过想到Business Intelligence，也就是传说中的商业智能，也觉得这是一个很高深的东西。然而，今天Michael跟我说了句话，让我完全改变了看法。

前几天上英语课学了个Central Intelligence Agency，这就是电视中常见的中情局CIA，说缩写谁都知道。这里的Intelligence是情报的意思。今天Michael跟我说，PI的I实际上和BI的I一样，都是情报的意思。我恍然大悟，原来商业智能根本就不是智能啊，是商业情报。Wikipedia上对Intelligence的解释分为两种，一种是Cognition，另一种是Information Gathering，其中就提到BI。

项目情报嘛，立刻就知道是关于项目的一切信息，例如需求、BUG、相关文档，相关代码，进度，优先级。原来如此，Mingle是这样说的：收集项目情报，功能强大易用。所以，以后别提什么商业智能了，就是商业信息收集，和智能两码事。

Posted in Agile 敏捷, ThoughtBlogs | 1 Comment »

在互联网行业应用敏捷方法应对快速变化

昨天才知道这篇文06年6月已经被发表了，自转一下。http://industry.ccidnet.com/art/1544/20060529/565255_1.html

随着Web 2.0概念的发展深化，以网站为依托、面向海量用户群的互联网应用再次吸引了整个IT业界的眼光。这些新兴的互联网应用通常为用户提供一个垂直领域的深入服务，以其独特的服务为客户提供价值。其中，为网络游戏的玩家提供道具交易功能，就是这样一种典型的新兴互联网业务。

自盛大宣布旗下的传奇游戏开始免费运作依赖，中国的网游市场开启了免费时代。这是网游市场竞争日趋激烈的必然产物。除了那些高端市场的网游之外，大部分的网游都受到了影响，由于用户群的流失而导致产品提前退出市场。免费的网游市场并不等于所有做网游的公司都开始喝西北风了。存活下来的网游公司，所依赖的是新的盈利模式，为客户提供增值服务，并获得利润。其中，为客户提供高级的道具就成为一种有效的盈利模式。

网游市场本身就是一个快速变化的市场。而伴随着网游市场兴起的虚拟物品交易市场更是一个不断变化的市场。面对这样的市场特点，以及同行的竞争，一家虚拟物品交易公司需要一个强有力的交易平台来支持。这个交易平台有着如下的特点：

1 业务模式将不断发展，趋于复杂化。

2 随着市场不断的变化，交易平台需要能够快速满足市场的需要。这种需要可能来自多方面，包括用户、游戏运营商、监管机构等。

3 由于不断变化的需求，交易平台的变化将非常频繁，极可能带来平台架构的不稳定。

4 由于快速的发布和日趋不稳定的平台架构，将有可能导致发布的应用出现bug，引发公司的经营性风险。

为了运营这样一个交易平台，虚拟物品交易公司需要有一个足够敏捷的组织，足够快速地响应变化，能够快速了解市场变化，市场的变化能够被翻译为需求，需求变为实现，并快速部署，保持应用平滑的过渡，并引导用户的使用。所以我们认为，虚拟物品交易公司的重点，是要建立这样一个敏捷的组织和流程。

传统的软件开发的过程一般是从需求获取开始，然后是实现、测试、部署。为了实现快速响应的目标，需要把这个过程分解为周期更短的迭代过程，以实现更快的产品面世速度（Time to Market）。

从与一家虚拟物品交易公司谈话的情况来看，主要的需求来自于这家公司的Marketing部门、Customer Service部门和公司的CEO（我们所了解的这家公司规模还不大，因此没有CIO的角色）。Marketing主要是和游戏运营商打交道，他了解的是一个宏观的和潜在的需求，Customer Service部门主要解决用户的具体需求。而CEO往往会提出战略上的一些考虑。我们看到，三种类型的需求同时存在，同时都反馈给研发部门。可以想象，在这样一个快速变化的市场环境中，研发部门很难对需求做出快速的应对。因此，我们首先就是要处理研发团队和需求团队之间的不匹配问题。

解决的办法是由Marketing部门、Customer Service部门、CEO以及研发部门的PM或经验共同组成一个需求团队。这样的团队涉及到决策、业务和技术三方面的人员，可以保证业务需求能够从战略层面被抽取出来，而能够在整个公司层面梳理业务需求的优先级。这样，有限的开发力量就可以集中到最有价值的部分，从而实现了技术对业务的有效支持。如果可能，在这个团队中最好还需要交互设计人员。因为交互设计将是客户获得良好体验的根本，交互设计更重要的工作是能够将问题用图形方式描述出来，可视的东西为需求团队提供了一种通用的语言，并为研发团队给出了一个明确的目标。

在需求团队中，经过一段时间磨合，将会引入开发速度（单位时间内的工作总量）的估计。一项需求确定之后，研发部门的代表将会很快做出评估，这样可以在需求团队中把业务需求和开发能力匹配起来。

需求团队最终的目的是产生一个新的发布计划。新的发布计划包含了最有价值的业务需求，这些需求包含有工期的估算及交互设计的原稿，被交付给研发部门，由研发部门进行开发。

对于一家持续运营的公司来说，交易平台的服务质量是生死攸关的。任何可能的数据出错，或是代码bug，都可以造成用户的损失，降低客户满意度。在软件开发中，质量主要是由测试来保证的。测试方式和层次有很多种，相应的也需要不同类型的人员来完成。例如，单元测试是最小粒度的测试，主要由开发人员来进行。接受测试（或称功能测试）由QA来完成。性能测试在每次发布前进行，由部署人员负责。全公司所有人员，包括业务人员，都会关注系统的开发，随时发现和提出 bug。这样形成的一张完整的测试网络，可以有效保证最后交付产品的质量。为了保证测试的效率，单元测试和接受测试是自动完成的。

自动的测试只能保证系统内部的质量，而系统和其他系统之间的测试，例如银行支付、游戏接入，这些部分不是自动化。在正式部署到真实环境之前，需要先在模拟环境中进行严格的部署前测试。由于真实数据库中存在着属于用户的数据，为了保证数据库的稳定，必须要进行升级测试。一般的思路是将真实的数据库导入到模拟环境中，把数据库升级到新版本的交易平台。对升级后的数据库进行验证，保证数据库升级的准确性。在完成了这些测试后，就可以部署一个高质量高稳定的产品了。

建立开发人员和业务人员之间的良好关系，积极响应需求，通过快速的迭代，先实现高优先级的需求，重视测试对质量的贡献，在部署之前进行严格完整的测试，保证交易平台的质量。这些因素加总起来，使得交易平台能够适应快速变化的市场，满足业务上的需要。很多企业中都存在业务和技术之间的错配，技术满足不了业务的需要，无法对商业价值做出直接的贡献。如果能够像这家虚拟物品交易公司这样，建立业务和技术之间的良性互动，就可以通过利用技术，取得市场上的优势地位。

Tags: Agile 敏捷, web 2.0

Posted in Agile 敏捷, Business, ThoughtBlogs | Comments Off

什么是敏捷？– Q&A

本文是回复CSDN编辑的问题：

> 1. 每个地方、每个人对敏捷的认识和理解都不一样，在我国技术应用和开发的背景下，能否结合您的体会说一下什么是敏捷？

从理论定义上讲，“敏捷是指在动荡的业务环境中，适应变化并创造变化，从而获得价值的一种能力“。Jim Highsmith在他的敏捷项目管理一书中如是说。“同时敏捷是平衡灵活性和稳定性的一种能力”。

(Agility is the ability to both create and respond to change in order to profit in a turbulent business environment. Agility is the ability to balance flexibility and stability )

不同的情况下，敏捷的适应能力可能会体现出不同的解决方案和做事方法。这也许是有人对敏捷认识不同的原因：他们被缤纷的实践手段而遮蔽，而忽视了对敏捷原则或理论的目的理解，那就是适应性。

有人说要做有中国特色的敏捷方法，而敏捷本身就是一种适应性方法，所谓适合中国的敏捷方法这本身就是一个错误的阐述。这句话应该说：敏捷思想天生的适合于各种情况，也包括中国的情况，因为他本身就一个适应性方法。在具体的实践上需要针对各组织和团队的情况进行创新。

> 2. 在我国，总体上说敏捷的实施和推广并不理想，“雷声大雨点小”。既然敏捷这么好，您认为为什么不是所有人和公司都用它？

上面说了，敏捷是一种指导思想。在这种指导思想下做事能获得很大的成功。敏捷需要团队协作，这种成功不可能是靠一个人的英雄主义来完成。必须是整个团队和组织在共同一致的目标和价值观作用下，共同努力的结果。很多人实施敏捷不理想的原因，是由于他们无法改变其他人的做事方法，无法获得团队的认同。在没有人支持和响应的情况下，成功真的很难。

另一方面，由于很多敏捷方法的实践者的尝试都局限在开发团队或IT部门中，他们无法改变外在环境，只能靠团队的努力来进行敏捷实践。这对他们的实践带来了很多限制。有时候外部的力量迫使他们不得不放下已经初有成效的实践。这也是在国外敏捷实践过程中人们逐渐发现的一个问题。ThoughtWorks提出敏捷企业的口号，就是要将敏捷思想和方法带给开发团队以外的公司其他部门。从而提升IT部门的创造力，为企业带来增值。

> 3. 摩卡软件的总工程师说，“敏捷并不适合中国？”您是否认同？能否说说您认同或者不认同的原因？

他说敏捷不适合中国的主要观点是说，中国开发者水平不足以实施敏捷。虽然没听上下文有断章取义之嫌，不过这点我不敢苟同。中国的开发者大多数都很聪明，能力用于实施敏捷开发足以。

目前的问题是，许多团队对敏捷了解不多，或者缺乏敏捷教练的指导。敏捷还没有成为他们做事的一种准绳，开发者的对敏捷的思路还不熟悉，很多人还是只了解学校里学到的瀑布模型。所以，在敏捷的普及上还有待各位敏捷支持者一起努力，来建立这样的大环境。

> 4. ThoughtWorks 在敏捷方面一直做得很优秀，在业内引领着敏捷前进的旗帜，您认为为什么ThoughtWorks 会做得这么好？

信念。因为每一个ThoughtWorker都对敏捷抱有坚定的信念。我们发自内心的认为敏捷是好的，是正确的。因此我们都会告诉我们的朋友，来吧，试试看敏捷。

> 5. 如果有开发者从未真正接触过敏捷，您要说服他使用敏捷的开发方法，您会怎么说？

我建议从具体的实践一点点的，手把手的去让他理解为什么要这么做。不用提敏捷，等到他自己逐步的了解之后，自然会水到渠成的明白敏捷是什么。

> 6. 对于使用敏捷开发方法的程序员，您有什么经验或者教训告诉他们呢？

如果你坚信一件事情是正确的，那就去做，不用管别人怎么说。你在做的同时，也告诉你的朋友，我在做这件事，我认为正确的一件事。这可以潜移默化的影响你周边的人。总有一天，你的努力会有成效的。

题外话：不仅仅是对敏捷，对任何你觉得正确的事情，都应该坚持。例如保护环境，例如节约，例如帮助困难的群体，例如微笑。

Tags: Agile 敏捷

Posted in Agile 敏捷, Consultant 咨询, ThoughtBlogs | No Comments »

敏捷需求管理 - Agile China 2006演讲

2007年7月14日下午，俺在AgileChina大会上做演讲：敏捷需求管理。

根据2006年的调查报告，软件项目失败原因的71%是由于缺乏或糟糕的需求管理造成的。敏捷需求管理过程注重于用户交互和客户参与，能够最大程度的发现和发掘用户的真实需求，从而引导正确的软件开发。敏捷需求管理是敏捷过程的重要一环。良好的需求管理可以使开发团队交付更令用户满意的软件。敬请关注

[updated: 2009.05.07 - added the slide]

Tags: Agile 敏捷, Analyst, Business

Posted in Agile 敏捷, ThoughtBlogs, 需求分析 | 1 Comment »

Distributed Agile Software Development

异地分布式敏捷软件开发 (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小时开发。然而，异地开发带来了高昂的交流和管理成本，如果处理不当将直接导致项目或产品的失败。

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

Tags: Agile 敏捷, distributed

Posted in Agile 敏捷, ThoughtBlogs, 思考 | 2 Comments »

敏捷团队建设

敏捷团队建设 本文发表于4月《软件世界》

最近很多人都问我，有没有适合的人可以推荐给他们公司，他们正在招人，面试了很多个，但有经验的开发人员太难找了。有一个朋友在问我要人的同时，他手下的一个开发人员反而问我有没有好的机会，他想跳槽。

不久前一份报告称，中国本地软件企业面临的最大问题之一，就是高级技术人才的缺乏。造成这种问题的原因，主要是由于本地软件企业的人才培养机制和管理机制的欠缺。人才大量涌入外资企业和频繁的流动，导致了各类有经验人才的欠缺。

每个人都会梦想自己的理想工作。做技术的开发人员要求的更是简单：一个能够不断学到新知识和新技能的职位，一个融洽的团队，一个舒适宽松的开发环境，一份成长的空间。而这些简单的需要，恰恰是许多公司所忽视的地方。这些东西，很多时候就是一个人决定离职的因素。

有的公司认为开发团队是成本中心，所以给他们买最便宜的桌椅——而恰恰是开发人员们一天都依赖于这样的桌椅为公司创造价值；有的公司觉得自己的一套软件不停的实施就能不停盈利——而开发人员最厌烦的就是做重复性工作；有的公司要求开发人员必须上班打卡——好的，那开发人员绝对不会晚下班一分钟。有的公司从来不举行内部的技术交流和培训活动——而开发人员希望的技术提高绝不仅仅是只靠读书能够完成的。

公司要依靠软件来盈利。而要开发一个成功的软件项目，人的作用是第一位的。而个人的力量相对于整个团队来说，又是微不足道的。稍微有点规模项目的成功都是集体努力的结果，而不是靠一两个英雄程序员能够完成的。为了能够保持一个稳定和高效的团队，建设一个吸引开发人员的环境和氛围是所有公司的管理人员们应该考虑的一件事。一个核心的产品开发人员离职，很可能使得当前的项目或订单陷入瘫痪，这目前已经成为了影响许多中小公司存亡的大事。

我所在的公司不仅仅以敏捷过程著称，同时，它以其特有的文化和团队氛围吸引了一大批高水平的开发人员。他们不仅仅是认同敏捷而聚在一起，更多的是，他们向往着这种平等、自由、轻松、快乐的空气。

人与团队

在公司一个典型的敏捷团队中，大致有四种不同角色：项目经理、业务分析师、开发工程师、测试工程师。同时，根据项目不同可能还需要：美术设计师、数据库工程师、系统工程师、交互设计师等不同人员。虽然在项目中不同的人需要确定一个角色，并担负相应的责任，但在公司内部，人与人之间是完全平等没有级别区分的。这种平等的文化，就使得人与人之间的交流不会因为等级差距而丧失。同时公司鼓励每个人向其感兴趣的其他领域发展，成为综合性人才。例如某个人现在是开发人员，但他也可以通过帮助项目经理做一些辅助工作，来学习项目管理方法，从而最终成为独当一面的项目经理。

项目成功的一个重要因素就是交流。保障团队内外顺利交流是项目经理的责任之一。公司鼓励员工之间交流看法和讨论问题。在公司内部，如果有闲暇时间，随时可安排一场讲座。这些讲座都是由员工自发组织和自愿开展，话题多种多样，不仅仅限于技术。经济、法律、业务知识等等，都是大家平时感兴趣的领域。在项目中，定期的Learning Lunch也是公司项目的一大特色。和客户一起围坐在餐桌前，边享受公司提供的午餐边讨论项目中的技术，团队的学习交流气氛自然会无限高涨。

除了自发的、自由的交流，还有一些约定的交流时间和形式，例如，每天的站立会议。你要说出昨天做了些什么，今天会做些什么，遇到了什么困难是否需要别人的帮助。站立会议鼓励每个人说出事情的真相。有了困难就大胆的向你最值得信任的同伴来寻求帮助，没有人会嘲笑你，也没有人会冷漠的不去理睬你的困境。一个自组织的团队，应当是一个温馨而又和谐的集体。每个人都会努力的帮助其他的人，帮他解决他的问题并从中积累更多的经验。

图略：站立会议

无论是在项目中还是在个人的发展过程中，回顾与总结都是一个必不可缺的步骤。公司内部任何事情告一段落的时候都会有一个总结活动。迭代总结，项目总结，发布总结，陪训总结等。在这段时间内什么做的好，什么做的不好，如何进行改进。任何的过程和成绩都不能是静止不变的。只有不断的反省和总结，才能够在未来的发展中进一步提高。项目团队一起召开总结会议活动，在这个活动中，任何人不能够对其他人进行指责和攻击，一切都应该以互相信任为基础，我们的目的是提高下次的工作效率和增强同伴的信心，而不是批斗和推卸责任。公司对员工的绩效考核，也是类似的由一起工作过的同伴来进行评价，360度全方位考核。这种定期的总结和回顾，提供给了员工与团队自我成长的机会。

除了内部的交流，公司还鼓励员工进行技术创新和参与其他社会活动，例如参与开源软件开发、撰写书籍、向杂志投稿、参加和举办技术社群活动等。这些对技术社区的贡献，不仅仅能够提高员工个人的能力，同时还展现了公司员工的整体能力和提升了公司的知名度。对公司和个人来说是双赢。

环境与工具

如果你有机会到我们的办公室，你就会发现，每一张墙都被占得满满的。墙上可能会贴满了各种颜色的小卡片，这些都是正在进行的项目的需求。每张卡片都是一条用户故事，开发人员根据用户故事实现系统功能。这种被贴在墙上的一目了然的管理方法叫做可视化管理。在公司内部，开发、招聘、销售等各种流程的状态都被一一列在墙上。一来可以作为工作的进展图公示于众，二来可以使每个感兴趣的人都可以随时提出他的想法或主意，集思广益，将工作做到最好。

图略：墙面

公司采用大长桌作为开发用桌。座位之间没有隔板。一方面适合与敏捷开发中的结对编程实践，另一方面可以减少隔板带来的交流障碍。如果你到一个采用隔板的公司去走一圈，再来比较公司的工作环境，就会明显的感受到交流频度和广度的明显不同。公司提供给开发人员舒适的座椅，带有扶手并可以调节高度和后仰角度，以适合每个人不同的需要。如果中午工作累了，还可以躺在椅子上小憩一会养足精神以便下午更好的投入到工作中。

图略 开发桌椅

在项目中，必不可缺的交流工具是白板和纸。再没有比这更廉价和更好用的工具了。两个开发人员遇到了分歧，两人走到白板前写写画画，很快，一副清晰的系统脉络就出现在两人面前。分歧达成了一致，开发继续进行，而图像留在白板上，任何过路的程序员都可以驻足观看，如果感兴趣还可以问一问作者，更深入的探讨。在开发的过程中，随时遇到问题或需要记录的，都可以立即写在手头的白纸上，一些简单的算法草稿，也都是用白纸完成。这些白纸多是打印用过一面的纸张，环保而又经济。

我公司和其他大多数外企公司一样，为员工提供免费的饮料和零食。每天早上，公司的面包机都会工作个不停，烤面包的香气会和着咖啡的味道飘扬在空气中。午饭后，从冰箱中拿出一罐健怡可乐，冰凉爽口，喝下后休息一下就可以精神十足的开展下午的工作。下午四五点钟，正是开始感到饿的时候，到零食区找一块巧克力吃补充一下体力，顺便休息几分钟，活动一下筋骨。

图略 饮料零食区

公司还在办公室内放了一台电视机和一台PS2，午饭后和下班后，你可以和同事相约PK一场实况足球，既休息了神经，又和同事加深了感情。公司还经常组织各种体育活动。每周租一次羽毛球场，让长期在电脑前工作的员工运动运动，有助于身体健康。

以上这些是我公司在团队文化建设的一些做法，提出这些供大家参考，希望更多的公司管理人员，能够从中或多或少的汲取一些经验，将之用于提高公司开发人员的物理和人文环境。

改造公司的开发环境，可以先从很简单的做起，例如，在办公室的一角开辟一处饮食区，提供免费的饮料和食品；在走廊上挂一个白板，随时有人记录一些东西；为员工提供更舒适的座椅。这些东西花不了多少成本，但其收效是明显的。不论是技术部门还是其他部门，都会为公司这一点点人性化的举动感到高兴。有了高昂的士气，做事情自然也会更加积极高效。不需要公司一下子全部改变，但往往一点点的细节变化就能够获得全体人员的支持。虽然有些投资，但员工给公司的回报会更多。

无论是敏捷开发理论还是精益管理理论中，都提到团队的作用是最重要的。如果能够发挥人的能动作用，并良好的保持下去。我想，没有什么目标是我们完不成的。如果所有的公司都能够提供良好的环境给开发人员，那不仅仅是开发人员的的幸事，更是我们整个中国IT界的一大幸事了。

Tags: Agile 敏捷, organization, team

Posted in Agile 敏捷, ThoughtBlogs, 项目管理 | No Comments »