SCRUM: Como encontrei a felicidade gerenciando prazos

Eu como desenvolvedor nunca tive real interesse em gerência de projetos, o que fatalmente resultava em projetos de qualidade duvidosa e fora de prazo. Devo confidenciar que até hoje não tenho interesse no modelo “tradicional” de gerenciar projetos de software, mas a preocupação com a qualidade, prazos e escopo acabou por fazer parte do meu cotidiano quando abri minha própria empresa de desenvolvimento.

Startups geralmente são compostas por equipes pequenas, e estas devem ser multidisciplinares. Acredito que o “desenvolvedor web” atualmente é mais do que aquele “feijão com arroz” do início dos anos 2000. Hoje temos a obrigação de saber o mínimo possível de cada área de conhecimento que envolve o desenvolvimento de software: desde design de interfaces à modelagem de entidades e relacionamentos em um banco de dados (ou seja, verdadeiros Engenheiros de Software).

Um dia eu disse “chega” ao caos, e decidi que meus projetos de agora em diante deveriam possuir prazos bem definidos e acima de tudo qualidade. O meu primeiro passo foi procurar ferramentas, e esse foi o meu maior erro. Não se trata de ferramentas ou processos… trata-se de pessoas e atitude!

Eu me sinto na obrigação de falar sobre Scrum antes mesmo de falar sobre camadas de desenvolvimento web, ambientes de desenvolvimento Python / Django, ou sobre testes automatizados.

Trata-se de pessoas…

Se você não sabe o que é Scrum, recomendo:

1. Primeiramente assitir ao vídeo “Scrum under 10 minutes“;
2. Após esta divertida introdução, ver Scrum no mundo real assistindo ao depoimento sobre como ele é usado na Globo.com;
3. Por fim, recomendo ler o e-book “Scrum e XP direto das trincheiras” (sem dúvida a minha refência favorita sobre Scrum).

Posso afirmar que o grande lance do Scrum é aproximar as pessoas envolvidas em um projeto removendo o que não importa. É tirá-las de baias, fazê-las pararem de ficar enviando e-mails umas para as outras, botar estas pessoas numa sala e fazer com que se conversem como seres humanos normais.

Particularmente, detesto o face-to-face. Mas me aproximar do cliente foi uma experiência muito agradável que só me trouxe benefícios. Agora eu sabia exatamente qual era a necessidade dele. O Scrum me possibilitou isso removendo pilhas de documentos e processos do caminho, mostrando que para você entender qual é o problema do cliente é necessário comunicação.

Foco garante agilidade

Sabendo exatamente qual era a necessidade do cliente, foi possível determinar o que era mais importante para o mesmo. O modelo de desenvolvimento iterativo permite que os desenvolvedores de software possam entregar pequenas partes usáveis de seu sistema para o cliente. Através de pequenas tarefas priorizadas pelo próprio, podemos gerar valor mesmo durante o processo de desenvolvimento (ao contrário do modelo cascata onde a aplicação só irá gerar valor ao término do desenvolvimento).

O modelo de pequenas entregas trouxe algumas vantagens para o meu ambiente de trabalho:

• Escopo bem definido: Nos preocupávamos com pequenos grupos de funcionalidades por vez, garantindo um foco no que realmente importava ao cliente naquela etapa de desenvolvimento do projeto. Com as propostas do Scrum para gerência de estórias, o conhecimento era sempre explícito (ou seja, todos da equipe sabem exatamente o que deve ser feito);
• Flexibilidade: Em um pequeno projeto, percebi que a maneira determinada inicialmente para resolver um problema específico era ineficaz. O modelo iterativo me permitiu mudar o andamento do desenvolvimento (através da utilização do Backlog e de Sprint Plannings);
• Qualidade acima de tudo: Com os feedbacks rápidos foi possível captar o sentimento do cliente em relação ao projeto. Com ele próximo a equipe fica muito mais fácil negociar escopo e garantir qualidade. Já li em alguns lugares que muitas vezes o fim do prazo do projeto não fora atingido mas o cliente já estava totalmente feliz com a solução… na verdade o cliente só vai saber o que quer quando mostrarmos algo a ele.

Conhecendo o escopo, tendo uma equipe “sincronizada”, tendo o poder de negociar escopo e coletando feedbacks rápidos do cliente; além de qualidade ganhamos o que falta no modelo tradicional de desenvolvimento de software: agilidade. Esta me permitiu entregar o escopo prometido (e negociado durante o desenvolvimento) dentro do prazo prometido (que influenciou diretamente na negociação do escopo) sem denegrir qualidade.

O cliente ganha, o desenvolvedor ganha e as famílias dos desenvolvedores também ganham =D

Considerações finais

Se você achou o Scrum burocrático demais para a sua empresa (garanto que terão pessoas que o acharão), recomendo a leitura do e-Book “Getting Real” do pessoal da 37 Signals. Já para aqueles que acharam o Scrum “anárquico” demais, recomendo conhecer a eXtreme Programming (este artigo da ImproveIT está sensacional!).

Não acho o agile uma solução ”bala de prata”. Acredito que os processos devam ser moldados de acordo com a realidade de cada instituição. Mas tenha em mente, este conceito de “fábrica de Software” já perdeu muito do seu prestígio, e hoje quase virou sinônimo de “projetos atrasados”.

Para mim funcionou muito bem, mesmo depois de fechar a minha empresa (não foi culpa do Scrum (: ) e aplicar estes conceitos em meus projetos freelancer.