Linear 方法：原则与实践

注：Linear 是一款研发项目管理工具（https://linear.app）。

Principles

原则

Build for the creators

为创造者而建

Software project management tools should build with the end users – the creators – in mind. Keeping individuals productive is more important than generating perfect reports.

软件项目管理工具的建立应考虑到最终用户--创建者。让个体保持生产力比生成完美的报告更重要。

Opinionated software

带有偏见的软件

Productivity software should be opinionated. It's the only way the product can truly do the heavy lifting for you. Flexible software lets everyone invent their own workflows, which eventually creates chaos as teams scale.

生产力软件应该是带着偏见的。这是产品能够真正为你完成重任的唯一方法。灵活的软件会导致每个人都发明自己的工作流程，随着团队规模的扩大，这最终会造成混乱局面。

Create momentum – don't sprint

创造动力 -- 不要冲刺

We should find a cadence and routine of working. In cycles, we decide priorities and assign responsibilities. Our goal is to maintain a healthy momentum with our teams, not rush towards the end.

我们应该找到一个工作的节奏和规律。在工作周期中，我们决定优先事项并分配责任。我们的目标是与我们的团队保持健康的势头，而不是急于求成。

Meaningful direction

有意义的方向

Our daily work might be filled with tasks but we should understand and remind our teams of the purpose and long term goals of our work. Roadmaps, projects and milestones are all important to keep in mind as we plan our weekly schedules.

我们的日常工作可能充满了各种任务，但我们应该理解并提醒我们的团队，我们工作的目的和长期目标。在我们计划每周的时间表时，路线图、项目和里程碑都是需要牢记的。

Aim for clarity

力求清晰

Don’t invent terms if possible, as these can confuse and have different meanings in different teams. Projects should be called projects.

如果可能的话，不要发明术语，因为这些术语会使人混淆，在不同的团队中有不同的含义。项目应该被称为项目。

Say no to busy work

对繁忙的工作说不

Our tools should not make us the designers and maintainers of them. We should throw away or automate the busy work so you can focus on the more important work.

我们的工具不应该让我们成为它们的设计者和维护者。我们应该扔掉或自动处理那些繁忙的工作，这样你就可以专注于更重要的工作。

Simple first, then powerful

先简单，后强大

Teams at different sizes have different needs. Tools should be simple to get started with and grow more powerful over time.

不同规模的团队有不同的需求。工具应该是简单上手的，并随着时间的推移而变得更加强大。

Decide and move on

决定并继续前进

There isn't always a best answer. The important thing is to make a decision, and move on.

并不总是有一个最好的答案。重要的是要做出决定，然后继续前进。

Practices

实践

Set monthly, quarterly or/and annual roadmaps

设定月度、季度或/和年度路线图

Ambitious goals are the only way to make a significant impact. Companies should focus on them when they define their high level direction. Reserve some space on your roadmaps for unexpected and reactive work that always comes up and allow your roadmap to change if needed.

雄心勃勃的目标是产生重大影响的唯一途径。公司在确定其高层方向时应关注它们。在你的路线图上为总是出现的意外和被动工作保留一些空间，并允许你的路线图在需要时进行改变。

Connect daily work to larger goals with projects

用项目将日常工作与更大的目标联系起来

All projects and work should directly correlate to these goals. Review projects and their target dates during roadmap meetings and pull from projects as you plan cycles.

所有项目和工作都应该与这些目标直接相关。在路线图会议上审查项目和它们的目标日期，并在计划周期时从项目中提取。

Work in n-week cycles

以 N 周为周期开展工作

Cycles create healthy routine and focus teams on what needs to happen next. 2-week cycles are the most common in software building. They're short enough to not lose sight of other priorities but long enough to build significant features. Cycles should feel reasonable. Don't overload cycles with tasks and let unfinished items move to the next cycle automatically.

周期创造了健康的流程，并使团队专注于接下来需要发生的事情。2 周的周期是软件构建中最常见的。它们足够短，不会忽略其他优先事项，但也足够长，可以创建重要的功能。周期应该感觉合理。不要在周期中过载任务，以至于未完成的任务自动进入下一个周期。

Keep a manageable backlog

保持一个可管理的待办列表

You don't need to save every feature request or piece of feedback. Important ones will resurface and low priority ones will never get fixed. A more focused backlog makes it easier and faster to plan cycles, and ensures the work will actually get done.

