積極管理 有效開發

最近剛完成一個軟體專案,有些感想提出來分享。專案成功的因素,簡單來說八個字"積極管理,有效開發"。


專案經理對於專案的監控,應該要"積極管理",意思是說,除了定期召開專案會議(project review meeting)追蹤專案成員的工作進度;定期review milestone的產出是否符合預期;隨時留意專案監控值,包括專案scope、cost、schedule是否異常、另外,常被忽略的是,隨時注意專案成員的工作狀況,專案經理隨時要扮演溝通的角色,減少專案成員間溝通不良及衝突。佌外,專案經理的態度,對內應該嚴格而積極,對外應該態度微婉立場堅定。


至於專案的執行,應該與專案成員達成"有效開發"的共識,所謂有效,並非只要求要有效率,如果工作很快完成,但bug一堆,反而花費更多的人力在改bug。應該要在品質達成的前提下有效率的工作。前面提過,應該減少非專案的工作,把重心花在專案的工作(project work)上,以達到有效開發的目的。


雖然,專案經理負有專案成敗的責任,但一個專案的成敗只靠專案經理,絕對無法順利結案。專案成功的方程式:專案經理的積極管理 + 專案成員的有效開發 = 專案如期結案


分類: ,

del.icio.us提供Blog整合功能

Link rolls : 條列式列出文章

Tag rolls :以Tag歸類文章


Play Tagger : 在Blog上聽MP3? 還沒試出來


分類: ,

web2.0應用

這篇Blog整理了一些熱門的web2.0應用以及簡介,非常詳細

The Best Web 2.0 Software of 2005

More Great Web 2.0 Software

分類:

Less drive-bys, more project works

常常,我們發現專案成員常在做一些無關於專案本身的工作,例如修改之前系統發生的bugs;客戶抱怨系統效能不好,而花時間做performance tuning;花時間處理客戶新的需求....

如果在專案執行期間做好測試,上線後的bug就會控制在一定數量;系統設計及開發階段,就考慮到系統效能的問題,進而事先預防,也不至於在上線後花費人力做performance tuning;系統分析時,就已預先針對使用者的需求做整體的考量,並做好需求管理,就能解決大部分客戶需求變更的問題。

隨著專案時程的增加,這些非專案工作(drive-bys, non-project work)所耗費的時間與成本會呈等比級數的成長,因此Less drive-bys, more project works

分類: ,

Project Sponsor和Stackholder定義的釐清

這篇文章釐清了Project Sponsor和Stackholder的定義

給項目「發起人」和「關係人」正名


作者: 黃紹良  來源: www.csai.cn  


任何項目經理在學習項目管理知識的過程中,都明白「Project Sponsor」(翻譯為「項目發起人」)及「Stakeholder」(翻譯為「項目干係人」)的重要性。但從我過去二十多年的項目管理經驗中,對這兩者的認識和在項目過程中需要建立的焦點,讓我感覺到一個項目管理應用的重大誤區。


我曾經在五月發表了一篇文章,內容主要說明我國軟件工程人員對需求的誤解,導致軟件行業未能有效把握客戶的「需求」,使我國的軟件缺乏創新。不期然,聯想到目前IT項目管理的應用,也因為一些錯誤的觀點,讓項目管理在IT企業中走上另一段冤枉路。


過去數年,項目管理在科技企業中漸漸被重視,企業希望利用項目管理的理念來強化項目的交付質量,最起碼也希望能夠讓項目可以如期完成交付,降低企業的交付成本,提升利潤。所以,很多從業人員誤以為只要考取了一個專業資格,便可以成為一個項目經理,有效執行項目管理的工作。


知識與體系的分別


要知道美國PMI項目管理的考試內容環繞著項目管理知識(PMBoK)的範圍,PMBoK不是一套體系(Methodology),它提供的是項目管理知識,但我們把Body of Knowledge 翻譯成為「知識體系」,讓我們誤會只要完成有關知識的學習,便可以有系統地直接實施。但往往在實際應用這些知識的時候,才發現無從入手。


