远程敏捷团队的7个最佳实践
时间：2020-10-30 15:24:00 来源：达达文档网 本文已影响 人 
Isaac Sacolick
团队的所有人都聚在一个地方工作时，敏捷方法最有效。团队在同一个工作场地时，成员们很容易提问题、结对处理编程任务并解决问题，无需安排会议。使用互联网会议、群组聊天和电子邮件之类的技术根本不如面对面直接交流来得有效。
话虽如此，企业组织也可以让敏捷方法在远程分布式团队中大有作为，但是这需要一些工作和试验。团队成员必须找到使用技术的最合理方式，并适应沟通方式，以确保团队的生产力、协作和质量。
新冠疫情爆发后，许多敏捷团队只好由在办公室工作改为远程工作。对于在职业生涯中大部分时间没有在家工作过的许多人以及习惯于面对面交流的团队来说，这将是一种全新体验。此外，由于疫情日益严峻，一些团队成员可能生病或面临其他困境，因此敏捷团队必须适应新的工作方式。
本文是一份简单的指南，旨在帮助团队成员、团队和企业组织由面对面为主的敏捷团队改为高度分布式的团队。
选择合适的设备、工具和办公空间
如果你要远程工作，请确保有适合你、贵公司及团队的工作环境。可以视之为办公室搬家，事先抽时间评估各种选择或方案，确保你拥有所需的一切东西，以保持工作效率、舒适度以及待在尽量避免分心的办公空间。
较长期远程工作时，请考虑所有的注意事项，包括工作纪律、办公空间、设备、网络和工具等方面的建议。
你需要进行的一些变化在开始入手后才会一目了然。如果网络连接很差，可能需要重新放置无线路由器或换成有线连接。如果你经常需要开视频会议，就可能需要调整办公桌的位置。你可能要告诉家人在工作时保持距离，以免分心。
人要在场，与团队成员交流
敏捷团队的成功之道在于，平衡好专用于协作的时间与专用于编写代码及其他开发活动所需的协力工作的时间。在办公室，更容易看到团队成员关注的事情，训练有素的敏捷团队要想方设法避免分心和环境切换。
远程工作时，团队必须在线，但也要向他人表明是否在场。Slack和Microsoft Teams等工具让你可以设置是否在场的状态，而其他协作工具可以使用通知静音。如果团队乐意接受灵活的工作时间，使用状态设置至关重要。
敏捷团队必须为正式的协作交流安排时间，并做好工作以完成用户故事，但团队成员还应该可以闲聊。人们对压力大的时期和远程工作的反应各不相同，因此相互联系非常重要。此外，人们在网上和面对面的交流方式也各不相同，现在有新的机会可以让更多的人参与网上对话。
敏捷专家（scrum master）、技术主管和产品负责人应定期询问团队，摸清他们对需求和阻碍工作进展的因素了解的程度，以及是否需要设法提高生产力和幸福感。
最后，来自多个团队的敏捷专家和技术主管应定期相互联系。他们在管理远程团队方面的经验和问题可能有普遍性。如何让敏捷团队在远程协作方面进行探讨和交流，无疑会使所有人受益。
审核敏捷仪式的方法
改而采用远程协作的敏捷团队不必重新设计流程或摈弃敏捷仪式。但是远程工作可能需要敏捷专家重新考虑如何开会，具体取决于团队的规模和可用的协作工具。
比如说，面对面的团队在每日例会时查看敏捷开发白板，因此需要设计这种仪式的数字版。如果团队规模小，过去在完成用户故事方面遇到的障碍比较少，那么他们可以摈弃会议，换成预定的聊天聚会。
对远程敏捷团队的其他几点建议：
· 使用数字白板工具用于迭代规划和设计讨论
· 为承诺会议安排视频互联网会议
· 选择一个人在迭代审核期间负责屏幕共享
· 回顾时使用调查或低代码应用程序征集反馈
致力于实际的团队和个人任务
由面对面改为远程协作的敏捷团队必须重新调整迭代速度，审核他们可以实际承诺并完成的工作数量和复杂性。敏捷专家和敏捷主管应采用类似于新组建敏捷团队的做法，让团队可以适应新的工作方式。
比如说，由于一些团队成员可能会在疫情期间无法参与开发，因此完成需要多个团队成员贡献的复杂用户故事是不明智的。如果可能，应将这类故事分解成小故事，或者如果产品负责人不再优先考虑它们，就推迟。
同样，敏捷团队可能需要避免完成依赖其他团队工作的故事。额外的协作可能需要几个sprint才能为新组建的远程团队定义。
提高文档详细程度
相比前期说明文档，敏捷开发团队更注重切实可行的代码，但这并不意味着没有必要为架构、API和代码编制文档。
长时间远程工作的团队可能希望讨论文档标准，看看是否需要做出更大的努力。有时，如果为代码編制文档，不大需要面对面讨论代码模块如何工作或团队成员如何处理技术债务等内容。
关注探针（spike）、CI/CD和解决技术债务
希望长时间远程工作的团队可能会发现，更容易专注于技术性更强的故事，而不是需要与产品负责人和利益相关者进行交互的故事。比如说，测试多步骤用户体验需要产品负责人、设计人员、开发人员和测试人员之间的协作。团队刚开始远程工作时，协调讨论或让大家共同了解最终用户的需求可能比较难。
还有其他机会可以优先考虑这类工作：需要较少的协作，需要更多的个人专注和创新。优先考虑小的探针试验（spike，定义研究开发故事的一种方法）以测试新想法是一个例子，如果开发人员可以在干扰或环境切换较少的情况下开发简短的概念验证，更是如此。另一个方法是优先考虑处理代码层面的技术债务，尤其是重构代码模块、添加单元测试或改进异常处理。第三种方法是花时间开发或改进持续集成/持续交付（CI/CD）自动化。
这些更具技术挑战性的任务还可以帮助开发人员专心致志地在可直接看到效益的方面完成工作。
审查部署策略，并降低风险
高度协作的敏捷团队要学会像优秀的冰球球队一样协同工作。在冰球比赛中，即使冰球飞速移动、不规则地弹跳，球员们还是会结合运用既定的打法和灵活的应对，确保既有强大的防守，又有凌厉的进攻。
现在，将这支队伍从室内竞技场拉到室外湖泊，球队需要一些时间来适应环境。他们会采取一段时间的保守防御，直到逐渐适应新环境、恢复节奏。
敏捷团队和多个团队组成的敏捷组织也是如此。无论团队在维护旧系统，还是使用最新的DevOps实践构建云优先的应用程序，都是如此。
要求敏捷团队远程工作的条件可能会影响公司的其他方面，包括业务运营、客户期望和供应链状况。
客户和最终用户可能希望不一样的部署频率，如果这种频率有损于应用程序的可靠性或性能更是如此。如果你的API用于衔接企业的供应商，那些供应商可能较难参与测试变更。如果应用软件受到法规遵从或监管部门的监督，那就可能更难得到所需的审核和批准。
敏捷团队须认识到一系列更广泛的变化在影响本组织的业务模式、客户和工作环境。需要从新的运营角度来审核组织原则，而组织原则决定了从部署的速度和频率到优先考虑的工作类型和用户故事。
要做到敏捷、而不仅仅遵循敏捷实践，关键是要认识到何时变化、如何变化。
原文网址
https：//www.infoworld.com/article/3532286/7-best-practices-for-remote-agile-teams.html
