【IT168 评论】多少年来，人们普遍有一种看法，认为软件工程应该和其它种类的工程一样：仔细的设计，精确的规划，然后进行开发 —— 严格按照设计说明书。就像修建一座桥梁，不是吗?这种开发方式的问题在于：软件，它是“软”的。它可以无限的延展。任何需要的时候你都可以大幅度的修改你的软件，人们也都是这么干的。还有，因为软件可以被拿来对任何事物进行模型造型，你能要求软件开发人员去实现的可能的东西几乎是无穷无尽。想要在软件里模拟集成电路吗?干吧。想管理银行?没问题。让五亿人和他们的朋友保持联系?为什么不呢?小菜一碟。不仅如此，在开发的中途我们还能要求程序员去做各种修改，这种事情经常的以一种不可预期的形式出现。
这可不是像修桥那样。
由于漠视这种需求不断变化的现实，多年来，无数的项目要么惨遭失败，要么巨额超出预算。所以，在各种证据面前，整个行业为什么还要坚守这种错误的认识?很难说为什么。不过，最终，行业里开始出现一种新的认识：软件开发工作应该更好的响应需求的变化。事实上，为了适应这种需求上的变化，我们应该改进软件开发过程。没有比如今的web创业开发社区更欢迎这种趋势的了。所谓的敏捷开发方法已经开始流行，“lean start-up”运动号召对运行中的系统进行自动的或依据经验的超常快速变更响应。
所以，我们都是好样的，不是吗?虽然行动的不是那么快。尽管有越来越多的敏捷开发方法被人们接受，仍然有大量的传统错误认识游荡在我们周围…这些认识大部分都该丢到脑后。
1. 误解：你应该招聘一些“日本忍者”式的程序员。
对编程超人的迷信是硅谷创业公司中最普遍的一种病症：一个孤僻的程序员，以匹萨和咖啡因为能量，头戴耳麦，通宵不倦的开发一个复杂的系统，所有的东西都自己一个人来干。时过境迁了。软件开发已经发展成一种团体运动。所有的创业公司只要获得了任何有意义的成功，都会成长起来。一个编程独侠客能够胜任的情况放到一个10人的公司里后就不可行了。而且，更糟糕的是，鼓励逞英雄的行为会在开发团队里产生腐蚀性的机能障碍。始终如一的朝九晚五、日复一日编写出公司赖以生存的稳固功能代码的程序员，输给了能以通宵加班(通常只是一晚)来期望获得慷慨的褒奖的精明极端利己主义者。与其奖励这种英雄，不如培养出真正具有团队精神的员工。
2. 误解: 程序员需要安静的工作，避免打搅。
让人们独自的干活，这个听起来很有道理。每一次的打扰都是切实的中断你的思绪，而且你需要花很久才能重新找回那种“状态”。有些著名的软件公司甚至坚持要为每个程序员安排独立的办公室。他们这样就不会被打搅了，是吗?除非现代新形式的干扰并不会像一个真人拍你的肩头时引起你的分心，比如即时聊天工具，移动手机，Facebook，Twitter，电子邮件，以及从程序员头上戴的耳麦里传出的用于帮助集中精神的音乐。现实情况是，大多数的独自工作的程序员每天只花一小段时间用于真正的编程：各种形式的干扰事情层出不穷，整天他们都在进入状态和失去状态的循环中来来回回。然而，有个办法能解决这个问题：结对编程。两个程序员，一台电脑。没有Email，没有Twitter，没有手机电话(至少没有无计划的电话;你可以在有规律的间隔休息时间里处理这些事情)。如果按照这样做，你会收获一个完全编程的一天。而且，和他人一起工作，“进入状态”的过程几乎完全不费时间。这是一种完全不同的工作方式，我深信这种方式的效率远高于独自工作的形式。事实上，针对当前的办公室里的这些“电子设备引起的注意力分散”情况，我认为这是能让软件开发团队获得最高效率的唯一办法。
3. 误解: 创业公司竞争激烈，所以每个人都该干到精疲力竭为止。
没白没夜的加班加点并不能让你做的更多，做的更快。事实上，这会让你适得其反。不错，你觉得一周就能完成。但大部分的创业公司的开发计划都会比这个长，程序员通常需要持续几个月的进行开发(如果不是几年的话)来成功的完成一个产品。很多创业公司的行为表现就好象是这罐金子就放在那个墙角，只要能再努力一点就能拿到它。很快，开发人员的精力就被榨干了，如僵尸一般只是做出在加班的样子，没有任何的工作效率。高强度的工作，只是从短期来看会获得更多的工作效率。著名的开发公司Pivotal帮助过成百上千的创业公司开发过系统，从来都是严格按照40小时工作日来完成任务的。
4. 误解: 工期紧必然需要走捷径。
很多团队都以市场压力大、需要立即发布产品为由，写出劣质的代码。写出的测试程序绕开问题部位;疯狂的攻坚冲锋中认真设计原则被抛在脑后。但是，作为各个软件开发团队，大家都一样。高效能的团队在成功之余不失英雄本色：正相反，当压力出现时，他们岿然不动，以自身深厚的功底成功化解任务。我们无数次听到过高压下出高成就的传奇故事 —— 要么是军事行动、专业运动，要么是飞行员在河上强行降落 —— 其中的原因无非是英雄们的那句话，“我们受过专门训练”。
