一名解決方案架構師的自我敏捷

要來進行今天的分享之前,我得要先來推一下 David Ko 前輩 David Ko Learning Journey,當初研究所開始接觸 Scurm / Agile 等等的都是主要都是從這位前輩上學習到相關經驗的,直到現在工作一陣子了,觀念還是非常有用,大推

今天要來講一下關於身為一位在 Red Hat 打工了快兩年的解決方案架構師 (Solution Architect) 如何透過敏捷方式提高個人生產力,這篇完完全全就是個人實際經驗分享 XD

何謂解決方案架構師?

解決方案架構師 (Solution Architect) 在 Red Hat 定義中是售前職位 (Pre-sales),主要每日任務簡要版本就是

  1. 白天跟著業務跑來跑去開會
  2. 晚上寫簡報 / Lab / 回信 / 讀書 / 研究

這個職位有個特性就是,無論來自業務還是客戶,需求都是來得又快又急,很容易一天內被一票不同的事情衝在一起,所以對自己的每月每週每日待辦工作項目掌握要非常清楚,不然很容易會 overloading。而剛好每一季的自我目標管理 (Management By Objectives, MBO),也需要回顧三個月內做的一些專案和工作負載狀況,故為了提高生產力和準時交付產物,所以…我自己開始了個人敏捷探索

常見的個人敏捷方式

Trello 有特別針對個人提出了幾種提高生產力的方式 - 以 Trello 提升個人生產力,包含如下 4 種方式:

  1. 個人生產力系統:元老級 Trello 使用者的個人生產力指南
  2. 艾森豪矩陣 (Eisenhower Matrix):相當著名的工作優先排序法實踐
  3. 每週檢討流程:以週為單位 《搞定!》一書建議養成每週自我檢討的習慣實踐
  4. 心智圖:我個人覺得走錯棚

或者是真的走看板方法 (Kanban Method) 的,但是給個人用的

  1. 運用個人看板做時間管理 - Ruddy
  2. 原來我以為的看板根本不是看板… - Oberon Lai

可能有些人對於看板方法 (Kanban Method) 的定義有所不清楚,這邊強烈建議看一下 視覺化白板, Proto-Kanban, Kanban 傻傻分不清楚? - David Ko,如同內文所述,只要沒有照著David J Anderson 所提出的以下看板方法實踐走,其實都不算真看板方法

  • 視覺化 (Visualize)
  • 限制同時工作數量 (Limit Work In Progress, WIP)
  • 管理工作流程 (Manage flow)
  • 為流程訂定明確的方針 (Make policies explicit)
  • 實現反饋迴圈 (Implement feedback loops)
  • 利用模型和科學方法來協同式改進, 實驗性演進(Improve collaboratively, evolve experimentally)

我使用的方式 - 小飛機版視覺化白板

對的,基於對於看板方式的規範,我沒有完全採納該實踐,但從中還是有擷取出 3 個核心概念,從中改成屬於小飛機版視覺化看板的樣子

  • 視覺化 (Visualize)
  • 管理工作流程 (Manage flow)
  • 為流程訂定明確的方針 (Make policies explicit)

工具選擇是採用 Trello,主要是簡單、快速和跨平台,當然選擇了好工具不代表專案就能跑得好,只是方便我自己使用而已,Trello 和看板方法的關係是? - David Ko 一文結語不錯,但我是自己使用,不是跟團隊使用就是了 XD

工具不會讓你團隊改善, 唯有團隊具備改善能力, 工具才能改善團隊

可能有人會想推我用矽谷真香的 Notion,我中間有兩個月換成使用 Notion,但使用體驗相當差,網頁開啟反應太慢、有點複雜,最重要是不能離線,我就果斷換回 Trello,另因自己的筆記已經有台灣團隊出品的 HackMD 及 HappenApps 出品的 Quiver 在使用,我就沒有持續使用 Notion 的理由了

