Executando verificação de segurança...
6
viniciusreinehr
6 min de leitura ·

A fantástica fábrica do desenvolvimento ágil

Atualmente é quase uma regra, TODA empresa se diz defensora de metodologias ágeis e quase que em todas as vagas abertas, pedem conhecimento em Scrum, Kanban, Lean, XP entre outras 50 metodologias existentes no mercado.

Trabalho com metodologia ágil a 5 anos e decidi trazer aqui algumas visões e algumas soluções para que possamos parar de sofrer com Métricas como Cycle time, Lead time, story points, etc.

O Grande PROBLEMA

Muitas empresas que estão trabalhando atualmente com metodologia ágil, veio do modelo cascata, sendo assim, algumas delas não conseguiram entender qual o problema que o ágil veio solucionar e acaba utilizando um modelo cascata dividido em cerimônias e ritos ágeis.

E qual problema o ágil veio solucionar?

Mensurar o tempo que será necessário para desenvolver determinada tarefa sempre foi nosso calcanhar de Aquiles. Nós 'malemal' temos uma noção do tempo que levaremos, mas nossa precisão de tempo é horrível. Podemos imaginar o pior cenário possível e falar que levaremos 10 dias e quando começarmos o desenvolvimento, levamos 2, como podemos mensurar o melhor cenário possível e mensurar 2 dias, ai teremos diversos problemas e levaremos 10. Sendo assim, o ágil nos ensina a olhar para o passado para planejar o futuro, complexo? calma, vou detalhar e explicar abaixo.

Como posso quebrar as primeiras tarefas em entregáveis?

Primeiro passo é criar um padrão inicial para poder melhorar esse padrão a cada ciclo. Minha sugestão inicial é: Quebre as tarefas de uma maneira que elas possam ser desenvolvidas em 1 dia de trabalho.

Exemplo:
Estamos criando o tabnews, como podemos "quebrar" ele em entregáveis?

  • ÉPICO-1: Versão inicial do Tabnews
    • STORY-1: Barra superior contendo logotipo
      Aqui não será adicionado itens de menu, nem login, nem busca, nem pontuação, somente a logotipo
    • STORY-2: Lista das postagens ordenado por data da postagem limitado em 30 itens
      Aqui terá somente o titulo a postagem com um espaço entre elas
    • STORY-3: Paginação da lista a cada 30 itens
      Aqui será somente a paginação, repetindo o mesmo layout da lista anterior
    • STORY-4: Rodapé contendo a logo junto ao ano atual
      Não terá itens de menu, somente a logo
    • STORY-5: Tela de detalhe da postagem com titulo e conteúdo
      Não terá voto, não terá data, não terá nada alem do titulo e conteúdo

Preste bastante atenção nos comentários abaixo das tarefas, aqui, não terão funcionalidades adicionais, o primeiro desenvolvimento será o básico do básico, qualquer possível melhoria deverá ser tratado como melhoria.

Como definir os próximos passos após o primeiro desenvolvimento?

Precisamos de feedback do usuário, durante o uso, os usuários entenderão quais são as principais dificuldades e melhorias que precisam ser implementadas. Você não precisa deduzir nada, escute o seu usuário.

Quais os tipos de tarefa mais comuns?

Existem diversos tipos de tarefas, algumas delas entregam valor visivel ao usuário e outras entregam valor invisivel ao usuário.

Exemplos:
Valor visivel -> Campo de busca onde o usuário poderá buscar por um conteúdo específico
*O usuário conseguirá interagir com a funcionalidade, será uma funcionalidade "palpável" para ele.
Valor invisivel -> Melhoria na performance da consulta ao banco de dados, reduzindo em 30% o tempo gasto para localizar um conteúdo.
O usuário não consegue ver nenhuma mudança no site, porém, sua experiência de uso será muito melhor

