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專頁按讚並追蹤,也歡迎您幫我們分享出去,謝謝您的支持。

留言

陳哲峰寫道…
台灣有PM 在追求透明度嗎?PM 怎會不知道誰是Team裡面的Key Man?濫竽充數的比例有多少?問題是PM 敢公開嗎?濫竽有backgroud 怎麼砍?不充數客戶會願意付那麼多錢嗎?
isDavid寫道…
@陳哲峰,

敏捷開發從一開始就挑戰甲乙雙方的人性陰暗面,開始習慣它吧... ^_^

另外,太透明確實會讓很多人感到恐懼,也因此,一開始不一定需要把所有資訊都公開在客戶或老闆面前,但不論如何,PM自己得要能掌握整個專案的狀況。

但長期下來,客戶和利益關係人早晚也會要求專案要有足夠的透明度。

這個網誌中的熱門文章

使用 Airtable 在小型需求上取代傳統資料庫

精彩(且驚人)的Semantic Kernel入門範例

使用Semantic Kernel 建立自然語言請假系統

在 LINE Bot 開發中使用Semantic Kernel建立自然語言請假系統

專業的價值...