Olá,
o post de hoje é um pouco diferente do convencional. Ainda na onda do Agile, resolvi tentar sumarizar a visão que nós (pessoas que trabalham com Scrum) temos sobre desenvolvimento ágil. Já adianto que não vim com uma resposta única e absoluta, mas com opiniões que servem para esclarecer a visão que temos sobre o conceito de agilidade.
Mas como? Bem, durante dois dias eu tirei entre 5 e 10 minutos para um bate papo informal com amigos da GPE sobre agilidade. Elaborei um roteiro para me apoiar nessa conversa e minha ideia era tentar capturar a visão geral que cada um tem a respeito de agilidade.
Então vamos lá!
Ao questionar sobre o que seria agilidade, ouvi opiniões que envolviam a capacidade da equipe se auto-organizar; a resposta rápida a mudanças; não perder tempo com retrabalho; e entrega contínua.
A auto-organização da equipe defende a ausência da figura do gerente definindo o quê e como fazer, confiando essas decisões ao conjunto.
Os outros conceitos estão muito ligados, pois a entrega contínua, com releases curtos permite que o cliente veja a evolução do produto e mostre antecipadamente o que precisa ser corrigido. Com isso a equipe estará respondendo rapidamente à mudança e evitando o retrabalho.
Dentre os principais benefícios que a agilidade traz, se destacam a proximidade com o cliente; o planejamento no início de cada iteração; e a transparência.
O primeiro benefício está ligado com a satisfação do cliente, que tem a possibilidade de acompanhar a evolução incremental do software a cada iteração. O segundo demonstra que a equipe de desenvolvimento se sente confortável para realizar seu trabalho ao ter bem definido os itens que devem ser desenvolvidos até o final da Sprint. E o terceiro destaca que os aspectos significativos do processo devem estar visíveis aos envolvidos.
Nenhum dos amigos com quem eu conversei gostaria de voltar a trabalhar sem agilidade ou alguma prática ágil. Da mesma forma, também não gostariam de ter um gerente de projeto, com exceção de uma única resposta que disse sentir falta do papel de um líder na equipe. Um líder possui perfil, características e responsabilidades bem diferentes de um gerente, mas esse não é papo de hoje. Acompanhe nosso blog que semana que vem teremos um post sobre esse assunto! 🙂
Durante a conversa também procurei identificar pontos negativos, ou que poderiam melhorar. Um ponto que surgiu foi a documentação. Esse ponto pode ser encarado de maneiras diferentes, dependendo da característica e tamanho do projeto. Pode ser que para um projeto pequeno uma documentação igualmente pequena, ou inexistente, seja suficiente. Mas pode ser que existam regras de negócios complexas que exigem essa documentação. Acredito que esse ponto pode ser resolvido incluindo algumas tarefas de documentação na definição de história preparada. Para saber mais sobre documentação no Scrum recomendo esse post do Igor Araújo: A importância da documentação.
Observei um outro ponto que pode ser melhorado, a quantidade elevada de reuniões a cada iteração: Revisão, Planning 1, Retrospectiva, Planning 2. Essas reuniões, existentes no Scrum, tem cada uma sua finalidade e podem ser adaptadas de acordo com cada projeto, afinal Scrum é uma constante adaptação! No projeto em que trabalho, houve um tempo em que nosso Planning 2 estava sendo muito improdutivo. Decidimos mudar, dando uma atenção maior ao Planning 1, e passamos a escrever a descrição das histórias de forma tão detalhada que naquele momento a maior parte do Planning 2 já está sendo feita. Isso melhorou o planejamento de nossas histórias e fez com que o nosso Planning 2 passasse a ser muito mais curto.
Bem, chegamos ao fim do post e para finalizar procurei resumir os pontos que se destacaram na imagem a seguir.
Um abraço e até a próxima!
