This is what we called "Scrum But".
不要再請鬼抓藥單了,要不要找一下我們這種專業人士去啊?
感覺就像寧可相信電台賣藥的,不相信醫生的建議,自己覺得醫生講的我也會,我也可以致病。
背後的科學基礎、整體系統全貌、累積夠多的失敗與順利上軌道的實務經驗,才是專業人士提供服務的依據。
就像你也知道投三分球得到的分數比較高,Curry 可以從三分線到半場都是他的開火距離,但你學得起來嗎?那適合你嗎?照著你只看到的表面模樣去依樣畫葫蘆,其實還蠻容易死人的,最後就會造就一堆不明究理的人上來靠北工程師上浪費生命。
至少先問一下,你們大家覺得 daily scrum 是為了什麼(我不是問 how,我是問 why),每一個設計的環節都有背後要解決的問題,而這些設計的環節可以彼此搭配出一些綜效。
如果你知道每一個設計環節的目的,要解決的問題,適用場景與限制,那你只要知道現在的團隊、組織痛點在哪、瓶頸點在哪、限制在哪,你就可以比較容易找到突破點,先讓大家進入改善的起點,有感之後,消除瓶頸就會引發瓶頸點轉移,一路把瓶頸點進行改善,就會發現整個 scrum 該有的,大概都有了。
如果你知道全貌,包含背後的目的,理論的基礎,實務的手法,甚至知道其他更多可以解決相同問題但不包含在 scrum 裡面的學問,你才能適時因人因地至宜。
很多人的邏輯沒學好,他們會說「這不是 scrum」,而忽略了「scrum framework 只是指出你該有哪些東西」,它只希望是個 framework,不要給你太多的「限制」,但你不能偏離它的核心與價值觀。
也就是 scrum 上沒有的,不代表你不能做,不是「這不是 scrum」,而是「scrum 沒有規定不能做」。
當然,scrum but 還是很有參考價值的,因為那幾乎都是「錯」的 pattern。
我一般都是建議入門者去看 scrum guide 跟 scrum master checklist (檢查一下你們在各個角色,有沒有符合上面的特徵跟選項),如果看不出來為啥那是個問題,那不知道這是問題就是個大問題。
#有用的話三萬塊不嫌貴
#沒用的話30塊還傷身體
#不要再請鬼抓藥單
--
另一個簡單的判斷標準,你就看你要找的對象,他平時呈現出來的言行是否一致,價值觀是否符合他老是掛在嘴巴上侃侃而談的東西。還是只是老是跩文的 buzzword guy,只是追逐著那堆潮流名詞只為了框點顧問費,是不是那種只是「人脈-driven」酬庸型的顧問。(我實在收別人的爛尾收到有點懶了)
認識我的朋友、參加培訓的學員、被我輔導過的團隊,常關注我 facebook 上分享的內容,應該都可以知道我是怎麼讓自己的人生、職涯、學習跟生活敏捷化的,對我們來說,了解了背後科學依據、理論基礎(scrum 背後的理論基礎跟科學依據,當然遠遠超過 scrum 的範圍,只學 scrum 當然只有皮),自然做事就會選擇有效果的方式。
再講一下 Odd-e 好了,大家 scrum 團隊成員太多,就會想拆 team 對吧?我們是公司超過5個人,基本上就會「拆另一間公司」出來,這樣公司層級的決策速度才會快,大家也才能都參與到。
我們所有的決定,都是團隊一起決定的,人數過多溝通成本過高,反應速度就會變慢。
我們所有的工作,都是自己決定的,薪水也是自己決定的,沒人會指派工作給你,你就是自己、產品、服務、公司的 owner。
註:我們公司的組織階層只有一層,我們的 founder,也是 LeSS 創始人之一的 Bas,跟所有 Odd-e 的人在同一層。扁平式組織?我們是一層式組織,這一層還可以圍成一個圈,互相支援所有事務。
我們講跨職能,Odd-e 的 never does 裡面在 Odd-e 公司內,是不招聘單一職能的夥伴的(例如行政、HR、法務、總務、會計,甚至只擔任講師,其他事情都不想管的那種),你就是公司,該了解的都得學會了解與負責,你才會當責、你才會有切膚之痛,你才會用心跟關心所有事情。這是我們的自組織 + ownership + end-to-end feature team。
我們講的 respect, open, 都能直接在 Odd-e never does 中窺探一二。我們不列所謂的「企業價值觀」,因為我們覺得通常列了什麼價值觀,就是缺了什麼。
我們只列出「我們共同認為不可以做、不該做的事情」,除此以外,是 open 的,你可以做任何事情,別人不能干涉你,當然團隊可以討論商量。
我們相信,每個人提出的觀點看法(perspective) 都有他的價值所在,當對方願意花時間講出來他的 perspective 跟你討論甚至爭論,都是值得被尊重的。我們也相信,任何事情都不會只有單一的 perspective。
如果身為 Odd-e 成員,還需要別人幫你安排好各種工作或事情,你才知道要做什麼,那你根本不該也不會被招進來當夥伴的。
當然,我們每個人還是有自己擅長、喜歡、不喜歡的事情和領域,但我們知道,這都不影響 ownership,該做的事情還是得有人做,但我們都知道也都具備「學習意願」,只要團隊或整個 Odd-e 有人對那一塊領域熟悉或擅長,我們就能跟他取經、抱大腿,或是請他幫忙。
我們對於自己開發產品或提供服務的要求(其實也不算是要求了,因為我們的人生就已經是敏捷化了),只會比客戶高,不會比客戶低。
所以啦,當你們想找外部教練來幫忙時,先去了解觀察探聽一下,他們公司是怎麼運作的,那個教練/顧問是個怎樣的人,是否言行合一,還是只是把「敏捷/scrum/lean」當作工作、商業上拿來賺錢的工具而已。
--
靠北工程師 原討論串 來源:https://www.facebook.com/init.kobeengineer/photos/a.1416496745064002/4100237950023188
同時也有10000部Youtube影片,追蹤數超過2,910的網紅コバにゃんチャンネル,也在其Youtube影片中提到,...
scrum guide daily scrum 在 矽谷阿雅 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