Jogos para o ensino do SCRUM e das histórias de usuários
Vivemos em um cenário em que o ensino do levantamento de requisitos e a gerência de projetos não é muito abordado no universo da Engenha de Software. Para sanar essa dor, apresentamos uma estratégia de ensino do Scrum para que a geração atual e as próximas possam experimentar uma abordagem que agrega a teoria e a prática. Esse artigo foi adaptado de Proposta e Avaliação de uma Abordagem Lúdica para o Ensino de Histórias de Usuário e Scrum
Sumário
Introdução
O processo de aprendizagem está constantemente aprimorando seus métodos de ensino, visando melhorar a educação tanto em nível de graduação como dentro do ambiente corporativo. Através do uso do método lúdico, a vontade de aprender aumenta, o interesse pelo conteúdo é estimulado e, dessa forma, os alunos realmente absorvem o que foi proposto a ser ensinado, incentivando-os a serem pensadores e questionadores.
O termo “lúdico” não se restringe mais apenas ao sentido de jogo, mas tornou-se parte integrante da atividade humana, apresentando características espontâneas, funcionais e satisfatórias. O foco não está apenas no resultado, mas na ação e na experiência vivenciada durante a atividade. O objetivo deste artigo é destacar a possibilidade de uma alternativa aos jogos digitais para o ensino de práticas ágeis.
Conceitos de metodologia ágil necessários ao ensino do Scrum
Agilidade
Métodos ágeis baseiam-se em uma abordagem incremental para a especificação, o desenvolvimento e a entrega do software. Eles são mais adequados ao desenvolvimento de aplicativos nos quais os requisitos do sistema mudam rapidamente durante o processo de desenvolvimento. Uma das grandes vantagens dos métodos ágeis é o de possuir o compromisso de atuar de forma rápida e adaptativa às demandas do cliente, reduzindo burocracias e formalidades para melhorar o desempenho final do processo de desenvolvimento de software. Não significa simplesmente desenvolvimento rápido de aplicações, mas principalmente capacidade de adaptação com rapidez e flexibilidade a mudanças nos processos, nos produtos e no ambiente.
Scrum
Scrum é um framework estrutural sobre o qual se pode utilizar dos vários processos ou técnicas para se desenvolver produtos complexos. Não é somente um processo ou técnica, mas a relação entre papéis, eventos, artefatos e regras do Scrum que viabilizarão um gerenciamento de projetos adaptável, iterativo e incremental. Esse modelo de gerenciamento de projetos advém das teorias empíricas de controle de processo e, portanto, se apoia nos pilares transparência, inspeção e adaptação.
O processo de gerenciamento no Scrum baseia-se nas unidades de trabalho denominadas Sprints. Sprint como um container para outros eventos e possuem essa estrutura para viabilizar transparência e inspeção criteriosa. Além disso, é importante citar que Sprints destinam-se para o desenvolvimento do(s) requisito(s) definido na Lista de Pendências (Product Backlog) e que será entregue no prazo estipulado
Nessa estrutura, então temos duas figuras que irão colocar em prática o Scrum: o Product Owner define uma lista de funcionalidades a serem desenvolvidas no Product Backlog. Após essa definição, o Scrum Master estabelece quais dessas serão desenvolvidas no decorrer da Sprint.
Histórias de usuário
História de Usuário é um método para levantamento de requisitos que descreve de forma funcional os requisitos para o cliente ou comprador do projeto.
- Cartão: meio de registro do requisito, normalmente em texto curto e como forma de lembrete quando na fase de desenvolvimento do software;
- Conversas: comunicação existente entre os envolvidos para melhor detalhar a história;
- Critérios de aceitação: pormenores a serem validados por meio de testes que servirão para validar e dar por concluída uma história. Apesar de o cartão conter as funcionalidades, mas não é o mais importante. Por meio das conversas serão tratados todos os detalhes de cada funcionalidade. Uma história, ainda que sintetizada no cartão, que produz histórias ainda menores, é chamada de épico. Assim, um épico contém vários detalhes a serem descritos em cartões distintos.
O método INVEST
Algumas características devem ser observadas ao escrever as histórias de usuário. O acrônimo inglês INVEST (Independent, Negotiable, Valuable to users or customers, Estimatable, Small and Testable), contém os seis atributos indispensáveis para uma história bem escrita. São eles:
-
- Independente: uma história deve poder ser desenvolvida, testada e até entregue A conclusão de uma história deixa o produto em um estado em que ele pode ser entregue;
- Negociável: as histórias representam oportunidades de discussão dos requisitos. Deve haver possibilidade de trade-offs entre funcionalidade e datas de entrega;
- de Valor: proporcionar valor para o cliente é a essência dos métodos ágeis. Trata-se de uma mudança de uma abordagem de decomposição hierárquica funcional para uma abordagem vertical;
- Estimável: a equipe deve ser capaz de prover uma estimativa de sua complexidade e quantidade de trabalho necessário para terminar a história. Se equipe não consegue estimar, a história deve ser quebrada em histórias menores;
- São de tamanho pequeno: As histórias devem ser completadas em uma iteração. Histórias pequenas provêm maior agilidade;
- Testável: a história deve ser testável, pois se a equipe sabe como testar uma história, eles sabem como codificá-la.
Atividade para ensino do Scrum
- Os participantes são divididos em grupos (preferencialmente em trios);
- O material é distribuído e apresentado aos participantes;
- O contexto e requisitos do sistema, procedimentos e regras da atividade são apresentados aos presentes e, a partir de então, se dá início à atividade propriamente dita, que se encerra com um questionário para avaliação da prática.
Contexto
Para o desenvolvimento do sistema, os participantes são apresentados às necessidades de uma biblioteca de uma escola pequena que precisa informatizar seus processos de pesquisa ao acervo, realização de empréstimo e devoluções. Neste cenário, os participantes ficam sabendo que a biblioteca não aplica penalidades aos participantes que atrasam as devoluções. Entretanto, mantém em seus arquivos uma restrição vinculada à matrícula do aluno que não devolver o livro até sua formatura e isso implica débitos para o aluno que deseja retirar seu diploma.
Sabem ainda que atualmente existe um sistema de gestão acadêmica na escola contendo os dados cadastrais de todos os participantes e ex-participantes e o mesmo disponibiliza em arquivo XML os dados dos participantes. Em relação às prioridades, os participantes tomam conhecimento de que é urgente para a biblioteca realizar a pesquisa em seu acervo seja pelo nome do livro, por autor ou gênero literário. Quando algum usuário realizar a pesquisa, o sistema deverá exibir o nome do livro, nome do autor (ou autores) e quantidade de exemplares contidos na biblioteca. Até que o processo de empréstimo e devolução seja incorporado, não é necessário apresentar a disponibilidade dos itens do acervo. Os empréstimos e devoluções são processos que podem ser entregues depois. Atribuir restrições a participantes com pendências é o processo de menor grau de prioridade para a biblioteca.
Dinâmica
Como pode ser observado, as informações passadas aos participantes permitem que eles possam reconhecer as histórias principais e até mesmo decompor algumas em histórias menores. Além disso, passa informações para que tenham uma noção da prioridade de cada história de maneira que eles possam identificar aquelas que devem compor a primeira Sprint.
Cada grupo inicia a atividade registrando nos cartões de história aquelas levantadas com base no cenário apresentado. Em seguida, os participantes fixam as histórias no Product Backlog.
Considerando a prioridade já estabelecida no cenário e também por meio de conversas realizadas com o Product Owner (papel desempenhado pela pessoa responsável por guiar a dinâmica), cada história terá sua prioridade assinalada. Em seguida, as histórias de prioridade alta são transferidas para a Sprint Backlog e estimativas são realizadas usando o método Planning Poker.
Terminadas estas atividades, os participantes então detalham as tarefas para a primeira história da Sprint Backlog, bem como os seus critérios de aceitação também registrados em cartão conforme representado na Figura 6. Por último é elaborado um produto, chamado de “produto acabado” sob a forma de protótipo de tela que refletirá a funcionalidade descrita na história cujas tarefas foram detalhadas e critérios de aceitação escritos. Esse produto precisa evidenciar ao menos um dos critérios de aceitação da história.
Regras
- Sempre que julgar necessário esclarecer dúvidas em relação ao cenário e/ou histórias, o grupo deve solicitar uma conversa com o Product Owner. Cada conversa terá a duração máxima de 3 minutos para permitir que o Product Owner atenda também outros grupos;
- Não há limites de número de conversas por grupo, mas existe a seguinte política de atendimento: O Product Owner primeiro deverá atender pelo menos uma vez cada grupo conforme ordem de chegada e solicitação dos Caso haja muitos pedidos de conversa e o tempo não seja suficiente, o Product Owner atenderá os grupos de tal forma que a quantidade de conversas com os grupos seja igual ou aproximada;
- No verso do cartão de história são listadas as características que uma história bem elaborada deve Os participantes são incentivados a utilizar o texto sempre que julgarem necessário;
- Os participantes são informados que no material fornecido há cartões de história preenchidos para auxiliar na elaboração dos cartões de história da atividade;
Dicas para o ensino do Scrum
O artigo original apresenta alguns pontos de atenção:
- No cenário a ser trabalhado, é importante que para quem desempenhar o papel de Product Owner, o escopo esteja bem claro e assim nas conversas desenvolvidas na atividade não haja divergências de respostas entre os grupos;
- Para ser aplicado em sala de aula, a atividade foi adaptada de acordo com o público. Portanto alguns passos se diferenciam um pouco da prática adotada nas empresas. Como por exemplo, a ordem que as estimativas e decomposição das histórias em tarefas são realizadas.
Tem interesse em fazer parte de um time que fomenta o aprendizado constante e te dá a chance de atuar diretamente na cultura ágil? Então acesse nossa página de carreiras, escolha a vaga que mais se encaixa no seu perfil e venha ser dti!
Por: Lorena Adrian
Desenvolvimento Profissional
Confira outros artigos
Como se tornar um analista de segurança da informação
O modo antigo de Segurança propunha modos de trabalho onde equipes trabalhavam separadas. Entretanto, na medida em que as empresas vão se transformando digitalmente, esse cenário também precisa se adaptar. Para tal, busca-se um modelo de trabalho em que o analista de segurança da informação encaixe o seu modelo de trabalho no modus operandi atual, […]
Desenvolvimento Profissional
Trajetórias negras no contexto digital e no agilismo
Quando falamos do contexto digital e trajetórias negras no agilismo, temos algumas pré-concepções de falarmos sobre times anti-frágeis, multidisciplinares, criativos e com várias outras características positivas. Nenhuma dessas concepções são errôneas, mas te convido a pensar que talvez, elas sejam incompletas se não analisadas em suas diferentes faces, e uma delas, é a face da […]
Desenvolvimento Profissional
5 Disfunções de um time: O que fazer a respeito
Durante o programa de mentoria que participei em Liderança aqui na dti no ano passado, me deparei com a proposta da minha mentora para fazermos uma discussão sobre o livro “The Five Dysfunctions of a Team”, ou, em tradução, “5 disfunções de um time”. Julgando o livro pela capa e pelo nome, propus começarmos o primeiro capítulo e, caso não […]
Desenvolvimento Profissional