【 #敏捷開發,快速回應市場的工作流程 】
九月底到十月初,我們和 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
同時也有10000部Youtube影片,追蹤數超過2,910的網紅コバにゃんチャンネル,也在其Youtube影片中提到,...
「sprint敏捷開發」的推薦目錄:
- 關於sprint敏捷開發 在 The Curators 策展人們 Facebook 的最佳貼文
- 關於sprint敏捷開發 在 矽谷阿雅 Anya Cheng Facebook 的精選貼文
- 關於sprint敏捷開發 在 愛流浪的小風 Facebook 的最佳貼文
- 關於sprint敏捷開發 在 コバにゃんチャンネル Youtube 的最佳解答
- 關於sprint敏捷開發 在 大象中醫 Youtube 的最佳解答
- 關於sprint敏捷開發 在 大象中醫 Youtube 的最佳解答
- 關於sprint敏捷開發 在 在scrum 中,怎麼處理這個sprint 中發生的插件? 1. 讓它插進來 ... 的評價
sprint敏捷開發 在 矽谷阿雅 Anya Cheng Facebook 的精選貼文
【有些事你不熱愛它,還是可以收穫滿滿 - 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敏捷開發 在 愛流浪的小風 Facebook 的最佳貼文
這週的分享來跟大家聊聊一些軟體建設的基礎,因為常常在和朋友聊天的時候,談到一些公司導入敏捷開發,但執行起來卻不是很順暢的情境,所以想趁這個機會和大家聊聊我的一些想法。
使用敏捷方法進行開發最大的好處是能夠盡快的交付價值,並且收集反餽,作為快速疊代的基礎。但往往敏捷失敗最大的原因,是忽略了先建立好能夠支持敏捷方法的基礎建設,舉例來說,如果今天沒有足夠的單元測試、自動化測試,那怎麼可能保證在快速交付的同時,維持產品的品質呢?
舉一個很實際的例子,假設今天我們是一個 ”成熟” 的敏捷開發團隊,每一個 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 都包含單元測試、自動化測試甚至是安全測試或壓力測試等等,讓這些成為產出的標準,自然而然就可以在持續疊代的同時,維持產品的品質,甚至是持續優化交付的速度!所以當進行敏捷開發時,必須要時時刻刻的檢視自己是否有把「品質」當作一個重要的指標,能夠很好的了解自己的產品價值所在,注重軟體開發的本質,才能夠更進一步的有穩定的疊代產出!
基本功是無論如何還是很重要的啊,如果沒有好好的打好基礎,不管用的方法工具再先進,都是跑不快的!
sprint敏捷開發 在 在scrum 中,怎麼處理這個sprint 中發生的插件? 1. 讓它插進來 ... 的推薦與評價
91 敏捷開發之路. 莊為任 蠻常見的作法,那2位operation 的如果線上無事,就會跟團隊一起pair,有事就可以隨時抽出身來處理. 1 yr Report. 陳涵宇, profile picture. ... <看更多>