O Scrum é uma abordagem ágil que prima pela otimização e objetividade no processo e em todas suas etapas, costuma minimizar burocracias, documentação e módulos em relação a outros processos (como RUP).
Tudo é baseado nas reuniões do processo (que são muitas). Entre uma reunião e outra o trabalho é realizado.
Essas reuniões são importantes ao ponto de algumas empresas não usarem nenhuma documentação escrita, ou seja, fazem Sprints semanais e reuniões às segundas e sextas, de Planning e Review respectivamente, onde fazem todo o tracking das atividades e desenvolvimento do produto.
Neste artigo usaremos o modelo de um Sprint de 10 dias úteis, ou aproximadamente 14 dias corridos, sendo o Planning no primeiro dia e o Review no último.
Após o Review ocorre a Retrospectiva e no decorrer do Sprint o pré-planning. Diariamente devem ocorrer as reuniões Diárias (Daily Meetings). Todas essas etapas são detalhadas no artigo.
A equipe na qual este artigo foi baseado é constituída uma Product Owner, um Scrum Master (que também acumula funções de Coordenador), um Analista de Testes (o autor do artigo), uma Designer, um Analista de UX (User Experience) e quatro desenvolvedores, que se dividem entre as plataformas iOS e Android, fora outras pessoas que auxiliam a equipe, como analistas de produto, infraestrutura e outros.
A manutenção do processo é responsabilidade do Scrum Master, ou seja, marcar todas as reuniões, garantir a presença de toda a equipe, comandar as reuniões em si, escrever no sistema de gerenciamento do processo, auxiliar no desenvolvimento dos critérios de aceite, avaliar questões de serviço, backend e etc.
Definição do Projeto
O primeiro passo para desenvolvimento de um sistema no Scrum seria a reunião de pre-planning (pré-planejamento), onde são definidos o objetivo principal do sistema, isto é, aquilo que ele deseja atingir: o mercado, o público e a/as funcionalidade(s) principal(ais) - para um aplicativo, por exemplo, seja trânsito, notícias, compras ou futebol - onde são pré-planejadas as histórias que iniciarão o desenvolvimento, e nelas são inseridos os critérios de aceite ou entrega. Estes são basicamente os requisitos do sistema, o detalhamento de todas as funcionalidades, desde as mais simples àquelas principais.
O título das histórias devem ser escritos na perspectiva de quem desejam atingir, por exemplo: “Eu, como cliente, quero que o aplicativo faça…” ou “Eu, como área de negócios da empresa, quero inserir a logomarca de nosso patrocinador…”, ou ainda, “Eu, como Product Owner, quero ver uma mensagem de erro quando o usuário executar uma ação indevida…”.
Isso facilita analisar quem deve aprovar a história. Caso exista a ...
