the DevOps journey (2) - 如果時程難預估，不如追求透明度…

前面說了，在近代專案管理當中，大家已經慢慢能夠理解，死板的去stick to the plan，追求計畫導向的專案管理，在外在環境瞬息萬變的今天，這恐怕是不可行的。

但是，如果我們不去追求計畫實施(implementation)的準確度，不去要求執行計畫的每一個步驟一如開始的計畫一般，那我們該用什麼標準去定義何謂一個『好的軟體專案』呢? 對企業來說，如果PM不是依照著既定計畫、時程把成果交出來，那到底什麼可以被叫做『執行了一個好專案』?

在DevOps課堂中，對於這個問題，我的回答是: 我們與其去要求專案100%按照計畫進行，不如追求軟體專案的高「透明度」、以及開發流程與維運的「自動化」。

有注意到這一篇的標題嗎? 請把它記起來…

如果時程難預估，不如追求透明度

什麼是透明度?

底下有幾個問題…不管你是PM、Team Leader、還是專案團隊的成員，你都應該要自問自答一下…

• 你知道每位開發人員今天正在開發哪些功能項目嗎?
• 你能知道最近一次Check-in上去的Code，是改了哪些程式碼嗎? 這個修改是因為哪一項需求或Bugs呢? 
• 專案的程式碼Check-in是否有觸發Build? Build是否成功?  
• CI Build的過程中執行的Unit Test是否都有通過? (還是你根本沒建立Unit Test? Check-in還不會觸發Unit Test?)
• 這個迭代每一個開發人員手上的工項(WorkItem)是否都與MVP(或潛在可交付產品增量)有關? 整體需求目前完成的比例是多少? 已經有多少完成的 item通過測試? 客戶實際驗收過的Item又有多少呢?
• 到今天為止，你還有多少已知的Bug尚未解決?
• 這個Sprint要達成的目標為何? 要交付出哪些成果(潛在可交付產品增量)? 當前進行的Sprint是否有任何風險? (導致無法交付出成果?)
• 已經上線的系統每天有多少人登入? 每天發生幾個Exception?

只要你確實參與在團隊當中，你自己一定很清楚，上面這些問題你能夠回答出來的比例有多少…

別急，我們再來看看幾張圖表:

上面這張圖表呈現出了專案中所有的需求數總共有多少、有多少比例的工作項目正在開發中、有多少需求已經開發完成等待測試、還有客戶已經驗收過(認定完成)的Item有多少。

上面這幾張圖，則呈現出了每一個迭代(Sprint)，開發團隊的工項完成度(此為燃盡圖，具體來說是Sprint中每一天的剩餘工作時數)。左上與右上兩張圖呈現出了團隊的預定進度狀況良好，而中間上下兩張圖以及左下的圖則是清楚呈現出專案團隊的問題(你看的出來是什麼問題嗎?) 以及進度狀況(一看就知道這個Sprint將會延遲，無法達成預定進度)。

上面這張圖，則呈現出每一個迭代(Sprint)當中正在進行的工項(展開後會有具體的工作item、原始需求、驗收條件…etc.)、以及每一個工項的狀態、負責人…等資訊。而這些工項，也可以透過看板(kanban)的方式來呈現，請看下圖:

底下這張圖則是程式碼版本控管機制當中，某次異動的紀錄，包含異動者、異動原因、關聯的工項、以及異動前後的內容…

底下則是典型的數位儀表板:

OK，看完了?
那底下這是一個可以問問PM的好問題:

你所參與的開發團隊，有沒有這樣的專案管理圖表? 在軟體專案管理上是否也能夠呈現出類似的透明度?

你得要知道，這些可是我們現在專案管理的標配喔...

專案中所有的利益關係人、技術與非技術負責人、團隊成員…etc.，對專案現況的掌握度，以及圖表呈現的清晰程度，就是我們後面接著要談的『透明度』。

所以，什麼叫做『執行了一個成功的專案』?

好，看完上面那些圖表之後，讓我們回到最初，請重新幫我思考這個問題，現在，在你的認知當中，你認為什麼叫做『執行了一個成功的專案』?

