作者alihue (wanda wanda)
看板Soft_Job
標題[討論] 因為 chatGPT，未來瀑布式開發會是主流?
時間Sun Apr 16 21:32:10 2023
現在一大堆針對 chatGPT 提問的 prompts
恰恰說明只要給的指令夠精確他就能做事
而瀑布式開發雖然近年被唾棄，但它的一大特點就是一開始就會有盡可能明確的規格書
尤其是接案產業為了驗收標準，幾乎定規格時連 schema 與流程圖都會有
優質一點的甚至附畫面以及定義每個互動的 input 與 expections
這種有明確的 test cases 正是 chatGPT 的強項
所以我猜測最快產生的取代工程師的情景:
1. 從 0 到 1 的專案，因為 chatGPT 不用了解現有系統
2. 瘋狂 CRUD 型的專案，例如內部系統，較少外部不明確 Dependencies
達到這步之前 chatGPT 需要先可以針對 spec 模糊與矛盾之處提問，
但目前的技術傾向於硬給解答，不曉得有沒有辦法改進
然後會產生操作 chatGPT 工程師需求，專門寫給 chatGPT 看的 spec/test cases
以及針對產出的 source code 微調與 QA 後交貨
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 106.73.26.66 (日本)
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1681651932.A.2F5.html
※ 編輯: alihue (106.73.26.66 日本), 04/16/2023 21:33:51
1F：→ foreverk: 你忘了這類公司的問題就就在於不寫spec或文件，或是只 04/16 21:35
2F：→ foreverk: 寫驗收交差用的，gpt時代他們還是一樣啊XD 04/16 21:35
接案公司還是有吧，不然怎麼簽合約開始開發，與驗收的參考基準?
※ 編輯: alihue (106.73.26.66 日本), 04/16/2023 21:37:01
3F：→ foreverk: 合約文件寫的是最模糊的那種，最多就是驗收階段文件會 04/16 21:41
4F：→ foreverk: 慢慢補上去，但驗收的項目跟一開始的spec大部分也不相 04/16 21:41
5F：→ foreverk: 同了 04/16 21:41
但其實也是我文中提到的，如果 chatGPT 有辦法針對需求模糊的地方提問來增進 spec
那就會很有幫助
6F：推 hegemon: 瀑布流跟敏捷各有其適用的場景 04/16 21:42
※ 編輯: alihue (106.73.26.66 日本), 04/16/2023 21:44:08
7F：推 NodeWay: 你想多了 接案一樣需求會在開發前後持續修改 04/16 21:52
8F：推 NodeWay: 你說的完善spec 但多數場景連客戶自己都不清楚他要什麼 04/16 21:57
9F：→ NodeWay: coding只佔軟體開發非常小的比例 而AI目前只加快了這小塊 04/16 21:58
10F：→ alihue: 所以我文中才說需要 chatGPT 能回頭釐清問題 04/16 21:58
11F：→ foreverk: 被樓上說完了XD接案本質上就是通靈，簽約的高層跟使用 04/16 22:00
12F：→ foreverk: 系統end user認知差距很大，而user大部分真的不知道自 04/16 22:00
13F：→ foreverk: 己要什麼，所以要應用在spec文件比較難，用在test case 04/16 22:00
14F：→ foreverk: s比較有機會 04/16 22:00
15F：推 wei115: 客戶連他自己想要什麼都不知道 要怎麼寫規格？ 04/16 22:03
16F：推 NodeWay: 所以才說通靈 有時候就是一些敘述而已你就要開始開發了 04/16 22:07
17F：→ foreverk: 合約只會寫建置xxx系統，要符合什麼法規，驗收要哪些單 04/16 22:11
18F：→ foreverk: 位，其他內容要嘛接案公司本來就是深耕客戶產業的，知 04/16 22:11
19F：→ foreverk: 道要幹嘛再依照客戶調整，不然都是要pm ba去一直開會問 04/16 22:11
20F：→ foreverk: 出來後，交給開發團隊開發 04/16 22:11
21F：→ foreverk: 最常見的就是依照客戶提出的case去寫測試，然後才發現 04/16 22:14
22F：→ foreverk: 有很多邏輯牴觸之處，最後幫客戶查出以前做法有錯帳， 04/16 22:14
23F：→ foreverk: 接著系統驗收項目就會憑空出現一個調帳功能，沒完成不 04/16 22:14
24F：→ foreverk: 撥uat驗收款 04/16 22:14
25F：→ foreverk: 那gpt能幫助的就是，快速完成各種test case提早發現客 04/16 22:17
26F：→ foreverk: 戶的商業邏輯有問題趕快改，或是乾脆問gpt遇到這種客戶 04/16 22:17
27F：→ foreverk: 該如何不追加驗收項目就通過驗收（？） 04/16 22:17
28F：推 viper9709: 推接案本質上就是通靈XD 04/16 22:47
29F：→ shomingchang: 等chatgpt能出來撕逼再說吧 04/16 22:52
30F：→ shomingchang: 敏捷就是為了撕逼輸的時候 頻繁改需求才出現的 04/16 22:53
31F：噓 anhpc: @foreverk 04/16 23:12
32F：→ superpandal: 噗 04/16 23:23
33F：推 Mike1109: 除非gpt會通靈XDD 04/17 00:15
34F：推 eeyellow: 連客戶都不知道自己要什麼商業邏輯，你要GPT通靈? 04/17 02:04
35F：推 mozume: 我的想法是反過來，gpt是幫助寫完結案所需文件，文件能自 04/17 07:29
36F：→ mozume: 動從程式自動不斷修改 04/17 07:29
37F：→ KAOKAOKAO: 良好的文化不是不能根基於瀑布模型 但成功的關鍵仍在於 04/17 07:54
38F：→ KAOKAOKAO: 即時的回饋與修正 這不是任何初期的精確能夠解決的 04/17 07:54
39F：→ KAOKAOKAO: 前期精確就是中後期的僵硬 AI介入輔助也不能改變這點 04/17 07:55
40F：推 jej: 你想多了 多的是scrum誤用成瀑布式的 04/17 19:34
41F：→ jej: 再加上需求變更在專案中本來就很常見 04/17 19:34
42F：→ jej: 定義上完成最小價值產品 還是使用者的偏好 04/17 19:34
43F：→ ikachann: 一堆公司都不寫文件或是文件跟成品落差很大沒更新的吧 04/17 20:01
44F：推 Csongs: 想法蠻有趣的耶 04/17 20:33
45F：→ DrTech: 呵呵，每篇都在用GPT通靈。 04/18 07:12
46F：→ DrTech: waterfall,的問題又不是在寫規格書，waterfall也沒有硬要 04/18 07:14
47F：→ DrTech: 人寫完整的規格書。 04/18 07:14