这篇博客讲述了作者从早期遵循详细需求规范（FS）的瀑布模式开发，到后来采用敏捷方法进行复杂项目开发的转变。作者分享了一键操作平台的开发案例，强调在面对甲方不断变化的需求时，快速迭代和灵活应对的重要性。文中提到了与业务顾问的高效合作，并讨论了在没有完整FS的情况下如何处理复杂的业务逻辑和接口集成。博客还包含了多个与软件开发相关的调试、项目管理和技术实践的推荐阅读内容。
看到群里聊到什么敏捷开发 瀑布模式之类的，
国外一哥们提到的很多观点挺好的。
我记得最开始入行的时候确实是，让业务顾问提供一份很详细的FS，然后我就按照FS做就行了。那会儿一方面是给我的需求都比较简单，另外我水平也不高，只能这么做。
尤其是理想的项目，有些业务顾问很牛，一些调整修改之类的，FS上连哪个程序修改第几行都给了，甚至都能给出代码。
随着资历增长，慢慢的肯定就不会只做一些简单需求，不会只是一个简单的修改，一个简单报表一个简单增强之类的。
可能就是一个完整的需求需要你一个人完成。
比如我四年之前吧 做的SD的平台。
客户要求的是一键操作，就是点一下按钮把整个流程全部跑完。
涉及了一些接口接收数据及反馈 推送第三方，还有一部分是走批导。
中间还涉及了不少增强 和自定义的其他东西。
另外任何一步可能出错，监控以及出错后要有重处理。
这个东西，其实真的是很恶心，但是甲方要求了，拿人钱财替人消灾，至于合理不合理，人家要，就得给。
这个东西是我开发的，业务顾问是老王和小强。开发用了一个月。
涉及接口接收 推送，基本功能正向反向实现，初始化导入，批导，批量调整修改，监控平台。
后面还有点儿财务的东西。
这个东西开发完我都没怎么看过FS，我跟老王坐一起，老王口头说，我来写，写的过程中遇到问题随时找老王，写完一部分让老王测一部分，然后我再做后面的需求。当时项目压的太紧了。
老王懂代码，我略懂业务，配合的相当默契。
第一版很快就出来了，剩下的就是改部分bug，处理特殊情况。
还有就是甲方突然说的公司有啥特殊是情况，
什么可以这样也可以那样，好吧……
坑反正也已经挖下了，无非是多挖一铁锹的事儿。
其实MMSD的还好，算是比较简单的。
还有一些PP APO 啥的，更乱七八糟的。那个更恶心，
哦还有EWM的，一整套功能，哎……
财务的合并报表，自开发的合并报表。
说起来，这些坑都快把地球挖穿了。
没办法，谁让金主要呢？
一旦功能复杂了，不可能会有完整的FS，尤其是国内的项目，一份晚上的FS得需要多久？
复杂功能有个大概就行了，先把基本功能实现，再去补充特殊逻辑。
最初就提供一份完善是FS真的就跟第一版代码就不许有bug一样。
不合实际。
完成最基本的的，修复bug，补充特殊逻辑，修复bug……
周而复始。
最后补一张图，嗯，大家都懂的……
推荐阅读：
《苏州游记》
《溜达：无锡》
《杂谈：几种接口》
《RESTful DEMO 一：SAP 如何提供 RESTful Web 服务》
Debug 系列
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
