文/Payson Hall 譯/趙克琛

在當今快節(jié)奏的工作環(huán)境中，軟件開發(fā)人員正面臨著一種痛苦的兩難境地：他們需要應(yīng)付加速軟件開發(fā)進程的持續(xù)壓力，這種對速度的要求會導致溝通失??；同時還要面對由此帶來的項目和系統(tǒng)開發(fā)的困難。由于業(yè)務(wù)需求不會在短期內(nèi)改變，所以快速開發(fā)項目經(jīng)理必須加倍努力地進行有效和高效的溝通。

在某些情況下，快速開發(fā)表示一系列的特殊軟件工程實踐，其目的在于正確選擇采用縮小范圍和增加資源以減少開發(fā)時間的方法，此類方法包括極限編程（XP），應(yīng)用程序快速開發(fā)（RAD）和快速原型法等。在另外的情況下，快速開發(fā)是用來推銷縮短軟件開發(fā)周期的工具、新方法或研討會的流行用語。無論你認同哪種定義，當項目團隊走捷徑并且試圖決定何處讓步以期完成緊張的計劃時，進度壓力會導致災(zāi)難發(fā)生。

“當我聽到快速開發(fā)的時候，我立即想到，開發(fā)團隊希望通過忽略掉關(guān)鍵步驟的方法來簡化項目法則?！贝鞣颉じジ裆缡钦f，他是美國加州El Dorado Hills地區(qū)的DST Output公司電子產(chǎn)品開發(fā)及實施部門的副總裁。他們公司的開發(fā)工作著重強調(diào)于軟件工程和項目管理。

在被問及分享一些快速開發(fā)的名言時，丹麥獨立項目管理咨詢師本特·埃澤森引用了羅馬皇帝奧古斯塔斯的話：“Festina lente”。此句拉丁文的意思是“從容趕急”。關(guān)鍵是避免恐慌和由此引起的混亂。這需要在項目開始時花時間建立健康的習慣。

緊張的時間限制會遏制溝通。英國倫敦Sapient Corp公司的技術(shù)總監(jiān)格雷厄姆·奧克斯建議：“快速開發(fā)的溝通問題與其他方法一樣存在，但是犯錯誤的空間更少，而且有很大的機會使事情在一個星期內(nèi)失去控制。”

