Re: [討論] 關於敏捷越來越深入台灣職場

mercurycgt6807/26 12:22敏捷是快速取得回饋並持續改善 廢物公司只想快速結

mercurycgt6807/26 12:22案死不改善

kuosos52007/26 12:27你這樣講我勉強認同，唯一一個點，Rd主導開發，但

kuosos52007/26 12:27需求還應該給專業的處理吧，我想，jira真的超雷的

kuosos52007/26 12:27，slack還比較有用處

RX122607/26 12:31推, 真的大部分的scrum都是雷缺

APTON07/26 13:04給原PO:你應該是誤解了 "主導" 可參考"安燈系統"

abccbaandy07/26 13:14可用的軟體 重於 詳盡的文件 那可用是誰說的算？

Lordaeron07/26 13:18這樣是不用結案的概念。

LiebeLion07/26 13:26你說的是理論 他說的是現實

oopFoo07/26 13:29Linux Kernel就是很好的敏捷案例。APTON大的"安燈系統"比

oopFoo07/26 13:30我剛才想打的一串的好，精簡清楚。

alongalone07/26 13:46說得很好.下次可以直接用貼的.但沒有解決實務問題

Lordaeron07/26 14:05Linux kernel project 是agile? 給一下出處好吧。

MoonCode07/26 14:09員工痛苦股東才會爽

atst207/26 14:18@Apton, @原Po, 兩位的'主導'定義好像跟一般不太一樣?

atst207/26 14:18能否詳細說明一下，這裡的主導是只有出問題時停下來嗎?

atst207/26 14:19還是包括專案的成果評估，方向，業務目標在內?

MOONY13507/26 14:50大家都說不是敏捷，那那間公司跑的是真敏捷？

Lordaeron07/26 15:20按上方的定義：不用結案的公司。

ikimerr07/26 15:39國外公司都受不了被壓榨的工作模式，早就已經放棄敏捷開

ikimerr07/26 15:39發

ikimerr07/26 15:39就台灣人自己越來越盛行www

Lordaeron07/26 16:10咦...這個說法，給個出處好吧。

APTON07/26 16:14@atst2 如果以"做產品"的角度 當然是都要包含

APTON07/26 16:15不然最後遇到狀況，開發還是會回頭去問同樣的問題

APTON07/26 16:16但是大部分的公司都是分工不合作 各團隊的距離很遠

happy864907/26 16:50台灣老闆眼中的敏捷=你各位員工員工做快一點

fatb07/26 16:50怕加班的我把敏捷點滿了...還是繼續加班

tzouandy281807/26 17:38痛苦就不是敏捷？所以敏捷式宣言包含不能痛苦是不是

atst207/26 18:01@APTON, 這個"都要包含"的意思，是指第一線開發者還要兼職

hegemon07/26 18:02很多時候工程師的立場跟客戶就是相對的，這樣要怎麼玩下

hegemon07/26 18:02去？很多工程師以刪客戶需求作為自己的kpi. 這樣可以良好

hegemon07/26 18:02互動？

atst207/26 18:02PM, Market，客服，主管等任務嗎? 還是你有別的意思呢?

atst207/26 18:03還望更進一步提供說明.

hegemon07/26 18:06我看過太多太尊重工程團隊的公司，搞到最後就是沒有人可

hegemon07/26 18:06以叫他們做事

hegemon07/26 18:08PM, 客服, 主管, 客戶通通都不行，最後動用到創辦人下來

hegemon07/26 18:08盯場，但是在看不見的地方還是偷雞摸狗，客戶幹到翻天，

hegemon07/26 18:08這樣會比較好？

hegemon07/26 18:09理想當然是工程師能夠自律，能夠以幫助客戶解決問題為目

hegemon07/26 18:09標，現實就是自律的人太少了..給予工程師過大的自由跟權

hegemon07/26 18:09限就是什麼事都做不成

yuinami07/26 19:26推

