该帖子同步发自：(牛草草的博客  访问该博客)

　　在当今快节奏的工作环境中，软件开发人员正面临着一种痛苦的两难境地：他们需要应付加速软件开发进程的持续压力，这种对速度的要求会导致沟通失败;同时还要面对由此带来的项目和系统开发的困难。由于业务需求不会在短期内改变，所以快速开发项目经理必须加倍努力地进行有效和高效的沟通。

　　在某些情况下，快速开发表示一系列的特殊软件工程实践，其目的在于正确选择采用缩小范围和增加资源以减少开发时间的方法，此类方法包括极限编程(XP)，应用程序快速开发(RAD)和快速原型法等。在另外的情况下，快速开发是用来推销缩短软件开发周期的工具、新方法或研讨会的流行用语。无论你认同哪种定义，当项目团队走捷径并且试图决定何处让步以期完成紧张的计划时，进度压力会导致灾难发生。

　　“当我听到快速开发的时候，我立即想到，开发团队希望通过忽略掉关键步骤的方法来简化项目法则。”戴夫?弗格森如是说，他是美国加州El Dorado Hills地区的DST Output公司电子产品开发及实施部门的副总裁。他们公司的开发工作着重强调于软件工程和项目管理。

　　在被问及分享一些快速开发的名言时，丹麦独立项目管理咨询师本特?埃泽森引用了罗马皇帝奥古斯塔斯的话：“Festina lente”。此句拉丁文的意思是“从容赶急”。关键是避免恐慌和由此引起的混乱。这需要在项目开始时花时间建立健康的习惯。

　　紧张的时间限制会遏制沟通。英国伦敦Sapient Corp公司的技术总监格雷厄姆?奥克斯建议：“快速开发的沟通问题与其他方法一样存在，但是犯错误的空间更少，而且有很大的机会使事情在一个星期内失去控制。”

　　奥克斯指出，项目团队受到压力时会不合时宜地牺牲流程和交付物来换取速度。他说：“按需要适当地调整流程，但不要因为时间原因而单纯抛弃评审和其他质量保证流程。因为缺陷同样浪费时间。”

　　谨慎地交接

　　在用户、获取需求的分析师、设计师和解释实现需求的开发人员之间的交接过程中，信息会频繁地丢失。“获取需求时要全面，并且要保证用户参与到设计评审里。”马代尔?霍尔说，他是美国加州萨克拉门托市Catalysis集团公司的咨询项目经理。

　　专业的开发流程受益于客户与开发人员之间的良好沟通。美国北卡来罗纳州达拉漠市Pugh-Killeen Associates公司的软件顾问肯?皮尤指出：“要使用极限编程法的话，客户必须在开发现场，这样在需要的时候，客户会解释需求的细节。如果技术问题与实现一个特殊需求相关，客户和开发人员会一起权衡以找到一个解决方案。”

　　很不幸的是，许多项目发起人并不理解这项规则和成功执行这些过程所需的资源许诺。使用极限编程来构建系统代价不菲，但如果执行得当，它可以缩短开发时间。邀请一些知识渊博的客户成为开发团队的组成部分以促进沟通的做法会使大部分项目预算超支，但结果是可以预测的。

　　美国科罗拉多州恩格尔伍德市govONE Solutions公司的产品交付部门总监雷恩?汤普森认为：“许多快速开发方法通过隔离开发团队来提高速度。但问题在于”成功“的定义。如果成功是指在规定的时间内交付系统产品，那许多团队或许是成功的。如果成功是指交付一个可用的系统产品，那些成功可能变成最多是瑕瑜互现。”

　　汤普森建议，在团队上下建立公共的视角是异常重要的。“在长期的项目里，有必要保持成员的士气高昂。在快速项目里，这有两个目的：其一，当团队在恶劣环境下长时间工作时维持他们的士气;其二，有效地确保团队向着公认的项目结尾前进。团队认识到这些视角有助于他们理解他们的角色和分歧所在。”

