Scrum uma visão prática do framework

278 visualizações

Publicada em

Modifiquei meu artigo para o modo apresentação do PowerPoint e inseri algumas imagens de ferramentas Microsoft que uso na empresa atual.

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
278
No SlideShare
0
A partir de incorporações
0
Número de incorporações
6
Ações
Compartilhamentos
0
Downloads
5
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Scrum uma visão prática do framework

  1. 1. Scrum: uma visão prática do framework Roberto Passani Gomes Analista de Testes – BNY Mellon
  2. 2. Sobre o Scrum 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), e tudo é baseado nas reuniões do processo. Entre uma reunião e outra o trabalho é realizado, as 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.
  3. 3. Estrutura do Sprint Para a apresentação 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 serão detalhadas durante a apresentação.
  4. 4. Apresentação do Ambiente A equipe na qual este artigo foi baseado é constituída de Product Owner, Scrum Master (que usualmente também acumula funções de Coordenador), Analista de Testes (autor do artigo), Designer, Analista de UX (User Experience) e desenvolvedores (no caso, quatro), que se dividem entre as plataformas iOS e Android (desenvolvimento Móvel), além disso temos equipes externas que dão suporte e ambiente aos projetos, como analistas de produto, setor comercial e infraestrutura. Conforme será detalhado mais a frente na apresentação, é função do Scrum Master se comunicar com outras equipes e remover riscos; questões de infraestrutura, backend e serviço, portanto retirar quaisquer bloqueios das histórias antes que elas entrem em qualquer Sprint.
  5. 5. Primeiros passos O primeiro passo para desenvolvimento de um sistema no Scrum, segundo o formato aqui apresentado, seria a reunião de pre-planning, onde são definidos o objetivo principal do sistema, isto é, aquilo que ele deseja atingir (core): 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 as principais.
  6. 6. Criação de Histórias 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 alguém além do Product Owner, o Scrum Master consegue analisar se há alguém além dos participantes diretos do projeto que deva ser convidado para os ritos, como Planning e Review, se há alguém externo à equipe que deseja inserir histórias ou acrescentar algo ao sistema.
  7. 7. Inclusão da Equipe Todos devem participar desse processo, ajudar na definição dos critérios, ajudar no levantamento de critérios de exceção, mensagens de erro e possíveis cenários que faltam definição. A equipe deve ser unida profissionalmente e ter o objetivo comum de entregar o melhor sistema possível. E o analista de testes já inicia a escrita dos testes baseado nesses requisitos, criando todos os testes de validação, exceção, carga, performance, e o que mais for necessário, muitas vezes já escrevendo os testes (apenas com objetivo) na própria reunião, através de um bloco de notas, caderno ou qualquer outra ferramenta. Já a equipe de desenvolvimento pode começar a pensar em todo o backend (serviços e servidores) necessário, e tudo que será preciso para a implementação do sistema.
  8. 8. Sobre o Pré-Projeto Uma vez estruturado o backend de serviços, a equipe pode começar a implementação do software, e para priorizar as histórias e analisar quais farão parte de um primeiro sprint realiza-se uma primeira reunião de planning, onde as histórias iniciais são colocadas no primeiro sprint e priorizadas na ordem decrescente dentro dele. Primeiramente colocam-se todas as histórias que precisam ser feitas e depois elas são priorizadas. Em seguida, pontua-se cada história de acordo com o critério utilizado no projeto (Fibonacci, por horas ou outro), daí podemos analisar se ainda é possível inserir alguma história, se a meta de pontos não estiver sido atingida, ou se alguma história deverá sair se a meta estiver sido ultrapassada. Caso a meta tenha sido ultrapassada e a quantidade de pontos das histórias for maior do que os pontos ultrapassados, então a última história, segundo os critérios de priorização, poderá ser dividida em duas.
  9. 9. Cuidados com a montagem do Sprint Um Sprint nunca deve ser iniciado com a quantidade de pontos excedida, com histórias que possuem critérios de aceite não definidos, sem layout ou definição de UX incompleta. Por isso, se a quantidade de pontos for excedida e não houver a possibilidade de troca com outra história, então os critérios de aceite devem ser divididos em duas histórias, sendo uma no Sprint atual, fechando o sprint dentro da métrica de pontuação e outra como a primeira história do próximo (segundo), abrindo o próximo sprint com os pontos e critérios de aceite que restaram, devendo ser devidamente entregue cada uma em seu sprint.
  10. 10. Primeiro Planning No planning, todo o layout e definições de UX já devem estar prontos e aprovados pelo “Product Owner”, tudo já deve estar disponível para análise da equipe de testes e desenvolvimento. No caso de aplicativos móveis é necessário ter a tela completa e também cada botão separado, cada ícone, com todas as definições de tela para iOS: retina e não- retina, e para Android: LDPI, MDPI, HDPI, XHDPI, XXHDPI. O ideal é anexar todas as imagens na história para facilitar o acesso para a equipe otimizando o tempo e evitando ter que buscar em Drivers, e-mail, e etc., ou em um sistema de pastas que nem sempre é claro para todos. Portanto, para realizar o desenvolvimento, todas as histórias do sprint que está para se iniciar precisam ter status de definidas na ferramenta usada pela empresa, que indica que todos os dados aqui descritos já foram detalhados, anexados à história e/ou link tenha sido disponibilizado.
  11. 11. Pós-Planning Logo após o planning, o Scrum Master deve marcar o pré-planning, review e planning que estão por vir, para 10 dias úteis após o primeiro planning, considerando que o planning já ocorre no primeiro dia do sprint e o review no último. Neste cenário, se o planning ocorre em uma segunda-feira dia 01, então o pré-planning deve ser marcado para quarta-feira dia 10 (aproximadamente) e o Review exatamente para o dia 12, sexta-feira. Tudo isso deve ser marcado com antecedência para que as datas de todos os ritos sejam de conhecimento de todos da equipe evitando atrasos por indisponibilidade de local ou surpresa em sua realização.
  12. 12. Sobre o uso de TDD no Projeto No projeto é utilizado o TDD, ou seja, Test Driven Development, porém um TDD um pouco diferente, não baseado em testes unitários ou automatizados, mas baseado nos testes funcionais escritos a partir dos critérios de aceite definidos no pré-planning. Os testes da primeira história da ordem de priorização devem ficar prontos antes do início do Sprint. O desenvolvedor segue os casos de testes para criar o sistema. Portanto, o analista de testes já deve ter todos os testes escritos e detalhados a essa altura do processo com a maior cobertura possível de forma otimizada. Esses testes devem estar disponíveis na ferramenta para análise dos desenvolvedores evitando paradas e atrasos no desenvolvimento, pois todas as perguntas já devem ter sido levantadas e respondidas, todas as mensagens de erro, validação e exceção com a cobertura adequada de forma que nenhuma demanda tenha que ser coberta no meio processo.
  13. 13. O inicio dos Testes Conforme as histórias forem sendo iniciadas, elas vão obtendo status de progresso na ferramenta. Após isso, quando forem sendo completadas, já podem ser disponibilizadas para teste. No caso de aplicativos móveis, é gerado um build que é instalado no aparelho, e os analistas de testes podem analisar as funcionalidades já implementadas. Uma vez encontrados erros, eles devem ser registrados na ferramenta e, se bloquearem a história (severidade e prioridade) e não forem recorrentes, devem ser corrigidos no próprio sprint. Caso sejam erros recorrentes ou que não bloqueiam a história ou seus critérios de aceite, eles podem ser deixados no backlog para priorização posterior.
  14. 14. Cadastro de Bugs Uma vez registrados bugs que ficam no sprint, eles devem então ser corrigidos em um novo build do sistema, e todos os testes da nova funcionalidade devem ser reexecutados para garantir que a correção de um defeito não gerou erros em outras partes da nova funcionalidade. Esse processo é repetido até que todos os testes sejam executados e nenhum erro seja encontrado. Feito isso, a história poderá obter o status de completa na ferramenta e poderá ser liberada para o Review que ocorrerá no último dia do sprint.
  15. 15. Dailies – Compromisso diário Diariamente, na rotina do projeto e com horário fixo, sempre com a presença de todos ou o máximo possível de componentes da equipe, deve ocorrer a “Daily Meeting” (Reunião Diária), onde todos devem resumir suas atividades do projeto desde a daily meeting anterior, tentando detalhar as ações e que métodos usou para atingir seus objetivos, abrindo espaço para que os colegas possam auxiliar em dúvidas ou se utilizar dos dados ali compartilhados como lições aprendidas ou melhores práticas.
  16. 16. Intercorrências – Não Planejado Na prática, sempre pode ocorrer de critérios de aceite ou exceção não terem sido definidos, algum layout ou definição de UX aparecer de última hora durante o Sprint. Nesse caso, devem ser tratados com urgência, uma vez que o desenvolvimento pode ficar parado até que artefatos sejam criados. O responsável pela experiência de usuário (UX) ou designer precisam criar o material necessário com o menor impacto possível no sprint para evitar atrasos ou impedimento da entrega. Caso essa solução se torne demasiadamente grande e o impacto inevitável, então a história pode ter a prioridade reduzida para o fim do Sprint, quando a definição ou artefatos necessários estarão prontos. Caso isso ainda não seja o bastante, então podemos finalizar o Sprint dentro do prazo normal e essa deverá ser a primeira história do próximo, a Review não deve ser adiada ou o Sprint alongado, salvo exceções, mas isso pode trazer impacto negativo a longo prazo e nunca deve se tornar uma rotina.
  17. 17. A Review Após finalizado o processo de desenvolvimento, passadas muitas “daily meetings” e muitas linhas de código, ocorre a primeira reunião de Review. A primeira versão poderá ser entregue, as funcionalidades devem ser preparadas e o ambiente todo pronto para a análise do “product owner”. Ao iniciar a reunião, o sistema deve estar disponível para uso de forma que as funcionalidades entregue possam ser exibidas, de preferência no projetor, e os critérios de aceite vão sendo passados ponto a ponto para análise do cliente. Ele pode realizar os testes necessários e passar por seus critérios de pronto. Quando finalizadas, as histórias obtêm aprovação no sistema e o cliente passa a analisar a próxima. Caso a história não seja completa e os critérios de aceite não sejam todos atingidos, ela pode passar por “split”, ou seja, ser dividida em duas, onde a segunda história poderá ser a primeira do próximo Sprint e terá os critérios de aceite que faltam para completar. Algumas ferramentas automaticamente repassam as tarefas incompletas para a história do próximo sprint. Caso os critérios de pronto do cliente é que não sejam atendidos, ou seja, ele visualizar novos critérios de aceite que deveriam ser incluídos para que a história possa ficar disponível para o usuário final então deve ser criada uma nova história para um sprint futuro e que será priorizada no planning. Essa deve conter os novos critérios de aceite que finalizam a nova funcionalidade.
  18. 18. Pré-Planning – Sprint 2 Durante o Sprint, deve ser realizada a reunião pré-planning. Nela devem ser enriquecidas as histórias para o Sprint 2, inserir critérios de aceite e priorizar histórias de UX, design e backend; para que tudo esteja pronto quando houver o planning.
  19. 19. Retrospectiva do primeiro Sprint Logo após o fim do Sprint, deve ser feita uma reunião de retrospectiva, onde os membros da equipe (exceto Product Owner) devem relatar como foram os últimos dias (do Sprint), todas as atividades de sucesso, boas práticas, lições aprendidas e “à melhorar” para obter um processo mais sólido e rico, satisfatório para todos, todos devem ter liberdade para falar tudo que desejam, sem ser oprimidos por alguma opinião contraditória, abrir discussão sobre o ponto apresentado e detalhar melhor sobre qualquer tópico. Geralmente abordam-se primeiro os pontos positivos, mas não é uma regra, pode ser feito assim apenas porque os pontos negativos costumam gerar mais polêmica. Após essa etapa discutem-se os pontos de melhoria, que costumam gerar mais polêmica e deixar ânimos exaltados. Todos devem se sentir à vontade para falar de qualquer tópico: desde a internet no ambiente de trabalho, relacionamento com outras equipes e pessoas, ar-condicionado, assim como questões técnicas que influenciam diretamente no projeto como design, UX, critérios de aceite, formato de código, algoritmos, processo, links, atuação de colegas, etc.
  20. 20. Remoção de Riscos Após apresentados e discutidos os dois lados do último sprint, ações de melhoria devem ser tomadas, ou seja, Product Owner, Scrum Master e Coordenador devem definir como e onde podem agir para tentar resolver ou, ao menos, apaziguar os pontos de melhoria do projeto que dependem de ação externa. Relacionamento com outras equipes, ações com a gerência da área ou até com as diretorias da empresa com o objetivo de tornar o ambiente do projeto o melhor possível, ações internas, como performance de um colaborador específico ou mudanças no processo devem ser resolvidas internamente e monitoradas durante as daily meetings do próximo sprint. Muitos projetos não veem importância na retrospectiva, principalmente com a evolução dos sprints onde o processo fica mais sólido e as retrospectivas se tornam repetitivas. Porém, só há evolução do projeto se houver reuniões de retrospectivas bem feitas. É importante também estar atento ao fato de que ninguém pode levar os pontos de melhoria para o lado pessoal. Essa é uma reunião para um processo de maturidade e o conceito é altamente profissional com objetivo de fazer um trabalho melhor.
  21. 21. Planning - Sprint #2 Após a retrospectiva, analisados os pontos positivos e definidos os pontos de melhoria, ocorre o Planning para definir o segundo sprint. As ações de melhoria já devem começar a ser adotadas imediatamente, e o processo se reinicia, histórias devem ser priorizadas. Se houve história com split no sprint anterior, então essas podem ser as primeiras, porém não é obrigatório, por isso os branches devem estar bem organizados para que uma história com menor prioridade possa ser continuada em um sprint posterior sem uma linha de aprendizado muito longa. Após priorizadas as histórias, deve-se discutir a pontuação, e definir as histórias que ficam no Sprint e quais serão adiadas para os próximos sprints. Devem ser evitadas discussões paralelas nas reuniões. No Planning algumas pessoas tendem a sair do foco, gostam de opinar, porém é o Product Owner quem define, as prioridades são dele e da área de negócios. É necessário manter o objetivo de construir o Sprint rapidamente para retornar ao desenvolvimento, porém sem deixar pontos indefinidos, como dito antes, todo o design, UX, backend, serviços, etc., precisa estar definido antes de iniciar o Sprint.
  22. 22. Descrição dos papéis de cada personagem do processo Para explicar melhor as atividades durante o processo de desenvolvimento de software, é interessante esclarecer as funções e papéis de cada ator no processo, o que é esperado de cada um e onde ele pode fazer algo mais, o “quilômetro extra” (versão brasileira da “Extra Mile” americana, que é aquilo feito além do esperado, além das responsabilidades) por onde se pode andar, onde se pode auxiliar na melhoria do processo para obter mais qualidade do sistema e mais satisfação do cliente. Eventualmente, em um processo de maturidade elevada e profissional, as pessoas opinam na forma como os colegas atuam, ou seja, o desenvolvedor tenta melhorar o processo de testes, o analista de testes ajuda o Scrum Master e esse pode ajudar nas funções do “Product Owner” ou coordenador, por exemplo.
  23. 23. Scrum Master – Funções e responsabilidades Sua função principal é definir e manter o processo sendo seguido, marcar e manter os ritos, garantir a presença de todos (ou o máximo possível) os participantes, ver se cada ação é realizada corretamente em cada reunião a que pertence, garantir que todos estão executando suas atividades no momento certo do projeto, se o desenvolvimento segue padrões de qualidade, testes unitários, design patterns, métricas, buscar novas formas de atingir metas assim como, analisar se o analista de testes (ou qualidade) está seguindo corretamente o processo, escrevendo os objetivos de testes no pré- planning, se os testes da primeira história já estão prontos após o planning (para iniciar o desenvolvimento), se a cobertura dos cenários de testes está adequada, coordenar se o processo é corretamente seguido, bem próximo dos analistas que fazem com que ele ocorra. Seu excedente pode ser analisar o sistema e ver se há formas diferentes e talvez melhores de fazer o mesmo, pesquisar, procurar se inteirar nos documentos sobre sistemas similares e analisar se há novos padrões sendo adotados, procurar o que há de mais moderno, quais os caminhos que estão sendo seguidos para obter o melhor desse modelo de sistema, assim como também do processo. Seguir práticas, discussões em fóruns, ler as revistas especializadas e obter dados de como otimizar o processo sem denegrir a qualidade, ou seja, o ScrumMaster deve ser sempre muito dedicado e proativo, muito curioso e ciente das atividades diversas para ver falhas onde não estão olhando, seja no desenvolvimento ou nos testes, sempre com objetivo de aprimorar onde pode haver algum tipo de evolução.
  24. 24. Analista de Testes – O Coringa É responsável por validar e garantir a qualidade do sistema, verificar que os critérios de aceite são devidamente atendidos, nenhum bug escape ou deixe de ser registrado, que os testes regressivos continuem aumentando, sendo atualizados, evoluindo, sendo executados em todos os critérios corretamente, que o ambiente seja bem preparado para a Review, que os testes sejam bem escritos e a cobertura seja adequada já no Planning. Outra função que o analista de testes costuma ter é fornecer dados para as métricas do projeto, analisar quantos defeitos são encontrados, quantos são corrigidos e quantos novos defeitos são encontrados a partir disso. Além disso, deve fornecer esses dados para a equipe de qualidade que irá analisar o desenvolvimento do sistema e a performance dos desenvolvedores, a evolução da equipe e se o processo está sendo seguido corretamente.
  25. 25. Desenvolvedor – Cabeça no código É responsável por criar o sistema, elaborar as funcionalidades, seguir corretamente os testes e critérios de aceite, analisar pontos de exceção, levantar questões sobre o planning para visualizar falhas de cobertura, pontuar com critério as histórias inserindo também o tempo de testes de cada feature e o regression ao final do Sprint. Precisam também seguir o processo de testes unitários definido e garantir que haja sempre evolução na quantidade de testes e melhora na cobertura.
  26. 26. Analista de UX – Usabilidade e Fluxo do Sistema É responsável pelo desenho do sistema, interfaces com usuário, a localização das funcionalidades, o resultado esperado de cada ação, que o sistema tenha a melhor usabilidade, que as funcionalidades sejam práticas, atendam padrões dos fabricantes (no caso de aplicativos móveis, por exemplo), que mensagens de erro sejam evitadas, mas, caso necessário, é responsável pelo texto da mensagem, pelo nome (“label”) dos botões. Além disso, deve analisar estatísticas do aplicativo, uso de funcionalidades e priorizar aquilo que é o foco e que o usuário mais procura no sistema. Também é responsabilidade do analista de UX pesquisar e fazer simulações com usuários, passar formulários, para descobrir quais são as funcionalidades que o usuário procura, e quais melhorias enriqueceriam o sistema e trariam mais usuários.
  27. 27. Designer – Ícones e Layout O designer de um sistema é responsável pelo layout, escolha de cores, logomarca, por aplicar o que o analista de produto (UX) projetou e o Project Owner aprovou.
  28. 28. Coordenador – “Pára-raios” dos problemas É função do coordenador do projeto dar toda estrutura de qualidade para que a equipe de forma adequada. Normalmente, associa-se ao Scrum Master para garantir a manutenção dos ritos e que o processo seja seguido. Além disso, atua no sentido de auxiliar na correção dos pontos de melhoria.
  29. 29. Product Owner – O Dono, parcerias e patrocínios É o dono do projeto, o cliente. É por ele que tudo começa, quem toma as decisões, as histórias são priorizadas com a opinião de todos mas de acordo com a vontade do PO. É ele quem define os critérios de aceite, na função de cliente ele utiliza todos os estudos do designer e do analista de UX para definir quais melhor se encaixam com os objetivos de projeto, e as necessidades de quem de fato utiliza o sistema. Também é função dele atuar próximo à área de negócio para ajudar a trazer patrocinadores, verba ou investimento ao projeto. No Scrum, tudo ocorre ao redor das reuniões, por isso elas são primordiais e precisam ser muito bem feitas. Essas etapas precisam ser bem obedecidas para garantir a qualidade do sistema e ter evolução no processo e no produto. Sendo bem definidas as reuniões e ficando claras as funções e responsabilidades de cada ator, as chances de desenvolver um projeto de sucesso utilizando o Scrum serão maiores.

×