你不需要保存每一个功能请求或反馈信息。重要的东西会重新出现，而低优先级的则永远不会被修复。一个更有针对性的待办列表可以让你更容易和更快地计划周期，并确保工作能够真正得到完成。

Mix feature and quality work

混合功能和质量工作

All software has bugs, more than we can ever fix. Include bugs and other fixes as part of your cycles. Invest in tooling as it is a force multiplier if done right.

所有的软件都有 bug，比我们能修复的要多。把 bug 和其他修复工作作为周期的一部分。对工具进行投资，因为如果做得好，它是一个力量的倍增器。

Specify project and issue owners

指定项目和问题负责人

Each project should have a named owner responsible to own delivery and write the project brief. The same goes for issues. Others should collaborate but responsibility should lie with a single person.

每个项目都应该有一个指定的负责人，负责交付和编写项目简报。对问题也是如此。其他人应该协作，但责任应该在一个人身上。

Write project specs

撰写项目规格书

Aim for brevity. Short specs are more likely to be read. The purpose of a spec is to briefly communicate the "why", "what" and "how" of the project to the rest of the team. Ideally these short documents force teams to scope out work so priorities are clear and teams avoid building the wrong thing.

力求简洁。简短的规范更有可能被阅读。规范的目的是将项目的"原因"、"内容"和"方法"简要地传达给团队的其他成员。理想情况下，这些简短的文件会约束团队确定工作边界，以便明确优先次序，避免团队建造错误的东西。

Understand your users

理解你的用户

The more popular your product, the more feedback you'll get. Overflowing inboxes are a good sign unless they're bug reports. Don’t worry too much about organizing all the feedback. Collect it and use it as a research library when developing new features. Try to spot trends. Use feedback, even complaints, as an opportunity to get to know your users and ask them to explain why they want a specific feature so you find out their needs. Solve the problem – don’t just build the feature.

你的产品越受欢迎，你得到的反馈就越多。溢出的收件箱是一个好兆头，除非它们是错误报告。不要太担心管理所有的反馈。收集它，并在开发新功能时将其作为一个研究库。试着去发现趋势。利用反馈，甚至是抱怨，作为了解你的用户的机会，请他们解释为什么他们想要一个特定的功能，这样你就能发现他们的需求。解决问题--不要只是建立功能。

Scope issues to be as small as possible

将问题的范围尽可能的小

It's hard to see visible progress when working on large tasks, which can be demotivating. Break down work into smaller parts and create an issue for each one when possible. Ideally you can complete several concrete tasks each week. It feels great to mark issues as done.

在处理大型任务时很难看到明显的进展，这可能会打击人的积极性。把工作分解成更小的部分，并尽可能为每个部分创建一个问题。理想情况下，你可以每周完成几个具体的任务。把问题标记为已完成的感觉很好。

Measure progress with actual work

用实际工作来衡量进展

The clearest way to see whether something is complete or not is to show the diff in the code or design file. When the tasks are scoped small, your changes will be small and easier to review, too. Avoid massive pull requests or large design changes.

看某件事情是否完成的最清楚的方法是在代码或设计文件中查看改变。当任务的范围很小时，你的改动也会很小，也更容易审查。避免大规模的代码合并请求或大的设计变更。

Run cross-functional teams

运行跨职能的团队

Designers and engineers should work together on projects, creating a natural push and pull. Designers bring their skills to explore ideas and push your team's thinking. Engineers can challenge thinking around implementation and will bring the winning ideas to reality. The best creators often have talent for both. Directly loop in other teams when building features they'll use or ask customers they interact with to use.

设计师和工程师应该在项目中一起工作，形成一种自然的推拉关系。设计师利用他们的技能来探索想法并推动你的团队的思考。工程师可以围绕实施方案进行思维调整，并将好的想法变成现实。最好的创造者往往在这两方面都有天赋。在构建功能或要求时，与这些功能的使用团队保持更新。

Write a changelog

撰写更新日志

It’s important to look back and celebrate what you achieved as a team. Consistent changelogs also communicate to the user new features, the value they get from your product, and your commitment to improving it. It's also an easy way to connect your team's individual work to the collective value they create.

回顾并庆祝你作为一个团队所取得的成就是很重要的。一致的更新日志还可以向用户传达新的功能，他们从你的产品中得到的价值，以及你对改进产品的承诺。这也是将你的团队的个人工作与他们创造的集体价值联系起来的一种简单方法。