評估能力

作者：
這是我還在讀研究所時所發生的事。有一個在職的同學突然間常常出現在實驗室，一副很輕鬆的樣子。他的公司在美國算是很大的公司（應該說是非常大的公司），軟體部門也非常大，而且他一向忙得不可開交，很難想像他怎麼有可能這麼輕鬆。原來他們所做的project 竟然提早一個月結束，team leader告訴他們不要讓經理知道他們已經做完，暫時享受一下悠閒的時間，所以他就有時間來學校晃一晃。

這種事當然不可能常發生，可是到底發生什麼？是招標端（客戶端）的評估能力差？cost estimation 的問題？project planning的問題？太高估了？假如兩方老闆發現了，會怎麼樣想？假如你是team leader你會作什麼？more testing? more refactoring?
在台灣的學歷：幼稚園中班肄業 （所受的教育都在國外）

留言

  1. 黃為德2008年9月10日 下午5:20

    可能做project之前沒有做estimation，不過這麼大的公司不知project estimation或prediction的重要，實在不解。

    回覆刪除
  2. 薛念林2008年9月10日 晚上11:23

    因為沒有提到原來的案子有多大。假如原來的案子是五年的案子，那麼誤差 1/60 還屬合理，我個人覺得很難估到非常精準。

    如何避免工程師謊報？如果專案經理有如期在追蹤這個專案的話，謊報的情形應該可以避免。也許這就是CMMI中提及的 PMC（project monitoring and control）的重要性吧。

    回覆刪除
  3. 劉立頌2008年9月10日 晚上11:28

    的確是不解。我相信他們有作estimation，因為他們的公司一項有在做，可是不曉的在哪一環太高估了些時間或人力。更是不解的是，其他競標的對手，難道沒有更好的prediction？再者，委託端難道沒有底標？

    更有趣的，team leader如何影藏他們超前的事實，到現在還是蠻好奇的。

    不知道大家有沒有一些相似的經驗？

    回覆刪除
  4. 劉沅2008年9月11日 清晨7:44

    一般來說，專案經理發現工作超前時會放慢腳步（少給些壓力）或是增加工作（如測試或寫文件），所以提前完成在我三十年的開發與管理經驗中幾乎沒有發生過。這裡有個類似墨菲定律的定律：Work expands to fill the alloted time ─ 工作量會自己膨脹以符合時間表。就像飛機或火車跑得比預期快時，駕駛員會自動放慢速度。
    總之，經理居然會叫組員出去晃，並且不要讓上面知道，的確是不可思議。因為，上面知道的機率是很大的。也有可能經理對組員這麼說，是要向他們邀功，博取「愛戴」，而實際上經理早已取得上面的許可。當然，也不排除那位同學隨口講講，不一定反映事實。

    回覆刪除
  5. 匿名2008年11月15日 晚上11:37

    專案時程估不準是常見的事，所以提前完成的機率應該也不小吧！只不過大部分的人（尤其是programmer)通常喜歡拖時間，時間快到了才發現系統有bug, 所以專案就延遲了。提前完成真的不容易，真的有完整測過了嗎？

    允許出去晃就更糟糕了，這代表沒有其他的專案在跑？那公司怎麼賺錢呢？

    回覆刪除

張貼留言

這個網誌中的熱門文章

CMMI是什麼?

