以角色為基礎的軟件開發團隊建設

0 評論 2758 瀏覽 2 收藏 23 分鐘

軟件開發管理的重要任務之一就是團隊的組建。本文提出了一種以角色為基礎的團隊建設方法,以有效提高團隊建設能力。在軟件開發過程中,對開發和管理活動進行分解會產生一系列的子活動,對子活動及其相關知識的抽象產生角色——問題角色;對人的分析和抽象也產生角色——人員角色。

在軟件開發過程中,對開發和管理活動進行分解會產生一系列的子活動,對子活動及其相關知識的抽象產生角色——問題角色;對人的分析和抽象也產生角色——人員角色。

問題角色與人員角色的有效關聯也就是團隊的組建,問題角色與人員角色的再定義和改進也就是團隊的建設。以角色為基礎來進行軟件開發團隊的組織,能夠比較全面地解決項目管理問題,而且團隊建設很容易達到可持續改進的目的。

角色抽象作為一種載體,可以很好地進行軟件工程知識體系和企業知識地圖的組織,滿足企業知識體系持續改進的需要,因此角色團隊組建和建設也可以作為軟件工程實施方法之一。

軟件開發項目立項時,重要工作之一就是開發團隊的組建;在軟件工程實施(把軟件工程研究結果產生的標準或規范如ISO、RUP、MSF、XP具體應用到軟件開發活動的程稱為軟件工程實施)的過程中,要解決的問題之一就是關于團隊組建規則的定義;從企業發展的角度來看,軟件開發團隊建設是企業建設的重要任務??傊浖_發團隊的組建和建設是企業經營和發展的重要內容之一。

幾乎所有的管理知識體系或規范都涉及到個體和團隊建設問題,比如組織行為學[Stephen P.Robbins,1997]對個體和團隊的行為進行了研究;項目管理[PMI,2000]中的計劃、人力資源管理、項目集成管理、項目溝通管理等多個項目管理領域都涉及到團隊建設和管理;在軟件能力成熟度模型(CMM)[SEI,2000]的發展過程中,從個體軟件過程和團隊軟件過程來研究軟件的開發和管理。對個體和團隊管理的研究是管理學的核心任務,涉及到的知識和學科紛繁、復雜。

然而,在管理的具體實施過程中,客觀上管理環境的不同及主觀上管理者的偏好,一般會在理論或規范基礎上進行簡化、刪減、方向取向、分類歸納等工作,最后表現為各自獨立的制度、規則、知識、評估方法、認證等多種獨立體系,失去了其內在的聯系,管理工作仍然復雜,而且不利于改進。

瑞理統一過程(RUP)[Rational,2001]通過對工作流分解的方式進行了軟件開發過程及活動的分解和定義,并以角色為中心來進行知識、活動、規則、工具等的關聯組織,從而把軟件開發活動一體化、層次化、結構化,并保持其內在的有機聯系,為個體和團隊軟件開發活動提供了很好的指導。

本文以“角色”這一概念為基礎,提出了“以角色為基礎的軟件開發團隊建設”的觀點,闡述了其原理和方法,并對其優、缺點進行了分析,簡要說明了該方法對“軟件工程過程改進”的支持。

為簡化敘述,文中“以角色為基礎的軟件開發團隊”簡稱為“角色團隊”,對應地,其它一般團隊簡稱為“一般團隊”;許多地方把文檔、資源、信息、規則等統稱為“知識體系”。

一、角色的含義

根據RUP[Rational,2001]的定義(如 “圖 1 RUP中角色的含義”所示),角色的含義是:角色是抽象的職責定義,它定義的是所執行的一組活動和所擁有的一組資源。角色通常由一個人或作為團隊相互協作的多個人來實現。

圖 1 RUP中角色的含義

角色定義是一種管理上的要求,是“以活動為基礎的管理”的表現形式,角色定義的依據是:問題、人、管理都可以分析為一系列活動的組合,這些活動有輸入、輸出,需要一定的環境和工具,需要活動承擔者具有一定的能力,所有這些要素都是可以定義的,其聯系的核心可以稱為“角色”;管理本身的任務包括對問題域的角色分解、對人的角色分解、問題角色與人員角色的配對等。