「知識」讓我們知道「該做什麼」(What),而「體系」告訴我們「如何去做」(How)。缺乏一個體系,所有的知識只是理論,這也是為什麼國內的新進項目經理感嘆「不知如何把學習到的理論在實踐中應用」的主要原因。


為什麼一些基建項目,如蓋房子、修路、建水壩等項目,能夠有效利用項目管理的知識?那是因為這些項目的管理機制和實施流程比較成熟。項目在設計階段已經把建設的方法(Construction Processes)有效地融合到項目交付的流程和機制(體系)中。


科技項目所需的時間往往比較短,範圍變動也比較大,加上沒有一個實施的流程和管理機制,所以科技項目往往未能有效地把項目管理知識應用到實際的過程中。


國內企業缺乏自建管理體系


一些比較成熟的管理體系,包括歐洲國家單位及企業所選擇的Prince2 (Project in Control Environment 第二版),美國MacDonnell Douglas 公司的STRADIS (Structured Analysis and Design of Information Systems), Ernst & Young 諮詢集團的Navigator,或者是Agile的Method123等,都是一些常用的體系。


有了一套管理體系,才能夠發揮知識的應用。歐美國家的企業大部分有本身的體系,按企業本身的項目特色及業務方向建立的管理流程和機制,讓企業的項目能夠按照這個體系實施。


要能有效地應用項目管理的知識,企業必須建立本身的管理體系。這是我們國內企業所最缺乏的。


其他項目管理誤區


任何項目經理在學習項目管理知識的過程中,都明白「Project Sponsor」(翻譯為「項目發起人」)及「Stakeholder」(翻譯為「項目干係人」)的重要性。但從我過去二十多年的項目管理經驗中,對這兩者的認識和在項目過程中需要建立的焦點,讓我感覺到一個項目管理應用的重大誤區。


贊助人與發起人


所謂「Sponsor」,直接翻譯應該是「贊助人」,但如何會變成「發起人」(Initiator)呢?假設A君有一個商業計劃,可以讓A君賺大錢,但因為缺乏資金,所以到處找尋投資者,最後B君對這計劃感覺興趣,願意投資A君的商業計劃,讓A君這個「發起人」可以進行有關的計劃,把計劃成為事實。


這裡談到的是兩個人,一個A君是項目「發起人」,而B君是項目「贊助人」,A君的計劃能夠成為項目,完全是B君的投資才能夠立項。但如何在項目管理的翻譯中把B君翻譯成為A君呢?唯一的解釋便是這個負責翻譯的「外人」在翻譯的時候,由於對項目管理缺乏認識,錯把「馮京」作「馬涼」了。


項目贊助人


回想我1997年被調派負責當時「郵電部」的「綠卡工程」(即現郵政儲蓄系統)建設的時候,當時有三家供應商負責提供全國各省的系統安裝,這個項目的資金安排是「郵電部」負責支付各項目的大部分資金,各「省」及「市」單位負責支付當地系統的小部分資金。


當時很多地區的項目在建設完成後,都需要進行變動及返工,經過很長的試運行期才能夠完成驗收過程。我們一家是當時最快得到驗收文檔的供應商,因為我們在各地執行項目的時候,嚴格執行「部」的要求,對「地方」單位所提出的功能變動採取嚴格的範圍變動管理方法,任何變動必須得到「部」的同意下才進行變動,所以我們的交付比較順利。


當然,在過程中,我們不像其他供應商一樣按照「地方」的需求增加或修改系統架構,常會與「地方」的官員發生爭議,但多能夠透過協調解決。我們能夠比其他供應商更順利完成驗收過程,是因為我們能夠明確理解到「部」是負責大部分資金的單位,他們的意見才是最重要的,「部」是整個項目的主要「贊助人」,而其他供應商均未能有效把握「Sponsor」的定義,讓項目延誤了多月才能夠完成。


