Introdução
Desde o fim dos anos 1990, temos testemunhado o crescimento das metodologias ágeis no desenvolvimento de software. As empresas têm se preocupado, cada vez mais, em ter ciclos mais curtos e com entregas menores e mais assertivas. Essa mentalidade foi absorvida por startups, a fim de promover suas ideias no mercado o mais rápido possível e se adaptar a ele progressivamente. O modelo foi se consolidando e, com o tempo, foi sendo aplicado em grandes organizações. Com isso, a complexidade, assim como os desafios, foram aumentando.
O que anteriormente se limitava ao escopo local, com entregas pequenas, foi escalado e se tornou desenvolvimento distribuído, com equipes remotas e diversas integrações, também conhecidas como interlocks. As entregas de software, hoje, compartilham sotaques, idiomas e fusos horários, fazendo a simplicidade dos frameworks, como Scrum e Kanban, se adaptar às diversas culturas presentes nas grandes organizações.
Foram criados frameworks para organizar o trabalho nessas situações, tais como o SAFe, que visa otimizar o fluxo de trabalho em ambientes distribuídos. Geralmente, temos os seguintes papéis:
- Scrum Master/Technical Project Manager (TPM): blinda o time, resolve impedimentos e planeja entregas;
- Product Owner (PO): alinha regras de negócio e requisitos a serem desenvolvidos pelo time;
- Time: composto por desenvolvedores, testadores, PO e Scrum Master.
- Gerente de Programa (PgM): alinha o roadmap do projeto/programa entre times especialistas. Geralmente, serve como par dos Scrum Masters, em um nível mais abstrato;
- Gerente de Produto (PdM): provê a orientação da direção a ser alcançada pelo produto dentro de um programa. Geralmente, serve como par dos Product Owners, em um nível mais abstrato.
É importante salientar que podemos ter diversos times trabalhando com um mesmo Gerente de Programa e Gerente de Produto, sendo assim, alguns colaboradores podem depender de outros para uma entrega. Nesse contexto, algumas questões que não faziam sentido no passado passaram a ser cotidianas, tais como:
- Devemos fazer nossa reunião diária no horário da Irlanda, local do nosso time parceiro, ou no horário do Brasil?
- As questões de formato de endereço projetadas pelo time na Índia para as vendas no Canadá não previram na arquitetura que o formato brasileiro era distinto.
- O escopo que estamos desenvolvendo já foi feito para os Estados Unidos e gerou retrabalho.
- Um gerente de outro time está usando os recursos do time para uma outra tarefa.
O Instituto Eldorado trabalha, atualmente, com empresas multinacionais. Nesse contexto, e com nossa experiência, gostaríamos de compartilhar um pouco desse conhecimento com a comunidade de desenvolvimento de software. Devemos ressaltar que, talvez, o leitor discorde de alguns tópicos, já que ele acredita em estruturas horizontais e liberdade no ambiente de trabalho, porém, as situações descritas abaixo são casos reais de desenvolvimento ágil. Ficarei feliz se puderem contribuir com meu artigo.
Desafios
A fim de compartilhar nossos conhecimentos, dividi os desafios em categorias:
Gestão de projetos
Desafio: Prioridade de programas
Descrição: em ambientes distribuídos, a gama de programas rodando ao mesmo tempo é considerável e a comunicação entre eles, muitas vezes, não é a mais eficiente. Nesse meio tempo, prioridades externas ao projeto podem ser escaladas.
Exemplo: projetos de adequação fiscal com prioridade maior do que melhorias da plataforma. A troca de prioridades é feita sem um devido planejamento forçando o time a se adaptar em um escopo desconhecido.
Efeito colateral: time desmotivado, sem noção dos próximos passos, necessidade de hora extra e baixa qualidade de vida.
Mitigação: nessas situações, é necessário um PdM e PO fortes, monitorando projetos paralelos, e um TPM que possa tenta frear intervenções externas ao time.
Desafio: Requisitos conflitantes
Descrição: considerando um ambiente global, os requisitos dependem de diversos fatores. Uma implementação de uma funcionalidade de modo deliberado pode impactar negativamente um outro requisito implementado com outro fim.
Exemplo: simplificação de uma regra de negócio que pode impactar na forma de taxação de um país.
Efeito colateral: retrabalho em todos os níveis, desde a concepção do requisito até a validação em diversas etapas (desenvolvimento, testes, homologação e entrega). Também pode ocorrer perda financeira pela falha de análise.
Mitigação: o time (e principalmente o PO) deve trabalhar muito próximo da área de negócio, a fim de garantir que o projeto seja desenvolvido corretamente o quanto antes. É importante aproveitar os ciclos curtos da metodologia utilizada para poder fazer ajustes o quanto antes – falhar e reagir rapidamente.
Desafio: Gestão de Stakeholders (partes interessadas)
Descrição: a gestão das partes interessadas em ambientes distribuídos é mais complexa do que em projetos locais. As expectativas e comunicação devem ser analisadas cuidadosamente, uma vez que podem trazer problemas na entrega.
Exemplo: implementação de pacotes que afetam outras equipes de desenvolvimento e a área de negócios requisitando mudanças que não fazem parte do roadmap.
Efeito colateral: conflito de interesses e desalinhamento com os objetivos da empresa ou do programa.
Mitigação: Scrum Master e PO devem identificar os stakeholders e montar um plano de comunicação, incluindo gerentes do programa e gerentes de desenvolvimento para que todos estejam cientes do plano de releases.
Desafio: Itens não entregues no sprint devido aos atrasos em dependências
Descrição: diferentemente de um ambiente local, em que os impedimentos são mais facilmente resolvidos, muitas vezes, em um cenário de desenvolvimento distribuído, temos dependências de outras equipes para a entrega, o que deve ser planejado com cuidado.
Exemplo: para a entrega de um módulo que exibe preços em um e-commerce, dependemos do time de taxas, que precisa desenvolver as regras de negócio, o que pode gerar um atraso, seja por prioridades de programas ou por gestão de stakeholders.
Efeito colateral: atraso no roadmap e baixa na autoestima do time.
Mitigação: planejamento em conjunto com os times dependentes e checkpoints regulares, acompanhando o progresso do desenvolvimento. Uma prática do SAFe é o Scrum of Scrums, em que os times se sincronizam periodicamente.
Desafio: Regras de negócio distribuídas
Descrição: em grandes empresas, existem vários níveis de testes (manuais, automatizados, testes de aceite do usuário/homologação, pós-entrega) e, muitas vezes, essas etapas estão segmentadas em diversos países.
Exemplo: domínio da aplicação não é concentrado, alguns times trabalham com front-end em uma região, outros com back-end ou configurações em outro fuso horário.
Efeito colateral: confusão sobre as regras de negócio e atrasos, pois a informação talvez esteja disponível somente no próximo dia. Lembrando que um dia de atraso equivale a 10% em um sprint de 2 semanas.
Mitigação: análise das dependências e requisitos pelo Product Owner com antecedência. O ideal é trabalhar de forma mais proativa do que reativa.
