敏捷開發,規則少少,看似簡單;
But,為什麼當我們真的要導入
才發現困難重重,不斷踩雷?


因為,你放錯重點了!

原理出發,在活動中體驗
避開無效的冤枉路,
不僅敏捷上路,更團隊重塑

立刻報名! ▷

THE COMPANIES THAT MAKE THEIR LIFE EASIER

體驗敏捷核心精神,
 由內而外,

踏出成功的第一步。

只要找一面牆當看板,寫寫便利貼,一群人在每日站會時大玩陶侃搬磚的遊戲,就是敏捷開發了嗎?
 
錯了,那不是重點!
 
重點在於,整個團隊的「個人與互動」是怎麼進行的?整個團隊是怎麼界定「可用的軟體」並據以規劃排程?該怎麼「與客戶互動」並「回應變化」呢?該怎樣建立安全感?該怎樣持續交付令客戶滿意的價值?該怎樣迅速實驗與學習?
 
或許,更根本的質疑是:「不重視這些,又怎麼樣呢?」或許,更殘酷的現實是:「如果我既沒有職位權,也沒有話語權,該如何踏出敏捷開發的第一步?」
 
沒有打自內心真正認同敏捷價值,並真心承諾為此齊心奮鬥,就會在敏捷實踐過程中一遇到困難,就酸言敏捷無用,甚至交相指責。
 
在演講諮詢及輔導團隊的過程中,我屢次看到上述問題的嚴重性,也累積了一些技術面及非技術面的引導手法。我發現,在崇尚經驗主義的敏捷框架之餘,搭配一些理性主義及其他領域的強項:TOC 的瓶頸處理、思考程序、抵制變革層次、應用專題,Satir 的改變歷程、冰山理論、雕塑手法,Kotter 的變革加速器觀念,可以有效降低敏捷開發的導入阻力,統一心智模式,建立共同願景。
 
有了這些基礎,再談進一步的 Scrum 或 Kanban 流程規則,可謂順水推舟,水到渠成。
 
現在,我將上述經驗,精煉而成這門七小時的體驗課。
 
這是一門動手、動眼、動口,更是動腦與動心的體驗課。哥教的不只是解答,更是思考的過程;不只是敏捷開發的核心方法,更是敏捷團隊的塑造心法
 
先處理心情,再處理事情!

帶得走的肌肉記憶

活潑有效的軟性引導手法,可轉化運用到自己的團隊身上。身體學會的,誰也拿不走!

血淋淋的鐵證

從真實案例及思辨過程,親眼見到傳統方法的問題,親自體會敏捷原理的效用。

打破人的界線

在課堂活動中,親身體驗敏捷宣言訴求的「個人與互動」是怎麼樣的境界。團隊團報,效果加倍!

這是一趟難以置信的旅程,兼具了敏捷的藝術及技術。
(原文連結)

葉秉哲老師是個有熱誠的人,很會帶課程氣氛,課程中每一個活動都精確點出採用敏捷開發很重要卻被非常容易忽略的點。

課程中活動的時間拿捏很精準,真正拖延時間的是我們(學員) XD,實在是有太多疑問想要提出,其範圍甚至超出敏捷開發或 Scrum,葉老師仍是知無不言,把軟技能都傾囊相授。同時也看得出來,為了把團隊成功帶起來,他涉獵的範圍之廣,著實令人佩服。

這個課程也讓我有機會與工作上同樣角色的人交流,原來我們遭遇的情況很普遍,大家都帶著差不多的無奈或傷痛希望求得一點解答。雖然軟體開發沒有銀彈,不過吃飯的時候一起上課的同學跟我們分享,他覺得很受用也很感動,是的,就是感動。
(原文連結)

想徹底搞懂 敏捷開發 的玄妙之處嗎?

給自己一個團隊升級、創造價值的機會吧!

立刻報名! ▷

Automate everything, make life easier!

Automate everything, make life easier!
© Copyright 2017

中華電信  台灣大哥大  xxx百大企業  工研院電通所  中央大學資訊工程系

課程內容

塑造敏捷的團隊氛圍:Modern Agile

體認敏捷的核心價值:Agile Manifesto

從理性主義角度分析敏捷實踐

實況演練:Sprint Planning、Daily Stand-up、Retrospective

推薦讀物

Q&A

預期效益

知其然,亦知其所以然,更能妥善運用 Scrum 或 Kanban 等敏捷方法。

