软件开发也称为什么开发 软件开发也称为什么开发呢

大家好，今天小编关注到一个比较有意思的话题，就是关于软件开发也称为什么开发的问题，于是小编就整理了1个相关介绍软件开发也称为什么开发的解答，让我们一起看看吧。

敏捷开发和迭代开发是一回事么？

敏捷开发与迭代开发是两个不同维度的东西，正如有位答者所说，敏捷开发是开发方法，迭代开发是开发过程。举个简单的例子，比如你要盖一栋高楼，敏捷开发就是各方确定这个楼应该用传统盖楼方法，先打地基，再往上盖，最后封顶。而不是按照新的盖楼方法，一层层做好了叠加上去。而迭代开发就是确定好盖楼方法之后，盖地基的时候具体应该怎么做，盖楼体的时候具体应该怎么做，封顶的时候具体应该怎么做。所以敏捷开发是战略层面的，迭代开发是具体实施的。

迭代开发就是炒菜前该洗还是要洗，该切还是要切。敏捷开发就是能不洗就不洗了，能不切就不切了。两者的共同点就是炒好一盘就给客人上一盘。正常开发是洗和切都要，而且炒好一桌菜再整桌上给客人。

自从开始做产品以来，负责的几个产品都是采用传统的瀑布流开发模式，需求分析——页面设计——开发——测试——上线。我本人除了负责需求分析外，还要负责项目管理的工作。几个产品做下来，对于这套流程还算驾轻就熟，公司的开发们也都乐此不疲的写着代码。不过最近一个项目，我们尝试了敏捷开发的工作流程，结果却不堪回首。

这次的项目并不是一个互联网产品，而是一个解决方案，甲方是一家拥有很多运动场的商业公司，希望我们能为其提供一套球场的智能化升级方案。但甲方的需求并不清晰，也不知道自己想要什么，唯一的目标就是让自己的运动场变得更“屌”，更科技化，能吸引更多的人来玩。

也正是因为甲方的这个特点，我们决定采用敏捷开发，先做出几个核心功能，交付到甲方，在甲方场地运营之后，再根据甲方的意见进行改进，逐步迭代，当整体做完之后，就可以把该项目内容打包成一个产品，对类似的客户进行销售。

在和领导分析了这个项目之后，我们决定采用敏捷开发的模式，我的任务就是需求分析，主要就是要多“走出去”，多和客户交流，把产品的其他事情，如流程图啊，文档啊……直接给研发们搞定，也算是试验一种新的开发模式。

怎奈理想很丰满，现实很骨干……整个开发过程多次返工，中断，这期间夹杂了无数次撕逼……

问题1：项目组内部人员问题

我和甲方沟通了需求之后，拉着开发们开会，所有人大开脑洞从甲方的基本需求中畅想了无数的延伸，无数的功能。仿佛做完这单，就可以覆盖全国……

但真正开工之后，问题一个接一个来了，首先，有的开发人员在之前的会上根本没有专心，我们所聊的场景，功能，他完全不知道，还停留在之前的瀑布流工作状态中，等着产品经理把详细的需求给到他……

其次，按照之前我和老板的讨论，由研发出流程图和文档，但真正执行的时候，却没有人做这项工作，后果就是在开发的过程中，不断的找我重新梳理流程，不断的聊场景，聊功能，这样一来二去时间就浪费了。

反思：敏捷开发和传统的瀑布式开发相差还是很多的，瀑布式开发只要在前期将用户需求，产品功能都想清楚，流程理顺，那后期只需要一个牛逼的项目经理把控项目进度，就不会出什么大问题。

我认为，敏捷开发的包含并大于迭代开发。

我的认知中，开发分为敏捷开发和非敏捷开发。敏捷开发的开发生命周期模型的典型代表是迭代开发。非敏捷的典型代表是瀑布开发。

举个例子。做一个产品，从需求到可行性到立项到开发到测试到上线，如果每一步的依赖都是前面一步的输出，例如要想做好可行性必须要做好需求并输出相应的文档，这种叫瀑布式开发。好处是每一步都有据可依，会把前期因为需求不明确或设计失误降到最低。每一步只有通过评审才能进行下一步。带来的问题是开发周期长，需求一旦确定，后期再变化，可能会造成项目失败。

做一个产品，将需求分解，确定的需求和不确定的需求，先做确定的需求，进行一个完整的开发周期，向客户交付，然后进一步确定不确定的需求，按照迭代升级不断的完善产品。这种方法的好处是产品可迅速出原型，可根据市场反应比较快的调整需求。同时它也就要求对产品的开发要有一个好的架构或模型，甚至要牺牲成本，有可能最后的成品需要重新迭代硬件，也就是每一次的迭代有可能只适应于当前需求，后期的迭代就要根据需求更新硬件。当然，如果产品规划的好，迭代思路明确，可以减少这方面的问题。

敏捷和非敏捷没有更好，只有更适合。工业品的开发应该更适合非敏捷，因为需求明确且不容易变，产品开发更注重稳定。消费品的开发应该更适合敏捷开发，迅速开发出原型机去验证市场或交付客户，之后一步步完善，更注重功能。或者说，可以不稳定，但一定可以不断升级。

以上

到此，以上就是小编对于软件开发也称为什么开发的问题就介绍到这了，希望介绍关于软件开发也称为什么开发的1点解答对大家有用。