ensino_scrum
Share on facebook
Share on twitter
Share on linkedin

Jogos para o ensino do SCRUM e das histórias de usuários

dti digital

dti digital

Um dos nossos colaboradores especializados!

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

Introdução

O processo de aprendizagem está aprimorando constantemente seus métodos de ensino para que se obtenha uma melhoria na educação a nível de graduação e até mesmo dentro do ambiente corporativo. Com o método lúdico, cresce a vontade de aprender, seu interesse ao conteúdo aumenta e, dessa maneira, ele realmente aprende o que foi proposto a ser ensinado, estimulando-o a ser pensador e questionador.

O lúdico deixou de se referir apenas ao sentido de jogo, fazendo parte da atividade humana e com características espontânea, funcional e satisfatória, não importando somente o resultado, mas a ação e o que se é vivenciado com a atividade. O objetivo do artigo é evidenciar a possibilidade de uma alterativa 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.

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

  1. Os participantes são divididos em grupos (preferencialmente em trios);
  2. O material é distribuído e apresentado aos participantes;
  3. 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

  1. 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;
  2. 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;
  3. 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;
  4. 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

Preencha seus dados para receber nossa newsletter!

Ficou com dúvidas?

contato@dtidigital.com.br
R. Antônio de Albuquerque, 330 – 14° andar
Savassi, Belo Horizonte – MG, 30112-010

Cuidado

Nós utilizamos cookies e outras tecnologias semelhantes para analisar sua experiência no site e personalizar conteúdos e anúncios durante sua navegação. Ao navegar pelo site, você autoriza a DTI Digital a realizar tal monitoramento. Conheça nossa Política de Privacidade.

you are being redirected to a page in portuguese, do you want to continue?