化繁為簡-從活動間的依賴說起

在臉書的社團中，好友八樓哥提了一個問題：MS project中，A活動duration=1 ；B活動duration=20 。在B活動開始3天時A就必須要完成。這樣子，任務連結要怎麼寫？我是直接把B切成B1+B2=3+17 ，然後把A設為B2的前置任務，A要在B進行3天時就要完成。A1要在B進行10天時就要完成。所以B的前置任務是A fs-3 B和A1 fs-10 B嗎？

接著，八樓哥又說了以下條件：

條件1.A以及A1的開始跟B有甚麼關聯?? -> 沒關係

條件2.A以及A1的完成條件跟B又有甚麼關聯? -> 沒關係

條件3.A是一個部件到?時間，需要一天處理。

條件4.A1部件是即到即用。

就上述的情境，依據PMBOKGuide，正確的答案應該是【Activity A FS -3 Activity B】，Activity B依賴Activity A，這是非常明確的。

但肥蝦這幾年來在執行專案，設定時程與申請資源調度，有兩點想跟各位朋友分享：

(一)  一個活動不要弄太長，並且中間又陸續整合或串接其他活動。

(二)  雖然依賴關係有FS、SF、FF、SS，但其設定除了絕對的因果邏輯外，還要對照合約，並且要易於說明。

就PMBOKGuide上，說明WBS的Package要以有交付物或可管理的基礎作為單位較好，activity則為執行的活動，並不一定要有交付物，但應以管理為依據。因此以八樓哥的例子，肥蝦一看，A好像是B開始三天後投入物！因此是否B的activity搞的太大了，稍為切一下會不會比較好？

當然，如果只是為了表示符號去切割單位package或activity是不太恰當！如果B不能切割，就該說明來看：「在B活動開始3天時A就必須要完成」，這只有B開始日，以及要求A一定要完成的日子。所以最遲是B開始的第二日A就一定要開始，(A要一個工作天)；此外又沒有其它對A的限制，A的完成條件跟B沒關係。因此保守起見，又或者沒有活動A資源調度的問題，那就讓A與B一起開始【A SS B】。

在PMBOKGuide上也說，FS的關係是最常用的，但是想想：「當活動A完成後要啟動活動B」，對照一下合約！現在台灣的環境有幾份合約會寫說：「簽約次日起三個月內完成需求確認；需求確認完成起三個月內完成系統開發…。」好像都是「簽約次日起三個月內完成需求確認；簽約次日起六個月內完成系統開發…。」又再想想，當向老闆報告時，如果太多的FS、SF…的老闆的反應會如何？如果向部門主管協調人力或資源時，會不會被以「前一項活動都還沒完成，等前一個要項完成了再來討論」的理由搪塞？

記得當the one-page project management剛出來之時，肥蝦也想學學來看看，結果被一位老長官當面批說：「那一頁密密麻麻的，我只在乎合約，以及合約上的milestone。」專案管理的資訊很多，不管以何種方式呈現，重點是在溝通！在溝通過程與專案內部的使用工具或語言可否具有相當的一致性！內部使用要求的具體與週延可否順利並迅速的轉換為外部溝通的簡要與效果！

因此就上述的問題，肥蝦以為當活動A一天可完成時，需要活動B先完成三天的進度，因此風險是是B大於A，加上A  independent on B；B dependent on A,，要是B前2天進度delay了，A進來的效果也有限。此外，若是從合約的主體與溝通的效果來看，A FS -3 B跟 B SS +2 A哪一個較能觸碰人的感知與警覺？因此肥蝦在考量活動之間的關係時，除了實際的依賴邏輯外，也會儘量考量每個活動在整體風險上的份量與合約規範主體，盡量把那些SF、FF轉成SS，然後加上每個活動的duration、寬限期與警示期，尤其是那警示日。

如果肥蝦把此問題的答案由A FS -3 B轉成B SS +2 A~~~也許您會問到：「那到時關鍵路徑如何標示？」CP是那完成專案最長時程，因此理論上就算把依賴關係稍微變化也不會有影響的。也許您又會問到：「那把依賴關係弄混了，就看不清楚那前因後果，看不到可能的專案瓶頸。」專案中的每個活動都是重要的，如果不重要也不會排進專案的範圍與時程之中，因此重點是在於那些為瓶頸活動的瓶頸在哪呢？是該活動可使用的資源有限？還是人力技能不足？還是時間不夠充份？就以肥蝦個人有限的經驗，瓶頸活動的瓶頸重點大多還是在是否有適宜的資源，所以使用SS的方式來溝通，也許能夠給予主管較為深刻的印象，看看是否能在專案初期的組織安排上佔得些許許的先機。

