Você já é realmente ágil?

** Este artigo foi escrito por Jamie Buckley, chefe de engenharia da Foundry4, e foi publicado originalmente por ** ** Foundry4 ** , uma consultoria de tecnologia que ajuda organizações a aproveitar tecnologia para resolver os problemas complexos de hoje. Leia o artigo original aqui e mais Foundry4 ** [ insights aqui ](https://foundry4.com/our- intuições).**

Ver o Agile feito corretamente é um abrir de olhos. Isso muda sua visão dos projetos de software da mesma forma que agora é difícil imaginar ter que usar sabão, água e mãos para lavar suas roupas desde a invenção da máquina de lavar.

Mas as empresas que se autodenominam "Agile" e os projetos de software muitas vezes fracassam. Para o novo engenheiro de software, há o perigo de que essa ferramenta incrível para entregar projetos de software bem-sucedidos se torne envenenado em seus olhos.

• Quer escrever para nós? Dê uma olhada no ** [ guia para colaboradores **] da Apolitical (https://apolitical.co/opinion-writing-becoming-an-apolitical-contributor/)

Talvez o principal problema seja que o Agile não resolverá seus problemas, apenas os exporá. Não gosto de espelhos exatamente pelo mesmo motivo, é desconfortável ver suas falhas e manchas apresentadas de volta para você ...

Eu descreveria o Agile como o processo de ** trabalhar como uma equipe **, em ** pequenas peças bem compreendidas ** de trabalho, para obter uma parte ** entregável ** dos referidos itens de trabalho completa, fornecendo valor comercial ** incremental **. É um conjunto de princípios orientadores, onde o domínio e a maturidade surgem na escolha de usar padrões e estruturas, em vez de segui-los cegamente.

Trabalhe em equipe e tente entender o que você está construindo antes de você construa. Não morda mais do que você pode mastigar. Certifique-se de que as mudanças de direção sejam de baixo custo, examinando frequentemente o que você está fazendo e o que está construindo. Se tudo isso soa como senso comum, é porque isso é tudo que o Agile deve ser.

Stand ups são para a equipe

As palavras para causar medo no coração de um engenheiro de software:

_ ** Ontem fiz ... Hoje estou fazendo ... ** _

Como é do conhecimento geral, a coisa favorita de todos é ser forçado a falar na frente de um semicírculo de outras pessoas, que os encaram em silêncio, esperando sua vez. A melhor parte é saber que cada pessoa no grupo ouviu cerca de zero por cento do que você acabou de dizer, estando muito preocupada em ensaiar o que estão prestes a dizer.

O gerente de projeto malvado olha para você ameaçadoramente, e raios estalam em cima.

_ ** Como você ainda está trabalhando nesta história, quando a medimos apenas em três laranjas e um mamão? ** _

Estou exagerando um pouco, mas esta não é uma situação estranha, especialmente se você odeia falar na frente de outras pessoas.

Se alguém está fazendo você dizer o formato "ontem eu fiz, hoje estou fazendo", não se sinta mal pela forma como você se sente. Isso não é Agile, é um KPI. Você não está trabalhando em uma empresa de software, está trabalhando em um call center, onde tem que fazer x número de vendas por dia, sem um entendimento mais amplo do contexto. Se você está fazendo sua equipe fazer isso, saiba que eles se ressentem de você por isso e fazem caretas pelas suas costas.

O erro que está sendo cometido aqui é simples. O formato “ontem, hoje” é para garantir que todos estejam tão ocupados quanto possível ou para colocar um membro da equipe contra outro. Mas o foco deve estar no trabalho no sprint, não no indivíduo.

Esta é uma maneira diferente de fazer isso:

_ ** Em seguida, o recurso submersível de açafrão. Vejo que ainda está em desenvolvimento. Paul, como vai? ** _

_ ** Paul: Na verdade, encontrei alguns problemas, acho que isso vai dar mais trabalho do que esperávamos. ** _

_ ** Entendo, talvez outra pessoa da equipe possa ajudar fazendo par com você nisso? João? Importa-se de ajudar? ** _

Discussão. Problema. Solução. Os Beatles estão agindo corretamente ...

Talvez este processo exponha que você não está gastando tempo suficiente refinando suas histórias, ou sua ** definição de pronto ** está faltando. Talvez exponha que um pico (parte do trabalho exploratório com limite de tempo) deveria ter sido feito para entender completamente o problema. Talvez exponha que as estimativas são muito otimistas. Seja o que for, é algo para discutir no retro (o exercício retrospectivo no final de um sprint onde você examina o que deu certo / errado).

A palavra 'expõe' aqui, é a parte chave. O Agile pressupõe que você está trabalhando em um ambiente sem ego, onde todos se preocupam em fazer o trabalho e ficam felizes em ajudar os outros a resolver seus problemas. Assume que a equipa tem autoridade e autonomia para identificar o que está a atrapalhar e resolver os problemas.

O desafio do refinamento

Se você selecionou um recurso para trabalhar e as informações no tíquete estão faltando, há problemas no início da cadeia. Tenho certeza de que muitos engenheiros terão alguma experiência de serem solicitados a escrever algo ao longo das linhas de:

_ ** Construir algo que faça isso ** _

Seguido por um e-mail na metade do trabalho que diz.

_ ** Espere não, exceto neste caso. ** _

Esses requisitos deveriam ter sido resolvidos com antecedência e boa sorte para o testador que não estava na cadeia de e-mail. Parte do problema é que as pessoas não são boas em descrever o que querem (pergunte a qualquer profissional da indústria da arte) e também não são boas em pedir que descrevam o que desejam.

Lutar para descrever o que você quer não é uma falha de caráter pessoal. Se você é um proprietário de produto novo, não se sinta mal porque sua experiência em seu campo não se traduz imediatamente em requisitos concretos, é preciso muita prática.

Veja meu artigo em BDD (Behavior Driven Development) para uma ferramenta potencial para usar aqui, ou apenas pegue qualquer livro sobre BDD e mapeamento de exemplo. Caso contrário, apenas faça desenhos do que é necessário. Qualquer coisa que não seja uma dança interpretativa que forneça um significado inequívoco e rastreável e indique as perguntas certas é útil.

A profissão de analista em engenharia de software é essencialmente a aplicação profissional de ter conversas úteis, o que é mais difícil do que parece. Isso é ótimo, mas a menos que o refinamento possa responder às perguntas de forma significativa, é apenas a introdução de uma nova camada para culpar na cadeia quando os mesmos problemas acontecem. Todas as partes envolvidas precisam de disposição para sentar e compreender o problema, uma estrutura para captar o entendimento e fazer as perguntas certas.

Pior ainda, às vezes o refinamento pode ser apenas pessoas de negócios e técnicas em uma sala juntas, pensando incorretamente que estão de acordo um com o outro. Isso é tão ruim quanto não ter uma conversa, há uma razão pela qual o famoso ‘Três Amigos’ não é ‘Dois Amigos’.

** Uma solução simples aqui ** é ampliar os tipos de pessoas na sala. Deve haver pelo menos uma pessoa que fale negócios, uma pessoa que fale tecnologia e um QA / testador / quem será solicitado a verificar se os dois idiomas falados correspondem.

Essas pessoas devem ser capazes de discordar amigavelmente. Refinamentos devem parecer um argumento amigável para qualquer trabalho não trivial. O BDD é excelente aqui porque fornece uma linguagem comum com a qual todas as três partes podem resolver suas divergências.

Já está se divertindo?

Isso nem sempre vai funcionar. Parte da natureza do Agile é aceitar que as coisas dão errado, que o software é difícil e que todos nós, até certo ponto, estamos tateando nosso caminho no escuro. Se parece que o Agile é apenas um conjunto interminável de dúvidas "estamos fazendo isso certo?" reuniões, isso porque gerenciar um projeto é difícil. (Waterfall não era melhor nesse aspecto, era apenas o equivalente a um casal reprimindo seus sentimentos até que um deles envenene os ovos mexidos …)

Sem uma estrutura para destacar e corrigir problemas, pode surgir um exercício negativo em que equipes ou indivíduos culpam uns aos outros.

_ ** É culpa da empresa por não explicar o que queria ** _

_ ** É culpa do engenheiro de software por entender mal o que foi pedido ** _

_ ** É culpa do testador deixar esse bug se espalhar ** _

Tudo isso é reativo e não vai ajudar. Sente-se em uma sala, discuta o que você achou que deu errado na ** _ história recente _ ** , ou seja, o último sprint. Em seguida, proponha o que poderia ser melhorado. Ouça o que as pessoas estão dizendo e esteja aberto à ideia de mudar a maneira como você trabalha.

Talvez a empresa não entendesse o quão complexo era o que eles estavam pedindo para entregar.

Talvez os engenheiros estejam muito entusiasmados para construir coisas legais e não estejam mais pensando em construir um MVP altamente focado. Claro, eu mesmo nunca fui culpado disso ...

Talvez os testadores estejam se esforçando para entender o que realmente foi pedido em meio ao caos e às facções em conflito.

Fale o que pensa, diga o que o está incomodando e o que o ajudaria. Faça algo de bom juntos como uma equipe para comemorar um sprint de sucesso. Temos sorte de trabalhar em uma profissão fundamentalmente divertida. O Agile deveria estar fazendo você dizer que ontem você gostou do seu dia de trabalho e hoje está se divertindo muito. ** - ** ** Jamie Buckley **

** Queremos saber sua opinião sobre este artigo. ** ** Lance um artigo ** ** para nós ou envie seus comentários para ** hello@apolitical.co

(Crédito da foto: Unsplash)