document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-13 22:30:37 +08:00
Code Issues Packages Projects Releases Wiki Activity

update at 2017年 12月 19日 星期二 12:57:31 CST

Browse Source
This commit is contained in:
darksun 2017-12-19 12:57:31 +08:00
parent c69d987e9d
commit 5b02d87512
2 changed files with 56 additions and 57 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

57
sources/tech/20171212 Asynchronous decision-making- Helping remote teams succeed.md
View File

@ -1,57 +0,0 @@
translating by lujun9972
Asynchronous decision-making: Helping remote teams succeed
======
Asynchronous decision-making is a strategy that enables geographically and culturally distributed software teams to make decisions more efficiently. In this article, I'll discuss some of the principles and tools that make this approach possible.
Synchronous decision-making, in which participants interact with each other in real time, can be expensive for people who work on a [Maker's Schedule][1], and they are often impractical for remote teams. We've all seen how such meetings can devolve into inefficient time wasters that we all dread and avoid.
In contrast, asynchronous decision-making, which is often used in large open source projects--for example, at the Apache Software Foundation (ASF), where I'm most active--provides an efficient way for teams to move forward with minimal meetings. Many open source projects involve only a few meetings each year (and some none at all), yet development teams consistently produce high-quality software.
How does asynchronous decision-making work?
## Required tools
### Central asynchronous communications channel
The first thing you need to enable asynchronous decision-making is a central asynchronous communications channel. The technology you use must enable all team members to get the same information and hold threaded discussions, where you can branch off on a topic while ignoring other topics being discussed on the same channel. Think of marine radio, in which a broadcast channel is used sparingly to get the attention of specific people, who then branch off to a sub-channel to have more detailed discussions.
Many open source projects still use mailing lists as this central channel, although younger software developers might consider this approach old and clunky. Mailing lists require a lot of discipline to efficiently manage the high traffic of a busy project, particularly when it comes to meaningful quoting, sticking to one topic per thread, and making sure [subject lines are relevant][2]. Still, when used properly and coupled with an indexed archive, mailing lists remain the most ubiquitous tool to create a central channel.
Corporate teams might benefit from more modern collaboration tools, which can be easier to use and provide stronger multimedia features. Regardless of which tools you use, the key is to create a channel in which large groups of people can communicate efficiently and asynchronously on a wide variety of topics. A [busy channel is often preferable to multiple channels][3] to create a consistent and engaged community.
### Consensus-building mechanism
The second tool is a mechanism for building consensus so you can avoid deadlocks and ensure that decisions go forward. Unanimity in decision-making is ideal, but consensus, defined as "widespread agreement among people who have decision power," is second-best. Requiring unanimity or allowing vetoes in decision-making can block progress, so at the ASF vetoes apply only to a very limited set of decision types. The [ASF's voting rules][4] constitute a well-established and often-emulated approach to building consensus in loosely coupled teams which, like the ASF, may have no single boss. They can also be used when consensus doesn't emerge naturally.
### Case management system
Building consensus usually happens on the project's central channel, as described above. But for complex topics, it often makes sense to use a third tool: a case management system. Groups can then focus the central channel on informal discussions and brainstorming, then move to a more structured case management system when a discussion evolves into a decision.
The case management system organizes decisions more precisely. Smaller teams with fewer decisions to make could work without one, but many find it convenient to be able to discuss the details of a given decision and keep associated information in a single, relatively isolated place.
A case management system does not require complex software; at the ASF we use simple issue trackers, web-based systems originally created for software support and bug management. Each case is handled on a single web page, with a history of comments and actions. This approach works well for keeping track of decisions and the paths that lead to them. Some non-urgent or complex decisions can take a long time to reach closure, for example, and it's useful to have their history in a single place. New team members can also get up to speed quickly by learning which decisions were made most recently, which remain outstanding, who's involved in each one, and the background behind each decision.
## Success stories
The nine members of ASF's board of directors make a few dozen decisions at each monthly phone meeting, which last less than two hours. We carefully prepare for these meetings by making most of our decisions asynchronously in advance. This allows us to focus the meeting on the complex or uncertain issues rather than the ones that already have full or partial consensus.
An interesting example outside of the software world is the [Swiss Federal Council's weekly meeting][5], which runs in a way similar to ASF. Teams prepare for the meeting by using asynchronous decision-making to build consensus. The meeting agenda consists of a set of color-coded lists that indicate which items can be approved quickly, which need more discussion, and which are expected to be most complex. This allows seven busy people to make more than 2,500 decisions each year, in about 50 weekly sessions of a few hours each. Sounds pretty efficient to me.
In my experience, the benefits of asynchronous decision-making are well worth the investment in time and tools. It also leads to happier team members, which is a key component of success.
--------------------------------------------------------------------------------
via: https://opensource.com/article/17/12/asynchronous-decision-making
作者：[Bertrand Delacretaz][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://opensource.com
[1]:http://www.paulgraham.com/makersschedule.html
[2]:https://grep.codeconsult.ch/2017/11/10/large-mailing-lists-survival-guide/
[3]:https://grep.codeconsult.ch/2011/12/06/stefanos-mazzocchis-busy-list-pattern/
[4]:http://www.apache.org/foundation/voting.html
[5]:https://www.admin.ch/gov/en/start/federal-council/tasks/decision-making/federal-council-meeting.html

56
translated/tech/20171212 Asynchronous decision-making- Helping remote teams succeed.md Normal file
View File

@ -0,0 +1,56 @@
异步决策：帮助远程团队走向成功
======
异步决策能够让地理和文化上分散的软件团队更有效率地做出决策。本文就将讨论一下实现异步决策所需要的一些原则和工具。
同步决策，要求参与者实时地进行互动，而这对那些需要大块完整时间工作 ([Maker's Schedule][1]) 的人来说代价非常大，而且对于远程团队来说这也不现实。我们会发现这种会议最后浪费的时间让人难以置信。
相比之下，异步决策常应用于大型开源项目中(比如我常参与的像 Apache Software Foundation (ASF))。它为团队提供了一种尽可能少开会的有效方法。很多开源项目每年只开很少的几次会议(有的甚至完全没开过会)，然而开发团队却始终如一地在生产高质量的软件。
怎样才能异步决策呢？
## 所需工具
### 中心化的异步沟通渠道
异步决策的第一步就是构建一个中心化的异步沟通渠道。你所使用的技术必须能让所有的团队成员都获得同样的信息，并能进行线索讨论 (threaded discussions)，也就是说你要既能对一个主题进行发散也要能封禁其他主题的讨论。想一想 marine 广播，其中广播渠道的作用只是为了引起特定人员的注意，这些人然后再创建一个子渠道来进行详细的讨论。
很多开源项目依旧使用邮件列表 (mailing lists) 作为中心渠道，不过很多新一代的软件开发者可能会觉得这个方法又古老有笨拙。邮件列表需要遵循大量的准则才能有效的管理热门项目，比如你需要进行有意义的引用，每个 thead 只讨论一个主题，保证 [标题与内容相吻合 ][2]。虽然这么麻烦，但使用得当的话，再加上一个经过索引的归档系统，邮件列表依然在创建中心渠道的工具中占据绝对主导的地位。
公司团队可以从一个更加现代化的协作工具中收益，这类工具更易使用并提供了更加强大的多媒体功能。不管你用的是哪个工具，关键在于要创建一个能让大量的人员有效沟通并异步地讨论各种主题的渠道。要创建一个一致而活跃的社区，使用一个 [繁忙的渠道要好过建立多个渠道 ][3] to create a consistent and engaged community。
### 构建共识的机制
第二个工具是一套构建共识的机制，这样你才不会陷入死循环从而确保能做出决策。做决策最理想的情况就是一致同意，而次佳的就是达成共识，也就是 "有决策权的人之间广泛形成了一致的看法"。强求完全一致的赞同或者允许一票否决都会阻碍决策的制定，因此 ASF 中只在非常有限的决策类似中允许否决权。[ASF 投票制度 ][4] 为类似 ASF 这样没有大老板的松散组织构建了一个久经考验的，用于达成共识的好方法。当共识无法自然产生时也可以使用该套制度。
### 案例管理系统
如上所述，我们通常在项目的中心渠道中构建共识。但是在讨论一些复杂的话题时，使用案例管理系统这一第三方的工具很有意义。小组可以使用中心渠道专注于非正式的讨论和头脑风暴上，当讨论要转变成一个决策时将其转到一个更加结构化的案例管理系统中去。
案例管理系统能够更精确地组织决策。小型团队不用做太多决策可以不需要它，但很多团队会发现能有一个相对独立的地方讨论决策的细节并保存相关信息会方便很多。
案例管理系统不一定就是个很复杂的软件; 在 ASF 中我们所使用的只是简单的问题跟踪软件而已，这些给予 web 的系统原本是创建来进行软件支持和 bug 管理的。每个案例列在一个单独的 web 页面上，还有一些历史的注释和动作信息。该途径可以很好的追踪决策是怎么制定出来的。比如，某些非紧急的决策或者复杂的决策可能会花很长时间才会制定出来，这时有一个地方能够了解这些决策的历史就很有用了。新来的团队成员也能很快地了解到最近做出了哪些决策，哪些决策还在讨论，每个决策都有那些人参与其中，每个决策的背景是什么。
## 成功的案例
ASF 董事会中的九名懂事在每个月的电话会议上只做很少的一些决策，耗时不超过 2 个小时。在准备这些会议之前大多数的决策都预先通过异步的方式决定好了。这使得我们可以在会议上集中讨论复杂和难以确定的问题，而不是他论那些已经达成普遍/部分共识的问题上。
软件世界外的一个有趣的案例是 [瑞士联邦委员会的周会 ][5]，它的运作方式跟 ASF 很类似。团队以异步决策构建共识的方式来准备会议。会议议程由一组不同颜色编码的列表组成，这些颜色标识了那些事项可以很快通过批准，那些事项需要进一步的讨论，哪些事项特别的复杂。这使得只要 7 个人就能每年忙完超过 2500 项决策，共 50 个周会，每个周会只需要几个小时时间。我觉得这个效率已经很高了。
就我的经验来看，异步决策带来的好处完全值得上为此投入的时间和工具。而且它也能让团队成员更快乐，这也是成功的关键因素之一。
--------------------------------------------------------------------------------
via: https://opensource.com/article/17/12/asynchronous-decision-making
作者：[Bertrand Delacretaz][a]
译者：[lujun9972](https://github.com/lujun9972)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://opensource.com
[1]:http://www.paulgraham.com/makersschedule.html
[2]:https://grep.codeconsult.ch/2017/11/10/large-mailing-lists-survival-guide/
[3]:https://grep.codeconsult.ch/2011/12/06/stefanos-mazzocchis-busy-list-pattern/
[4]:http://www.apache.org/foundation/voting.html
[5]:https://www.admin.ch/gov/en/start/federal-council/tasks/decision-making/federal-council-meeting.html