奧克斯指出，項目團隊受到壓力時會不合時宜地犧牲流程和交付物來換取速度。他說：“按需要適當?shù)卣{(diào)整流程，但不要因為時間原因而單純拋棄評審和其他質(zhì)量保證流程。因為缺陷同樣浪費時間。”

謹慎地交接

在用戶、獲取需求的分析師、設(shè)計師和解釋實現(xiàn)需求的開發(fā)人員之間的交接過程中，信息會頻繁地丟失。“獲取需求時要全面，并且要保證用戶參與到設(shè)計評審里?！瘪R代爾·霍爾說，他是美國加州薩克拉門托市Catalysis集團公司的咨詢項目經(jīng)理。

專業(yè)的開發(fā)流程受益于客戶與開發(fā)人員之間的良好溝通。美國北卡來羅納州達拉漠市Pugh-Killeen Associates公司的軟件顧問肯·皮尤指出：“要使用極限編程法的話，客戶必須在開發(fā)現(xiàn)場，這樣在需要的時候，客戶會解釋需求的細節(jié)。如果技術(shù)問題與實現(xiàn)一個特殊需求相關(guān)，客戶和開發(fā)人員會一起權(quán)衡以找到一個解決方案?！?br>
很不幸的是，許多項目發(fā)起人并不理解這項規(guī)則和成功執(zhí)行這些過程所需的資源許諾。使用極限編程來構(gòu)建系統(tǒng)代價不菲，但如果執(zhí)行得當，它可以縮短開發(fā)時間。邀請一些知識淵博的客戶成為開發(fā)團隊的組成部分以促進溝通的做法會使大部分項目預(yù)算超支，但結(jié)果是可以預(yù)測的。

美國科羅拉多州恩格爾伍德市g(shù)ovONE Solutions公司的產(chǎn)品交付部門總監(jiān)雷恩·湯普森認為：“許多快速開發(fā)方法通過隔離開發(fā)團隊來提高速度。但問題在于“成功”的定義。如果成功是指在規(guī)定的時間內(nèi)交付系統(tǒng)產(chǎn)品，那許多團隊或許是成功的。如果成功是指交付一個可用的系統(tǒng)產(chǎn)品，那些成功可能變成最多是瑕瑜互現(xiàn)。”

湯普森建議，在團隊上下建立公共的視角是異常重要的?！霸陂L期的項目里，有必要保持成員的士氣高昂。在快速項目里，這有兩個目的：其一，當團隊在惡劣環(huán)境下長時間工作時維持他們的士氣；其二，有效地確保團隊向著公認的項目結(jié)尾前進。團隊認識到這些視角有助于他們理解他們的角色和分歧所在?！?br>
應(yīng)用程序快速開發(fā)法在需求不明確時被廣泛應(yīng)用，在此情況下，客戶的參與也非常關(guān)鍵。皮尤認為：“使用應(yīng)用程序快速開發(fā)法時，通常沒有足夠的時間或知識來創(chuàng)建一份詳細需求說明書。最終產(chǎn)品可能基于在開發(fā)過程中學習到的東西。既然需求不確定，那么開發(fā)人員和客戶必須一起工作來開發(fā)產(chǎn)品?！?br>
湯普森認為快速開發(fā)法本身很少能導致工作更快地完成。相反，產(chǎn)生最大價值的那部分系統(tǒng)的開發(fā)工作會更加高效。他說：“我想，當人們把快速開發(fā)作為一項技術(shù)實踐來對待時，他們誤會了關(guān)鍵問題。如果你揭開快速開發(fā)背后的故事，開發(fā)的重點在于將工作的耗時固定，然后控制范圍以適應(yīng)固定的時間。通過理解整體規(guī)劃和自己的工作如何融入整體，上述說法可以實現(xiàn)，此外，還要進行經(jīng)常性地溝通，當威脅到時間的事務(wù)發(fā)生時，設(shè)定期望值亦為必要?！?br>
快速開發(fā)的成功可以部分地歸功于開發(fā)團隊的小型化，開發(fā)人員和客戶在同一地點工作并關(guān)注于手頭的事情，這樣會自然而然地將溝通的挑戰(zhàn)減至最小。

謹慎但不乏靈活地規(guī)劃和開發(fā)

像需求規(guī)范、架構(gòu)規(guī)范和詳細設(shè)計等工作成果用來記錄復雜的思想，這樣它們可以經(jīng)過評審以確保明確一致，然后會被提上議案討論。當進度的高壓導致工作內(nèi)容不明確時，誤解會蜂擁而至。

為了避免返工，開發(fā)人員應(yīng)頂住壓力以完成那些相對簡單的部分直到整體規(guī)劃得以清晰定義。羅伯特·盧如是說，他是薩克拉門托市的加州政府的一名程序開發(fā)經(jīng)理。盧描述了最近的一個開端困難的項目，此項目目的是通過互聯(lián)網(wǎng)提交客戶數(shù)據(jù)，他解釋道：“我們獲得的最重要的經(jīng)驗是盡早的開始著手開發(fā)架構(gòu)規(guī)范，這樣，此后劃分系統(tǒng)時，人們會清楚各部分之間的相互關(guān)聯(lián)?！?br>
這需要訓練，很重要的問題是，在開始時花時間記錄那些在開發(fā)流程和交付物的質(zhì)量標準上達成的共識，并且在質(zhì)量標準被準確無誤的達成之前抵制住宣稱“完成”交付物的誘惑。

Sapient公司的格雷厄姆·奧克斯領(lǐng)導了成功的快速開發(fā)項目的同時，對溝通和計劃做出了正確的決定。為了取得成功，他給出如下建議：

結(jié)構(gòu)化的計劃。只有當一份完善的計劃存在時，每日的進展匯報才會有比對的標準。狀態(tài)周報需要有完整定義的結(jié)構(gòu)，這樣可以迅速的完成周報而不致遺漏要點。

高透明度。Sapient采用了項目作戰(zhàn)室來確保所有計劃的高透明度和可獲得性，包括高層計劃、中層計劃、每日計劃、風險列表、項目總目標、標注了負責人和時限的待完成事項列表和進度度量標準。

頻繁但簡短的溝通。Sapient每天會有站立進行的進展會議，這種會議不會超過15分鐘，每位與會成員針對每日計劃來匯報進展。

清晰、公認的目標。人們在不工作時會做出很多決定，但他們必須知道他們自己的項目難題如何影響整體目標。

一項最有挑戰(zhàn)性的溝通問題是創(chuàng)建和維持關(guān)鍵干系人和項目發(fā)起人對開發(fā)流程的共識。在開發(fā)過程中提供可見的和易理解的里程碑是個關(guān)鍵，這樣發(fā)起人和干系人會對進展有所了解。這些方法有助于管理他們的期望并有利于事務(wù)和進展的溝通。

團隊如是說

以下提及的是有助于促進溝通的團隊組織和管理的一些基本指導：

保持團隊小型化。針對完善定義的子系統(tǒng)工作的四到五名成員的規(guī)模能夠促進溝通。

迅速處理問題型員工。那些不能或不愿成為團隊一部分的成員會迅速地造成比他們本身價值浪費多很多的士氣問題。

避免使用兼職人員。與其他項目共享人員會使成員同時兼顧太多的工作，而兩個項目都會遇到問題。嘗試獲取項目所需要的全職員工。

避免通過添加開發(fā)人員來解決進度問題。如果項目落后于進度目標，不要試圖向現(xiàn)有團隊加人。團隊重新定位和吸收新成員的代價很少會帶來短期的進度跟進。

安排團隊的座位。開發(fā)團隊要設(shè)置在同一座建筑物、同一層、同一區(qū)域來促進評審和詢問。為團隊準備的一間小會議室的確是一個有利的條件。

作者簡介：Payson Hall是美國加州薩克拉門托市Catalysis集團公司的顧問系統(tǒng)工程師和項目管理顧問。Hall在北美和歐洲的公共和私營部門里的軟硬件系統(tǒng)集成項目中有20年的從業(yè)經(jīng)驗。

原文：
　　　　　　
　　　　　　　　　　　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.

【?發(fā)表評論?0條?】