Sabemos que utilizar e acompanhar um desenvolvimento de software numa metodologia é extremamente importante para o sucesso do projeto. Melhor ainda é quando vemos que tudo está caminhando conforme o planejado, isso acontece principalmente no início do projeto.

Porém, este "mar de rosas" raramente é o tal "felizes para sempre" dentro do ciclo de vida do projeto. As opiniões mudam, a visão sobre o negócio muda, os stakeholders dificilmente concordam/aceitam o que lhes são apresentados, e, em consequência disso, os requisitos também mudam, tudo muda. Sem falar nos casos em que várias pessoas dentro da organização opinam (de forma diferente até sobre a mesma visão) sobre o produto, deixando a equipe do projeto de cabelos em pé!

A partir desta situação, começa então gerar o caos dentro do processo que antes parecia tão "organizado" e alinhado ao projeto e que agora se tornou um pesadelo gerenciar as estimativas, cronograma que não pode estourar, custos, replanejamento, recursos humanos, etc.

Normal, não? Porém, as metodologias tradicionais podem não ter o suporte necessário para o "gerenciamento" dessas mudanças. Isto ocorre devido às burocracias que fazem parte deste contexto, em que na maioria das vezes, dão ênfase a tantos artefatos e deixam de lado a parte mais importante, o porquê de sua existência, o produto em si.

Onde está o socorro?

No Scrum!

O manifesto ágil diz que:

  • Software funcionando vem antes de documentação abrangente
  • Colaboração do cliente vem antes de negociação de contrato
  • Resposta às modificações vem antes de um plano em andamento

Ao contrário de que muitos pensam, o sinônimo de "Agilidade" não fará com que seu produto seja entregue na metade do tempo de uma metodologia tradicional, ou de um dia para o outro. Ser ágil dentro do Scrum, por exemplo, quer dizer à (não se limita):

  • Responder rapidamente a modificações e solicitações
  • Aperfeiçoar a previsibilidade
  • Controlar/limitar os riscos
  • Ser auto-organizável, sem depender de terceiros, o que pode ser dito como ser proativo, e
  • Buscar uma contínua perfeição de trabalho para entrega de produto de mais alto valor possível

Os processos ágeis valorizam as modificações (mesmo que tardia) para vantagem competitiva do cliente. Se você consegue responder rapidamente às mudanças de requisitos, provavelmente consegue retorno mais rápido, em consequência, obtém como resultado um produto de mais valor para seu cliente.

O Scrum não é um processo e sim um framework onde se pode empregar vários processos ou técnicas. Sendo assim, é possível aplicá-lo dentro de um processo já existente na sua organização, aderindo para as novas terminologias.

Como exemplo, colocar em prática os eventos Scrum. Tais eventos são projetados para garantir a previsibilidade e a transparência, de modo a criar uma rotina que garante reuniões centralizadas reduzindo a necessidade de outras e o desgaste de tempo desnecessário dentro do processo. Também, promovem a inspeção de modo que o Time Scrum avalie com frequência o progresso em rumo ao objetivo, adaptando-se (como equipe auto-organizada) sempre que necessário, o que faz com que o Scrum seja totalmente adequado para a solução dos problemas mencionados no segundo parágrafo.

O Scrum é leve e por isso não é preciso abandonar um processo já em uso, basta fazer uma adaptação abrindo mão da tal "da cultura". Essa mudança diz respeito à (o que não se limita):

  • Mais cooperação por parte de todos envolvidos e menos formalismo
  • Proatvidade da Equipe de Desenvolvimento e autorização para gerenciar seu próprio trabalho
  • Apoio e contato direto da participação do stakeholder de forma centralizada e representada por um único integrante na pessoa do Product Owner

Seu processo atual não está dando conta do recado? Que tal transformar cada porção do tradicional modelo de "Ciclo de vida" numa Sprint?

Você pode "inventar" o Scrum de várias formas, aplicando os papéis, eventos, artefatos e regras do mesmo, enriquecendo seu processo tradicional com a eficácia das práticas Scrum.

Ser Scrum é desprender-se das coisas que engessam o processo e valorizar os pontos positivos de forma que eles evoluam cada vez mais.

É criar e conduzir de forma produtiva o trabalho necessário para construção do produto.
 


Sobre o autor desse post: Rafael Amaral, há 6 anos trabalhando com desenvolvimento web em Juiz de Fora, Professional Scrum Master I certificado pela Scrum.org, desenvolvendo sites, sistemas e soluções para o seu negócio através da plataforma web.