NT330 特價中
這主要是一門邊做邊學的課程。很快地深入到 3 個實際操作的專案中,這些專案展示了成功的團隊是如何執行敏捷 Scrum 的。
你將從這門課程中得到什麼 ?
展示為什麼敏捷 Scrum 在如此多的軟體專案中執行得如此之好。
你將獲得對官方敏捷 Scrum 的深入理解,正如 Scrum 的 Scrum.org “規則手冊”中所描述的那樣。
然後通過分層的非官方敏捷 Scrum 來進一步瞭解成功的團隊如何填補 Scrum 中的缺口。
完成一個逐步的、真實世界的專案,它將向你展示如何從一個產品構想,轉變為一個功能完善的實質待辦事項列表( backlog )。
https://softnshare.com/agile-scrum-mastery/
backlog軟體 在 矽谷阿雅 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
backlog軟體 在 DavidKo Learning Journey Facebook 的最讚貼文
[光是只有Scrum 還不夠]
最近剛好翻到之前整理 Uncle Bob 對 Scrum 批評的文章, 現在看起來還是十分受用.
https://kojenchieh.pixnet.net/blog/post/75411841
A. 工程實踐沒有就 GG
畢竟這是軟體開發, 如果沒有工程實踐, 不斷的迭代, 會讓系統很不穩定, 需要工程實踐來導回正道.
所以, 我猜測如果 Sale, HR , 或是其他領域要來用, 或許可能要找到那個領域的工程實踐來幫忙.
B. Scrum Master 不是一個人?
SM 這個角色是否必要, eXtreme Programming 倒是有不同看法, 他認為可以由一些 team members 來輪流. 我看過隔壁團隊是這樣去做, 效果還不錯, 讓大家會更有 owenrship, 畢竟如果沒有專注在其中, 下次輪到你可能會不知道怎麼做.
C. 自組織不是萬能
Scrum 是有點反抗管理, 認為團隊自組織就可以解決一切. 可是這是有點想得太美好, 有些人還是習慣有別人幫他出個主意, 這時候有個主管幫個忙還是有用的. 或者是有些跨團隊的溝通, 或者是一些行政庶務, 這些讓主管出手其實沒什麼不好.
D. Scrum 只是產品流程的一小段
其實 Scrum 沒有講的東西真的很多, 不光是需求探索的部分, backlog 的管理, Ops 等等都不在其中, 本來你就還需要別的技能, 不過, Scrum 在開發的流程上還是很優秀的.