專案的目標在達成專案目標，WBS, Activity, CP, Schedule僅是工具，因此專案的任何作為還是要以合約為依據，以合約規定的方式與設定的milestone來作為專案進一步範圍、時程等等細部規畫。因此些許PMBOKGuide說明的方式，也許在實際專案執行上可以再稍為調整簡化一下。

以上蝦扯一通，純是個人的愚見，還請  各位多多包涵。

軟體開發流程、開發文件與系統程式對得起來嗎？

因著前公司的政治糾葛，肥蝦不得不於10月1日轉移戰場。記得9月27日現在老闆打電話給肥蝦說：「有沒有空跟他去一趟客戶那！」本想說可以接到個新案子，疏緩一下這幾個月來的紛亂。不意去到後發現雙方正為了案子的文件與範圍鬧得不可開交，肥蝦還遭受炮火的轟擊！正所謂吵架無好話，這肥蝦是看淡了，只是這後續如何化解？如何完成專案？才是肥蝦關心的議題。

這個案子的主要爭議點之一就是要交付的文件種類與對文件品質的定義。因著客戶通過CMMI Level3的評審，對於案子文件種類與品質有一定要求；相反的，因著公司(10月1日上任了)內部進行的開發方式與文件撰寫方式，也因一定時間的累積有著自己的看法。因此就造成甲方嫌棄乙方的文件不夠Qualified，乙方認為甲方是變相增加工作範圍，引起雙方的不快，就變成了肥蝦首要面對解決的問題。

針對爭議，惟一的作法就是回到合約主體，看看原有合約到底有哪些條文是否涉及這爭議項目？盡力就合約記載去縮減雙方認知的差距！因為肥蝦不是本案的PM，因此就去請教PM與申請調閱RFP。結果發現了一條：本案專案開發應遵循CMMI相關規定。哇~~~光這一條，至少就得增加成本30%以上！因為本公司並沒採行CMMI，美其名可說我們Follow的是Agile software development，光就這文件的提供不啻要有專人負責，也要配合開發過程逐步產生才行。

因為甲方已經接受了先前第一、二階段的需求分析書、系統分析書、測試計畫書(雖然對方PM是諸多抱怨與覺得委曲，但木已成舟)，因此肥蝦首要的就是設法達成雙方對系統設計規格與程式規格文件的撰寫要項與內容。甲方PM是很有誠意設法完成專案目標(先不論對專案開發範圍的要求是否雙方都能接受！)，因此經過幾次的會商，就甲方提供的樣本進行討論與溝通，雙方作了部分的妥協，肥蝦就只好耐著性子、硬著頭皮，就程式碼回頭來寫相關文件。拼了一個月，經過三、四次的磋商，掰出了三十三份的程式規格書，以及系統設計文件，交付給甲方審查。至於第三階段，肥蝦就能本著自己的想法進行撰寫，但是光桿司令一員，也似無多大作用啦!

在軟體開發與測試流程，從需求分析、系統分析、系統設計、程式規格、程式碼，到對應的測試計畫、測試實例，有著一般普遍接受的V模型。

圖片來源：http://arithmandar.blogspot.tw/2009/08/v-model.html

另外，就物件導向開發文件，UML定義了十種圖示文件：使用案例圖(User Case Diagram)、類別圖(Class Diagram)、物件圖(Object Diagram)、順序圖(Sequence Diagram)、合作圖(Collaboration Diagram)、狀態圖(State Char Diagram)、活動圖(Activity Diagram)、套件圖(Package Diagram)、元件圖(Component Diagram)、部署圖(Deployment Diagram)。其中套件圖不是UML正式規定的圖表，而使用案例圖因為太過簡約，也多會配合使用案例文件。

以上各圖表的定義與使用，網路上與市面上均有各樣的資訊提供，肥蝦在此想要說明的是：文件、開發流程與程式間的對應，如何與實務間進行協調，達成一致性的要求，並且有助於後續系統的維護與開發。

就肥蝦所接觸的現況中，台灣除了資本雄厚、稍有制度的軟體公司(這可跟他們有沒有獲得CMMI或ISO認證無關)，一般多在確認需求分析後，程式設計師就著手Coding，開發所需的系統分析與設計等文件，因為在專案合約多未載明交付時程，都在驗收的時候在拼命補，搞得人仰馬翻，寫出來的文件也跟實際有著相當大的差距。甚者，因為每人的開發與coding習慣不一，文件寫得更是參差不齊，搞得一本多綱，連那目錄都難以統合。

