Scrum – gestão e planejamento de projetos de software

Acabei lendo um pouco sobre desenvolvimento de softwares de reconhecimento de imagens enquanto estava tentando descobrir se é viável identificar padrões no “código-fonte” (nem sei se é exatamente este o nome) de imagens JPEG para usar como critério de semelhança de imagem. Bom, ainda não quitei a minha dúvida, mas esbarrei num assunto que me interessou: o “framework” Scrum.

Na minha prática, quase tudo dele é demais, pois não sou desenvolvedor de softwares. Contudo, para alguém, como eu, cujo trabalho é oferecer “soluções para arquivos”, o Scrum fornece algumas ideias interessantes como, por exemplo modelo de Backlog do produto, ou como organizar uma equipe para bolar soluções sob pressão. Eu sempre descrevo/organizo minhas intervenções por meio de algo inspirado no 5W2H, mas o “Backlog do produto” parece mais acertado quando for necessário anotar e seguir exigências para aplicatições (e não serviços).

“O SCRUM é uma metodologia de desenvolvimento ágil e flexível. Tem por objetivo definir um processo iterativo e incremental de desenvolvimento de produtos ou gestão de projetos. Produz um conjunto de funcionalidades potencialmente mais próximas do objetivo final no terminar de cada iteração (normalmente com uma duração de 30 dias). Centrado no trabalho em equipe, melhora a comunicação e maximiza a cooperação, permitindo que cada um faça o seu melhor e se sinta bem com o que faz, o que mais tarde se reflete em aumento de produtividade.” (BISSI, 2007, nas palavras de TOMASEL, 2014, p. 11)

“[…] SCRUM aplica-se a projetos tanto pequenos como grandes, esforçando-se para liberar o processo de quaisquer barreiras, o seu principal objetivo é conseguir uma avaliação correta do ambiente em evolução, adaptando-se constantemente ao “caos” de interesses e necessidades, indicado e utilizado para o desenvolvimento de softwares em ambientes complexos, onde os requisitos mudam com certa frequência, sendo o caminho utilizado para aumentar produtividade nesses tipos de sistemas.”  (BISSI, 2007, nas palavras de TOMASEL, 2014, p. 11).

Segue um esquema do fluxo do Scrum:

Fonte: 2Gather, Tecnologia, 2014 em: TOMASEL, 2014.

Fonte: 2Gather, Tecnologia, 2014 em: TOMASEL, 2014.

O framework é organizado pelas entidades “time Scrum” “eventos” e “artefatos”.

“O Time Scrum é composto pelo Product Owner, o Time de Desenvolvimento e o Scrum Master. Times Scrum são auto-organizáveis e multifuncionais. Times auto-organizáveis escolhem qual a melhor forma para completarem seu trabalho, em vez de serem dirigidos por outros de fora do Time. Times multifuncionais possuem todas as competências necessárias para completar o trabalho sem depender de outros que não fazem parte da equipe. O modelo de time no Scrum é projetado para aperfeiçoar a flexibilidade, criatividade e produtividade. Times Scrum entregam produtos de forma iterativa e incremental, maximizando as oportunidades de realimentação. Entregas incrementais de produto “Pronto” garantem que uma versão potencialmente funcional do produto do trabalho esteja sempre disponível.” (SCHWABER; SUTHERLAND, 2014, p. 5)

“Eventos prescritos são usados no Scrum para criar uma rotina e minimizar a necessidade de reuniões não definidas no Scrum. Todos os eventos são eventos time-boxed, de tal modo que todo evento tem uma duração máxima. Uma vez que a Sprint começa, sua duração é fixada e não pode ser reduzida ou aumentada. Os eventos restantes podem terminar sempre que o propósito do evento é alcançado, garantindo que uma quantidade adequada de tempo seja gasta sem permitir perdas no processo. Além da Sprint, que é um container para outros eventos, cada evento no Scrum é uma oportunidade de inspecionar e adaptar alguma coisa. Estes eventos são especificamente projetados para permitir uma transparência e inspeção criteriosa. A não inclusão de qualquer um dos eventos resultará na redução da transparência e da perda de oportunidade para inspecionar e adaptar”. (SCHWABER; SUTHERLAND, 2014, p. 8)

