VS2005改善團隊開發的人力負擔與協調

2021-04-06 22:19:05 字數 3330 閱讀 5865

vs2005為落實軟體開發生命週期與流程管理,而明確區分角色(但同一人可擔任多種角色)與權責,讓企業重新調整組織結構,卻可能帶來額外的人力負擔,以及資訊共享的困難。

角色與分責所增加的人力負荷

vs2005採用軟體開發生命週期,作為企業在選擇資訊系統發展方**(system development methodology)時的標準流程,其特徵是將開發流程區分為幾個連續階段(3個~20個不等),標示著不同的系統發展成果,實作時則配合專門的技術角色(分析師、架構師、開發人員、測試人員與專案經理等),目的是容易管理、分層負責與確保軟體質量。vs2005則在軟體開發生命週期中定義出區分架構師(architect)、開發人員(developer)、測試人員(tester)與專案經理(project manager),並將軟體依角色區分為3種版本:team architect、team developer、team tester等,專案經理的權責則包含在excel或project上,可與team system整合。

以工具區分角色的做法對大型開發團隊而言,終於有對應的專屬工具,但對中小企業而言,通常由一人扮演多種角色,而不同角色下工具卻能強迫兼職的人不至於混淆工作,以致於難以追蹤工作進度(這是造成中小企業軟體專案常「重工(re-work)」的原因)。

另一點附帶的優點是應用軟體生命週期對中小企業主管而言,仍是艱澀的觀念,但微軟卻可以透過功能與版本的區分,再加上整合,使初學者跟著工具所規範的功能,即可以完成軟體開發生命週期。

角色與分責是軟體工程化的精神之一,我們可以用半導體製程的方法來比擬,生產線將晶圓的製作手續上區分為黃光製程、薄膜製程等,各製程緊守著本身的生產責任,達到整體流程標準化(sop),而製程整合工程師負責排除製程缺陷問題,並確保高良率等。但角色與分責使得企業的開發團隊中常一人分飾多種角色的問題,以及人力精簡的目標又重回原點。為了角色與分責勢必增加人力,但這對企業而言,原本因為資訊單位只是消耗預算的單位而精簡人力,若為了軟體質量而朝向工程化,形成兩難的局面。即使敏捷式開發方法能解決人力問題,但企業中開發角色的賦予,並非如工程師所願。他們常因為主管的臨危受命下擔任救火隊的角色,使得角色混淆問題嚴重,vs2005雖立意良善,但企業勢必在現實與工具間取得平衡點,而且還要取得所有成員的共識,否則萬用的瑞士刀只是用主刀來切水果,不免大材小用,而且這樣的狀況下,vs.net 2003已能應付需求,不需要公升級到vs2005。

團隊協同作業難以溝通與培養默契

如果vs 2005只是區分版本,那麼過於小看此次改版。軟體開發生命週期注重反覆式的過程,以逐步提公升軟體質量,而在反覆改進過程扮演開發方向控管的操舵手:專案經理,不再置身事外。vs2005此次也針對專案經理開闢專屬的工具:team system,讓專案經理與開發人員因為使用共通的工具而使用共同的語言溝通,不再像是局外人。

team system也讓開發工具轉為開發與管理平台,讓開發人員可以分享資源,更重要的是讓專案經理可以從集中式平台監督軟體專案。以往開發工具為單機版時,各成員的工作成果均保留在個人計算機,專案經理僅能透過威脅利誘的方式,才能彙整各成員的成果成為專案進度,但此時專案經理不但被架空,而且形同虛設。

為了管理創意成果供貨商莫不絞盡腦汁,像borland便在starteam產品中內建repository(**儲存庫),這是一種**控管的資料庫,用於有系統與結構化地儲存軟體開發過程的各式資料、圖表與程式**等。微軟則在team system鏈結sql server 2005達到相同的功能,而且n-tier架構強迫軟體工程師在開發過程便進入專案控管,而不是寫完程式後才決定要不要歸建到專案檔中。這讓開發更有效率,也讓軟體工程師專注在程式開發上,而不是與管理有關的瑣碎、例行事務上。

