黑先生

【敏捷 123起步走~】 最近在公司試驗了小班敏捷體驗專案，先來介紹背景，再來分享過程。 背景：5人，專案大小2個月內，有4人未接觸過敏捷，意願高，技術中上，授權度高 算是極品團隊，那要如何讓在最短的時間內讓大家了解敏捷框架並實際開發呢? 當然就是發揮"做中學、學中做"的精神。雖然專案小、團隊小，但也不能馬虎應付敏捷步驟，否則反而適得其反。 分享過程，還是要提醒一下，每個團隊人員和公司文化不同，不一定能全套用，別人的解藥可能是你的毒藥，參考就好囉! 【啟動 - 為何敏捷】 ●啟動會議 - 1.5小時 ●團隊建立活動，信任的開始，讓大家先透過活動來認識彼此 ●透過會議來向團隊稍微介紹一下敏捷核心精神，接下來會做哪些事情，讓成員有心理準備 ●主軸內容： 面對VUCA時代、 由代工思維轉變成產品思維 【第一次Planning meeting - 成就感】 ●讓團隊容易上手為主要訴求 ●簡化過程，先請PO寫好這次Sprint要的User Story，討論過後，直接讓成員寫下Task ●這次的User Story要特別與PO設計一下，是容易拆出且不需要太多討論的項目 ●訂些Task寫法規則，便利貼右上名字、右下粗估工時、完成時打勾、意外時標記 ●因為專案規模不大，使用User Story Mapping取代To do、Doing、Done看板，讓系統全貌能慢慢浮現(這步要好好想一下) ● 不用一步到位，過程中漸近調整就好，讓團隊成就感大於挫折感，也是個近程勝利 【Daily - 一天一觀念】 ●透過每天的Daily後，補上相關的觀念 ●以下的圖都會列印出來，然後貼在看板旁 ●適團隊狀況或事件給予相關資訊，下圖是第一個Sprint會提到的 ● 與其一開始把這些都說完，還不如慢慢釋出消化，讓資訊更貼近實際狀況                                             【第一次Review - 產品思維】 ●第一次如果可以的話，安排以內部Review為主，而這樣就需要在第一次的Planning meeting項目調整一下 ●先讓成員理解這個會議是什麼，並 鼓勵Demo者使用非技術(產品)語言來說明 ●以產品思維做任何的

【職場修煉 - 做得多不如做得巧】 前一陣子在活動中，遇到一位28歲想從倉管業轉職到遊戲業的男生，估且先稱他為A。A很有心，為了做好轉職準備，放下工作去職訓局上課五個月，最近結訓的他開始要找工作，身為職涯規劃師(GCDF)的我，有緣正巧碰上了，給了些建議希望能讓他順利轉職成功。 A背景摘要 A做倉管有四五年時間，直到今年發現自己對遊戲業很有興趣，於是參加職訓局授課，期待上完後能順利轉職。職訓局在結訓後，大部份有一個流程，就是邀請企業參加並當下做個簡短面試，如果合意的話，會再進一步邀請進公司面談。顯然的，A應該是沒被選上或者是不喜歡來面試的那些公司，所以才需要自己再找工作。 職訓局的結訓課程都是以小組為單位，共同作出一個作品，也有可能是獨自一人做，但大部份就是小組。既然是小組，就會有分工，每個人負責的工作內容不一樣，比重也不一樣。問了一下A，A是負責程式部份，自己覺得佔了50%比重。其實這樣對一個公司的程式設計師來說，有點偏低。 一、 A結業後二個月，還沒主動面試找工作，有聽聞其他同學一些面試經驗，會問一些程式語言基本觀念，似乎讓他有些怯步。所以打算再花二個月時間自學後，再主動去找投履歷面試。當下問了想自學什麼，卻又有些不知如何下手的感覺。 這好像是這世代的常會發生的現象，對於未來的未知感到不安，卻說不出個所以然，但堅信要動手自學些什麼，好似就可以解決此焦慮然後達成。 二、 之前遇到好幾位都有同樣的想法，當然，首先要肯定他們的是，對於自身問題的覺察是有的，大概就贏50%以上的人，是一種自我預警。大多數人是沉浸在安逸的環境下，不覺有什麼困擾，或者是問題明顯發生了才求救，也都比較難處理。 發生這種狀況後，如果能更進一步自我釐清要做些什麼、怎麼做，讓行動發揮更大效率，不僅可以縮短歷程，大腦思考更是高層次的提升，好好利用此機會讓自己在轉職的過程也轉個腦袋。 通常這時候的腦袋有些打結、想不通或出現盲點，不知如何處理，所以會強烈出現"須要"動手來降低不安，而不是"想要"。這時靜下心來，好好有系統性的全面思考，或者找朋友或專家諮詢，從客觀角度提醒下，會有很大收獲。而這次收獲的經驗，將讓你下次又遇到時，比較有機會能做出順暢的反應。 三、 由於時間關係，直

