Scrum e o ciclo do PDCA

Ciclo do PDCA

Ciclo do PDCA

Discutindo com o Cláudio Kerber via twitter hoje, falamos sobre como alguns administradores insistem em planejar, planejar, planejar tudo nos mínimos detalhes antes de executar. Muitos pregam inclusive que é possível planejar com exatidão antes de agir, sendo possível prever tudo o que ocorrerá no decorrer do projeto. Pois bem, sabemos que essa premissa não é verdadeira não é mesmo?

Em desenvolvimento de softwares é fato que não é possível prever todas as variáveis que existem, uma vez que o negócio pode mudar, o cliente pode ter que reagir a algum estímulo do mercado para tirar vantagem competitiva e por ai vai.

O ciclo do PDCA(Plain, Do, Check, Act), ciclo de Shewhart ou ciclo de Deming, é um ciclo de desenvolvimento que tem foco na melhoria contínua. Até aí nenhuma novidade, pois bem, o Scrum evidencia essa melhoria contínua do processo, da seguinte forma:

Plain: No Scrum planejamos o tempo todo, temos uma reunião própria para estabelecermos uma meta e um plano para atingir essa meta durante a iteração, ou Sprint, como é conhecida no Scrum. Nesse momento analisamos quais são as atividades que farão parte do escopo inicial da Sprint, isso mesmo, inicial, porque isso pode mudar o tempo todo, conforme seja necessário para alcançarmos nossa meta.

Do: É quando realizamos o trabalho que assumimos que é possível realizar durante o tempo determinado, que no Scrum não pode passar de um mês.

Check: Talvez daqui para frente estejam as maiores diferenças do Ciclo do PDCA tradicional(chamei assim para diferenciar do Scrum). No Scrum temos uma reunião diária de 15 minutos para verificar o andamento do projeto, quais impedimentos temos para atingir a nossa meta. É aqui que diferimos muito do PDCA tradicional, pois diferente de lá, se percebemos um desvio, podemos ajustar na mesma hora, não esperando para o final da Sprint para fazê-lo, isso nos torna ágeis na tomada de decisão, até mesmo no ajuste a mudança de direção do produto, mercado, etc. Temos também um momento para avaliar o resultado do que foi realizado na Sprint que é a Sprint Review, onde o trabalho é inspecionado e avaliado o resultado. A partir daí é reajustado o Product Backlog para que seja iniciado um novo ciclo.

Act: Após a Sprint Review é realizada uma reunião para melhoria do processo, chamada de Sprint Retrospective, onde analisamos o que funcionou, o que pode melhorar no processo e determinamos quais ações serão realizadas para que o processo melhore efetivamente.

Diferentemente do processo de desenvolvimento tradicional, estamos sempre planejando, inspecionando, adaptando e agindo. No processo tradicional de desenvolvimento de softwares, chamado Waterfall ou também Cascata, assume-se que toda a análise pode ser feita no início do projeto, abrangendo todos os cenários possíveis e que nada irá mudar. Nós no Scrum somos mais realistas e assumimos que tudo pode mudar e o tempo todo, nós acolhemos a mudança, mesmo que tardia, vide os princípios do manifesto ágil.Também não esperamos o final do projeto para entregar para o cliente o software, isso é feito já no final de cada Sprint, para que o cliente possa avaliar se o sistema está no caminho correto, simples assim.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s