vs2005觸及開發團隊合作的痛處,這牽涉到開發人員技術本位與文人相輕的老問題。「軟體**(俗稱hard coding的工程師)」與規畫架構的架構師不平等的工作任務與負擔,以及最後把關的測試工程師所揹負的壓力,都會在團隊中形成各自為政的問題。最常見的是測試工程師與開發工程師難以取得協調,以及資歷高於專案經理的資深工程師,對流程與管理的抗拒,特別是這些人掌握舊式語言(如corba語言)或舊型主機(legacy system)的維護等,使得專案經理的權威受到挑戰,以及對團隊向心力都形成威脅。單從工具的角度無法面對這些問題,然而,以工具要求團隊合作只是讓問題浮上檯面,但企業可能沒有心理準備面對這個積弊。

專案進度控管與資訊共享矛盾

vs2005實作軟體專案管理,並不同於一般我們所謂的專案管理,目前技術上能實踐的部份,僅只於與軟體工程所要求的軟體質量相關的績核專案,例如原始程式**或臭蟲數量等。

專案入口**(project portal website)主要是突顯出專案管理並非專案經理本身的事,而是所有關係人(stakeholders)都應了解,隨時隨地都可看到最新進展。此外,軟體開發專案的特性是集合各種技術專精的人員,入口**有助於分享資訊,這在台灣中小企業的資訊專案正面臨這個嚴重問題,也就是成員將技術資訊藏私,以展現他在團隊的地位。james lewis提出兩個建議,能讓專案運作更有效率:

1.重要成員擁有較充足的資訊時,許多的決定就可以自行處理,不必事事求教於專案經理。

2.資訊具有自我組織的特性,當所有團隊成員都能一同分享專案經理的資訊,並加以使用時,對整個團隊的幫助最大。

簡單地說,無論是專案經理或工程師,對任何成員蒙蔽資訊都會造成不滿,並延燒到其它成員而瓦解向心力。微軟也注意到資訊分享在軟體專案上的重要,當vs2005每次新增乙個專案,便會對應在內建的wss(windows sharepoint services)上對應開啟乙個wss**,不僅用於專案現狀與臭蟲數量回報等。此入口**也支援excel與project(vsts可取代project server),專案經理在指派任務後,將任務分配上傳到wss**或整合所有資訊。現實中,資訊部門常因為緊湊的接案與結案等過程,少有喘息空間,遑論有空分享資訊與文章,而且入口**的績效報告是工作上的無形壓力,多數人不會主動面對。

開發流程與創意、彈性的衝突

微軟在vs2005工具中用於描繪軟體開發生命週期的方**(methodology)稱為:microsoft solutions framework(msf),涵蓋軟體開發與基礎環境部署等完整流程的中介模型(meta-model)。vs2005內建兩種主流的流程模板,分別是msf for agile software development與msf for cmmi process improvement。顧名思義,前者適用於小型團隊所使用的敏捷式開發流程,講求測試與原型(prototype)、較短的開發迴圈與持續整合等;後者則適用於大型開發團隊,注重嚴謹的開發流程,並符合cmmi(capability maturity model integration)level 3的要求。

開發工程師的毛病是技術本位,缺乏管理的思維,當然也缺少被流程制約的性格。另乙個問題是他們常被專案擠壓時間,而這些專案都是主管為了利潤而接回來的,此時,他們會為結案而犧牲各階段性流程上所需的報告、檔案等成果,並視為末枝小節造成流程混亂。人們都知道工具是死的,但遵守制度考驗著成員間的默契。

VS2005 開發水晶報表(初級)

自 在網上看到很多用vs開發水晶報表的文章,但都是基於vs2003的,找到的這篇才是真正基於vs2005,而且原博主 講解的很詳細,web專案 windowsform專案 都講到了。同時 根據我的理解,進行了一些修改和調整 水晶報表是乙個功能強大的報表工具,現在已經被microsoft visual...

win32 搭建QT和VS2005開發平台。

ide vs2005 qt版本 qt everywhere opensource src 4.7.0和qt sdk win opensource 2010.05兩個版本。vs add in qt vs addin 1.1.6和qt visual studio integration v1.43.先說...

在vs2005中開發的乙個儲存過程

目的 根據輸入的序列號獲得對應的合同號 輸入引數 序列號 輸出 存在則輸出對應的合同號,不存在則輸出null 開發日期 2009 05 05 版本 1.0 alter procedure dbo.getcontractbyseq seq nvarchar 10 as declare contract...