基于敏捷思想的重量級IT項目管理框架思考

摘 要:重量級IT項目具有高度復雜性和不確定性，以過程為基礎的項目管理需要借敏捷方法加以改進。本文以闡明IT項目的復雜產品系統(tǒng)特性為起點，從復雜產品系統(tǒng)的模塊化及分解入手，討論了IT產品的動態(tài)形成過程，提出了一個基于敏捷開發(fā)過程的重量級IT項目管理框架。以提升重載方法開發(fā)效率、提高產品質量為目的，探討了復雜產品分解的隨機Petri網概念模型、柔性團隊行為模型、重載方法適度規(guī)范集以及基于知識轉移的敏捷開發(fā)過程，并提出了若干管理對策。

關鍵詞:IT項目管理;敏捷思想;管理框架;柔性團隊

中圖分類號:F407.67 文獻標識碼:A 文章編號:1003-5192(2010)02-0032-05

A Heavy Weight IT Project Management Framework Based on Agile Theory

CHEN Jian-bin， FANG De-ying， SHI Tong

(Business College of Beijing Union University， Beijing 100025， China)

Abstract:The heavyweight IT projects have so high complexity and uncertainty that the traditional process management method should be improved. In this paper， the attribute of complexity product system(CoPS) of IT project， the modularity of CoPS and its decompose， the dynamic process of IT product development have been discussed， then a heavyweight IT project management framework based on agile theory was proposed. It contains some models such as the concept model on stochastic Petri net for complex IT product decomposition， the behavior model for flexible team， just enough set of heavyweight method and the core process of agile development base on knowledge transfer. This framework can reflect the trend of traditional IT development method changing to agile method， and can to provide a basic management rule to improve the development efficiency and the quality of IT product.

Key words:IT project management; agile method; management framework; flexible team

1 引言

軟件危機推動了軟件工程思想成熟，20世紀80、90 年代，軟件項目開始使用可重復的規(guī)范過程，產生了以質量管理為核心、以軟件工程理論為基礎的嚴格有序的過程管理理論體系。軟件項目被定義為一個有序的、可重復的、可度量的、可嚴格控制的過程。SEI的CMM模型是這一階段過程管理思想的結晶，而且成為一套適用面很廣的通用過程實踐標準。但是，CMM及與其類似的ISO9000、SPICE等通常被認為是重載(Heavy Weight)過程，其出發(fā)點是為使軟件項目能應對不可預知的變化，采取繁復的管理工作抵御風險。CMM 重視系統(tǒng)性、制度化、文檔化和度量，強調提高過程的可靠性、可見性、可預測性和可管理性，實施CMM要求組織在過程制度化建設上付出大量努力。重載過程的工作集中在防止和跟蹤錯誤上，大量工作流程的制定，是為了保證項目不犯錯誤，因此，軟件過程越來越復雜，越來越龐大，重載過程的繁文縟節(jié)、組織臃腫、辦事低效、形式主義等等副作用越來越明顯[1]。重載方法與IT產品及其開發(fā)過程特性的矛盾日益明顯，快速變化的外部市場環(huán)境也向傳統(tǒng)的軟件工程管理理論提出挑戰(zhàn)。人們對軟件過程的認識日漸深刻:軟件過程不是混沌的、隨機的、即興的活動，也不只是一個嚴格有序的因果聯(lián)系的工作流，軟件項目是一個復雜系統(tǒng)，而軟件過程是一種處于混沌邊緣的非平衡狀態(tài)下的系統(tǒng)行為。軟件敏捷開發(fā)方法由此產生。

IT項目敏捷開發(fā)方法，具有早期客戶參與、快速迭代交付、自組織團隊、柔性等典型特征[2]，能夠提供客戶滿意的知識產品，非常適用于特定的環(huán)境——高風險、不可預測和小規(guī)模的探索型軟件研發(fā)項目[3]。但是，軟件產品的規(guī)模(size)日益龐大[4]，重量級IT項目越來越多。相對而言，重量級IT項目具有較高的復雜性和不確定性，風險性、不可預測性也更高。傳統(tǒng)IT項目開發(fā)方法及管理過程，導致重量級IT項目周期長、投入大、成果不可預期，較難獲得客戶的滿意認可。重量級IT產品更需要運用敏捷開發(fā)方法。其中，重量級IT產品的架構、分解優(yōu)化及其與柔性團隊的匹配，是成功實現(xiàn)敏捷管理的關鍵。本文針對重量級IT項目敏捷管理的需要，提出一個基于敏捷開發(fā)過程的重量級IT項目管理框架，反映傳統(tǒng)開發(fā)方法的敏捷性改造，為改進重載方法過程、提高開發(fā)效率和產品質量提供基本思路。

