为什么要敏捷？

这是一个“没有需求”的项目，原因很多，主要有：
1. 客户没主意或者是客户没时间/主观意愿整理需求
2. 项目进度很紧，客户必须要先有个原型
3. 新领域的项目，没有产品化积累


经过两个小项目的经验，团队对于需求明确的瀑布式开发流程已经渐入佳境，对于这个所谓“没有需求”的项目，团队成员，包括我在内，都想得比较简单，总觉着出问题再说。


好吧，出问题了！


领导给的deadline是45天，需求大概的每个功能点说了两句，我听了之后，也觉得还好，由于这个时间点是由商务因素决定的，没办法，硬着头皮上吧。45天之后，事实证明是真的干不完的，中间团队人数由6人一度扩张到14人，6周之后，勉强的把功能点都覆盖到了，集成测试没做（只能拉着客户当测试员了），代码评审，周期性回顾，文档审查，毛都没干，简单的说，项目的质量完全是没谱的。


由于初期没有明确的需求，基本上是，需求工程师给一块，我们干一块，没有整体的规划和设计，导致后期在项目中出现了大量的不一致，这种不一致出现在各种层面，数据库，代码，界面都有。这种问题，对于有一定程度的精神洁癖的我来说，完全不能接受，而且，感觉拖得越久越容易出大问题。原型上了之后，立马重构系统。


项目的“被迭代”次数越来越多，负责产品的领导在开发前往往是不知道系统会做成什么样的（事实上，他也不太清楚要做成什么样子，从上到下，所有人都是摸石头过河），由于又缺少正式的，明晰的沟通（例如用例图、需求评审），大量的返工出现在项目的中后期（返工工时在整个项目过程中占30%以上），主要体现在，领导看了一下样式，觉得哪哪不好，改吧。又发现什么地方能增加一个新功能，加吧。甚至有好几处改动，整个系统的功能架构都需要进行调整。这段时间，开发人员怨声载道，手头的开发工作还没干完，昨天提交的代码又要进行调整。由于质量没保证，因此我对单元测试要求很高，测试也被搞得够呛。但又由于进度压力摆在那，导致文档、代码评审，更新基本瘫痪，只能记为遗留问题，事后补上。


上周末，系统原型能够演示了，开了一个回顾会议，团队成员疯狂的鞭尸吐槽，收获颇多，也坚定了我把敏捷引入到现有流程中的决心。


以上，吐槽基本上就结束了，哪天想起来再补充补充，时间不早了，关于小张对“什么是敏捷”、“如何敏捷”以及“敏捷 in CMMI3”的一些粗浅看法，梦醒再说。