作者查詢 / oopFoo

總覽項目：發文 | 留言 | 暱稱

作者 oopFoo 在 PTT 全部看板的留言(推文), 共7107則

限定看板：全部

首頁

尾頁

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

[ Soft_Job ]188 留言, 推噓總分: +26

作者: oopFoo - 發表於 2024/07/26 12:14(1年前)

11^F→oopFoo: Linux Kernel就是很好的敏捷案例。APTON大的"安燈系統"比07/26 13:29

12^F→oopFoo: 我剛才想打的一串的好，精簡清楚。07/26 13:30

46^F→oopFoo: (顧客，pm，主管）決定功能，工程師決定時間與作法。07/26 19:35

47^F→oopFoo: 不過夢想很豐滿，現實很骨感。當壓力來的時候，加班，壓時07/26 19:36

48^F→oopFoo: 間，各種非敏捷的作法通通上來，能夠徹底執行敏捷的團隊還07/26 19:38

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

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

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

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

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

54^F→oopFoo: 也是見識少，看到的比較少。07/26 19:45

55^F→oopFoo: 敏捷真的就是人的互動才是重點，但人的互動真的是最困難的07/26 19:46

56^F→oopFoo: 課題。要願意信任也是個困難。07/26 19:48

62^F→oopFoo: 應該說敏捷是成功率比較高的方法，所有方法都有成功的機會07/26 20:08

63^F→oopFoo: 但敏捷迭代，多許多機會成功。07/26 20:10

64^F→oopFoo: 當初xp的團隊，是良好的團隊，但最後他們的案子是被取消的07/26 20:11

67^F→oopFoo: 因為Chrysler被Daimler-Benz買走，新東家有不同想法。07/26 20:16

69^F→oopFoo: 老實說，沒有研究。這都是我們觀察跟想當然爾的07/26 20:18

95^F→oopFoo: extreme programming系列的書，是一個好入門的書，它提倡07/27 06:26

96^F→oopFoo: test first，短時間的迭代，standup meeting，pair07/27 06:27

97^F→oopFoo: programming和如何計畫，都有很好的解釋跟緣由。現在的人07/27 06:29

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

99^F→oopFoo: 個很好的管理想法，雖然跟軟體有點遠。07/27 06:32

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

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

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

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

106^F→oopFoo: 次要的。正確的心態才是比較重要的。07/27 07:13

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

117^F→oopFoo: 問題一起pair，或帶新人大家比較願意做。07/27 08:01

118^F→oopFoo: 站立會議，檢討會議現在都太形式化了。開會是要了解跟檢討07/27 08:02

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

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

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

122^F→oopFoo: 照著教條做。07/27 08:10

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

157^F→oopFoo: 1)看團隊自己決定，2)人人有工作，3)隨時都是production，07/27 21:35

158^F→oopFoo: 4)每個人拿自己適合的工作，有問題在standup meeting就要07/27 21:37

159^F→oopFoo: 提出，如果還是不能解決，轉給可解決的人。如果無人可解，07/27 21:38

160^F→oopFoo: 看是要花時間研究，或放棄選另一條路走。07/27 21:39

161^F→oopFoo: code review完才算完成，但有的team不用code review。07/27 21:40

162^F→oopFoo: 進度其實是檢視，而不是要追求的目標。做不到，做不快，就07/27 21:43

164^F→oopFoo: 是砍功能。如何取捨，排進度，一門藝術。07/27 21:46

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

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

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

178^F→oopFoo: 開心做事就好了。謀事在人成敗由天07/28 07:18

[颱風] 凱米颱風解除颱風警報第28報

[ TY_Research ]401 留言, 推噓總分: +355

作者: Matthew10244 - 發表於 2024/07/26 08:27(1年前)

273^F推oopFoo: 謝謝馬修大07/26 12:19

Re: [情報] GN耶穌 AMD 9000 品質問題延後上市

[ PC_Shopping ]97 留言, 推噓總分: +35

作者: oopFoo - 發表於 2024/07/25 08:12(1年前)

2^F→oopFoo: 就出廠即灰燼。我現在都建議限制power在58.114.66.74 07/25 08:52

3^F→oopFoo: 230w左右。58.114.66.74 07/25 08:54

[情報] 英特爾終於宣布CPU崩潰錯誤的解決方案

[ PC_Shopping ]572 留言, 推噓總分: +234

作者: oopFoo - 發表於 2024/07/23 07:21(1年前)

2^F→oopFoo: 所以，性能還要再減幾%?58.114.66.74 07/23 07:25

[討論] AI模型討論

[ TY_Research ]102 留言, 推噓總分: +37

作者: oopFoo - 發表於 2024/07/21 21:46(1年前)

49^F→oopFoo: 現在對AI的期待太高了，AI是好用，但有它的侷限。07/22 06:33

