A cada dia, a utilização da metodologia Scrum tem crescido na comunidade de desenvolvimento de software. Mesmo que alguns tenham críticas a algum ponto do Scrum, é quase consenso de que ele proporciona excelentes ganhos. Para empresas e equipes que trabalham exclusivamente no esquema de projetos, a metodologia pode ser aplicada naturalmente. Problemas e dúvidas surgem quando se quer implantá-la em equipes de desenvolvimento de software que realizam atividades paralelas, como por exemplo atendimento à usuários e suporte técnico.
Uma das principais características do Scrum é definir a "quantidade" de coisas (backlog) que poderá ser feita pela equipe dentro de um determinado período de tempo (Sprint). Mas de que forma esta equipe poderá definir com quanto poderá se comprometer se não sabe quanto tempo poderá se dedicar ao projeto?
Uma das saídas seria determinar um percentual do tempo que será dedicado exclusivamente ao projeto, baseando-se em algum tipo de métrica histórica. Alguém então poderia dizer: "Bem, podemos considerar que nossa dedicação exclusiva será de 50%, ou seja, 4 horas por dia. Perfeito, podemos começar".
Mas ... o que acontecerá no dia em que não houver nenhuma atividade, nenhuma interrupção causada por fatores externos ao projeto? Os desenvolvedores ficarão metade do dia à toa? Claro que não ... irão trabalhar no projeto, naturalmente. Aí temos um novo problema: no Scrum é importantíssimo que com o tempo o time consiga ter uma boa noção de quanto trabalho (quantidade de pontos) consegue realizar durante um Sprint. Se o tempo de trabalho dedicado ao projeto variar a cada Sprint, essa métrica não será confiável, tornando praticamente impossível fazer um planejamento de duração total dos projetos.
Tenho lido bastante coisa sobre Scrum e não encontrei ninguém falando sobre esta situação. Os livros e sites falam de Scrum apenas para a realidade de uma fábrica de software ou departamentos exclusivamente dedicados a projetos. Como minha experiência com Scrum se resume também a cenários como estes, não tenho experiência prática para dar uma solução mágica. Penso, entretanto, em uma alternativa que considero viável.
No início de um Sprint, a equipe se compromete com o P.O. (Product Owner, aquele que define o que tem que ser feito) a entregar determinadas funcionalidades ao fim do prazo determinado. Em situações em que a equipe não tem dedicação exclusiva a projetos, entendo que deverá haver uma flexibilidade muito grande do P.O. em aceitar uma negociação com o Scrum Master no sentido de cancelar ou adicionar estórias no decorrer do Sprint. Se o time está conseguindo se dedicar menos que imaginava, negocia a retirada de algumas estórias do Sprint. Por outro lado, se estiver tendo mais tempo, pode puxar estórias novas. Para que isso funcione, além de um excelente relacionamento entre P.O. e Scrum Master, é necessário que o primeiro mantenha o backlog muito bem priorizado e com o mínimo de dependências possível, de forma a ser possível ter a flexibilidade mencionada.
Fazendo desta forma, acredito que a equipe consiga ter um primeiro contato com o SCrum. Com o tempo, será possível adaptar-se ainda mais à cada realidade, conseguindo dimensionar de uma maneira mais exata com quantos pontos poderá se comprometer, diminuindo cada vez mais a necessidade de ficar negociando entrada ou saída de estórias no decorrer do Sprint.
Nenhum comentário:
Postar um comentário