2 IT復雜產品系統(tǒng)及其模塊化

復雜產品系統(tǒng)(Complex Product Systems， CoPS)指高成本的、技術密集型的、用戶定制、單件或小批量生產的生產資料、系統(tǒng)、網絡、控制單位、軟件包、建筑物和服務[5，6]。IT產品復雜性也日益增加，一方面，軟件規(guī)模的擴展意味著功能擴展，這種擴展不僅僅是相同元素重復添加，而必然是不同元素實體的添加，并且多數(shù)情況下它們以非線性遞增的方式交互，使整個軟件復雜度以更大的非線性增長。另一方面，軟件本身的技術復雜性引發(fā)了更多的管理復雜性。Ren和Yeo認為[7]，IT項目是典型的以人為中心、基于人工的，實質上更富個人主義色彩，因而難以預測、控制和自動化。因此，以ERP系統(tǒng)為代表的大型IT項目屬于復雜產品系統(tǒng)范疇[7，8]。

對于復雜產品系統(tǒng)的開發(fā)，一般應首先采取模塊化方法進行分解，才能有效實現(xiàn)產品目標。Simon等提出了系統(tǒng)的層級特性和可分解特性以便于降低系統(tǒng)的復雜性，并研究了軟件結構化設計程度與軟件復雜性、多變性和改進(Enhancement)之間的相互關系，系統(tǒng)地提出了復雜產品系統(tǒng)的特性和劃分準則[9~11]。IT產品的模塊劃分是基于對整個產品系統(tǒng)框架以及功能需求分析的基礎上，將整個IT產品系統(tǒng)的研發(fā)任務按照應用技術類別劃分相對獨立的模塊/子系統(tǒng)進行的，在各模塊開發(fā)完成后，交給集成商整合為一個完整的復雜產品系統(tǒng)，在這個意義上說，模塊化是實施復雜產品系統(tǒng)的前提條件或必要條件。

3 IT產品的動態(tài)形成過程

從IT項目復雜性可以看出，IT項目最終交付的軟件產品，是多種知識、資源動態(tài)結合而成的知識產品。不少學者[12]認為，敏捷產品是知識產品，產品的價值主要產生于它所包含的知識，而非產品的有形部分，同時認為過程也是一種知識產品。Wang[13]認為，ERP實施的關鍵是組織中系統(tǒng)和過程的相互適應，ERP系統(tǒng)知識必定產生于實施過程，并反映于產品之中。信息系統(tǒng)開發(fā)過程中，每一類知識的擁有主體是不同的，信息系統(tǒng)的開發(fā)過程就是這些主體之間的知識轉移過程，信息系統(tǒng)的最終交付成果是這種動態(tài)交互的結果。

ERP系統(tǒng)作為一種典型的IT復雜產品系統(tǒng)，反映了重量級IT項目復雜性的兩個方面，一是最終知識產品的高度復雜性，是業(yè)務知識、管理模型和軟件技術的綜合體;二是知識產品生產過程的復雜性，即據(jù)以對用戶需求的預測，以人為載體的多種知識、資源的相互作用、相互影響、相互結合，由于人的因素，過程管理具有較大的不確定性、不可預見性。實踐中，IT復雜產品系統(tǒng)的第二個復雜性，即動態(tài)生產過程的復雜度要遠遠高于第一個復雜性，而項目成敗也多決定于此，項目風險的控制也主要存在于此。

4 重量級IT項目的敏捷管理思想

IT項目敏捷開發(fā)的需求主要表現(xiàn)為快速適應系統(tǒng)需求的變化、提高軟件生產率、突出企業(yè)自身特點、支持動態(tài)聯(lián)盟、面向業(yè)務目標持續(xù)改進和重組等方面。軟件敏捷開發(fā)不僅僅簡單地意味著軟件的快速開發(fā)，它著重于對軟件需求、過程和產品變化的靈活快速反應，是基于統(tǒng)一概念的一整套技術。和傳統(tǒng)的軟件過程有相當不同，敏捷軟件方法是一種輕載的、基于時間的、恰好夠用(Just Enough)的、并行的和基于組件的軟件開發(fā)過程[14]。

