confluence 流程_更好的Web开发工作流程：Confluence，Airtable等

confluence 流程

Working as a front-end developer for nearly two years, I’ve got helpful experience from being part of several web development projects of design/digital agencies.

作为前端开发人员将近两年，我从参与设计/数字代理机构的多个Web开发项目中获得了有益的经验。

One obvious but valuable lesson I’ve learnt is that collaborating between each groups with one goal but distinct responsibilities and purposes is not easy. There’re different aspects and levels of difficulties in terms of collaboration, and the specific part of which I’d like to address here is workflow process.

我学到的一个明显但有价值的教训是，要在每个小组之间达成​​一个目标，但要明确职责和目标，要进行合作并不容易。 在协作方面存在不同的方面和难度级别，在此我要解决的特定部分是工作流程。

Based on my experience, and with the help from my designer and developer friends, I built a website development workflow designed for small team (5–15 people). The system is composed of Confluence, Jira, Airtable and Abstract. In this article, I’ll share the why and how of the this workflow.

根据我的经验，在设计师和开发人员朋友的帮助下，我建立了一个专为小型团队(5至15人)设计的网站开发工作流程。 该系统由Confluence ， Jira ， Airtable和Abstract组成 。 在本文中，我将分享此工作流程的原因和方式。

建立新工作流程的动机 (Motivation for building a new workflow)

To deliver a customized website without using templates provided by website builders, the minimum talent requirements includes a designer, developer and project manager. After participating in a couple of cases, I had a sense that there was something wrong with the workflow we had: important information was always not aligned both internally between different roles and externally to the client. This inefficient communication was clearly slowing down the development cycle and hurting the team.

要交付不使用网站建设者提供的模板的自定义网站，最低人才要求包括设计师，开发人员和项目经理。 参加了几次案例后，我感到我们的工作流程出了点问题：重要的信息始终不会在内部在不同角色之间以及在外部与客户保持一致。 这种低效的沟通显然在拖延开发周期并伤害了团队。

So I started to solve this problem.

所以我开始解决这个问题。

I Google searched resources about establishing and improving a workflow. Though I learned a lot from all the great resources, I found nearly none of which was for web development projects in a design/digital agency. It was either a design system or coding guidelines that scoped in design or front-end roles, or a workflow that was built for a team with its own product.

Google搜索了有关建立和改进工作流程的资源。 尽管我从所有的宝贵资源中学到了很多东西，但是我发现几乎没有一个是用于设计/数字代理中的Web开发项目的。 它既是设计系统或编码准则，其范围仅限于设计或前端角色，或者是为拥有自己产品的团队构建的工作流。

As a result, I decided to cherry pick the parts I needed to solve our problems, and formed a customized workflow for website development.

结果，我决定挑选解决问题所需的零件，并形成了用于网站开发的自定义工作流。

问题与目标 (Problems and goals)

Following are the problems I inspected from our existing workflow, and the corresponding improvement goals:

以下是我从现有工作流程中检查的问题以及相应的改进目标：

1.瀑布方法 (1. Waterfall methodology)

Problem: Based on my experience, website projects adopt a waterfall approach because clients don’t have a concept of a minimum viable product (MVP). Instead of splitting functionalities from views and modulization, clients tend to think about the site in a traditional page-by-page way, which forces both designers and developers to work page by page in sequence. This causes them to lose a universal perspective across the project. This situation results in lots of back-and-forth redundant revisions between pages.

问题：根据我的经验，网站项目采用瀑布式方法，因为客户没有最低可行产品(MVP)的概念。 客户倾向于从传统的逐页方式考虑站点，而不是从视图和模块化中拆分功能，这迫使设计人员和开发人员都按顺序逐页工作。 这使他们在整个项目中失去了普遍观点。 这种情况导致页面之间有很多来回的冗余修订。

Goal: Changing the mindset of clients is both arrogant and unrealistic. The goal is to find a way to separate requirements from views as soon as possible and develop in as as modulized a way as possible internally based on page-by-page model.

目标：改变客户的观念既傲慢又不切实际。 目标是找到一种方法，以尽快从视图中分离需求，并基于逐页模型在内部尽可能以模块化的方式进行开发。

2.由设计人员和开发人员共同管理的通用设计令牌和组件 (2. Universal design tokens and components managed by both designers and developers)