就肥蝦經歷與合作過的廠商夥伴而言，基本上純外商的文件在就定義與內容上均優於本土化的外商；本土化的外商又多優於純本土廠商。若只就台灣設有分公司或公司的廠商而言，不可誨言的，I18M的確是較優的，其它有些廠商雖然也有詳細文件，但系統分析或設計文件，應該比較像是既有系統的說明書，多無法實際反應出客製化過的系統，更難以反映出系統從分析、開發到測試的過程。

在系統開發過程中，每個人對於系統文件與圖表的作法均有自己的偏好或公司的規定。肥蝦個人，習慣上喜愛使用案例圖與文件，流程圖或泳道圖(可能是因為一開始肥蝦是從程序式語言Cobol入門)，系統模組架構圖，操作畫面輸入/出示意圖，資料庫的ER圖表，模組內的程式設計文件(如果是物件化程式就改以類別圖)，並且針對每種圖形，再輔以表格說明。

由於肥蝦是非資訊本科系(後來唸了個世新資管在職碩班，還沒畢業，對不起指導教授ㄚ！)，對於【人】的角色與定位，在系統開發中非常強調，也很在意與專案成員的分工互動中，介面的界定。因此，就一個新系統的開發，個人習慣性的步驟會是：

(1)使用案例圖與表：界定使用者在系統中扮演與操作的角色與定位。

(2)流程圖或泳道圖：界定使用者的作業啟始到結束狀態，其間的系統處理過程，以及與其他使用者的互動。

(3)模組架構圖：界定系統處理過程的區塊切分，以及其間溝通的介面。

(4)用FrontPage畫個使用者介面輸入/出示意圖：確認使用者操作的輸入與輸出要求。

(5)資料庫的ER圖表：界定系統資料存放的方式與儲存的本體，以及配合系統流程的狀態轉移所要配合的儲存資訊與資料。

(6)就每個模組再進一步寫出程式設計文件：針對系統模塊負責的處理要項，明確對應資料庫的表格儲存。

(7)最後就整體系統繪製系統流程圖：界定細部的系統處理與資料轉接過程。

在遞次撰寫文件的過程中，也能不斷的發現問題，回頭審視上一層的文件，進行修正。至於程式規格，就請程式設計師在Coding的同時，根據個人的實際作法，把相關的細節增添進程式設計文件，成為程式規格書。因此肥蝦在進一步查看同仁的程式前，習慣上會要求讓我先看他(她)們寫的規格書，如果覺得可疑，再進一步去看程式碼，利用文件來QA程式碼的品質。

古諺有云：「大軍未動，糧草先行。」對應到系統的開發，至目前為止的經驗，肥蝦也深信：「程式未寫，文件先行。」經由文件逐步取得成員間的共識與反饋。使用案例圖與表，可以取得與使用者間對於系統地位與功能的共識；流程圖或泳道圖，取得開發團隊SA人員間對系統整體的共識；模組架構圖取得SA人員與各開發小組成員間的共識；使用者介面輸入/出示意圖進一步確認使用者對系統的認知；資料庫的ER圖表與程式設計文件獲得程式開發成員間coding的共識與基礎；而程式規格書就用來確認開發成員對於SA(SD)要求認知的回應與實現。

在系統開發架構中，肥蝦以為該簡單的就儘量讓它簡單，最後再就那20%較複雜的作業，思考那簡化單元的串接作法，或再進一步要求其他區塊配合。

在這一次後補程式規格文件過程中，肥蝦就深深體會到如果成員間沒有共識，沒有界定好大家可以自行發揮的範圍，先不論那程式的寫法大家差異很大，只光那DAO讀取資料庫的程式，大家就各出奇招，搞得程式規格實在非常複雜。

系統開發的文件類別，不管在教科書或實務上雖然有一定的共識，但對於每種文件的內容與細節卻是要因案、因人而異，重點在於每種文件的功用，以及誰是閱讀者。如果忽略了文件的主要閱讀對象與其資訊能力，以及他(她)們所盼望從文件中獲得的訊息重點，一份文件不管怎麼寫，一定是大家都有意見的！

以上僅是肥蝦的個人淺見，還請  各位先進多給予指導！在軟體專案的學習中，肥蝦還有很長的路要走、要學，經由您的提攜，希望能縮短一點學習的時間，並且累積更多的能量。

執行中專案的度量

肥蝦今日幫一位好友填寫開放式問卷，肥蝦這位朋友的研究主題是承攬後，或說得標後的專案進度衡量與估算。其實該友已是一位浸潤於軟體專案管理與系統分析多年的專家了，就只為了湊一下訪談人數，只好把肥蝦這濫竽拿來充數；肥蝦為了義氣，也只好厚顏的忝充一下【專家】(好像唸高中同學間為了考卷上的簽名只好彼此充當對方家長一樣)。因為問題還蠻有意思的，因此肥蝦就更無恥的把肥蝦的回應潑到部落格來一同與大家討論與分享！

