Para entender melhor precisamos conhecer primeiro o dilema de nomenclatura, como apresentado a seguir.
Scrum: Framework ou metodologia
Por mais que o Scrum forneça ferramentas e maneiras de se conduzir o desenvolvimento ele não pode ser considerado uma metodologia.
A diferença entre metodologia e framework é que uma metodologia fornece praticamente tudo que é necessário para condução de um projeto. Ela é mais completa que um framework, já que diz o que fazer e como fazer. Já o framework apenas indica qual a trajetória, mas não indica exatamente como fazer, existindo a possibilidade de ser empregado juntamente com outros processos e técnicas.
Por dentro do Scrum
O Scrum é um framework estrutural para gestão de projetos baseado no empirismo, afirmando que o conhecimento vem de experiências anteriores e de decisões tomadas. Isso significa que é um framework iterativo e incremental, pois usa experiências anteriores para aperfeiçoar controle de riscos e decisões futuras. Além disso, possui como ideia que o desenvolvimento do produto é algo que tem um grande grau de incerteza, por isso deve ser construído de forma empírica.
O produto de software deve estar suficientemente bem direcionado e definido no início do planejamento e na elicitação de requisitos, embora a documentação excessiva seja dispensável. A ideia é justamente partir para a etapa “mais importante” do projeto, que é o desenvolvimento, evitando grande detalhamento no início do mesmo e codificar o mais rápido possível.
Porém recomenda-se que nas etapas iniciais o cliente já esteja presente, dando feedback constante a cada ciclo ou até mesmo definindo novos requisitos. Mas para isso o time de desenvolvimento deve estar apto a adequar o produto às novas mudanças. O Scrum conta com etapas bem definidas e ajudarão nas mudanças de cada ciclo. A seguir conheceremos mais sobre essas etapas.
Mecânica e ciclo do Scrum
O Scrum possui alguns elementos e etapas bem definidas, que exemplifica o funcionamento e ciclo de uma Sprint, parte essencial do Scrum.
Para entender melhor este artigo alguns termos precisam ser detalhados:
Product Backlog – É uma lista organizada que contém tudo que o produto deverá ter. Sua ordenação e coerência é mantida pelo Product Owner. O backlog do produto é dinâmico e deve evoluir de acordo com a evolução do produto em si, para que se adeque ao novo formato e tenha a utilidade apropriada;
Product Owner – O dono do produto é a pessoa responsável por gerenciar o backlog do produto. Ele acrescenta valor ao produto e ao trabalho do time de desenvolvimento. É o principal responsável por manter contato com a equipe de desenvolvedores e afirmar quais são os requisitos necessários no product backlog;
Defect Backlog – Representa tarefas defeituosas, que por algum motivo não funcionaram. Em outras palavras, são tarefas com bugs;
Scrum Master – Quem desempenha este papel deve garantir o progresso do projeto do produto, mantendo a comunicação com a equipe, monitorando o trabalho feito e organizando reuniões. Além disso deve garantir que cada membro envolvido no projeto tenha as ferramentas necessárias para executar seu próprio trabalho;
RoadMap do produto – É um plano feito pelo Product Owner, que demonstra como se espera que o produto evolua ao longo do tempo;
Daily Scrum (Scrum diariamente) – São reuniões diárias que o grupo se compromete a participar. As reuniões são feitas em pé e a ideia por trás disso é não desperdiçar tempo, então as reuniões são curtas. No Daily Scrum é muito comum que o tema abordado seja o andamento e colaboração de cada participante no projeto;
Sprint backlog ou Sprint– Todas as atividades do projeto Scrum se encontram divididas em Sprints, que são ciclos de tarefas;
Sprint review – É uma reunião informal, onde é feita uma revisão, sempre executada ao final de cada Sprint para avaliar o que foi feito e, caso necessário, fazer modificações no Product Backlog;
Sprint retrospective – Acontece após o fechamento de uma Sprint com o intuito de analisar pontos positivos e negativos do que foi realizado;
Product planning – Reunião que visa discutir e planejar os trabalhos que serão realizados nas Sprints. O conceito de time-box (Caixa de tempo) também é discutido. Time-boxes são determinações de tempo para fazer um trabalho. O tempo máximo que uma time-box pode receber é de oito horas, que pode ser aplicado à reuniões ou aos Sprints;
Release Planning – Forma “enxuta” do backlog do produto. Os requisitos do backlog são ordenados por prioridade para depois serem divididos entre os Sprints;
Burndown chart – É um gráfico que assegura que os Sprints estão sendo cumpridos dentro do prazo previsto. É muito importante para o time ter conhecimento do andamento do projeto e fazer ajustes, caso seja necessário.
Resumidamente, os ciclos são chamados de Sprints, onde cada um acontece de maneira linear, um após o outro e possui tamanho fixo definido por um time-box. Isso significa que todas as etapas do projeto que usa Scrum estão contidas em Sprints.
Diariamente o time Scrum realiza uma reunião (Daily Scrum) para discutir sobre o andamento das Sprints. Ao final de cada Sprint é feita uma Sprint review para analisar o que foi feito e, em seguida, a Sprint restropective para analisar pontos positivos e negativos e realizar possíveis mudanças.
O Product Owner ainda conta com ajuda do Scrum Master, além de todo seu time envolvido. O Scrum Master é responsável por organizar reuniões, deixar claro a todos os participantes qual papel cada um deve exercer e quais ferramentas são necessárias para que possam desempenhar seus trabalhos.
A visão do produto deve ser mantida pelo Product Owner, assim maximizando o seu valor. Ele mantém comunicação constante com os clientes e partes interessadas no projeto para que a visão do produto seja a mais clara possível. Com o projeto bem definido e atualizado, o Product Owner cria um Roadmap do produto, que é um plano de como é esperado que o produto evolua ao longo do tempo.
Assim, todos esses eventos apresentados até agora fazem parte de um ciclo conhecido como PDCA: Plan -> Do -> Check -> Act (Planejar, Fazer, Checar, Agir).
Veja bem: uma equipe de Scrum seguindo o planejado normalmente documenta características do produto no Product backlog, ordena por ordem de importância e prioridade em uma Release Planning e planeja meios de alcançar objetivos em um Product planning. Assim, alcançamos a fase PLAN.
Após o planejamento dividem os requisitos da(s) Release(s) Planning(s) em Sprints backlogs e executam as tarefas das Sprints de acordo com o tempo estipulado, concluindo a fase DO.
Ao final de cada Sprint, é hora de realizar a Sprint Review e a Sprint restropective, revisando e avaliando o que foi feito até então e, caso haja necessidade, fazer as alterações no Product backlog, finalizando a fase CHECK.
Todo o desempenho da equipe em relação ao cumprimento das tarefas é armazenado em no gráfico Burndown Chart. E as tarefas de Sprints que geraram bugs podem ser movidas para o Defect Backlog e removidas ou corrigidas, concluindo a fase ACT.
Como o Scrum é recomendado para projetos que estão em constante mudança, o ciclo apresentado pode ser iniciado várias vezes, conforme os requisitos que veremos a seguir.
Mudanças com Scrum
Em um projeto de software existem mudanças no decorrer dos processos: ora acontecem mudanças nos recursos e pessoas envolvidas, ora nos requisitos do cliente. Por isso que em projetos de alta complexidade o Scrum é altamente aconselhável.
Algumas das características e pontos fortes dele permitem que problemas como esse sejam contornados de forma eficaz:
Os indivíduos envolvidos no projeto passaram a serem mais importantes que os processos;
O cliente está muito mais presente no desenvolvimento que nas formas tradicionais;
Tem-se agilidade na entrega do produto;
Só se entrega de algo de valor (produto que atenda às necessidades do cliente);
O produto final tem mais importância do que uma documentação abrangente;
Projeto flexível é aquele onde é mais importante responder às mudanças do que ao planejamento;
Frequentes entregas de parte do produto funcionando.
Todos as características do Scrum fazem com que um projeto seja capaz de se moldar à realidade, uma vez que o cliente está sempre presente para manter os requisitos.
O sucesso ou não com o uso de qualquer metodologia ou framework que seja dependerá da sua aplicação. Por isso, devemos nos atentar a alguns fatos a serem apresentados na próxima seção.
Como obter sucesso com o Scrum
Para se ter sucesso, antes de mais nada, temos que ter certeza que estamos aplicando Scrum em um contexto adequado. Mas como podemos saber isso?
Alguns pontos importantes merecem destaque:
É importante que o time Scrum (Stakeholders) esteja encorajado e tenha conhecimento do funcionamento da nova maneira de trabalho;
Prazos de time-boxes devem ser seguidos da maneira que foram determinados, assim uma atividade não interfere na outra;
Evite menosprezar tarefas difíceis, pois também faz parte da qualidade.
Imagine o seguinte: você está em uma rua quilométrica e, com certeza, você conseguirá observar e descrever até certo ponto aquilo que está a curta distância. Após determinado ponto já não é possível descrever com tanta clareza, mas ainda assim é possível observar e ter uma ideia do que se trata. Mais longe ainda, a quilômetros de distância, não será possível nem observar e muito menos descrever de forma clara.
Comparando este cenário hipotético com um projeto veja que, embora não se saiba os detalhes do projeto do início ao fim, é possível ter ao menos um começo e uma visão detalhada até um certo momento, e isso é importante para o Scrum. É necessário que tenhamos pelo menos um “horizonte” para podermos dar início ao ciclo.
Para colocar tudo isso em prática, contamos com algumas ferramentas e fazendo parte do nosso time serão oferecidas.
