{"id":593,"date":"2022-01-26T01:46:08","date_gmt":"2022-01-26T01:46:08","guid":{"rendered":"https:\/\/www.cybermedian.com\/pt\/?p=593"},"modified":"2022-04-01T11:58:56","modified_gmt":"2022-04-01T03:58:56","slug":"cross-functional-vs-self-organizing-vs-feature-vs-component-teams-in-agile","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/pt\/cross-functional-vs-self-organizing-vs-feature-vs-component-teams-in-agile\/","title":{"rendered":"Equipes multifuncionais x auto-organizadas x recursos x componentes no Agile"},"content":{"rendered":"
\n
\n
\n
\n
\n
\n

Tradicionalmente, um projeto \u00e9 organizado em torno de\u00a0\u00a0equipes de componentes<\/strong>\u00a0\u00a0(ou seja, UX, Dev, Business, Testador e…), qualquer vers\u00e3o que exija uma variedade de conhecimentos de componentes precisar\u00e1 envolver v\u00e1rias equipes de componentes.\u00a0Normalmente, equipes diferentes ter\u00e3o conjuntos de prioridades diferentes, o que inevitavelmente leva a gargalos no ciclo de lan\u00e7amento do produto.<\/p>\n

De acordo com a Wikipedia, uma equipe multifuncional \u00e9 um grupo de pessoas com diferentes conhecimentos funcionais trabalhando em dire\u00e7\u00e3o a um objetivo comum.\u00a0Uma das melhores maneiras de melhorar a qualidade de sua equipe \u00e9 torn\u00e1-la multifuncional.\u00a0Uma equipe multifuncional tem todas as habilidades necess\u00e1rias para transformar uma ideia em um produto funcional.<\/p>\n

\u201c\u00a0Uma\u00a0\u00a0<\/em>equipe multifuncional<\/em><\/strong>\u00a0\u00a0tem todas as compet\u00eancias necess\u00e1rias para realizar o trabalho sem depender de outros que n\u00e3o fazem parte da equipe<\/em>\u00a0\u201d \u2014 Guia Scrum<\/p>\n

Em contraste com a abordagem de equipe de componentes,\u00a0\u00a0as equipes multifuncionais<\/strong>\u00a0\u00a0s\u00e3o grupos formados por pessoas de diferentes \u00e1reas funcionais da empresa.\u00a0\u2014 deve ser formado n\u00e3o apenas por especialistas t\u00e9cnicos (back-end, desenvolvedores front-end, engenheiros de controle de qualidade, etc.), mas tamb\u00e9m por membros como analistas de neg\u00f3cios, especialistas em marketing e UX ou qualquer outra pessoa que participe ativamente do projeto.<\/p>\n

<\/figure>\n

Uma\u00a0\u00a0equipe auto-organizada<\/strong>\u00a0\u00a0\u00e9 uma equipe que tem autonomia para escolher a melhor forma de realizar seu trabalho, em vez de ser dirigida por outras pessoas de fora da equipe.\u00a0Ao contr\u00e1rio dos princ\u00edpios tradicionais de gest\u00e3o, as equipes auto-organizadas n\u00e3o s\u00e3o dirigidas e controladas a partir do topo;\u00a0em vez disso, eles evoluem de membros da equipe participando ativamente e coletivamente em todas as pr\u00e1ticas e eventos do Scrum.<\/p>\n

<\/figure>\n

Equipe tradicional x equipe \u00e1gil<\/p>\n

\u201cUma\u00a0\u00a0<\/em>equipe de auto-organiza\u00e7\u00e3o<\/em><\/strong>\u00a0\u00a0consiste em um grupo de trabalhadores do conhecimento que precisam gerenciar a si mesmos.\u00a0Eles precisam ter autonomia\u201d \u2013\u200a<\/em>\u00a0Peter Drucker.<\/p>\n

O Guia do Scrum indica que \u201cO Time Scrum consiste em um Product Owner, o Time de Desenvolvimento e um Scrum Master.\u00a0Eles est\u00e3o:<\/p>\n

\u201c\u00a0Times Scrum<\/strong>\u00a0\u00a0s\u00e3o\u00a0\u00a0auto-organizados<\/strong>\u00a0\u00a0e\u00a0\u00a0multifuncionais\u00a0<\/strong>\u201d \u2014\u200a<\/em>\u00a0Guia Scrum:<\/p>\n

Equipe de componentes vs equipe de recursos<\/span><\/h3>\n

A abordagem tradicional \u00e9 dividir o produto de forma mais ou menos l\u00f3gica e significativa em componentes e atribuir equipes de componentes a eles.\u00a0No entanto, esses componentes s\u00e3o completamente irrelevantes para o ponto de vista do cliente.<\/p>\n

Uma abordagem de equipe de recursos agora \u00e9 uma maneira quase universalmente aceita para organizar suas equipes, em oposi\u00e7\u00e3o \u00e0 equipe de pilha de tecnologia, especialmente, na abordagem de entrega cont\u00ednua, ela enfatiza recursos (ou seja, uma fatia vertical do sistema) que resolvem as necessidades do usu\u00e1rio que normalmente podem acelerar entrega de valor de qualquer recurso ou software em funcionamento e encurtar o ciclo de feedback dos usu\u00e1rios reais.\u00a0Uma equipe de recursos teria todas as habilidades para executar o trabalho em n\u00edvel de tarefa necess\u00e1rio para realizar o trabalho.\u00a0Em particular, assumindo uma arquitetura de tr\u00eas camadas, os membros da equipe trabalhariam em tarefas relacionadas \u00e0 GUI, camada intermedi\u00e1ria e partes do banco de dados desta hist\u00f3ria.<\/p>\n

<\/figure>\n

A grande desvantagem da organiza\u00e7\u00e3o de componentes \u00e9 \u00f3bvia: ela retarda o fluxo de valor.\u00a0A maioria dos recursos do sistema cria depend\u00eancias que exigem coopera\u00e7\u00e3o entre as equipes de componentes para construir, implantar e, finalmente, liberar.\u00a0As equipes passam muito tempo discutindo as depend\u00eancias entre as equipes e testando o comportamento entre os componentes, em vez de serem capazes de fornecer valor ao usu\u00e1rio final.<\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n