當項目發起人建議項目的概念時,往往在經過「可行性研究」後對項目的範圍及功能會有很多不一樣的地方,不管實際應用需求或資金問題。發起人的概念可能在項目立項時只保留了一部份的概念,只有負責項目費用的人才知道他投資這個項目的最終目標。如果按照項目發起人的要求執行項目,不一定能夠得到投資者的認同,讓項目走上冤枉路。


由此可以看到,當一個項目在實施過程中,往往項目發起人並不是項目贊助人,當然也有可能兩者是同一個人,但明確體會「贊助人」及「發起人」的差異,讓我們能夠把握項目的焦點,降低項目延誤的風險,減少交付時進行修改及返工的機會,降低項目的成本。項目經理對「Sponsor」(贊助人)及「Initiator」(發起人)的理解對項目能否如期完成起了重大的影響。


項目干係人


「Stake」的直接翻譯是「籌碼」或「賭注」,所以「Stakeholder」可以直接翻譯成為「拿著籌碼的人」。但中文翻譯為「項目干係人」,這更讓人感覺莫名其妙。


什麼才算是「拿著籌碼的人」呢?那就是在賭局完的時候(既系統開始運行的時候),最終是「輸」還是「贏」,是看這個人在過程中投注的決定。在系統建設的過程中,是那個「初步」決定哪些功能需要增加,哪些功能可以減少,明確理解系統在運行時,能否提升部門的能力和效率,這個人便是系統應用部門的主管。這個主管及他的屬下是系統使用者(Users),是項目干係人,但只有這個部門的主管才是Stakeholder。


我說那個「『初步'決定哪些功能需要增加,哪些功能可以減少」的人,是因為最終決定不是這個Stakeholder,是項目的Sponsor。Stakeholder有可能是項目發起人,但也可能不是。他需要說服贊助人對項目進行投資,讓系統提供他所需要的功能來完成他部門的工作。所以在項目過程中,我們需要Stakeholder對項目的認同。一些中小型項目可能有數十個使用者,但可能只有一個 Stakeholder,一些大型的項目可能有數萬名使用者,但可能只有二三十個Stakeholders。我們的焦點錯了,項目便會失敗。


當我們在2003年負責實施澳門政府一個信息平台的建設項目時,我們面對的是數萬政府公務員,這數萬名公務員都會因為這個信息平台的建設使他們的應用受到影響。如果我們需要這數萬名「項目干係人」認同我們的設計,那麼這個項目便沒有辦法如期完成。所以這個項目的Stakeholders只是部門的主管級人員(視乎系統本身的應用範圍,一些大型系統供應數個部門使用的Stakeholders是部長,一些小型系統只提供一個「署」或「處」應用的 Stakeholders是署長或處長),整個項目的Stakeholders只有二十來人。我們只需要說服這些主管,讓他們認同整個信息平台的設計便可以實施,而不是要說服數萬個項目干係人的公務員,去認同我們的設計方案。


項目管理本身的意義是MBA課程的Management By Objectives (MBO)與Management by Exception (MBE)的混合體。MBO在項目管理中是範圍管理、成本管理、質量管理、溝通管理、採購管理和時間管理。MBE在項目管理中是進度管理、範圍變動管理,爭議管理和風險管理。


如何適當應用這些知識,那便需要企業本身提供一套體系,或者需要項目經理本身為企業建立一套體系,同時改正翻譯的錯誤。只有這樣才能夠推動我國的項目管理應用。


分類:

測試是交付成功的優質的產品的保證

測試是交付成功的優質的產品的保證 (from www.csai.cn)


我們每個人,不會都是軟體測試人員,但都是某些軟體的用戶。缺省或默認情況下,用戶都會覺得買到的軟體是沒有問題的,一般不會去想這樣的軟體可能會有問題,用戶只要使用這些軟體來解決他們需要解決的問題就可以了。當他們發現問題的時候,甚至會感到震驚。