Os eventos são:

Sprint:

“O coração do Scrum é a Sprint, um time-boxed de um mês ou menos, durante o qual um “Pronto”, versão incremental potencialmente utilizável do produto, é criado. Sprints tem durações coerentes em todo o esforço de desenvolvimento. Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior.” (SCHWABER; SUTHERLAND, 2014, p. 8)

Reunião de planejamento da Sprint:

“Reunião de Planejamento da Sprint O trabalho a ser realizado na Sprint é planejado na reunião de planejamento da Sprint. Este plano é criado com o trabalho colaborativo de todo o Time Scrum. Reunião de planejamento da Sprint possui um time-box com no máximo oito horas para uma Sprint de um mês de duração. Para Sprints menores, este evento é usualmente menor. O Scrum Master garante que o evento ocorra e que os participantes entendam seu propósito. O Scrum Master ensina o Time Scrum a manter-se dentro dos limites do time-box. A reunião de planejamento da Sprint responde as seguintes questões:  

-O que pode ser entregue como resultado do incremento da próxima Sprint? 

-Como o trabalho necessário para entregar o incremento será realizado?” (SCHWABER; SUTHERLAND, 2014, p. 9)

Reunião diária:

“A Reunião Diária do Scrum é um evento time-boxed de 15 minutos, para que o Time de Desenvolvimento possa sincronizar as atividades e criar um plano para as próximas 24 horas. Esta reunião é feita para inspecionar o trabalho desde a última Reunião Diária, e prever o trabalho que deverá ser feito antes da próxima Reunião Diária. A Reunião Diária é mantida no mesmo horário e local todo dia para reduzir a complexidade. Durante a reunião os membros do Time de Desenvolvimento esclarecem: 

-O que eu fiz ontem que ajudou o Time de Desenvolvimento a atender a meta da Sprint? 

-O que eu farei hoje para ajudar o Time de Desenvolvimento atender a meta da Sprint? 

-Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no atendimento da meta da Sprint?” (SCHWABER; SUTHERLAND, 2014, p. 11)

Revisão da Sprint:

“A Revisão da Sprint é executada no final da Sprint para inspecionar o incremento e adaptar o Backlog do Produto se necessário. Durante a reunião de Revisão da Sprint o Time Scrum e as partes interessadas colaboram sobre o que foi feito na Sprint. Com base nisso e em qualquer mudança no Backlog do Produto durante a Sprint, os participantes colaboram nas próximas coisas que podem ser feitas para otimizar valor. Esta é uma reunião informal, não uma reunião de status, e a apresentação do incremento destina-se a motivar e obter comentários e promover a colaboração.” (SCHWABER; SUTHERLAND, 2014, p. 12)

“Esta é uma reunião time-boxed de 4 horas de duração para uma Sprint de um mês. Para Sprints menores, este evento é usualmente menor. O Scrum Master garante que o evento ocorra e que os participantes entendam o seu objetivo. O Scrum Master ensina a todos a manter a reunião dentro dos limites do Time-box. A Reunião de Revisão inclui os seguintes elementos: 

-Os participantes incluem o Time Scrum e os Stakeholders chaves convidados pelo Product Owner;

-O Product Owner esclarece quais itens do Backlog do Produto foram “Prontos” e quais não foram “Prontos”; 

-O Time de Desenvolvimento discute o que foi bem durante a Sprint, quais problemas ocorreram dentro da Sprint, e como estes problemas foram resolvidos; 

-O Time de Desenvolvimento demonstra o trabalho que está “Pronto” e responde as questões sobre o incremento; 

-O Product Owner discute o Backlog do Produto tal como está. Ele (ou ela) projeta as prováveis datas de conclusão baseado no progresso até a data (se necessário); 

-O grupo todo colabora sobre o que fazer a seguir, e é assim que a Reunião de Revisão da Sprint fornece valiosas entradas para a Reunião de Planejamento da próxima Sprint; 