但是敏捷方法高度的動態(tài)性、靈活性優(yōu)勢也形成了其應用的局限性。對于規(guī)模較大的IT項目(重量級項目)，強功能、高集成的復雜性，使敏捷方法的適用受到極大的挑戰(zhàn)。而重量級IT項目也具備需求快速變化、業(yè)務目標實現(xiàn)、提高開發(fā)效率等需求，也需要敏捷思想的應用。目前關于敏捷管理的研究仍強調敏捷過程適用于特定的環(huán)境——高風險、不可預測和小規(guī)模的探索型軟件研發(fā)項目。有學者意識到了敏捷理念與傳統(tǒng)實踐的融合，一些CMM 和ISO9000的組織也開始接受部分地應用敏捷方法[15]，但是這些同時考慮項目過程的成果，沒有引入構建過程的核心要素——知識鏈，所以顯得操作性不強，也缺乏實證。因此，本文提出一種重載過程的敏捷性改造，即基于敏捷思想的重量級IT項目管理方法。

5 基于敏捷過程的重量級IT項目管理框架

基于敏捷過程的重量級IT項目管理框架，力圖達到的目標是:依據(jù)“敏捷靈活”與“過程規(guī)范”相平衡的原則，解決長周期性、高集成性、功能全面性等重量級項目特性下敏捷方法的有效性。框架的核心思想是:(1)建立復雜產品架構及系統(tǒng)動力學模型，實現(xiàn)復雜產品基于動態(tài)關系的分解與優(yōu)化，導出最優(yōu)知識產品單元劃分;(2)構造基于多智能主體的柔性團隊，設定團隊內部協(xié)同的元規(guī)則，設定團隊功能績效指標，實現(xiàn)外科手術式團隊構建和能力評價;(3)基于能力的柔性團隊與知識產品單元匹配，根據(jù)團隊特性分配開發(fā)任務;(4)基于適度規(guī)范的過程管理，微觀上是柔性團隊的自組織迭代，宏觀上是過程管理的規(guī)范框架，實現(xiàn)重量級IT項目的動態(tài)、柔性、規(guī)范?？蚣軆热萑鐖D1所示。

5.1 IT復雜知識產品的模塊化分解

模塊化開發(fā)方法，首先保證了復雜IT產品的降階，從分解的角度保證了項目開發(fā)的操作性;模塊化也可以提高整個產品開發(fā)的并行化，大大提高產品開發(fā)的效率;同時，通過交叉優(yōu)化保證各模塊的質量，實現(xiàn)“一次達到目的”與傳統(tǒng)“反復做直到滿意”的有機結合，從而保證產品系統(tǒng)的質量。

傳統(tǒng)軟件架構理論一般基于產品功能的靜態(tài)劃分[8]，主要從信息流角度考慮模塊單元的內聚與耦合關系，更多來自于項目初期基于需求的預測和設計;而敏捷方法更關注過程中需求創(chuàng)新，趨于對最終目標的逼近，是一種迭代更替漸進式方式。因此，此種方式下，關于知識產品的模型表述，勢必與傳統(tǒng)軟件架構描述方法有所不同。復雜IT項目的模塊化除了考慮最終知識產品的功能特征外，還要考慮開發(fā)過程的協(xié)同與控制問題。為此可以建立IT產品基于最小完備單元圖的隨機Petri網模型[16]，采用消解規(guī)則進行系統(tǒng)分析，靜態(tài)和動態(tài)分析相結合，有效地反映產品結構中任務執(zhí)行或信息傳遞的主要特征，反映知識產品單元之間順序、并行、交叉等多種復雜的網狀動態(tài)結構關系。

隨機Petri網模型中，用變遷表示單元本身，而變遷之間的關系則代表單元之間的關系。根據(jù)每個變遷(單元)的內在特征，可形式化定義為一個七元組

即{活動，輸入產品，輸出產品，前置條件，后置條件，環(huán)境，度量指標}。