存在的問題很多都和測試的成效有關係,一般的軟體產品存在的問題確實比較少,但我覺得即使是以前買的正版的金山快譯2000都有著一些顯而易見的bug。如果測試不充分,那麼這些問題會潛伏在軟體中,等到用戶發現以後,再有開發人員進行維護,改正錯誤的費用一般是開發階段的40倍到60倍。


人們對測試存在著一些誤區,例如:



1 測試是想像到可能出現的問題,然後試圖驗證這些問題。
實際上能想像到的只是一部分的情況,隨意性太大,還要取決於開發人員的經驗,對業務的熟悉程度和他想像到的程度。

2 讓時間充裕的員工去做一些測試
表面上看這體現了管理的效率和靈活性,但實際上也體現了管理者對測試的輕視。測試和測試的人有很大關係。測試工作人員應該是勤奮並富有耐心,善於學 習、思考和發現問題,細心有條理,總結問題,如果具備這樣的優點,做其他工作同樣也會很出色,因此這裏還有一個要求,就是要喜歡測試這項工作。

如果他是專職的,那麼肯定更有經驗和信心。國內的小夥子好像都喜歡做程式師,兩者工作性質不同,待遇不同,地位不同,對自我實現的價值的認識也不同,這是行業的一個需要改善的問題。如果只是為了完成任務而完成任務,或者發現了幾個問題就覺得滿意了,這在任何其他工作中都是不行的。



3 測試是相對簡單的工作。
實際上並非如此,要真正做好一件事都不容易。測試也有很多相關技術和工具。而對測試的輕視問題,也許要通過痛苦的經歷和結果才可能確切體會到。很多專家都在對測試的理論進行深入的探討和研究。

測試的基本知識


讓我們一起快速過一遍:


什麼是軟體測試:在軟體投入運行前,對軟體需求分析、設計規格說明和編碼的最終復審,是軟體品質保證的關鍵步驟。


測試的目標:以較少的案例、時間和人力找出軟體中潛在的各種錯誤和缺陷,以確保系統的品質。



從測試的類型來看,測試分為2種:黑盒測試和白盒測試。
黑盒測試又稱為功能測試或資料驅動測試,把系統看成一個黑盒子,不考慮程式的內在邏輯,只根據需求規格說明書的要求來檢查程式的功能是否符合它的功能說明。

白盒測試又稱為結構測試和邏輯驅動測試,允許測試人員對程式內部邏輯結構及有關資訊來設計和選擇測試用例,對程式的邏輯路徑進行測試。


測試案例由測試輸入資料以及與之對應的輸出結果組成。測試案例設計的好壞直接決定了測試的效果和結果。


從測試實際的前後過程來看,軟體測試上是由一系列的不同測試所組成,這些軟體測試的步驟分為:單元測試、組裝測試(集成測試)、確認測試和系統測試。軟體發展的過程是自頂向下的,測試則正好相反,以上這些過程就是自底向上,逐步集成的。


單元測試(模組測試):針對每個模組進行的測試,可從程式的內部結構出發設計測試用例,多個模組可以平行地對立地測試。通常在編碼階段進行,必要的時候要製作驅動模組和樁模組。


集成測試:在單元測試的基礎上,將所有模組按照設計要求組裝成為系統,必須精心計畫,應提交集成測試計畫、集成測試規格說明和集成測試分析報告。


確認測試:驗證軟體的功能和性能及其它特性是否與用戶的要求一致。


系統測試:將軟體放在整個電腦環境下,包括軟硬體平臺、某些支援軟體、資料和人員等,在實際運行環境下進行一系列的測試。


測試工作的文檔主要有:測試計畫、測試模型和案例設計或規格說明、測試分析報告等。從軟體工程上說,這是屬於軟體配置的一部分。(我不知道,如果什麼報告都沒有,只是不斷地擺弄執行程式,看到錯誤和問題就記下來,算不算真正的測試?)


測試需要一定的技術和工具


在案例設計過程中,可以考慮到很多方面,並且也有很多的指導方法和技術。


黑盒測試案例設計包括:



