组建团队的时候从算法到数据结构，从OO到template，从并发到协程，每个人都各有擅长。可整个团队交付的代码总是一团糟，总觉得还不如自己一个写全部代码好。本文尝试从软件流程和开发实践的角度分析内在原因。
“软件工程”，我们先来看工程学wiki定义：“工程学、工程科学或工学，是通过研究与实践应用数学、自然科学、 社会学等基础学科的知识，以达到改良各行业中现有材料、土木建筑、机械、电机电子、仪器、系统、 化学和加工步骤的设计和应用方式一门学科，而实践与研究工程学的人称为工程师。在高等学府中， 将自然科学原理应用至服务业、工业、农业等各个生产部门所形成的诸多工程学科也称为工科和工学。”
个人不是很喜欢这个词，因为早期软件工程和土木工程建筑设计流程很相识。无法确定瀑布开发方式是否参照了土木工程。
如果我们要造一座桥大致会有如下关键流程：
如果用瀑布流程开发软件：
流程是不是很相似，建筑行业几千年的经验总结，沉淀，产生了无数的建筑奇迹。这套建筑工程流程经过了无数的实践，会有很大问题吗？我认为不会。那软件行业参照这套流程设计可行吗？看隔壁日本这套流程玩的溜起来，但这套流程需满足建筑行业的几个基本条件。
条件1:施工人员严格按照流程的要求施工
条件2:一开始问题想的很清楚，到了施工阶段，需求变更很少，甚至几乎没有
条件3:足够的时间完成项目
瀑布流程里面每个流程都是环环相扣，a.每个流程都是由具备相应能力的人员完成，b.缺少任何一个环节都会导致后续动作直接变形。
建筑行业中“初步设计，技术设计，施工设计”都是由相应具备能力的建设设计师，结构力学工程师等协作完成。对应于软件行业里面“架构设计，概要设计，详细设计”，现实中架构设计由架构师参与完成，但概要设计，详细设计架构师很少参与，大多是由负责相应开发功能的开发人员完成。如果要类比建筑行业就是技术设计和施工设计由施工人员完成？！所以团队成员是否具备概要设计和详细设计能力会直接影响你后续的编码活动。
裁剪，瀑布流程里面我听到最多的就是这个词语。“详细设计浪费时间裁剪掉”，“单元测试没能力做，裁剪掉”，“代码检视没时间做，裁剪掉”，一个好端端的流程被你裁剪成只剩开发和测试，你说团队做出的东西不是一坨翔，你信吗？软件开发是你想的那么简单吗。
但软件毕竟不是建筑。软件的要解决的问题千奇百怪，很难一次想明白，软件变更成本相比建筑行业低太多。同时很多时候产品需要快速上线，无法接受瀑布流程的一个月甚至几个月的交付周期。所以瀑布流程需要满足的几个条件，在现在看来很难满足。在这种环境下用这套流程开发，自己是有多想不开。
敏捷开发流程就是在这种环境下应运而生。解决方案一开始想不清楚，先做个MVP来看看。需求变化多，采用迭代的方式缓解。用户量随时间增长，架构根据需要调整。
但敏捷开发在缩短迭代周期到2周以后，相应的开发实践都需要做相应的调整来适应开发流程的变化。
极限编程基本实践：
越是缩短交付周期，这些基础实践越重要，可以说如果不进行这些基础实践，根本不可能高质量1～2周交付。可经历过所谓瀑布开发流程的裁剪者们又来实践敏捷了，“UT太难写了，不写了”，“重构，不存在的”，“代码检视，太浪费时间了”，最后敏捷开发又变成了，两周只有开发和测试的活动。
这些裁剪者们往往从来没有写过UT，没有感受过UT对调试代码的益处，对重构的帮助。也没从来了解过优秀团队怎么做代码检视(https://google.github.io/eng-practices/review/), 然后他们拍脑袋本能的觉得除了本能开发一切都不重要。不去借鉴业界优秀的实践。
任何开发流程我认为有两个核心作用：帮助团队高效协作，帮助不同能力的团队成员都输出较高质量的代码。
如果你有幸和一群技术高手共事，那你可以看到他们用更多的开发实践去高效协作。
如果你所在的团队成员能力高低不平，做扎实基础实践和流程去帮助团队成员。
如果你所在的团队能力一般，整个交付过程，只有开发和测试，自求多福吧。