知性與感性並重的體驗活動。

融合 TOC、Satir 等領域的精髓。

觀念衝擊,尤適於整個團隊全員組隊參與,達到團隊塑造的效果。

預見可能的困難,更有自信踏上敏捷之路,更有全員一起奮鬥解決困難的勇氣。

敏捷原理 團隊塑造

由內而外,踏出成功的第一步

適合對象

本課程適合對敏捷開發感興趣的 IT 從業人員:專案經理、產品經理、研發主管、UX 設計師、程式設計師、品管人員等。


不適合對象

1. 沒有在軟體開發環節中擔任過任何一個角色的,可能不易體會課堂中呈現的困境及衝突。

2. 曾上過 CSM、CSPO、LeSS、PMI-ACP、PMP 課程超過七小時,或已有相關證照者,這門課對你來說太小兒科了。

2017 年 Q2 梯次

8/20(日) 09:30~17:30 (午休一小時)

地點

台北市忠孝東路五段 293 號 3 樓/ Bookshow
(捷運板南線,位於市府站及永春站之間。)

課前作業

敏資歷

  • 2014~2016 連續三年在 Container Summit 技術高峰會發表 Docker 技術趨勢及導入手法。
  • 2015 在 Docker.Taipei Meetup 發表【追求極簡化 Docker image 之路】。
  • 2016 在 Community Open Camp 發表【從 Ansible 到 Docker:混血模式】。
  • 八個梯次 Docker Workshop 教學經驗 : 2015-02-07、2015-03-07、2015-04-11、2015-05-09、2015-06-27、2016-12-18、2017-03-05、2017-04-09。
  • 在數個學校及公司行號演講 Docker 及教育訓練。

學員感言

講師簡介

葉秉哲 (William Yeh)

擔任過許多職場角色:程式設計師、軟體架構師、技術團隊領班、技術作家及譯者、教授、顧問、技術佈道者,但目前最喜歡的身份,還是「研發團隊教練」。

  • 曾列名《資訊游俠列傳》的名人介紹,被譽為「台灣十大電腦高手」之一。
  • 譯有《C++ 程式語言經典本》、《物件導向設計模式 Design Patterns》等經典著作。
  • 於 Gogolook 擔任軟體架構師、Server 總監、Scrum Master。
  • CSPO

► 這次課程,適合拉主管及同事一起來聽嗎?

這門課的前身,一部分是公開講座(在敏捷社群講過兩次的【瓶頸處理九大原則】),一部分是企業內訓(在自家公司及其他公司都有講過),過程中發現,我設計的活動內容,不僅傳達了敏捷原理,還兼具「團隊塑造」的效果。
 
你會選擇來上課,一定是對敏捷開發的好處有些期待。如果你不希望回到工作場域之後,還要絞盡腦汁費盡唇舌去對同事洗腦,甚至主管,何不直接邀請他們一起組隊報名,讓我來負責做洗腦的工作呢?
 

► 我是程式設計師(或是 UX 設計師、品管人員 ),沒有專案管理背景,能上這門課嗎?

這門課不會涉及太多專案管理的背景知識。只要你曾在軟體開發環節中擔任過任何一個角色,就能體會課堂中呈現的困境及衝突。
 
大體而言,只要你能夠把課前作業做到五成的地步,就能來上課了。
 

► 我是主管(可能是專案經理、產品經理、研發主管 ),但其實也還不太懂專案管理,能上這門課嗎?

這門課不會涉及太多專案管理的背景知識。只要你曾在軟體開發環節中擔任過任何一個角色(即使只是動嘴不動手),就能體會課堂中呈現的困境及衝突。
 
大體而言,只要你能夠把課前作業做到五成的地步,就能來上課了。
 

► 我是 xxx 人員,沒有直接參與過軟體專案,能上這門課嗎?

雖然理論上來講,「敏捷原理」並不局限於軟體產業,但為了聚焦,這門課在設計上就是圍繞在軟體產業的脈絡情境。如果你不曾在軟體開發環節中擔任過任何一個角色,可能不易體會課堂中呈現的困境及衝突。
 
你可以做個簡單的實驗:如果你能夠把課前作業做到五成的地步,就能來上課了。
 

► 課前作業好像有點難⋯⋯做不完,還能上這門課嗎?

課前作業的內容,會作為課堂上某些互動活動的素材。
 
