作者查詢 / Feis
作者 Feis 在 PTT 全部看板的留言(推文), 共2002則
限定看板:全部
看板排序:
全部C_and_CPP1648Soft_Job86b93902HW60Web_Design42GameDesign35NTU_BOTDorm18b96902HW14Dart14Kinmen13b90902xxx12MATLAB8Monkeys6NTU-Guitar6b92902xxx4b94902xxx4CSCamp20044CSIE_TTENNIS3CSCamp20022CSCamp20092HCKuo2MedRock2Python2ACMCLUB1ask1Baseball1bass1C_Sharp1Chan_Mou1Jacky1Jinmen1LoL1mrsthis1PDA1Programming1PttCurrent1Tech_Job1TOEIC1<< 收起看板(37)
43F推: 能從興趣堅持到找到工作真的不容易,恭喜!01/10 01:53
1F→: 想成 Unity只是做前端介面,做資料的 prepocessing。其他都09/30 18:53
2F→: 丟到常用的工具算就好09/30 18:53
9F→: 用 C 寫 LeetCode 的話,如果不要求一次過的話,個人經驗是07/09 07:37
10F→: 不會特別難。只是看目的07/09 07:37
11F→: 比較麻煩的主要是 I/O 處理07/09 07:38
12F→: 但剛好 LeetCode 比較少這問題07/09 07:39
1F→: 直覺就窮舉,接著遞迴分治,然後動態規劃11/16 00:38
6F→: 所以是溝通的『起點』。會讓不會寫的人估不是偶然07/24 23:18
7F→: 人事時地物都可能影響估計的結果,但是不代表估是錯的07/24 23:19
8F→: 拿來壓榨就只是工具使用錯誤07/24 23:19
13F→: 如果你認為讓資深的帶真的就沒問題,那為什麼不提看看?07/24 23:25
14F→: 每個專案組織的權力結構不同,組織的運作不是偶然07/24 23:26
15F→: 但也不是必然。正常情況下沒人想期待專案失敗07/24 23:28
16F→: 我個人的信仰是比較接近敏捷的,所以我理解與許多人價值不同07/24 23:32
17F→: 最近有分享一些粗淺想法,請參考: https://reurl.cc/RNdrz07/24 23:35
19F→: 不是很確定樓上的意思,也許我們要先定義意義的是什麼 XD07/25 00:31
20F→: 從另一個角度來說,應該說誰能真的知道東西『完成』了07/25 00:32
21F→: 也許這輩子都沒有『完成』的一天?07/25 00:33
25F→: 我自己想法努力的讓專案越早關越好,不止維護分開,甚至原07/25 11:57
26F→: 型跟產品開發階段都可以分成多個階段,才能聚焦需求保持品07/25 11:57
27F→: 質07/25 11:57
29F→: 而怎麼讓專案越早關的方法很多,改需求也是一種07/25 11:59
30F→: 聚焦在可完成的需求跟可接受的品質下盡早產生產品獲得回饋07/25 12:07
13F→: 不認同,預估工時跟品質當然有關07/24 12:15
17F→: 如果連明天能不能上架都無法預估,真不知道怎麼做專案…07/24 13:12
18F→: 見識太少,尊重你的看法07/24 13:14
26F推: 「預估時間對品質,我認為沒有幫助」這中文理解有障礙07/24 22:27
27F→: 我有說要放棄其他方法嗎07/24 22:27
28F→: 我只是不認同沒幫助這件事,沒幫助還是要做,所以就是有幫助07/24 22:28
29F→: 呀07/24 22:28
30F→: 這邏輯……07/24 22:28
31F→: 軟體專案以人為本,預估時間也是個工具,政治手段也是個工07/24 22:31
32F→: 具,不要以偏概全07/24 22:31
33F→: 抱歉,一開始就不應該回應…07/24 22:34
35F→: 是的,我們都在做沒幫助的事。我猜原作者的論點不是這方向07/25 00:36
36F→: 我原本的認知是要透過測試稽核之類的去決定狀態07/25 00:38
37F→: 而測試稽核不是建立在預估工時上是我原本以為的論點07/25 00:39
38F→: 我自己的論點是,短期的預估工時是無可避免的07/25 00:40
39F→: 而預估工時是個工具,工具有好有壞,有用對有用錯07/25 00:41
42F→: 了解,所以現在主題變成為什麼要做沒幫助的事 ?07/25 00:43
44F→: 是嗎?如果完全沒辦法預估工時,你怎麼決定什麼時候稽核?07/25 00:44
46F→: 我能理解有更上層的問題,但是這篇的意思就是『預估時間對07/25 00:46
47F→: 品質沒有幫助』07/25 00:46
48F→: 可以指教一下嗎?07/25 00:46
49F→: 我只是對這點表達不認同07/25 00:47
50F→: 『估不準不會死』我也認同,要估六次十次我也認同07/25 00:57
51F→: 那結論不就是要嘛做這些事與品質無關要嘛有關07/25 00:58
52F→: 原作者論點是『無關』,但我無法認同而已07/25 00:58
53F→: 抱歉糾正,是有沒有幫助07/25 00:58
54F→: 如果『沒有幫助』卻又要『做』的邏輯是什麼,需要有人指導我07/25 00:59
55F→: 我想表達的是工具本身是中性的,使用工具的人才是問題07/25 01:05
56F→: 不要因為人的問題就去說工具沒有用07/25 01:05
57F→: 而工具有學習成本有使用風險,這些都是專案管理要考量的07/25 01:08
58F→: 挑適合的工具給適合的團隊創造適合的文化07/25 01:28
59F→: 才是專案管理者該走的路跟價值 (當然是我自以為07/25 01:31
72F→: 了解,可能是大家對品質的定義不同。可能是我誤解,謝謝07/25 09:08
73F→: 沒有氧氣會死,所以飽足跟氧氣無關。可能是這邏輯我誤會了07/25 09:10
74F→: 我原本以為是不需要預估時程也可以確保品質。07/25 09:10
75F→: 每個人對專案品質的定義不同,打擾大家了 QQ07/25 09:11
79F→: 所以規劃不需要預估時間的意思嗎,我越來越混亂XD 當然不用07/25 09:50
80F→: 神準07/25 09:50
82F→: 照這意思是產品設計時不考慮做不做得完,那我就完全理解了07/25 10:05
83F→: 感恩07/25 10:05
85F→: 我沒誤會,我以為品質是建立在有做完產品的前提07/25 10:14
86F→: 是我誤解品質,抱歉07/25 10:14
87F→: 這產品品質很好只是沒做完,我以為這不是前提的07/25 10:16
88F→: 我不覺得獨立比較好,不過尊重你論點07/25 10:20
89F→: 加速上市不一定要犧牲品質07/25 10:20
90F→: 不過還是回到品質的定義問題,是我誤會。07/25 10:21
91F→: 了解,我那句並不是要否定。抱歉07/25 10:24
2F推: 推07/10 15:35
2F推: 右移?04/28 09:08
1F→: 在建構時傳進去就好,範例有: http://bit.ly/2VRHqvR fifth04/18 18:39
2F推: Delete04/16 14:08