Olá amigos,
Tenho me deparado com muitas pessoas me perguntando: “Mas Vitor, o que significa ser ágil em projetos?” e com algumas definições, tais como:
“Ser ágil é correr para fazer entregas rápidas, focando nas equipes autogerenciáveis”.
Em primeiro lugar, quem acompanha meus artigos ou mesmo minhas palestras e workshops, sabe que tenho verdadeiro horror à palavra autogerenciável (entenda mais meu ponto de vista sobre o assunto neste artigo).
Em segundo lugar, correr para fazer algo resulta quase sempre nas imagens abaixo:
Outra definição distorcida: “Ser ágil é trabalhar sem planejamento e sem cronograma visando sempre entregar o máximo de valor ao cliente”. Projeto sem cronograma? Sem estimativa de prazo? Como assim? O orçamento do projeto também dura pra sempre? Explique-me melhor?
Uma definição melhor poderia ser:
“Ser ágil é gerar entregas contínuas, incrementais e frequentes de valor para o cliente, focando em equipes auto-organizadas”.
Porém acredito que exista uma etapa anterior a esta e vejo que é onde muitos falham neste sentido:
“Ser ágil significa simplificar o mindset, pensar de forma simples e objetiva. Porém não confundir pensar simples com preguiça de pensar”.
Às vezes vejo literaturas como “Scrum passo-a-passo” ou “Torne-se um Scrum Master em 24 horas” e penso que de nada adianta o embasamento teórico sem trabalhar a simplicidade do pensamento.
“Mas Vitor, como assim? Pensar simples?”
Quando pensamos no produto de um novo projeto, não devemos começar a planejar se não entendermos o básico do produto (MMF ou MVP, leia mais sobre o assunto neste artigo). Exemplo: suponha que meu projeto consiste em gerar um novo modelo de celular que concorra com o iPhone. De que adianta fazer um longo planejamento ou ter mil ideias mirabolantes se não partir pelo básico, ou seja, um aparelho que liga, desliga, faz e recebe chamadas?
Costumo chamar esse tipo de planejamento de “pensar de cima para baixo”, nome que criei para o conceito de elaboração progressiva descrito abaixo:
Então “ser ágil” na minha opinião significa:
- Simplificar o mindset
- Pensar “de cima para baixo”
- Planejar de forma interativa
- Ser receptivo à ideia de combinar as metodologias, frameworks e boas práticas existentes, sem se prender a rótulos ou radicalismos
- Entender que projetos devem possuir um gerente, porém, as pessoas precisam muito mais de um líder do que um gerente
Depois de tudo o que eu escrevi acima, aí sim vou procurar entender melhor o que é um Scrum Master, Sprints, Extreme Programming, PMBOK, etc. Pois serão as teorias que poderei aplicar partindo de um mindset “ágil” e que me ajudarão a obter melhores resultados nos meus projetos.
Abraços a todos e até o próximo artigo.
5 Comentários
Olá Vitor, na sua experiência, como é, de um modo geral, a reação das empresas (leia-se pessoas/lideranças) aos erros/falhas, já que nos métodos ágeis corremos mais riscos (ou não?) ?
abraço, Matheus
Olá Matheus,
Os riscos embora altos, são mitigados aos poucos através dos conceitos de processos empíricos (conhecimento adquirido através da experiência).
A reação das empresas acaba sendo ruim pois os métodos ágeis são utilizados da maneira incorreta. O que vejo acontecer muito, são pessoas que fazem um curso de Scrum de dois dias e já querem sair aplicando, sem se preocupar com o principal na minha opinião, que é simplificar o mindset (tema deste artigo).
Forte abraço,
Vitor Massari
Excelente explicação Vitor, muitas pessoas praticam esse tema de forma errada e acabam achando que não funciona.. muito pelo contrário, se aplicado de forma correta o ganho é gigantesco.
Abs.
Oi Vitor, então dentro desse tema, gostaria que comenta-se como elaborar um projeto/orçamento para atender uma determinada necessidade de uma empresa se o fator tempo desenvolvimento/tempo/custo estão extremamente interligados. Como ou o quanto ser ágil nesse caso?
Entendo que o desenvolvimento Ágil está relacionado com formas e procedimentos de trabalho, e não com uma data especifica de entrega de um produto. Espero ter sido claro, obrigado.
Olá Orlando,
Ser ágil em projetos com restrição de prazo (date-driven) é um desafio dos bons.
Leia minhas considerações a respeito neste artigo: http://www.profissionaisti.com.br/2014/01/projetos-o-que-e-mais-importante-atingir-o-escopo-ou-cumprir-prazo/
A real agilidade em projetos com restrição de tempo e prazo é a capacidade de determinar um escopo de funcionalidades que realmente agregam valor. Mas acredite, não é tarefa fácil. Veja o que penso a respeito neste artigo: http://www.profissionaisti.com.br/2014/01/minimum-marketable-feature-a-arte-de-pensar-simples-e-entregar-valor/
Abraços,
Vitor Massari