Problem: This is a common issue that a lot of articles have shared great solutions to, which mostly propose building a design system that’s managed by style guide/library generators. Though it is great solution, managing an extra site that barely provided edit permission to designers was not appropriate in our situation.

问题：这是一个常见的问题，很多文章都对此提出了很好的解决方案，其中大多数提议建立一个由样式指南/库生成器管理的设计系统。 尽管这是一个很好的解决方案，但在我们的情况下，管理一个几乎不向设计人员提供编辑权限的额外站点是不合适的。

Goal: Except for creating universal design tokens and languages that designers, developers and managers can all understand, build a system that allows everyone to manage the assets in a synchronous way.

目标：除了创建设计人员，开发人员和管理人员都可以理解的通用设计令牌和语言之外，还要构建一个系统，使每个人都可以以同步方式管理资产。

3.准确，更新的进度仪表板 (3. Accurate, updated progress dashboard)

Problem: Though issue trackers, kanban, and more project management models are useful and practical, most of them failed to act as a straightforward, flexible and friendly progress dashboard. This kind of dashboard would save the team a lot of time because it would prevent team members from actively reporting or asking about the current situation of specific tasks. It also makes managers’ lives easier if they have a clear knowledge of the entire project without too much effort.

问题：尽管问题跟踪器，看板和更多的项目管理模型是有用且实用的，但它们中的大多数未能充当简单，灵活和友好的进度仪表板。 这种仪表板将为团队节省大量时间，因为它将阻止团队成员主动报告或询问特定任务的当前状况。 如果管理人员对整个项目有清楚的了解而无需付出过多的努力，也可以使他们的生活更轻松。

Goal: Build a dashboard system that provides edit permission for individuals in charge of specific tasks.

目标：建立一个仪表板系统，向负责特定任务的个人提供编辑权限。

工作流程图 (Workflow diagram)

Before we dive into the detail introduction of the management tools stack, let’s take a look at the abstract simplified workflow I organized. It’s pretty much just a visualization of a normal workflow that most agencies have, but there’s two points to be noted here.

在深入介绍管理工具堆栈的详细介绍之前，让我们看一下我组织的抽象简化工作流程。 它几乎是大多数代理机构正常工作流程的可视化，但是这里有两点需要注意。

1.开发人员评估 (1. Developer evaluation)

First, when requirements or issues coming from the client are approved and documented by manager, with the exception of sending the task to a designer, they also go to a developer for evaluation. In this process, the developer reviews the specification of the task, checking if there are any rather complicated functions or features included. If it’s positive, the developer could start working on it or notify the designer about the potential problems beforehand.

首先，当来自客户的需求或问题由经理批准并记录下来时，除了将任务发送给设计人员之外，他们还向开发人员进行评估。 在此过程中，开发人员检查任务的规格，检查是否包含任何相当复杂的功能。 如果是肯定的，则开发人员可以开始进行开发，也可以事先通知设计人员潜在的问题。

2.真理的单一来源 (2. Single source of truth)

Also notice that after design deliverable is approved by the client, and before handing the task over to the developer’s hand, it goes through a process of register/modify/delete over design store conducted by the designer. This is because the developer should always be exposed to one and only one source of design store, which contains constantly maintained and updated assets ready for development.

还要注意，在客户批准设计交付物之后，在将任务移交给开发人员之前，它要经历由设计师执行的在设计存储中进行注册/修改/删除的过程。 这是因为开发人员应始终接触唯一的一个设计商店资源，其中包含为开发而不断维护和更新的资产。

Now we can dive into the management tools stack I prepared and see how the tools help us solve our problems.

现在，我们可以深入研究我准备的管理工具堆栈，看看这些工具如何帮助我们解决问题。

工具堆栈 (The tools stack)

After experimenting with various options on the market, the stack I’m proposing here is composed of Confluence, Jira, Airtable and Abstract. In addition to basic introduction and few key application examples, I’ll not cover all the details of using the tools.

在尝试了市场上的各种选择之后，我在这里提出的堆栈由Confluence ， Jira ， Airtable和Abstract组成 。 除了基本的介绍和一些关键的应用程序示例之外，我不会涵盖所有使用工具的细节。

Note: the system assumes that the development team adopts the atomic design methodology and ABEM naming system.

注意：系统假定开发团队采用原子设计方法和ABEM命名系统。

