如何快速前进

本文面向所有从事软件行业、希望生活简单、压力小，同时又能让雇主满意的人士。你将了解如何通过做出简单的选择，并遵循易于理解、行之有效的原则，顺利交付软件，避免让所有人在开发过程中精疲力竭。

公司随意给了你的团队一年的时间来开发一个网站，而他们有很多宏伟的想法。不要试图在前期投入大量时间去规划，去设想围绕这些雄心勃勃的目标构建庞大的架构和待办事项。这只会走向失败、过早优化和违背承诺。

您唯一能做出的承诺是，您将每两周展示一次您所做的事情，并接受业务部门针对实际问题而非功能决策的指导。

我们知道快速发展很重要，但我们构建的系统的质量以及团队的心理健康也同样重要。我们会快速发展，但始终以可持续的方式进行。

我们不想因为大规模发布而感到压力，不想进行令人恐惧的大规模重构，也不想为我们可能永远不会真正做的工作的无关估计而烦恼。

迭代

从 hello world 开始，全面部署并持续交付。

我们始终希望团队能够专注于一个小型而专注的愿景。开发小项目很容易，而且更有可能成功。

考虑提供大量的功能会导致团队过于复杂，并使决策变得困难。

由于许多功能尚未确定，团队规模扩大的诱惑也随之而来，这也拖慢了进度。参见：《人月神话》

相反，我们会根据业务专业知识、研究、开发人员的专业知识和用户的反馈来研究下一个最重要的事情。

我们将无限期地持续迭代地提供小功能。

规则和原则

1 个小型同地团队

小团队比大团队交付速度更快，因为沟通渠道少，一次性完成的工作量也小。大团队同时处理多项工作，容易造成混乱和复杂性。

让多个小团队负责明确划分的任务是可行的，但需要良好的协调。一旦产品成熟，按照架构划分这些团队就会容易得多。我认为，把一个充满未知数的新项目分给多个团队是错误的，因为此时架构需要非常灵活，因此各个团队无法独立工作，彼此之间会相互耦合。

根据我的经验，能够轻松地与他人沟通非常重要。与同事轻松交谈，对于打破分享想法和建立关系的障碍至关重要。对我来说，这就是为什么我更喜欢在同地办公的团队中工作，因为它可以最大限度地减少沟通摩擦。

大部分时间都是结对编程

结对编程能帮你编写出更好的软件，并促进技能、想法和领域知识的交叉融合。它还能帮助你的团队壮大，改善人际关系，最终让每个人都更快乐！

不过，不要强制从早上 9 点到下午 5 点工作，因为这样很快就会让人很累。人们需要时间和空间去思考。

没有分支，没有拉取请求

你的团队规模很小，正在进行结对工作。你们应该一直保持沟通，这样就不需要通过拉取请求来检查代码是否正确。最好是先交付代码，然后再获取反馈。你应该相信两个人在大多数情况下都能把事情做好。

对于开源项目来说，拉取请求 (Pull Request) 非常实用，因为您无需完全信任所有贡献者。在小型团队中，您不需要拉取请求，而且您需要通过减少软件编写的繁琐程序来充分利用紧密的反馈循环。

这些规则的一大主题是消除反馈循环的障碍，这意味着我们可以轻松地更改软件。有人发布不理想的代码并不意味着世界末日，只需修复它并继续前进——不要引入拖慢一切的复杂流程。

拥有最小部署管道

维护管道和各种非实时环境可能会变得繁重。至少在项目开始时，你真正需要的是：

1. 运行测试
2. 部署上线
3. 运行冒烟测试

如果你发现自己试图证明一个非现场环境的合理性，那么问问自己

• 我无法在本地或生产环境中测试什么？为什么？
• 只能在特定环境中测试某事物会有哪些成本和后果？
• 这会对生产运输造成什么延误？

大多数时候你可能无法很好地回答这些问题。

持续交付绿色建筑。

这将为您提供：

• 快速反馈
• 强制你进行自动化测试
• 强制你编写可交付的代码
• 迫使你进行良好的监控
• 让发布变得轻松无压力

