如果Scrum不行，那到底什么才行？

2018 年 4 月 23 日 聊聊架构 Adam Ard

策划｜ Gary

编辑｜ Alice

1.软件构建工作具有不可预测性

由于存在这种固有的不可预测性，因此大家不应对版本的预期发布时间及功能列表作出过于严格的限制。事实上，即使是增派人手往往也解决不了问题。正如 Fred Brooks 的著名言论，“为已经延期的软件项目增派人手，只会进一步加剧其延期问题。”这样的事实非常残酷且令人头痛，导致很多工作变得异常艰难；（对未来版本进行营销、签订谈判合同以及创建产品路线图等等。）但忽视这一前提则将引发冲突甚至更为严重的异常。

流程建议：

选定较为合适的发布周期，例如每月一次，而后定期发布您已经完成的部分；
选定一组功能并将其完成时间作为新版本的发布时间；
宣传您已经有的，别宣传您将会有的；
不要过度依赖于长期发展路线图，因为一切都有可能发生改变；
不要强迫程序员们承诺在冲刺期限或者特定时间之前完成某些功能。

2. 流程也有成本。其总会对生产力及道德产生影响——且往往极为显著

所有的流程都是有成本的。最轻松、最简洁的流程总是最好的——大家可能对自己实际需要的流程之少感到相当惊讶。另外需要强调，程序员的主要动力源自自我管理与自我激励。

流程建议：

别想着追踪一切。这通常会带来不必要的额外流程及工具；
允许每位程序员使用其最喜爱的工具进行任务追踪——具体包括便笺、纸笔或者软件。总之只要其效率合理，就不要过多介入；
程序员们最适应扁平化的组织结构。事实上，很多有前瞻性的企业都能够在无需管理者的情况下良好运转（例如 Valve、Medium、Zappos 以及Treehouse 等）。

3. 软件从不会真正“完成”。其总是在趋近于完成，但只能无限趋近

软件当中总会存在 bug，您总需要对用户体验作出调整，总会存在需要清理的代码，您也总需要编写更多测试、说明文档乃至更多工作。您必须判断何时停止进一步调整。因此，“完成”这样的定义并不确切。

流程建议：

不要试图收集指标或执行标准以自动执行“完成判断”；
在这个问题上，相信程序员们的直觉、自尊心以及威胁。这将推动产品达到足够的质量水平，且保证他们的工作不受干扰。

4. 程序员需要长时间不间断集中注意力

在理想情况下，程序员既可以远程工作、又可以拥有个人办公室，或者二者兼而有之。只要可能，协作应该是异步加联机并重，远程与本地齐行，同时为讨论项目保留永久记录。

流程建议：

即使众多程序员在同一间办公室内工作，每个人也都可以在线组织会议；
尽量少使用视频 /语音工具（Hangouts、Skype、FaceTime 等），多使用不打扰他人的异步工具（IM、电子邮件、内部版 Reddit 以及 IRC 等）；
避免将办公室布置得太过开放，为每个人保留一点私人空间。

5. 编码更像是设计或艺术，而非生硬制造

大家可以想象，如果我们要求雕塑家估计完成一尊雕像的手臂部分所需要的时间，或者要求其承诺在两周期限之内完成整座雕像——这明显非常荒谬。雕塑家拥有完全自我的实现过程。他也许首先会勾勒出自己的思路，甚至会在真正动手之前先用石膏构建一个完整的版本。这些工作最好交给他独自完成——换言之，硬要介入只会给他带来挫败感、低下的质量以及工期滞后等影响。

对于创意工作者们来说，这一点无疑非常重要，而必须强调的是，这一点同样适用于软件编写工作。每一位程序员都有自己的工作方式。有些人喜欢画类图，有些人则喜欢先进行原型编码设计。有些采取自上而下的方法，有些则使用自下而上的方兴未艾。由于创建软件中存在着巨大的复杂性，因此大多数程序员都已经拥有自己的一套完备的测试工具与技术，能够很好地解决这一复杂问题。别干涉，再说一次，别干涉。

此外，与设计师及艺术家们一样，大家应当信任程序员们有能力作出正确的产品决策。正如架构师负责决定在蓝图上绘制多少门窗一样，程序员们也可以制定功能决策，这将有助于实现高效且对接紧密的最终产品。从历史角度看，最成功的软件企业都是由一群才华横溢的程序员们所组成，他们能够在无需产品导向的情况下顺畅运作。

流程建议：

为程序员分配责任区域而非具体任务，他们会知道如何解决问题。如果这些任务处于某人的责任范围之内，则不要浪费时间将其估算、规划或者设计成团队任务；
将协作规划与设计限制为个别程序员职责之间的接口；
如果某一责任范围内必然存在多位成员，则应指派一名程序员作为负责人，并为其分配完全行政权力。其他人可以向其提交建议，从而以拒绝或接受的方式判断最适合在开源项目当中展示的质量与模式；
让产品部门成为向程序员提供反馈与信息的服务组织，但永远不要直接指导或管理他们的工作。等他们主动打电话来询问接下来要实现的功能是什么。