Scrum (Parte 2): Preceitos

Scrum – Preceitos

- Indivíduos e interações são mais importantes que processos e ferramentas.

- Software funcionando é mais importante do que documentação pesada.

- A colaboração com o cliente deve sobressair em relação à negociação do contrato. Isto é uma via de mão dupla, mas se o cliente percebe o nosso interesse no projeto, a parceria tende a ocorrer naturalmente.

- Responder a uma mudança é muito mais importante que seguir o plano. O Scrum, por ser adaptativo, acolhe mudanças. A equipe trabalha para produzir aquilo que traz valor ao negócio. Se uma regra do negócio mudar, o Scrum acolhe as mudanças e as implementam. O Scrum não tem dó nem piedade de jogar um projeto fora se o barco estiver rumando em um sentido oposto. Mas isso se aplica melhor a um ambiente organizacional interno. Em empresas que prestam serviços para outras empresas, a negociação terá de ser feita de forma mais abrangente, pois envolve contrato e custo.

- É colaborativo na sua essência e ideal para projetos de desenvolvimento de software em um cenário onde os requisitos mudam constantemente.

- Não fala sobre muitas disciplinas que o RUP e o XP implementam, mas não impede e estimula que adaptemos estas disciplinas. É mais focado na gestão do processo, enquanto o RUP e o XP são mais focados nas questões de engenharia.

- Cada composição de processos de engenharia deve ocorrer de acordo com cada contexto organizacional. Não se podem engessar as questões de engenharia de software. Por exemplo, escolher Scrum como processo e não atentar às lacunas que ele deixa.

- O Scrum aceita mudanças e não condena erros. Erros de cronograma, por exemplo: ao invés de apresentar o incremento com 10 estórias estimadas implementadas, apresenta o produto com 6 estórias implementadas. As outras 4, joga para o próximo sprint. Assim, a velociadade da equipe vai sendo ajustada de sprint em sprint até chegar a uma estimativa próxima do ideal.

- Comunicação melhorada, comprometimento, verdade e transparência.

- Times auto-organizados: o time é auto-organizado dentro dos limites delegados pelo Scrum Master, que é o guardião do processo. Quanto mais tempo um time está junto, mais conhecimento um do outro há e, portanto, melhor será a produtividade e a qualidade do projeto.

- Produto progride em sprints de 15 dias cada.

- Rever os problemas e levantar as lições aprendidas para melhoria constante do processo.

- Software funcionando, sempre como entrega. Ao final de cada sprint, o time deve apresentar um release, que deve ser um potencial entregável. Isto faz com que o cliente já tenha os subsistemas do software em produção e trazendo ROI (retorno ao investimento) a cada sprint de 3 semanas, o que é muito mais produtivo e lucrativo do que esperar meses ou anos para o projeto como um todo ser concluído.