【 #敏捷開發，快速回應市場的工作流程 】

九月底到十月初，我們和 Reborn 設計學院 企劃了為期一週的 Design Sprint 課程，從 Mapping 一個專案、繪製 Sketch 到最後週末各組學員上台 Pitch 自己產品的 Persona/Customer Journey Map 和 Wireframe，很扎實走過一趟 UX 設計課。

＃體驗設計從受眾出發
在策展領域，實體的觀眾互動和心流曲線，是體驗設計師最需專注的面向之一。轉移到 UX 介面，我們探討了更多受眾在使用產品時的痛點和延伸出的機會點，每一步設計都回歸到觀眾行動、感受。
The Curators 策展人們將持續推動體驗相關的課程，並歡迎各界團隊合作，聯合企劃活動或線上專案！

-------------------------

策劃單位｜Reborn 設計學院、The Curators 策展人們
課程講師｜Terry Wu、Alvin Chen、Mark Lin
企劃設計｜Reborn 設計學院、The Curators 策展人們
協辦單位｜街口支付
課程攝影｜Jang Long

【有些事你不熱愛它，還是可以收穫滿滿 - Scrum到底講什麼？】
今天考過了Scrum Master的證照！坦白說，我一直都沒有想過要去考證照，因為我是一個熱愛挑戰、有時喜歡破壞規則的人，總覺得這種規則很多的東西不適合我。但剛好 HowAgile 請我給他們的課程一些反饋、天下文化 請我做 #SCRUM敏捷實戰手冊 書評，大人學、MasterTalks 請我開產品管理、專案管理的課程，「是時候好好研究一下我沒有特別熱愛的事！」我想。

雖然面試過上百Scrum Master(敏捷導師)、陸續有十多個敏捷導師在我團隊上，也用敏捷開發十多年，但我其實沒有考過證照，也不知道竟然還有手冊！

抱著踢館的心態，開始了證照課程，發現自己用敏捷開發就像是騎腳踏車，會騎（用敏捷十年）、也在國家隊裡（臉書），但其實不知道原理，了解原理以後，感覺事情都串連起來的感覺！

幾個簡單的摘要給大家，不過切記，重點是團隊自動自發、有自主權的精神和背後的道理，倒不是這些規則喔！

【團隊】
📌 Product Owner管Product Backlog，負責讓Development Team做的事發揮最大的價值
📌 Scrum Master提倡、觀察、指導、協助團隊用Scrum
📌 Development Team決定Sprint Backlog，負責達成Sprint Goal、每個Sprint產出可以使用、上線的產品「Done Increment」，所有需要完成Backlog都在Development Team上，可能不只有工程師

【Sprint】不超過四週，矽谷軟體公司通常是兩週
【會議】
📌 Sprint Planning：決定Sprint要做什麼、Sprint Goal，一月不超過8小時。在業界通常分為「Backlog Grooming」讓團隊了解要做什麼、「Sprint Planning」決定Sprint 要做什麼。
📌 Daily Scrum：在業界常被叫做「Daily Standup每日站會」，固定15分鐘，只有Development Team參加。
Sprint Review：在業界常被叫做「Demo」，每月不超過4小時。不只是「看喔！我做好了！」還有評估調整剩下的東西。
📌 Sprint Retro：檢討會，每月不超過3小時。不只是檢討，還有選出一樣改進下個Sprint執行。

雖然我覺得Scrum Guild有些過於理想化，業界通常Product Owner也不是那個最了解產品時程的人（是Scrum Master），但整體來說，還是一個非常棒、矽谷每家公司都用（類似）的framework。
還有很多心得啦！下次再細講。

👉 聽 矽谷資深女工程師 、 NATEA北美台灣工程師協會 工程師怎麼用敏捷，今天台灣時間11am、美西晚上8點 https://www.facebook.com/events/3495823580475824
👉 Scrum書 https://www.books.com.tw/products/0010856655
👉 考scrum證照 HowAgile
👉 免費Scrum 線上測驗 https://www.scrum.org/open-assessments/scrum-open
👉 免費Scrum Guide https://www.scrumguides.org/
👉 上非Scrum專案管理實戰課 https://shop.darencademy.com/product/view/id/1

這週的分享來跟大家聊聊一些軟體建設的基礎，因為常常在和朋友聊天的時候，談到一些公司導入敏捷開發，但執行起來卻不是很順暢的情境，所以想趁這個機會和大家聊聊我的一些想法。

使用敏捷方法進行開發最大的好處是能夠盡快的交付價值，並且收集反餽，作為快速疊代的基礎。但往往敏捷失敗最大的原因，是忽略了先建立好能夠支持敏捷方法的基礎建設，舉例來說，如果今天沒有足夠的單元測試、自動化測試，那怎麼可能保證在快速交付的同時，維持產品的品質呢？

舉一個很實際的例子，假設今天我們是一個 ”成熟” 的敏捷開發團隊，每一個 Sprint (兩週) 固定可以完成 20 個 User story，而目前團隊已經完成 100 個 User story 功能上線，我們每一個 Sprint 的目標是，在盡可能交付新的 User story 的同時，要確保原本既有的功能使用正常，這樣才能夠對客戶帶來最良好的使用者體驗。這樣的情境假設應該是每一個敏捷團隊希望達成的目標，甚至是希望能夠透過持續改進的方式，讓團隊和產品成長的同時，交付速度越來越快，但是由於團隊希望可以專注在 「交付價值」（注意這邊這個交付價值的定義），所以一切都以 ”開發” 功能為優先，在 Merge PR 或是上線前再多做一些測試確保功能正常。這一切聽起來都非常的合理，大家專注在交付價值，但是在幾個 Sprint 之後，卻發現使用者抱怨系統問題的頻率變高了？

這個情境其實是一個很常見的誤區，由於想要趕快先交付價值，讓系統上線，所以打算等有空的時候再補測試，或是先用手動測試，但卻忽略了功能成長時測試案例增加的速度，如果原本團隊已經有 100 User story，每週可以穩定交付 20 個新的 User story，那麼只要 5 個 Sprint，需要驗證的功能數量就會變成一開始的 2 倍，只要經過一年，測試的工作量就會將近變成 7 倍，通常到最後都會變成，只測試覺得有被修改的部分，或是感覺需要測試的部分，剩下大部分的功能都不會被測試到，自然而然產品就會越來越多小問題，也越來越不敢隨意修改，反而導致開發速度大幅度下降，甚至是因為不敢大幅度的修改，失去了重構的機會，然而讓程式碼更難維護，然後又發生越來越多的問題，進入了一個惡性的循環！

所以從一開始定義正確價值交付就是一個很重要的議題，在定義產出的時候，就必須要把維持產品品質最低限度的標準都包含進去，例如是否有經過 Linter 確保程式碼風格一致，所有產出的 Feature 都包含單元測試、自動化測試甚至是安全測試或壓力測試等等，讓這些成為產出的標準，自然而然就可以在持續疊代的同時，維持產品的品質，甚至是持續優化交付的速度！所以當進行敏捷開發時，必須要時時刻刻的檢視自己是否有把「品質」當作一個重要的指標，能夠很好的了解自己的產品價值所在，注重軟體開發的本質，才能夠更進一步的有穩定的疊代產出！

基本功是無論如何還是很重要的啊，如果沒有好好的打好基礎，不管用的方法工具再先進，都是跑不快的！