Abaixo, alguns tipos de tarefas que eu já vi e gostei do uso:

  • Tarefas "mãe"

    • Story: Nova funcionalidade visível, algum entregável e testável.
    • Technical Debt: Durante o desenvolvimento foi identificado algo que poderia ser melhor, não deve ser corrigido durante o desenvolvimento da estória e sim, criado um débito técnico para solução futura(se necessário).
    • Technical Solution: Alguma melhoria de performance e/ou usabilidade que não será visivel pelo usuário final. Uma inclusão de atributo, melhoria de consulta, etc.
    • Task: Criação de um banco de dados, servidor, repositório, etc. Algo que seja necessário para o negócio mas não será visivel ao usuário.
    • Bug: Quando alguém da equipe identificou um problema no fluxo que precisa ser corrigido.

  • Tarefas "filho"

    • Sub-Task: Quando uma das tarefas acima terá mais de uma ação, ela poderá conter sub tarefas. Ex.: 1. Criar titulo do tópico, 2. Criar descrição do tópico, 3. Realizar testes
    • Sub-Bug: Quando durante o pré teste, o QA ou próprio Dev identificou um problema que precisa ser corrigido, ele cria um sub-bug para sinalizar o time que ele terá um tempo a mais que será gasto naquela atividade.

Mas se eu mesmo encontrei um bug, eu já corrijo, não vou abrir um bug para isso

Vamos lá, imagine que você está dirigindo seu carro para ir a uma festa, segundo o GPS, o trajeto será feito em 15 minutos. Quando você chegou a uma bifurcação, você acabou pegando a saída errada. Tudo bem né? sem problemas, só fazer o retorno e pegar a certa. Sim, mas o tempo estimado já não será mais de 15 minutos e sim, 20, ou mais, dependendo de onde você conseguir fazer o retorno.

BUG NÃO É O FIM DO MUNDO

Vocês precisam abrir, documentar, escrever para que possam aprender com ele e evitar que volte a acontecer coisas similares no futuro.

O que é mais correto utilizar? Scrum? Kanban? Qual?

Não existe uma receita de bolo para isso. Depende das pessoas que fazem parte do time, do produto que está sendo desenvolvido, do público alvo, etc. Os fatores são MUITOS. Você precisa implementar um processo inicial e ir adaptando ao seu negócio.

Minha dica é: Vai utilizar Scrum? Estude tudo sobre, implemente 100% Scrum no fluxo e em seguida vá polindo e adaptando ao seu negócio.

Já vi empresas que alguns times utilizam Scrum, outros Kanban, Outros 'Scrumban' e todos os times funcionam na sua própria maneira entregando valor ao usuário.

E como eu, mero integrante do time, posso implementar isso aqui na empresa, se meus líderes não estão nem ai?

Bom, contra fatos, não há argumentos. Estude, utilize no seu dia a dia os conceitos do ágil, aos poucos, compartilhe com seus colegas suas metodologias, quando menos esperar, o time estará trabalhando de uma maneira ágil e entregando valor ao negócio sem fazer 500 horas extras por mês.

Como posso implementar o ágil no meu trabalho se o time não usa?
Vamos supor que te passaram a tarefa de criar um endpoint de listagem de tópicos que recebe no payload os campos de busca, usuário e ordenação e devolve no response titulo, data da postagem, descrição e usuário que postou. E para isso, te deram o prazo de 5 dias(um absurdo, ou não).
Pegue essa tarefa e divida da seguinte forma:

  • Criar Controller do endpoint sem receber nada e devolvendo vazio.
  • Criar consulta no banco de dados trazendo as postagens
  • Criar o service que vai devolver ao controller o resultado da consulta
  • Criar o payload por usuário
  • Criar o payload por busca
  • Criar o payload da ordenação

Dessa forma, você terá uma melhor visão da porcentagem de conclusão a cada dia e todo dia saberá qual a sua chance de concluir a tarefa dentro do prazo esperado. Sendo assim, caso surja um impedimento logo no primeiro dia, poderá reportar ao seu líder que a tarefa irá atrasar explicando os motivos.

A Vinicius, mas na teoria é fácil, quero ver na prática

Sim, na teoria sempre é mais fácil, mas a minha sugestão final é:
NÃO TENHA MEDO DE ERRAR

