Scrum nos Projetos

Olá Marcelo,

dentro dos times de desenvolvimento da Caelum e Alura nós já usamos muito o Scrum "de caixinha" nos nossos projetos. Por ser um framework bem definido, ele indica o que os times podem fazer para ter um desenvolvimento seguindo a cultura da agilidade, mesmo que estes ainda não tenham muita maturidade no assunto.

Só que não usamos o Scrum puro para sempre também, com o passar do tempo nós vamos adaptando o processo de acordo com o contexto de cada time. As vezes, até mesmo pegando inspiração em outros frameworks e modelos, como o XP, Kanban, etc. Tem que sempre lembrar de dois valores fundamentais da agilidade: indivíduos e interações mais que processos e ferramentas, responder a mudanças mais que seguir um plano.

Quanto a alteração de custo e prazo, isso já entra numa categoria acima do Scrum. Quem discute mais isso é a comunidade ágil como um todo. Antigamente os contratos de desenvolvimento envolviam 3 variáveis mais fixas: custo, prazo e escopo. Mas havia uma 4 variável que é a qualidade. O problema é que em geral, quando o cliente queria alterar um dos 3 pontos fixos, em geral quem era afetado era a qualidade do projeto. Por exemplo, se o cliente decide aumentar o escopo, havia uma redução da qualidade do software para entregar na mesma data e no mesmo prazo. Só que a queda na qualidade em geral acabava virando um problema no futuro, com o aumento do número de bugs, crescimento no custo de manutenção, etc.

Já nos contratos que seguem os princípios da agilidade, a ideia é que os 3 pontos mais fixos tendem a ser a qualidade, o prazo e o custo. Mas como você comentou, problemas surgem e pode sim acontecer de ter que redimensionar eventualmente o prazo e o custo de acordo com as necessidades do cliente, só que isso impacta no escopo do projeto. Entregar software de qualidade é o único que tende a ser inegociável. Então se por exemplo teve uma redução do orçamento e o cliente decide redimensionar o custo do projeto, ele precisa decidir o que vai retirar do escopo para entregar no mesmo prazo e com mesma qualidade.

Para deixar até mesmo o contrato mais interessante e flexível tanto para o cliente quanto para o time de desenvolvimento, uma coisa que a Caelum fez por muito tempo foram contratos ágeis mensais. Então o prazo do contrato era de 1 mês e se definia um custo e escopo do projeto para este período. No final deste prazo, havia uma cláusula no contrato que permitia o cliente renovar o contrato para mais 1 mês, com um novo custo e escopo para o próximo período de contrato. Mas se o cliente não estivesse gostando do trabalho que estava sendo desenvolvido, ao final deste período curto o contrato se encerrava e ele não renovava. Um detalhe interessante deste contrato é que o time de desenvolvimento poderia também cancelar o contrato caso o cliente não estivesse cumprindo com o que ele se comprometeu, de estar sempre presente, dando feedbacks das funcionalidades para o time, participando das reuniões, etc.

Obrigado mais uma vez, Lucas, por se prestar a escrever uma (grande) resposta.

Se eu entendi bem, funciona assim na Caelum / Alura : vocês assinam junto ao cliente um contrato (e isto é realmente uma coisa cultural que dificilmente irá mudar) e conduzem o projeto usando Scrum.

Porém, como qualquer projeto do mundo real, pode haver mudança de escopo (diminuição ou, provavelmente, aumento) e ai é que o Scrum não quebra pois o que é feito por vocês em cada sprint é definido na cerimônia de planejamento. Logo vocês procuram fazer "um pouco de cada vez". O aumento de escopo não influenciaria em nada.

Estou correto ?