不论何种开发模式，只要能够满足开发需要，低成本达到满意的开发目标，就是好的开发模式，无论其名字叫瀑布式开发，或敏捷开发，异或是无名的模式。
低成本达到满意开发目标的前置条件
软件开发的一个特点是边际成本低，当然前提是正常开发没什么问题的情况下，而达成这个目标一般来说有两个方面的影响，一则是人，一则是技术。
人往往是一群人，是一个技术团队，这群人被什么样的人领导，又是什么样的人在执行，对开发目标的实现影响甚大。
领导是否愿意听取下属意见，是否有自己的谋划，是否能够让下属信服，是否愿意为下属承担一定的压力，这些很大程度决定了一个团队的做事风格。优秀的团队领导一定是有担当，有主见的，差的团队，领导一般是有问题的，正所谓，其身正，不令而行，其身不正，虽令不行。
骨干员工是否具备足够的技术能力以支持团队目标的实现同样尤为重要，如果技术水平达不到一定的高度，无法覆盖目标所需，一样没法很好地达成目标。而普通员工，我认为在软件行业里，非常重要的一点是不要帮倒忙，你创造不创造价值还是其次，帮倒忙的特别损害团队。
这里所谓的帮倒忙，往往披着的是努力、上进的外衣，你见他天天加班，你见他积极领取工作，可是他的产出不是影响这，就是影响那，你还不好说人家什么，毕竟对方也是“好意”。这类人往往能力不够，工作意愿却很强烈，遇到这样的人还是要稍加注意，给予合适的项目让其成长后再好好发挥（若无法成长，不如及早“割爱”）。
当然，好的团队除了上述因素外，还要能够“和”，各部分之间能够互相信任，能力相当是最好的，当然这个太过理想了，能相互信任都已经不错了。
所谓的相互信任，往往出现在不同类型团队之间，比如产品与开发，开发说2周，产品说我下周就要上线，且没有可谈的空间，这就是不和。若产品和开发相互信任，不必多说，你说几天就几天，实在着急的需求，咱商量一下，互相做个妥协，而不是一味强调自己是正确的。
再来谈谈技术
搞软件项目与做别的工程项目也是相通的，比如汽车来说，需要考虑整车架构，底盘车架的设计，也要考虑内部装饰的设计，大致来说可以分为宏观和微观两方面。
宏观来说，考虑的是体系化、系统职责、系统关系、发布部署、开发管理过程等，其核心目标是建立一个立体的能够让团队持续高效运转的机制；
微观来说，更多考虑的是具体业务功能的设计，代码层面的管理与维护，其核心目标是保障项目落地实施的质量；
技术能力的高下，决定了很多问题，包括但不限于目标是否能够实现，成本是否可控，软件是否可持续维护，所以一个团队能否选择一个合适的，能够匹配项目目标的技术非常之重要；
就身边真实的案例，过度微服务，系统拆得很碎，但却没有掌握微服务的精髓，只是浅浅地认为拆成多个系统即是微服务，数据共享仍然是同一个数据库，同一个Redis，外部的请求可以打到任意一个系统里，所有服务的接口又是集成在一个jar包内；系统复杂度增加，可维护性下降，对外口子也收不住，人么总是不够用，所以这个系统也经常出问题。
那么一般我们如何去做软件工程？
一般来说，软件系统从目标的制定，到上线，以及后续维护，一般会经历立项、需求、分析、设计、实现、测试、上线等过程。那么阶段性的功能开发也同样会经历上述过程，无非是哪些过程被简化，被合并到同一个人内部消化，异或直接省略。所谓的敏捷开发，或其他开发方法名称，也都是对上述过程的某些方面进行加强或简化。
敏捷开发，侧重在快，期望通过快速迭代，让开发手上的工作及时呈现在用户面前，以期达到提前交付的可能；
而传统某些开发模式，可能侧重在稳字，不求功能快速实现，但求不要在现有功能上发生问题，或上线尽可能避免新的问题出现，用户对交付时间并不敏感，甚至对交付质量也不敏感，只要能用就行；
不同的开发模式，有其适用的场景，本身并无问题，但敏捷开发之所以被人诟病，其很大原因在于只学了敏捷的外形，而未学到敏捷的精神。
敏捷的精神就一条，即：小步快跑，快速迭代。但其背后有一条隐形的前提条件，却常常被人忽视，即再小的步，再快的迭代，他首先得是正确的。
有人可能会说，快速上线，出了问题，快速修掉就行了，也并不是不可以，如果一个团队频繁上线出问题，频繁hotfix，那么这就已经失去敏捷的意义的，毕竟上线前和上线后处理起问题来，并不是一个成本。
当然一两个人，测试、生产，开发、运维全包的团队你们爱怎么整怎么来，不在本案讨论范围内！
敏捷的外形很多，user story、sprint、CI、TDD、任务面板、每日站会、计划会议、评审会议、回顾会议、需求池…所有这些构成了一整套的敏捷开发理论和实践。如果这些过程都在服务于小步快跑，快速迭代，自然不会有什么问题，但实际应用过程中出现为了敏捷而敏捷的情况。
每日站会必须要吗？如果团队规模不大，就几个人，所有事情自己心里有数，开什么站会，除非有别的目的；
别的目的也可以有，不是说绝对不能开
一定要定期开代码评审会？非也，如果团队开发质量可以，平日里有互相检查Merge Request的习惯，或者其他情况以保证代码上线基本不出问题的，那为什么要开会？还非得搞到晚上开？
一般代码评审有两类，一类是日常小需求迭代开发，此类代码评审日常工作中看下Merge Request就差不多了，即使有些问题，下个迭代也可以调，而一些复杂的，大块的系统，特别是从0到1建设的系统，则需要代码拉下来，从头到尾，细细查看，有问题直接改掉，或者标记让作者自己改，真的也不太需要开会大家一起看，关心的人自己会看，不关心的人开会也不会提什么意见，何必为难大家！
凡此种种，无法穷举，觉得敏捷就该有敏捷的那些过程，以及引进敏捷相关的软件系统，必须让开发按照敏捷的要求去做；但实际开发过程千变万化，场景无法穷举，生搬硬套损的是团队的气数，增加项目死气，容易把脑力劳动干成体力劳动！
虽然如此，若能以术入道，真正掌握敏捷开发的精神，灵活应变，根据团队，项目的实际情况（人与技术），有所取舍，能够真正为团队创造一个良好开发环境，那么以何种形式开展工作，是否叫敏捷开发，都不再重要。
有道无术，术尚可求，有术无道，止于术。搞开发亦是如此，有些团队看着很敏捷，产品却总出问题，天天加班；有些团队，看着吊儿郎当，还经常质疑这，质疑那，需求在他那里总是会被怒，也不爱加班，可人家有一件干一件，晚上都能安心睡大觉；你说你喜欢哪种开发模式？
