RojerChen CYH.2012.02.01

距離先前參加微軟的研討會『軟體品質日』會有好一段時間了，不過一直都沒有時間整理一下當天的筆記，趁著過年這段時間整理一下資料，並且回顧一下過去專案上的經驗，和大家分享一下心得：

※兩千萬守則

進度？你是怎麼來去評估你專案的進度為何？在我過去當專案經理的時候，我會覺得掌握專案的進度是一件很困難的事情，因為我不知道該 如何 或是 有效 的去評估專案的進度狀況。每次老闆或是客戶問我說現在的進度為何？目前專案進度 60% 或是 80% 根本沒說個準。

到了後來，我們會把專案上的功能區分，並且加上權重百分比，完成 A 表示完成 5%，所以會很清楚的知道現在的進度是怎麼樣，這樣看似好多了些，不過還不夠，因為我們把最後整合測設留在最後階段。雖然每個項目都應該要各自完成測試後進度才算完成，但是階段性的整合測試只有最後一次，所以往往會發生各別功能無誤，但是整合起來往往錯誤百出。

所以當你有天當上專案經理，兩千萬守則是非常重要的：

這兩點來說，我覺得最難的是第二點。一方面我所接的專案期限是固定的，夥伴的成員有限，但我卻常發生我的專案成員被挖走，導致整個專案進度落後之外，使得原本預估的整合測試時程，變成拿來補先前尚未完成的功能目標。在 品質、時程、功能 這三個面像中，我們往往能夠在 時程 內完成 功能 就很不錯了，品質 這塊往往是被犧牲的。

※持續整合 Continuous Integration

所以 持續整合 Continuous Integration 這件事情就變得非常重要。在一個專案運作的過程中，我們原本規畫上測試可能只有在專案後期才測試，若是可以把原本 『一個』測試時程 增加為 『四個』測試時程，是不是就會讓整個系統的穩定度和可靠度提升？

並且在每個測試階段完成後，就發布新版本給客戶 使用或測試。主要的目的在於盡早讓客戶熟悉系統的操作並且給予建議，讓彼此溝通的『認知差距』能夠縮小，另外一方面，整合過的程式基本上也測試過了，所以整個專案的『進度』也更加明確。

所以整個專案的『進度』不是功能完成多少就表示目前的進度是多少，而是透過目前 發布的版本 來決定目前的專案進度狀況。


在工時的評估上，我覺得讓夥伴評估專案工時是一個不錯的方法，只要讓專案經理與成員一同練習評估工時，讓大家練習把工時抓得更加精準。像我以前是每週開一次週會，所以當一件功能或工作會超過一個星期以上的時間，就要把該工作拆解，這樣在評估上，才能夠把誤差降低。

只是在現實上，如果超乎專案進度的時間，如果超乎原本專案的期限，可能還是要想辦法在期限內完工吧！

※行動化的開發

自從 iPhone 開始熱門起來後，讓風行已久的 WEB 延燒到 APP，可謂是數十年風水輪流轉。近幾年，大家都拼命的開發 APP，只不過你的系統需要 APP 嗎？

在 APP 化之前，先思考一下下面幾個問題：

1. 給誰用？
2. 安全性？
3. 是 Native APP、WebAPP 還是 混合式 APP？