文/Payson Hall 譯/趙克琛

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

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

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

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

緊張的時(shí)間限制會(huì)遏制溝通。英國(guó)倫敦Sapient Corp公司的技術(shù)總監(jiān)格雷厄姆·奧克斯建議：“快速開發(fā)的溝通問題與其他方法一樣存在，但是犯錯(cuò)誤的空間更少，而且有很大的機(jī)會(huì)使事情在一個(gè)星期內(nèi)失去控制?！?br>
奧克斯指出，項(xiàng)目團(tuán)隊(duì)受到壓力時(shí)會(huì)不合時(shí)宜地犧牲流程和交付物來換取速度。他說：“按需要適當(dāng)?shù)卣{(diào)整流程，但不要因?yàn)闀r(shí)間原因而單純拋棄評(píng)審和其他質(zhì)量保證流程。因?yàn)槿毕萃瑯永速M(fèi)時(shí)間?！?br>
謹(jǐn)慎地交接

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

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

美國(guó)科羅拉多州恩格爾伍德市g(shù)ovONE Solutions公司的產(chǎn)品交付部門總監(jiān)雷恩·湯普森認(rèn)為：“許多快速開發(fā)方法通過隔離開發(fā)團(tuán)隊(duì)來提高速度。但問題在于“成功”的定義。如果成功是指在規(guī)定的時(shí)間內(nèi)交付系統(tǒng)產(chǎn)品，那許多團(tuán)隊(duì)或許是成功的。如果成功是指交付一個(gè)可用的系統(tǒng)產(chǎn)品，那些成功可能變成最多是瑕瑜互現(xiàn)?！?br>
湯普森建議，在團(tuán)隊(duì)上下建立公共的視角是異常重要的?！霸陂L(zhǎng)期的項(xiàng)目里，有必要保持成員的士氣高昂。在快速項(xiàng)目里，這有兩個(gè)目的：其一，當(dāng)團(tuán)隊(duì)在惡劣環(huán)境下長(zhǎng)時(shí)間工作時(shí)維持他們的士氣；其二，有效地確保團(tuán)隊(duì)向著公認(rèn)的項(xiàng)目結(jié)尾前進(jìn)。團(tuán)隊(duì)認(rèn)識(shí)到這些視角有助于他們理解他們的角色和分歧所在?！?br>
應(yīng)用程序快速開發(fā)法在需求不明確時(shí)被廣泛應(yīng)用，在此情況下，客戶的參與也非常關(guān)鍵。皮尤認(rèn)為：“使用應(yīng)用程序快速開發(fā)法時(shí)，通常沒有足夠的時(shí)間或知識(shí)來創(chuàng)建一份詳細(xì)需求說明書。最終產(chǎn)品可能基于在開發(fā)過程中學(xué)習(xí)到的東西。既然需求不確定，那么開發(fā)人員和客戶必須一起工作來開發(fā)產(chǎn)品?！?br>
湯普森認(rèn)為快速開發(fā)法本身很少能導(dǎo)致工作更快地完成。相反，產(chǎn)生最大價(jià)值的那部分系統(tǒng)的開發(fā)工作會(huì)更加高效。他說：“我想，當(dāng)人們把快速開發(fā)作為一項(xiàng)技術(shù)實(shí)踐來對(duì)待時(shí)，他們誤會(huì)了關(guān)鍵問題。如果你揭開快速開發(fā)背后的故事，開發(fā)的重點(diǎn)在于將工作的耗時(shí)固定，然后控制范圍以適應(yīng)固定的時(shí)間。通過理解整體規(guī)劃和自己的工作如何融入整體，上述說法可以實(shí)現(xiàn)，此外，還要進(jìn)行經(jīng)常性地溝通，當(dāng)威脅到時(shí)間的事務(wù)發(fā)生時(shí)，設(shè)定期望值亦為必要。”

快速開發(fā)的成功可以部分地歸功于開發(fā)團(tuán)隊(duì)的小型化，開發(fā)人員和客戶在同一地點(diǎn)工作并關(guān)注于手頭的事情，這樣會(huì)自然而然地將溝通的挑戰(zhàn)減至最小。

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

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

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

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

結(jié)構(gòu)化的計(jì)劃。只有當(dāng)一份完善的計(jì)劃存在時(shí)，每日的進(jìn)展匯報(bào)才會(huì)有比對(duì)的標(biāo)準(zhǔn)。狀態(tài)周報(bào)需要有完整定義的結(jié)構(gòu)，這樣可以迅速的完成周報(bào)而不致遺漏要點(diǎn)。

高透明度。Sapient采用了項(xiàng)目作戰(zhàn)室來確保所有計(jì)劃的高透明度和可獲得性，包括高層計(jì)劃、中層計(jì)劃、每日計(jì)劃、風(fēng)險(xiǎn)列表、項(xiàng)目總目標(biāo)、標(biāo)注了負(fù)責(zé)人和時(shí)限的待完成事項(xiàng)列表和進(jìn)度度量標(biāo)準(zhǔn)。

頻繁但簡(jiǎn)短的溝通。Sapient每天會(huì)有站立進(jìn)行的進(jìn)展會(huì)議，這種會(huì)議不會(huì)超過15分鐘，每位與會(huì)成員針對(duì)每日計(jì)劃來匯報(bào)進(jìn)展。

清晰、公認(rèn)的目標(biāo)。人們?cè)诓还ぷ鲿r(shí)會(huì)做出很多決定，但他們必須知道他們自己的項(xiàng)目難題如何影響整體目標(biāo)。

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

團(tuán)隊(duì)如是說

以下提及的是有助于促進(jìn)溝通的團(tuán)隊(duì)組織和管理的一些基本指導(dǎo)：

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

迅速處理問題型員工。那些不能或不愿成為團(tuán)隊(duì)一部分的成員會(huì)迅速地造成比他們本身價(jià)值浪費(fèi)多很多的士氣問題。

避免使用兼職人員。與其他項(xiàng)目共享人員會(huì)使成員同時(shí)兼顧太多的工作，而兩個(gè)項(xiàng)目都會(huì)遇到問題。嘗試獲取項(xiàng)目所需要的全職員工。

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

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

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

原文：
　　　　　　
　　　　　　　　　　　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ā)表評(píng)論?0條?】