等價類劃分:劃分等價類--確立測試案例--設計案例
邊界值分析:通過分析,考慮如何確立邊界情況
錯誤推測法:靠經驗和直覺來推測程式中可能存在的各種錯誤,從而有針對性地編寫案例。可以列舉出可能的錯誤和可能發生錯誤的地方,然後選擇案例。
因果圖:通過畫因果圖,在圖上標明約束和限制,轉換成判定表,然後設計測試案例。這適合於檢查程式輸入條件的各種組合情況。

功能圖FD:通過形式化地表示程式的功能說明,並機械地生成功能圖的測試案例。


白盒測試案例設計包括:


1 邏輯覆蓋,以程式內在邏輯結構為基礎的測試,包括以下5種類型:


1.1 語句覆蓋:每一條可執行語句至少覆蓋一次;


1.2 判定覆蓋(分支覆蓋):設計若干個測試案例,運行所測程式,使程式中每個判斷的取真分支和取假分支至少執行一次;


1.3 條件覆蓋:設計足夠多的測試案例,運行所測程式,使程式中每個判斷的每個條件的每個可能取值至少執行一次;


1.4 判定-條件覆蓋:設計足夠多的測試案例,運行所測程式,使程式中每個判斷的每個條件的所有可能取值至少執行一次,並且每個可能的判斷結果也至少執行一次;


1.5 條件組合測試:設計足夠多的測試案例,運行所測程式,使程式中每個判斷的所有可能的條件取值至少執行一次;


1.6 路徑測試:設計足夠多的測試案例,運行所測程式,要覆蓋程式中所有可能的路徑。


2 基本路徑測試


在程式控制流圖的基礎上,通過分析控制構造的環路複雜性,導出基本可執行路徑集合,從而設計測試用例。包括以下5個方面:


2.1 程式的控制流圖:描述程式控制流的一種圖示方法。


2.2 程式環境複雜性:McCabe複雜性度量。從程式的環路複雜性可導出程式基本路徑集合中的獨立路徑條數,這是確定程式中每個可執行語句至少執行依次所必須的測試用例數目的上界。


2.3 導出測試案例


2.4 準備測試案例,確保基本路徑集中的每一條路徑的執行


2.5 圖形矩陣:是在基本路徑測試中起輔助作用的軟體工具,利用它可以實現自動地確定一個基本路徑集。


程式的靜態分析方法:


1 生成各種引用表、靜態錯誤分析


2 人工測試:桌前檢查、代碼評審等


3 軟體測試工具:包括靜態分析工具、動態測試工具、測試資料自動化生成工具、模組測試台、測試合成環境


3.1 靜態分析工具:語言程式的預處理器、資料庫工具、錯誤分析器和報告生成器。直接掃描所測試的正文,對程式的資料流程和控制流進行分析,然後送出測試報告。


3.2 動態測試工具:通過選擇適當的測試案例,實際運行所測程式,比較實際運行結果和預期結果,發現錯誤。


3.3 測試資料自動化生成工具:包括路徑測試資料生成程式、隨機測試資料生成程式以及根據資料規格說明生成測試資料


3.4 模組測試台是一種專門的測試用例描述語言,負責將輸入資料傳送到所測試模組中,然後將實際輸出結果與在描述測試用例的語言中所表述的期望結果進行比較,發現錯誤。另外,也包括其他的功能:語句跟蹤、動態斷句、覆蓋度量、用戶自定義符號表、內容表和輸出格式。


3.5 測試合成環境:包括環境類比程式,代碼檢查程式,測試文檔生成程式,測試執行嚴整程式,輸出比較程式,程式正確性證明程式等,以及各種調試工具。而且還有集成系統,集成了多種工具,如SADATMicrosoft Test for WindowsPureArtria等。


測試的管理


作為專案或產品開發的一個必要的組成部分,需要良好的組織和管理。使用軟體品質規範,編寫和實現測試用例和模型,可以有效地組織測試。


一般的測試工作過程也可以是:計畫-->配置(必要的軟硬體資源下)-->開發(構造或配置測試工具、創建測試套件和測試方案庫、準備適當的報告工具並記錄測試系統如何運轉)-->測試執行(進行測試、記錄測試條件和問題,報告結果)。