Tente, mude, tente novamente, mude, tente novamente, e assim por diante, mas não deixe de tentar e melhorar.

O processo NUNCA estará perfeito, mas poderá ser cada vez melhor a cada ciclo.

Um grande abraço a todos!

Se quiserem ajuda com alguma coisa ou tiverem alguma dúvida, sintam-se à vontade para perguntar!

Carregando publicação patrocinada...
5
lehen

Rapaz, eu tenho uma visão um pouco diferente.

Já tem uns anos que eu to na área e vou te falar que a discussão sobre como fazer o "agile certo" já dura uns 10 anos, viu?

O que eu reparo é que quanto maior o foco no processo, pior o time performa e quanto menor, melhor costuma ser. E, não, não estou defendendo um anarquismo do contribuidor individual, isso nunca funcionaria. Apenas focar na coisa certa.

O lance é que quem foca no processo, normalmente não foca na parte mais importante que são as pessoas do time. Nossa, já trabalhei em uma empresa que o time tava se odiando pelos mais diversos motivos e o pessoal achava que mudar o sistema de pontos de fibonacci pra tamanho de camisa (P, M, G) ia resolver a parada, socorro!! Já vi gente olhando toda sprint pra burn down chart e tentando tirar alguma lógica daquilo (eu chamo de astrologia do agile).

Hoje em dia eu vejo que o agile está morrendo aos pouco na indústria, já não ouço mais falar muito sobre qual metodologia está sendo usada em uma determinada equipe nem escuto muito falar sobre ser enfático nas regras... na verdade eu vejo uma discussão sobre como POs e Agilistas ficaram em uma posição difícil nesse mercado que ta mudando.

A minha opinião sobre gestão é que o processo ajuda, mas um time que se escuta, ta engajado, entende o que ta sendo feito vai produzir muito mais que um time disfuncional com um sistema de gestão impecável.

Malz desvirtuar um pouco o post, que eu sei que não é sobre a validade ou invalidade do Agile, mas queria colocar essa posição. De qualquer maneira, tome um TabCoin por iniciar o assunto =]

1
viniciusreinehr
Autor
Autor

Com certeza o foco deve ser nas pessoas prioritariamente.
Sempre comentei com meus superiores que queriam milagres dentro dos times:

Se implementarmos o Scrum mal implementado, ninguém irá gostar do Scrum

As mudanças e implementações devem ser feitas pouco a pouco, para que se aprenda sobre as pessoas que fazem parte daquele time e se entenda quais as melhores práticas para tais.

Já trabalhei em time que utilizamos Scrum com XP, outras que tinhamos as cerimônias do Scrum mas o board Kanban e outras com as mais diversas mixagens de metodologia.

É necessário entender as cerimônias e utilizar elas de uma maneira que seja produtiva e não massante. Trabalhando em outros cargos, para auxiliar os times na implementação do ágil, já vi Squads que a daily durava mais de 1 hora e não se respondia nada, acabava a daily e as pessoas saiam com a sensação de terem jogado fora 1 hora do dia.

O ágil veio para auxiliar o time a fazer o pessoal da gestão entender os prazos por eles dados, mas acabou caindo em um cenário que o pessoal da gestão usa o ágil para "julgar" o time, ou seja, vira uma confusão e nada melhora.

E diversos "Scrum Masters" que só tiraram a certificação mas não entenderam de fato a metodologia, não sabe nem fazer uma resolução de conflitos, não sabe o básico, manter o time unido no objetivo.

É igual para todas as coisas que existem e todas as que vão existir, por causa de alguns, todos serão julgados culpados. É o famoso 'pré conceito'.

Não só para o ágil, mas para tudo, desde não utilizar software pirata, respeitar as leis, escutar mais do que falar, entre outras coisas, precisamos ser sempre melhores para que em um futuro longínquo, tudo se torne melhor.

1
raf

Concordo, a metodologia ágil sempre teve como objetivo central as pessoas em detrimento do processo. Isso é claramente expresso no manifesto ágil:

Individuals and interactions over processes and tools
"Indivíduos e interações acima de processos e ferramentas."

