contratada por uma lanchonete de disk-crepes. A lanchonete, cujo dono é o Carlos,
precisa automatizar seu modo de venda: além do telefone, quer vender por um site
responsivo, receber os pedidos em tempo real e mostrar um status ao cliente. A SD4 é
composta por quatro empregados: Milan, Lara, Leo e João. Nenhum deles possuía
experiência com venda online, sentiram necessidade de mais ordem dali em diante e
Milan se encarregou de buscar um método que ajudasse sua equipe, escolhendo o
Scrum. O Scrum é um framework ágil para gerenciamento, planejado para ser simples e
efetivo, ao mesmo tempo que pode ser aplicado a projetos de pequenos a complexos,
sejam da área de Tecnologia da Informação ou de outras formas de desenvolvimento. Seu
nome foi emprestado de uma formação do rugby, esporte fundamentado em organização
e cooperação entre o time. Atualmente é a metodologia ágil mais utilizada em processos
de desenvolvimento de software.
Em 1986, Takeuchi e Nonaka descreveram no artigo "The New Product
Development Game" que equipes reduzidas e multidisciplinares eram mais bem-
sucedidas na realização de projetos de novos produtos, ou seja, cujas tecnologias ainda
não eram totalmente compreendidas. Jeff Sutherland, John Scumniotales e Jeff McKenna,
aprimorando as técnicas relatadas naquele artigo, documentaram o Scrum como se
conhece hoje em 1993, na empresa Easel Corporation, e em 1995 Ken Schwaber a
formalizou e implantou no desenvolvimento de software.
O Scrum é embasado na teoria empírica. O empirismo afirma que o conhecimento
é adquirido por meio da experiência e deve-se fazer escolhas considerando o que já se
conhece. Isso o torna extremamente adaptável a situações distintas, não tendo muitos
detalhes pré-estabelecidos, apenas uma visão geral de regras e valores. São eles os
princípios, papéis, artefatos e eventos.
•Princípios
Transparência: Aspectos importantes do projeto como status, requisitos e processos
devem ser compreendíveis e estarem à mostra de todos os envolvidos. Para terem esse
entendimento em comum, é preciso que hajam padrões bem definidos para a maneira de
representar, certificando-se que todos entendam aquela maneira, como por exemplo,
todos na SD4 utilizarem a mesma linguagem de programação.
Inspeção: Frequentemente, os envolvidos devem checar o progresso e os artefatos
(resultados de cada processo), com objetivo de encontrar possíveis deslizes, mas não
podem chegar a ponto de atrapalhar o andamento do trabalho. Assim, a equipe entre si
confere se tudo está indo como o esperado, e pode impedir que pequenas falhas
aumentem no futuro.
Adaptação: Como já foi mencionado, o Scrum almeja ser maleável para aplicações de
toda forma. Além disso, se um inspetor decidir que algo está saindo dos limites e pode
prejudicar a entrega do sprint, é necessária uma adaptação no projeto que resolva o
conflito, assim como quando o product owner decide que precisa alterar os requisitos
originais. Elas devem ser aplicadas o quanto antes, a fim de minimizar dificuldades. Os
eventos formalizados no Scrum são dedicados a essas adaptações onde se mostrar
preciso.
•Equipe/Papéis
Product Owner: Responsável por transmitir de maneira mais clara que puder ao restante
do grupo quais são os objetivos, ou seja, especificar o produto e em qual ordem de
prioridade, e também indicar se deve haver alguma mudança nos requisitos. Ele deve ter
conhecimento aprofundado na área para qual o software está sendo desenvolvido, de
modo que possa auxiliar o time nos detalhes técnicos. Ele faz parte da equipe e portanto
deve se apresentar diariamente para acompanhar o andamento. Carlos, por ter
funcionários que cuidem da lanchonete por ele, se prontificou como product owner.
Scrum Master: Espécie de coach que conhece bem a fundo as práticas e filosofias da
metodologia, fazendo questão de que todos entendam e sigam-na da maneira certa, e
ajudando a equipe a moldar o Scrum para suas necessidades específicas. Pode ser
considerado o líder por estar à disposição da equipe e ser o principal ponto de contato
com o product owner, mas nunca chefe, pois o time deve ser autônomo. Milan é o Scrum
Master, tendo pesquisado a fundo o Scrum e se responsabilizado por repassar as
informações para seus colegas e Carlos.
Time: Em outras metodologias, são os chamados programadores. O time Scrum é o
grupo de pessoas que realmente irão criar o projeto, neste caso, todos na SD4 são um
time só. Eles não devem ser divididos por especialidades e sim compartilhar um
conhecimento amplo de programação para que possam ter uma interação melhor e maior
aproveitamento do tempo disponível. Desta forma, não devem agarrar-se a títulos, se o
Leo é mais especializado em testes do que os outros e não houverem testes a fazer, ele
deve desenvolver código. A palavra-chave aqui é a auto-organização: o time deve decidir
o modo mais proveitoso de se executar cada tarefa, ao invés de algum tipo de gerente,
pois são eles mesmos quem mais conhecem os funcionamentos. Resolveram adotar a
programação em pares, Milan com Lara e João com Leo, que é uma prática do eXtreme
Programming mas frequentemente misturada com o Scrum por sua eficiência provada.
• Eventos
Visão do Produto: Primeira reunião onde o Product Owner explica como deseja seu
software, quais devem ser as metas e funcionalidades que o Time deve alcançar. Esta
visão pode ser documentada da maneira que preferirem, como um pequeno texto. Milan,
o Scrum Master, ajuda Carlos a organizar estas funcionalidades, também chamadas
casos de uso, em uma lista no Excel que vai das essenciais para importantes e enfim
desejáveis conforme sua prioridade. Tal lista no contexto Scrum é o artefato Product
Backlog, que servirá como principal guia para o andamento do projeto.
menos, é possível alterar o Product Backlog, como adicionar um item da lista. Este item
deve ser posicionado em sua devida prioridade.
Sprint Planning: Nesta etapa, que tem no máximo 8 horas no total para sprints de um
mês, são discutidos quais itens do Product Backlog devem ser feitos na iteração (sprint)
que sucederá. Em outras palavras, quantas funcionalidades poderão ser criadas no tempo
do sprint com base na capacidade do Time, além de entrar em maiores detalhes de cada
uma. O resultado do Sprint Planning é o artefato Sprint Backlog, que nada mais é do que
uma pequena porção do Product Backlog.
Sprint: Período no qual o Time irá desenvolver o Sprint Backlog, obrigatoriamente time-
boxed: os sprints de um mesmo projeto devem ter a mesma duração, entre duas a quatro
semanas. O mais comum é ter três semanas, 15 dias úteis, como no caso do projeto da
lanchonete do Carlos. Ao final do sprint é entregue um incremento usável do software e
imediatamente inicia-se o próximo, voltando à etapa do Sprint Planning. A vantagem de
priorizar entregas frequentes e parcialmente úteis no lugar de todo o programa
funcionando como planejado nos requisitos iniciais é poder observar como o usuário final
e o Product Owner avaliam estas versões beta, poder corrigir e embarcar casos
inesperados e ao final do processo entregar um software de maior valor.
Daily Scrum: Reunião diária de cerca de 15 minutos, sempre no mesmo local e horário,
durante o sprint e com todos os integrantes da equipe. Cada membro do time responderá
três perguntas básicas:
1. O que fiz ontem?
2. O que farei hoje?
3. Há algo me impedindo de atingir as expectativas?
Respondidas, todos podem visualizar bem como vai o andamento do sprint.
Revisão do Sprint: Apresenta-se aquilo que foi feito durante o sprint, se está de acordo
com o esperado. Nesta reunião, que tem uma duração máxima de quatro horas para
sprints de um mês, o Product Owner verifica quais funcionalidades estão prontas, e se há
a necessidade de alterar o Product Backlog. Seu objetivo é, em resumo, validar e adaptar
o produto que está sendo construído, e o resultado normalmente é um Product Backlog
adaptado à situação atual.
Retrospectiva do Sprint: É uma reunião focada para o Time avaliar a si mesmo. Tem
como objetivo verificar se há necessidade de alterações no processo de desenvolvimento,
práticas que não foram bem aplicadas e devem receber mais atenção, por exemplo, ou
que não deveriam ser feitas. Inspeciona-se como foi o decorrer do sprint quanto a
ferramentas, relações, pessoas e processos, identifica-se o que foi bem e pode ser uma
melhoria em potencial e ao fim definem como o próximo sprint pode ser melhorado.
Referências
I. The Scrum Guide. Em: <https://www.scrumalliance.org/why-scrum/scrum-guide>.
Acesso em: 06 de Março de 2017.
II. Scrum – Aprenda Scrum em 9 Minutos. Em: <https://www.youtube.com/watch?
v=XfvQWnRgxG0>. Acesso em: 06 de Março de 2017.
III. Métodos Ágeis: Scrum. Em:
<https://www.oficinadanet.com.br/artigo/1971/metodos_ageis_scrum>. Acesso em:
06 de Março de 2017.
Nenhum comentário:
Postar um comentário