Devs de back-end descartados por histórias de usuários

Planejei dividir o desenvolvimento de back-end nas histórias de usuários verticalmente. Mas um funcionário da nossa equipe começou a reclamar que isso torna seu trabalho invisível.

Minha resposta foi que

• nas reuniões de planejamento e revisão do sprint, discutimos tarefas de back-end na frente das partes interessadas, para torná-las visíveis e

• manter uma alta qualidade durante o projeto resultará em um ritmo de início mais lento do que em outras equipes, mas teremos uma velocidade estável durante o projeto. E a velocidade é altamente visível para as partes interessadas.

Ele ainda insiste em ter histórias como: "Como desenvolvedor, preciso ter uma camada de domínio para encapsular a lógica de negócios".

Como posso resolver o problema antes que ele polua a equipe?

A raiz do problema é que nosso gerenciamento considera sistematicamente o trabalho de back-end como invisível e chama os devs mineiros de desenvolvedores ou outros termos pejorativos.

Há algumas coisas erradas na situação descrita, o problema óbvio é a falta de respeito dada aos desenvolvedores de back-end. Como esta pergunta é marcada como ágil, vou adiar outras respostas, sugerindo que isso é apenas um problema social. Existem vários maus cheiros e possíveis antipadrões em sua história, nenhum dos quais tem a ver com gerenciamento ignorante ou mesmo como você os divide.

O fato de um grupo de indivíduos da equipe se sentir menosprezado por não receber a glória do trabalho completou vários problemas possíveis.

• Não deve haver pessoas que apenas desenvolvam back-end. Uma abordagem comum do Agile é ter equipes multifuncionais compostas por especialistas em generalização que praticam a propriedade de código compartilhado. Os indivíduos não devem se concentrar exclusivamente no desenvolvimento de back-end ou front-end, embora certamente tenham mais experiência ou melhor em algumas coisas do que em outras.
• Arquitetura não ganha valor. Da perspectiva de um usuário - a única perspectiva que realmente importa - não importa se você possui camadas ou idiomas de domínio ou mesmo se a solução está programada. A única coisa que importa é se você criou valor para os usuários. A "história" proposta pelo desenvolvedor de back-end é um requisito sem sentido - é um resumo das decisões de design que, da perspectiva de um usuário / cliente, não fazem nada para alcançar a funcionalidade desejada. Em outras palavras, qualquer história de usuário pode ser alcançada por vários projetos de arquitetura diferentes. É possível que uma história de usuário seja concluída sem nenhuma modificação no backend. Isso não a torna uma história inválida.
• Pensar sistemicamente ainda é crítico. Embora a arquitetura possa não agregar valor, ainda é essencial para o sucesso. O desenvolvedor de back-end tem algumas preocupações válidas. Você deve estar pensando em como criará o sistema. Você deve escrever essas decisões. Todo o sistema é importante, embora apenas os recursos de front-end sejam os itens que receberão toda a glória.

Minha recomendação é tratar a arquitetura como um cidadão de primeira classe - mas faça-o da maneira certa. Realize um workshop de atributos de qualidade com as partes interessadas . Envolva as principais partes interessadas nas revisões de arquitetura ou, pelo menos, resuma decisões de design essenciais em etapas importantes. Desenhe a arquitetura em papel grande e torne-a visível para que toda a equipe possa vê-la.

Exija que todos desenvolvam em qualquer lugar do sistema (front-end e back-end), emparelhe o programa, se necessário, para que isso possa acontecer de maneira eficaz. Continue a criar histórias de usuário focadas no usuário. Mas também identifique os principais cenários de atributos de qualidade que mostram por que o sistema é projetado da maneira como é e impulsiona a tomada de decisões em relação ao design de "back-end". Eleve o design da arquitetura para que não fique mais invisível.

Isso parece ser um problema social, por isso precisará de uma solução social.

Se (como eu o entendo) os desenvolvedores de back-end se sentem ignorados e menosprezados, e sentem que seu trabalho não é valorizado o suficiente, então há pouco que o processo de desenvolvimento possa fazer para mudar isso.

Se eu entendi direito, parece que os desenvolvedores acham que deveriam ter pelo menos suas próprias histórias de usuários, para que possam apontar para eles e dizer "Foi isso que fizemos, basta fazer o back-end de caras / moças". No entanto, ter histórias cortadas "horizontalmente" dessa maneira é uma má idéia, e eu concordo que você as corte verticalmente.

A melhor solução é provavelmente conversar em silêncio com o (s) desenvolvedor (es) em questão (individualmente ou em grupo) e abordar o problema subjacente, que parece ser de respeito. Em algum momento, isso provavelmente precisará ser encaminhado para o gerenciamento.

A raiz do problema é que nosso gerenciamento considera sistematicamente o trabalho de back-end como invisível e chama os devs mineiros de desenvolvedores ou outros termos pejorativos.

Na verdade, este é o problema. É óbvio que você não vai resolver isso com histórias!

Em geral, uma das características do desenvolvimento ágil é a transparência. Isso também significa que isso torna seus problemas organizacionais mais manifestos .

A solução ágil padrão para esse problema é adotar uma abordagem mais "vertical" ou "full-stack" para o desenvolvimento, onde seus desenvolvedores de back-end levam histórias de cima para baixo em vez de simplesmente trabalhar na zona de conforto da camada de back-end e os desenvolvedores de frontend também se estendem para o backend (*).

Em outras palavras: faça com que todos produzam valor para seus usuários finais.

^{(*) Nota: nem todas as matérias precisam ter um componente front-end ou back-end. Os elementos da interface do usuário podem ser reorganizados sem trabalho adicional de back-end, e o desempenho é um recurso .}

Seus problemas são:

• Você tem camadas de gerenciamento em seus negócios, onde elas não servem para nada. Scrum, ágil, eu não ligo. O gerenciamento e o desenvolvimento devem ser isolados com as preocupações comerciais tratadas por um gerente de produto que tenha uma pista! @ # $ Ing sobre tecnologia. Talvez tenha funcionado para Steve Jobs, mas eu nunca estive em uma situação em que gerentes não especialistas em tecnologia, estando perto de desenvolvedores, fossem algo saudável ou, finalmente, servissem para produzir o melhor produto de qualidade que uma equipe poderia ter produzido.

• Você tem desenvolvedores que estão mais preocupados com as aparências do que com os problemas. Esse é um problema de cultura muito sério (parece provável, considerando todo esse fenômeno "mineiro") e / ou você tem um problema de qualidade do desenvolvedor, o que também não me chocaria devido à falta de confiança.

Tire as pessoas que não precisam estar lá fora do planejamento e da postura. Qualquer pessoa que tenha noções de que o back-end é menos importante que o front-end é alguém que não precisa estar lá e está de fato dificultando o processo por estar lá.

Valas de histórias. Sim, estou a falar a sério. Se eles estão causando esse tipo de problema, jogue fora a câmara. No meu trabalho atual, mantemos apenas os critérios "concluídos" para uma determinada tarefa, que normalmente permanece mais focada no aplicativo do que no usuário, o que pode ofender aqueles que pensam que o ágil (que está mudando constantemente há 20 anos) ganhou " Não funcionará se você não seguir as instruções, mas, na verdade, se somos profissionais, não precisamos de nada que esteja causando problemas para nós. Amasse-os, jogue-os por cima do ombro.

E você pode lembrar que os desenvolvedores de que as pessoas com quem realmente precisam se preocupar são seus pares imediatos, não as pessoas que não têm noção de nada para planejar o sprint.