David Ko的學習之旅

 
Source: The Official Guide to The Kanban Method v.1, Feb 2021

(繼續閱讀...)

文章標籤

kojenchieh 發表在 痞客邦 留言(0) 人氣(608)

之前有人一直討論什麼是真 Scrum, 什麼不是 Scrum.
簡單的說, 在 Scrum Guide 上有提到的, 就是 Scrum. 

(繼續閱讀...)

文章標籤

kojenchieh 發表在 痞客邦 留言(0) 人氣(306)

在敏捷的世界中, 只要遵守 Agile Manifesto 和 Principles 的方法, 我們都會稱之為敏捷方法. 所以這也就是你為什麼在市面上會看到有 Scrum, eXtreme Programming, Kanban, FDD 等作法.
 

(繼續閱讀...)

文章標籤

kojenchieh 發表在 痞客邦 留言(0) 人氣(239)

 
DevOps Handbook 中提到要先繪製價值流, 然後轉換成看版, 藉由監看看板中項目的流程, 可以找出瓶頸或是多工的問題.

(繼續閱讀...)

文章標籤

kojenchieh 發表在 痞客邦 留言(0) 人氣(804)

很多人只要使用 Trello, 或是把便利貼貼到一塊白板, 就會號稱他們在用 看板方法 (Kanban Method)
 

(繼續閱讀...)

文章標籤

kojenchieh 發表在 痞客邦 留言(0) 人氣(422)

HR 朋友聽到 Agile 最近很流行, 因此都跑來問我敏捷是什麼, 他們想要知道他們家 R&D 的需求是什麼. 關心自家研發部門很重要, 但是只有聽聽, 要了解新東西會比較慢. 事實上, 有些 agile method 很適合 HR 來使用, 如果可以實際上來使用一些敏捷方法, 可以更快瞭解 agile 的原理, 以及可以幫什麼忙.
 

(繼續閱讀...)

文章標籤

kojenchieh 發表在 痞客邦 留言(0) 人氣(1,413)

在看 DevOps 相關研究時, 很多團隊都是使用看板方法來管理, 但是他們並不強調 Scrum, 這是為什麼呢? 就讓我們來瞧瞧:
 
(1) 綜觀全局
 
所謂 DevOps 就是要結合 開發 和 維運, 甚至有時候還要看需求端, 因此, 想要看的是從想法進來, 到最後上線和維護階段. 不會像 Scrum, 大多應用在開發團隊上面.
 
利用 Kanban 就可把這三個部分繪製在一起, 你就可以看到某個需求被處理到哪個階段, 哪裡比較忙, 哪邊已經卡住了, 就可以知道哪邊要幫忙, 哪邊要調資源.
 
 
 
 
(2) 事件導向
 
在維運端時, 事件來的頻率很不固定, 有時候很忙, 有時候就還好, 完全是看天吃飯. 這時候你說要安排 iteration 內要做什麼, 有時候是很難決定. 
 
另外, bug 來的時候, 何時能解決也無法評估, 因為有時候為了要 reprudce bug, 需要和客戶來來回回, 客戶會不會聽你安排, 這也是無法控制的.
 
在製作 kanban board 時, 你會有各個不同專案的工作進來, 但是你可以有一個欄位, 是在決定這周或是這天, 大家打算做什麼. 什麼時候決定這個內容, 可以依你團隊狀況決定. 做很快就天天, 普通快就每週, 慢一點就兩週. 不像 Scrum 就是固定每次 sprint 開始才決定這次要做什麼. Kanban 可以根據團隊狀況, 自行決定用什麼頻率來挑選要做的事.
 
 
 
 
(3) 適合互不相干的任務
 
很多時候 DevOps 團隊每個人負責不同的專案, 大家沒有什麼交集, 因此你很難一起召開 sprint planning, 因為沒有什麼事要一起討論的, 都是各自自己規劃的狀況比較多.
 
如果是這樣的狀況, Scrum 很多活動就會變得很怪異. sprint planning, sprint review 進行起來就會沒有參與感. 當然你還是可以請大家一起來, 只是大家容易覺得事不關己. 在 Kanban 中, 不用所謂的 sprint planning, 可以主管和相關的人討論決定即可. Sprint review 也可以只找相關的人來看, 或者請資深的人幫忙檢視. 完整的 Scrum 儀式, 反而可是個累贅.
 
 
 
(4) 可看多個團隊狀況
 
很多時候搞 Devops 會是多個團隊一起合作. 
    a. 可能是一個專案很大, 需要多組人馬. 
    b. 或者是團隊散落在不同區域, 可是卻要一起攜手合作. 
    c. 或是處理流程很常和複雜, 中間要經手多個部門或團隊
 
如果這時候用 Scrum board 來做的話, 一方面他著重只看一個團隊, 或是把所有東西和在一個 Scrum board 看. 這樣這個 board 就太複雜了, 你很難從上面找到你想要的, 也容易看漏.
 
這時候 Kanban 就可以利用兩階層的 kanban board: 
    a. 上層是 high level 的, 描述要經過那些大步驟, 或是哪些團隊處理.
    b. 下層可以團隊各自展開的 task board or kanban board. 
這樣你可以有全貌, 又可以有細節.
 
source: Lean from the trenches
 
 
 
(5) 有助處理多工
 
Devops 團隊就是雜事很多, 常常大家都說他的事情最重要. 以前的話就是會一直塞進來, 誰大聲就做誰的.
 
這時候可以利用 (2) 中的做法, 當某個急件進來, 可以請主管一下來協商, 看看目前手頭上的, Next 欄位中, 以及 急件的部分, 這麼多事情, 哪個要先, 那個要放下來. 所有資訊攤在眼前, 一起來做個當時最佳決定. 
 
 
你會說有的主管就是要全做, 這樣還是沒用. 沒錯, 如果是這種不理性的主管, 不過你用什麼招都沒用, 這不是 Kanban method 的錯.
 
因此, 若要導入 Devops, 看板方法 (Kanban Method) 是個不可或缺的工具. 有了它狀況才能透明, 才能方便你看出問題, 進而及早處理. 所以你怎能不學習看板呢?
 
 
 
 
 
 
 

(繼續閱讀...)

文章標籤

kojenchieh 發表在 痞客邦 留言(0) 人氣(781)

第三步: 持續學習與實驗原則
 

(繼續閱讀...)

文章標籤

kojenchieh 發表在 痞客邦 留言(0) 人氣(512)

第二步: 反饋原則
 

(繼續閱讀...)

文章標籤

kojenchieh 發表在 痞客邦 留言(0) 人氣(848)

鳳凰計畫中提到三步工作法, 他是一個落實 DevOps 的基礎原則, 透過這些能使工作有效率, 並且達到全局優化. 但是在鳳凰計畫中似乎沒有太多描述, 因此特別翻了一下 DevOps Handbook, 期待能了解更多內容, 以下是一些重點記錄和心得.
 

(繼續閱讀...)

文章標籤

kojenchieh 發表在 痞客邦 留言(0) 人氣(2,146)