從最小完備單元圖出發(fā)，結合已建立的變遷(單元)間基本關系圖和建立原理可以得到最小完備單元圖對應的Petri網基本模型。直接計算該隨機Petri網模型的復雜度很高，可以應用文獻[16]中提供的關系度分解技術，考察最小完備單元圖的相應矩陣，將單元進行分組。然后，根據(jù)不同組內單元之間原來關系的最高出現(xiàn)頻次進行組間連接。多層次的分解，可以形成復雜產品的金字塔型模塊結構，既包含了靜態(tài)功能信息，又反映開發(fā)過程的動態(tài)信息。

5.2 柔性多項目團隊

柔性團隊是典型的“外科手術式團隊”，其內部具有高度的柔性和靈活性，團隊成員之間有深入的溝通和密切的協(xié)作;對外則呈現(xiàn)高度的開發(fā)效率和運行規(guī)范，能夠進行顯性的能力評價和績效考核。柔性團隊的概念模型可以表示為

T=F(Ma， Mr， ST， C， Ms)

其中T指柔性團隊(Self Organizing Teams， or Well-Structured Teams)，是具有高度適應能力，自組織與他組織相結合的項目開發(fā)團隊。Ma指多智能主體(Multi-Agents)，即團隊成員，具備能動性、協(xié)作性的知識主體，其中包括用戶方的參與。Mr是指元規(guī)則(Meta Rules)，團隊成員相互協(xié)作溝通的基本規(guī)則集。根據(jù)復雜適應理論，該團隊系統(tǒng)由一群行動者組成，他們按照一套規(guī)則與其他人交流，通過探索實現(xiàn)目標，這其中“元規(guī)則”特別重要。它是團隊協(xié)作的基本依據(jù)，其他規(guī)則是這些元規(guī)則的不同函數(shù)。ST是共享的隱性知識(Shared Tacit Knowledge)，團隊長期協(xié)作過程中所共享的默會知識集。C是指情境(Contextual)，是柔性團隊完成具體任務時所面臨的資源、關系、環(huán)境、他人協(xié)作等狀況。Ms是指基于能力的柔性團隊度量(Measures)，度量的目的一是與模塊化的結果——知識產品單元的匹配，為產品單元尋找最佳的開發(fā)團隊;二是對團隊的績效進行考評，并動態(tài)更新團隊能力表征，指導團隊的成長演化。

柔性團隊是重量級IT項目管理的基本組織單元。對于模塊化后的開發(fā)任務，一般就由多個柔性團隊根據(jù)自身特質選擇相應的開發(fā)單元，并納入動態(tài)組織網絡進行管理。每個團隊的敏捷軟件開發(fā)過程必須定義每個活動什么時候、誰、在什么地方、采用什么工具協(xié)助等等具體的細節(jié)場景，同時也要根據(jù)項目的目標、團隊規(guī)模、項目關鍵程度、風險以及不確定性和客戶協(xié)作程度這些不同項目的因素對活動進行裁減和調整。除了定義單個活動以外，定義多個活動之間相互的關聯(lián)和影響，形成一個完整的過程系統(tǒng)也是關鍵。這需要在開發(fā)過程中定義各種場景，來說明各個活動如何結合協(xié)作。

5.3 統(tǒng)一產品定義和標準

復雜IT產品系統(tǒng)的開發(fā)強調相關模塊的兼容性。為了使模塊的開發(fā)團隊一開始就考慮復雜產品各個模塊的所有因素，統(tǒng)一的產品定義與技術標準是系統(tǒng)集成研究的關鍵，是支持各模塊開發(fā)團隊工作的必要條件，使各模塊開發(fā)的專業(yè)人員有共同的語言，使用“同一種語言”進行交流。從而使各團隊能相互協(xié)作和共享信息，通過彼此及時、有效地通信和交流，盡早地發(fā)現(xiàn)問題并予以解決，以達到各項工作協(xié)調一致。

復雜IT產品系統(tǒng)統(tǒng)一的產品定義與技術標準包括產品功能、性能、用戶要求、開發(fā)、質量保證、進度計劃等方面，把不同階段可能出現(xiàn)的問題，先期加以研究制定，對產品的功能、性能、可靠性、可測試性、可維修性、可重用性等預先進行定義和標準化，使IT產品開發(fā)一次成功，避免出現(xiàn)大的反復。除了產品定義和標準外，多項目團隊還需要共享的知識資源等的支持，如通用的組件、構件、元素等。