【Q&A - 敏捷中他說做完了，可是怎還少30%沒做?】 這也是從別人那裡聽來的困惱，"PO覺得應該是這樣，但實際結果確和自己想的少30%?" 首先，先來理解一下，自己的30%和別人的100%是如何各自解讀的。任務板上通常稱為靜態資訊，是屬於不會變動的。而在每個人的大腦叫作動態資訊，這種會隨著自我預設、假設而產生不同。但理論上，這些會在Planning meeting、Daily中縮短、對齊你我的資訊才對，如果還發生這種情況該怎辦? 通常會這樣說的人，大概都是PO，開發人員一定都是身在其中，認為自己是已經全部完成的。所以，極有可能是某些環節歪掉導致這樣結果，從頭檢視有沒有可以改善調整的地方， Planning meeting： ●需求描述太大，以至於寫任務時會遺漏，不妨縮小描述，讓開發Team自然而然展開正確需求任務，也能從全部展開的Task中，再次確認跟PO想像的有沒有落差 ●SBE ( Specification By Examples 實例化需求 )，透過關鍵實例的描述再次讓資訊落差縮小 ( Specification by Example 中文版：團隊如何交付正確的軟體 ) ●DoD (Definition of Done 完成的定義) ●AC(Acceptance criteria 驗收標準) Daily： ●每日的自我檢視，搭配以上的定義，如果有問題的話，會在執行過程中發現，再去找PO確認；當然，如果沒有上面那些定義的話，就只能做到最後才發現 ●如果真的是重要項目，PO必要的話也可以在該項目執行中，也加入關心。 Review： ●PO通常在這時候才發現資訊落差的現象，先以產品和利害關係人回饋為優先，觀察、記錄會議過程，也許能從中發現為什麼有落差的原因。 Retrospective： ●好好了解一下，為何發生這種落差。除了避免下次再發生，也稍微討論一下可以如何補救落後進度。 除了這些工具以外，日常生活中也可以訓練這樣的邏輯思維，這樣在才不會又發生你聽你的我說我的冏境。 PREP溝通法則 ，這也是簡報常使用的方式 POINT=結論 REASON=依據 EXAMPLE=具體事例 POINT=強化與重申結論 結論： 如果透過以上的方式還是一直發生，應該就不是工

