Olá Pessoal, tudo bom?
O post de hoje tem o objetivo de explicar um pouco como funciona a metodologia ágil chamada Scrum, pois iremos utilizá-la para criar e continuar o projeto do Mauda Hostels. Vamos aprender um pouco sobre ela na continuação desse texto.
Scrum
Scrum é uma metodologia ágil para gestão e planejamento de projetos de software. Com uma organização realizando a arbitragem das regras da metodologia, chamada Scrum Org ((Scrum Org – https://www.scrum.org/)) é possível dizer que essa metodologia está bem amadurecida para ser utilizada por equipes de desenvolvimento em todo o mundo.
Atores de um projeto Scrum
Existem vários atores dentro de um projeto que segue a metodologia Scrum:
- Product Owner – Dono do Projeto – Pessoa que tem as responsabilidades de definir as prioridades negociais, dirimir as duvidas negociais, avaliar os requisitos e o sistema codificado.
- Scrum Master – Lider do Projeto – Pessoa que tem as responsabilidade de ajudar o Scrum Team a respeitar a metodologia do Scrum, remover barreiras e outros impedimentos do team. Normalmente é exercido por um gerente de projeto ou líder técnico.
- Scrum Team – Equipe de Desenvolvimento – Grupo de pessoas compostas pela equipe de desenvolvimento, equipe de requisitos e equipe de testes, que possui a responsabilidade de entregar o projeto nos prazos acordados com o Product Owner. Normalmente é composto de 6 a 10 pessoas, pois facilita a parte de padronizações na equipe.
Planejar sempre no inicio…
No inicio do desenvolvimento de uma release entregável do projeto, o Product Owner, irá se reunir com o Scrum Master e Scrum Team em uma reunião chamada Inception. Essa reunião normalmente dura de 3 a 5 dias e serve para o Product Owner apresentar o projeto ou as novas funcionalidades para o Scrum Team. Durante essa reunião são elencadas funcionalidades possíveis que estarão presentes na entrega final do projeto. Essas funcionalidades elencadas são armazenadas em um local chamado Sprint Backlog.
O projeto que utiliza da metodologia Scrum é dividido em etapas chamadas Sprints. Uma sprint é um período de tempo, normalmente 20 dias úteis, o qual a equipe deverá desenvolver um conjunto de funcionalidades extraídas do Sprint Backog. Assim em algum momento da reunião de Inception deverá ser definido com o Product Owner a quantidade de dias que cada Sprint terá e será valida para todas as sprints do projeto.
Além disso, próximo do fim da reunião, o Product Owner deverá definir para todas as funcionalidades qual é a prioridade negocial para a criação da funcionalidade. Baixa, Média ou Alta. Isso indica quais são as funcionalidades negocialmente mais importantes, pois estas podem ser atacadas por primeiro, para ter mais tempo de testes sobre estas. Junto com essa definição o Scrum Team deverá definir para cada funcionalidade qual é a dificuldade técnica para desenvolver a funcionalidade: Fácil, Médio ou Difícil. Deve-se levar em conta tecnologias desconhecidas, integrações com outros sistemas e particularidades das funcionalidades.
Por fim, com a definição das prioridades negociais e dificuldades técnicas, essas funcionalidades são distribuídas nas Sprints. A quantidade de funcionalidades definidas por sprint varia de equipe para equipe, pois não é possível indicar um numero exato de funcionalidades que o Time irá conseguir desenvolver na Sprint. Com a distribuição das funcionalidades nas Sprints é possível definir quantas sprints serão necessárias para que essa release do projeto seja entregue e multiplicando isso pela quantidade de dias úteis definidas por Sprint, quando que o projeto estará disponível para implantação.
Após a Inception já partimos para a Sprint 1?
Não! Após a reunião de Inception, existe um período chamado de pré-game, ou Sprint Zero. Mas pra que isso???? Vamos desenvolver po… Calma gafanhoto, não é bem assim, deixa eu explicar…
O primeiro ponto é. Após a reunião de Inception, todo o Scrum Team foi apresentado ao projeto. Inclusive os analistas de requisitos. Assim esse tempo de pré-game serve para que eles possam escrever os requisitos. Além disso os analistas de requisitos e o product owner irão conversar muito sobre as duvidas levantadas por essa escrita. Além disso, o Product Owner necessita aprovar os requisitos para que a Sprint 1 possa começar a ser desenvolvida pelo Scrum Team, pois como será desenvolvido algo que o dono não aprovou?
Tá, mas e a equipe de desenvolvimento fica parada? Não necessariamente! Os arquitetos podem ir definindo alguns pontos levantados na reunião de inception, como integrações ou novos pontos tecnológicos. E o restante da equipe pode ir estudando novas tecnologias que serão utilizadas no projeto. Ninguém precisa ficar parado! Todos já tiveram as informações básicas sobre as funcionalidades, dessa forma é possível encontrar tarefas para todos.
E a equipe de testes, também há trabalho pra eles? Como o planejamento dos testes é feito a partir dos requisitos aprovados, nesse momento não há tanto trabalho concreto para a equipe de testes. Assim podem estudar ou entender alguma tecnologia de testes que será utilizada no projeto.
Com o término dos requisitos e aprovação do Product Owner, é possível iniciar a Sprint 1.
Sprint 1 e outras…
Toda Sprint começa com a equipe de requisitos apresentando os casos de uso ou histórias para a equipe de desenvolvimento e equipe de testes. Normalmente essa apresentação tem duração máxima de 1 dia dependendo da quantidade de funcionalidades máximas elencadas para a Sprint.
Após essa apresentação a equipe de desenvolvimento irá realizar uma reunião de análise, com duração máxima de 3 dias, com os seguintes objetivos:
- Definir as tarefas de desenvolvimento para as funcionalidades, pois podem haver partes gráficas, negociais ou de banco de dados
- Elencar pontos mais críticos das funcionalidades para a Sprint, definindo formas destes serem atacados
- Projetar um diagrama de classes UML ou continuar a elaboração deste
Após a reunião de análise começa o desenvolvimento propriamente dito. Essa etapa se estende até o penúltimo dia da Sprint. Durante o desenvolvimento surgirão duvidas e serão elencadas para a equipe de requisitos. Estes enviarão para o Product Owner para responde-las. Dependendo do que for a resposta, pode impedir temporariamente o desenvolvimento desta funcionalidade. Assim é possível que o desenvolvimento de uma funcionalidade seja postergado para as próximas sprints.
Todos os dias deverá ocorrer uma reunião chamada de Daily Meeting. Essa reunião possui tempo máximo de 15 minutos e serve para que todos os integrantes do Scrum Teram saibam o que os outros integrantes estão fazendo e para impedimentos que possam estar ocorrendo com o time.
A equipe de testes irá começar a testar as funcionalidades assim que esta estiver pronta, mas isso não impede que no começo da Sprint após a apresentação dos requisitos, eles já comecem a executar o planejamento dos testes para as funcionalidades.
A equipe de requisitos deverá estar com os requisitos da próxima Sprint prontos e aprovados pelo Product Owner ao final da Sprint atual. Impedindo assim que a equipe de desenvolvimento fique sem trabalho.
Todas as atividades da Sprint deverão ser encerradas até o penúltimo dia da Sprint, pois no último dia será realizada uma apresentação das funcionalidades codificadas para o Product Owner, chamada Validação da Sprint. Essa reunião é muito importante pois o Product Owner já consegue ver como está ficando o seu produto e consegue identificar problemas pontuais em um tempo muito menor, podendo redirecionar o Scrum Team para atender seus anseios.
Além disso no último dia também é realizada uma reunião de retrospectiva da Sprint, verificando pontos positivos e negativos da Sprint, para que a equipe melhore o seu trabalho nas próximas Sprints.
Esse ciclo se repete por todas as sprints que existirem no projeto.
finally{
Com essa apresentação básica sobre as definições do Scrum, podemos elencar como iremos aplicar essas definições ao projeto. O ponto principal aqui é elencar que o projeto irá seguir o conceito de definições pequenas com a entrega destas, não querendo fazer tudo de uma vez. Pois isso facilita a tomada de decisões e ajuda a elencar explicações sobre cada aspecto do desenvolvimento. Mas de qualquer forma esse conhecimento apresentado acima é amplamente utilizado no mercado de trabalho, assim é muito importante saber esses conceitos.
Duvidas ou sugestões? Deixe seu feedback! Isso ajuda a saber a sua opinião sobre os artigos e melhorá-los para o futuro! Isso é muito importante!
Até um próximo post!
Leave a Reply