
在企業內推廣一個東西, 即使立意良好, 未來前景看好, 還是要先有些成績出來, 否則不但高層坐立難安, 反對者也會趁機反撲. 因此, 如何快速打響第一炮, 是轉型初期的要務.
kojenchieh 發表在 痞客邦 留言(0) 人氣(171)

前一陣子在 Facebook 上的 Test Corner 和 Scrum Community in Taiwan po 文, 想知道大家的想法為何.
kojenchieh 發表在 痞客邦 留言(1) 人氣(3,590)

Liberating Structure (解放結構) 中提到的[結構] 是指在會議討論中的結構. 例如討論的方法, 坐位的安排, 會議室的佈置等等. 傳統的方式通常是PPT, 個人簡報, 長桌等等. 單向交流無法充分釋放與會者的能力和智慧, 因此, Liberating Structures 就是想透過簡單而又可行的方式, 逐步改變傳統, 為組織團隊拆牆鬆綁, 建立創新的文化.
kojenchieh 發表在 痞客邦 留言(0) 人氣(1,176)

貝爾賓團隊角色理論 (Belbin Team Roles) 是英國 Dr. Raymond Meredith Belbin 教授所提出, 對於團隊組成和管理要怎麼做提出一些作法. 貝爾賓研究後發現, 成功團隊中成員, 通常會包含以下九種角色. 如果這九種角色齊全, 團隊就能運作良好.
kojenchieh 發表在 痞客邦 留言(2) 人氣(7,845)

測試金字塔這個概念是由 Mike Cohn 所提出, 在敏捷測試圈很流行, 不過大家不太清楚他是什麼, 並且對它有很多誤解. 因此, 簡單整理了一下他的想法, 希望能對大家有幫助.
kojenchieh 發表在 痞客邦 留言(0) 人氣(3,262)
在看 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) 人氣(229)

你常會發現大家總是喜歡把別人貼標籤, 你是綠的, 他是藍的. 你很保守, 他們激進. 每個標籤自成一個小團體, 每個團體有自己的文化和運作方式, 不同標籤的人, 進不來也不想進去.
kojenchieh 發表在 痞客邦 留言(0) 人氣(203)

今年很多挑戰, 自己也很茫然, 但是就像鯰魚效應一樣, 沒有一些危機或是刺激, 我自己覺得是不會成長的. Seafood 和 John 真的幫我不少, 常常用話激我, 很真心的感謝他們. 接下來, 就簡單記錄一下今年發生的一些大事吧.
kojenchieh 發表在 痞客邦 留言(0) 人氣(453)

昨天和 Daniel Teng, John Yu 吃飯, 聽到了 Skin in the game 一書中狼和狗故事. 故事如下
kojenchieh 發表在 痞客邦 留言(0) 人氣(657)