敏捷突擊隊 — 松山站
這篇文章，很多的文字會來自於 David 哥的這篇文章。
為什麼會有這個活動呢? 主要是看到了對岸敏捷圈有這個活動，覺得這樣的活動很有意義，不但推廣了敏捷，也驗證社群自己的實戰經驗。因此，就和上海的組織小夥伴說一聲後，就在台灣這邊舉行。如果你對對岸的活動有興趣，可以參考以下文章：
這次敏捷突擊隊與事主約在松山車站附近的書店，邊吃邊聊。敏捷社群由我與 Jenson 一起參與討論：
公司名稱：kkday
聯繫人：Onnie
問題背景
1) 如何建立 IT 和非 IT人員的敏捷概念。
2）產品及微服務架 vs. 敏捷組織的建立原則
在聯繫 Onnie 之後，取得更具體的問題如下：
1. 沒有教練，是否應該找個全職的教練呢？是找敏捷教練？還是 Scrum 教練呢？
2. 根據”康威定律” vs 敏捷跨職能的角度來看，IT 組織的方式方向或建議？
3. 多個小組的合作 vs 敏捷組織，合作或分工的方式？
4. 小組各自運作，但又在建立在同一個商業核心上，所會面臨的問題？
事主 Onnie（kkday CTO）對於在團隊推動 Agile 的背景闡述：
2014 第一次聽到 Scrum，當時的印象是 Scrum 是許多新創公司採用的方法，加上團隊裡的成員也想嘗試，就跟著團隊一起跑了幾個 sprint，只是過程中一直覺得很卡，所以執行幾次後就停止了。
去年團隊有幾位年輕的成員加入，對於 Scrum 躍躍欲試，所以又開始跑了起來，團隊裡也有成員會去研究與了解 Scrum，但執行了一陣子後還是遇到類似問題，例如 Daily Scrum 雖然都有開，只是久了就變成例會
建議的方向
1.沒有教練，是否應該找個全職的教練呢？是找敏捷教練？還是 Scrum 教練呢？
- 台灣專職的敏捷教練數量有限，即使是要找專職的 Scrum Master 都不是那麼容易。
- 或許可以先送幾個成員去上課，成為團隊裡推動敏捷的種子球員。
2. 根據”康威定律” vs 敏捷跨職能的角度來看，IT 組織的方式方向或建議?
3. 多個小組的合作 vs 敏捷組織，合作或分工的方式？
關於這兩題，以下提供數個大規模敏捷的 framework 作為參考，提供連結，可以點過去看看～
- Scrum of Scrum （Jeff Sutherland 與 Scrum Inc所提倡）
- SAFe（客觀來說，似乎是主流的大規模的敏捷作法。）
- LeSS（一個 PO，實作上似乎比較需要有經驗的敏捷教練，並且大家要相信敏捷與 Scrum。）
- MicroService（要切的漂亮很困難）
- Nexus （Scrum.org 所提倡）
基本上，因為問到我了…XDDDD 所以想當然爾我個人建議是使用 LeSS，非常不建議使用 SAFe。不過這都只是個人意見而已。
所以，一個 PO，其他的團隊不要以 Component 或是 functional 去分隊，而是組成一個一個的跨職能團隊，各個跨職能團隊對一個一個 feature 有交付的責任。
Onnie 還順便問到了設計與開發團隊如何比較好協作。
建議是，設計團隊偷跑至少一個
sprint，一個 sprint 可能不夠，因為設計師們的偷跑可能要累積數個 sprint
後才可以有足夠的份量與設計脈絡給工程師們施工。同時，設計師們也要參與開發團隊的開發，互相 feedback，互相調整，讓最後的產品與成果是好的。
4. 小組各自運作，但又在建立在同一個商業核心上，所會面臨的問題？
這題太 depend on context，但以 LeSS 來說的話，就是以一個 PO，使用同一份 Product Backlog，對齊團隊，統整需求。
其他建議
這些問題都好大喔…找一個顧問或敏捷教練吧。國內只推薦：Odd-e 的 91、泰迪軟體的 Teddy 跟 Erica。
Ruddy 老師也很推薦，但他已經死會了。
軟體開發沒有太多神奇的地方，基本上就是做好基本功，多檢視，多寫測試，多記錄一些必要資訊，很多問題就不會那麼嚴重。
下次，我們會利用開放空間會議的方法，來討論敏捷轉型和導入的問題。有興趣的人，千萬不要錯過 2018/8 月份的活動喔。
留言
張貼留言