4
respostas

O Método Ágil não substitui o planejamento - faz parte dele...

Vejo no fórum muitas duvidas que seguem o mesmo caminho... como se adotar metodologia ágil fosse ignorar tudo que conhecemos sobre planejamento, viabilidade, riscos e custo.

Só que essas coisas continuam existindo, não se pode criar um produto do nada sem descobrir seu custo, sua rentabilidade, se ele é viável. Não existe ágil sem planejamento prévio. A diferença é que ele faz parte do planejamento.

Eu vejo a aplicação da metodologia ágil como uma ETAPA de um plano maior (que pode até ser feito em waterfall), mas voltado fase de execução/desenvolvimento, onde o caos se instaura. Ao invés de prever contingencias (de prazo e custo) pra mitigar riscos, como aconteceria num modelo cascata, o Ágil "abraça" o risco de mudança, sem comprometer todo o orçamento numa unica entrega.

As palavras não são minhas, são da minha chefe, mas achei muito coerentes: " a magica do ser Ágil está em justamente poder "esquecer" itens que não são tão relevantes na primeira analise para o objetivo e ajustar conforme as coisas vão acontecendo "

4 respostas

Acho que isso tem mais relação com o nível de maturidade de uma corporação com o Ágil. Se uma corporação não tem a cultura Ágil acabará por utilizar o Ágil como uma etapa do desenvolvimento do projeto e não como parte do seu DNA. O Jeff Sutherland fala um pouco sobre isso no livro Scrum. A Arte de Fazer o Dobro do Trabalho na Metade do Tempo, o planejamento de um projeto realmente Ágil. Sempre vamos ter o planejamento, afinal ninguém está por ai rasgando dinheiro na rua, mas esse planejamento é baseado em roadmap, releases, Scrum escalado, etc. Eu tenho um budget, mas ele vai ser utilizado de forma que terá valor máximo. Em alguns casos ele nem é utilizado totalmente, ou é economizado ou destinado a features que não estavam relacionada no início.

Entendi seu ponto, Ronaldo.

Acredito que a dificuldade de entendimento que vi em parte das duvidas - e que também eram as minhas - era que a forma como o material foi apresentado PODE CAUSAR essa sensação , que o "fazer em pedacinhos" significa deixar de considerar o todo ... ( vide uma questão que está no forum , que achei um exemplo perfeito do que estou falando (https://cursos.alura.com.br/forum/topico-mas-em-que-area-do-terreno-vou-construir-o-quarto-83206 )

Entendo que o nosso problema agora, como aluno, é a quebra de conceito para entender a filosofia ágil - estamos acostumados a detalhar profundamente o todo no gerenciamento, ao invés de pensar em micro-gerenciamentos do todo.

Correto ?

O exemplo é muito bom mesmo! Esse é um dos desafios, entender o que é o produto mínimo viável para que o cliente use. O famoso MVP (minimum viable product). Indo para produtos de software, a equipe deve estar bem ciente e deixar bem transparente as questões de débitos técnicos que determinadas decisões vão gerar. Se você tiver um terreno que tem 1.5 o tamanho de uma piscina olímpica e decidir construir uma casa que ocupe o espaço da piscina olímpica fica claro que não poderá construir mais uma piscina olímpica, no mínimo uma meia piscina olímpica. E tudo bem! Afinal isso foi alinhado o tempo todo com o cliente. Se isso fosse feito em uma metodologia tradicional o cliente no fim do projeto ia querer uma piscina, a equipe ia dizer que não dá para fazer e o cliente ficaria frustrado. Essa flexibilidade e transparência do ágil é que são a grande sacada.

Essa é a figura clássica sobre MVP

Ok... mas nesse exemplo que você deu, me apresenta outra confusão: Mesmo numa metodologia tradicional, se o produto é uma casa com piscina, aquilo que o cliente entende como "casa" e como "piscina" precisariam ser destrinchados e acordados para atender a suas expectativas.

Entendo que no método tradicional, se o cliente mudar sua necessidade e quiser uma casa menor pra ter uma piscina maior, ai temos um problema - o que não ocorre na metodologia Ágil , ele sabe que vai ter no final uma casa e uma piscina.

A minha confusão se baseia em: esse "briefing", esse esclarecimento de expectativas do cliente , na área de software não consegue ficar tão claro, ou a velocidade das mudanças é tão caótica que bagunça também essa concepção de produto do cliente ?