1.合流 (1. Confluence)

Role: information and resource center

角色：信息和资源中心

Though it’s intimidating at first, Confluence provides a powerful workspace that’s easy to organize, and it has tons of features, integration of apps, and customized templates. It’s definitely not a universal solution to all problems, but it’s perfect for documentation of specifications, requirements, meeting notes and more.

尽管起初令人生畏，但Confluence提供了一个易于组织的强大工作空间，并且具有大量功能，应用程序集成和自定义模板。 它绝对不是解决所有问题的通用解决方案，但是非常适合规范，要求，会议记录等文档。

Therefore, Confluence in this stack works as an information and resource center, which means every related link and detail about this project should be documented properly in here.

因此，该堆栈中的Confluence充当了信息和资源中心的角色，这意味着应在此处正确记录与该项目有关的所有相关链接和详细信息。

My favorite advantage of Confluence is the ability to customize document templates. This feature makes it really convenience to standardize the workflow.

我最喜欢Confluence的优点是能够自定义文档模板。 此功能使标准化工作流变得非常方便。

示例：组件 功能审查 (Example: Component functionality review)

I mentioned the developer evaluation process above, which is actually a complicated job. This is because this process includes basic information of the component, a developer’s FSM review (if necessary), FAQ space and more. But the flexibility of the template and tools Confluence provides makes this super easy. Just build a template in configuration settings and you’re good to go.

我在上面提到了开发人员评估过程 ，这实际上是一项复杂的工作。 这是因为此过程包括组件的基本信息，开发人员的FSM评论 (如有必要)，常见问题解答空间等等。 但是Confluence提供的模板和工具的灵活性使此操作非常容易。 只需在配置设置中构建模板，就可以了。

2.吉拉 (2. Jira)

Role: issue tracking and action type management

角色：问题跟踪和操作类型管理

Also a member of the Atlassian family, Jira is a super powerful issue tracking and project planning software. My favorite part about it is making customized issue workflows. Since there are tons of great tutorials on how to utilize power of Jira, the only thing I want to point out here is using issue type as mentioned below.

作为Atlassian家族的成员， Jira是一款功能强大的问题跟踪和项目计划软件。 我最喜欢的部分是制作定制的问题工作流程。 既然有大量关于如何利用Jira的功能的出色教程，我在这里要指出的唯一一件事就是使用如下所述的问题类型。

示例：按问题类型向开发人员更新设计存储的更改 (Example: Update developer on changes of design store by issue type)

To ensure that developers are building the components based on correct design views, they need to be notified whenever something in the design store is being updated, which includes actions like register, modify and delete. So, as a component is updated, the designer should open an issue with the responsible developer assigned and the correct issue/action type selected.

为了确保开发人员基于正确的设计视图来构建组件，每当更新设计存储中的某些东西(包括诸如register，modify和delete之类的动作)时，都需要通知他们。 因此，随着组件的更新，设计人员应在分配有责任的开发人员并选择正确的问题/操作类型的情况下打开问题。

3.空气表 (3. Airtable)

Role: component management and progress dashboard

角色：组件管理和进度仪表板

Airtable, a mixture of spreadsheet and database, is the thing that makes this stack work. There’s two amazing features that support my workflow: four types of view transition in single table and related content linking. I’ll showcase two examples of using these two features here.

Airtable是电子表格和数据库的混合体，是使此堆栈正常工作的要素 。 有两个惊人的功能支持我的工作流程：单表中的四种视图转换和相关的内容链接。 我将在此处展示使用这两个功能的两个示例。

示例1：组件管理 (Example 1: Component management)

How do you manage your component library? We chose not to use a style guide generator, because it’s not accessible for designers to edit. Using the Sketch component library wasn’t appropriate either, because it’s has too many limitations if we tried to use it outside the scope of the software itself.

您如何管理组件库？ 我们选择不使用样式指南生成器，因为设计师无法对其进行编辑。 使用Sketch组件库也不合适，因为如果我们尝试在软件本身范围之外使用它，则存在太多限制。

I wouldn’t say Airtable is a perfect solution, but it’s the easiest and most flexible option I could think of. Take a look at the demo template of the component management table here:

我不会说Airtable是一个完美的解决方案，但这是我能想到的最简单，最灵活的选择。 在这里查看组件管理表的演示模板：

