Visto que essa metodologia já entrou no dia a dia das empresas, e este não pode ser baixado na Internet ou tirado de dentro de uma caixinha. E tampouco resolve magicamente atrasos na entrega de projetos de tecnologia. Mas pode, sim, dar vida nova ao ciclo de desenvolvimento de software das empresas e tornar as equipes mais eficientes. Baseado em uma reorganização dos métodos de trabalho, o framework é antes de qualquer coisa, uma mudança cultural dentro das equipes. No lugar da relação hierárquica vertical, entra a parceria entre times de profissionais com especialidades complementares e chefes que têm a obrigação de se comunicar de forma padronizada. Em vez de formalidade na documentação de projetos, há reuniões diárias e rápidas. E mais, importante, o acúmulo de tarefas e dos atraso na entrega dos projetos dá lugar a uma cultura de ciclos curtos de desenvolvimento que aperfeiçoam um produto mais funcional.
Esses profissionais foram envolvidos diretamente na Gerência de Tecnologia, na Gerência de Operações Virtuais, e no acompanhamento da equipe de desenvolvimento.
Eles foram moldando um novo corpo para a gerência desse projeto.
Além das equipes de programadores, chamadas de times, outros dois papéis são atribuídos aos profissionais: O Scrum Master e o Owner. O primeiro é o chefe-servil, que tem como principal função remover obstáculos que podem atrapalhar o trabalho de sua equipe. É preciso acessar dados de outro departamento ? O Scrum Master tem que correr atrás da autorização, e assim por diante. O Product Owner, ou P.O. descreve meticulosamente a funções que espera ver implementadas e define as prioridades de cada uma delas.
Os períodos vem em forma de listas em que são colocadas as chamadas “histórias de usuário” para cada função. São duas ou três linhas bem resumidas com o que se espera de determinado recurso do site ou do software. É a partir desses dados que são feitos os backloags dos produtos, com a documentação sobre o que deve ser feito, o que já foi e o que fica para depois.



Reunião sem cadeira
Com essa estrutura, o trabalho começa a ser executado de forma modular. Planejamento, execução e revisão de feitos diariamente por meio de reuniões rápidas de 15 minutos que definem quais tarefas serão desenvolvidas no dia. Para garantir a rapidez, os encontros são feitos com os membros do time em pé. Sem espaço para enrolação.

No Scrum, cada profissional desempenha um papel, não é preso a um cargo. Aquele esteriótipo do programador introspectivo não se encaixa mais nesse cenário. È preciso ter liderança, ser multifuncional e assumir compromisso com a equipe. Dessa forma, as reuniões (também chamadas de cerimônias) servem como um preciso termômetro para o desempenho das equipes envolvidas e definem com precisão os prazos para a entrega de cada etapa de um projeto. Nessas reuniões não há uma hierarquia fixa definida. Nos manuais de boas práticas do Scrum existe até a figura nada elogiosa do “Gorila da sala”, usada para descrever o membro que não deixa que os outros membros falem.

Tarefas do Sprint
Cada conjunto de tarefas é colocado dentro de um sprint, ou seja, um período predeterminado, que varia entre três e trinta dias, em que é preciso chegar a resultado. Geralmente cada sprint tem 15 dias e, durante esse tempo, são implementadas funcionalidades ao produto – como um novo menu de categorias para um site ou uma nova função para o buscador.

Outra técnica interessante é a medição de dificuldade de cada tarefa, que pode ser feita de maneira lúdica, usando fichas de pocker. O membro do time que realiza a parte mais penosa do trabalho, por exemplo, ganha pontos e pode medir mais prazo do que outro que realiza uma tarefa relativamente mais simples. O acompanhamento diário evita atrasos e dá noção real do tempo e da força de trabalho necessária para realizar cada projeto. Assim, os times são autorregulados e podem mudar a direção do trabalho rapidamente, algo bastante exigido no desenvolvimento de produtos e serviços baseados em Web.

Com o Scrum os líderes de cada equipe definem estratégias e trocam informações sobre seus projetos, evitando tarefas redundantes ou desperdício da força de trabalho. Outra prática comum é restringir times de desenvolvimento em, no máximo, 12 profissionais.

Dentro desse cenário, não bastam apenas profissionais certificados, é preciso comprometimento e de uma revisão dos processos para que a cultura antiga da empresa não contamine as práticas do Scrum.

O Scrum Master é um grande conhecedor de processos, ele precisa de liderança e boa comunicação. São habilidades mais ligadas às ciências humanas do que às exatas.

http://info.abril.com.br/noticias/carreira/pronto-para-o-scrum-15092009-14.shl?2