5.4 重載過程適度規(guī)范集

基于優(yōu)化模型的IT開發(fā)重載方法，其理論假設是過程可以通過持續(xù)的改進而提高能力，而過程是能力意味著產出結果是可預測的。以優(yōu)化和預測為特征的傳統(tǒng)過程管理雖然無法解決軟件開發(fā)難題，但其過程管理模型和框架的規(guī)范性，是保證軟件質量的重要內容。

敏捷軟件過程主張結合企業(yè)業(yè)務，開發(fā)自己的軟件過程，這就是“Just Enough”策略。該策略指出，在進行軟件過程改進時，應著重領會CMM等過程模型的精神實質和基本原理，建立適合自己的過程框架而不是拘泥于CMM等形式。在實施CMM時，必須考慮過程的多樣性，從實際出發(fā)做好文檔和過程管理，把過程管理與企業(yè)的業(yè)務目標緊密結合起來，同時探索可滿足CMM KPAs的最小關鍵活動集合。

另外，為了保證敏捷、適應原則下的過程管理，除了傳統(tǒng)方法的適度規(guī)范集外，更重要的是增加模塊化開發(fā)的協(xié)同機制。這種開發(fā)機制，首先是基于傳統(tǒng)過程框架下分階段的敏捷改進，如敏捷建模、敏捷設計、敏捷開發(fā)、敏捷測試等;然后是基于敏捷思想的過程框架改進，如基于全局的需求變更管理、模型調配、進程反饋，甚至必要時的全局性迭代重啟。

5.5 基于知識轉移的敏捷過程

Paulk曾經提出“XP是CMM的一個截面”的理念，指出敏捷方法可以是規(guī)范方法的一個環(huán)節(jié)或微觀表現(xiàn)。因此，“基于知識轉移的敏捷過程”是基于敏捷過程的重量級IT項目管理框架的核心。其中“知識轉移”則強調敏捷開發(fā)過程中，多智能主體與知識產品之間多種形式、多種類別的知識轉移活動，并且最終的產出是這種轉移活動集成的成果。動態(tài)結合過程中，知識相互關系的處理，多主體的互動與影響等，都會導致最終成果的不同。

IT項目開發(fā)中的知識轉移是一個復雜過程，與知識主體的屬性、關系、知識本身的屬性等密切相關。IT開發(fā)過程涉及不同團隊的各種知識和技術，專家知識分布于團隊之中而不是某一個人，他們必須進行工作聯(lián)合和知識集成去完成統(tǒng)一的任務。這些知識在軟件開發(fā)過程中不斷在智能主體間、智能主體與產品間傳遞。敏捷開發(fā)過程由于強調人的主動性、適應性，強調團隊的自組織特性，對知識轉移的高效管理就顯得尤為重要。

有別于傳統(tǒng)基于規(guī)模的軟件過程，基于知識轉移的敏捷過程由構想、推測、探索、適應、結束等幾個階段組成，其結構和實施是面向時間的，是一種基于時間的軟件開發(fā)(Time-Based Software Development)[13]。每一次迭代有固定的時間限制，一個復雜的項目可被分為多個迭代和多次發(fā)放，需求在迭代開始時被確定，直至下一次迭代開始前才再次修改。

6 管理對策

根據(jù)以上管理框架，實踐中的管理對策主要應該采用:

(1)建立包括技術接受方和技術提供方在內的聯(lián)合開發(fā)團隊，通過培訓、交流和組織，提升開發(fā)團隊的柔性。

其中包括甲乙雙方的聯(lián)合開發(fā)團隊是本對策的核心，特別在技術提供方對技術接受方的業(yè)務比較生疏、業(yè)務過程較為復雜的情況下。

(2)測評待開發(fā)產品的復雜程度及開發(fā)團隊的柔性程度，構筑重量級項目敏捷開發(fā)基礎。

產品復雜程度和開發(fā)團隊柔性程度是客觀的，理想情況下應該有客觀的評價尺度，初始階段可以以較大粒度定性測定。

(3)以實現(xiàn)高效知識轉移為出發(fā)點，劃分產品模塊，使之與開發(fā)團隊的柔性相適應。