50^F→oopFoo: 就像5年前的AI自駕，吹太高了，如果當初簡單07/22 06:36

51^F→oopFoo: 開始，只專注高速公路，也許現在早就有普及的自駕07/22 06:42

82^F→oopFoo: 問題是，要減少誤差，你需要多多少資料？減半是需要07/22 13:30

84^F→oopFoo: 多50%?多2x?3x?4x?。這幾個model都是用約40年的資料07/22 13:32

85^F→oopFoo: 來訓練。你要減半誤差，要多少個40年的資料？07/22 13:34

Re: [討論] 有公司使用到WASM技術了嗎?

[ Soft_Job ]24 留言, 推噓總分: +7

作者: oopFoo - 發表於 2024/07/06 04:00(1年前)

8^F→oopFoo: dotNet也只能用wasm的byteCode，JIT都需要wasm的vm處理，07/07 02:12

9^F→oopFoo: 主要是wasm的vm優化不足，c#的compiler的frontEnd在wasm也07/07 02:13

10^F→oopFoo: 算是簡易沒優化的。wasm的c#應該不是vm inside vm，07/07 02:44

11^F→oopFoo: wasm的限制很多，例如只有32bit，只有4GB的memory。vm的07/07 02:47

12^F→oopFoo: byteCode也是極精簡，不像java/dotNet。很多地方都需要再07/07 02:50

13^F→oopFoo: 打磨，延伸。WasmGC主要是延伸garbage collected object，07/07 02:52

14^F→oopFoo: 這樣Java/dotNet/python/....的gc語言可以跟Js互通，大幅07/07 02:53

15^F→oopFoo: 簡化互call的問題。07/07 02:58

16^F→oopFoo: wasm，webworker平台，因為安全性，與跨平台的限制，很多07/07 03:01

17^F→oopFoo: 東西需要修改架構，不是直間套用就可。但因為wasm vm的安07/07 03:06

18^F→oopFoo: 全性出發的設計概念，以後應該會普及到serverless的應用07/07 03:09

[討論] 有公司使用到WASM技術了嗎?

[ Soft_Job ]36 留言, 推噓總分: +10

作者: erspicu - 發表於 2024/07/02 01:52(1年前)

6^F推oopFoo: 你知道wasm跟js是怎麼互相call？資料怎麼傳？你這個要搞清07/02 06:17

7^F→oopFoo: 楚。wasmGC是用來解決一部份這類的問題。wasm你需要管理07/02 06:19

8^F→oopFoo: 記憶體，不然光是copy就吃掉一堆效能。而且wasm的compiler07/02 06:20

9^F→oopFoo: 本來就比java/c#差很多，效能差是正常的。所以不用c/c++或07/02 06:22

10^F→oopFoo: 直接wasm assembly，還要規劃好資料的傳遞，不然根本直接07/02 06:24

11^F→oopFoo: js+typedarray就好了。07/02 06:25

12^F推oopFoo: js的效能是非常好的，不要有錯誤的觀念。所以除非你的07/02 06:35

13^F→oopFoo: wasm程式規劃的很好，不然比js差是正常的。c#除非移植到07/02 06:36

14^F→oopFoo: wasmGC，不然高效能是很難的。07/02 06:38

15^F→oopFoo: https://web.dev/case-studies/google-sheets-wasmgc07/02 06:39

17^F推oopFoo: webgl/glsl來跑lanczos是最快，最簡單，相容性最好的方法07/02 06:46

18^F→oopFoo: webgl/glsl處理影像容易，程式也容易，只是入門難而已。07/02 06:47

19^F推oopFoo: https://stackoverflow.com/questions/5429945707/02 06:58

20^F→oopFoo: 從這篇追回去，你大概就知道怎麼做了07/02 06:59

[心得] NoSQL vs RDS 資料庫哪個適合你？七大面向深入比較

[ Soft_Job ]40 留言, 推噓總分: +9

作者: uopsdod - 發表於 2024/07/01 15:19(1年前)

10^F→oopFoo: 現在還有人推NoSQL?99%的情況選Sql才對吧。這篇重點沒抓到07/02 06:11

Re: [分享] 吞食天地2 同能網版正體中文化專案

[ Emulator ]15 留言, 推噓總分: +15

作者: ChampYen - 發表於 2024/06/06 00:52(1年前)

14^F推oopFoo: 辛苦了！！生日快樂！！06/20 11:57

[閒聊] Computex 2024之我的所見所聞(IC篇-完)

[ PC_Shopping ]30 留言, 推噓總分: +21

作者: Cubelia - 發表於 2024/06/18 14:52(1年前)

16^F推oopFoo: 感謝58.114.66.74 06/18 20:06

首頁

尾頁