因此,我們可以定義通用的角色模型如“圖 2 通用角色模型”所示。

圖 2 通用角色模型

通用角色模型的含義:

  • 角色是活動的承擔者,角色與所需要的知識、工具、環境、輸入、輸出相關,是分析和定義結果的抽象,是一個容器;
  • 角色是構成知識體系的基本粒子,角色粒度大小和層次構成根據企業對角色團隊掌握的成熟度靈活控制。

問題角色容納了對問題域的認識和分析結果,人員角色滿足預定義的能力和人格要求,并在掌握了相關知識和工具后獲得認證;問題角色和人員角色關聯后,人員角色利用知識、工具、輸入文檔等進行創造性活動,解決問題角色的需求;關聯活動產生的結果經過總結、分析,進行經驗總結反饋,從而可以改進問題角色和人員角色的定義和認證,為組織進步提供通道。

二、角色團隊組建原理

在軟件開發實踐中涉及到的問題、人、管理都具有一個共同特點:復雜,人類解決復雜問題的方法離不開“分解”,分解結果被定義為一系列的“信息點”,由于這些“信息點”的粒度、層次、構成還是太復雜,因此又被進行分類、歸納、總結成為一系列的“知識體系”,這些“知識體系”各自有重點,同時又具有一定的相關性,有的發展為“學科”,有的發展為“規范”,知識體系在具體應用時又以知識、規則、制度、工具等各種方式來具體體現。

在這些分析、綜合、歸納、合并的過程中,關聯性并沒有消失,但是變得難以掌握和理解——在學習的過程中很少有機會同時應用多種知識及其關聯性,而在知識的具體應用過程中,由于其龐大、復雜,只有少數專家能夠充分理解、綜合應用,大部分人難見全貌、只見一斑,能夠學習獨立的學科,但是很難根據相關性進行綜合應用。于是,又產生了一個新的問題:良好的知識體系得不到良好的應用,這就是常見的“理論與實踐脫節”問題。

“角色”是一個抽象的概念,通過角色,能夠有機地把知識體系以及實踐結果聯系在一起,而且是恰到好處——只有需要的知識體系和實踐結果才和對應的角色進行關聯,通過角色粒度的控制甚至可以達到這樣一種效果:只要符合了角色定義要求,那么就能夠順利完成角色活動。另一方面,角色概念與“社會化分工”原理不謀而合,主要差別僅僅是粒度、層次上的差別而已。

人員角色并不代表個人,而是說明個人在某一具體業務活動中應該如何表現以及他們應該承擔的責任。角色有一組互相聯系的活動需要執行,這些活動密切相關,在功能上互相補充,所以最好由同一個人來執行。活動與知識體系密切相關:知識體系提供活動的輸入和輸出,并提供活動之間的通信機制。項目團隊成員在履行角色職能的過程中,一個人可以擔任許多不同的角色,一個角色也可以由多個人來承擔。

三、角色團隊組建方法

根據“角色團隊組建原理”,角色團隊組建就是面向問題、人進行角色的定義和關聯,把相關知識有機地分布到角色上去,在具體團隊組建時進行合理關聯配對:讓合適的人在合適的時間利用合適的工具完成合適的任務。

1.?從問題分析角色需求

根據相關知識體系、過去的定義、經驗、角色定義原則,把解決問題的過程分解為子問題及子活動,控制子活動的粒度甚至粒度層次,并就每個子活動進行關聯分析、環境分析、知識分析,最后定義為角色,稱為問題解決角色,如“圖 3 從問題分析角色需求”所示。

圖 3 從問題分析角色需求

?2. 從人員分析角色認可

根據企業發展要求、角色定義原則、人的能力、興趣等要素,對人進行分析和認可,控制知識體系的粒度、相關性等,最后定義為角色,稱為人員認可角色,如“圖 4 從人員分析角色認可”所示。

