Usando metodologia ágil na vida — PARTE II: até que enfim vamos falar de SCRUM!
Hey kids!
Muito bem… na PARTE I dessa série de posts eu abri meu coração para vocês e contei toda a bagunça que a minha vida estava e porque eu resolvi que precisava de uma maneira de gerenciar meus objetivos pessoais para não me perder (de novo!). Na parte II — essa que estou escrevendo agora — eu vou contar um pouco sobre SCRUM, algumas curiosidades, papéis, cerimônias, etapas, documentos e etc. Então se você já conhece SCRUM e não quer ver as curiosidades que têm no post, aguarde a PARTE III (que deve sair até o sábado).
OBS:. se quiser ver as curiosidades, é só dar um “Ctrl+F” e digitar “curiosidade” porque eu deixei marcadinho caso você queira ler ;)
Antes de continuar eu gostaria que vocês fizessem um minuto de silêncio para meu “foco” que deve estar morto, pois sabe-se lá Deus como eu fui parar nesse vídeo aqui (quando estava procurando imagens para ilustrar o blog, antes de começar a escrever):
Agora vamos fazer como a bruxa do pica-pau e…
Primeira curiosidade: a ideia do SCRUM é de 1986:
Se você já ouviu falar de SCRUM alguma vez na vida, já ouviu falar no Jeff Sutherland e no Ken Schwaber. São os criadores do SCRUM… mas o que pode ser que você não saiba é que a ideia da ‘metodologia’ foi baseada em um artigo de 1986, escrito por de dois professores japoneses.
O Jeff e sua equipe da época estavam pesquisando como aumentar a produtividade da equipe. Em meio às pesquisas, um dos membros se deparou com um artigo* publicado na Harvard Business Review (que pode ser lido na íntegra aqui), no qual os professores Hirotaka Takeuchi e Ikujiro Nonaka contavam que após uma análise feita em diversas empresas inovadoras da época, eles viram que o método cascata** para a produção de produtos era falho e que elas usavam um processo de desenvolvimento de “sobreposição”, que era mais rápido e flexível. Contam também que as equipes dessas empresas era multifuncionais e tinham automomia, objetivos ambiciosos e tentavam sempre se reiventar — queriam ser as melhores.
Observações:
*Só pra constar, eu não li o artigo ainda tá? Esse entendimento foi tirado de um livro do Jeff Sutherland (referências no final do post).
**Método cascata, para quem não sabe, é um “método” de condução de projetos no qual o projeto todinho é feito “em cascata” mesmo: primeiro analisa tudo, depois desenvolve tudo, depois testa tudo … e entrega tudo de uma vez (o que normalmente não acaba resultando em algo muito legal — RYSOS)
Pois bem. No artigo, os professores também comparam o trabalho da equipe a um time de rugby, e dizem que as melhores equipes agem como se houvesse um SCRUM — que no rugby, é aquele “montinho” que os dois times fazem se empurrando para uma determinada direção e com um objetivo em comum a todos: conseguir a posse de bola. Observação minha:
De verdade, na minha humilde opinião, o SCRUM faz a diferença justamente por isso: o time tem um objetivo claro, bem definido, e todo mundo está alinhado. Novamente, na minha humilde opinião, “o time” é um dos elementos mais importantes — se não o mais — para esse modelo de trabalho justamente porque ele está desalinhado, todo o resto desanda.
Uma coisa que me chamou a atenção é que esse artigo havia sido publicado em 1986, e até 1993 ninguém ainda tinha feito nada relacionado àquilo! 😱. “Esse foi o nascimento formal do Scrum” (frase extraída do capítulo 2 do livro do Jeff — “As origens do Scrum”).
Segunda curiosidade: O Jeff Sutherland usou a ideia de inspeção e adaptação no exército (antes que o SCRUM existisse)
Quando serviu o exército em West Point, o Jeff fez parte de um regimento (a Loose Deuce) que era sempre o último colocado na competição de formações na academia (imagino que deve ser aquele esquema de marchar, fazer aqueles movimentos sincronizados e tudo mais). Para tentar melhorar, ele — que era o oficial de treinamento — começou a fazer reuniões com os cadetes para mostrar o que tinha sido bom e para que todos vissem juntos no que eles poderiam melhorar. Algum tempo depois, eles ficaram em primeiro lugar depois de ser a última colocada por mais de um século. Leia aqui esse trechinho — tá no livro — que é bem interessante e emocionante :)
Beleza Mi, você falou um monte e ainda não começou a falar o que é o SCRUM, krai!
Tá! E afinal, o que é o SCRUM?
Se você, pequeno gafanhoto que não conhece SCRUM, procurar essa singela palavrinha no google, vai chover um caminhão de páginas para você consultar:
Mas se houver uma maneira de definir de resumir a “filosofia” por trás, eu diria que ele é o framework que une todos os princípios do manifesto ágil.
Mas que diabos é manifesto ágil?
É o manifesto escrito por vários autores no qual são valorizados 4 princípios:
- Individuos e interações
- Software em funcionamento
- Colaboração com o cliente
- Responder à mudanças
O SCRUM, é um framework de gerenciamento de projetos ágeis de forma leve, interativa e incremental que segue os princípios do manifesto ágil.
Ok, mas na prática, o que significa?
Significa que quando você usa o SCRUM no seu projeto, você vai ter entregas parciais. O exemplo clássico é: O cliente chega e diz que precisa de um veículo para se locomover. Quando ele apresenta essa necessidade, ele vai recebendo uma série de entregas:
Ou seja, o cliente não ficou lá 8 meses esperando o veículo dele sem ter absolutamente nada para usar. Ele foi recebendo entregas menores, usando, dando feedback, priorizando algumas coisas e despriorizando outras. Isso é chamado no SCRUM de inspeção e adaptação.
Tá, mas como funciona um projeto SCRUM na prática?
Vamos usar essa imagem aqui para falar dos elementos contidos dentro de um projeto SCRUM:
O SCRUM tem:
- Os papéis muito bem definidos
- Alguns artefatos “recomendados”
- Algumas cerimônias obrigatórias
- Algumas time-boxes (exemplo: sprint de “x” semanas)
Vamos falar de cada um deles:
Os papéis, de maneira macro, são:
— O Product Owner (Aquele que concebe a ideia / Recebe as ideias dos envolvidos)
O P.O. (como é carinhosamente chamado) é responsável por:
- Definir a visão do produto
- Elaborar e manter o product backlog
- Definir a prioridade dos itens do backlog (geralmente de acordo com o ROI — Return Of Investiment)
- Representar o “cliente” (interno ou final)
- Aceitar ou rejeitar os entregáveis
Não tem muito segredo. O P.O. é o cara que vai trazer as necessidades para o time. É um “papel” que tem que conhecer de negócio, saber qual é a visão final do produto,
— O Scrum Master (Aquele que tira tudo do caminho tudo que impede as engrenagens de rodarem)
O SM por sua vez responsável por:
- Ser um líder (ser referência)
- Remover impedimentos
- Proteger a equipe
- Ajudar o P.O.
- Ser o facilitador da equipe
- Garantir as práticas do SCRUM
O SM é o cara que vai tirar os impedimentos e ajudar a roda a girar. Vou fazer uma analogia aqui: Se o time fosse um ventilador que não está conseguindo girar a hélice (buscar seu objetivo), o SM é o cara que vai tirar a poeira das engrenagens para ajudar a hélice a rodar :)
— O time (Aqueles que rodam as engrenagens — ou fazem os ventiladores)
O time é a galera que mete a mão na massa e faz a coisa acontecer minha gente! Novamente, na minha humilde opinião, o elemento mais importante do SCRUM é o time (isso euzinha, Mi, falando).
Nossa Mi mas porque?
Porque se o time não estiver alinhado, for comprometido, entrosado, você pode ter o PO e o SM que for, que o trem não vai andar cara. Isso tô falando por experiências pessoais e trocas de figurinhas com outras pessoas.
Enfim… o time é responsável por:
- Fazer a estimativa
- Definir as tarefas
- Desenvolver o produto
- Garantir a qualidade do produto
- Apresentar o produto para o cliente
Ele também deve ser autogerenciável e multifuncional.
E os demais envolvidos? (Aqueles que às vezes só aparecem para cobrar — RYSOS)
Cara, em algumas literaturas sobre SCRUM eles sequer aparecem, mas eles tão aí na figura então vamos falar deles vai… (Mintiiiiiiiiira que eles são importantes também — RYSOS).
A gente sabe que na prática muitas vezes esses caras trazem insumos para garantir a visão do produto (eu mesma sou PO de um time ágil, mas recebo pedidos / insumos de vááárias pessoas — RYSOS). Eles não tem um papel ativo na metodologia, mas acho que o que vale ressaltar aqui (em letras garrafais — e que vale principalmente para SMs e para POs) é:
NÃO DEIXE OS ENVOLVIDOS INTERROMPEREM O TIME
Entenderam? Vou falar de novo:
NÃO DEIXE OS ENVOLVIDOS INTERROMPEREM O TIME!
Se você por acaso está num time ágil e tem gente de fora te impactando, PELOAMORDEDEUS, pare o que você está fazendo e
FALE COM SEU SM AGORA MESMO! RYSOS.
Mas e as cerimônias e artefatos?
Pois é… depois de muito escrever e re-escrever, acabei achando um site bacanudo onde você pode ler o que os especialistas falam (é de uma consultoria de treinamento de metodologias ágeis!). Dá uma olhada aqui:
É bem didático e certamente eles vão explicar isso muito melhor do que eu — RYSOS.
Agora deixa eu ver como está minha meta porque estou na metade do meu sprint e acho que não fiz nem metade do que deveria — RYSOS.
Arrivederci,
Mi
Fontes:
http://www.knowledge21.com.br/sobreagilidade/user-stories/como-e-user-story/ (acessada em:12/12/17–20:01)
http://www.knowledge21.com.br/sobreagilidade/scrum/ (acessada em:12/12/17–20:32)
http://www.manifestoagil.com.br/ (acessada em: 04/12/17–22:03)
http://www.desenvolvimentoagil.com.br/scrum/ (acessada em: 04/12/17–19:45)
Scrum_Revealed_by_International_Scrum_Institute — livro
Scrum — a arte de fazer o dobro do trabalho na metade do tempo — livro
SCRUM experience — livro
Imagens:
http://slideplayer.com.br/slide/293289/1/images/9/Ciclo+de+Vida+do+SCRUM.jpg (acessada em: 04/12/17–22:30)