Muitos projetos de desenvolvimento de software sofrem de má gestão e tentam mudar o processo na ilusão de que um milagre ocorrerá. Na realidade, o verdadeiro "milagre" é algo muito mais simples: entregar software funcional em pequenas partes incrementais.

1
raf

Eu venho trabalhando com metodologia ágil há 15 anos. Tirei certificação Scrum Master e trabalhei com várias funções, tais como desenvolvedor, Scrum Master e líder de projeto.

Eu gostaria de compartilhar a minha opinião porque a grande maioria das organizações e pessoas não enxergam uma das principais motivações das metodologias ágeis: adaptar a mudanças constantes.

A realidade do modelo cascata é que a maioria destes projetos acaba mudando no meio do projeto por várias razões: a ideia de negócio mudou, requisitos não funcionais mudaram, o orçamento mudou, etc. Um exemplo clássico seria um projeto que foi arquitetado com várias integrações com e-mails; mas durante o desenvolvimento, o WhatsApp ficou popular, e agora o requisito mudou para usar o WhatsApp. Ou melhor ainda, a ideia de negócio mudou completamente, e agora querem mudar para um modelo muito diferente, aproveitando algumas partes do sistema anterior. Neste tipo de ambiente, o modelo cascata fracassa.

O modelo ágil tenta minimizar as falhas do modelo cascata. Contudo, os líderes de muitas empresas por aí ainda tiveram treinamento clássico em gerenciamento de empresas e querem o planejamento clássico do modelo cascata mascarado de ágil.

Para o modelo ágil funcionar, é necessário o apoio da gestão com entendimento da área de gestão de desenvolvimento de software e economia clássica e/ou economia comportamental para realmente aplicar a metodologia ágil.

Bom, eu poderia escrever muito sobre o tema, mas não vejo a necessidade. Vou parando por aqui.

1
viniciusreinehr
Autor
Autor

Concordo, inclusive, já vi empresas se dizendo ágeis, com uma sprint de 2 semanas e um cycle time de 70 dias.

É de extrema importância que o ágil seja implementado aos poucos, melhorando a cada ciclo. Mas o que vejo em vários casos é ciclos se repetindo com os mesmos erros, como se todos estivessem de olhos vendados.

Escutei uma vez um Scrum Master falando: "- Estamos atrasados com essa tarefa, mas já temos um plano de ação definido. O Pessoal vai fazer 3 horas de hora extra até sexta e vai trabalhar fim de semana.".

Um Scrum Master que considera Hora Extra como plano de ação, comprou sua "habilitação" no paraguai. Uma frase dessa já deveria remover o certificado dele da parede instantaneamente.

1
gaido

Um dia desses eu estava passeando com meu cachorro, e uma pessoa se aproximou:

-- Que lindo. Qual o nome dele?
-- Scrum Master.
-- Posso passar a mão?
-- Pode. Ele não faz nada.

Agora falando seriamente.
O Manifesto Ágil surgiu para remover uma série de partes do processo de desenvolvimento de software que eram venenosas.

Décadas depois, frameworks de processos e, equipes e empresas inteiras ganham dinheiro pra vomitar processos de desenvolvimento de software venenosos.

É preciso um outro manisfesto pra limpar essa baboseira toda de novo.

1
viniciusreinehr
Autor
Autor

-- Tinha um papagaio que aprender a falar "E ai, como estamos?" e ele foi promovido a Scrum Master.

Como comentei acima, devido a MUITOS não saberem o básico antes de se tornarem SM, todos pagam por isso.

Já conheci pessoas que tinham todas as certificações possíveis do Scrum e não sabiam nem como conduzir uma cerimônia. Ou seja, as empresas certificadoras acabaram se tornando uma máquina de fazer dinheiro(um certificado é bem caro), ao invés de se tornar a máquina de fazer Scrum Master.

Não existe manifesto que mude uma mentalidade. Se vier um coach e falar bonito, vários vão seguir ele e falar que ele é um gênio, mas poucos vão entender de fato e seguir sua filosofia.

1