Gestão > Estratégia, Gestão de Projetos

CPBR 2018: 5 ações essenciais para adoção da metodologia Agile

Para especialista, mudança de mindset é principal desafio para transformação ágil

02 de Fevereiro de 2018 - 18h16

Pense no seguinte processo: o usuário descreve as especificações de software que deseja para um projeto, entrega para a equipe de projetos, que, por meio do PMO (Project Management Office), repassa os requisitos em uma documentação para a equipe de desenvolvimento. O design do produto ou solução é realizado, e quando o projeto retorna ao usuário que solicitou, o pedido muitas vezes já está ultrapassado.

O processo geralmente é longo, basicamente o que define o Modelo Cascata (Waterfall). Com esse método, o desenvolvimento de software é feito de forma sequencial (como uma cascata) por meio das fases de análise de requisitos, projeto, implementação, testes (validação), integração, e manutenção de software. Criado na década de 70 e ainda muito utilizado, ele pode estar com os dias contados.

Pelo menos se depender de profissionais como Natasha Ribeiro, gestora de projetos de big data, analytics na área de marketing digital. A especialista é contra o modelo, que, para ela, tem escopo completamente fechado, com planejamentos individuais e com pouca comunicação entre equipes envolvidas no processo.

"Quanto desperdício não é causado porque as pessoas não conseguem definir o que precisam fazer. Ou porque alguém não definiu bem o que precisa. O correto é descobrir as necessidades conforme for fazendo, ou perderá tempo e dinheiro e, mais do que isso, é desperdício de vida", comentou, durante participação na Campus Party, evento de tecnologia realizado nesta semana em São Paulo.

O grande desafio, segundo Natasha, é lidar com desperdício de tempo e falta de contexto dos projetos. Por isso, ela defende a metodologia Agile, em busca de processos ágeis para organizações.

"No Agile, você define custo e prazo. Enquanto adapta-se o escopo de acordo com o que se aprende, é definido o que terá valor, com uma lista de prioridades. Durante cada ciclo, os profissionais entendem quais são as verdadeiras necessidades, que muitas vezes não estavam descritas no início do projeto. E um processo sempre com pessoas, que é com quem lidamos, sejam desenvolvedores, usuários ou gerentes."

Ciclos

O processo é cíclico. O primeiro ponto é descobrir o que é preciso para validar uma hipótese. Com o ciclo de desenvolver, testar e descobrir, são diversos sprints - ou testes -, com diferentes entregas de valor. E sem necessariamente um projeto no longo prazo.

"O Waterfall não atende o time-to-market de hoje, principalmente no mercado de tecnologia, que muda muito rápido. Agile deveria ser assunto desde a década de 80. Ainda usamos métodos da Segunda Guerra Mundial e que nunca funcionaram. Dizem que é utopia, mas Agile é um processo viável. Funciona na Nasa, FBI, Nubank, Google e outras empresas, como IBM e Microsoft, também estão no processo de transformação ágil", destacou.

Mas o que é preciso fazer para mudar e implementar uma cultura ágil nos projetos? Natasha indica cinco pontos:

1. Envolver todas as partes interessadas

"Usuários, desenvolvedores, stakeholders e outros profissionais fazem parte do projeto. Todos precisam saber quais dados precisam ser entregues. Quando é a próxima entrega? Surgiu um bloqueio no ciclo de desenvolvimento? O usuário, o stakeholder e todos os envolvidos precisam saber. Todos precisam estar envolvidos."

2. Contextualizar a resolver o problema

"Quantos desenvolvedores atualmente entendem o contexto da solicitação do usuário? Normalmente o desenvolvedor recebe um documento com uma série de itens que ele não entende. Ok, ele faz a entrega, mas o usuário não pediu aquilo. Eles não estão juntos no dia a dia. É preciso contextualizar para todo mundo e ser multidisciplinar."

3. Resolver um problema de cada vez

"Soa utópico, mas é possível. A partir de cada dor, o que podemos pensar como solução para deixar de ser uma dor? Com uma lista de atividades, definir o que é prioridade e definir ponto a ponto."

4. Definir quais são os requisitos mínimos que vão entregar valor naquele momento

"Você tem um produto mínimo que resolve o primeiro problema definido na sua hipótese validada? Ok, qual é o próximo? Caso seja invalidada, volta e define antes de ir para o próximo."

5. Planeje-se de forma realista

"Não adianta querer abraçar o mundo. Prometa apenas o que sua equipe é capaz, o que pode de fato entregar. Não iluda o usuário."