這門課,不只是給解答,不只是給直接套用的範例,更著重在思考的過程。所以,親自嘗試課前作業,將你的頭腦及心態都調整到能在課程現場暢快思辨、徹底吸收的強度,是很重要的前置準備工夫。
 
根據過往數個梯次的經驗,投注在課前作業的心力愈確實,在課堂上的收穫也愈多,也愈能提出有水準的好問題。
 
為了確保你一走進課堂,馬上就能進入狀況,至少請試著將課前作業做個幾成,並記錄你感到困難的地方。
 
你能學到多少,完全看你事前投入有多少。加油吧!
 

► 在我的工作經驗中,都不曾被要求做正式或非正式的工作分解,所以這次的課前作業,對我來說有點抽象。能給我一點點提示嗎?我怕搞錯方向⋯⋯

這次課前作業,難度應該低於我的另外兩門軟體技術實作課(Ansible WorkshopDocker Workshop)。不過,對沒有被如此要求過的工作者,或許稍微抽象了一點,格局與廣度也提高了一個檔次。
 
好吧,我提供一份我經手過的工作分解真實案例,供各位參考。我會同時用「WBS + activity」及「User story + task」兩種形式來示範。
 
⋯⋯會放在課程的 Quip 中。加油吧!
 

► 真實的軟體研發工作場域中,真的有人會用像課前作業所描述的這種方式來做事嗎?

千真萬確。而且,是連非資訊背景的人,也做得到的。
 
像下圖,最右邊的看板,就是敝公司某位大學剛畢業的 PO (product owner),獨自拆解的。這位「PO 資歷」才一季的 PO 做得到,你也一定做得到!
 

常見問題

注意事項

這份課前作業,要藉此請你思考:貌似簡單的軟體專案,背後竟有多少隱含的交付標的 (deliverable) 及工作項目 (activity; task)。

工作分解/拆解,並不只是專案經理的責任,而是實際執行者也必須參與的。這也是專業工作者的責任區。所以,不管你的職場角色職位是什麼,都請你努力完成這份作業,才能深刻體會本課程的某些議題。作答內容,也會作為課堂活動的素材。

如果你不太熟悉工作分解結構 (WBS) 概念,請參考以下幾篇淺顯易懂的文章:

小提醒:「工作分解結構」觀念,不管是古典的 PMP,還是近代流行的 agile、Scrum、Kanban,其實大原則是相通的。讀這幾篇文章時,請留意幾個重點:

  • Deliverable (用名詞表述) 與 activity (用動詞片語表述) 的劃分。
  • 逆向拆解。
  • 100% Rule。
  • 麥肯錫的 MECE 原則(Mutually Exclusive, Collectively Exhaustive),也就是說,WBS 拆解要做到「彼此獨立、毫無遺漏。」

題目

你是專案經理,奉命帶領一個 Web 軟體專案,以知名的 TodoMVC 範例為競品,還要超越它,做出多人、多帳號的網路版,資料也要儲存在雲端伺服器上。

現在,你開始規劃專案的工作分解結構,並預估個別工作項目的理想工時,以向主管報告。

  • 交付標的 (deliverable)名詞表述,請列出至少兩層。
  • 工作項目 (activity; task)動詞片語表述。
  • 個別工作項目的工時估計,請以「理想工作天」為單位,最小單位為 0.5 天。
  • 如果個別工作項目超過 2 個工作天,請再予以分解。

請在 Quip 課程群組中作答。並在上課前自行列印一份,攜至課堂上。

想在第一時間
收到本站快訊嗎?

OSS 大獎肯定

InfoWorld 2015 最佳雲端/資料中心軟體 (詳情)
opensource.com 2014 十大開源軟體 (詳情)

Why Ansible?

大廠背書

2015/10 被大廠 Red Hat 併購,據傳金額超過一億美金。

專家證言

「這些 (InfoWorld 2015) 好用的系統軟體,有時間多學一個,功力就多一分;學會如何綜合運用,境界就提升一級;懂得修改這些開源計畫來滿足應用需求,就能夠解決許多問題;有能力改良創新這些開源計畫,那就是炙手可熱的人物。」(台大資工洪士灝)

2017: 第二梯次
8/20 (日)

昨天真的是很棒的課。我其實上過您的 AnsibleDocker,這是我第三次上您的課,卻是第一次看到如此具備軟技能的 William。蠻感動的!