圖 4 從人員分析角色認可

四、角色團隊組建

在項目團隊組建時,根據對問題域的分析結果,在成員角色表中選取對應的角色去承擔問題角色任務,并從項目管理的角度來進行工作時間分配、費用預算等。如果企業內部沒有所需要的角色,則可以考慮尋求外部資源。如“圖 5 以角色為基礎的團隊組建”所示。

圖 5 以角色為基礎的團隊組建

五、角色團隊組建與建設過程

角色團隊組建是發生在項目立項時的工作,而角色團隊建設是在企業經營的整個生命周期內都要進行的,建設結果是角色團隊組建的基礎。建設是持續性的,組建是臨時性的,建設為組建提供基礎,組建后的項目團隊的實施結果為建設提供依據,整個過程如“圖 6 角色團隊組建與建設過程”所示。

圖 6 角色團隊組建與建設過程

角色團隊建設要完成的工作有:

  • 通用問題域角色定義:定義企業開發領域的通用問題,根據對通用問題的解決“從問題分析角色”工作,定義問題域角色體系;
  • 通用人員角色定義:根據“問題域角色體系”,對人進行分析、定義和認證,建立關于“人員角色體系”;對某些超出問題域角色體系的人的角色也進行定義,選擇標準可以根據企業的發展方向進行選擇;
  • 問題域角色與人員角色映射規則:為了適應企業業務的變化和發展、滿足管理要求,問題域角色與人員角色不一定要一一對應,甚至粒度、層次也可以不一樣,所以要建立映射規則為以后的工作安排提供指導。

角色團隊組建時要完成的工作有:

  • 具體問題域角色定義:以“問題域角色體系”為基礎,分析項目所面臨的問題,定義“項目角色體系”;
  • 具體人員角色定義:對照“項目角色體系”和“人員角色體系”,根據映射規則,進行配合、關聯、調整,完成項目團隊的組建和任務計劃,進行項目實施;
  • 角色體系改進:在項目實施的任何時刻,如果有超出“問題域角色體系”的角色產生,可以根據需要補充到“問題域角色體系”中,對人員角色體系的變化也可以采取同樣方法處理。

在具體的角色團隊建設過程中,實際上可以保留多個層次的角色體系,主要原則就是適應企業的經營要求和發展要求,其它相關內容如取舍、粒度控制、層次控制、結構控制、管理、認證等原則和方法本文不再贅述,部分內容可參考RUP。

  • 角色團隊分析
  • 一般團隊面臨的問題和原因

在過去的實際管理過程中,一般團隊存在很多問題,包括:

  • 結構簡單:過于簡單化,“開發團隊”等于“工程師集合”,其相關性控制、團隊配合等全部依賴于領導者的直覺或感覺;盡管不會完全錯誤,但是不夠精細,屬于“粗放”管理范疇;
  • 管理困難:缺乏層次級別,幾乎都處于同一個層次上,令難行,禁難止;
  • 職責不清:針對工作內容,一方面缺乏規范,另一方面范圍模糊,因此導致職責不清楚,工作目標模糊;
  • 資源浪費:由于組織和管理不力,軟件開發效率低、成功率低,并期望通過提高個體素質來提高效率或成功率,片面追求文憑,本科不行用碩士,碩士不行用博士,等等,導致資源浪費,經營成本高;
  • 發展緩慢:團隊的進步沒有明確的計劃和方向,團隊的進步依賴于個體的隨意發展,因此團隊的建設變成了艱難地培養“全才”,很難培養“專才”;企業發展不明確,員工發展也不明確。