過去，當碰到這個問題，一般人腦袋裡立即閃過的字眼會是『on schedule』…是的，用我們先前很愛拿出來講的那個字眼，就叫做stick to the plan。過去，計畫導向的專案管理認為，on schedule的專案就是好專案，一位PM若能夠依照既定計畫，精確的執行一個專案，那他就算是一個好PM(哪怕這個專案的原始計畫再怎麼爛也無所謂，因為PM照著執行完了啊)。

但我們前面已經花了兩個篇幅告訴各位，僅僅只是stick to the plan，在這個時代是不可行的。既然我們確定它不可行，那就衍生出一個問題，若我們不照著計劃走，軟體專案管理豈不就失去了方向? 不追求照著計劃，那我們該追求什麼呢? 答案就是這兩個關鍵字，分別是 『透明度』和『自動化』。

『透明度』和『自動化』

如今，我對開發團隊在專案管理當中所要求的，也就是『透明度』和『自動化』。而這兩個關鍵字，將會帶出我們這一系列文章的主題 -- ALM與DevOps。

為什麼我們應該在意透明度? 請回憶上一篇的一些關鍵字，像是: 『迭代開發』、『潛在可交付產品增量』、『持續修正』、『持續改善』…，你會發現一件事情，當我們採用迭代開發並且企圖持續改善時，有一個非常非常重要的關鍵，那就是『專案現況到底是如何?』。

如果你壓根不知道專案的實際現況，那你要怎麼持續改善呢？要修正什麼？有什麼好調整的？只要你想要讓團隊可以持續改善，那你的現況必須是可量測的、可估量(可評估)的，說白話一點，就是你的專案現況要夠清楚，你專案中的問題要能夠真的被凸顯出來(而不是被掩蓋起來，所有人都不知道，又或者是，所有成員都知道，但只有PM和老闆不知道)

你想要能夠持續修正、持續改善，那你的首要任務就是讓整體專案的透明度提升，否則你無法知道該怎麼改善? 無法知道該讓專案團隊往哪個方向走。

因此，對我來說，透明度提升是敏捷開發要追求的第一個首要目標，它將會貫穿我們專案管理的每一個層面。

拿我們一開始隨手舉的幾個問題當例子，你知道你的專案當中，目前有多少個bug尚未解決? 每天完成哪幾個功能點? 整體需求的完成度比例是多少? 每天程式碼改了哪些? 每一次修改是為了哪些功能或bugs? 開發人員正在開發哪個功能? 每一次Build是否都正確無誤的? 今天(或這周)開發人員Check in / Push 了哪些Code? 開發人員測試過了哪些功能? 客戶驗收過哪些功能? 已經上線的系統每天發生幾個Exception?

不管你是專案的PM、Team Leader、還是Team Member，上面這些問題我們能掌握多少? 你知道坐在你隔壁的開發人員現在手上正在開發哪一個功能嗎?

這幾年下來，我可以武斷地說: 專案的透明度，幾乎表現出(等同於)專案管理的成熟度。

那該怎麼做?

好，當你同意專案的透明度是一個重點之後，接著我們就得要來看如何提升它? 答案依舊是透過迭代開發與敏捷流程，例如我們團隊採用的開發法是Scrum。而工具(我們用的是VSTS/TFS)當然也是一個很大的關鍵，不過別忘了敏捷開發的核心精神才是一切的重點…

到目前為止，這一篇，我們提出了現代軟體專案管理所追求的兩個重要指標 --『透明度』與『自動化』，而這恰恰就是ALM與DevOps可幫助我們實現的目標。我們後面會接著利用幾個篇幅，慢慢來介紹如何透過導入敏捷的開發流程、建立團隊的開發準則與習慣、以及妥善的使用VSTS/TFS等工具的協助，來實現專案透明度。

但別急，我們下一篇還要談談剛才提過的另一個重點，就是『自動化』。

------------------------------
本系列文章索引位於 http://studyhost.blogspot.tw/2017/02/the-devops-journey-index.html
相關教育訓練: http://www.studyhost.tw/NewCourses/ALM 
若這篇文章對您有所幫助，請點選這裡加入FaceBook專頁按讚並追蹤，也歡迎您幫我們分享出去，謝謝您的支持。