敏捷开发和瀑布开发的混搭

我认为开发的过程没有太大的问题。

当然，这里有个前提，贵司这个软件不是实现客户现有的管理思想，而是要向客户传递一个新的管理思想。

看看客户需求描述：“做XXXX运维成本太高了，管理也很混乱，能不能给做个管理系统给控制一下”，这通常意味着，客户的管理比较原始，还没有形成有效的管理模式。

软件是思想的体现，当客户没有一套行之有效的管理模式时，软件是很难做下去的。

正常的做法是，客户先找个咨询公司，梳理管理流程，再依据新流程，完成软件。现在两步并一步了，贵司既要承担咨询师的角色，又要实现软件。

当贵司确实想做这个项目的时候，第一步做的其实很正确，就是通过行业专家（充当咨询师的角色）来再造管理流程，这是因为你的客户的管理水平较低，很少或无法给你提供这方面的建议，当然，这个过程如果有客户的参与，及原型验证就圆满了，只要你能说服客户接受新的管理流程，一切就OK了。

高见。不过我认为问题还是有的：

1、由于开发开始的时间有点晚（距离项目启动3个月），所以需求分析的偏差比较难及时得到纠正。这导致需求分析、概要设计、代码实现这几个阶段的工作量，都会有一些浪费

2、实际编码人员没有参与到前期的分析和设计中，所以前期的工作成果，在传递上会有些遗漏

您其他的分析，我觉得都挺到位的

正在考虑敏捷开发，但是不是套用，而且结合实际来用。目前思路不清晰，等清晰了，与给位探讨

貌似是华为的项目。。。

不管怎么开发，都不能生搬硬套。

所有相关人员都应该参加到前期需求分析和设计中来，否则，后期的敏捷也只是看似敏捷，有名无实。站例会、持续集成是能够推动项目良性发展，优化项目过程的好实践，但是不能因为是在敏捷开发中提出来的，就觉得做到了这些就是引用了敏捷开发。

一个项目的发开模式，应该在确定要去做这个项目的时候就制定下来。虎头蛇尾的东西到底是虎还是蛇？这里只是打个比方，没有褒贬的意思。

瀑布开发未必就做不好项目，为什么突然就转向敏捷了呢。帮你分析下，往好点说，是因为你们的MANAGER缺乏这方面的经验。深层次的分析，在你们MANAGER的意识中，分析设计人员和开发人员的地位是不均等的，所以开发阶段的成本，是可以尽情压缩的。

至于你说的分析，设计，开发这三个阶段中逐渐对需求产生的偏差的问题。
首先考虑下相关文档的管理是否合理。有没有及时的更新，更新后没有及时知会相关人员等等，当然这些也是MANAGER应该考虑的问题。

其次，就是沟通的问题了。个人沟通能力是慢慢培养出来的；团队默契也是慢慢培养出来的。所以新形成的团队在开始的一两个项目中，慎用敏捷开发。敏捷的不是项目，而是人。

以上纯属个人意见。

敏捷开发的根本是 持续获取用户的反馈，从LZ的描述来看，没有做到这一点，至于后阶段所提的“敏捷”，也是伪敏捷，建议采用由外到内的开发方式进行。

其实我还是感觉MSF的一套理论方法比较实用些。

毕竟，MS的理论方法体系和工具都很完善啊，哈哈。

个人觉得整个流程没有问题。
但是看楼主的描述，最终该项目的结果是不成功的，其中的一些问题值得我们深思。
该项目启动的原因是一个重要客户的原始需求，我们要一个什么样的系统呢？
只是为该客户定制一个管理系统，或者做一个产品，可以推给行业内的其他客户？
第一阶段，有业务专家，现场运维人员，为什么不邀请客户一起来参加呢，至少可以听听客户更多的一些想法，可以把需求理解的更贴近客户一些。该阶段要形成比较原始的需求文档
第二阶段，已经决定要做这个项目了，应该要确定项目经理和项目技术经理，项目经理、需求分析人员一起分析需求，技术经理也要参与。
第三阶段，技术经理根据需求做设计，不过设计要做的比较细，开发人员开发时直接根据设计来做，不需要太关心原始的需求。
流程越长，越来注意各阶段信息的流畅和保真，尽量减少沟通成本