作者：
CMMI(Capability Maturity Model Integration) 將軟體開發流程視為一種工程 ( 製造 ) 流程，利用控制、量測、改善 (control, measure, and improve) 等循序漸進的方法，達到軟體流程改善的一個框架。 CMMI 是在美國國防部 DoD 以及國防工業協會 (NDIA) 的支持下， CMU 的軟體工程學院 (Software Engineering Institute, SEI) 發展出來的模型。 CMMI 中許多的概念與原理來自於創立 SEI 軟體流程計畫 (software process program) ，並曾任職於 IBM 、領導大型系統軟體開發的 Watts Humphrey 。根據 IBM 與 SEI 的經驗， Humphrey 將廣泛運用在製造流程中的統計流程控管 (Statistical process control, SPC) 的概念，加以修正、擴充後運用於軟體流程管理中。 在一方面，定義軟體開發流程中的各種活動與其彼此間的關係，是將軟體開發流程視為一種製造流程，並實施量化控制的前提之一。在另一方面，由於這些活動相當繁多、複雜且彼此牽動，故唯有在軟體開發活動結構定義清楚之後，方能找出可量測事物，並根據其關連性推論量測值的意義。 CMMI 將軟體開發相關活動的實務作法分為 25 個流程領域 (process area, PA) ，定義其需管理的項目，含一般目標、特定目標、具體作法等，並找出其彼此間的關連性。 依性質來分，這些 PA 分屬於流程管理、專案管理、工程、與支援等四大類 流程管理 ： CMMI 的目的是流程改善，因此流程的定義、維護、修正等均為重要活動。 專案管理 ：因為軟體開發、維護均以專案為單位，以便在專案進行前進行人力、資源、時間、經費計算以及專案進行中管控，如需求變更、進度監控等。 工程 ：軟體開發實質上涵蓋許多軟體工程的原理與具體作法，如需求發展、分析、應用設計、系統設計、實作、測試、部署、維護等相關活動，這些活動需要加以管理。 支援 ：支持前三類活動進行之環境與工具之支援活動等，例如提供產出物與組態管控、議題追蹤等活動。 CMMI 有連續式 (continuous) 與階段 (staged) 式兩種表示法。採用連續表示法
閱讀完整內容

CRC cards - 非正規物件導向發展技術

作者：
圖片
最近看到Kent Beck與Martin Fowler講的一句『諺語』，說："Stick with simple tool, like pencil, paper, and whiteboard. Communication is more important than whizbang." 我才想到PO這篇短文，提供學生們(至少選我開授的OOSE的學生)參考。這句諺語我認為最重要的是『溝通』，溝通在軟體發展的過程中十分重要，尤其想使用『敏捷方法』發展軟體的工程師們更為重要(可參考Agile Alliance在2001年發表的『宣言』(manifesto)，此地不宜對宣言多做闡述)，問題是你要使用何種工具或方法來溝通？我想除use cases外，CRC cards可能是最佳工具之一，它是隨時隨地可得的低技術工具，易學易用。 軟體開發與維護時，工作夥伴的合作十分重要，換言之，團隊合作是發展工作成敗的關鍵，夥伴合作必須有好的工具或技術協助，CRC cards可能是適當的工具之一，據我所知，在台灣發展軟體的工程師很少使用像CRC cards這種簡單但被認為是一種『驚奇』(wonderful)的發明 (David Bellin, et al. 1997)，而這種技術雖然簡單，但卻可避免發展早期陷入太細節或者產生雜亂且定義不清楚的類別，因此希望這篇報導能引起從事軟體發展的人士注意到這種『老而彌堅』的技術，而且也希望各界人士能予指正。 CR C cards (Class-Responsibility-Collaborator cards) 是1989由Kent Beck與Ward Cunningham所共同介紹 (http:\\c2.com/doc/oopsla89/paper.html)， 其出現時期與WWW相同，至今約有20幾年的歷史，這個工具開始是用來教導新學員如何學習物件導向的觀念與程式製作，後來的演變卻超乎在教室內的需要，而成為軟體分析、設計以及敏捷思考的工具。CRC cards的軟體發展方法屬於一種非正規方法 (informal approach)，雖然屬非正規方法，但CRC cards可做為正規方法的輸入或前端作業，如Booch方法、James Rumbaugh, et al. 的OMT、Ivar Jacoson, et al.的OOS
閱讀完整內容

課程改進

作者：
今年在輔大招開的TSCE11，其中在Panel Discusion中(主題：軟體核心能力)，我提議軟工教育訓練由OO modeling概念開始，而程式則依據models來撰寫，這種提議可能須修改教學程序，不過我認為，「軟體核心能力」的目的乃是要建立優良的軟體系統，而models比複雜的程式容易描述系統，也比較容易保養系統，因為其抽象層次較高，也符合程式語言以及軟體發展方法的演變之故。我提出這種意見，希望對軟體工程教育有興趣的人士能夠討論，提供意見。
閱讀完整內容