A aplicação de metodologias ágeis em projetos de desenvolvimento de software já é uma realidade, sendo motivada, principalmente, por sua característica dinâmica, exigência de um mercado cada vez mais competitivo.
A metodologia Scrum vem sendo utilizada para o desenvolvimento de produtos complexos desde o início dos anos 90. Porém, pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessite trabalhar juntas para atingir um objetivo comum, como construir uma ponte, projetos acadêmicos, ou até mesmo o planejamento de um aniversário.
O Scrum é um framework para desenvolvimento iterativo e incrementalparagerenciamento de projetose desenvolvimento ágil de software. É fundamentado nas teorias empíricas de controle de processo. O empirismo afirma que o conhecimento vem da experiência e de tomada de decisões baseadas no que é conhecido.
O Scrum apresenta uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos. Três pilares suportam sua implementação:
- Transparência: A transparência garante que aspectos do processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os resultados. Esses aspectos não apenas devem ser transparentes, mas também o que está sendo visto deve ser conhecido. Isto é, quando alguém que inspeciona um processo acredita que algo está pronto, isso deve ser equivalente à definição de pronto utilizada;
- Inspeção: Os diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que variações inaceitáveis no processo possam ser detectadas. A frequência da inspeção deve levar em consideração que qualquer processo é modificado pelo próprio ato da inspeção. O problema acontece quando a frequência de inspeção necessária excede a tolerância do processo à inspeção. Os outros fatores são a habilidade e a aplicação das pessoas em inspecionar os resultados do trabalho;
- Adaptação: Se o inspetor determinar, a partir da inspeção, que um ou mais aspectos do processo estão fora dos limites aceitáveis e que o produto resultante será inaceitável, ele deverá ajustar o processo ou o material sendo processado. Esse ajuste deve ser feito o mais rápido possível para minimizar desvios posteriores.
Os papéis principais em equipes Scrum são aqueles comprometidos com o projeto no processo do Scrum e os que produzem o produto (objetivo do projeto). Times Scrum são auto organizáveis e multifuncionais. Equipes auto organizáveis escolhem qual a melhor forma para completarem seu trabalho, em vez de serem dirigidos por outros de fora da equipe. Equipes multifuncionais possuem todas as competências necessárias para completar o trabalho sem depender de outros que não fazem parte da equipe. O modelo de equipe no Scrum é projetado para aperfeiçoar a flexibilidade, criatividade e produtividade. O tamanho ideal da equipe de desenvolvimento é o suficiente para se manter ágil e grande o suficiente para completar uma parcela significativa do trabalho. Menos de três integrantes na equipe de desenvolvimento diminuem a interação e resultam em um menor ganho de produtividade.
Cerimônias SCRUM
As cerimônias SCRUM são eventos que acontecem dentro de um ciclo de desenvolvimento utilizando esta metodologia. Existem três tipos de cerimônias SCRUM: a reunião de Planejamento do Sprint, as reuniões diárias SCRUM e a reunião de revisão do Sprint. Estes três tipos de evento caracterizam bem o ciclo de vida de cada Sprint: início, meio e fim.
O primeiro passo de um projeto SCRUM é quando o PO desenvolve um plano para o projeto de software. Neste plano, ele trabalha bem próximo ao cliente para definir todas as funcionalidades que o cliente quer no seu produto. A partir desta lista, ele também tem que definir as prioridades de cada funcionalidade de acordo com várias variáveis: valor de mercado, importância de base, importância para o cliente, entre outras. Esta lista final é o que chamamos de Product Backlog e é a base para a reunião de planejamento do Sprint.
Nesta reunião, o ScrumMaster trabalha junto com o PO e a equipe de desenvolvimento para definir qual a carga de tempo que cada funcionalidade do Product Backlog terá. Isto ajuda o PO a definir prazos reais para o projeto e o habilita a poder verificar como está o andamento do projeto durante todo o período de desenvolvimento. Esta carga de tempo e esforço é definida de acordo com o tamanho dos times, horas disponíveis e o nível de produtividade do time." [...] continue lendo...