雖然之前參加過 xxx 的 CSM 課程也拿到了認證,但是整個執行起來,還是有很多疑慮的。

還好有幸逛到學長的臉書,看到課程就立刻報名,一天的課程就釐清了許多實際上碰到的疑惑。也感謝學長提供了許多火力的指引,對於 引導 這件事情,終於感到有個學習的脈絡可循了。

上課過了一個星期多了,我仍常想起來當天的場景,也常常想起敏捷宣言。

如果有 #AgileWorkshop Part 2 的話,我會很期待!

訂閱! ▷

這是堂極具互動和軟技術的課程,講者藉由自己的實戰經驗和不少的體驗活動,讓我們意識到 Agile 是什麼?怎麼藉由 Agile 在有限的資源下打出一手漂亮的好牌?

在 Agile 之外,講者更融入了「薩提爾的冰山理論」、「限制理論」、「使用者故事對照」⋯⋯等軟技術進行團隊塑造,這都是我未曾接觸過的領域,說講者是本活字典也不為過!
(原文連結)

是的,這門課有課前作業!

課堂需求

不需自備筆電,也不建議帶平板電腦。

請攜帶慣用鋼筆、原子筆或鉛筆,穿著寬鬆衣物。

► 課前作業,我一個人做起來有點吃力。能夠和別人一起合作嗎?

可以。而且,如果你們是團報,也鼓勵這麼做。
 

► 課前作業太簡單了⋯⋯我還需要上這門課嗎?

強人!這門課對你來說,只是幼幼班等級(或許對你來說,敏捷與否也已經不是需要考慮的問題了)。
 

► 這次課程,會只講理論嗎?

如果只講理論,其實市面上已經有一堆專書,網路上也有一大堆文章,並不需要來上課。
 
這門課,將敏捷開發活動的真實案例,改編成體驗活動來呈現。所以,不是理論派,而是實戰派。
 

► 這次課程,會講 Scrum 或 Kanban 這些具體的敏捷方法嗎?

許多人急切導入 Scrum 或 Kanban 方法,卻忽略背後的敏捷原理,甚至團隊心態,很容易一遇到困難就半途而廢。你看看台灣有多少公司嘴巴嚷嚷著對敏捷感興趣,但真正開始上路的比例有多高,就知道這問題嚴不嚴重了⋯⋯

這門課,著重在各種敏捷方法背後的共同基礎,尤其是對齊整個團隊的心態。有了這些基礎,再談進一步的 Scrum 或 Kanban 流程規則,可謂順水推舟,水到渠成。
 
七個小時的課程中,會適度介紹 Scrum 及 Kanban 的概括內容。如果日後你決定要導入 Scrum 或 Kanban,需要知道具體的遊戲規則,不妨讀讀《告別瀑布,擁抱 Scrum》、《Essential Scrum》、《精實開發與看板方法》之類的專書。屆時仍有疑惑,再去考慮以下優質課程,擇一報名:【David Ko 教你 Scrum 軟體開發】、【Scrum 敏捷方法實作班】、【看板方法與精實開發實作班】。
 

► 如果課前想先預習,可以先看哪些書呢?

其實不太有必要。如果你堅持要先讀一些書才肯放心,我只建議這一本:Scrum 發明人之一寫的《Scrum:用一半的時間做兩倍的事》,可當科普讀物(書介1書介2)。還不放心的話,可加讀這本:《軟件開發本質論》。
 

► 這次課程,需要自備筆電嗎?

不必。本課程是高度的互動體驗活動,筆電不僅會佔據寶貴的桌面,更可能不慎掉落。
 

► 關於這次課程,我還有些地方不太清楚⋯⋯

歡迎利用畫面右下角的【課程留言】功能提出問題。
 

► 報名繳費之後,還有什麼事情我該做的?

離課程開始的日子,還有好幾天的時間。在這段等候的時間中,我會陸續透過 email 及 Quip 這兩個管道,通知你一些要事先準備的事項。
 
Quip 是個很方便的團隊協作平台。我在 Quip 開設一個課程群組,陳列相關的課程準備資料、作業繳交區、公告事項。還有一個「許願池」,可以讓你許願:提出你想在課堂上聽到或實作到的項目,我會列入參考。
 

► 聽起來不錯!我該怎麼加入課程群組呢?

報名完成後,數個工作天之內,你會收到 Quip 寄給你的邀請函。