Levantar requisitos, planejar o projeto, criar o cronograma, controlar os custos, executar o desenvolvimento, fazer os testes, validar os requisitos e entregar o produto. Uffa.. todos estes processos para no final do projeto descobrir que o cliente não ficou satisfeito com o produto, houve erros no levantamento dos requisitos, o cliente mudou o escopo mil vezes ou simplesmente o cliente não gostou do designer. Este modelo de gerenciamento de projetos, foi utilizado por muito tempo e dados mostram a alta taxa de fracasso deste modelo. Hoje iremos falar do framework que mudou todo este contexto de gerenciar projetos e hoje é considerado o novo passo para gerenciamento de projetos.
O Scrum foi criado inicialmente para gerenciamento de automóveis e produtos de consumo por Takeuchi e Nonaka no artigo "The New Product Development Game" (Harvard Business Review, Janeiro-Fevereiro 1986). Os idealizadores notaram que projetos usando equipes pequenas e multidisciplinares produziam melhores resultados, e associaram estas equipes altamente eficazes à formação Scrum do Rugby (utilizada para reinício do jogo em certos casos). Jeff Sutherland, John Scumniotales e Jeff McKenna conceberam, documentaram e implementaram o Scrum, conforme descrito abaixo, na empresa Easel Corporation em 1993, incorporando os estilos de gerenciamento observados por Takeuchi e Nonaka. Ken Schwaber e Jeff Sutherland fizeram a primeira co-apresentação do Scrum na conferência OOPSLA de 1995. Esta apresentação essencialmente documentou o aprendizado que Ken e Jeff tiveram ao longo dos anos anteriores na aplicação do Scrum. Ajudando a implantá-lo no desenvolvimento de softwares em todo o mundo. O Scrum agrupa conceitos de Lean, desenvolvimento iterativo, integração continua e foco no cliente.
O Guia do Scrum
O Guia do Scrum é o documento oficial que documenta o Scrum, suas regras e definições conforme desenvolvido e sustentado por mais de 20 anos por Jeff Sutherland e Ken Schwaber. Caso deseja baixar uma cópia clique aqui.
A função primária do Scrum é ser utilizado para o gerenciamento de projetos de desenvolvimento de software. Ele tem sido usado com sucesso para isso, assim como Extreme Programming e outras metodologias de desenvolvimento. Porém, teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessitem trabalhar juntas para atingir um objetivo comum.
Vamos começar a falar sobre os artefatos do Scrum
TimeBox - É o máximo de tempo que deve durar um evento no Scrum.
Esforço – O Scrum tem um processo diferente para valorar atividades, normalmente fazemos isso utilizando o aspecto de tempo (Ex: uma tarefa irá ficar pronta em tanto tempo). No Scrum utilizamos o esforço, (Ex: o qual difícil será fazer esta atividade) o framework recomenda utilizar a sequência de Fibonacci (0,1, 1, 2, 3, 5, 8, 13, 21, ...) como parâmetro.
Backlog do Produto – São todas as solicitações que o cliente deseja que o produto tenha e ainda as demandas necessárias para estas solicitações ficarem prontas, pense neste como um documento de requisitos, escopo do projeto ou planejamento do produto. Aqui estará tudo que precisa para o produto ficar pronto. O diferencial do backlog do produto é que as solicitações não precisam estar totalmente especificadas no inicio do projeto, o backlog é vivo, assim as tarefas mais prioritárias (que serão desenvolvidas primeiro) precisão ter um nível de especificação suficiente para serem desenvolvida, as tarefas menos prioritárias poderão ser especificadas mais tarde. Esse procedimento facilita a mudança de escopo caso o cliente deseje.
Backlog da Sprint – Aqui teremos todo o trabalho que será feito dentro da Sprint (timebox). As atividades do backlog do produto são transformadas em tarefas pela equipe de desenvolvimento, estas tarefas devem ser valoradas para compreendermos quantas tarefas conseguimos contemplar dentro de uma Sprint.
Agora vamos falar sobre os Papeis:
Product Owner (PO) – Este é o responsável pela manutenção e controle do backlog do produto, suas principais funções são: entender as necessidades do cliente, priorizar o as atividades mais importantes, detalhar as atividades com a equipe de desenvolvimento, transmitir o que o cliente necessita para equipe de desenvolvimento. Pense neste papel como o analista de negócios, um bom PO deve ser o cliente, deve validar e pensar em cada atividade que trará benefícios para o negócio, umas das ferramentas utilizadas pelo PO é o ROI (Return On Investment).
Scrum Master (SM) – Normalmente esse papel é confundido como o do gerente de projeto, o que é um erro, o SM basicamente é um facilitador, sua função é gerenciar o processo Scrum e eliminar todas as barreiras que a equipe de desenvolvimento e PO tiverem durante o projeto. O SM não pode ter o poder de demitir funcionários ou bonificá-los, pense neste papel como o técnico de um time, ele não entre em campo (desenvolvendo) mas orienta o time em como deve funcionar o framework.
Development Team (DevTeam) – Estes são os responsáveis pela construção do software, produto ou serviço. A equipe deve possuir habilidades multifuncionais que possibilite fazer todo o trabalho do projeto como analisar, projetar, desenvolver, testar, documentar e etc. Outro ponto importante é que a equipe deve ser autogerenciável, os participantes devem ser comprometidos e maduros, não existe a figura do chefe que determina o que deve ser feito, as decisões são realizadas democraticamente.
Scrum Team – É a junção dos três papeis do Scrum, product owner, scrum master e development team. O Scrum prega que á equipe seja de no mínimo 3 e no máximo de 9 pessoas. Lembrando que não existe um gerente, todos devem colaborar com o projeto entendendo o seu papel.
Eventos do Scrum
Sprint
Objetivo: Realizar as atividades necessárias para entregar o acordado no final.
Participantes: Team Scrum
Timebox: Máximo de 4 semanas e mínimo de 1 semana.
A Sprint nada mais é que um tempo determinado (timebox) para realização do trabalho. Quando tempos uma Sprint de 1 mês todo o backlog da sprint deve contemplar atividades para um mês de trabalho, incluindo esforço, priorização e refinamento das atividades.
Planning Meeting – Reunião de Planejamento
Objetivo: Detalhar e priorizar as atividades que serão desenvolvidas na Sprint.
Quando Ocorre: Início da Sprint.
Participantes: Team Scrum
Timebox: 8 horas para Sprint de 1 mês, 4 horas para Sprint de 15 dias e assim sucessivamente.
Neta reunião o PO leve o backlog do produto com todas as atividades priorizadas (utilizando o ROI). A equipe de desenvolvimento pegas estas atividades e destrincha em tarefas, com isso o time começa a pontuar as tarefas com base no esforço que será realizado para entregar a tarefa. O objetivo é que no final da reunião, o time saia com o backlog da Sprint, que são as tarefas que podem ser realizadas até o final da Sprint.
Daly Meeting - Reunião diária
Objetivo: Realizar o reporte e status das atividades que estão sendo desenvolvidas.
Quando Ocorre: Todos os dias, exceto quando há as reuniões de Planning, review e restrospectiva.
Participantes: Developmet Time. (Scrum Master e PO podem participar apenas como ouvintes)
TimeBox: 15 minutos. Todos os participantes devem estar de pé, é preferível que utilizem sempre o mesmo local e horário.
Esta reunião é feita diariamente com toda a equipe de desenvolvimento onde são abordadas três perguntas para cada membro, o que eu fiz ontem, o que vou fazer hoje e se existem algum impedimento para realizar meu trabalho. Esta reunião é excelente para que haja o report de cada membro sobre suas atividades, assim os outros integrantes podem ajudar se alguém estiver com algum impeditivo para finalizar o trabalho, o intuito é a colaboração entre os membros da equipe.
Review Meeting – Reunião de Revisão
Objetivo: Apresentar o trabalho que foi realizado durante a Sprint.
Quando Ocorre: No final da Sprint.
Participantes: Time Scrum e Stakeholders.
TimeBox: 4 horas para uma Sprint de 1 mês e 2 horas para uma Sprint de 15 dias e proporcional para Sprints deiferentes.
Está na hora de apresentarmos o andamento do projeto, a reunião de review acontece para todos os envolvidos do projeto, nesta reunião são apresentadas as atividades que foram planejadas na reunião de planning. A ideia é que o cliente/usuários finais verifiquem o andamento do projeto, não é um evento de testes, é uma reunião para apresentar as soluções já feitas (validações). Esta reunião é excelente para levantar mais “requisitos” sobre o projeto e dar visibilidade do andamento do projeto.
Retrospective Meeting – Reunião de Retrospectiva
Objetivo: Apresentar os processos que deram certo e o que precisa ser feito melhor.
Quando Ocorre: Após a reunião de revisão e antes da reunião de planejamento.
Participantes: Time Scrum.
TimeBox: 3 horas para uma Sprint de 1 mês e 90 minutos para uma Sprint de 15 dias e proporcional para Sprints diferentes.
Na reunião de retrospectiva é hora de falar sobre o processo e andamento do Sprint a equipe se reuni para debater o que fizeram de bom durante a sprint, o que deu errado e como melhorar o processo para aumentar a performance, normalmente a equipe se une para falar sobre, integração continua, acessos a banco de dados, versionamento de código, melhorar o refinamento dos requisitos e etc.. Qualquer assunto que possa melhorar a performance do desenvolvimento do projeto pode ser abordado nesta reunião.
Grooming
Está reunião não é mandatória, porém é bastante utilizada pela equipe de desenvolvimento, quando uma atividade não está bem especificada e a equipe precisa de mais detalhes é marcado com o PO e se necessário o usuário final uma reunião para tirar duvidas e detalhar melhor a atividade, está reunião tem bastante valia pois a reunião de planning tem um timebox curto para um detalhamento complexo e existem atividades muito técnicas que o PO não consegue mapear sozinho, a reunião de Grooming pode ser realizada durante a Sprint com as tarefas existentes no backlog da Sprint e seu tempo não pode exceder mais de 5% do timebox da sprint.
Valores
O que mais me chama atenção no Scrum, são os valores bem definidos. A base do framework são estes valores e todos os membros do Scrum Team deve praticar. Parece algo simples, porem estabelecer essa cultura em uma organização é o mais difícil do processo são valores que muitas pessoas desconhecem ou não conseguem praticar.
Coragem – A equipe precisa ter coragem para encarar os desafios e não ficar o tempo todo na defensiva procurando problemas. A ideia é solucionar.
Foco – Parece obvio, mas a equipe precisa estar focada no produto que deseja entregar, cada atividade deve ser encarada como desafio, não podemos perder o foco é adiar problemas.
Comprometimento – Esse é um valor que acredito fundamental, uma equipe comprometida com os resultados e performance não a limite. A parte difícil é motivar colaboradores, pois como disse ninguém da equipe deveria ter o poder de realizar um aumento salarial ou satisfazer alguma necessidade de colaboradores.
Respeito – Sem este valor nenhuma equipe dura o suficiente para finalizar um projeto. No Scrum temos uma equipe multifuncional e auto gerenciável, todos os colaboradores tem o mesmo peso, independente do cargo ou salário na empresa. Sem o respeito, é impossível um bom convívio entre os membros da equipe.
Abertura – Todos os participantes do projeto devem ser abertos a outros integrantes, os stakeholders deve ser aberto a retirar dúvidas, a equipe de desenvolvimento aberta a mudanças. O ideal é que exista um ambiente de harmonia onde todos estão comprometidos em entregar o projeto, então todos devem ser abertos a interação.
Agora que entendemos todos os artefatos e eventos do Scrum, vamos falar sobre como ocorre o uma Sprint.
A Sprint é iniciada com a execução da reunião de planning, nesta reunião os participantes do time scrum se reúnem por um timebox determinado de acordo com o tamanho da Sprint. Nesta reunião o PO leva o backlog do produto com todas as atividades priorizadas que cliente deseja validar no final do processo. Durante a reunião a equipe de desenvolvimento começa a pontuar as atividades com o esforço necessário e divide as atividades em tarefas. A equipe de desenvolvimento combina com PO as atividades que podem ser entregues até o final da Sprint baseados no esforço. É importante ter em mente que as atividades que o PO leva para a planning devem ter os requisitos suficientes para serem desenvolvidas, caso negativo, a equipe pode recusar a atividade, podendo agendar uma reunião de grooming (reunião de detalhamento) ou adicionar está atividade apenas na próxima Sprint.
Após a finalização da planning temos o backlog da Sprint criado, onde irá conter todas as atividades/tarefas que serão realizadas durante a sprint. Com este backlog em mãos, a equipe de desenvolvimento inicia o trabalho de desenvolvimento, lembrando que diariamente temos as reuniões de diárias realizadas pela equipe de desenvolvimento onde, pode ser obter o status e report do andamento das atividades, um dos valores do scrum é a colaboração e abertura, então sempre que existir necessidade de tirar dúvidas o PO ou cliente devem ser solícitos.
No final da Sprint a equipe se reúne com os stakeholders para realizar a reunião de revisão, onde as atividades realizadas na Sprint serão validadas pelo usuário, importante lembrar que os usuários não irão testar as atividades, este já deve estar previsto na Sprint. Durante a reunião os usuários/clientes podem dar sua opinião sobre o que foi feito, e dar sugestões para a nova Sprint, o SM deve fazer o intermédio da reunião e o PO anotar as solicitações dos clientes.
Após estão reunião podemos fazer a retrospectiva que reúne o time scrum para debaterem o que foi feito de bom e ruim durante esta sprint o objetivo é melhorar os processos fortificando o que fizeram de bom e criando um plano de ação para as mudanças que são desejadas pela equipe. Após o final da Sprint uma nova Sprint se inicia de maneira cíclica, e todas as atividades são realizadas novamente.
O Scrum é framework muito bem estruturado e organizado, muitas empresas não só de TI estão utilizando este modelo para gerir projetos e demandas em suas organizações. Não podemos pensar que é solução para todos os projetos mais é uma ótima alternativa para deixar sua empresa mais ágil.
Comments