　　应用程序快速开发法在需求不明确时被广泛应用，在此情况下，客户的参与也非常关键。皮尤认为：“使用应用程序快速开发法时，通常没有足够的时间或知识来创建一份详细需求说明书。最终产品可能基于在开发过程中学习到的东西。既然需求不确定，那么开发人员和客户必须一起工作来开发产品。”

　　汤普森认为快速开发法本身很少能导致工作更快地完成。相反，产生最大价值的那部分系统的开发工作会更加高效。他说：“我想，当人们把快速开发作为一项技术实践来对待时，他们误会了关键问题。如果你揭开快速开发背后的故事，开发的重点在于将工作的耗时固定，然后控制范围以适应固定的时间。通过理解整体规划和自己的工作如何融入整体，上述说法可以实现，此外，还要进行经常性地沟通，当威胁到时间的事务发生时，设定期望值亦为必要。”

　　快速开发的成功可以部分地归功于开发团队的小型化，开发人员和客户在同一地点工作并关注于手头的事情，这样会自然而然地将沟通的挑战减至最小。

　　谨慎但不乏灵活地规划和开发

　　像需求规范、架构规范和详细设计等工作成果用来记录复杂的思想，这样它们可以经过评审以确保明确一致，然后会被提上议案讨论。当进度的高压导致工作内容不明确时，误解会蜂拥而至。

　　为了避免返工，开发人员应顶住压力以完成那些相对简单的部分直到整体规划得以清晰定义。罗伯特?卢如是说，他是萨克拉门托市的加州政府的一名程序开发经理。卢描述了最近的一个开端困难的项目，此项目目的是通过互联网提交客户数据，他解释道：“我们获得的最重要的经验是尽早的开始着手开发架构规范，这样，此后划分系统时，人们会清楚各部分之间的相互关联。”

　　这需要训练，很重要的问题是，在开始时花时间记录那些在开发流程和交付物的质量标准上达成的共识，并且在质量标准被准确无误的达成之前抵制住宣称“完成”交付物的诱惑。

　　在开发流程和交付物的质量标准上达成的共识，并且在质量标准被准确无误的达成之前抵制住宣称“完成”交付物的诱惑。

　　Sapient公司的格雷厄姆?奥克斯领导了成功的快速开发项目的同时，对沟通和计划做出了正确的决定。为了取得成功，他给出如下建议：

　　结构化的计划。只有当一份完善的计划存在时，每日的进展汇报才会有比对的标准。状态周报需要有完整定义的结构，这样可以迅速的完成周报而不致遗漏要点。

　　高透明度。Sapient采用了项目作战室来确保所有计划的高透明度和可获得性，包括高层计划、中层计划、每日计划、风险列表、项目总目标、标注了负责人和时限的待完成事项列表和进度度量标准。

　　频繁但简短的沟通。Sapient每天会有站立进行的进展会议，这种会议不会超过15分钟，每位与会成员针对每日计划来汇报进展。

　　清晰、公认的目标。人们在不工作时会做出很多决定，但他们必须知道他们自己的项目难题如何影响整体目标。

　　一项最有挑战性的沟通问题是创建和维持关键干系人和项目发起人对开发流程的共识。在开发过程中提供可见的和易理解的里程碑是个关键，这样发起人和干系人会对进展有所了解。这些方法有助于管理他们的期望并有利于事务和进展的沟通。

　　团队如是说

　　以下提及的是有助于促进沟通的团队组织和管理的一些基本指导：

　　保持团队小型化。针对完善定义的子系统工作的四到五名成员的规模能够促进沟通。

　　迅速处理问题型员工。那些不能或不愿成为团队一部分的成员会迅速地造成比他们本身价值浪费多很多的士气问题。

　　避免使用兼职人员。与其他项目共享人员会使成员同时兼顾太多的工作，而两个项目都会遇到问题。尝试获取项目所需要的全职员工。

　　避免通过添加开发人员来解决进度问题。如果项目落后于进度目标，不要试图向现有团队加人。团队重新定位和吸收新成员的代价很少会带来短期的进度跟进。

　　安排团队的座位。开发团队要设置在同一座建筑物、同一层、同一区域来促进评审和询问。为团队准备的一间小会议室的确是一个有利的条件。