【Q&A - 敏捷中不開回顧會議會怎樣?】 每個人心中都有自己敏捷流程的樣貌與解讀，甚至會自己發展出自己的一套理論或做法。這是好事，就「守、破、離」來說，說不定已經到達「離」的境界，隨心所欲而不越矩。 當然，在此之前，請先確認前二個階段都經歷過，才能確保你不是貌合神"離"的離，否則SM可真是"誤"人子弟囉! 前幾天的交流中，有個問題是，團隊只有開Plan、Daily、Review但不開Retrospective? 就此現象我們來探討一下會有怎樣的影響。這觀點沒有對錯，也許團隊真的是這種個性、高水準表現，一樣能交出好產品、好品質，那就沒問題。 我們先拉回一般團隊討論，如果沒有開回顧會議會怎樣呢? 情境想像一下流程，做完Review後，在新的Sprint開始前，把實體任務板上的所有Task全撕下來，Reset然後展開新的衝刺，全新空白的任務板展開。 再來看看一個實驗，從樂高實驗發現意義的重要性( 動機背後的隱藏邏輯 )，實驗內容是這樣： 實驗中，要求參與者組裝樂高生化戰士，把參與者分成兩種不同條件的組別。 我們提供第一組參與者每人 2 美元報酬，組裝出第一個戰士。我們告訴參與者，實驗結束後，我們會把他們拼好的戰士拆掉，把積木放回盒子裡，再讓下一組參與者用同樣的一批積木組裝戰士。 當這些參與者組裝出他們的第一個戰士後，我們把成品放在桌下，稍後再拆掉。然後，我們問：「這一次報酬少了 0.11 美元，給你們 1.89 美元，你們想不想再組裝一個？」如果對方同意，我們便再給他一組積木，等他組裝完畢，我們再問一次。以此類推。到了某個時候，參與者會說：「不做了，划不來。」這一組每人平均組裝了十一個戰士，獲得 14 多美元。 第二組的參與者也獲得到一樣的金額，金錢報酬條件與第一組相同。不過，這一次，他們完成一個戰士、著手組裝下一個的時候，我們就在他們面前把前一個作品拆掉，等到他們完成手上的戰士，我們便把拆好的積木放回盒子裡。 第一組參與者是在我們所謂的「有意義」條件下組裝積木，因為他們可以感覺到自己滿意地完成了工作。我們稱第二組的條件為「 西西弗斯 」條件，命名自希臘神話裡的西西弗斯。他被眾神懲罰推石頭上山，等他好不容易推上了山頂，石頭又滾下山，一再重複、永不止歇。這些在西西弗斯條件下組裝積木

【Q&A - 敏捷中有人不敏捷該怎辦?】 前幾天有個交流討論的問題是這樣的：在執行Scrum時，遇到有人不配合協作，Daily不參加的情況，該如何處理? 先來看看 Scrum指南 的對於Scrum Team的描述，倒也不是非得要遵照著執行，先看看最好的標準，心中才有依據該如何下修決策。 "Scrum Teams 是一個自我組織和跨職能的團隊。 自我組織的團隊會自行選擇最好的方式來完成工 作，而不是被團隊外的人指示如何做。 跨職能的團隊不需依靠非團隊成員而擁有所有完成 工作所必備的能力。 Scrum 中的團隊模式是設計用來將彈性，創意，和生產力最大化。  Scrum Team 必須證明自己在前述的情況和錯綜複雜的工作中越來越有效。" 指南期望能在"對的團隊"之中，生產力最大化，由團隊反應並自我決定該如何做，不過這還有團隊成熟度的問題。假如裡面的人員都足以做出最好的決定，團隊自然而然就會發生選擇行動，大多情況下，還是要SM或主管輔導或介入。 回到問題本身來分析，通常在建立Scrum Team時，會先找心態開放與意願較高的人選為優先成為示範團隊，這樣不僅可增加推行成功率，也能讓這群人未來成為種子教練或傳道士。 當然，現象往往沒有這麼美好，公司有可能以現有組織狀態直接導入敏捷，就會發生"強迫在一起的敏捷"，只有肉體沒有心靈，然後就產生為敏捷而敏捷的聲音。真不幸發生的話，該如何做補救呢? 第五項修練：顯而易見的解往往無效。 過路人遇到一位醉漢在路燈下，跪在地上用手摸索。他發現醉漢正在找自己房屋的鑰匙，便想幫助他。問道：「你在什麼地方丟掉的呢?」醉漢回答是在他房子的大門前掉的。過路人問：「那你為什麼在路燈下找?」醉漢說：「因為我家門前沒有燈。」 在日常生活中，應用熟悉的方法來解決問題，好像最容易，因此我們往往固執的使用自己最了解的方式。 當我們努力推動熟悉的解決方案，而根本的問題仍然沒有改善，甚至更加惡化時，就極有可能是"非系統思考"的結果。所以，最好以系統全貌先檢視一下目前狀態，再去做行動方案。千萬不要只看眼下事件急救章處理，埋下更大的地雷。譬如說，A不參加Daily，就訂團隊規範條款來因應、放任不管、同儕壓力迫使他加入，