測試管理也可以從測試經理和測試小組2個方面去看:


測試經理要管理好團隊,很多人認為測試是枯燥乏味的事情,而且似乎低級的事情,所以測試經理應該不斷地激勵小組成員,為他們爭取利益。在時間進度上保證穩步前進。就象賽跑,一開始就加班加點,只會導致極限的過早到來。


作為測試經理,應該有足夠的品質意識。評價品質風險的方法是失敗模式和效果分析”(Failure Mode and Effect Analysis, FMEA)。這種方法可以允許您在特定的品質風險和結果上映射需求、規範,以及專案小組假設。然後,按照風險級別進行分類,並按序排列。


實際上如果能得到充分的資源已是很困難的了,能用好臨時的測試人員也已經不錯了。一般企業的主管和技術經理都並不怎麼真正重視測試工作的意義和價值。也許他們認為臨時的投入一次性的強力測試足以發現絕大部分問題,而實際上這對產品的長遠發展,以及品質改進都沒有太大好處。


測試過程中軟體功能可能進行調整和變化,測試發現問題也會導致變化,需要重新的測試。對這些變更也需要進行管理。


另外,由於上層管理部門的不重視,必須想辦法與之進行清楚而有效的溝通;同開發部門的溝通也非常重要,因為開發和測試在性質上是有些對立的,很容易在相互之間產生一些不必要的矛盾。和開發部門不同的是,一般品質或測試部門和市場或銷售部門的立場倒是比較一致的,如果雙方都認為高品質的產品是市場戰略中重 要的品牌戰略,徹底的測試對於達到這樣的目標來說意義重大。因此,有必要和市場部門保持協作和交流。


測試經理可以經常問自己一些問題:


計畫做哪些測試?實際完成了哪些測試?使用了多少案例?其中多少沒有通過?管理部門是否有足夠的支持?他們是否向你要過測試報告?開發部門的聯絡是否及時?等等。如果你是測試管理人員,應該可以想到更多的問題。


測試小組:


測試小組有多大的規模,一般取決於專案規模、測試人員與開發人員的比例、專案經理對品質保證的認識和期望等,也取決於你的準確的測試計畫。


對一些項目來說,最好是在開始階段就有測試人員有所介入。



如本文一開始所提到的,在測試小組中測試人員必須具備的素質包括:有效的坦率真誠的交流的能力、清晰簡明的表達能力、一定的好奇心(但不至於太強,以至於花太多精力去探究一個微小的問題),不應害怕提出尖銳問題引起麻煩,一定的責任心,
注意力能夠高度集中,是職業悲觀主義者(但不是抱怨和憎惡)。

以下是一些測試的方法和基本工具:


測試方案、測試模型和測試用例


測試就像是做實驗一樣,實驗對於象我這樣的理工科畢業生來說真是太熟悉不過了。做實驗之前必然有實驗的方案、內容和步驟,測試似乎也是同樣的。另外,基於測試用例的測試和常見的隨機性的測來測去也是完全不同的,儘管習慣於隨機性測試的人,如果注意力集中的話,他的頭腦裏也是有一些測試案例的。


關於測試實驗室,進行測試工作首先要爭取到盡可能好的環境。如果可能,應該建立測試實驗室,實驗室包括必要的裝備、工具軟體(包括測試工具)和各種作業系統平臺,保持實驗室的實用、整潔,避免他人干擾甚至破壞測試環境。


關於測試跟蹤軟體,製作一個簡單的測試問題跟蹤軟體,記錄測試的結果,將測試發現的問題分類,並對測試發現的問題和模組、開發人員進行關聯,有助於分析問題,並可有效記錄測試的結果,形成測試報告,並從中找出一些規律性的東西來。因此測試問題跟蹤軟體還是有一定的價值的。


