Todo membro de uma equipe ágil precisa ser desenvolvedor de software?

Recentemente, começamos a usar metodologias ágeis na minha empresa. Por eu ser bastante novo no Agile, me pergunto se nossa maneira de implementá-lo está correta de acordo com os princípios básicos do Agile.

Anteriormente, tínhamos funções como analista de negócios, testador de controle de qualidade e desenvolvedor de software. Mas agora a gerência decidiu que essas funções devem ser removidas e todos trabalharão como desenvolvedores de software.

Na prática, isso significa que um desenvolvedor de software terá as mesmas responsabilidades que três funções separadas anteriormente (por exemplo, um analista de negócios, um testador de controle de qualidade e um desenvolvedor de software).

Eles justificam a mudança com o fato de ser ágil. É assim que outras empresas também implementam agilidade?

Não. Isso definitivamente não é ágil. Nem é uma boa ideia.

Equipes multifuncionais, ou seja, equipes que incluem todas as funções (analista, administrador de servidor, administrador de banco de dados, designer de UX, testador de controle de qualidade, redator técnico, designer gráfico) necessárias para fornecer com êxito o software de trabalho, são um grampo de muitas metodologias ágeis. De fato, em muitas metodologias, o próprio cliente também é considerado parte da equipe.

Na verdade, isso é ortogonal a ágil, no entanto. Equipes multifuncionais são simplesmente uma boa ideia, independentemente de você estar agilizando ou não.

O que é verdade, no entanto, é que, com o aumento constante de testes automatizados, testes de desenvolvedores, desenvolvimento orientado a testes e comportamental, por um lado, e infraestrutura definida por software, comissionamento, configuração e implantação altamente automatizados, DevOps e Na nuvem, algumas cargas de trabalho podem ter mudado de administradores para engenheiros de DevOps e de controle de qualidade para desenvolvimento. Isso não significa, contudo, que esses papéis estão extintos. Significa apenas que o controle de qualidade tem bugs mais interessantes a serem perseguidos, porque todos os problemas triviais foram encontrados pelos testes dos desenvolvedores, e os administradores se concentram mais em permitir que o DevOps gerencie a infraestrutura com ferramentas automatizadas do que elas próprias.

Existe um teste fácil para verificar se algo é ágil: quando alguém diz "você faz isso porque é ágil", então não é ágil. Agile é sobre equipes de autogerenciamento que refletem constantemente em seus processos e os adaptam. Sempre que alguém diz "você faz isso", não é ágil. É somente ágil quando a equipe diz " nós fazer isso, porque depois de refletir sobre nossas experiências passadas, nós determinamos que ele funciona, e vamos continuar refletindo sobre ele e parar de fazer isso assim que determinar isso não acontece."

É assim que outras empresas também implementam agilidade?

Infelizmente sim. Existem muitas empresas nas quais o Agile é imposto pela gerência, ou pelo menos o que eles acham que é Agile (o que obviamente não é).

Se você olhar no guia Scrum , que provavelmente é de onde sua gerência pegou a idéia, você encontrará o seguinte:

O Scrum não reconhece títulos para os membros da equipe de desenvolvimento que não sejam Developer, independentemente do trabalho que está sendo realizado pela pessoa

Mas a ideia de todos os membros da equipe serem "desenvolvedores" é que, independentemente de sua função (controle de qualidade, programador, designer, etc.), todos contribuem para o desenvolvimento do aplicativo, juntos, com esforços iguais, responsabilidade e responsabilidade iguais . O programador não é mais importante que o testador apenas porque ela escreve o código e o testador apenas o testa, o designer não cria os wireframes e desaparece enquanto os desenvolvedores do front-end os implementam. Todo mundo é importante. Todo mundo contribui. Então, todos são iguais a esse respeito. Os cargos não importam. É por isso que todo mundo é um "desenvolvedor".

Mas isso não significa que, de repente, o designer começa a fazer a arquitetura do aplicativo ou a escrever o código. E na mesma linha de pensamento, apenas porque agora você é todos "desenvolvedores" porque a gerência disse isso, isso não significa que você está fazendo o Agile.

O que eles estão fazendo é um absurdo. Por exemplo, se você faz um desenvolvedor de software assumir uma função de controle de qualidade:

Primeiro, o desenvolvedor de software não tem a experiência necessária. É tudo o que pode ser aprendido, mas eu pessoalmente começaria como um engenheiro de controle de qualidade júnior, sendo muito menos eficaz do que trabalhar no desenvolvimento de software.

Segundo, as pessoas têm talentos diferentes e entram em posições em que seus talentos contam. As pessoas se tornam desenvolvedores de software porque têm talento para isso e outras se tornam engenheiros de controle de qualidade porque têm talento para isso. E ambos teriam sido menos bons no outro trabalho.

Terceiro, se a mesma pessoa faz desenvolvimento de software e controle de qualidade, eles estão em conflito. O controle de qualidade encontra problemas que causam mais trabalho aos desenvolvedores de software. Os desenvolvedores de software, como todo mundo, não gostam de mais trabalho. Então, o que você espera que um desenvolvedor de software que trabalhe como controle de qualidade faça?

Embora as origens do Agile estejam no domínio do desenvolvimento de software, as abordagens iterativas para o desenvolvimento existem desde o final dos anos 50 e foram usadas nos primeiros dias da NASA (consulte https://en.wikipedia.org/wiki/Iterative_and_incremental_development ). Essas equipes obviamente eram apenas engenheiros de software.

Usamos com sucesso várias abordagens ágeis em minhas empresas e para a equipe de robótica que mentor. O conceito de sprints, picos e design iterativo com épicos abrangentes provou ser muito bem-sucedido em toda a equipe - software, hardware, CAD, marketing, etc. Por isso, não temos nenhuma infraestrutura "DevOps" que as crianças estão fazendo protótipos avançados e demonstrações de seus aprendizados em sprints de duas semanas. As decisões sobre como proceder são tomadas a partir daí, mas o núcleo é um robô que é gradualmente melhor a cada sprint. Em termos de função, isso consiste em "desenvolvedores de software", "cara de CAD", "construtores" e "divulgação". A maioria dessa equipe NÃO está envolvida diretamente no software de codificação.

Para minhas empresas de software, a equipe normalmente consiste em desenvolvedores, testadores, devops, designers e suporte.

Em geral, o Agile não é uma coisa e existem muitas abordagens para implementar a filosofia. Mas, no centro, está a idéia de desenvolvimento iterativo, dividindo o trabalho em tarefas curtas e reavaliação contínua. Coisas como reuniões diárias de scrum, pendências, histórias de usuários etc. são frequentemente usadas, mas de forma alguma precisam ser "Ágeis". O Agile é sobre a adaptação constante, e isso inclui a maneira como uma equipe específica implementa o próprio Agile.

Portanto, resposta curta - sua equipe de gerenciamento não entende o Agile ou está usando isso como algum tipo de justificativa para eliminar as coisas que eles consideram um desperdício de dinheiro. Pode ser justificável fazer alterações, mas não é porque o Agile é apenas para programadores.