為了尊重好友的智慧產權,肥蝦就搞了一個山寨版的問卷。

開放問卷的回答

==============

問題一：肥蝦對不同類型的案子是否有不同的進度衡量標準？

回答：沒有針對不同類型的專案訂出不同的標準。原則上採行統一定義的標準，但會根據不同類型給予不同的權數或比重，尤其是對於完工的定義採行不同的百分比法。

問題二：您用的有哪些方式?優缺點？

回答：如果對於程序型的軟體開發專案就以WBS下各Package的完工進度加總後作為衡量；如果是產品客製化的專案，就以完成的交易數作為衡量的基準。

以Package的完工進度加總計算優點是各負責人責任明確，回報容易；缺點就是擔心各負責人隱藏訊息。

以完成的交易數作為衡量，優點是客戶容易明瞭，而且有明確的感受；缺點就是客戶看不到的部分，如：架構、品質…等工作難以反應，易造成給客戶沒有進度的感受。

但以上兩者都有一個重大的問題，就是實際進度的衡量基準與專案預估時的方法與基準不同，對後續新專案時程與成本預估的Lesson Learned幫助有限。

問題三：能反應實況嗎?

回答：應該可以反應實際狀況的百分之七十到百分之八十或九十，實際狀況要視配合同仁彼此間的合作氛圍與默契。比如就以交易數為例，有些同仁認真負責，瞭解交易的目的與重點，進度的顯示會同時真實反應品質等問題，而有些同仁的作法就有可能增加後續的修改時間。

問題四：影響進度度量的因素有那些？

回答：就軟體開發案來說，個人以為最主要的還是人的問題。

從一開始的Initial階段，參與人員的經驗是否足夠？參與人的是否明確研議招標書，審慎評估專案的風險，研議合約？對於合作的廠商與專案人員是否有正確的評估？

planning階段參與分析的規畫人員是否深入瞭解User的需求？，瞭解產品的架構？是否真實的反應哪些RFP項目是可能有困難的？進一步負責的擬定分析書與設計書？User參與人員是否全心投入？是否對於提出的需求有明確的認識？並且可以與廠商一同以完成專案目標為前提下，探討這需求是否在合約或RFP的範圍內？

Executing階段，公司主管是否認真看待本案？對於人力與資源的分配給予穩定的承諾？還是常常臨時變更指定人員？負責實作與執行的人員是否能確實研究分析人員開列的文件與要求？真實的陳報開發進度與反應問題？

Monitor時，最擔心就是怕因應公司或內部主管的想法就要求變更專案進度與文件，甚至管控方法與記錄？或者主管對專案不明瞭，對於專案的範圍、成本、進度與品質等要件有自己的看法？專案成員是否私下進行承諾？

在Closing階段，比較麻煩的就是先前各階段的人員是否真得write down下符合要求的相關文件？業主與廠商參與驗收的人員是否與先前配合的人員是否一致？如果人不一樣，那要求與重點是否差異太多？

問題五：那些階段估算容易失真？為何？

回答：一般來說，比較容易失真或出現失真是在Executing階段。其次是Planning階段或所謂的需求分析階段。但是最可怕的是失真問題出現在Closing階段。

就軟體估算來說，最常發生的就是規畫之時受到不同因素的干擾，對於專案範圍或要項有意或無意的疏漏，導致Executing之時還得不斷回頭重新進行分析，更甚者還必須變更整體的架構。其次，就是配合的廠商與人員不如原先的期待，導致增加的時程或成本遠超出原先的估算，更可怕的就是加時程或成本也無法解決，必須重新更換合作廠商或人員。

問題六：有更好的建議？

回答：軟體開發的平台，在目前的環境下多不是問題，【人】還是整個專案問題的核心！是否有足夠適當的人員參與？業主與廠商間的人際互動是否良善，並真實的立基於合約的規範？

目前任何的度量方式如：EVM是用換算成金額的方式來度量，功能點是將專案交付物各要項轉成另一個所謂點數方式，…是依據外顯的特性進行計算與度量。但是軟體專案不似其他土木建案或舉辦party的專案，軟體的特點在於依賴深度的人力與能力，並且一般單一軟體系統專案所交付是一個整體性的產品，各軟體組件間密切相關，難以明確快速替換。

因此，加求度量的方式不是設法強化人的約束，朝向所謂的『工程』導向，如：印度。不然就是設法改善人員的態度，如Google的人性化。期盼藉由人態度的正向改變來確實反應出度量的計算方式。

TOC理論提議了所謂『時間-金錢』計算單位，也許軟體進度度量單位可以設計一個『人性-時間-金錢』的度量單位。