快速軟體開發專案中的有效溝通（轉）

在當今快節奏的工作環境中，軟體開發人員正面臨著一種痛苦的兩難境地：他們需要應付加速軟體開發程式的持續壓力，這種對速度的要求會導致溝通失敗；同時還要面對由此帶來的專案和系統開發的困難。由於業務需求不會在短期內改變，所以快速開發專案經理必須加倍努力地進行有效和高效的溝通。

在某些情況下，快速開發表示一系列的特殊軟體工程實踐，其目的在於正確選擇採用縮小範圍和增加資源以減少開發時間的方法，此類方法包括極限程式設計（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.[@more@]