<p>多少年来，人们普遍有一种看法，认为软件工程应该和其它种类的工程一样：仔细的设计，精确的规划，然后进行开发—严格按照设计说明书。就像修建一座 桥梁，不是吗？这种开发方式的问题在于：软件，它是“软”的。它可以无限的延展。任何需要的时候你都可以大幅度的修改你的软件，人们也都是这么干的。还有，因为软件可以被拿来对任何事物进行模型造型，你能要求软件开发人员去实现的可能的东西几乎是无穷无尽。想要在软件里模拟集成电路吗？干吧。想管理银 行？没问题。让五亿人和他们的朋友保持联系？为什么不呢？小菜一碟。不仅如此，在开发的中途我们还能要求程序员去做各种修改，这种事情经常的以一种不可预 期的形式出现。</p>    <p>这可不是像修桥那样。</p>    <p>由于漠视这种需求不断变化的现实，多年来，无数的项目要么惨遭失败，要么巨额超出预算。所以，在总总的各种证据面前，整个行业为什么还要坚守这种错 误的认识？很难说为什么。不过，最终，行业里开始出现一种新的认识：软件开发工作应该更好的响应需求的变化。事实上，为了适应这种需求上的变化，我们应该 改进软件开发过程。没有比如今的web创业开发社区更欢迎这种趋势的了。所谓的 敏捷开发方法 已经开始流行， “lean start-up” 运动号召对运行中的系统进行自动的或依据经验的超常快速变更响应。</p>    <p>所以，我们都是好样的，不是吗？虽然行动的不是那么快。尽管有越来越多的敏捷开发方法被人们接受，仍然有大量的传统错误认识游荡在我们周围…这些认识大部分都该丢到脑后。</p>    <h3><strong>1. 误解：你应该招聘一些“日本忍者”式的程序员。</strong></h3>    <p>对编程超人的迷信是硅谷创业公司中最普遍的一种病症：一个孤僻的程序员，以匹萨和咖啡因为能量，头戴耳麦，通宵不倦的开发一个复杂的系统，所有的东 西都自己一个人来干。时过境迁了。软件开发已经发展成一种团体运动。所有的创业公司只要获得了任何有意义的成功，都会成长起来。一个编程独侠客能够胜任的 情况放到一个10人的公司里后就不可行了。而且，更糟糕的是，鼓励逞英雄的行为会在开发团队里产生腐蚀性的机能障碍。始终如一的朝九晚五、日复一日编写出 公司赖以生存的稳固功能代码的程序员，输给了能以通宵加班(通常只是一晚)来期望获得慷慨的褒奖的精明极端利己主义者。与其奖励这种英雄，不如培养出真正 具有团队精神的员工。</p>    <h3><strong>2. 误解: 程序员需要安静的工作，避免打搅。</strong></h3>    <p>让人们独自的干活，这个听起来很有道理 。每一次的打扰都是切实的中断你的思绪，而且你需要花很久才能重新找回那种“状态”。有些著名的软件公司甚至坚持要为每个程序员安排独立的办公室。他们这 样就不会被打搅了，是吗？除非现代新形式的干扰并不会像一个真人拍你的肩头时引起你的分心，比如即时聊天工具，移动手 机，非死book，推ter，电子邮件，以及从程序员头上戴的耳麦里传出的用于帮助集中精神的音乐。现实情况是，大多数的独自工作的程序员每天 只花一小段时间用于真正的编程：各种形式的干扰事情层出不穷，整天他们都在进入状态和失去状态的循环中来来回回。然而，有个办法能解决这个问题：结对编 程。两个程序员，一台电脑。没有Email，没有推ter，没有手机电话(至少没有无计划的电话；你可以在有规律的间隔休息时间里处理这些事情)。 如果按照这样做，你会收获一个完全编程的一天。而且，和他人一起工作，“进入状态”的过程几乎完全不费时间。这是一种完全不同的工作方式，我深信这种方式 的效率远高于独自工作的形式。事实上，针对当前的办公室里的这些“电子设备引起的注意力分散”情况，我认为这是能让软件开发团队获得最高效率的唯一办法。</p>    <h3><strong>3. 误解: 创业公司竞争激烈，所以每个人都该干到精疲力竭为止。</strong></h3>    <p>没白没夜的加班加点并不能让你做的更多，做的更快。事实上，这会让你适得其反。不错，你觉得一周就能完成。但大部分的创业公司的开发计划都会比这个 长，程序员通常需要持续几个月的进行开发(如果不是几年的话)来成功的完成一个产品。很多创业公司的行为表现就好象是这罐金子就放在那个墙角，只要能再努 力一点就能拿到它。很快，开发人员的精力就被榨干了，如僵尸一般只是做出在加班的样子，没有任何的工作效率。高强度的工作，只是从短期来看会获得更多的工 作效率。著名的开发公司Pivotal帮助过成百上千的创业公司开发过系统，从来都是严格按照40小时工作日来完成任务的。</p>    <h3><strong>4. 误解: 工期紧必然需要走捷径。</strong></h3>    <p>很多团队都以市场压力大、需要立即发布产品为由，写出劣质的代码。写出的测试程序绕开问题部位；疯狂的攻坚冲锋中认真设计原则被抛在脑后。但是，作 为各个软件开发团队，大家都一样。高效能的团队在成功之余不失英雄本色：正相反，当压力出现时，他们岿然不动，以自身深厚的功底成功化解任务。我们无数次 听到过高压下出高成就的传奇故事—要么是军事行动、专业运动，要么是飞行员在河上强行降落—其中的原因无非是英雄们的那句话，“我们受过专门训练”。</p>    <h3><strong>5. 误解：开发人员应该全权负责自己的代码。</strong></h3>    <p>负责自己的代码，听起来很正确。理所当然的。个人职责嘛。可是，开发团队里在代码上分配归属人就意味着每个模块的程序只有一个开发人员来写，只有一 个人能掌握。这会导致负责模块的程序员之间产生“地方保护主义”。对于公司老板来说，这造成了很大的风险，因为团队中损失一个人就会影响整个团队的进程， 如果这个人是负责系统的关键核心模块的，那更会造成公司业务瘫痪。健康的工作方式是让每个程序员都经手过系统内的所有代码。结对编程能让你实现这个效果， 知识会从一个人传递到另一个人。所谓的“ 巴士指数 ”(团队中的多少人被车撞才会导致大家都无法进行)是一个软件创业公司的关键风险指标。我们这里所说的不仅仅指的是巴士在使坏，还有你的竞争对手，他们乐衷于挖走你最好的程序员。理解整个系统的人越多，你的公司就越健壮，越有活力。</p>    <h3><strong>6. 误解：你需要一个怪异的招聘过程。</strong></h3>    <p>你会在雇用一个演员时不进行试镜吗？如果要试，你就能短暂的做一回导演。这正是如今几乎所有的公司在招聘程序员时会出现的场景。通常的面试都会谈论 应聘者的经验。这就完了。你可以想象一下，问一个踌躇满志的演员是否喜欢饰演哈姆雷特这个角色。你能传神的扮演他吗？好的。你被雇用了！很多著名的软件公 司喜欢给应聘者出脑筋急转弯题。有些顶级的公司甚至给候选人进行IQ测试。他们中最可取的是在白板上模拟软件问题，让候选人解决。这些情况让人很无奈。我 要说的是这非常明显的道理：招到好的程序员的唯一可靠的方法就是跟他们一起编程。我对程序员的面试是跟他们进行一个小时的快速的结对编程—而且这只是面试 的一个开始。大量的筛选，把他们按满分100打分。什么样的会被选中？思维敏捷，抽象思考能力强，掌握各种算法，问题解决能力强。而最重要的是，领会能 力。因为协作是对团队来说最重要的东西，如果你不能理解其他人是如何思考的，再聪明也没用。</p>    <h3><strong>7. 误解: 专业化很重要。</strong></h3>    <p>非常自然的，管理者遇到问题时习惯把问题分解，各个击破。在开发团队里，这通常怂恿技术人员专项发展。前端开发， 后台开发，数据库管理员等等。 Brad Feld  在他的博客里建议说，每个团队里都应该有个“全能程序员”，这个人是个真正的通才。他是对的，但他说的还不够。每个团队里的每个成员都应该是 通才全才 。为什么？因为专才导致团队脆弱。还记得“ 巴士指数 ” 吗？每个专才都是一个弱点；如果他离开了，你找不到替代他的人，你完了。不仅如此，它还能使团队机能失调。专项的人需要把他们负责的系统里相互独立的模块 通过定义好的接口相互通信。事实上，他们每人都写出了各自不统一通信方式。这导致了大量的额外开销，经常会出现“地方保护主义”或相互指责。而在著名的 Pivotal公司，每个程序员都要接触到系统的各个层面，从HTML和JavaScript到Ruby，到数据库。而有些人认为专才会在系统的某个层面 上更专业的，这种说法未必站得住脚。如今的软件技术变得已经不是那么复杂了。程序员能更容易的掌握各个层面上的知识以及如何操作它们。顺便说一下，这暗示 出了另外一个非常重要的信息：你不再需要为某个特殊的技术而招聘人才了。缺少Ruby程序员？好，招一个Java程序员，培训他使用Ruby(这里使用结 对编程格外的有效)。有些人称自己为“服务器端”程序员？没问题，让他们写JavaScript程序，他们很快就能学会。</p>    <p> </p>    <p> </p>    <p>来自：http://www.androidchina.net/5620.html</p>    <p> </p>