正文
6、开发组长复查了这个 pull request，毙掉了它并给出 17 条解释：代码性能很差、有个边界情况方法没有考虑到、整个类读起来像在读恐怖小说、并且完成的功能跟一开始的定义根本不沾边。
7、程序员和组长反复拉锯，重写了两遍代码，两天后他们都对修改后的结果满意了。
8、代码当天就被合并部署到产品中了。
9、几天后主管们看到一堆全新的版本更新说明，对这轮冲刺（sprint）中所有事情都很满意，但其中一位奇怪为什么他提的需求没实现。他开始重复第 2 步。
很显然这并不明智。这就像是翻版的
传话
游戏、看图说话或者 20 猜，作为游戏玩玩还不错，拿来运作公司就太扯了。而实际上，硅谷精英们还在宣扬这种方式，敏捷教练还在鼓吹它，而年轻的团队还把它当作默认工作方式。
我们可以做得更好，现在从第一步开始重来。
在 DirectScale，我们不会雇佣一群想法哥，围坐在一起编故事让我们实现。我不想戳破这个现实，但很抱歉，实际上并没有“想法哥”这个职位。事实是人人都有想法。关于你的产品如何提高以及解决什么问题，人人都能贡献好点子。而公司可以选择鼓励或者打压这些想法。大部分公司选择了打压，即便是以不起眼的方式：把程序员和设计人员排除在产品特性讨论之外，让中间人来传递指示和需求，或者把程序员的异议当作“懒惰”或者“抱怨”。
更好的方式是确保开发流程中每个阶段各方的意见都能顺畅表达，每次会议、每个功能点，从始至终都应如此。与其等到下次冲刺才发现你的新特性在技术上不可行，为什么不现在就去发现它呢？当然这意味着你的程序员要离开键盘（停止编码）很长时间，但如果你征求并听取他们的意见，他们就会鼎力相助，为团队共享的愿景付出，对产品特性负责，从而更好更快地完成他们自己的工作。新功能规模越大，需要的支持越多，也就需要更多程序员加入讨论。
如我之前提到的，这样做同样可以防止你浪费好几天的时间构想出一个新功能，但程序员不能（或不应该）这么实现。大部分人都有过这种经历，即看上去简单明了的功能有时候会超乎想象地复杂，不可能做到或者根本不应该这么搞。没人愿意等到功能发布日期确定以后再意识到这件事。
我最近参加的一次会议是关于一个大功能集的
Design Studio
，这关乎到 DirectScale 未来几年内最大的一笔收入来源。这也是我们一整年内讨论过的最重要的纵向产品。猜猜谁参加了？
-
一个用户体验（UX）设计师
-
三四个程序员
-
一个美术设计师
-
我们的产品经理
上级并没有给出我们要构建的功能细节，也没有任何 C 什么 O 或者副总参加会议。就只有我们。为什么不呢？我们是有备而来的：我们的 UX 设计师和产品经理都具备行业经验，并同几位功能集的潜在用户聊过。领导层已经表达了他们对功能集的期望（并不涉及对创作过程的控制）。我们已经有过几次讨论，限定了要解决的问题范围。而且毕竟这些东西最终要由我们来实现。
两个半小时以后（比一般的会议要久，但很值得），我们画了一些草图，对这个问题的理解达成了初步的共识，每个人都很满意我们的意见会成为最终结果的一部分。这就是我们的产品从无到有的过程。
一旦我们的想法有了雏形，我们就准备好编码了。但我们仍没打开 IDE 呢。
瞧，软件构建是一门遗失的艺术。Steve McConnell，《代码大全》（Code Complete）的作者，激情洋溢地花了数章的篇幅来讨论从业务需求创立后到真正开始编码前的过程——据他描述，这个过程是对每个类、接口、交互和数据节点的详细设计，要由办公室中最优秀的架构师来完成。McConnell 的观点是，如果编码时只有用户故事（user story），就好比没有蓝图就去盖一座摩天大楼一样。
但不知何故，大部分公司都忘了该怎么设计。