关于这一点已经有很多文章进行了论述。

并被证明是高效团队的工作方式

手动运送一周或两周的工作需要时间并且有风险；不断发布小东西很容易，而且风险较小。

编写测试

它们能让你自信地快速迭代。没有它们，就无法实现持续交付；如果必须一直手动检查，就无法快速完成。

单体式架构，而非微服务

编写分布式系统是一件痛苦的事，我宁愿避免这种痛苦，直到我真正需要分布式我的系统。换句话说，就是 YAGNI。

重构进程内方法调用比修改 API 调用容易得多。部署一个应用程序比协调多个系统部署等要容易得多。

我过去曾参与过微服务项目，但我的上一个项目是一个整体，而且我们的进展速度更快，因为我们解决了大量需要处理的问题。

为了实现微服务，您必须考虑如何将系统分解为小组件，从而顺利实现...

不要预先设计

只需发送一些代码，如果你制作了一些有用的东西并不断重构和迭代，设计就会从现实中出现，而不是开发人员在白板上争论。

持续重构

糟糕的代码会让你慢下来。糟糕的代码往往会变得更糟。所以要持续重构，不要搞个“重构冲刺”之类的蠢事。不要请求许可，如果代码不好，直接修复就好。

单体应用中一半的问题都源于编写糟糕代码的人。如果你能维护代码质量，基于实际使用场景的抽象就会自然而然地出现，这样，当你需要拆分单体应用时，就会有显而易见的方法。

避免编写 SPA，采用渐进增强

SPA 带来了巨大的复杂性，而大多数项目并不需要。你可能不需要开发 Gmail，所以别再假装自己需要编写 SPA 了。你只需花 10% 的时间就能把 React 写进简历里。

相反，你应该使用渐进式增强技术，通过编写语义化的 HTML、CSS 修饰以及少量 JavaScript 来提升体验。更好的做法是，如果可以的话，不要编写任何客户端 JavaScript。

不要过分追求像素完美的设计

如果您的设计师过于注重其设计在每个浏览器中的像素完美度，那么编写 HTML 和 CSS 可能会很有挑战性并且非常耗时。

我们为用户编写代码，而不是为设计师编写代码，大多数时候他们不会关心 Firefox 与 Chrome 相比代码是否看起来有一点不同。

通过挑战什么对用户来说足够好来节省时间、精力和压力。

简单的设计易于实现，复杂的设计则难以实现。如果你的设计师给你的网页设计比较复杂，请提醒他们我们正在努力加快速度。

先发货 80%，然后再进行完善

与上述相关，如果事实证明某个功能并不需要，那么在设计和用户体验方面真正完善该功能完全是浪费时间。

我曾见过一个团队花费数周时间完善网站的搜索功能及其 JavaScript，但几个月后就被抛弃了，因为其基本理念从一开始就是错误的。

交付足够多的产品来获得反馈并证明这个想法，一旦你完成了，你就可以花时间完善它。

编写软件的人是支持该软件的人

这一责任必须与授权相结合，以使系统可维护。

如果创建系统的人面临凌晨 3 点因系统瘫痪而被报警的威胁，那么他们就更有可能交付更强大的代码。

使用成熟、经过验证的工具

如果你离开并且没有人能够构建或理解你的代码，那么即使你快速地开发出闪亮的东西也没关系。

团队应该就大家喜欢用什么语言编写适合当前任务的代码达成共识。不要选择一种大家都不熟悉的编程语言——记住，我们的目标是快速完成任务。

构建软件必须简单

运行和测试项目所需的设置应该尽可能少。仅仅因为几个月没人动过，或者关键人员离职，就无法构建项目，这是完全不可接受的。如果一个人花了一个多小时来设置项目，那你就彻底失败了。

借助 Docker 等技术，可以轻松配置项目，使其拥有所有第三方依赖项（例如本地可用的数据库）。

它不应该依赖于特定的计算机配置（除了安装一些关键组件，例如 JVM、Go 或其他）。它不能依赖第三方系统在本地运行和测试。

