8 minutos de leitura
Como discutido no artigo anterior, toda metodologia Agile aborda a complexidade no trabalho, tornando a informação transparente para que qualquer um possa inspecionar e se adaptar de acordo com as condições atuais ao invés das – equivocadas e não mais aplicáveis ao contexto – condições previstas. Isso permite que as equipes se protejam das armadilhas comuns de um processo de desenvolvimento em cascata (“Waterfall”): o caos resultante de requisitos em constante mudança; subestimação de tempo, recursos e custo; compromissos na qualidade do software; e relatórios de progresso imprecisos.
Os princípios ágeis são utilizados para guiar as diferentes metodologias de trabalho nas maiores empresas de tecnologia do mundo, como Google, Amazon, IBM e Microsoft. Contudo, um ponto muito relevante sobre os princípios ágeis é que eles surgiram para suprir a necessidade de uma metodologia adequada para projetos de software, mas seus adeptos vão muito além de empresas de TI. Algumas das maiores corporações do mundo, dos mais diferentes setores, são adeptas de alguns desses frameworks de trabalho, como: Bancos (Bank of America, Merrill Lynch, Credit Suisse, …), Consultorias (McKinsey & Co., Accenture, …), Mídia (CNN, The Economist, …) e tantos outros. Por mais diferentes que sejam seus nichos de mercado ou modelo de negócios, todas essas empresas tem uma coisa em comum que as fazem adeptas dessas novas metodologias de trabalho: a necessidade por agilidade para responder ao micro e macroambiente em que estão inseridas.
Deu para ter uma noção do quão relevante são esses novos métodos de trabalho?
Nesse artigo, vamos abordar o framework de princípios ágeis mais famoso, um dos menos atrelados ao uso exclusivo para desenvolvimento de software e, não por acaso, um dos mais fáceis de serem aplicado a qualquer empresa: o Scrum.
Scrum
Como surgiu?
O Scrum, a metodologia ágil mais famosa dentre o leque existente – e, também, a mais utilizada em empresas – foi criada no início da década de 90, com sua criação sendo atribuída a Jeff Sutherland e Ken Schwaber. Os dois, mais tarde, viriam a escrever o livro que funciona como manual para gestores implementarem o framework, “Guia do Scrum”. Seu nome advém do rugby e se refere a um time atuando em conjunto para atingir uma “goal” (em inglês, “goal” se refere tanto a “gol” – objetivo do time de rugby – quanto uma “meta” estabelecida) – uma analogia ao ambiente organizacional de uma empresa.
Como funciona?
O framework de trabalho do Scrum envolve 3 elementos para um bom funcionamento dos processos: (1) Papéis (personas envolvidas), (2) Cerimônias (eventos que devem ocorrer) e (3) Artefatos (documentação necessária).
Papéis
Product Owner: O PO, como é chamado, é o usuário principal do projeto ou qualquer pessoa com uma compreensão sólida dos usuários, do mercado, da concorrência e das tendências futuras para o tipo de projeto que está sendo desenvolvido. Tem papel chave na questão da comunicação dentro do projeto, pois ele coordena a relação com o Time e quaisquer outros stakeholders envolvidos no projeto.
Scrum Master: É um líder-servil para o Time. Ele não tem autoridade sobre o Time, mas tem autoridade sobre como o processo do trabalho está caminhando. Suas principais funções são (1) garantir que os valores e práticas do Scrum estão sendo seguidos durante o trabalho, (2) remover quais impedimentos que surjam durante o trabalho do Time e (3) facilitar o trabalho do Time junto com o P.O.
Time Scrum: Todos que trabalham em efetivamente construir o projeto. Trabalham em conjunto, fazendo de tudo a seu alcance para conseguir entregar tudo que foi acordado para aquela Sprint. Sem hierarquia, sem tarefas fechadas, mas com trabalhos de duração definida e designado a cada um dos membros. Em suma, é um grupo de pessoas trabalhado a cumprir um objetivo: fechar a Sprint com sucesso.
Eventos
Sprint: O Scrum baseia-se na ideia de que o projeto será finalizado após uma sequência de Sprints. As Sprints são prazos de trabalho que variam de 1 semana a 1 mês – 2 semanas sendo a duração mais comum. Nelas, o Time tem que, quase que obrigatoriamente, dar um jeito de cumprir com o conjunto de tarefas planejados para aquele período de tempo.
Ao término de toda a Sprint, com o trabalho realizado e os entregáveis resultantes desse determinado período de tempo, deve-se ter um incremento no produto/projeto que, caso necessário, poderia ser lançado/colocado em prática. A ideia por trás disso é uma consequência dos princípios ágeis: devemos construir produtos incrementais, para serem testados e validados continuamente ao longo do processo, ao invés de continuamente fazermos incrementos no produto para testá-lo e validá-lo ao final, quando as mudanças serão: (1) maiores (devido a maior divergência entre o entregável desejado e o realizado); (2) mais custosas, pois exigirão retrabalho e alterações naquilo que já estava pronto (é estimado pelo Google que uma alteração no escopo após ter escrito uma linha de código é cerca de 1.000x mais cara que qualquer mudança antes alteração antes da etapa de desenvolvimento) e (3) resultarão em atraso (por estar-se muito próximo da deadline).
Sprint Planning: O momento que antecede uma Sprint. Nessa cerimônia, todos os membros (Product Owner, Scrum Master e Time) se reúnem para priorizar as tarefas em termos de dificuldade na execução e valor para usuário. Em seguida, são escolhidas aquelas que devem ser realizadas na próxima Sprint.
Daily Scrum: É o evento responsável por manter uma sincronia no trabalho de todos envolvidos no projeto. Uma reunião diária com, novamente, todos os participantes que não deve durar mais que 15 minutos – inclusive é sugerido que ocorra de pé (para ninguém se acomodar) ou com prazo definido por uma xícara de café – onde são abordados 3 pontos:
1. O que os membros do time fizeram hoje?
2. O que os membros do time farão amanhã?
3. Houve algum impedimento para a realização do trabalho? Se sim, o quê?
Caso tenha havido algum impedimento no trabalho dos membros do time, a responsabilidade recai sobre o Scrum Master para conseguir “destravar” essa tarefa. Como facilitador do processo Scrum, é sua função principal garantir um fluxo contínuo de trabalho.
Sprint Review e Retrospective: Reunião de fechamento da Sprint ocorrida. Ela é dividida em 2 partes:
Sprint Review (Revisão da Sprint): apresenta-se, ao Product Owner, os entregáveis acordados e são coletados quaisquer feedbacks para ajustes necessários.
Sprint Retrospective (Retrospectiva da Sprint): logo em seguida da Sprint Review, ocorre a análise de como o trabalho ocorreu e são discutidas ideias para melhorias dos processos para as Sprints seguintes. Aqui, cada membro do Time Scrum especifica ações e comportamentos que os membros do Time devem:
– Começar a fazer
– Para de fazer
– Continuar a fazer no decorrer do trabalho do projeto.
Artefatos
Product Backlog: o Backlog de um produto/projeto é uma lista de funcionalidades (software) ou entregáveis (geral) priorizadas, contendo breves descrições curtas de tudo que se imagina compor o produto/projeto final.
Ao aplicar o Scrum, não é necessário iniciar um projeto com um longo e antecipado esforço para documentar todos os requisitos – por, como já discutido no 1º artigo, alterações de escopo ocorrerem com frequência no decorrer do desenvolvimento. Normalmente, o Time Scrum e o Product Owner começam por escrever tudo o que eles podem pensar para a priorização do Backlog.
Com agilidade, essa 1ª versão do Product Backlog é quase sempre mais do que suficiente para rodar uma primeira Sprint. A partir disso, o Backlog do produto/projeto é então permitido crescer e mudar à medida que se aprende mais sobre o entregável final desejado e seus clientes/stakeholders.
Sprint Backlog: é a lista de entregáveis que devem estar entregues ao término da Sprint, sendo estes pedaços selecionados do Product Backlog e atribuídos para o trabalho corrente. O Sprint Backlog deve ser escolhido cuidadosamente em termos de complexidade e valor criado pelos entregáveis: é aconselhável que se cada sub-Backlog criado (para cada Sprint) mantenha uma constante de esforço/valor criado por Sprint realizada, garantindo que não haverá (1) ociosidade do time e (2) excesso de trabalho – resultando, muitas vezes, em atrasos – em nenhuma Sprint do processo.
Exemplo do Funcionamento:
No diagrama acima vemos claramente como funciona o framework de trabalho Scrum.
1. Selecionamos 1 Product Owner, 1 Scrum Master e o Time Scrum para o trabalho.
2. Montamos o Product Backlog e priorizamos os itens componentes
3. Fazemos a Sprint Planning, na qual definimos sua duração e quais itens estarão entregues ao término dela (Sprint Backlog).
4. Durante a Sprint, realiza-se o trabalho e, diariamente, ocorrem reuniões breves (Daily Scrum) para manter a sincronia e sinergia entre as tarefas.
5. Ao término da Sprint, faz-se a Sprint Review, na qual apresenta-se o produto – que deve ser possível de ser testado e avaliado – ao Product Owner, clientes e outros stakeholders envolvidos.
6. Faz-se uma Sprint Retrospective, na qual todos os agentes envolvidos na execução do trabalho avaliam os processos atuais e sugerem melhorias para as Sprints subsequentes.
7. Repete-se o processo a partir do (2), fazendo quaisquer alterações necessárias no Backlog que surgirem, até que a última Sprint ocorra e o produto/projeto esteja finalizado.
De maneira superficial, esse é o Scrum. Existem livros e enormes bibliografias que abordam a sua completude e alguns pontos não citados no artigo, mas muito úteis e interessantes também.
(Exemplo de cerimônias e artefatos que integram o Scrum e não foram mencionados: Planning Poker e Burndown Chart
Mas, com o que foi citado, você já pôde entender bem mais sobre esse inovador método de trabalho e, se quiser, optar por implementar ou não essa ferramenta no seu ambiente de trabalho.
No próximo artigo, vamos apresentar um passo a passo de como implementar o Scrum na sua organização.
Acompanhe o especial para se informar mais!