Hive Mind开发:与多个团队一起构建成功的软件解决方案

随着我们不断前进,软件正变得越来越复杂,用简化的数字解决方案代替了更多的人工,劳动密集型和基于纸张的流程。 对于为整个组织中的大量流程提供服务的多功能解决方案,开发工作通常需要少量(或大量!)设计人员和开发人员,以便及时完成任务。

为了解决这种规模的解决方案,大型组织通常将人员分为几个较小的团队,以提高效率和吞吐量。 通常,这是最佳选择,但容易受到许多挑战,从降低效率和士气,甚至如果管理不当,甚至会破坏整个项目。

以下是可以采取的一些步骤,以帮助减轻这些风险和挑战,并确保不仅提供更好的解决方案,而且确保开发人员也更加快乐。

1.首先设计全局

复杂的软件需要整体设计。 这包括用户体验以及基础系统设计。 主要成分是什么? 他们如何互操作和相互支持? 有重叠吗? 资源(屏幕,组件,数据源)可以共享吗? 什么可以解耦? 或者,通过组合相似的组件可以简化什么? 整个解决方案的主要要求和假设是什么?

这些问题的答案将增加清晰度,使每个人都具有共同的愿景,并有助于做出更好的决定,例如如何拆分工作。 它还有助于将工作分解为任务,应使用的技术以及更准确的总体成本估算。

此设计过程需要“足够详细”,而不必在特定的编码实现或技术优势案例上陷入杂草,否则,冒着过多地使用“瀑布式”方法而使迭代开发过程延迟的风险。

2.建立原则,模式,界面,语言和框架

一旦完成整个系统设计,就可以做出某些高级实施决策。 解决方案中涉及的所有设计人员和开发人员都应遵守这些规定。 如果将各个团队留在自己的设备上,他们可能会构建可行的组件,但是实现细节(例如编程语言,框架,命名约定,外观和编码样式)可能会大不相同。 这可能会导致集成和维护麻烦。 另外,可能会发生多余的工作。 例如,理想情况下可以由多个组件共享的代码可以由独立的团队多次开发。 或者,互操作性可以通过每个团队以不同的方式实现,而不是通过一组明确定义的共享接口来实现。

在最近的一次参与中,我回顾了一个包含60多种不同编程语言和框架,数十种自定义组件(包括本地ORM和REST路由器)的解决方案,并且服务之间没有一致的身份验证或授权模式。 除了安全性,互操作性,可读性和代码重用问题之外,软件的基本维护还需要特定的开发人员,他们最好地了解特定功能的语言和实现,以便对该功能进行重构或故障排除。 其中大部分是部落知识,随着开发人员可以在大型组织中来来往往,这可能会增加长期支持成本。 这种实施的结果是,新功能的进展变得缓慢且昂贵,并且对现有代码中的问题进行故障排除也既耗时又昂贵。

并非总是可以根据体系结构要求或组件选择一种语言或框架,但是越少越好! 如果有一个真正热爱Ruby的团队构建一个Ruby Web服务,并且需要使用与其余Python / Go / JAVA / .NET Core Web服务相同的方式进行身份验证,则意味着他们将需要创建自己的独立身份验证代码,除了增加不必要的安全风险外,还会造成工作量冗余(并因此增加成本)。

理想情况下,最终解决方案应该看起来像是由单个开发人员制作的,具有一致的样式,外观,命名约定,异常处理和其他最佳实践。 只有将设计,模式和实践布置为所有人都可以遵循,才能实现这一目标。

3.发挥个人优势

并非每个开发人员都能掌握每种语言和框架。 有些在“前端”方面更好,而另一些在“后端”方面更好。 神话般的“全栈”开发人员通常是通才,或者是每个体系结构层中特定技术选择的掌握者,这可能适用于某些项目或组件,但不适用于其他项目或组件。 一些开发人员对特定的语言和框架(例如Java或.NET)具有丰富的知识,这对于解决该堆栈中特别具有挑战性的技术问题可能非常有价值。 一些开发人员具有丰富的领域知识或在构建特定类型的功能方面的经验。

成功的团队组织的关键是了解每个人的优点和缺点,并据此组建团队。 将一堆开发人员投入团队,并期望他们每个人都能够从积压中获取任何用户故事,并端到端构建任何功能,无论需要多少架构层,涉及的语言或UI或后端的复杂性无效。 相反,团队应该拥有最能执行团队负责的功能或组件的成员,并且采用他们最有效使用的技术。 如果期望团队为特定功能构建“完整堆栈”,则它应该在堆栈的每个区域都有出色的个人成员来完成此任务。 或者,考虑组织围绕技术或体系结构层(前端与后端)的团队,并建立良好的跨团队协作以共同提供全功能,从而引向下一个要点。

4.沟通,沟通,沟通!

团队之间的清晰沟通对于成功至关重要。 每个团队和每个人都应该为实现共同目标而共同努力,并意识到当前出现的问题和挑战。 此外,多个人或团队不应因重蹈覆辙而重新发明轮子,以解决同一问题,也不应该因其注意力被另一团队的交付“阻塞”而在他们关注的领域中创建变通的解决方法。 可以通过良好的前期计划来缓解其中的一些问题:具有预期依赖关系的交错交付结果路线图。 实际上,无论计划有多好,执行期间事物都会发生变化,并且随着事物的迭代而识别和适应的能力是关键。 随着事情的进展,这需要不断的沟通。

一些组织形成了“ Scrum of Scrums”流程,其中每个团队的代表参与跨团队可交付状态,即将到来的依赖关系和阻止问​​题的日常沟通。 只要来自各个受影响团队的设计人员和工程师也齐心协力,以协作的方式解决眼前的问题,这便会有效。 交流不仅仅是在栅栏上抛出状态和请求:它应该导致跨团队边界的协作开发。

一个可能有助于此目的的过程是跨团队设计和代码审查。 提取请求和设计可以由另一个团队的成员进行审核,理想情况下,该团队取决于或与正在审核的功能或组件重叠。 这自然会促进沟通,并提供跨团队边界的其他可见性。

总而言之,软件开发中的许多挑战是人员或流程问题,而不是编码或技术问题。 在单个横幅和执行计划下调整大型组织是很困难的,但是上述步骤和注意事项可以为成功的解决方案及其背后的团队带来成功的秘诀。

作者:iTrellis顾问Stephen Pugmire