Quem está acostumado, sabe como a maioria dos projetos de software pode ser frustrante. Prazos de entrega são raramente cumpridos, a qualidade do software nem sempre é ideal e há horas e horas de trabalho extra, frustrações e pressão o tempo todo em todos os níves do projeto: diretoria, gerentes de projeto, clientes, desenvolvedores.
Ao final de um projeto, com sucesso ou não, várias baixas aconteceram e os que restaram têm cicatrizes que vão durar um bom tempo. Não tenho estatísticas do sucesso em projetos de software no Brasil, mas tenho certeza que a taxa de mortalidade é altíssima. De vários projetos que trabalhei, os poucos que foram para produção eram em sua maioria mutações do que havia sido planejado.
Grande parte do problema nestes projetos está relacionado a falsas expectativas e, sinceramente, a hipocrisia, conseqüência dos modelos tradicionais de projeto de software.
Fazendo uma super simplificação, os modelos mais tradicionais de projeto de software, como Waterfall, são divididos em fases distintas: inicialmente os requisitos são levantados, o que pode durar meses. Em seguida começa-se a fase de construção, depois testes e então o projeto vai para produção.
Nas fases iniciais do projeto uma data alvo de entrega é definida às vezes baseada em bons motivos, mas comumente tirada da cabeça de um executivo. Semanas depois, com os requisitos em mão, um grupo calcula quanto tempo vai ser necessário pra terminar o projeto. A diretoria aprova o projeto, e começa-se o desenvolvimento de software.
Tudo seria perfeito se os requisitos não mudassem, se a equipe não mudasse, se a data de entrega do projeto ?calculada? não tivesse influência da gerência e diversos outros motivos.
Nas primeiras semanas do projeto temos a fase de euforia onde quase todos estão confiantes no sucesso.
Semanas depois uma silenciosa transformação passa a acontecer: superficialmente todo mundo se mostra confiante, mas no fundo todos começam a ter dúvidas. O gerente de projeto sabe que os requisitos não são tão claros, mas deve passar um ar de confiança pra sua equipe.
Os desenvolvedores sabem que no fundo as estimativas foram feitas na base do achômetro. A diretoria e executivos, por experiência própria, sabe que os prazos que receberam não são confiáveis e por isso mesmo precisam manter pressão e fazer acontecer.
Resumindo, toda a equipe está insegura, mas durante um bom tempo todos se calam diante do cenário, vivendo neste ambiente fictício, como se ignorar os problemas fosse suficiente para resolvê-los.
Por volta do mesmo período o time de desenvolvimento passa a encontrar diversas incoerências nos requisitos, faltas de detalhes além de pedidos de mudança no comportamento ou regras de negócio pelo usuário/cliente. O que se segue são negociações sobre sintaxe e escopo dos casos de uso. O time de desenvolvimento e gerente de projeto pedem mais tempo (ou seja, dinheiro) para assimilar as mudanças, que do ponto de vista do cliente nem sempre são mudanças.
Em algum momento, digamos que quando o projeto alcança 70% do tempo de desenvolvimento, a gerência percebe que apenas 20% do projeto foi completado até o momento. Uma reunião é convocada para discutir o andamento e o gerente de projeto, ou alguém com mais poder faz a grande promessa: “– Não se preocupem, nós completamos 20% do projeto em 70% do tempo alocado, mas vamos com certeza conseguir terminá-lo com os 30% de tempo que ainda faltam“.
Na maioria das vezes (sinceramente não entendo como), a gerência/diretoria concorda com tal estimativa e promessa. Muitas vezes essa promessa é feita sem a participação do time de desenvolvimento (ou quando ele é convidado a dar a opinião, esta deve ser compatível com a as expectativas da gerência).
Logo após esta reunião as horas extras começam e desenvolvedores trocam de emprego. Geralmente os melhores são os primeiros a sair e a qualidade do software e do ambiente de trabalho caem consideravelmente.
Quando a gerência descobre que o prazo não vai ser cumprido, uma extensão de algumas semanas é dada ao time. E quando a gerência descobre que o novo prazo não vai ser cumprido, mais uma extensão é dada ao time.
Esse ciclo pode se repetir durante meses. O que se segue são semanas e semanas de irritação, stress, decepções para todos os envolvidos. Basicamente o projeto está sendo mantido vivo por conta de aparelhos. Todo mundo sabe que ele tem poucas chances de sobreviver, e se sobreviver será delimitado em várias áreas. Eventualmente o projeto é dado como morto.
O problema aqui não é simplesmente uma falta de comunicação aberta e sincera, mas a idéia de que é possível planejar todas as funcionalidades, regras e comportamento de um novo software de uma só vez. Pior ainda é usar este plano imperfeito como base para estimativa de custos e prazos, que por conseqüência só podem ser imperfeitos.
As metodologias ágeis como Scrum tem em seu cerne a certeza da mudança e falta de detalhes e oferecem formas de lidar com elas. Requisitos vão mudar, estimativas são apenas estimativas e para ter um projeto de sucesso é preciso assumir responsabilidade sobre estas incertezas e estar preparado para elas.
Para entender como as metodologias ágeis lidam com mudança, vale a pena rever os quatro princípios do Agile Manifesto adotados pelo Scrum.
Indivíduos e relacionamentos ao invés de processos e ferramentas
É quase desnecessário dizer que num projeto de software os indivíduos são mais importantes que ferramentas e processos. Apesar de todo mundo concordar com isso, a prática é mais rara.
As chances de sucesso em um projeto são muito maiores em times onde há uma boa comunicação, onde há entendimento e cooperação mútua.
Se o músico é bom, ele faz música com qualquer tipo de instrumento, até com latas e panelas. Um grupo de bons músicos entretanto não consegue tocar uma simples canção se não houver comunicação entre eles.
Em projetos de software é a mesma coisa. De nada adianta ter o melhor servidor de aplicações, a melhor linguagem, o melhor editor UML se o time não for de verdade um time.
Software funcionando ao invés de uma extensa documentação
Com uma versão funcional do produto, o cliente pode interagir e avaliar o sofware. Sentir como o software funciona, mesmo que seja apenas uma pitada, como um pequeno trailer do filme. O gerente de produto pode usar o software para avaliar se suas expectativas foram cumpridas e se a sua forma de comunicação com o time foi eficiente.
Do ponto de vista técnico, o time de desenvolvimento pode provar que a arquitetura e tecnologias usadas para desenvolver o produto são funcionais, sem contar com a satisfação que é ter algo concreto para mostrar ao final de cada sprint. Como numa guerra, cada sprint terminado é uma batalha vencida e uma coleção de batalhas sucedidas na maioria das vezes leva à vitória.
Ter um software funcionando ao final de cada sprint é uma das peças chaves do Scrum.
Um sprint ou interação é um intervalo geralmente de duas a quatro semanas onde o desenvolvimento de software ocorre. Algumas vantagens deste ciclo interativo são:
- O conjunto de tarefas a ser cumprido é menor, o que os torna mais fácil discutir, priorizar, entender, estimar e executar;
- O acompanhamento do andamento do projeto é simplificado e mais eficiente, já que trabalha com um número reduzido de tarefas;
- Ao final de cada sprint, o desempenho do projeto é visível para todos e pode ser facilmente comunicado para a gerência, que por sua vez tem a chance de fazer correções e tomar melhores decisões sobre o produto.
- Ao final de cada sprint, o time também tem a oportunidade de avaliar o que deu certo e errado e fazer melhorias para a próxima interação, ficando mais eficiente a cada novo ciclo.
Colaboração com o cliente ao invés de negociação de contrato
Em um projeto Scrum, o cliente é parte integral do time, trabalhando diariamente com os desenvolvedores e Scrum Master (Scrum Master é uma posição semelhante ao gerente de projetos). No projeto ideal, o Scrum Master e desenvolvedores não precisam nunca tomar uma decisão sobre uma regra de negócio, pois o cliente está sempre disponível.
O cliente está sempre envolvido, esclarecendo regras de negócio, participando da demonstração do software ao final de cada sprint, oferecendo feedback e atento às mudanças e suas conseqüências.
Reação à mudanças ao invés de seguir um plano
Como já foi enfatizado neste artigo, as mudanças são uma das poucas coisas que podemos ter como certeza no início de cada projeto. Planejamento é importante, uma metodologia ágil reconhece isso, mas o mais importante é que o time possa absorver as mudanças que tornam o produto final melhor. A cada novo sprint, o product owner tem a chance de alterar a prioridade ou adicionar novas tarefas a serem executadas durante o sprint.
Vale a pena ressaltar que o time de desenvolvimento tem total controle sobre o número de itens a serem trabalhados durante o sprint, baseados no tamanho das tarefas e duração do sprint.
É errôneo pensar que Scrum, por exemplo, não enfatiza planejamento. A diferença é que o planejamento é dividido em vários sprints. Se há a necessidade, por exemplo, de integração com um sistema legado, o planejamento de tal atividade acontece durante o sprint, onde os detalhes são levantados, a prioridade é definida e o real valor para o negócio entendido.
Se a tarefa é muito complexa, ela pode ser dividida em sub tarefas que são então alocadas em dois ou mais sprints, onde no primeiro faz-se o planejamento e no segundo acontece a execução.
Não existe metodologia perfeita, assim como não há a bala de prata – uma solução única para todos os casos. Projetos de software têm muito a ganhar com metodologias ágeis e suas práticas.
Tenho certeza que ao final deste artigo o leitor talvez tenha mais dúvidas do que tinha ao começar a ler, mas pretendo no futuro explicar um pouco melhor como Scrum pode fazer seu ambiente de desenvolvimento mais produtivo e influenciar de forma positiva na qualidade do software e sucesso de projetos. [Webinsider]
.
As opiniões expressas neste artigo são do seu autor e não refletem necessariamente a posição de seu empregador.
Handerson Ferreira Gomes
Handerson Ferreira Gomes (handerson.gomes@summa-tech.com) é consultor senior da Summa Technologies nos Estados Unidos.
11 respostas
Bia, acho interessante vc conhecer.
Marcelo,
você acertou em cheio. Uma das formas que utilizamos Scrum é para exatamente podermos oferecer uma estimativa mais acurada.
As primeiras interações (Sprints) são usadas exatamente para isso. Se faz uma estimativa de quantas tarefas serão cumpridas em um Sprint.
Para isso as tarefas são estimadas não em horas mas em pontos, basicamente complexidade.
Executa-se o Sprint e faz uma comparação entre o planejado e realizado. Se a estimativa foi de completar um total de 50 pontos, e apenas 40 foram completados, então essa passa a ser a nova velocidade do time. No segundo Sprint o time se compromete a completar 40 tarefas. Se o time completou as 40, então o time pode avaliar se essa é uma velocidade confiável ou se pode puxar para 45.
A tendência é que a velocidade se estabilize ao longo dos Sprints. Para saber o custo total de um projeto basta somar o total de pontos no projeto e dividir pela velocidade.
Num modelo como esse o cliente teria que bancar de 6 a 8 semanas de desenvolvimento para poder então ter uma idéia de qual a velocidade do time.
É importante salientar que esta estimativa é baseada na velocidade do time que não é imune à mudanças no ambiente. Membros vão tirar férias, outros vão sair do projeto ou serem deslocados para outras atividades, novos membros vão entrar. A vantagem de saber a velocidade do time é que se a equipe for reduzida, pode-se diminuir a velocidade do time e rapidamente se ter uma idéia do impacto desta mudança no tempo de desenvolvimento.
Obrigado pelo comentário Julio Cezar. Se há um contrato onde o prazo, custo e funcionalidades estão descritas e acertadas então dificilmente este vai ser um projeto Scrum.
E essa é exatamente uma das dificuldades na adoção do Scrum.
O cliente sempre quer um contrato com preço, requisitos e tempo de desenvolvimento fechado. Na grande maioria das vezes ao longo do projeto o fornecedor sente a necessidade de renegociar alguns desses items.
Infelizmente ainda há no mercado a idéia que desenvolvimento de software é manufatura, o que está longe de ser. Temos ferramentas e processos, mas desenvolvimento de software é processo criativo e portanto com grandes margens de erro.
O problema destas metodologias de desenvolvimento ágil é fazer com que os advogados as entendam. O que dizer para eles quando o prazo acabar e o que está descrito no contrato não for completamente produzido? e ainda forem necessárias 1000 horas para completar o resto do sistema??
Este e o sistema que te tinha falado.
Já li Getting Real.
É mais uma ótima referência! O difícil não é ter uma boa referência (um modelo ou metodologia), mas sim conseguir aplicá-la.
Quantas vezes ouvimos aqui estão as 10 melhores práticas em … ou os 10 erros mais comuns em …? Tenho certeza de que todos reconhecemos algo familiar em todas estas listas e há ações propostas para cada item e a resposta está em conseguir aplicar as ações: nada de novo 😉
Por exemplo, um dos principais pontos de atenção é o cuidado com o lado comportamental de sua(s) equipe(s): seres humanos são complexos e exigem estratégias ágeis e fáceis de implementar… Evitar criar ilhas na empresa; Retirar o sentimento de propriedade sob artefatos (códigos, documentos, outros ativos) – os artefatos são da empresa (ou do projeto!), mas mantendo o compromisso com os resultados. Fazer isto não é fácil e, na minha opinião, exige um grande apoio de pessoas de RH para ser implementado.
Já tinha ouvido falar muito de Scrum e nunca tinha lido muita coisa a respeito. Pelo texto, deu pra ver que é uma metodologia interessante, embora dependa do contexto da aplicação, como já disseram.
Recentemente, fiz uma matéria para a Intranet da empresa na qual eu trabalho sobre o Scrum. Utilizada, principlamente, pela área de Tecnologia, a metodologia é muito eficaz. Os objetivos são melhores definidos e as tarefas demandadas de forma mais direta, com prazos que são cumpridos quase em sua maioria. O foco, que geralmente se perde em alguns projetos, é levado a sério. Tem quem pense que não é necessário um programa como o Scrum para que as coisas andem. Para alguns, boa vontade é a palavra-chave. Mas, com certeza, os grupos que o Scrum forma faz com que o trabalho fiquei melhor dividido e aproveitado.
Leiam Getting Real.
Sou favorável ao uso do que for mais adequado a cada projeto.
As narrativas de experiências de fracassos e observações sobre outros modelos e metodologias poderiam ser explicadas por vários fatores cruciais em qualquer projeto, entre eles: gestão de mudanças ausente ou muito fraca, problemas de comunicação, falta de clareza e consenso sobre os objetivos do projeto.
Eu trabalhei em projetos adotando o modelo waterfall com sucesso e digo, com certeza, que eles tem seus momentos de glória.
Quanto a SCRUM, os conceitos não são novos. Tem sua importância e eficiência dependendo do contexto. Mas consiga aplicar o SCRUM num projeto em que há um valor fechado (a maioria dos casos) e em que o cliente não tem maturidade para entender evoluções que mais parecerão empirismo para ele!
Por favor, que fique claro que não sou contra SCRUM, apenas acredito que devemos avaliar muito cautelosamente a aplicação dele (ou de qualquer outra metodologia) sem fechar os olhos para outras alternativas.
Olá Handerson, tudo bom?
Atualmente venho lendo muitas informações referente a gerenciamento de projetos, muitas vezes citando a metodogolia Scrum.
Concordo plenamente que é impossível prever tudo e que a melhor alternativa é focar e concluir tarefas por parte, porém geralmente o cliente deseja saber o preço completo do software e prazo confíavel.
Nesta ocasião a melhor alternativa não seria mensurar valores e prazos para desenvolvimento de software de forma completa e sim por partes?
Você recomenda alguma fonte de estudo ou leituras específicas referente a metodologia SCRUM ?
Grato pela atenção …