Eliminar requisitos detalhados, especificações de design extensas, governança problemática ou por etapas que acabam por dificultar o progresso, aprovações desnecessárias com atrasos independentes e todos os outros processos contraproducentes são os desafios que enfrentamos ao optar por implementar métodos lean agile.
Certamente não existe um método lean definitivo; no entanto, a estrutura é ou deve ser padrão em diferentes organizações, independentemente da solução ou modelo de negócios.
A escalabilidade é um fator chave aqui; as organizações desejam um processo que atenda às suas necessidades de negócios. Isso nem sempre tem ocorrido bem com todas as partes envolvidas na entrega de software, já que o que normalmente prevalece é a política de “faça o que eu mando”. Ou seja, uma abordagem concreta de cima para baixo, sem espaço para feedback de baixo para cima, o que indiretamente impede a liberdade necessária para impulsionar a criatividade na entrega.
E se uma organização pudesse “ter o bolo e comê-lo também”? Ou seja, um ciclo de feedback que permita às equipes incorporar valores que se integram à estrutura ou framework e que também retornem ao nível da equipe, permitindo que todos tenham sua participação. Isso geralmente parece mais fácil do que realmente é, mas um simples framework lean agile pode fazer maravilhas se todas as partes tiverem paciência suficiente para acompanhar o processo.
Este artigo simplesmente destaca a visão geral de uma estrutura lean agile necessária para construir a solução ou sistema complexo que resolve os problemas de hoje. Os três níveis que compõem um framework lean agile são:
- Nível de Equipe
- Nível de Programa
- Nível de Portfólio
Nível de Equipe
Esses são os soldados da linha de frente do processo de entrega agile, com a responsabilidade principal de escrever e testar os códigos que entregam valor. Esta equipe geralmente é composta por no máximo sete a nove membros, embora não seja o fim do mundo ter mais, considerando que algumas equipes estão comprometidas em construir grandes funcionalidades, sendo assim um ou dois membros adicionais não fariam mal.
Para que esse valor seja plenamente alcançado, a equipe de desenvolvimento deve ser apoiada por arquitetos, especialistas em garantia de qualidade (Quality Assurance), banco de dados e TI. Para satisfazer esse objetivo, algumas organizações seguem um modelo de equipe multifuncional, em que cada equipe possui um grupo de desenvolvedores, QA/testadores, especialistas em TI e engenheiros de banco de dados, algo ideal, mas na maioria dos casos impraticável, já que os recursos sempre serão escassos no mundo da entrega e gestão de software.
Em muitos outros casos, os membros da equipe podem ter mais de uma habilidade, o que pode ser útil para a equipe, mas isso deve ser incorporado no planejamento, pois um, dois ou três membros da equipe podem precisar dividir seu tempo para realizar mais de um tipo de atividade. Se isso é ideal ou não, certamente não é o tema de hoje, pois este artigo se concentra apenas em destacar a visão lean agile.
Uma coisa que sabemos é que as equipes são auto-organizadas e autogeridas para entregar funcionalidades ou componentes. Enquanto as equipes de funcionalidades se concentram em entregar iniciativas voltadas ao usuário, as equipes de componentes se concentram mais em construir plataformas compartilhadas ou camadas intermediárias que suportam a entrega de funcionalidades. A maioria das grandes organizações terá ambas. Essas equipes autogeridas e auto-organizadas devem ser flexíveis o suficiente para se adaptar às possíveis mudanças nas necessidades ou prioridades da organização, mas também devem ser estáveis o suficiente por pelo menos seis meses para passar pelas fases de tempestade, normatização e formação.
Os papéis em uma equipe agile típica são:
- O Scrum Master/Agile Coach
- O Product Owner
- Desenvolvedores
- Testadores
O Scrum Master/Agile Coach é sempre recomendado, mesmo que a equipe não esteja praticando Scrum. Ele/ela tem o dever de servir à equipe e ajudá-la a transitar para uma forma de trabalho agile, além de ajudar a gerenciar as cerimônias agile relevantes. Além da equipe, o Agile Coach também ajuda a alinhar a organização com o framework agile proposto ou acordado, com o objetivo de entregar valor, e algumas organizações podem chamar esse papel de gerente de projeto ágil (Agile Project Manager).
O Product Owner é responsável por priorizar os requisitos (User Stories) e gerenciar o backlog do produto. Este é um papel que também é muito importante, mesmo que a equipe não esteja praticando Scrum, pois provou ser um divisor de águas na simplificação do trabalho das equipes. Esse papel de Product Owner também se alinha claramente com o item número quatro do princípio agile: pessoas de negócios e desenvolvedores devem trabalhar juntos diariamente ao longo do projeto. O PO representa o negócio dentro da equipe.
Desenvolvedores e testadores escrevem e testam códigos e trabalham em sprints. Iteração é a palavra-chave associada ao trabalho que eles realizam, à medida que novas funcionalidades são construídas em eventos curtos e com tempo delimitado chamados de iterações, também conhecidos como Sprints se a equipe estiver usando Scrum. É importante notar que cada sprint entregará valor, que pode ser uma funcionalidade completa ou um incremento valioso que leva a uma funcionalidade completa.
Os papéis principais mencionados acima trabalharão juntos para planejar, construir, testar e demonstrar funcionalidades para as partes interessadas, inspecionar e adaptar, e finalmente repetir todo o processo.
Nível de Programa
O nível de programa é responsável pelo Agile Release Train, que também é delimitado por tempo, mas com um escopo variável, afastando-se, assim, do triângulo de ferro da gestão de projetos.
Em uma metodologia lean agile, o nível de programa é composto por papéis adicionais, processos e artefatos de requisitos, sendo geralmente adequado ou relevante ao construir sistemas ou produtos em larga escala.
Este nível do método lean agile ajuda a gerenciar:
- Releases e Incrementos Potencialmente Entregáveis,
- Visão, funcionalidades e o backlog do programa
- Planejamento de releases
- Roteiro e gestão de produtos
Releases/Incrementos Potencialmente Entregáveis:
O objetivo aqui é criar uma estrutura que permita às equipes produzir um incremento entregável, mas, novamente, o que realmente deve ser considerado entregável? Por que um determinado item deve ser enviado dentro de um determinado prazo? Como as expectativas do negócio serão atendidas? Quais são os padrões para refatoração, teste e quais processos de conformidade estão em vigor para garantir uma qualidade geral que atenda aos legítimos objetivos de negócios?
Fatores importantes como licenciamento do cliente e acordos de serviço, sobrecarga do cliente e interrupções nos negócios, treinamento de usuários, potenciais interrupções das operações existentes do cliente durante a regressão ou defeitos são todos considerados e gerenciados adequadamente dentro da categoria de gestão de releases no nível de programa.
Algumas organizações terão um gerente de release dedicado para este papel, o que geralmente deve facilitar bastante as coisas para a equipe.
Visão, funcionalidades e o backlog do programa:
Assim como um gerente de release pode ser introduzido na categoria acima, um gerente de produto pode ser introduzido aqui. A responsabilidade será manter a visão dos produtos. A visão responde a perguntas como:
- Qual problema a solução está resolvendo?
- Quais funcionalidades e benefícios ela fornecerá?
- Responde às perguntas de quem, o quê e por quê
- Confiabilidade de desempenho
- Plataformas e padrões que apoiarão a solução.
As respostas às perguntas acima manterão constantemente o foco da equipe e dos negócios em investir tempo e recursos apenas no que agrega valor ao objetivo e meta gerais do negócio.
Planejamento de releases:
A arte de trabalhar em cadência, a beleza de dividir funcionalidades em stories e adicionar stories acordadas na cadência de iteração com base no conhecimento de sua velocidade, origina o processo de planejamento de releases, que é composto por entradas da visão, objetivos e as funcionalidades desejadas, formando assim um lote para a próxima release com base na prioridade.
As equipes se reúnem em um único local e discutem suas interdependências, negociam o escopo com a gestão de produtos, guiados pela compreensão de sua velocidade conhecida, o que, por sua vez, determina quais stories podem estar viáveis na(s) próxima(s) release(s).
Essa atividade tem tanto benefícios tangíveis, como ter todos a bordo e participando por meio da colaboração na determinação do que deve estar no próximo trem de release, quanto um benefício intangível, onde as equipes se esforçam subconscientemente para cumprir seus compromissos.
Roteiro e gestão de produtos:
Uma série de releases planejadas e suas datas relevantes geralmente são mapeadas no roteiro, uma linha do tempo que mostra o plano de entrega para as funcionalidades da solução. O objetivo do roteiro é ajudar todos os envolvidos na entrega da solução a se alinharem à visão do produto.
Este é um exercício recorrente e as funcionalidades são revisadas, alteradas e movidas para cima ou para baixo, com base no feedback e nas metas e objetivos atuais do negócio, nas revisões das release e nas possíveis mudanças nos requisitos de conformidade.
Mais uma vez, a equipe de produto ou gerente de produto.
Nível de Portfólio
A visão geral composta por equipes ou indivíduos dedicados a gerenciar os investimentos da organização ou empresa, dirigindo a estratégia geral de negócios, se enquadra neste grupo. Os artefatos derivados aqui são:
- Temas de Investimento
- Épicos e Backlog de Portfólio
Tema de Investimento:
O estabelecimento dos objetivos de investimento para a organização, impulsionado pela visão de todos os programas, se enquadra neste grupo. Os gerentes de portfólio, proprietários de negócios e outros papéis de alto nível são responsáveis por gerenciar essa categoria e ajudarão a impulsionar os épicos que apoiam seus investimentos.
Aqui, os gerentes de portfólio são responsáveis por criar propostas de valor únicas que diferenciem a solução do mercado existente e criem uma vantagem competitiva, sendo geralmente derivadas e propostas nesse nível ao obter feedback tanto externamente quanto do nível de equipe e programa.
Épicos e Backlog de Portfólio:
O nível mais alto de expressão do cliente é chamado de épico. Eles são destinados a entregar o valor de um tema de investimento, e os gerentes de portfólio farão bem em identificar, priorizar, estimar e manter esses épicos dentro do backlog de portfólio. As métricas de estimativa recomendadas para esse nível podem ser o tamanho da camiseta (t-shirt sizing), ou seja, pequeno, médio e grande, que posteriormente serão decompostos ou divididos em funcionalidades, depois em stories, tornando-os prontos para implementação pela equipe.
Mais uma vez, para que tudo isso aconteça sem problemas, deve haver uma boa colaboração entre o nível de equipe, programa e portfólio. Todos se reúnem durante o planejamento de release e discutem qualquer diferença ou mal-entendido, orientando assim todos na mesma direção para a entrega da próxima cadência.
Treinamentos relacionados com essa postagem