產品模型的劃分并不唯一依據(jù)產品的復雜程度，開發(fā)團隊的柔性程度是客觀的也是相對的。因此本對策的核心是圍繞建立高效的知識轉移渠道。

(4)積極采用和不斷開發(fā)、積累輔助工具，提高團隊開發(fā)效率、降低團隊工作強度。

規(guī)范和靈活是一對矛盾，利用前人的成果，并不斷積累自身的經驗，將會使團隊以靈活的方式繼承規(guī)范的過程。

7 結論

本文通過平衡“過程定義”和“靈活性”，既考慮過程對活動的指導，又要保證活動與敏捷價值觀的原則一致，提出基于敏捷思想的重量級IT項目的管理框架。該框架中，基于重載方法適度規(guī)范集的開發(fā)協(xié)同機制是關鍵，其既要規(guī)范開發(fā)過程的活動、文檔、團隊行為，又要從全局角度協(xié)調多團隊多模塊的開發(fā)活動，還要確保收集到適當?shù)姆答佇畔?，將這些信息融入到新的迭代過程中去，以此實現(xiàn)知識轉移與敏捷項目管理的結合，達到傳統(tǒng)項目管理與敏捷項目管理的融合，實現(xiàn):拓寬知識轉移的應用深度，拓展敏捷項目管理的應用廣度。

該框架反映了重量級IT項目開發(fā)的敏捷思想，但更多技術細節(jié)尚需解決，如復雜項目的模塊化分解方法、柔性團隊的構建及行為規(guī)則、產品與標準的定義、適度規(guī)范集及協(xié)同機制等，均需要進一步研究給出具體的模型、方法和機制。這是本文后續(xù)研究的主要內容。

參 考 文 獻:

[1]Chen J， He K J. The pair-working model for project team development[A]. Proceedings of 2003 International Conference on Management Science Engineering[C]. Atlanta， 2003. 2520-2524.

[2]Highsmith J. Agile project management[M]. Beijing: Qinghua Publishing House， 2005. 7-10.

[3]Turk D， France R， Rumpe B. Assumptions underlying agile software-development processes[J]. Journal of Database Management， 2005， 16(4): 62-87.

[4]Shaw M， Garlan D. Software architecture: an emerging discipline， upper saddle river[M]. NJ: Prentice-Hall， 10-25.

[5]Hobday M， Brady T. Rational vs. soft management in complex software: lessons from flight simulation[J]. International Journal of Innovation Management， 1998， 2(1): 1-43.

[6]Hansen K， Rush H. Hotspots in complex product systems: emerging issues in innovation management[J].Technovation， 1998， 18(9): 555-561.

[7]Ren Y T， Yeo K T. Research challenges on complex product systems(CoPS)innovation[J]. Journal of the Chinese Institute of Industrial Engineers， 2006， 23(6): 519-529.

[8]MacCormack A， Rusnak J， Baldwin C Y. Exploring the structure of complex software designs: an empirical study of open source and proprietary code[J]. Management Science， 2006， 52(7): 1015-1030.

[9]Simon H A. The architecture of complexity[A]. Proceedings of the American Philosophical Society[C]. Reprinted in E:CO， 2005. 138-154.

[10]Banker R D， Slaughter S A. The moderating effects of structure on volatility and complexity in software enhancement[J]. Information Systems Research， 2000， 11(3): 219-240.

[11]Hobday M. Product complexity， innovation and industrial organization[J]. Research Policy， 1998， 26: 689-710.

[12]杜紅，李從東，李曉宇.面向ERP實施的知識轉移體系研究[J].管理工程學報，2005，19(2):110-113.

[13]Wang E T G， Lin C C L， Jiang J J， et al.. Improving enterprise resource planning (ERP) fit to organizational process through knowledge transfer[J]. International Journal of Information Management， 2007， 27: 200-212.

[14]沈備軍，陳誠，居德華.敏捷軟件過程的研究[J].計算機研究與發(fā)展，2002，39(11):1456-1463.

[15]Williams L， Cockburn A. Agile software development: it’s about feedback and change[J]. IEEE Computer， 2003， (6): 39-43.

[16]顧元勛.基于單元關系度技術的Petri網模型分解[J].系統(tǒng)工程學報，2003，18(6):491-497.