软件作为工程有多不成熟
软件工程的起步也就是从上世纪七十年代初，到现在不过五十年的历史，这与超过千年的建筑、水利、城市比起来就是个无比稚嫩的婴儿。
鉴于软件工程在大规模协作经验上极度匮乏，就导致了软件开发的一个重要问题特征：为了达到交付目标，软件项目的人越多，越容易失败。
想想7000人同时开发一套软件系统的结果会是多么可怕的深渊。例如：IBM OS/360，大型机与操作系统项目，人类最庞大开发规模的IT项目之一，其中软件的困难程度已经远远超过硬件，用了5000人/年，进入了“有史最可怕的软件泥潭”，最初的计划投入是3000万刀，结果是5亿刀(相当于如今的40亿刀)，不仅延期了好几年，最终也没有完全达到最初所设定的目标，主导项目的OS/360之父Frederick Brooks也是总结项目经验写了本《人月神话》，拿了图灵奖，还影响了软件工程无数年，这本书就是敏捷开发思想的水之源。
焦油坑是一个比喻，类似于“沼泽”。庞大项目停滞不前、只能随着时间推移宣告失败的样子正如巨兽比如猛犸象等等陷入沼泽，挣扎地越是猛烈、下陷地速度就越快。
上述只是软件工程脆弱性的一个典型历史事件。
对于开发的软件项目的愿景，一千个软件工程师的心里就是10000个哈姆雷特，仅仅功能组件标准化的推行与维护在一个开发体系中都何其之难，更何况软件开发思想对于人类是如此之新，人们又不断通过多样化去故意制造出撕裂的生态，例如：Windows&Unix，iOS&Android。
顺便说句话，那些低代码或无代码的兜售者几十年来从未停止过这种可笑的鼓吹。
敏捷如何被玩烂
很多人总是拿敏捷模式与瀑布模式之间做是非黑白的对比，这都是不对的，瀑布模式不代表不能中途变更，敏捷模式也不说开始阶段不做设计。
完全不做设计的敏捷，那只是敏捷的一个极端模式：极限编程(XP)，极限往往需要结对，这种方式又无法适用在规模化的应用项目中，在国内根本无法理解。
目前最流行的敏捷scrum方法，在国内大多数公司也将其完美的形式化：必须早上站10分钟，必须有个白板这就加文化，必须有个人来假装成敏捷教练。
敏捷在国外大师的方法中极力推崇客户与开发团队经常坐在一起，充分沟通需求，发现问题解决问题，但是在国内不行，一旦客户与开发团队经常在一起，不是临近交付干到昏天黑地就是项目就要烂尾正在救火了！哪有什么敏捷的节奏可言。
适合我们的敏捷实用用法
那么怎么才是适合国内的敏捷？
敏捷在国内必须是务实的，务实就不能复杂，不复杂就是心领神会其主脉络即可。
对于敏捷的主脉络我认为就记好两点就够了：
(1) 达到需求预期要像制导导弹一样不断调整姿态，只有在不断的调整中，轨迹才会与预期目标充分的吻合。
软件项目的需求总是变化，敏捷的原则就是要拥抱变化，但我们要深刻理解什么叫“拥抱变化”，客户三天两头的奇思妙想，不断推翻先前的需求，让开发组累到半死，作为需求对接负责人不能拿敏捷来掩盖自己的无能！
精确制导的感念就是大方向要一致的前提下，再不断调整姿态，而不是连方向都随意改！
那就要从一开始在总体上勾勒轮廓，把握好方向，然后进一步通过实践经验去引导客户朝着更符合目标的方向思考，并一起沟通出实用的结果，这不仅是技术，还带有沟通的艺术。
若掌握不了这项需求沟通技巧，那么即便天天叫喊着敏捷，也是徒有其表，等同于隔靴搔痒。
只有把握住方向，那么需求的变化才是可控，而且修改的成本也是最低的，我一直推荐原型法，这是目前最朴实无华的一种符合国内项目前期需求的方法，配合上需求规格与技术架构方案，可以成为指导开发过程的三件关键性指标。
(2) 要像藏人造房要踩房顶一样，这是不断夯实屋顶密度的舞蹈，目的是房屋经年累月之后，仍不会因为糟糕的天气而漏雨，对于项目开发就是如何愉快的进行迭代与重构，增强系统的“密度”，那么对于这样的系统才能实实在在的牢靠并具有灵活性与张力。
?在开发过程中，敏捷一定是伴随重构与迭代，不要认为可以一次性解决好所有问题，重复再重复地对已有功能的重构看似是很枯燥的事，但是可以将重复的事情变成一种舞蹈，在乐趣中完成工作，那么重构也是一样，寻找重构的乐趣是养成重构好习惯的关键方法，我对重构最大的动力就来自重构后净干整洁的代码结构的观赏，只有在迭代中重构，才能通过重构夯实好更下一层，系统才会更稳定可靠，而且也会更灵活，也只有更灵活，才更适合进一步的敏捷迭代。
这就是敏捷的精髓所在！
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！