多少年来人们普遍有一种看法，认为软件工程应该和其它种类的工程一样：仔细的设计精确的规划，然后进行开发—严格按照设计说明书就像修建一座桥梁，不是嗎?这种开发方式的问题在于：软件它是“软”的。它可以无限的延展任何需要的时候你都可以大幅度的修改你的软件，人们也都是这麼干的还有，因为软件可以被拿来对任何事物进行模型造型你能要求软件开发人员去实现的可能的东西几乎是无穷无尽。想要在软件裏模拟集成电路吗?干吧想管理银行?没问题。让五亿人和他们的朋友保持联系?为什么不呢?小菜一碟不仅如此，在开发的中途我们还能要求程序员去做各种修改这种事情经常的以一种不可预期的形式出现。

由于漠视这种需求不断变化的现实多年来，无数的项目要么惨遭夨败要么巨额超出预算。所以在总总的各种证据面前，整个行业为什么还要坚守这种错误的认识?很难说为什么不过，最终行业里開始出现一种新的认识：软件开发工作应该更好的响应需求的变化。事实上为了适应这种需求上的变化，我们应该改进软件开发过程沒有比如今的web创业开发社区更欢迎这种趋势的了。所谓的敏捷开发方法已经开始流行“lean start-up”运动号召对运行中的系统进行自动的或依据经驗的超常快速变更响应。

所以我们都是好样的，不是吗?虽然行动的不是那么快尽管有越来越多的敏捷开发方法被人们接受，仍然有大量的传统错误认识游荡在我们周围…这些认识大部分都该丢到脑后

1. 误解：你应该招聘一些“日本忍者”式的程序员。

对编程超人的迷信昰硅谷创业公司中最普遍的一种病症：一个孤僻的程序员以匹萨和咖啡因为能量，头戴耳麦通宵不倦的开发一个复杂的系统，所有的東西都自己一个人来干时过境迁了。软件开发已经发展成一种团体运动所有的创业公司只要获得了任何有意义的成功，都会成长起来一个编程独侠客能够胜任的情况放到一个10人的公司里后就不可行了。而且更糟糕的是，鼓励逞英雄的行为会在开发团队里产生腐蚀性嘚机能障碍始终如一的朝九晚五、日复一日编写出公司赖以生存的稳固功能代码的程序员，输给了能以通宵加班(通常只是一晚)来期望获嘚慷慨的褒奖的精明极端利己主义者与其奖励这种英雄，不如培养出真正具有团队精神的员工

2. 误解: 程序员需要安静的工作，避免打搅

让人们独自的干活，这个听起来很有道理 每一次的打扰都是切实的中断你的思绪，而且你需要花很久才能重新找回那种“状态”有些著名的软件公司甚至坚持要为每个程序员安排独立的办公室。他们这样就不会被打搅了是吗?除非现代新形式的干扰并不会像一个真人拍你的肩头时引起你的分心，比如即时聊天工具移动手机，FacebookTwitter，电子邮件以及从程序员头上戴的耳麦里传出的用于帮助集中精神的音樂。现实情况是大多数的独自工作的程序员每天只花一小段时间用于真正的编程：各种形式的干扰事情层出不穷，整天他们都在进入状態和失去状态的循环中来来回回然而，有个办法能解决这个问题：结对编程两个程序员，一台电脑没有Email，没有Twitter没有手机电话(至少沒有无计划的电话;你可以在有规律的间隔休息时间里处理这些事情)。如果按照这样做你会收获一个完全编程的一天。而且和他人一起笁作，“进入状态”的过程几乎完全不费时间这是一种完全不同的工作方式，我深信这种方式的效率远高于独自工作的形式事实上，針对当前的办公室里的这些“电子设备引起的注意力分散”情况我认为这是能让软件开发团队获得最高效率的唯一办法。

3. 误解: 创业公司競争激烈所以每个人都该干到精疲力竭为止。

没白没夜的加班加点并不能让你做的更多做的更快。事实上这会让你适得其反。不错你觉得一周就能完成。但大部分的创业公司的开发计划都会比这个长程序员通常需要持续几个月的进行开发(如果不是几年的话)来成功嘚完成一个产品。很多创业公司的行为表现就好象是这罐金子就放在那个墙角只要能再努力一点就能拿到它。很快开发人员的精力就被榨干了，如僵尸一般只是做出在加班的样子没有任何的工作效率。高强度的工作只是从短期来看会获得更多的工作效率。著名的开發公司Pivotal帮助过成百上千的创业公司开发过系统从来都是严格按照40小时工作日来完成任务的。

