文/Payson Hall 译/赵克琛
在当今快节奏的工作环境中，软件开发人员正面临着一种痛苦的两难境地：他们需要应付加速软件开发进程的持续压力，这种对速度的要求会导致沟通失败；同时还要面对由此带来的项目和系统开发的困难。由于业务需求不会在短期内改变，所以快速开发项目经理必须加倍努力地进行有效和高效的沟通。
在某些情况下，快速开发表示一系列的特殊软件工程实践，其目的在于正确选择采用缩小范围和增加资源以减少开发时间的方法，此类方法包括极限编程（XP），应用程序快速开发（RAD）和快速原型法等。在另外的情况下，快速开发是用来推销缩短软件开发周期的工具、新方法或研讨会的流行用语。无论你认同哪种定义，当项目团队走捷径并且试图决定何处让步以期完成紧张的计划时，进度压力会导致灾难发生。
“当我听到快速开发的时候，我立即想到，开发团队希望通过忽略掉关键步骤的方法来简化项目法则。”戴夫·弗格森如是说，他是美国加州El Dorado Hills地区的DST Output公司电子产品开发及实施部门的副总裁。他们公司的开发工作着重强调于软件工程和项目管理。
在被问及分享一些快速开发的名言时，丹麦独立项目管理咨询师本特·埃泽森引用了罗马皇帝奥古斯塔斯的话：“Festina lente”。此句拉丁文的意思是“从容赶急”。关键是避免恐慌和由此引起的混乱。这需要在项目开始时花时间建立健康的习惯。
紧张的时间限制会遏制沟通。英国伦敦Sapient Corp公司的技术总监格雷厄姆·奥克斯建议：“快速开发的沟通问题与其他方法一样存在，但是犯错误的空间更少，而且有很大的机会使事情在一个星期内失去控制。”
奥克斯指出，项目团队受到压力时会不合时宜地牺牲流程和交付物来换取速度。他说：“按需要适当地调整流程，但不要因为时间原因而单纯抛弃评审和其他质量保证流程。因为缺陷同样浪费时间。”
谨慎地交接
在用户、获取需求的分析师、设计师和解释实现需求的开发人员之间的交接过程中，信息会频繁地丢失。“获取需求时要全面，并且要保证用户参与到设计评审里。”马代尔·霍尔说，他是美国加州萨克拉门托市Catalysis集团公司的咨询项目经理。
专业的开发流程受益于客户与开发人员之间的良好沟通。美国北卡来罗纳州达拉漠市Pugh-Killeen Associates公司的软件顾问肯·皮尤指出：“要使用极限编程法的话，客户必须在开发现场，这样在需要的时候，客户会解释需求的细节。如果技术问题与实现一个特殊需求相关，客户和开发人员会一起权衡以找到一个解决方案。”
很不幸的是，许多项目发起人并不理解这项规则和成功执行这些过程所需的资源许诺。使用极限编程来构建系统代价不菲，但如果执行得当，它可以缩短开发时间。邀请一些知识渊博的客户成为开发团队的组成部分以促进沟通的做法会使大部分项目预算超支，但结果是可以预测的。
美国科罗拉多州恩格尔伍德市govONE Solutions公司的产品交付部门总监雷恩·汤普森认为：“许多快速开发方法通过隔离开发团队来提高速度。但问题在于“成功”的定义。如果成功是指在规定的时间内交付系统产品，那许多团队或许是成功的。如果成功是指交付一个可用的系统产品，那些成功可能变成最多是瑕瑜互现。”
汤普森建议，在团队上下建立公共的视角是异常重要的。“在长期的项目里，有必要保持成员的士气高昂。在快速项目里，这有两个目的：其一，当团队在恶劣环境下长时间工作时维持他们的士气；其二，有效地确保团队向着公认的项目结尾前进。团队认识到这些视角有助于他们理解他们的角色和分歧所在。”
应用程序快速开发法在需求不明确时被广泛应用，在此情况下，客户的参与也非常关键。皮尤认为：“使用应用程序快速开发法时，通常没有足够的时间或知识来创建一份详细需求说明书。最终产品可能基于在开发过程中学习到的东西。既然需求不确定，那么开发人员和客户必须一起工作来开发产品。”
汤普森认为快速开发法本身很少能导致工作更快地完成。相反，产生最大价值的那部分系统的开发工作会更加高效。他说：“我想，当人们把快速开发作为一项技术实践来对待时，他们误会了关键问题。如果你揭开快速开发背后的故事，开发的重点在于将工作的耗时固定，然后控制范围以适应固定的时间。通过理解整体规划和自己的工作如何融入整体，上述说法可以实现，此外，还要进行经常性地沟通，当威胁到时间的事务发生时，设定期望值亦为必要。”
快速开发的成功可以部分地归功于开发团队的小型化，开发人员和客户在同一地点工作并关注于手头的事情，这样会自然而然地将沟通的挑战减至最小。
谨慎但不乏灵活地规划和开发
像需求规范、架构规范和详细设计等工作成果用来记录复杂的思想，这样它们可以经过评审以确保明确一致，然后会被提上议案讨论。当进度的高压导致工作内容不明确时，误解会蜂拥而至。
为了避免返工，开发人员应顶住压力以完成那些相对简单的部分直到整体规划得以清晰定义。罗伯特·卢如是说，他是萨克拉门托市的加州政府的一名程序开发经理。卢描述了最近的一个开端困难的项目，此项目目的是通过互联网提交客户数据，他解释道：“我们获得的最重要的经验是尽早的开始着手开发架构规范，这样，此后划分系统时，人们会清楚各部分之间的相互关联。”
这需要训练，很重要的问题是，在开始时花时间记录那些在开发流程和交付物的质量标准上达成的共识，并且在质量标准被准确无误的达成之前抵制住宣称“完成”交付物的诱惑。
Sapient公司的格雷厄姆·奥克斯领导了成功的快速开发项目的同时，对沟通和计划做出了正确的决定。为了取得成功，他给出如下建议：
结构化的计划。只有当一份完善的计划存在时，每日的进展汇报才会有比对的标准。状态周报需要有完整定义的结构，这样可以迅速的完成周报而不致遗漏要点。
高透明度。Sapient采用了项目作战室来确保所有计划的高透明度和可获得性，包括高层计划、中层计划、每日计划、风险列表、项目总目标、标注了负责人和时限的待完成事项列表和进度度量标准。
频繁但简短的沟通。Sapient每天会有站立进行的进展会议，这种会议不会超过15分钟，每位与会成员针对每日计划来汇报进展。
清晰、公认的目标。人们在不工作时会做出很多决定，但他们必须知道他们自己的项目难题如何影响整体目标。
一项最有挑战性的沟通问题是创建和维持关键干系人和项目发起人对开发流程的共识。在开发过程中提供可见的和易理解的里程碑是个关键，这样发起人和干系人会对进展有所了解。这些方法有助于管理他们的期望并有利于事务和进展的沟通。
团队如是说
以下提及的是有助于促进沟通的团队组织和管理的一些基本指导：
保持团队小型化。针对完善定义的子系统工作的四到五名成员的规模能够促进沟通。
迅速处理问题型员工。那些不能或不愿成为团队一部分的成员会迅速地造成比他们本身价值浪费多很多的士气问题。
避免使用兼职人员。与其他项目共享人员会使成员同时兼顾太多的工作，而两个项目都会遇到问题。尝试获取项目所需要的全职员工。
避免通过添加开发人员来解决进度问题。如果项目落后于进度目标，不要试图向现有团队加人。团队重新定位和吸收新成员的代价很少会带来短期的进度跟进。
安排团队的座位。开发团队要设置在同一座建筑物、同一层、同一区域来促进评审和询问。为团队准备的一间小会议室的确是一个有利的条件。
作者简介：Payson Hall是美国加州萨克拉门托市Catalysis集团公司的顾问系统工程师和项目管理顾问。Hall在北美和欧洲的公共和私营部门里的软硬件系统集成项目中有20年的从业经验。
原文：
Make Haste Slowly
By Payson Hall
Communicating Effectively in Rapid Development Software Projects.
In today’s quick-paced workplace, software developers are confronted with a painful paradox: They face continual pressure to accelerate the development process, yet this need for speed results in communication failures – and the accompanying project and system development troubles. Because business imperatives won’t change anytime soon, project managers on rapid development projects must redouble their efforts to communicate efficiently and effectively.
To some, rapid development refers to a collection of specialized software engineering practices – extreme programming (XP), rapid application development (RAD), rapid prototyping – intended to make conscious choices about trading reduced scope and additional resources for shorter development time. For others, rapid development is a catch phrase to sell tools, new methodologies or seminars – each promising to reduce software development cycle times. Whichever definition you prefer, schedule pressure can lead to disaster as teams cut corners and try to decide where to make concessions in hopes of achieving tight schedule goals.
“When I hear rapid development, I immediately think, ‘Here’s a development team that’s hoping to shortcut the laws of projects by skipping key steps,’” says Dave Ferguson, vice president of e-product development and implementation for DST Output in El Dorado Hills, Calif., USA. His organization’s development practices place a strong emphasis on software engineering and project management.
Asked to share rapid development insights, Bent Adsersen, independent Danish project consultant, offers the words of Roman emperor Augustus: “Festina lente” – Latin for “Make haste slowly.” Avoiding panic and the chaos it engenders is key. This involves taking the time to establish sound habits at the start of the project.
Compressed time frames strain communication. Graham Oakes, director of technology for Sapient Corp, London, U.K., suggests, “The communication issues [of rapid development] are all the same, but there’s less margin for error and more opportunity for things to go wildly off course in a week.”
Oakes points out that teams under pressure often improperly sacrifice both processes and software deliverables for the sake of speed. “Tailor processes to the circumstances, but don’t simply drop review and other quality assurance processes to save time,” he says. “Defects cost time.”
Cautious Hand-Offs
The baton frequently drops in the hand-off between the users and analysts who capture requirements and the designers and developers who interpret and implement them. “Be thorough when capturing requirements and assure that users are involved in design reviews,” says Mardell Hall, consulting project manager for Catalysis Group Inc., Sacramento, Calif., USA.
Specialized development processes benefit from improved communication between customers and developers. As Ken Pugh, software consultant from Pugh-Killeen Associates in Durham, N.C., USA, points out, “With XP, the customer must be on-site, so that the details of requirements can be explained as needed. If technical issues implementing a particular requirement become relevant, the customer and developer can work together to make tradeoffs in finding a solution.”
Unfortunately many project sponsors do not understand the discipline and resource commitments required to execute these processes successfully. XP is not an inexpensive way to build systems but it can decrease development time if execute well. Making several knowledgeable customers integral members of the development team to facilitate communication is beyond the budget allocated to most projects – and the results are predictable.
“Many of the rapid methods try to gain speed by isolating the development team,” says Ron Thompson, director of product delivery for govONE Solutions in Englewood, Colo., USA. “The problem is the definition of ‘success.’ If success means delivering a system in the allotted time, many teams are probably successful. If success means delivering a useful system, success is probably spotty at best.”
Thompson suggests that building a common vision with the team is particularly important. “On long projects, it is necessary just to keep people excited. On raid projects, it serves two purposes. The first is to maintain the morale of the team when they are working long, hard hours under poor working conditions. The second is to effectively keep the team working towards a common understanding of the end product. When people can ‘see’ this vision, it helps them understand how their part contributes (and when it is diverging from the target).”
RAD methods are frequently employed when requirements are unclear, and customer involvement also is critical to success in this case. “With RAD development, there isn’t time or even sufficient knowledge to create a detailed requirements specification,” says Pugh. “The final product may be based on what is learned or created during the development process. Since the requirements aren’t fixed, the developers and customers must work together to create the product.”
Rapid development methods themselves rarely lead to accomplishing work faster, according to Thompson. Instead, the parts of the system that deliver the most value are more efficient. “I think that people are missing the point when they treat rapid development as a technical exercise,” he says. “If you really look under the covers of any of the rapid methods, the emphasis is on time-boxing the work and controlling the scope to fit in the time-box. That can only be done by understanding the bigger picture and how this piece of work fits in and constantly communicating and setting expectations as the work uncovers issues that may threaten the time-box.”
The successes of rapid development methods can be attributed in part to small teams of developers and customers who are located at the same site and focused on the effort at hand – which naturally minimizes some of the communication challenges.
Deft and Deliberate
Work products like requirements specifications, architectural specifications and detailed designs are intended to record complex ideas so they can be reviewed for consistency and clarity, then communicated to others. When schedule pressure results in reduced clarity or content of the work products, misunderstandings snowball.
To avoid rework, resist pressure to get the developers working on the “easy parts” until the big picture is clearly defined, according to Robert Lew, an application development manager for the State of California in Sacramento. Describing a recent project to allow client data submission via the Internet that had a rocky start, Lew says, “Our biggest lesson learned is to take the time up front to develop the architectural specification so that when the system is subsequently partitioned, people are clear about the interactions among the parts.”
While it takes discipline, it is essential to take the time at the outset to document agreements on development processes and quality criteria for deliverables and resist the temptation to declare a deliverable “complete” until the quality criteria have unambiguously been achieved.
Sapient’s Graham Oakes has had the most rapid development success when making conscious decisions about communication and planning. To gain an advantage, he advocates:
l Structured Plans. Daily progress meetings work only if they’re reporting progress against a well-defined plan. Weekly status reports follow well-defined structure so they can be written quickly without forgetting key issues
l Extreme Visibility. Sapient employs a project war room with all plans – top-level, mid-level, and a day-by-day micro schedule, risk lists, overall project objectives, to-do lists with owners and deadlines and progress metrics – highly visible and easily accessible
l Frequent, Brief Communication. Sapient uses daily stand-up progress meetings – no more than 15 minutes – in which each member details progress against the micro schedule
l Clear, Common Goals. People will make a lot of decisions on the fly, but they must know how their piece of the project puzzle ties into the overall objectives.
One of the biggest communication challenges is building and sustaining an understanding of the development process among key stakeholders and sponsors. Providing understandable and visible milestones during development is key so that sponsors and stakeholders get a sense of progress. This in turn helps to manage their expectations and facilitates communication about issues and schedules.
Team Speak
Some basic guidelines for team formation and management that improve communication include:
l Keep teams small. Four to five developers working on a well-defined subsystem streamlines communication.
l Address problem team members promptly. Team members who cannot or will not work well as part of a team quickly become morale issues that cost more that they are worth.
l Avoid “part-time” team members. Sharing team members with other projects guarantees people will be trying to accomplish too many jobs at once and assures that both projects will suffer. Try to get full-time commitment from team members for the duration you need them on the project.
l Avoid adding developers to “fix” schedule issues. If the project is not performing to its schedule goals, avoid the quick fix of assigning additional people to an existing team. The overhead required to orient and assimilate a new team member rarely results in any short-term schedule improvement.
l Co-locate teams. A development team should be located in the same building, on the same floor and in the same general area to facilitate tam reviews and questions. A small meeting room for team use is a real plus.
Payson Hall is a consulting systems engineer and project management consultant from Catalysis Group Inc., Sacramento, Calif., USA. Hall has worked hardware and software systems integration projects in both the public and private sectors throughout North America and Europe during his 20-year career.
【 发表评论 0条 】