設計上,因為這職業對於時間相當要求,所以視覺化白板設計是以時間作為分隔進行流水線設計,範例網址在此 Trello Template - 小飛機版視覺化看板

清單從左至右:

  1. Backlog per month:本月收到的任何代辦事項或要求都寫在裡面
  2. Todo per Week:這週要處理的待辦事項
  3. Do it per Day:今天要處理的待辦事項
  4. Ready to go:已處理完的事項,但還沒執行
  5. Tracking:已處理完的事項,但還會有延伸需處理之項目
  6. Done - Week 1:第一週已處理完的事項
  7. Done - Week 2:第二週已處理完的事項
  8. Done - Week 3:第三週已處理完的事項
  9. Done - Week 4:第四週已處理完的事項
  10. Discard:放棄處理的待辦事項

關於卡片排序方式,採用艾森豪矩陣 (Eisenhower Matrix) 方式,時間先決,故優先處理順序由上至下:

  1. 緊急且重要 (Urgent, Important):一定會列在上去白板上,當前優先處理順序最高
  2. 緊急但不重要(Urgent, Not Important):一定會列上去白板上
  3. 不急但重要 (Not Urgent, Important):一定會列上去白板上,當前優先處理順序最低
  4. 不急但不重要 (Not Urgent, Not important):不列,靠緣分

至於卡片內容的撰寫方式則為

  • 抬頭 (Title):一定是 執行對象要幹麻 不會有其他多餘的描述
  • 截止日期 (Due Date):要從 Backlog 裡面拉出來,一定要上截止時間
  • 描述 (Description):產出物,可以是簡報網址、網址、文字結論
  • 待辦清單 (CheckList):看複雜度,有時候會用
  • 評論 (Comment):交談後隨手筆記或者是雜資料都可以往裡面塞

而標籤 (Label) 我就比較少用了,沒特別想到怎麼用,而免費版的 Trello 可以選一個 Power Ups 使用,這邊是用 Custom Fields,可以自己加欄位

長期使用下來的缺點?

我這個設計使用大概三年多了,當中的缺點其實也蠻明顯的,前 3 有感如下:

  • 對於自身的工作量無法以數字量化,所以工作生活平衡 (Work–life balance) 奇差無比 XD
  • 僅能單人使用,只有我自己看得懂在幹嘛
  • 不適合用在跑一個中長期專案,或需要定期迭代交付東西的事情,我的理解是改走 Scrum 實踐比較適合,畢竟需要跟其他人協作

雖然我知道有這些缺點,但這個自我設計可以搞定我將近八九成以上的工作型態,我就懶得做成 100% 的樣子

但如果團隊要一起放在同一個板上管理的話,還是先從 Agile 最佳實踐中,先行選出可行的做法後,隨著執行時間越久,慢慢地淬煉出自家團隊的走法是比較有規章的作法

Red Hat 開源敏捷軟體專案經驗分享?

以下都有公開的資訊可以被 Google 到,只是要知道關鍵字而已 XD

工具選擇上,目前常見走 Kanban 或類似看板 (極難在廣大社群專案上 WIP = =) 的作法,我看到的都是放在 Trello 比較多,而跑 Scrum 的方式則是跑在 Jira 軟體為主的作法居多,少數跑 Kanban 也會放在 Jira 上執行就是了

敏捷方法選擇上,Red Hat 軟體專案管理無論是上中下游大多數都是 Scrum 居多,我的觀察是蠻標準的 Scrum 跑法,至於與 Kanban 差異可以看看 Kanban board 和 Scrum Board 不同之處 - David Ko

結語

眾里尋他千百度,驀然回首,那妹卻在燈火闌珊處

對,沒錯,我就是沒有遵照最佳實踐,但弄出一套自己運行的很開心的模式,工具在手,揮灑在我。我個人並不是待在軟體開發團隊,而是業務團隊,所以使用敏捷方式會有別於現在大多主流軟體開發的討論情境,各位在思考的時候要留意一下

References

Comments