week 7 敏捷已經，死了
2021/9/8
沒跑過敏捷，學了很多 0-0
Scrum 分享
by KK
點數跟時間要分開
能跑 Scrum 跟老闆能不能接受有關，也許 kanban+瀑布流更適合團隊
團隊要不要導入，不導入要用什麼方式改善，跟團隊的每個個體有關。管理者要了解每個人的習慣、做事方式、個性，再試出適合的方法
卡片組成
誰做：一人負責一卡 （看公司，也有的公司會多人一卡）
點數
優先度 ：low/md/high/urgent
綁 gitfow pm 會加上註記要在哪裡修 eg. urgent+ 表示 hotfix
點數
投點階段團隊投票決定點數大小，評估依據是以大家站在團隊角度思考這張卡片對團隊的難度是多少
點數是 Scrum Master 用來評估 Scrum Team 產能的工具，跟工程師沒太大關係
工程師可能可以用點數來評估自己是不是進步了
每次衝刺 manager 會預計消耗多少點，但不是絕對，也可能會有遞延狀況發生，這些指標出現要去找 Scrum Team 產能變差的原因
工程師拿點效果不佳會在月以上的回顧討論狀況，但通常有問題會在 daily 就讓大家知道哪裡卡住，而不是到月結才發現拿點不佳
做超出點數的事情 refinement
自己提出，tech lead daily 決定要不要拆出來做或記錄一下補點數。但補點數跟工程師沒太大關係，工程師不應該一直想幾點，點數是 Scrum Master 的評估產能的工具
通常要跑十次以上的 team 才能穩定（point variant：團隊有做過？什麼叫難？）
點數與績效
variation point
好的績效
變異數小或穩定成長
回顧內有獨立完成難度高的卡片
Trello API 回顧自己的產值、公司的 release
估時
工程師在敏捷裡是不用管估時的，只要拿卡片跟做事，用點數來估時是管理職的事情
點數對工程師的意義只有：
Junior 可以跳過一些點數太大的卡片
個人做月/季回顧的參考
Retro
感恩讚嘆要不要拔掉，起碼要試過
其他
需求海
backlog/WIP/verified/...
REF
如果遇到面試時對自己的敏捷很有自信的招募者，問一下他的敏捷
一點要做多久 小時/天
每次 sprint 一個人要拿多少點
sprint 內沒有完成會怎麼檢討
拿多少點可以加薪
這些都是把敏捷拿來壓時程的危險警訊 >"<
Comment:
敏捷起義 2001 年由開發人員(工程師)發表的敏捷軟體開發宣言(The Agile Manifesto, 12條原則)，而這份宣言是基於這些開發者的過去經驗所統合而成的理想開發原則，看起來這分宣言是開發者(工程師們)的抗議，希望可以奪回產品開發流程的主導權—由開發者來決定開發流程。
這三篇文章在講的敏捷失敗 「敏捷」成功了，「敏捷起義」失敗了：敏捷變成一種管理工程師的方法，工程師並沒有奪回自己的開發流程(那一天，工程師終於回想起了曾一度被管理層所支配的恐怖)
Martin Fowler（17位敏捷宣言发起人之一）在其博客《2018年敏捷软件开发现状》中写的那样：“从表面上看，敏捷软件开发已经成为了主流，世界一片光明。但现实是令人不安的，因为其中大多都是假敏捷，无视敏捷的价值观和原则。”
在他们看来，敏捷是一种强加给他们的控制机制，而不是他们欣然接受的自我武装力量。但我希望围绕历史和最初的愿景展开一些讨论，帮助我们记住敏捷应有的发展方向。
Discussion:
敏捷失敗了嗎？
順著這幾篇文來看，敏捷精神好像滿失敗的，好像沒人在乎敏捷精神，許多想導入敏捷的團隊，好像也只是挑幾個敏捷方法論/框架執行，目的是要「管理工程師進度」。
為什麼敏捷精神失敗？
首先是「敏捷」太成功，如同這幾篇文所說，大家都覺得 fancy 想導入，但多數人聽到敏捷的時候並不是從他的精神開始聽到，而是先綁定了敏捷的方法/框架 (scrum,kanban) 跟結果 (自從我們導入敏捷開發，規格變彈性、開發的時間也變短了，連腰痛都減緩了，工程師們都很開心呢！)，所以對敏捷有誤會的預設
另外一個我覺得失敗的原因是因為他是原則不是方法論。公司很難導入原則，比較好導入一套方法。要懂敏捷似乎要順著脈絡去了解相關的一切，比較不同的敏捷框架，像在做學術研究一樣，但公司只想要一套有效率的方法，注定是把方法論拼拼湊湊弄出假敏捷。(然後光是讀 scrum 跟 kanban 怎麼操作就已經讀不完)
現在想想自己也看過不少網路上的「十分鐘學會」、「五分鐘讀懂」，變成現在這樣自以為懂(就跟REST一樣)，真的要有能力篩選閱讀資料 :P
Last updated
