Caracter´ısticas Principais

O Scrum emprega um processo iterativo e incremental estruturado em em ciclos chama- dos de Sprint. A Sprint ´e uma itera¸c˜ao, ou seja, um espa¸co de tempo fixo, onde ocorre a aplica¸c˜ao de esfor¸cos visando a entrega de uma parcela funcional do produto. No in´ıcio de cada itera¸c˜ao o time revisa o que dever´a realizar e ent˜ao seleciona os requisitos que acre- dita poder transformar em um incremento, ou funcionalidade potencialmente utiliz´avel ao fim da itera¸c˜ao. O time ent˜ao coletivamente decide qual a melhor forma para realizar o trabalho planejado para a Sprint, analisando aspectos como requisitos, tecnologia e habi- lidades dos membros. Esta abordagem ´e adaptada e modificada diariamente, na medida em que novas complexidades, dificuldades ou surpresas s˜ao encontradas no caminho ao longo da itera¸c˜ao. Ao final da itera¸c˜ao, o time apresenta os incrementos constru´ıdos para que os stakeholders possam inspecionar e realizar adapta¸c˜oes ao projeto.

conhecimento seja originado da experiˆencia e que decis˜oes sejam tomadas com base no que ´e conhecido, buscando controlar riscos e otimizar a previsibilidade no projeto.

O Scrum n˜ao provˆe t´ecnicas espec´ıficas para construir produtos, mas uma estrutura na qual diversas t´ecnicas e processos podem ser aplicados. Portanto, as implementa¸c˜oes do Scrum podem variar em diferentes projetos (GIROT, 2013). Todavia, recomenda-se que as implementa¸c˜oes do Scrum sejam adaptadas de acordo com a situa¸c˜ao apenas ap´os o Scrum ser implementado de forma integral. As regras do Scrum s˜ao definidas e mantidas oficialmente por seus criadores no Guia do Scrum (SCHWABER; SUTHERLAND, 2013).

A Figura 6 ilustra o ciclo de funcionamento do processo. Os papeis, eventos e artefatos do processo s˜ao descritos nas se¸c˜oes posteriores.

Figura 6: Processo Scrum. Fonte: Adaptado de (SUTHERLAND; SCHWABER, 2007)

3.3.3

Papeis

S˜ao definidos trˆes pap´eis no Scrum, cada qual com sua fun¸c˜ao especifica dentro da equipe. S˜ao eles:

• Product owner : O Product Owner tem a responsabilidade de maximizar o valor de neg´ocio produzido pelo time, mantendo e priorizando os itens no backlog de pro- duto e regularmente reportando o status do produto aos interessados. Geralmente este papel ´e desempenhado pelo pr´oprio cliente ou algu´em designado, que possua conhecimentos abrangentes sobre o neg´ocio (SCHWABER, 2004).

• Scrum master: ´E uma esp´ecie de gerente de projetos, facilitador e mediador. Seu papel ´e remover obst´aculos da equipe e assegurar que as pr´aticas de Scrum est˜ao sendo executadas com eficiˆencia. O Scrum master deve servir o time de desen- volvimento, o Product Owner e a organiza¸c˜ao, facilitando o processo e alinhando interesses (SCHWABER; SUTHERLAND, 2013).

• Time de desenvolvimento: Time formado por um grupo de 5 a 9 pessoas e que ´

e respons´avel por converter os itens do backlog em incrementos, ou solu¸c˜oes. O time de desenvolvimento trabalha de forma auto-gerenciada, nem mesmo o Scrum Master deve dizer ao time de desenvolvimento como trabalhar (SUTHERLAND; SCHWABER, 2007). O time de desenvolvimento deve ser multifuncional, possuindo todas as habilidades necess´arias para criar um incremento do produto.

O Scrum n˜ao reconhece nenhum outro papel ou sub-times em suas equipes. A existˆencia de papeis ou t´ıtulos espec´ıficos no time de desenvolvimento, como testadores, analistas de neg´ocio ou desenvolvedores, pode prejudicar a colabora¸c˜ao entre os membros (SCHWABER, 2004).

3.3.4

Eventos

O framework Scrum define eventos fixos que s˜ao utilizados para criar regularidade e minimizar a necessidade de reuni˜oes adicionais n˜ao definidas pelo framework. Todos os eventos do framework tˆem dura¸c˜oes m´axima pr´e-definidas (time-boxing). De acordo com Schwaber e Sutherland (2013), os eventos s˜ao especificamente designados para promover a transparˆencia e a inspe¸c˜ao do processo. Portanto, caso alguns dos eventos n˜ao seja executado, o processo ´e diretamente afetado.

3.3.4.1 Sprint

Considerada como o cora¸c˜ao do framework, a Sprint ´e uma itera¸c˜ao, ou seja, um espa¸co de tempo onde ocorre a aplica¸c˜ao de esfor¸cos visando a entrega de uma parcela do produto. A Sprint tem um intervalo de tempo fixo, seu t´ermino n˜ao pode ser adiantado ou adiado. De acordo com as regras definidas pelo Scrum, a Sprint deve ter dura¸c˜ao de duas a quatro semanas e deve ter como objetivo principal o desenvolvimento de uma parte do produto potencialmente utiliz´avel (SCHWABER, 2004).

Uma nova Sprint ´e iniciada imediatamente ap´os o t´ermino da Sprint anterior. A ideia ´e que novas itera¸c˜oes sejam executadas at´e a conclus˜ao dos itens no backlog do produto, que consiste em uma lista de requisitos planejados para o projeto.

A itera¸c˜ao deve ser guiada por um objetivo de Sprint (Sprint Goal ), que ´e utilizado para definir o que ser´a alcan¸cado na Sprint atrav´es da implementa¸c˜ao dos itens selecionados. Este objetivo ´e utilizado para orientar as decis˜oes do time em rela¸c˜ao ao trabalho realizado na itera¸c˜ao.