導致上述問題存在的根本原因是什么?我們認為,主要的原因有:

  • 對問題的認識不充分:沒有對問題域進行定義、分析、內容組織,或者比較薄弱,僅僅從比較高層的軟件開發的“需求、分析、設計、開發”出發來進行開發團隊的組織,缺乏“具體問題具體分析環節”;
  • 對人的認識不充分:對個體的認識依賴于管理者的直覺、感覺和經驗,個體的發展依賴于自己的興趣,把工作當成任務,過多依賴于文憑評價;
  • 對管理的認識不充分:過分依賴管理者的直覺和感覺,安排任務時“大體上”知道存在的問題、什么人能解決什么問題,但是沒有進行問題的分化、定義、具體化等細節工作,比較“粗放”;管理過于依賴于權力;
  • 過于平面化和大粒度:從問題認識、人的認識、管理認識三個方面都缺乏層次化、模塊化和結構化,分工粒度過大,忽略問題的多樣性、人的多樣性、管理的多樣性,決策一刀切;

最基本的原因是全面性問題,不夠全面導致管理不到位:用不合適的方法去解決模糊的問題,如“圖 7 一般團隊的問題域覆蓋程度”所示,應該解決的問題沒有解決,解決問題的人又不一定是合適的。

圖 7 一般團隊的問題域覆蓋程度

六、角色團隊對問題的解決

角色團隊通過“問題角色體系”的建立來促進對問題的分析,很大程度上解決了一般團隊存在的“不夠全面”問題,改善了對問題域的覆蓋程度,如圖“圖 8 角色團隊提高問題域覆蓋程度”所示。通過“人員角色體系”的建立來進行培訓、認證、甄別,促進團隊建設,并為薪酬體系、績效考核提供依據。角色團隊組建后,管理定位更加容易:管理者有事可做,有章可循;被管理者明確管理定位和職責,依照角色關聯的合作更加順暢。

圖 8 角色團隊提高問題域覆蓋程度

更重要的是,角色團隊的組建和建設過程,就是企業知識體系的建設過程,角色體系也就是知識體系,角色體系的改進就是知識體系的挖掘和進步,是學習性組織的良好選擇。

七、角色團隊的缺點

角色團隊的建立和組建,其本身就是一項復雜的管理活動,需要有力的資源支持;角色團隊的建設是一個持續性發展的過程,不是一蹴而就的,因此需要企業具有持續建設的需要和能力,也就不適合那些業務方向頻繁變化、業務領域不明確的企業。

八、角色團隊原理在軟件工程實施中的作用

在目前軟件工程實施中,“持續改進”無疑是最重要的思想;首先,改進就必須要有一個載體,這個載體必然是企業知識體系,因此也可以采用“角色團隊”作為這一載體;其次,改進必須是持續的,也就意味著過去定義的知識體系能夠在一定程度上重用。角色團隊通過“角色”這一概念來進行知識體系的分解,通過粒度和層次的控制很容易達到高程度重用的目的,因此,角色團隊原理可以在軟件工程實施中作為實施載體來使用。

以角色團隊為基礎的企業知識體系還可以很方便地容納軟件工程規范,因而對軟件工程的實施具有很高的支持性;通過“人員角色體系”的建立,可以達到對個體的針對性培訓和學習引導,對團隊的進步具有很好的引導作用。

由于角色粒度、層次控制的靈活性,角色團隊的組建和建設可以從任何時候、任何規模開始逐步建設,非常靈活,滿足企業逐步成熟的要求。

小結

軟件開發是一項知識性活動、創造性活動,軟件技術日新月異,軟件應用領域復雜多變,所有的這些原因造成了軟件開發管理的困難,導致了軟件危機的產生。軟件管理問題的解決,離不開對知識體系的依賴和對變化的適應。角色團隊原理作為一個知識體系的載體以及對持續改進的充分支持,可以作為軟件工程實施方法之一。

參考資料

[1]? Stephen P.Robbins,《組織行為學》(第七版),1997,中國人民大學出版社;

[2]? PMI,《A Guide to The Project Management Body of Knowledge》,2000;

[3] ?SEI,《CMMI for Systems Engineering/ Software Engineering》,2000;

[4]? Rational,《Rational Unified Process?》,2000。

本文由 @我觀世界觀 原創發布于人人都是產品經理,未經許可,禁止轉載

題圖來自 Unsplash,基于 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!