豆果金菠萝2021-05-05付老师您好，我现在也在做帮助公司实现数字化转型的工作，用的是和外部低代码平台团队合作的方式。由于公司属于国企，内部研发人员很少，水平有限，为了能快速实现某个业务的快速落地，快速反馈，快速迭代，也正在探索这种模式的可行性。作者回复: 低代码方式本身可以处理不复杂的应用，所以，不用太听外界的声音，还是看自己的落地实效。毕竟，自身技术队伍的建立也是需要时间的。
共 2 条评论3
祝青2021-05-25其实，能够理解到瀑布模型的核心需求是稳妥，代表谨慎的态度，敏捷模型的核心诉求是快速，允许一定程度的试错，代表了开放的态度，这是发展的价值观区别，这已经是很深层的理解。它们同样适用于企业转型的场景，传统内部优化可以敏态处理，新业务的创新开拓，可以谨慎探索，遵守企业转型方法论中的既定步骤，起码从过程的层面降低出错的概率，这样的项目方法论应用在企业转型中，对我来说很新鲜，很有启发！作者回复: 感谢您的支持，也欢迎多交流企业转型、企业工程方面的心得，请您多指教👍
2
甘亚鹏2022-07-30 来自北京解决痛点，还是多分析，多观察，多实践作者回复: 是的👍
V2021-05-11对于在搞转型的传统企业，付老师建议用敏捷方法对待持续的自我完善，用传统稳态工程方法对待用新技术打造新业务模式。 我感觉这也是一种架构思维。架构师都知道甘蔗没有两头甜，做架构就是做权衡取舍。敏捷的好处在于迭代，快速低成本试错，持续自我完善这种天然就是迭代的场景可以用敏捷来主动探索。传统模式（也就是瀑布啦）的好处是慎重，对新技术和新业务这种不确定性较高的场景，慎重点没坏处，也不一定慢。作者回复: 是的，您解释的非常好👍
共 2 条评论- 邓小年2021-05-08付老师，对于思考题中，不完全赞同这个观点。我们实际经验是对于新业务新技术也是用敏捷的方式，因为这个过程不断在调整。如果用传统工程的方法可能就玩不起来了。
作者回复: 您提的非常好，我看待这个问题的角度是，面向新领域的创新需要速度，但更需要慎重，所以才建议大家对于业务改进型的创新，因为熟悉，所以可以敏捷，即便错了，大概率也知道怎么控制，但是新领域不是这么容易的发现问题的。目前金融领域国家已经提出要求，必须稳妥发展金融科技，并建立产品的纠偏纠错机制，新业务和新技术的潜在风险评估并不容易，也不是试错可以简单发现的，另外，看这个问题时，也要注意，传统不代表慢，而是代表要慎重，这是面向新领域创新时需要注意的。其实提这个问题主要是避免大家过于相信敏捷试错的效果，而忽略试错的成本，并因此而盲目试错。
共 3 条评论