3.3.4.2 Reuni˜ao de Planejamento da Sprint

A reuni˜ao de planejamento da Sprint ocorre no inicio de cada itera¸c˜ao. Neste evento, s˜ao discutidos dois principais t´opicos:

• O que pode ser realizado na Sprint Atual? Nesta etapa inicial o Product Ow- ner explica ao time os itens no backlog do produto, incluindo requisitos de neg´ocio, demandas t´ecnicas, entre outros itens. A partir das informa¸c˜oes apresentadas, o Product Owner e o time coletivamente definem as funcionalidades que ser˜ao imple- mentadas na Sprint, cunhando tamb´em um objetivo para a Sprint em rela¸c˜ao ao produto/projeto (SCHWABER; SUTHERLAND, 2013).

• Como o trabalho selecionado ser´a realizado? Ap´os o time obter uma clara vis˜ao do que deve ser realizado, os membros do time de desenvolvimento se reunem para elaborar um plano inicial para o desenvolvimento dos itens. Ao final deste evento, o time dever´a ser capaz de explicar ao Product Owner e ao Scrum Master como pretende trabalhar como um time auto-organizado para alcan¸car o objetivo da Sprint definido na etapa anterior (SCHWABER, 2004).

Este evento tem dura¸c˜ao m´axima de 8 horas para Sprints com dura¸c˜ao de um mˆes. Para Sprints mais curtas, o evento ´e geralmente realizado em um tempo menor (SCHWABER; SUTHERLAND, 2013).

3.3.4.3 Reuni˜ao Di´aria

A reuni˜ao di´aria ´e um evento com dura¸c˜ao m´axima de 15 minutos que tem como prop´osito sincronizar o progresso do trabalho dos membros do time e ressaltar impedimentos ou barreiras que foram encontradas durante o desenvolvimento dos incrementos. Esta reuni˜ao deve ser utilizada para inspecionar o progresso do time em rela¸c˜ao ao objetivo da Sprint e aos itens presentes no backlog da Sprint (SCHWABER, 2004).

De acordo com Schwaber e Sutherland (2013), a reuni˜ao di´aria ´e um elemento chave da inspe¸c˜ao e adapta¸c˜ao, podendo promover uma melhor comunica¸c˜ao, eliminar a necessidade de reuni˜oes adicionais, identificar impedimentos e aprimorar o n´ıvel de conhecimento do time de desenvolvimento. Apenas o time de desenvolvimento deve participar desta reuni˜ao, visando promover a auto-organiza¸c˜ao e impedindo interferˆencias externas.

3.3.4.4 Reuni˜ao de Revis˜ao da Sprint

Ao final de cada itera¸c˜ao, uma reuni˜ao de revis˜ao da Sprint ´e realizada para inspecionar o incremento e adaptar o backlog do produto, se necess´ario. Esta ´e uma reuni˜ao informal com dura¸c˜ao m´axima de quatro horas para Sprints de um mˆes e que tem como objetivo apresentar ao Product Owner e aos stakeholders relevantes os itens realizados na Sprint, com objetivo de elicitar feedback e promover a colabora¸c˜ao (SCHWABER; SUTHERLAND, 2013). De acordo com Cervone (2011), a revis˜ao da Sprint n˜ao deve ser uma reuni˜ao de status ou reuni˜ao formal de acompanhamento de projetos.

3.3.4.5 Reuni˜ao de Retrospectiva da Sprint

Ap´os a revis˜ao da Sprint e antes do planejamento da pr´oxima Sprint, uma reuni˜ao de retrospectiva ´e realizada. Esta ´e uma reuni˜ao de auto-inspe¸c˜ao, com dura¸c˜ao m´axima de trˆes horas para Sprints com um mˆes de dura¸c˜ao, utilizada para revisar o processo de desenvolvimento do time, incluindo aspectos como ferramentas, relacionamentos e poss´ıveis melhorias (SCHWABER; SUTHERLAND, 2013).

3.3.5

Artefatos

Os artefatos do Scrum s˜ao utilizados para promover transparˆencia no processo e oportu- nidades de inspe¸c˜ao e adapta¸c˜ao (SCHWABER; SUTHERLAND, 2013). Tais artefatos s˜ao descritos a seguir:

• Backlog do Produto: Uma lista de requisitos funcionais e n˜ao funcionais que s˜ao necess´arios para desenvolver o produto. De acordo com Cervone (2011), ´e um arte- fato constantemente atualizado que reflete as necessidades de neg´ocio e a evolu¸c˜ao do conhecimento por parte dos stakeholders. De acordo com as regras do Scrum, o backlog deve ser a ´unica fonte de requisitos para qualquer mudan¸ca realizada no produto. (SCHWABER; SUTHERLAND, 2013).

• Backlog da Sprint: O backlog da Sprint ´e um conjunto de itens do backlog de produtos selecionados para serem implementados na Sprint em execu¸c˜ao. Este artefato deve conter um breve plano para a entrega dos incrementos de produto e realiza¸c˜ao do objetivo da Sprint. Ao contr´ario do backlog do produto, mantido pelo Product Owner, este artefato ´e gerenciado e ordenado pelo time de desenvolvimento. O backlog da Sprint promove transparˆencia no processo, de forma que representa

uma figura atualizada do trabalho que o time de desenvolvimento pretende alcan¸car na Sprint.

• Incremento: O incremento ´e a soma de todos os itens do backlog do produto completados durante uma Sprint. Ao final da Sprint o incremento deve estar em condi¸c˜ao de ser utilizado, atendendo aos crit´erios da Defini¸c˜ao de Pronto definida pelo time.