oopFoo07/26 19:35(顧客，pm，主管）決定功能，工程師決定時間與作法。

oopFoo07/26 19:36不過夢想很豐滿，現實很骨感。當壓力來的時候，加班，壓時

oopFoo07/26 19:38間，各種非敏捷的作法通通上來，能夠徹底執行敏捷的團隊還

oopFoo07/26 19:38是少。而且敏捷最重要的是所有人都須認同也配合，這也是不

oopFoo07/26 19:40容易的。沒有良好的團隊，或者強力溝通能力的主管，敏捷不

oopFoo07/26 19:41容易執行也不容易成功。這有點像社會主義，理念良好，但常

oopFoo07/26 19:43常淪落到獨裁者模式。敏捷是需要上面的人全力支持，加上所

oopFoo07/26 19:44有人的配合才行。國外我看到成功的案例比較多，台灣可能我

oopFoo07/26 19:45也是見識少，看到的比較少。

oopFoo07/26 19:46敏捷真的就是人的互動才是重點，但人的互動真的是最困難的

oopFoo07/26 19:48課題。要願意信任也是個困難。

atst207/26 19:54@oopFoo，如果一個方法論，需要依賴人的素質，才會有用, 這

atst207/26 19:55個方法論能稱得上是方法論嗎?

atst207/26 19:56反過來問，有沒有案例是，有良好的團隊但不走敏捷，所以失

atst207/26 19:56敗，改用敏捷後就成功了?

atst207/26 19:58還是只要有良好的團隊，不論走不走敏捷，其實都無所謂呢?

oopFoo07/26 20:08應該說敏捷是成功率比較高的方法，所有方法都有成功的機會

oopFoo07/26 20:10但敏捷迭代，多許多機會成功。

oopFoo07/26 20:11當初xp的團隊，是良好的團隊，但最後他們的案子是被取消的

atst207/26 20:15關於方法論是否影響產出，NDark網友有提出 #1MWgps7K

atst207/26 20:16那您這邊提到'成功率'比較高，是否也有研究可以參考呢?

oopFoo07/26 20:16因為Chrysler被Daimler-Benz買走，新東家有不同想法。

atst207/26 20:17在您繼續回覆，我先提一下個人對Agile/Scrum/Lean的想法，

oopFoo07/26 20:18老實說，沒有研究。這都是我們觀察跟想當然爾的

atst207/26 20:19個人覺得敏捷以及相類似的方法論，其實是有一定道理的。

atst207/26 20:20但個人一直覺得，這些方法論，很多還只是理論, 而非定理.

atst207/26 20:21從理論到落實一直有很大的落差，而這些落差，目前看不到相

atst207/26 20:22關推廣的人，有想去填補的努力在，而一直是不斷強調理論有

atst207/26 20:22多美好.

atst207/26 20:23也許有團隊/研究已經在努力了，但個人見識有限，無法知曉.

atst207/26 20:25在這種情況下，去指稱某些公司跑的是'假敏捷'，敏捷"不是"

atst207/26 20:26什麼，是沒有意義的。因為對於想要進入"敏捷"，享用到好處

atst207/26 20:27的團體而言，他們想要知道的是，彌平理論到實作間的落差的

atst207/26 20:27手段。

nathanlu07/26 20:30敏捷好棒棒，每間都說在跑敏捷，需求完成率很高

atst207/26 20:33如果沒有這個手段，而只能依賴團隊人員素質的話，老實說,

atst207/26 20:33與其引入敏捷，不如去增進HR團隊的能力還比較實際一點。

Lordaeron07/26 21:16我做上百個大大小小(錢)的案子，人員倒是沒有哪些一百

Lordaeron07/26 21:17幾十的案子。但三五七個倒有。就是沒有方法論。

Lordaeron07/26 21:17但全部準時收錢。

Lordaeron07/26 21:18數學解題，就是從基本的去解就是好的方法。哪些什麼特

Lordaeron07/26 21:19解，遇到某類題目有專門快速的解法，就是爛解法。

howdiee07/26 21:41只能說牽扯到人的理論在實際上就是會有落差

Lhmstu07/26 21:47台灣文化融合的敏捷等於快速結案

Lordaeron07/26 23:20很多人都認為，用了某某方法，我也可以做出一樣的系統.

Lordaeron07/26 23:22正如看著菜譜，人人都是大廚的概念。

viper970907/27 00:03推atst2

fantasystar07/27 02:35Ron 讓我學到很多，感謝分享

fantasystar07/27 02:36*Ron的文章

oopFoo07/27 06:26extreme programming系列的書，是一個好入門的書，它提倡

oopFoo07/27 06:27test first，短時間的迭代，standup meeting，pair

oopFoo07/27 06:29programming和如何計畫，都有很好的解釋跟緣由。現在的人

oopFoo07/27 06:31使用敏捷大部分都不了解背後的緣由。toytota way，也是一

oopFoo07/27 06:32個很好的管理想法，雖然跟軟體有點遠。

oopFoo07/27 06:39好的團隊是需要時間去互相磨合，也不是hr找對人就可以的。

oopFoo07/27 06:40所以敏捷第一條就是"個人與互動"。這真的是最難的課題。

notimenofree07/27 06:57Jira只是工具 雷在哪

notimenofree07/27 06:57錯的是用的方式吧

oopFoo07/27 07:09最後我想強調的是，敏捷強調的是心態。但理工人喜歡方法，

oopFoo07/27 07:11想找SOP，想找工具來解決問題。敏捷宣言就是想告訴你那是

oopFoo07/27 07:13次要的。正確的心態才是比較重要的。

lchcoding07/27 07:45我看得少.如果 Debug 和帶新人

lchcoding07/27 07:45不算的話.pair programming 我沒看過餒

lchcoding07/27 07:45兩位程式設計師，寫一份碼

lchcoding07/27 07:45不吵架，可能嗎？

lchcoding07/27 07:45（當然，平常就是用嘴巴寫程式

lchcoding07/27 07:45那種不討論）

atst207/27 07:50我懂了，敏捷就是宗教。站立會議就是早晚課，檢討會議就是

atst207/27 07:50發露懺悔。每次迭代都是一個輪迴。好好照著做就可以成佛。

atst207/27 07:50不成的話，就是心態不正，信仰不足。持續做下去就對了。

oopFoo07/27 07:59pair programming很少見，大部分人不願意試，主要就是困難

oopFoo07/27 08:01問題一起pair，或帶新人大家比較願意做。

oopFoo07/27 08:02站立會議，檢討會議現在都太形式化了。開會是要了解跟檢討

oopFoo07/27 08:06程式問題。其實兩三個人一組，不要超過五六個人參與，簡短

oopFoo07/27 08:07結束。當變成形式的時候，就是要換個方法做。可惜，現代管

oopFoo07/27 08:10理，無法從SOP跳開。敏捷就是團隊要找出適合的方法，不需

oopFoo07/27 08:10照著教條做。

z2277118707/27 09:35國外立意良好的東西進到台灣後都會歪斜

NDark07/27 09:46pair要好好分組訓練 因為這種新制度在學校職場都沒教

NDark07/27 09:46新制度的引入就跟新機器一樣要有教學

Csongs07/27 10:11敏捷很容易壓榨啊 那個宣言都是強者 敏捷就是很多強者一起

Csongs07/27 10:11合作 不會掉棒

Csongs07/27 10:13不欣賞工具這段還是怪怪的 抓戰犯用excel管也能抓

tzouandy281807/27 10:14信奉敏捷式的人都沒有拿研究或數據佐證 只會說你成

tzouandy281807/27 10:14效不彰就是沒有敏捷/不夠敏捷 論述充滿不可證偽性

oopFoo07/27 10:53excel的好處是，pm花時間填資料就沒那麼多時間騷擾工程師

internetms5207/27 12:18jira是工具，不會扭曲流程，如果流程有問題，不能

internetms5207/27 12:18怪jira

internetms5207/27 12:21jira也可以不壓時間啊，是用法問題

NDark07/27 12:25某種敏捷有一條規則是"成員都是專家" 而且都假設是全端的

labbat07/27 12:55須符合真空狀態下，且專家是球體的時候才有效

sCHb6807/27 13:57預估根本不準，不然就不會不做不知道一做嚇一跳了，

sCHb6807/27 13:57待過某家公司，就是把預估當成是設定，

sCHb6807/27 13:57一個spint一定要完成，拖延到的話PM還會很不爽。

lylu07/27 14:04我還遇過直接把planning 的點數當成kpi的呢

APTON07/27 16:32嗯...果然根本沒有打算討論，只是想趁機偷酸，還好沒浪費時

APTON07/27 16:32間回覆

kckckckc07/27 17:54真的，還遇到一個連規格都不會開的在那一般說要導入敏

kckckckc07/27 17:54捷xD

Ghamu07/27 18:41覺得問題點在於1. 團隊了解敏捷開發是什麼？ 2. 團隊要知道

Ghamu07/27 18:41怎麼執行？ 3. 上頭有權力者要相信 了解 決心推動敏捷開發

Ghamu07/27 18:44不懂 執行的不是敏捷 沒有權力只能推半套 都會爆炸

Ghamu07/27 18:46想想人也是很重要的 只有工具也是不可行 再好的工具遇到錯

Ghamu07/27 18:46的人 不去用或是用錯也是白搭

Lordaeron07/27 19:10AGILE的專家們，請問AGILE 在最開始前，要先寫一些底

Lordaeron07/27 19:11層的東西嗎? 要架環境嗎? 要的話，要算進sprint?

Lordaeron07/27 19:12會人人都有工作? 還是只有某幾位負責?

Lordaeron07/27 19:13再來，何時on production? 按國外大神的說法，沒提到呢

Lordaeron07/27 19:13若成員的程度差異，導致他的工作無法如期完成，會不會

Lordaeron07/27 19:14大家都完工了，還要等他? code review 會算進sprint?

Lordaeron07/27 19:14review 後的modification 要算下一個sprint?

oopFoo07/27 21:351)看團隊自己決定，2)人人有工作，3)隨時都是production，