關於測試自動化,有一定的風險。對一個穩定的系統,甚至可以自己開發自動化軟體,而對於正處於快速變形中的軟體發展過程,介面、主要功能和支援環境在發展變化中。為測試配置環境也要付出很多的時間。


以下是關於測試的一些技巧和經驗:



在制定測試計畫的時候,就要考慮到測試的風險,並抉擇要執行哪些測試,並放棄哪些測試;測試計畫的評審應該讓開發人員參與;
測試模型的製作應該盡可能貼近用戶,或者站在用戶的使用立場上來觀測軟體,此時應該能發現更多的問題。

由於測試發現問題,在解決問題後還要重新測試,因此測試的時間可能會比實際更長一些


識別和注意少數重要的方面,而忽略多數次要的方面,有時候少數的問題足以致命,這些問題將是軟體測試結果中重要性最高的錯誤。


錯誤的定位有時是很難的,要找出必然發生的前因後果,而不至於因為描述錯誤而誤導開發人員。有時候確實存在錯誤不能重建的問題。解決辦法之一是在錯誤報告中給予說明。


對錯誤的描述,應該是準確、完整而簡練。因為描述的問題或者不完整的描述會引起開發人員的誤解,其後果是可以想見的。


有時有經驗的測試人員憑藉直覺就可以發現一些問題,這可稱為錯誤猜測


測試人員容易犯2種錯誤:一是測試人員發生判斷錯誤,將本沒有錯誤的系統行為報告為錯誤,或者將錯誤指定了過高的嚴重級別,或者過高估計了問題的嚴重性,這樣會引起開發人員的不信任,產生一種象狼來了一樣的效果;二是測試人員將錯誤的嚴重性或優先順序定得過低,從而產生測試逃逸,這樣會造成產品 品質的風險。以上兩種錯誤應該儘量避免。


最後,我忽然想,測試實際上可以覆蓋到硬體,甚至非電腦產品的測試,也許可以相互借鑒。


還有一種很奇特的感想,這種感想使我反而有些困惑不清了。我發現對測試來說,理論和實踐的距離好象非常遙遠,我先看了一本軟體工程的書,然後寫下了前面的一半內容,然後我又匆匆翻看了一本美國人的書,叫做《測試流程管理》,然後整理出了本文後一半的內容,該書中有著比本文多得多的各方面的實踐經驗。歌德說過,理論是蒼白的,生命之樹常青。我稍稍改變一下,就變成了:理論是蒼白的,實踐之樹常青。也許測試是一種實踐性很強的工作,大學教授們一般也不可能熱 衷於參加測試工作吧。



分類:

Google Earth推出Feed服務

Google Earth以RSS Reader的想法, 開放用戶可自由訂閱與分享各種衛星空照的景點

分類:

PMCDF 專案管理績效評估指標

PMCDF(Project Management Competency Development Framework), 是PMI發布的專案管理績效評估指標, 主要以專案經理知識能力(PM Knowledge Competence)、專案經理執行能力(PM Performance Competence)、專案經理個人能力(PM Personal Competence), 客觀的評量專案經理的能力

熟讀PMBOK或拿到PMP證照, 並不代表專案經理的核心職能就已建立, PMCDF的架構協助高階主管評估專案經理的專案管理知識與實務運用的能力,

詳細資訊, 可參考PMCDF在項目經理績效評估指標體系設計中的應用

分類:

Business 2.0: Tech's new resolutions

本期的Business 2.0報導幾家科技公司2006年的發展重點

Google's resolution: Reinvent the mobile phone

Apple's resolution: Keep pushing the envelope

Yahoo's resolution: Create a media hub

Microsoft's resolution: Go Live for real

Amazon.com's resolution: Let customers design their own products

Disney's resolution: Make Internet video a profit center

分類:

Business 2.0: My Golden Rule


business2_20051201.jpg


本期的Business 2.0 My Golden Role介紹49位成功人士,分享他們的成功秘訣

分類:

Copyright © Andy Cheng

Distributed By My Blogger Themes | Blogger Theme By NewBloggerThemes Up ↑