Once a newly registered design view that’s ready to be developed programmatically is submitted to the developer, they would asses the view based on the ABEM system, and register it into the table. There are 9 columns in the table, including:

将准备好以编程方式开发的新注册设计视图提交给开发人员后，他们将基于ABEM系统评估该视图并将其注册到表中。 表中有9列，包括：

1. Name: naming of the component in ABEM principle

1.名称：按照ABEM原理命名组件

2. Preview: screenshot or exported image of component

2.预览：组件的屏幕截图或导出的图像

3. Linked page: link to the page contains this component

3.链接页面：链接到包含此组件的页面

4. Children component: link to children components contains this one

4.子组件：链接到子组件包含此组件

5. Modifier: checks if there’s style variations (ex: — active, — red)

5.修饰符：检查样式是否有变化(例如：-启用，-红色)

6. Component category: a general category classification (ex: text, hero, sidebar)

6.组件类别：常规类别分类(例如：文本，英雄，侧边栏)

7. Development status: status of development progress (pending, assigned, in progress, complete, in revision)

7.开发状态：开发进度的状态(待定，已分配，进行中，完成，正在修订中)

8. Assignee: developer responsible for this component

8.受让人：负责此组件的开发人员

9. Atomic level: atomic category of this component (atom, molecule, organism)

9.原子水平：此成分的原子类别(原子，分子，生物)

The best thing here is that you can reference data in both the same and other tables. This connection of dots prevents things from getting messier as the scale grows. Also notice that you can filter, sort and change views easily.

最好的是，您可以在同一表和其他表中引用数据。 点的这种连接防止事物随着比例的增长而变得混乱。 还要注意，您可以轻松地过滤，排序和更改视图。

示例2：页面开发状态 (Example 2: Page development status)

Since the assumption here is that we’ll inevitably asses development progress page by page, a table template designed for this purpose is necessary. This table can be a progress dashboard for both internal teams and shared with client at the same time.

由于这里的假设是我们不可避免地要逐页评估开发进度，因此为此目的设计一个表格模板是必要的。 该表可以是内部团队的进度仪表板，也可以同时与客户共享。

Any information about the page, including deadline, InVision prototype link, assignee, and children component can be organized here. Note that it’s very convenient to document and update design, front-end, and back-end development status at the same time.

可以在此处组织有关页面的任何信息，包括截止日期，InVision原型链接，受让人和子组件。 请注意，同时记录和更新设计，前端和后端开发状态非常方便。

4.摘要 (4. Abstract)

Role: single source of truth and design assets version control

角色：真相和设计资产版本控制的单一来源

Abstract is GitHub for Sketch assets that saves designers from the hell of copying and pasting files. It’s out of this article’s scope to demonstrate details of managing version control flow. The key takeaway here is that Abstract is the design store that acts as the single source of truth. Designers should keep updating master branch to the latest version of confirmed design and then notify developers. On the other hand, developers should only take design assets in the master branch as reference.

摘要是适用于Sketch资产的GitHub ，可将设计师从复制和粘贴文件的繁琐工作中解救出来。 演示管理版本控制流的详细信息不在本文的讨论范围之内。 这里的关键要点是，摘要是充当真理唯一来源的设计商店。 设计人员应继续将master分支更新为已确认设计的最新版本，然后通知开发人员。 另一方面，开发人员应仅将master分支中的设计资产作为参考。

还有更多工作要做 (More work to be done)

From my own experience, development of the entire project after adopting this new workflow has been at least two times faster than before. It’s not a perfect solution, because it still requires lots of manual labor to update and maintain.

根据我自己的经验，采用此新工作流程后，整个项目的开发至少比以前快了两倍。 这不是一个完美的解决方案，因为它仍然需要大量的体力劳动来进行更新和维护。

But I think it could be aa helpful reference to website development teams searching for aa better workflow, and hopefully more people can share their workflows in the future!

但是，我认为这对于网站开发团队寻求更好的工作流程可能是一个有用的参考，希望将来有更多的人可以共享他们的工作流程！

---

---

中文版連結 (Chinese version)  / Originally posted on vinceshao.com

中文 版连结(中文版) /最初发布于 vinceshao.com

翻译自: https://www.freecodecamp.org/news/a-better-web-development-workflow-confluence-airtable-jira-abstract-e626ef4ff5bc/

confluence 流程