为什么需要一个严格的规范来约束团队？

　　个人认为，整个软件开发的历史可大致分为三个时期，开荒期，处在这个时期的软件开发人员非常牛逼，都是所谓的“徒手程序员”，没有先进的IDE，没有便利的设计工具，在黑底白字的屏幕上，为整个软件行业奠定了基石。第二个时期为发展期，处在这个时代的软件开发人员稍显尴尬，因为是过渡时期，一切都需要靠规范，所以，他们建立了一套软件行业的规范，并流传至今。第三个时期，就是我们现在处在的时期：创新期。到了这个时期，软件行业发展非常迅速，各种成熟的开发工具，项目管理工具供我们使用，然后，前一个时期保留下的各种规范、流程也同样适用于我们，但是，真的有必要么？

　　首先，我承认，好的流程和规范可以帮助一个公司管理开发团队。但是，这是建立在牺牲了团队的机动性和发散性的基础之上。

　　以前，我是SOLO，一个人在战斗，做开发的时候，非常灵活，首先在纸上思考问题（一直保留了在本子上做笔记的习惯，因为一直觉得拿着笔我才能真正的写出东西，虽然现在字确实写的很难看了），画架构图，画关系图，画原型，然后在记录到电子档上。而且我这些笔记不遵循任何标准，没有ISO、没有CMMI来烦我，一切是那么的自由和流畅，有时候，一个灵光闪现，马上就实现了，有什么需求变更，在纸上画个叉，下次我一看就知道这个是变化过的。

　　然后，我加入了团队，他们说软件行业是没有孤胆英雄的，我对这点也深信不疑。然后，他们又说，我很不专业，根本不遵循行业的游戏规矩，我做的设计说明书，不遵循规范，不能拿给其他开发人员看（因为我喜欢把设计图画在PPT上）。唯一能拿的出手的就是UML类图和数据库关系图（因为用的工具做的，都大同小异）。我想说，大神们，真的看不懂么？于是，我又开始按照各种标准各种规范来写文档，哪怕里面是屁话（就像我用图来表示了数据库关系，但是非要在下一节在用一个表格来说明数据库关系），他们看着都是舒服的，就想领导的发言稿一样。

　　其实，我觉得，软件开发行业到了今天，完全可以做到灵活、高效的，特别是我们这种处于应用层开发的。现在都提倡组件化，一旦大的架构（一定程度上可复用）设计好，组件（可复用）设计好，实现业务和功能，其实无需太多的设计，唯一就是理清楚流程和数据关系即可。对于文档，我认为只需要建立好一个每个开发成员都认同的、可交流的版本即可，尽量减少由于标准化而给开发人员带来的额外的工作负担，我想这些负担都是开发人员（一个非常喜欢编程和富有热情的开发人员）非常反感的。尽量想办法让开发人员在一定程度上用自己感兴趣的方式来工作，这才是现代软件开发需要考虑的事情，增加开发人员对于编程的热情、兴趣，把感情融入代码，不断的追求完美代码，这才是现代软件开发所需的。

　　我就是我行我素，我要让那些标准去见鬼，我做我的产品，不是做我的流程，我要用我自己觉得灵活可靠的方式来做开发！

---

　　2013-03-01更新：

　　为什么大家都理解的是不需要文档？不需要文档如何保证在编码过程中理解清楚流程？就像我在回复中说的一样，善于寻找一种简单、有效的协作方式，而不是形式化的方式。至于什么你要申请产品认证，需要标准化的文档，一大堆公司可以帮你做这个事情，把你自己的过程文档版本交给他们，就可以产出标准化文档，这个也可以放在结项前来做，而不是非要在过程中就产出。KISS原则不仅适用于程序设计，同样适用于开发过程！