【職場修煉 - 第一次團隊合併就上手】 假如你的部門要被合併時，該做哪些事呢? 這種經驗很難得，剛好，幾年前有這經驗來與大家分享，希望大家都沒機會遇到。如果不幸遇到的話，每個團隊與公司狀況不一樣，所以面對的方式也會不同，就參考囉! 身為主管，當然是希望整個過程不僅僅只是順利，更希望雙方能滿意。提供之前的步驟參考 ●預先計劃 既然想要透過合併過程得到些成長經驗，好好的分析、計劃是少不了的，預想一下哪些事要讓它發生、哪些人要預先告知討論、雙方可以有哪些討論空間...等等。讓整個計劃經過設計，才會發揮到最大效益。 例如，先跟另一位合併的主管商量，接下來可能會發生哪些事情，讓雙方都有準備的情況下，事情才會順利交接。而一開始就先跟對方主管說好，會有一個會議，由組長親自表達合併後規劃。一來，讓成員有些掌控權降低不安，二來，透過這會議讓對方主管更認識他們。 ●先調整心態、心情，才能看清方向 成員面臨這事件通常都是慌亂的，但結果不一定是不好的，只是大家怕害的不是改變，而是未知的不確定感。 這如同團隊剛要敏捷時，對於要做些什麼，會發生什麼變化，整個心思和焦點都被這不安因素佔據，完全沒法看到其它正向面。好好說明並讓成員都理解為何要合併是基本，但也通常停止在這一步驟。如果能再多說明接下來可能的情境，成員能在腦中形成想像，可以降低焦慮和不安感。 ●賦能自我探索 有了上一步的心情穩定後，大腦就可以正常發揮。主管如果能讓成員藉由這次難得經驗也獲得經驗成長，這將是雙贏。千萬不要只是等待時間的到來，然後合併，結束了這過程，很浪費。那要怎利用呢? 簡單一個概念，就是把 原本只屬於主管的事，變成大家的事 。也就是說， 請成員在合併前，好好思考對於自身會有哪些影響與改變，並請各組長分組帶頭討論。 主管創造這討論空間，成員自然而然會去找合併的團隊探聽，間接賦權成員，讓他們有機會思考，也有機會掌握接下來的改變。這也是降低合併負面感受的好方法，主導權一半給團隊，自己可以如何與想要怎麼做的發揮空間。 ●回饋與調適 記得，任何討論的過程，主管最好都是被動的。例如，組長和成員自己發起的討論，沒有主管在，會有更開放、安心的討論。主管只要在最後的結果整理好後，另外拉個會議給與建議和回饋就好，藉由過程引導成員成長。 當然，前期信任和安全的失敗環境要先建立好，才有機