为了帮助实现这一点，请配置您正在使用的任何 CI 工具，以便每天早上自动构建软件；即使没有人承诺过这一点。

如果构建为红色，则停止

测试必须始终通过。如果测试不可靠，请停止并修复。过去，不稳定的测试已经浪费了我很多时间。

真正坐在用户旁边观察他们的工作

企业认为用户的需求和用户实际需要的往往大相径庭。我有幸亲眼见证了这一点，通过观察用户的实际使用情况，我们节省了大量的工作，并且能够找到一个他们真正想要的非常便宜、简单的解决方案，而不是企业提出的极其昂贵的解决方案。

用户故事是对话的起点

如果用户故事明确规定了要编写什么软件，那么是谁做的决定？为什么？他们怎么知道他们是正确的？

这种由“技术主管”或其他人决定如何编写软件的方法，会创造出幻想破灭的开发机器人，他们没有主人翁意识，而且他们的故事也会因为没有得到某些过度控制的领导者的认可而被“阻止”。

用户故事应该描述一个用户问题，当这个问题被提出后，团队会想出一个解决方案，然后执行这个方案，就这么简单。这样做成功的可能性更高，因为会有更多人思考这个问题，并让他们有参与感。

每张票都有某种成功的衡量标准，当收集到足够的数据/研究时应该进行验证。

了解我们都是软件开发人员

在我设想的公司里，如果你自认为是“后端”开发人员，结果因为“前端”开发人员生病而被封杀，那你就被解雇了。同样，如果用户体验设计师不在，而你又不想参与某个特定交互的最终结果，那也一样。

你应该对软件开发的各个方面都有所了解。这并不是说你必须成为所有方面的专家，但因为某个人不在而被阻碍是不可接受的。

你应该感到足够强大，可以尝试任何任务。即使不完美也没关系，因为最好交付 70% 完成度的产品，等专家回来后，你就可以对软件进行迭代改进。

我之前说的结对编程，并不单指“后端开发人员”之类的。每个人都应该参与其中。如果用户体验设计师正在访谈用户，他们有责任带其他人一起体验这项技能，并了解用户。这种知识共享对于让每个人感受到对项目和团队的投入至关重要。

有 10/20% 的时间

为每个人分配时间去做他们想做的事情，并严格执行。

我们从事创意行业，我们需要一些空间来呼吸、学习东西和尝试不同的想法。

这对团队来说是一项很棒的福利，可以帮助避免倦怠，并有助于带来新的想法，从而为您的系统带来很大的改进。

不要制定超过 6 周的详细计划

拥有未来的愿景固然有趣，但要保持模糊和雄心勃勃的愿景。记住，专注于一两个功能的团队远比纠结于十个虚构需求的团队效率更高。

没有 Jira，没有估算，没有计时，没有燃尽图

所有这些都浪费了大量的时间，造成了摩擦，而且在我的职业生涯中，我还没有见过一张燃尽图能提供任何真正有用的信息。

请记住，我们致力于频繁展示真实可用的软件，而不是那些充其量只是猜测的虚构图表。随意猜测是可以的，但为那些在未来 3 个月内不可能真正被审核的工单添加故事点是毫无意义的。

个体和互动高于流程和工具

一定要有一面简单的、物理的墙，上面列有准备开发、开发中和完成的内容，但如果超过这个数量，就会变得很愚蠢。

总结

快速行动的方法不是想象完美的产品、架构、设计积压然后执行它。

快速行动的方式是通过低努力、经过验证的方法快速迭代，并在迭代过程中学习时相互沟通。

优化你的流程，让你的团队能够无所畏惧地快速更改软件。这样，你就能在持续的反馈循环的引导下，构建出优秀的产品。

打造能够交付优秀产品的优秀团队，并没有万能的正确方法，但就我目前的经验而言，这些原则似乎行之有效。你的方法可能有所不同，这没关系，但要问问自己，你的团队是否已经达到了最佳状态。回顾过去，始终有助于你的团队适应新情况。