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
scrum 人數 在 Re: [請益] 主管工時都估太短- 看板Soft_Job 的推薦與評價
※ 引述《chatmonkey (打屁猴)》之銘言：
: ※ 引述《purin88 (原來我是憤怒的鄉民)》之銘言：
: : 唉，但工時估太短，就造成我不停的加班追進度，沒有六日、沒有晚上
: : 請問我該怎麼辦？
: : 還有更好的solution嗎？
推文有提到scrum,我也來討論一下
小弟在新創公司,開發模式導scrum
廢話就不講了
一次sprint需求會議16人,開兩三天(整個團隊
估工時要花兩天
我看我同事都估的短(主管會壓時間
我自己估還花心力看需求文件認真地估出來
也是估的短
每天daily meeting約40分鐘
進公司後一個小時,才能真正動工
也就是8小時的事,7小時要做完
導scrum真的好嗎?
daily meeting本意不是每天盯進度造成員工時程壓力吧?我不懂
而且什麼sprint google翻譯出來就是跑百米
跑百米是能夠讓人跑幾次衝刺幾次...
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 122.147.27.211
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1463840341.A.C69.html
... <看更多>