作者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/cn.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