oopFoo07/27 21:374)每個人拿自己適合的工作，有問題在standup meeting就要

oopFoo07/27 21:38提出，如果還是不能解決，轉給可解決的人。如果無人可解，

oopFoo07/27 21:39看是要花時間研究，或放棄選另一條路走。

oopFoo07/27 21:40code review完才算完成，但有的team不用code review。

oopFoo07/27 21:43進度其實是檢視，而不是要追求的目標。做不到，做不快，就

s06yji307/27 21:44待過4個團隊，沒有一個agile是跑到起來的XD

oopFoo07/27 21:46是砍功能。如何取捨，排進度，一門藝術。

atst207/28 00:22#170rfWYy 這是我的舊帳，在2007年的文章.

atst207/28 00:23#1I7R-qV6 這是2013年，我在介紹Lean Programming相關書藉

atst207/28 00:29然後在2024年的今天, Agile的傳道士們, 沒有證據，沒有研究

atst207/28 00:29面對我提出的問題，把一切都歸結到心態上, 最後再指責有人

atst207/28 00:30藉討論之名暗酸?

atst207/28 00:30你們是不是真的以為，所有意見不同的人，都沒有跑過敏捷

atst207/28 00:32沒有在相關領域，花費時間精力，也不知道安燈, toyota是怎

atst207/28 00:32麼回事?

atst207/28 00:34面對他人的質疑，你們的回應有符合敏捷宣言的第一條嗎?

tzouandy281807/28 03:44不知道為什麼敏捷式開發要搞得像宗教信仰

oopFoo07/28 07:10還是要講心態很重要。上司，顧客就是隕石，流星雨的需求，

oopFoo07/28 07:14不管怎麼敏捷都沒用。能夠抵抗隕石的需求是第一個關鍵，溝

oopFoo07/28 07:16通再溝通，沒其他法子。就算所有都作對了，也不保證成功，

oopFoo07/28 07:18開心做事就好了。謀事在人成敗由天

Druid07/28 10:42推 我們team算是一個成功的敏捷範例 我認同這篇內容

Druid07/28 10:43敏捷跑得好 應該是大家都輕鬆 客戶也開心 但是要跑得起來

Druid07/28 10:45需要超罩的主管+自律的工程師 人力素質PR95以上

Druid07/28 10:47這真的非常不容易 所以失敗的敏捷居多

jacklin200207/28 18:27加班過勞死的工程師轉生到異世界開始研究敏捷開發

v8686106207/29 16:41推推