从我开始与远程团队合作已经三年了。 这个团队完成了工作，就像不是在遥远的地方一样。 因此，这里是我们与远程团队合作开发项目（或多个并行项目）的工具和方法论。
显然，这可以适应您自己的口味，只有概念很重要。 当我写“重要”字时，我只是说这对我们有用。
首先，让我介绍一下团队：
- 一位销售员
- 一位产品负责人
- 一位艺术总监
- 一堆开发人员（前后或全栈）
与这个团队一起，我们一直在从事移动，Web和数据开发项目，并且我们计划继续创建软件。 幸运的是，所有团队成员都愿意在远程生活和工作，而且他们都已经足够成熟，可以理解所需要的东西。
我将列出团队的不同需求，在传统环境中进行描述，并提出涵盖这些需求的工具或方法。
工作方法
我们正在为开发项目使用Scrum框架的简化版本。 我将不做过多介绍，因为它已经做过很多次了，即使团队不在同一地点，我们也将遵循该方法的概念和流程。 在下一章中，我们将看到，使用一些工具和纪律，我们可以达到相同的效率。
通讯
这是第一个要解决的主要主题。 团队需要沟通很多。
共享信息可能是成功的最重要的关键：如果您可以将不同的想法集中在一个问题上，那么您可能会更快地获得更具创造性的解决方案。 而且工作分散在团队中，因此他们需要共享结果，设计决策，工作方法，问题……我们稍后将讨论该主题，但是使用敏捷方法会使团队负责许多主题，但这仅是如果通信顺利进行，则可以正常工作。
聊天室
通常，这不是问题：您可以为团队提供一个开放的空间，或者人们可以从一个办公室转到另一个办公室进行交谈。 现在，您的两个开发人员是9000 kms的公寓。 他们怎么说？
他们总是可以安排电话，但是有限制。
首先，它需要同步发生（否则这将是一次无聊而无聊的通话）。 在不同时区的情况下，这可能会很棘手。
然后，根据您所在的位置，它可能要花很多钱。
要考虑的另一件事：在开放空间中聊天时，周围的其他人可以听到您的声音，从而使信息传播的范围超出了您的原始意图。 即使事情不在您的直接管辖范围之内，了解它也非常重要。 它使您可以在全局上有更大的视野。
几年前，诸如IRC或XMPP实现之类的工具是在线聊天的方式，但是它缺少一些功能：
- 文件共享
- 历史记录（即离线消息）
- 易于使用
如今，有很多在线聊天工具，其中最受欢迎的两个可能是Flowdock和Slack（但我可以命名为Mattermost，zulip，HipChat等）。 它们之间有一些区别，但是它们都有相同的概念：
- 人们可以聊天的房间
- 历史记录得以保存，因此您可以查看外出时所说的话
- 一对一通讯
- 文件共享
- 其他工具集成
最后一点也很重要：它将所有通信或数据流集中在一个地方。 其他工具可以是您的Git服务器宣布提交或构建，您的部署工具或任何其他脚本，监视工具可以警报，twitter搜索或可以跟踪帐户，可以接收电子邮件，客户支持以快速升级到合适的人（那里是一个非常庞大的集成列表）…
这是迄今为止我在早上启动的第一个应用程序，它模拟了进入真实房间（开放空间）并为同事欢呼的过程。 我是否提到过您可以在聊天室看到谁在线（因为您可以看到谁在办公室）？
我确实对Flowdock略有偏爱，因为它具有“线程视图”，它允许答复特定的消息而不是一般主题，并且可以在同一会议室中同时进行多个讨论。 非常便利。
为了提高沟通效率，您必须提供反馈。 让我举个例子：您正在休息吗？ 说吧！ 您的同事看不见您，您喝咖啡时他们可能正在等待答案。 宣布您暂时没有空，以免沮丧。
另一件事：即使您在公共场所聊天，也要使用提及（例如“ @user”），让人们知道您正在与谁聊天。
实际上，就像团队其他成员一样，请考虑一下自己是盲人。 因此，如果发生任何事情，没人会看到它，因此您需要对其进行描述。 您刚刚被问到一个问题，您正在考虑吗？ 说吧！ 当有人试图与您联系时，您正在打电话：宣布您不可用。 一天结束了，您要走了，告别流程！
您可以创建多个流程或聊天室，也可以根据项目将其命名为聊天室，但始终可以进行随机聊天（又称咖啡机）。 您的团队可以在这里共享与工作无关的主题，就像在公司大楼中一样。
电话会议和视频会议
聊天室很酷，因为它不是侵入性的，它可以是异步的，可以根据需要共享文件，但是它有一些缺点。
首先：这是非个人化的，非人性化的。 确实，您在聊天室中唯一的界面是带有文本（以及图像和表情符号，而不是人类）的软件。
有时，即使进行了主题讨论，也很难对文本进行讨论。 例如，考虑有关某些功能实现的技术聊天，或产品人员之间的一些头脑风暴。 它需要很大的敏捷性，而这并不是书面沟通的最佳方式。
最后，您可能想邀请一些外部资源参加远程会议，但不希望它们访问您的聊天室。
这是电话会议或视频会议解决方案发挥作用的地方。 再有一次，无论是Google Hangout还是Room.co还是Skype或present.in，都有很多选择。
请注意，Slack提供了集成的视频通话解决方案。 实际上，Flowdock和Slack都有两种快捷方式，可以直接从聊天中快速启动视频会议。
我还建议Scrum会议是通过视频通话进行的，以便整个团队可以面对面交谈，因为这是一个很好的场合。 显然，只有在您有共同的工作时间并考虑不同的时区时，才会发生这种情况（timeanddate.com会议计划者是组织它的最好的朋友）。
屏幕共享
远程工作时，最后一个有用的工具是：屏幕共享解决方案。
如果您有配对编程会话，则将需要它，或者在帮助同伴时它可能会很有用，并且您想使用其键盘/鼠标。
Screenhero确实运行良好，而TeamViewer可能是最著名的解决方案。
项目组织
现在我们可以讨论它，让我们组织项目🙂
任务管理
涉及任务管理的工具太多，以至于很难找到自己的方式。 我不会浏览它们的列表，因为Internet尚不足以托管它。
我确实推荐我的团队产品负责人Jalmin的帖子，从这个角度来看，它将向您展示一切。 但是我还是会宠坏的：Trello
那么，我在Trello中爱什么？ 简单灵活。 并集成（在Flowdock，Slack等）中。 并且易于使用和理解。 又漂亮 简而言之：我们喜欢这个工具。 我什至组织我的个人生活项目。
Trello可以用来映射您的Scrum实现，即使您扭曲了很多原始方法。 您有两个主要功能可对任务进行分类：列和标签。
我们决定使用列来表示时间，并使用标签来为任务提供“状态”。 水平时间组织如下：
- 待办事项列表的一列（即默认列，或“通常要做的事情”）；
- 一栏代表部署队列（我们可以想象每个环境要部署到其中一列）；
- 从新的（左侧）到旧的（右侧），每个sprint一列。
由于优先级是最好的排序方式（您首先要了解什么是重要的），因此我们决定将垂直轴用作优先级标准：重要性越高，重要性就越低。 再次，它确实映射了真实的物理旧世界：当您接下一个任务时，将堆栈中的第一个文件取出。
为了更清晰和更懒惰，我什至倾向于将“完成”任务移到列表的底部，以便首先执行的任务按重要性排序。
另一个类别参数是标签。 它赋予卡状态。 在我们的案例中，我们将颜色和标签链接如下：
- 绿色=完成
- 黄色=做
- 橙色=做
- 红色=不会
- 紫=暂停
- 浅蓝色=等待验证
- 黑色=生产中
显然，您可以根据需要组织自己的东西，但是我真的很喜欢卡片上的绿色/黄色/橙色基本状态，这是非常常见的阅读方式。 你知道吗？ 每张卡可以有多个标签。
请参阅Jalmin的上一期模板项目：https：//trello.com/b/4tNmNTng/project-template-board-for-tech
每张Trello卡代表一个用户故事，这是要实施的一项功能。 根据您的方法，您可以用Scrum风格（“作为用户，我想..”）或作为TDD风格的验证测试来描述您的用户故事，或诸如此类。 您可以为任务分配人员，设置“到期日”，附加文档，对其进行注释（定时堆栈），附加清单，创建指向其他卡片的链接以及提及人员（即ping他们）。
在另一位置可以完成一种任务，与它的主题更好地集成：CVS系统中的问题（在我们的示例中为gitlab，请参见下文）。
我喜欢任务可以链接到提交甚至代码行这一事实，尤其是在涉及技术问题时（尽管在功能错误方面效果不佳）。
但是对于技术团队来说，将某些技术任务集成到与sprint链接的发行版中可能是一个不错的地方。
我对使用gitlab-issues唯一的担心是，您现在有两个任务来源，一方面是Trello，另一方面是gitlab-issues。 如何确定它们之间的优先级？ 如何报告单个时间跟踪器？ 我更喜欢每个任务使用一个工具，但是我可以理解，技术团队可能对问题管理感兴趣，例如研发团队或后端服务/开发人员/运营团队。
任务管理不是一种选择：这是集中列出“我们必须做什么以及何时要做”列表的唯一方法。 无论您选择哪种工具，您都需要像其他团队成员一样非常满意。 它是（或者应该是）团队中每个人的最好的朋友：它告诉您该怎么做。
这就是为什么我对此毫不妥协的原因：如果它不在任务列表中，那么它就不存在。
时间跟踪
是的，这很痛苦，我们都讨厌它，但是我们必须定时报告。 做到并保持下去的唯一方法就是让它变得如此简单，以至于您甚至都不觉得自己在做。
在任务管理中拥有所有任务的好处是，最好是尽可能自动地进行时间跟踪的地方。 在我们的情况下，与Trello一起工作自然给了我们两个选择：Trello的打卡时间和/或Scrum。 这是与Trello集成的两个时间跟踪工具，但是用法略有不同。
Trello的Scrum是一个纯Scrum工具。 它允许为Trello卡分配2个变量：估计点和消耗点。 这些要点是从Scrum的角度理解的，但是好消息是，当您可以配置所需的值时，还可以假装它是所需的指标！
这些值放在卡的标题中（这就是为什么您必须对其进行编辑才能获得菜单），并在列级别进行汇总。 非常方便查看进度或估计的工作量是否现实。
该系统的局限性是您的正统程度。 如果您将这些点视为纯Scrum点（即，基于斐波那契数列的无单位值）或实时单位（无论是小时，天，…）。 我之所以喜欢纯Scrum积分，有很多原因（使用斐波那契数列有助于感觉到日益增加的复杂性/难度），但是在向客户收费时，它不如时间单位那么精确。 时间单位是报告的理想选择，但是坦率地说，要准确估算7小时和9小时工作之间的实际差异确实很困难。
在这里，您可以在武器库中增加打卡时间。 这是一个纯时间跟踪器，已很好地集成到Trello和您的环境（您的浏览器和您的手机）中。
因此，基本上，一旦您开始使用卡，就可以启动计时器。 一旦您停止处理卡，（猜测是什么），您就停止计时器并投入时间。 而已。 好吧，不完全是这样：有一个报告系统，可以让您查看每个项目，每个卡，每个状态，每个用户的时间报告，并生成不同的导出。
资源资源
我们已经看到，我们可以将文档附加到Trello中的任务，并在Flowdock或Slack等通信工具中共享它们。 但这还不够：您还拥有与项目相关的文档，这些文档包括：
- 不属于Git存储库：它不是代码，没有版本控制，很重；
- 不属于关于Flowdock / Slack的讨论：它更持久；
- 不属于Trello上的一项任务：它不是特定于一项任务的。
您可以想到图形资源（是的，大的PSD），或任何类型的报告/间距/损益表/数据导入/您的名字。
这可能有点过时了，我怕说：您需要一个文件服务器。 良好的候选人是Google云端硬盘或Dropbox。 我最喜欢的是ownCloud，这是一种基于云的开源存储（具有台式机和移动客户端，可在需要时同步您的数据）。 这是我的最爱，因为它具有远程文件服务器所期望的所有功能，并且您可以将其托管在自己的服务器上，如果您不希望与各层共享机密文档，则这很重要😉
技术
以下大多数内容已在https://medium.com/@chilladx/my-dev-toolbox-for-new-projects-580b4684c036中介绍
再一次，在技术方面，我想保持简单。 有工具可以帮助团队有效地工作。
编码
Git是托管代码的明显选择，我真的很喜欢GitLab。 托管版本很棒（您不需要服务器，您拥有最新的gitlab服务器版本，并且是免费的），但更好的是：您可以自己托管（是的，它是开源的）。
现在，请记住您处于远程配置中，因此需要某种方法来使用Git。 首先，获取一个流（git-flow，github-flow或gitlab-flow或…）。 当组织代码分支和发布过程时，这是使整个团队保持一致的唯一方法。 在我们的案例中，我们选择了git-flow，因为它很容易理解和应用，并且众所周知（因此临时贡献者或新团队成员可以快速集成）。
然后，设置存储库模板，以及有关操作方式的一些准则（即，文档作为/ docs中的markdown文件，强制性CHANGELOG等）。
最后，选择您的代码样式，以使它在项目的模块和项目之间是同质的。
团队应该使用相同的IDE吗？ 我热爱自由，所以即使我不得不承认它对协调事物（相同的工具，具有相同的配置……）有很大帮助，我也会拒绝。
关于代码的最后一件事：不应涉及自我。 与团队合作，在代码中建立这种言论自由的文化，免责怪罪，总是乐于学习等。这很关键，因为您看不到有人批评您的工作，并且您可能会在一段时间之前没有收到他/她的消息。
一个连续的集成工具应该与git一起放在分支“ develop”上（如果您遵循git-flow）。 那里的每个提交都应该触发一堆测试，并报告以下内容：
- 单元测试；
- 功能测试；
- 代码覆盖率；
- 格式/样式/皮棉。
请注意，“ develop”是开始运行测试的好分支，因为它是代码不同部分整合在一起的第一个地方（在git-flow中，这是功能分支合并的地方）。 您可能想知道在开发过程中是否有错误。 但是“ master”分支显然是应该始终通过测试的分支，因为它是生产中使用的分支。 您可能会考虑在两个分支机构中都拥有CI（总比后悔好，是吗？）。
幸运的是，GitLab将再次为您提供帮助：默认情况下，GitLab CI集成在任何最新的gitlab安装中。 配置项目以使用它非常容易：您只需在存储库中添加一个配置文件，即.gitlab-ci.yml文件。 该文件包含由提交触发的不同工作流程。 即使我不是自动部署的忠实拥护者，它也可以包括运行测试以及部署代码（至少应该非常小心地进行）。
可以使用徽章来快速了解集成的最新状态，但是如果需要修复，则最后一次提交的作者应该能够获得测试的全部结果。
该文件
文档是一个棘手的话题。 它太多了，没有用； 没有足够的信息，您会错过重要的信息； 放错了地方，没有人找到或阅读它。
不要浪费时间写没有人要阅读的文档。 问题在于我们并不总是事先知道它。 但是，就像估算过程一样，它也伴随着经验，您很快就会保留一些没人关心的文档。
另一方面，描述软件的全局体系结构，主要概念或实现的敏感部分是一个好习惯。 如果您没有对此进行记录，那么人们将不得不阅读您的代码以获取它（并且您的代码不如您想象的那么清晰）。
有不同类型的文档，同一个人不会同时阅读。
- Wiki是托管有关项目，体系结构演示文稿和主要概念的常规信息的好地方。 这完全可以与技术相关（请参阅下一点）。 幸运的是，gitlab集成了一个简单的Wiki模块，该模块链接到您的存储库（顺便说一下，也可以在存储库中进行管理）。 使用它的问题有两个方面：一方面，如果您的项目包含多个存储库，您可能最终会在多个Wiki中进行搜索以获取常规信息； 另一方面，该文档与您的代码相关。 后者还意味着文档未部署为代码的一部分，这不是很方便。
- 我最喜欢存放技术文档的位置是放在存储库根目录/ docs文件夹中的markdown / reStructuredText文件。 易于查找，可在任何地方阅读，易于编写且结构简单。 我倾向于将所有信息放在一个位置，每个主题一个文件，甚至不使用我保存的有关项目的敏感信息（例如帐户）的Wiki。
- 做好注释后，代码中的注释仍然是记录代码的最佳方法。 类和函数应附有标准文档，以便您在眨眼之间即可获得用法，参数和返回值。 然后，只有代码的复杂部分才应接收注释。 而且，不要告诉我，您正在遍历数组，“上尉队长”，而是要解释一个怪异的语法，一些不太明显的数据转换，或链接到一篇论文，解释您使用的算法。 本文档的结构应由您的编程语言的自动文档工具（无论Javadoc是Java，pydoc是Python还是…）进行解析。 遵循规则无需花费任何费用，并且可以生成干净的文档，从而可以帮助新用户整合团队。 此外，大多数IDE都使用它为您提供上下文帮助（非常方便）。
还有一件事：无论您的解决方案是什么，请确保都有一个不错的搜索引擎为您的文档建立索引，以便用户可以轻松地对其进行挖掘。 并尝试避免选择多种文档来源，以免您四处寻找信息。 建议您将文档工作集中在项目/ docs文件夹中的.md文件中。
基础设施
现在，远程工作的基础结构比以前容易得多。 首先，开发人员可以在其开发环境上模拟基础架构，而无需操作团队。 然后，虚拟服务器现在变得如此便宜，您可以根据需要使用它们来创建临时环境。 最后，部署不需要像以前那样需要特定的技能，因此您可以允许不同的团队根据需要在不同的环境中进行部署，甚至可以使某些部署自动化（这是我不推荐的做法）。
Vagrant（带有VirtualBox）是我选择的在开发人员计算机上运行目标平台的解决方案。 基本上，在项目开始时就决定了架构（或至少是它的全局）。 我确实在存储库的根目录下创建了一个vagrant文件夹，并在其中放置了一个Vagrantfile，描述了机器，转发的端口和共享文件夹。 这是存储库的一部分，因此会随着时间的推移而发展，但是任何允许访问该存储库的开发人员都可以在生产配置中运行代码，无论其工作站是什么。
好的，您有服务器，但是部署过程，需求安装和服务配置如何？ 不用担心，我们也涵盖了这一方面，其原理与虚拟服务器相同：任何人都可以轻松使用它。
Ansible是我们的选择，因为它使用起来非常简单（一堆yaml文件），使用起来非常轻巧（无需在目标服务器上安装任何代理），并且可以很容易地集成到代码存储库中（或者可以坐在旁边）。
一堆标准角色部署和配置了我的环境，一个非常具体的角色（作为项目开发）部署了代码，并确保项目在环境中运行。 相同的脚本可以部署无业游民的计算机，以及其他环境（直至生产环境）。 这样就可以在最重要的位置进行测试和演练，然后再在最重要的位置进行操作：面向生产的客户。 可以肯定的是，它将使您的运营团队感到高兴。
您需要做的最后一件事：分享生产中发生的事情。 它不是特定于远程的主题，但是在设置环境时，为什么不这样做呢？
对于一个正在运行的应用程序，至少有三个信号：它正在运行（或不完全或部分运行），它创建/转换/使用的数据以及它所生成的日志（说明其活动）的事实。 开发人员需要知道生产中会发生什么，因为数据是真实的（性质和数量都很高），因此很少在其他任何环境中模拟。
对于前两个信号，这是监视的问题。 就其本身而言，这是一个很大的话题，但是拥有一个可定期调用应用程序并根据这些调用结果发出警报的工具。
最后一个信号是关于共享正在运行的应用程序生成的日志和错误。
Sentry是一个很好的选择，易于集成，可以猜测：开放源代码（因此您可以托管它）。 它拥有每种主要编程语言或框架的客户，以简化集成。 它允许您将异常发送到中央位置：Sentry服务器。 一项不错的功能：它会重复删除条目，从而使查看起来更容易。
另一个选项可能更易于部署，并且向湖中添加了其他数据：ELK堆栈。 它由Elasticsearch（用于存储数据），Logstash（用于传输数据）和Kibana（用于查看数据）组成。
您可以通过两种方法将日志保存到中央位置：部署Filebeat以读取实型日志文件（并将其发送到Logstash），或者在应用程序中集成对Logstash服务器的直接调用（可以例如，将JSON发送到HTTP）。 您还可以轻松地将大量其他日志发送到Logstash，例如syslog，nginx / apache，数据库（慢查询）…
我喜欢这种解决方案，因为您可以在一个点上收集大量信息，并将它们关联起来进行分析/验尸/调查。 Kibana是查看数据的绝佳工具，而Grafana是令人难以置信的替代方案。
结论
如我们所见，与远程团队合作只需要一些工具和一些工作方法。 最重要的一点显然是要沟通，同时要牢记距离。 这意味着要付出更多的努力来喂养它，但不要淹没它或在它上面花费太多时间。 一堆工具可帮助组织不同的主题和主题的用法。
每个人在团队中分享沟通的重要性也很重要。 您应该特别注意Sprint回顾（或您所谓的回顾），因为这是团队可能表达需求（无论是否明确）的地方。 这些需求可能意味着方法论的适应（并对此开放）或一种新工具。 请注意尽量减少使用的不同工具的数量，因为太多的工具可能会导致人员流失。
最后，要记住的最重要的一点是，一切都与人有关，您实施的工具和采用的方法不会改变这一点。 创建和维护良好的公司文化是使人们拥有互动和共享意愿的一种方式。 并且让每个人都意识到远程通信固有的困难，因此每个人都在努力。 这并不复杂，但是需要纪律。
特别感谢 Jalmin 帮助撰写了这篇论文，以及 @dgellow 建议了很好的更新。