【從 阿喜法則（ARCI Model） 來看 Scrum角色】 前一陣子很流行「當責(Accountability)」，大概就是「負責」升級成2.0的概念。如果說「負責」是對自己的承諾，那麼「當責」就是是對別人的承諾，所以「當責」比「負責」更具深度、廣度，唯有實施當責，把對的事情做對，才能既有效果又有效率(from wiki)。 當責裡面有用到 阿喜法則(ARCI Model) 來描述當責團隊的樣貌，用四種角色和四種責任區分。先來看看wiki如何描述各職責， ARCI法則，目的是協助任務相關者的分析與項目規畫，進而確認責任範圍。可助於角色的分配與協調。 角色可分為： A：當責者（Accountable） 負起最終責任者，是經理人，有否決權（Veto power）；每個活動內只會有一位「A」，這個人必須負全部的責任。 R：負責者（Responsible） 實際完成任務者，是執行者（Doer）；負責行動與執行，可有多人分工，其程度由「A」決定，他遵循「A」的領導做事。 C：事先諮詢者（Consulted） 在「最終決定」或「行動」前必須諮詢者，可能是上司或外人，為雙向溝通的模式，須提供「A」充分資訊，簡單的說就是顧問。 I：事後被告知者（Informed） 在決策之後或行動完成後必須告知者；是有關人員，在各層及各部門為單向溝通之模式，是執行的一部分。 ( 參考 ) 《當責》一書中提及，李‧波曼（Lee Bolman）與泰倫斯‧迪爾（Terrence Deal）在1984年的著作《認識與經營組織的當代之道》（Modern Approaches to Understanding and Managing Organizations）裡，首先提出「RACI」的概念（通稱為銳西矩陣（RACI matrix）或銳西法則），目的在於協助澄清「誰該負什麼責任？」畢竟，唯有清楚界定一項任務所有參與者的角色與責任，才能避免權責不分或推諉塞責。 然而，隨著RACI法則的應用範圍日廣，RACI本身的用字次序與用意，開始引發爭議，舉凡英國資訊工程基礎建設學會（ITIL）、顧問業者及企業，均主張「是ARCI，不是RACI」。 以A來舉個例子，就工作坊或活動來說，當人數多的時候，為了方便傳達訊息與快速回應， 大多會拆分成小

【看板方法導入 - 過程總結】 上一篇【 Scrum過程總結 - The Great ScrumMaster 】提到"成功變革八步驟"，試著來套用看看 ~看板專案過程~ ●引導團隊● 看板方法導入 PART 0 - 情境體驗、資料蒐集與訪談 ●建立迫切感● 看板方法導入 PART 1 - 問題發現與現況連結工作坊 ●理解與買帳● 看板方法導入 PART 2 - 看板建置 看板方法導入 PART 3 - 第一次Daily 看板方法導入 PART 4 - Daily 迭代(消除浪費) 看板方法導入 PART 5 - Daily 迭代(時間管理) 看板方法導入 PART 6 - Daily 迭代(資訊與認知落差) ●變革願景● 看板方法導入 PART 7 - 第一次回顧會議(問題蒐集) 看板方法導入 PART 8 - 第一次回顧會議(問題共識) 看板方法導入 PART 9 - 第一次回顧會議(規則明確) ●賦權他人行動● 看板方法導入 PART 10 - Daily 迭代(觀念、行為、習慣、態度...等非認知能力提升) ●短期成功● 看板方法導入 PART 11 - 第二次回顧會議(ORID焦點討論法) 看板方法導入 PART 12 - WIP(披薩工廠) ●不要懈怠● 列Check list清單給主管，後續追蹤與執行 看板方法導入 PART 13 - 第n次回顧會議(期望) ●建立新的文化● 文化的改變還需要時間來沉澱 由於是輔導性質，最後的二步就由團隊自主慢慢在對的時機點來臨時發酵。 每個團隊狀況不一樣，所以上列也是參考。有些團隊對於WIP的需求就很破切重要， 一定要在初期就引入才有效果，有些是溝通就很不好了，還沒到工作，所以需要先調體質。有些心團隊則是需要些框架規範，直接套入即可。面對不同團隊有不同的執行樣貌與比重，但基本上，八個步驟都會經歷。 當你輔導的團隊越多排斥、抗拒心態時，前二步的"引導團隊"、"建立迫切感"越是要做好。多多善用或創造一些活動(儀式)來創造更多的投入度。 整個過程剛好有個很大的效益呈現出來，有個長期二三個月的案子，在這次看板過程上線，比以往順利很多(大概