Introdução ao Scrum

Como resposta aos diversos fracassos nos projetos de softwares que utilizavam processos de desenvolvimento tradicionais, fadados ao fracasso por requisitos e especificações incompletas ou a falta de envolvimento do cliente no projeto, foi criado o manifesto ágil. Este foi um projeto que reuniu diversos profissionais de desenvolvimento de software com o objetivo de discutir melhores práticas no processo da construção destes.

A forma de interação entre stakeholders, ou seja, os interessados no projeto e a colaboração com o cliente final foram algumas das características que sofreram grandes mudanças.

Graças ao manifesto, várias metodologias alternativas e frameworks ganharam espaço. Dentre os frameworks, o que mais se destacou foi justamente o Scrum, que será abordado ao longo do artigo.

Saiba mais: Levantamento de requisitos utilizando o Scrum

Embora este tenha sido projetado para ser um framework estrutural para desenvolvimento de produtos de software é possível aplicá-lo também a outros projetos.

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. Funciona praticamente como um "esqueleto", que fornece uma estrutura básica como suporte.

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, conforme mostra a Figura 1 , 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. A Figura 1 exemplifica o funcionamento de uma Sprint, onde os requisitos contidos no Product Backlog são selecionados, ordenados e colocados em outra lista chamada Release planning, depois dividida em uma ou mais Sprints. Diariamente o time Scrum realiza uma reunião (Daily Scrum) que acontece em pé 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.

Saiba mais: Curso de Scrum - Conhecendo o Product Owner

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 que serão apresentadas a seguir.

Ferramentas para trabalhar com Scrum

Existem muitas ferramentas próprias para trabalhar com Scrum, sejam elas web, desktop, gratuitas, pagas ou freemium (gratuitas, mas com algumas funcionalidades pagas).

Iremos conhecer algumas que podem ajudar no gerenciamento do projeto.

Opção1 - ScrumHalf

É uma ferramenta web brasileira com um período de avaliação gratuita. É uma boa ferramenta, não tão detalhada e rica em características, mas possui a interface bastante simples. Além disso, permite fazer anexos aos backlogs do produto diretamente do Dropbox, que e um sistema de arquivos em nuvem

Por padrão, ela vem com as configurações de acordo com a Figura 2.

No sumário do projeto há algumas informações como estatísticas, Burn-up (permite analisar o desempenho das Sprints em forma de gráfico), descrição do projeto e a possibilidade de gerar relatórios de Sprints ou até de Releases.

A ferramenta permite diferenciar, de forma clara, quem são os integrantes do projeto, como mostra a Figura 3.

Outra boa opção da ferramenta é o chat do projeto, que permite comunicação com o restante da equipe, como mostra a Figura 4.

As sprints são exibidas em um quadro Kanban, ou seja, um quadrocom post-its, divididas em tarefas a fazer, tarefas em execução e tarefas prontas, como mostra a Figura 5.

No menu da Sprint existe maneiras de revisar o Scrum e gerar a retrospectiva, ressaltando pontos positivos e negativos do projeto e metas alcançadas.

Opção 2 - ScrumDesk

É uma ferramenta completa e interativa, pois possui versão para web e desktop. É muito boa para gerenciar times Scrum, pois permite adicionar membros ao projeto e delegar tarefas.

A página inicial do projeto é um quadro que pode ser adequado em formato list ou desk, que exibem o backlog do produto. Após adicionar funções ao backlog é possível vincular cada uma delas as Sprints, como mostra o exemplo da Figura 6.

Outra vantagem desta ferramenta é a visualização de alterações de forma detalhada. É possível também gerenciar tarefas do product backlog em uma espécie de quadro Kanban, com funcionalidade drag-and-drop (arrastar e soltar), como mostra a Figura 7.

Dá para perceber que o ScrumDesk é mais completo, porém, mais complexo. Além disso, permite integrar o projeto ao App de comunicação Slack, que funciona no Android e no iOS para unificar as comunicações internas das empresas.

Opção 3 - Trello

Não necessariamente é uma ferramenta própria para projetos Scrum, pois ela é essencialmente uma solução para organização de tarefas através de quadros Kanban, mas que podem auxiliar bastante em qualquer projeto.

Ela é composta de quadros, onde em cada um pode-se criar lista que, por sua vez, pode-se criar cartões. Na prática é bem simples utilizar, como mostra o exemplo da Figura 8.

Veja que usamos alguns conceitos de Scrum em uma ferramenta que não necessariamente foi feita para gerenciar projetos deste tipo. Usamos o product backlog com os requisitos do produto, que foram passados para uma outra lista, a release planning divididas em sprints, e depois gerenciadas em quadros de acordo com o estado da tarefa: pendente, em execução, atrasadas ou finalizadas, como podemos ver na Figura 9.

A figura exemplifica a configuração de cartões no Trello, que possui funcionalidades interessantes para o trabalho colaborativo. Além disso, é permitida a delegação de tarefas a determinados membros, determinar data de entrega, anexar documentos, visualizar histórico de atividades, realizar comentários e compartilhar o quadro de tarefas. Também possui a funcionalidade de compartilhamento, que torna o Trello uma opção de quadros kanban completa. É uma boa opção para gerenciamento de tarefas, mas não possuem características específicas de um projeto Scrum, como organização de reuniões, revisão de sprints e time-boxes.

Veja que mesmo com uma ferramenta que não foi desenvolvida para Scrum conseguimos trabalhar com agilidade em nossos projetos. A ideia do manifesto ágil e das metodologias ágeis que surgiram foi quebrar o paradigma de gestão de projetos tradicional através de um meio alternativo. O Scrum, não sendo uma metodologia, deve ser aplicado com outros métodos para obter o sucesso. Aplique o Scrum no contexto certo, incentive as pessoas envolvidas (inclusive o cliente) e cumpra os prazos e reuniões. Este conjunto bem aplicado é uma ótima maneira de obter bons resultados.