迭代开发模型和工作流程管理

“不管做任何事情，发现本质非常重要，不要让它的本质被其外表所呈现出的假象所掩盖，要抓住它的‘内核’——而这正是精益思想的精髓。”
IvarJacobson

迭代开发模型和工作流程管理

软件开发过程更像盖大楼还是种苗圃呢？几年前闲聊之间朋友这么问我。我当初的回答是盖大楼。建筑工程经过漫长的发展，已经非常成熟了。在设计阶段，每栋建筑的用砖量，建材消耗都已经很明确了。如果没有意外的话，比如资金链断裂，工伤之类的事情，施工进度应该没有多大问题。软件工业发展至今也不过数十年，和建筑工程不可同日而语。无论是从产品设计的角度还是从结构设计角度而言，都有很多不确定性。在软件开发工作结束之前准确的预估其开发成本是非常困难的。以我的经验而言，软件开发更像是种苗圃。在结出果实之前，根本不知道他会长成什么样子。无论你有过多少年经验，新的问题总会出现。所以我推荐的开发过程是拥有迭代过程的开发模型，比如迭代模型或者Scrum模型。换言之，希望找到所谓的高手，以瀑布模型来开发是冒着巨大的风险的，特别是在互联网这个多变的行业。
就像前面说过的，软件开发就像种苗圃。每一轮迭代过程就会对整个项目经行梳理。实践中，每一轮迭代过程基本上都是相同的：

产品策划-->结构设计-->编码-->测试-->评审-->发布或返回产品策划，开始新一轮迭代


整个过程其实就是RUP过程。这个过程的每个环节都遵循“尽力”原则，即尽力而为的意思。不纠结于一轮迭代中某无法确定的问题，只对已知的部分采取行动。不确定的部分在其后的若干轮迭代中逐步解决。比如产品策划人员经常纠结于颜色、字体、按钮摆放的位置等没问题。在上述开发模型中，当这些问题无法确定时即先不确定。开发人员也许会抱怨每一轮迭代都会对修改上一次迭代过程中产生的代码。每一轮产品策划阶段结束后，本轮迭代的产品需求不再修改，处于封闭状态，直到下一轮迭代的产品策划阶段。
让人头疼的一件事是产品策划人员常常力求完美，希望一次给出完整的需求。我认为这是完全没有必要的。而且由于产品初期不确定因素太多，策划人员也很难给出一步到位的解决方案。我认为短时间内产生可交付物非常重要。在前文《建设稳定的技术团队》一文中描述过里程碑的时间划分。我重复下这个建议值，2~4周，2周为宜。
迭代的过程使风险降低，工作量比较均衡。也就是说不会出现时紧时松的工作状况。事实上，所谓的时紧时松的工作状态基本上不存在，即使存在也是不好的。时紧时松的工作状态说明工作量分布不均匀。也即是说在整个工作模型中存在着不可控的因素。（可控的部分总可以平均分布在时间线上。）如果整个工作模型都不稳定的话，项目蕴含的风险不言而喻。