敏捷开发和瀑布开发的混搭
现在这家公司的开发流程很奇怪，和以前的公司很不一样
一、首先拿到一个客户需求，这个客户需求（OR）可能就只有一句话：“做XXXX运维成本太高了，管理也很混乱，能不能给做个管理系统给控制一下”
由于这个客户很重要，所以虽然需求很不明确，连系统该做成啥样都不知道，但是领导还是决定要做。于是项目组就启动了。这个时候所有已知的东西，就只有这个一句话的OR
二、第一阶段，叫Chart开发，这个阶段找了很多业务专家，以及有现场运维实际经验的人来。一边猜想，一边问。这个阶段主要解决以下问题：
1、这个系统做出来要解决什么问题
2、这个系统大概是啥样的
3、这个系统做出来以后，用户要怎么用
然后这个阶段项目组分成3个小组：“业务分析组”、“竞争分析组”、“技术预研组”，来并行工作。业务分析组就是和业务专家在一起，“猜测”系统应该是怎么样的，回答前面的3个问题。竞争分析组把同类的产品拿来看，自己边用边分析，其实就是模仿。技术预研组则是把有风险的技术先研究研究，免得到时候做不出来
这个阶段结束以后，输出了一堆文档。最重要的就是一个叫“包需求”的东西。把前面的一句话OR扩大了很多，变成一个很长的需求列表。这个输出是后面所有工作的起点。
我感觉这里就有点问题了：
1、为啥叫包需求，我看了这么多书，就没见过有这么一个名词，再说也很难听
2、这个包需求，根据多个项目的经验，相当不准确。遗漏或者瞎猜的情况很严重
三、不管怎样，然后就进入第二阶段了。这个阶段叫“需求分析”，但是分析的不是原始需求了，而是上个阶段输出的“包需求”。这个阶段把包需求分解了，也加了很多人进来。每天大家就对着包需求“想象”场景，输出“场景分析”，这个场景分析之后，又把包需求分解成了一大堆“设计需求”（DR），这个DR也是一个长长的列表，作为下一阶段工作的起点
我感觉这里又有问题了：
1、本来包需求就是有偏差的，经过进一步想象，或者说瞎猜，这一阶段输出的设计需求，已经和原始需求有了更大的偏差
2、很多人没有经历过上一阶段，在这个阶段空降加入，效率很低，沟通成本很高
3、实际的开发人员到这个阶段还是没有全部参与，这个阶段的输出传递会有问题
四、不管怎样，接下来该进入第三阶段了。这个阶段的起点就是上个阶段的“设计需求清单”，这个阶段叫“设计阶段”，把设计需求，再进行一个“概要设计”，最后输出一个“用户故事清单”（Story List）。好吧，敏捷开发的名词终于出现了，在经过了这么久的瀑布之后。。
五、然后进入了迭代开发阶段，这个阶段才开始实际编码。工作的起点是上个阶段输出的“Story List”，每个开发小组对Story进行迭代的简单设计、开发、测试、集成测试。这个阶段有点像敏捷开发了，包括站立会议、持续集成、交叉检视等等手段都会引进来
六、总结，个人感觉，这个开发流程，前面是瀑布，后面是敏捷，我猜到了开头，却猜不到结局。。。
1、前面花了很大的力气（至少3个月），进行需求分析和设计，但是这个需求分析和设计的结果，往往在开发阶段发现有很多问题，部署后用户表示和最初的想法有差距
2、前期的工作成果，传递得很不好，没有参加前3个阶段的开发人员，在开发阶段基本不会去看前期的输出，但实际编码的又是这些人，这样前期的工作意义又被削弱了
总之，我觉得还是我以前那个公司，开发流程更像真正的敏捷。虽然没有站立会议、结对开发这种手段上的东西。但是出可运行交付的周期更短，用户可以更快的反馈结果，浪费在需求分析和设计阶段的时间更少
不过。。。体验一下现在这种流程也不坏，有比较才有想法嘛~~
