從PM的角度淺談test case的應用

在PMBOK（註1）的定義裡，完整的品質管理計畫包含「品質保證」（Quality Assurance, QA，中文簡稱「品保」）與「品質管制」（Quality Control, QC，中文簡稱「品管」）兩個面向，其中，品保的目的是確保產品交付的品質，例如軟體開發專案中，交付的軟體是否能符合規格文件內所定義的功能。在編制完整的組織內，也可能會有QA這樣的角色（Quality Assurance engineer，即品質保證工程師），協助PM檢驗產品品質。

專案成果的爛品質到底是怎麼形成的？正本清源的解決之道又是什麼？

我們知道，任何專案，最終都有一定的成果得產出，而這些成果必須符合一定的品質標準。有些成果的品質要求較寬鬆，有些則必須極為嚴苛，沒有一點商量的餘地，像與人身安全相關的品質要求就是一例。照道理，軟體有品質瑕疵是不該被放行出貨的，不論是看得見的使用者介面（User Interface），還是看不見的內部程式碼的瑕疵都一樣。然而，實際的商業運作情況，卻不是這樣。為什麼會這樣呢？

從「阿姆斯壯登月」學專案管理：關於外包和採購管理，PM該知道的3件事情

西元1969年，阿姆斯壯成為首位登陸月球的人類，直到現在已超過50年，然而，1961年甘迺迪總統宣布登月計畫時，美國甚至尚未發射載人太空船進入地球軌道，論經驗、理論都還無法支撐遠大的目標，因此，即便是至關美國與蘇聯之間的太空競賽角力，NASA也不得不將部分技術發包委外，尋求更有效的解決方案。在專案管理學當中，外包屬於採購管理的一環，具有契約、法律效力的存在，PM在面對合約議題時，務必要小心謹慎。本文章想探討的，是這個真實案例裡，有沒有日常專案工作中所能借鏡的地方?

敏捷品質管理：笨蛋！問題不在是否能做到「零瑕疵」，而是在「看待瑕疵的態度」

日前於敏捷課堂上，有學員問到，應不應把瑕疵（以下簡稱 bug ）列為用戶故事來處理？ 這個問題，其實可以分為好幾個層次來探討，我們就先從根源來談起吧！ 瑕疵該發生嗎？是理所當然的嗎？瑕疵可以放任多久再處理？瑕疵該以用戶故事紀錄、跟催嗎？