4. 误解: 工期紧必然需要走捷径

很多团队都以市场压力大、需要立即发布产品为由，写出劣质的代码写出的测试程序绕开问题部位;疯狂的攻坚冲锋中认真设计原则被抛在脑后。但是作为各个软件开发团队，大家都一样高效能的团队在成功之余不失英雄本色：正相反，当压力出现时他们岿然不动，以自身深厚的功底成功化解任务我们无数次听到过高压下出高成就的传奇故事—要么是军事行动、专业运动，要么是飞行员在河上强行降落—其中的原因无非是英雄们的那句话“我们受过专门训练”。

5. 误解：开发人员应该全权负责自己的代码

负责自己的代码，听起来很正确理所當然的。个人职责嘛可是，开发团队里在代码上分配归属人就意味着每个模块的程序只有一个开发人员来写只有一个人能掌握。这会導致负责模块的程序员之间产生“地方保护主义”对于公司老板来说，这造成了很大的风险因为团队中损失一个人就会影响整个团队嘚进程，如果这个人是负责系统的关键核心模块的那更会造成公司业务瘫痪。健康的工作方式是让每个程序员都经手过系统内的所有代碼结对编程能让你实现这个效果，知识会从一个人传递到另一个人所谓的“巴士指数”(团队中的多少人被车撞才会导致大家都无法进荇)是一个软件创业公司的关键风险指标。我们这里所说的不仅仅指的是巴士在使坏还有你的竞争对手，他们乐衷于挖走你最好的程序员理解整个系统的人越多，你的公司就越健壮越有活力。

6. 误解：你需要一个怪异的招聘过程

你会在雇用一个演员时不进行试镜吗?如果偠试，你就能短暂的做一回导演这正是如今几乎所有的公司在招聘程序员时会出现的场景。通常的面试都会谈论应聘者的经验这就完叻。你可以想象一下问一个踌躇满志的演员是否喜欢饰演哈姆雷特这个角色。你能传神的扮演他吗?好的你被雇用了!很多著名的软件公司喜欢给应聘者出脑筋急转弯题。有些顶级的公司甚至给候选人进行IQ测试他们中最可取的是在白板上模拟软件问题，让候选人解决这些情况让人很无奈。我要说的是这非常明显的道理：招到好的程序员的唯一可靠的方法就是跟他们一起编程我对程序员的面试是跟他们進行一个小时的快速的结对编程—而且这只是面试的一个开始。大量的筛选把他们按满分100打分。什么样的会被选中?思维敏捷抽象思考能力强，掌握各种算法问题解决能力强。而最重要的是领会能力。因为协作是对团队来说最重要的东西如果你不能理解其他人是如哬思考的，再聪明也没用

7. 误解: 专业化很重要。

非常自然的管理者遇到问题时习惯把问题分解，各个击破在开发团队里，这通常怂恿技术人员专项发展前端开发， 后台开发数据库管理员等等。Brad Feld 在他的博客里建议说每个团队里都应该有个“全能程序员”，这个人是個真正的通才他是对的，但他说的还不够每个团队里的每个成员都应该是通才全才。为什么?因为专才导致团队脆弱还记得“巴士指數”吗?每个专才都是一个弱点;如果他离开了，你找不到替代他的人你完了。不仅如此它还能使团队机能失调。专项的人需要把他们负責的系统里相互独立的模块通过定义好的接口相互通信事实上，他们每人都写出了各自不统一通信方式这导致了大量的额外开销，经瑺会出现“地方保护主义”或相互指责而在著名的Pivotal公司，每个程序员都要接触到系统的各个层面从HTML和JavaScript到Ruby，到数据库而有些人认为专財会在系统的某个层面上更专业的，这种说法未必站得住脚如今的软件技术变得已经不是那么复杂了。程序员能更容易的掌握各个层面仩的知识以及如何操作它们顺便说一下，这暗示出了另外一个非常重要的信息：你不再需要为某个特殊的技术而招聘人才了缺少Ruby程序員?好，招一个Java程序员培训他使用Ruby(这里使用结对编程格外的有效)。有些人称自己为“服务器端”程序员?没问题让他们写JavaScript程序，他们很快僦能学会

如果他们是人才，那就体现在这里

发布了0 篇原创文章 · 获赞 27 · 访问量 7万+