-Análise de como o mercado ou o uso potencial do produto pode ter mudado e o que é a coisa mais importante a se fazer a seguir; e, 

-Análise da linha do tempo, orçamento, potenciais capacidades, e mercado para a próxima versão esperada do produto.

O resultado da Reunião de Revisão da Sprint é um Backlog do Produto revisado que define o provável Backlog do Produto para a próxima Sprint. O Backlog do Produto pode também ser ajustado completamente para atender novas oportunidades.” (SCHWABER; SUTHERLAND, 2014, p. 12)

Artefatos:

“Os artefatos do Scrum representam o trabalho ou o valor para o fornecimento de transparência e oportunidades para inspeção e adaptação. Os artefatos definidos para o Scrum são especificamente projetados para maximizar a transparência das informações chave de modo que todos tenham o mesmo entendimento dos artefatos.” (SCHWABER; SUTHERLAND, 2014, p. 13)

Backlog do produto:

“O Backlog do Produto é uma lista ordenada de tudo que deve ser necessário no produto, e é uma origem única dos requisitos para qualquer mudança a ser feita no produto. O Product Owner é responsável pelo Backlog do Produto, incluindo seu conteúdo, disponibilidade e ordenação. Um Backlog do Produto nunca está completo. Os primeiros desenvolvimentos apenas estabelecem os requisitos inicialmente conhecidos e melhor entendidos. O Backlog do Produto evolui tanto quanto o produto e o ambiente no qual ele será utilizado evoluem. O Backlog do Produto é dinâmico; mudando constantemente para identificar o que o produto necessita para ser mais apropriado, competitivo e útil. O Backlog do Produto existirá enquanto o produto também existir” ((SCHWABER; SUTHERLAND, 2014, p. 13)

 

Backlog da sprint:
“O Backlog da Sprint é um conjunto de itens do Backlog do Produto selecionados para a Sprint, juntamente com o plano para entregar o incremento do produto e atingir o objetivo da Sprint. O Backlog da Sprint é a previsão do Time de Desenvolvimento sobre qual funcionalidade estará no próximo incremento e sobre o trabalho necessário para entregar essa funcionalidade em um incremento ‘Pronto’.” ((SCHWABER; SUTHERLAND, 2014, p. 15)

 

Incremento:
“O incremento é a soma de todos os itens do Backlog do Produto completados durante a Sprint e o valor dos incrementos de todas as Sprints anteriores. Ao final da Sprint um novo incremento deve estar “Pronto”, o que significa que deve estar na condição utilizável e atender a definição de “Pronto” do Time Scrum. Este deve estar na condição utilizável independente do Product Owner decidir por liberá-lo realmente ou não.” (SCHWABER; SUTHERLAND, 2014, p. 15)

 

Referências utilizadas

SCHWABER, Ken; SUTHERLAND, Jeff. Guia do Scrum – Um guia definitivo para o Scrum: As regras do jogo. 2014 Online. Disponível em: <http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf&gt;. Acessado em: 29 jan. 2016.

TOMASEL, Tiago Souza. APLICATIVO DE RECONHECIMENTO DE IMAGENS EM DISPOSITIVOS MÓVEIS PARA AMBIENTES PREVIAMENTE MAPEADOS. Trabalho de conclusão de curso de graduação em Ciência da Computação – Ciência da Computação do Centro Universitário La Salle – Unilasalle. Disponível em <http://biblioteca.unilasalle.edu.br/docs_online/tcc/graduacao/ciencia_da_computacao/2014/tstomasel.pdf>. Acessado em: 29 jan. 2016.

 

Recursos sobre Scrum

https://www.scrumalliance.org/why-scrum

http://www.desenvolvimentoagil.com.br/scrum/

https://pt.wikipedia.org/wiki/Scrum

Scrum: A Metodologia Ágil Explicada de forma Definitiva

http://www.projectbuilder.com.br/blog-pb/entry/projetos/como-fazer-o-product-backlog

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s