SISTEMAS DE INFORMAÇÃO

JAILSON DE SOUSA MARQUES

IMPLANTAÇÃO E ANÁLISE DA EFICÁCIA DE UM MODELO ÁGIL DE PROCESSO NO DESENVOLVIMENTO DE ATIVIDADES ACADÊMICAS

Manaus

2013

JAILSON DE SOUSA MARQUES

IMPLANTAÇÃO E ANÁLISE DA EFICÁCIA DE UM MODELO ÁGIL DE PROCESSO NO DESENVOLVIMENTO DE ATIVIDADES ACADÊMICAS

Projeto de Pesquisa submetido ao corpo docente do Curso de Sistemas de Informação da Faculdade La Salle Manaus como parte dos requisitos para obtenção do grau de Bacharel em Sistemas de Informação.

Manaus

2013

SUMÁRIO

INTRODUÇÃO.......................................................................................................................................................3

PROJETO DE PESQUISA....................................................................................................................................4

1 TEMA....................................................................................................................................................................4

2 DELIMITAÇÃO DO TEMA..............................................................................................................................4

3 JUSTIFICATIVA.................................................................................................................................................4

4 PROBLEMA.........................................................................................................................................................4

5 HIPÓTESE...........................................................................................................................................................4

6 OBJETIVOS.........................................................................................................................................................5

6.1 OBJETIVO GERAL............................................................................................................................................56,2 OBJETIVOS ESPECÍFICOS.................................................................................................................................5

7 REFERENCIAL TEÓRICO...............................................................................................................................5

8 METODOLOGIA................................................................................................................................................9

9 CRONOGRAMA...............................................................................................................................................10

10 REFERENCIAS...............................................................................................................................................11

INTRODUÇÃO

O processo de desenvolvimento de software da forma como vem sendo

desenvolvido, apresenta uma série de problemas que impactam em atrasos e na sua utilidade,

e com a alta demanda por software e o tempo escasso para a sua entrega, muitas empresas

estão migrando do modo de desenvolvimento tradicional para metodologias ágeis com o

intuito de fornecer aos clientes softwares mais funcionais, com entregas frequentes e uma

maior flexibilidade às mudanças.

Para que as empresas consigam adaptar-se a esta nova realidade que vem surgindo

no processo de desenvolvimento de softwares, as mesmas precisam de egressos das

Universidades já familiarizados com estes novos métodos de desenvolvimento e não apenas

com as ferramentas para desenvolver.

Os problemas com o desenvolvimento de software parecem ter sua raiz nas

universidades uma vez que o desenvolvimento de atividades acadêmicas apresenta os mesmos

sintomas de atrasos, entregas em discordância do que foi solicitado e alterações nos requisitos

não são bem vindas.

Conhecendo estes problemas, e na busca de minimizá-los na área acadêmica e por

consequência na área profissional, o autor deste projeto se propõe a trazer o scrum (que

segundo Pressman (2006), se trata de um modelo ágil de processo utilizado para guiar

atividades de desenvolvimento) para a sala de aula, onde será implantado no desenvolvimento

de um software na disciplina de estagio II do curso de sistemas de informação da Faculdade

La Salle-Manaus, onde será analisada a sua eficácia.

4

PROJETO DE PESQUISA

1 TEMA

Utilização do modelo ágil de processo scrum no desenvolvimento de atividades

acadêmicas.

2 DELIMITAÇÃO DO TEMA

Implantação e análise da eficácia do modelo ágil de processo scrum no

desenvolvimento de atividade acadêmica realizada na disciplina Estágio II ofertada na

Faculdade La Salle-Manaus.

3 JUSTIFICATIVA

A forma como as atividades acadêmicas vem sendo desenvolvidas, em especial as

atividades de desenvolvimento de software, não apresentam um processo bem definido que

possa guiar os acadêmicos na busca de um bom resultado.

Com a implantação de um modelo ágil de processo no meio acadêmico, haverá uma

grande relevância para as áreas científica, pessoal e social.

No que se refere ao conhecimento científico, o projeto servirá de base para que as

instituições de ensino tenham um discernimento se realmente é útil implantar um modelo ágil no seu

método de ensino, de que forma devem implantar e quais as adaptações necessárias.

Em razão do autor do projeto estar cursando na área de tecnologia da informação, e que seu

curso tem como um dos pontos chave a gestão de projetos, o projeto contribuirá para que o autor possa

colocar em prática os conhecimentos adquiridos ao longo do curso.

Com a implantação deste modelo ágil, a sociedade será beneficiada na forma de que os

acadêmicos participantes da implantação do modelo ágil terão um método para o

desenvolvimento das suas atividades tanto acadêmicas quanto profissionais, as empresas

receberão egressos já familiarizados com um modelo ágil de processo, e caso este se mostre

eficaz, poderão fornecer um software útil e de forma pontual para a sociedade.

4 PROBLEMA

O uso de um modelo ágil é capaz propiciar aos acadêmicos do curso de sistemas de

informação uma maior organização, agilidade, pontualidade, flexibilidade, qualidade e

viabilidade no desenvolvimento das suas atividades no curso relacionadas a desenvolvimento

de software?

5

5 HIPÓTESE

Analisando as melhorias que os métodos ágeis têm trazido às empresas que

passaram a utilizá-lo nos seus processos, espera-se que da mesma forma os acadêmicos

apresentem uma evolução no modo de desenvolvimento das suas atividades acadêmicas

principalmente no que se refere á organização, agilidade, pontualidade e flexibilidade.

6 OBJETIVOS

6.1 Objetivo Geral

Implantar e analisar a eficácia da utilização do modelo ágil de processo scrum para os

acadêmicos de sistemas de informação no desenvolvimento das atividades do curso.

6.2 Objetivos Específicos

a) Realizar entrevista com acadêmicos que desenvolveram atividades na disciplina

Estágio I, onde não foi utilizado um modelo ágil;

b) Aplicar o modelo ágil scrum no desenvolvimento da atividade realizada na disciplina

Estágio II;

c) Entrevistar e analisar a opinião dos alunos envolvidos nas atividades sem a utilização

do modelo ágil na disciplina Estágio I, e com a utilização do modelo ágil na disciplina

Estágio II;

d) Apresentar os resultados da análise.

7 METODOLOGIA

O projeto será desenvolvido na Faculdade La Salle-Manaus, especificamente com os

alunos da disciplina de Estagio II do curso de sistemas de informação, o mesmo será realizado

ao longo de cinco meses aproximadamente que é o tempo de duração da disciplina.

A metodologia de pesquisa utilizada será do tipo: qualitativa, que de acordo com

Marconi e Lakatos (2008), o método qualitativo ao invés de utilizar instrumentos estatísticos

nas investigações científicas (como no método quantitativo), procura analisar e interpretar

aspectos que só podem ser percebidos com maior aprofundamento, busca descrever sobre o

6

comportamento humano, oferecendo maiores detalhes sobre as investigações, hábitos,

atitudes, tendências de comportamento etc.

Com base nos objetivos do projeto optou-se por realizar uma pesquisa do tipo

exploratória e os procedimentos técnicos serão delineados como pesquisa-ação que de acordo

com Thiorrente (1985) apud Gil (2002), é um tipo de pesquisa em que é realizada uma estreita

associação com uma ação ou com a resolução de um problema coletivo onde os pesquisadores

se envolvem na situação ou no problema de modo cooperativo ou participativo.

Para a coleta de dados serão realizadas entrevistas. Que é uma forma de obter

informações de determinado assunto, através da conversação entre duas pessoas de forma

profissional. Este procedimento é utilizado na investigação social, para coletar dados ou

auxiliar no diagnóstico ou no tratamento de um problema social. (LAKATOS; MARCONI,

1991).

A entrevista será do tipo não-padronizada, segundo Lakatos e Marconi(1991), Esta

forma de pesquisa dá ao entrevistador a liberdade de desenvolver cada situação em qualquer

direção que considerar adequada. Permite explorar mais amplamente uma questão.

Geralmente as perguntas são abertas e permitem ser respondidas em uma conversação

informal.

De acordo com Ander-egg (1978) apud Lakatos e Marconi(1991), a pesquisa não

padronizada apresenta três modalidades. e a modalidade utilizada será a entrevista focalizada,

onde existe um roteiro com tópicos relativos ao problema em questão, e dentro destes tópicos

o entrevistador faz as perguntas que convir, sonda razões e motivos, dá esclarecimentos. Não

obedecendo fielmente a uma estrutura formal.

Para que não corram o risco de passar despercebidas algumas afirmações dos

entrevistados, toda a entrevista será gravada por meio de um aparelho gravador de áudio.

Serão observados também aspectos como gestos e entonação de voz.

Será utilizada ainda a técnica de análise de conteúdo que segundo Bardin (1977) apud

Vergara (2008), se trata de técnicas voltadas para a análise das comunicações com o intuito de

obter indicadores que possibilitem inferir conhecimentos relativos as condições de

produção/recepção destas mensagens, utilizando para isto procedimentos sistemáticos e

objetivos que descrevem o conteúdo das mensagens.

Para guiar a entrevista será utilizado o seguinte formulário de questões:

1- Ao que se refere o projeto realizado?

2- Vem sendo utilizada alguma metodologia no desenvolvimento do projeto? Qual? (ágil,

tradicional)

7

3- Como está o cumprimento de prazos do projeto?

4- Com que frequência são apresentadas novas implementações no projeto?

5- Como está a organização da equipe?

6- Foram solicitadas da equipe alterações nos requisitos? De que forma foi aceito?

7- Você poderia citar alguns fatores que em sua opinião possam estar levando ao sucesso ou

fracasso deste projeto?

8 REFERENCIAL TEÓRICO

8.1 Dificuldades no Desenvolvimento de Software

De acordo com Geenfield (2004) a forma como o software vem sendo desenvolvido,

apresenta uma morosidade para a sua conclusão, requer muita despesa, e é grande a

possibilidade erros, ocorrendo de muitas vezes os produtos apresentarem grande numero de

defeitos sérios problemas com a usabilidade, confiabilidade, desempenho e segurança do

mesmo.

Com a crescente demanda de software, as empresas precisam completar mais projetos,

de forma mais rápida sem sacrificar a qualidade e utilizando poucos recursos.

Segundo Elder apud Retamal (2006) o gerenciamento de projetos sofre de cinco

doenças, são elas:

a. Prioridades que mudam constantemente (multitarefa nociva);

b. O tempo de segurança para o termino de uma tarefa é sempre inflacionado (lei de

Parkinson);

c. Adiar o trabalho para o ultimo momento possível (síndrome do estudante);

d. As tarefas começam no dia em que estiverem agendadas, e não quando as entradas

estiverem disponíveis (dependência entre tarefas);

e. Por mais que uma tarefa tenha sido terminada antes do prazo, a pessoa não terá

pressa para entregar, pois ainda está no prazo (2+2=5).

Analisando estas causas de problemas nos projetos, percebe-se uma nítida associação

com a situação da área acadêmica com relação à problemática no desenvolvimento das

atividades acadêmicas, como se as “doenças” citadas por Elder apud Retamal (2006) fossem

herdadas da vida acadêmica, trazendo uma conclusão de que os problemas devem ser

atacados na sua origem, na formação acadêmica.

8

8.2 Relacionamento entre Universidade e Mercado de Trabalho

Segundo Oliveira (2004), a relação da universidade com a sociedade está no fato de a

universidade prover a competência interna em prol do desenvolvimento da sociedade através

da produção cientifica, e a sociedade fornece parâmetros reais para que a universidade realize

novos estudos e proponha uma metodologia científica para novos parâmetros.

Figura 1 – Relacionamento entre Universidade e sociedade.

Fonte: Oliveira, 2004.

Um novo parâmetro que vem crescendo no desenvolvimento de software é a migração

das metodologias de desenvolvimento tradicionais para as metodologias ágeis e as

universidades precisam abranger estas novas metodologias para dar um retorno científico para

a sociedade em especial para o mercado de desenvolvimento de software.

De acordo com Cavalcante (2004) apud Oliveira (2004, p.2) A complexidade social no

Brasil exige muito mais que intenções pedagógicas em discursos acadêmicos sobre

transformações do real, têm exigido posturas e processos de formação acadêmica que

realmente atuem em função de tais mudanças, e para tanto, é importante que elas comecem a

acontecer na construção da prática pedagógica universitária. A discussão da didática, como

instrumento de reflexão para a relação teoria e prática voltada para a função social da

universidade e do papel do educador na construção deste social, pode ilustrar a importância da

necessidade de construir um processo de formação profissional que insista também em uma

formação sócio-política do universitário.

8.3 Agilidade

Para que sejam desenvolvidos softwares, a engenharia de software fornece métodos e

processos para que se tenha um fundamento de como os softwares devem ser desenvolvidos.

Como alternativa aos processos tradicionais, como o processo de desenvolvimento em

9

cascata, surgiu o conceito de modelos ágeis de processo em resposta ao cenário atual do

mercado em que tudo muda rapidamente.

Segundo Jacobson (2002) apud Pressman (2006), agilidade está ligada à capacidade de

respostas às mudanças, estas mudanças podem ser tanto na equipe, nas tecnologias, no

software que está sendo construído, ou qualquer outra modificação que possa impactar no

produto ou no projeto que está sendo desenvolvido.

Para Pressman (2006), além da resposta às mudanças, na agilidade deve haver também

uma estrutura que facilite a comunicação entre todos os envolvidos no projeto, deve enfatizar

a entrega rápida de software utilizável, os clientes devem ser considerados como parte do time

de desenvolvimento, e o plano de projeto deve ser flexível.

Ainda segundo Pressman (2006) para se alcançar a agilidade foram definidos pela

aliança ágil (será vista em seguida) 12 princípios. São eles: priorizar a satisfação do cliente

entregando software útil desde o início; aceitar que os requisitos podem precisar de

modificação; entregar frequente de software funcionando; os envolvidos no projeto devem

trabalhar juntos diariamente; deve ser fornecido o ambiente e apoio para que a equipe se sinta

motivada; favorecer a troca de informações através da conversa face a face; a medição de

progresso deve ter como base software funcionando; deve-se manter um ritmo constante;

manter atenção contínua a excelência técnica e ao bom projeto; buscar a maior simplicidade

possível; as equipes devem ser auto-organizadas; devem ser realizados intervalos para a

equipe analisar como pode melhorar sua eficiência e fazer um ajuste em seu comportamento.

8.3.1 Manifesto Ágil

BEC (2001) apud Pressman (2006), afirma que em 2001 foi feita uma aliança por Kent

Beck e outros 16 desenvolvedores onde os mesmos assinaram o “manifesto para o

desenvolvimento ágil de software”, tentando com isso mudar os problemas conhecidos na

engenharia de software convencional e passar a utilizar melhores modos de desenvolvimento

de software. Este novo modo foca mais em: indivíduos e interações em vez de processos e

ferramentas; softwares funcionando em vez de documentação abrangente; colaboração do

cliente em vez de negociação de contratos; resposta a modificações em vez de seguir um

plano.

O modelo ágil já existia antes do manifesto, mas com o intuito de trazê-lo à tona

sugerindo mudanças na engenharia de software tradicional e atacando as suas fraquezas o

manifesto foi realizado.

10

8.3.2 Processo Ágil

Segundo Pressman (2006), um processo ágil é caracterizado por atender três

suposições-chave sobre a maioria dos projetos de software, são eles:

a. A dificuldade de prever quais alterações será necessária nos requisitos de

software e as prioridades desejadas pelo cliente.

b. A dificuldade de prever a quantidade de projeto necessária antes que a

construção seja usada para comprovar o projeto.

c. A dificuldade de planejar a análise, projeto, construção e testes por não serem

bem previsíveis.

O processo ágil pode ser caracterizado por atender a estas suposições por ter um cunho

adaptativo, ajudando a gerenciar portanto a imprevisibilidade.

8.3.3 Modelos Ágeis de Processo

De acordo com Pressman (2006), existem diferentes modelos ágeis de processo, e

existem entre eles grandes semelhanças e também características particulares, mas o que os

liga são os princípios que satisfazem ao manifesto para o desenvolvimento ágil ou pelo menos

parte dele.

Alguns exemplos de modelo ágil de processo são: extreme programming (XP), scrum,

dynamic systems development method (DSDM), crystal, feature driven development (FDD) e

agile modeling (AM).

8.4 Scrum

Segundo SHC (2001) apud Pressman (2006), o scrum (seu nome é em alusão a uma

estratégia utilizada no jogo de rugby, onde os jogadores do mesmo time se unem ao redor da

bola, passando-a entre os mesmos e evitando que os adversários influenciem na jogada), se

trata de um modelo ágil de processo criado por Jeff Shuterland na década de 1990 e mais

recentemente Scwaber e Beedle realizaram desenvolvimento adicional de métodos.

O scrum, portanto não é algo novo, mas vem recebendo incrementos nos seus métodos

para chegar à forma como se conhece hoje.

Na definição Schwaber e Shuterland apud Cruz e Sabbagh (2011), scrum se trata de

um framework [enquadramento] onde as pessoas utilizam suas regras para tratar e resolver

problemas que apresentam complexidade e exigem um alto grau de adaptação, enquanto

busca entregar produtos com o mais alto valor possível de forma criativa e produtiva.

11

ADM (1996) apud Presman (2006) afirma que os princípios do scrum são consistentes

com o manifesto ágil no sentido de que: as equipes de trabalho são pequenas, maximizando

assim a comunicação, o compartilhamento do conhecimento e diminuindo a supervisão; o

processo deve ser adaptável às modificações técnicas e de negócio; o processo produz

incrementos no software com frequência; a divisão do trabalho de desenvolvimento e dos

integrantes da equipe é feita em partições claras; os testes e a documentação do produto são

feitos concomitantemente com o desenvolvimento do mesmo.

8.4.1 Quando o Scrum deve ser Utilizado?

Schwaber e Shuterland apud Cruz e Sabbagh (2011), afirmam que antes de se começar

a utilizar o scrum, deve-se observar a forma como a equipe está trabalhando, e os pontos

fracos, para saber então o quão relevante pode ser a adoção deste processo na equipe, evitando

assim fatores como impactos na rentabilidade da empresa.

Schwaber e Shuterland apud Cruz e Sabbagh (2011), ressaltam ainda que esta

observação é de grande importância para identificar se o processo da empresa precisa

realmente ser modificado para que a mesma tenha uma melhora na sua produtividade.

Se o processo presente da empresa já supre as necessidades de desenvolvimento de

software, não é necessário implementar modificações no seu processo. Apesar de o projeto

não se passar dentro de uma empresa, e sim em uma Faculdade, viu-se a necessidade da

adoção de um processo para guiar o desenvolvimento das atividades. O que se observou foi

que o processo utilizado para guiar as atividades não está bem definido, tendendo mais para o

método tradicional, tendo como uma das características o maior foco na documentação.

Até aqui foi identificado o processo utilizado no desenvolvimento das atividades, mas

o que sugere que deve haver uma modificação do mesmo com o intuito de melhorar a

produtividade é a afirmação de Schwaber e Shuterland apud Cruz e Sabbagh (2011), que

dizem que as empresas que ainda possuem como foco os processos e documentação

acreditando que é isso que vai melhorar seu trabalho, estão tendo que se readequar á novos

conceitos para se manter no mercado e de forma competitiva. Fazendo uma analogia com as

atividades acadêmicas, apesar das mesmas não enfrentarem competitividade, elas fazem parte

da preparação dos acadêmicos, e estes irão enfrentar a competitividade ao partirem para o

mercado de trabalho.

Admitindo-se que o processo utilizado no desenvolvimento das atividades foi

identificado e viu-se a necessidade de melhorá-lo, entra aqui a resposta de quando o scrum

deve ser utilizado, apoiando-se na afirmação de Schwaber e Shuterland apud Cruz e Sabbagh

12

(2011), que dizem que a agilidade no desenvolvimento de software, tem se mostrado cada vez

mais como um diferencial no mercado, pois a medida que a velocidade das informações

aumentam, aumenta também a necessidade das empresas por software.

Com a necessidade de construir softwares mais rapidamente para suprir as

necessidades das empresas, os autores citados acima sugerem a adoção da agilidade. Por este

motivo o autor do projeto optou por adotar o scrum (que segue os princípios da agilidade) no

desenvolvimento da atividade acadêmica, tendo em vista que a atividade à ser realizada tem

um prazo curto de apenas cinco meses aproximadamente, devendo a mesma ser realizada com

extrema rapidez.

8.4.2 Etapas do Scrum

De acordo com Schwaber e Shuterland apud Cruz e Sabbagh (2011) embora o scrum

seja passível de alterações como a utilização apenas de partes do seu resultado final não seria

scrum. Para ser scrum devem ser seguidos todos os papéis, artefatos eventos e regras do

mesmo.

Portanto para que o projeto tenha validade, devem ser seguidas todas as etapas do

scrum, que são definidas no guia do scrum de Schwaber e Shuterland apud Cruz e Sabbagh

(2011), são eles:

8.4.2.1 Papéis

Antes de abordar as etapas do scrum, é interessante conhecer os papéis que compõem

o time scrum, são eles:

a. Time Scrum (o autor consultado o diferencia do time que engloba todos os

papéis pelo “T” maiúsculo, o autor do projeto seguirá o mesmo padrão de

diferenciação): Equipe de desenvolvimento, profissionais responsáveis por

dividir o product backlog (será visto a seguir) e transformar em incrementos

funcionais que poderão ser entregues no final de cada sprint (será visto a

seguir).

Segundo Shuterland apud Cruz e Sabbagh (2011), os membros do Time scrum devem

possuir características como: interdisciplinaridade; por mais que seja especialista em uma área

caso seja necessário deve atuar em outras áreas; devem ser auto-organizáveis, eles mesmos

devem saber como vão transformar os requisitos em incrementos utilizáveis; o numero ideal

13

de membros do Time deve ser de (7) sete pessoas, podendo ter uma variação de mais ou

menos (2) dois membros

O Time scrum neste caso serão os acadêmicos que estarão cursando a disciplina

Estágio II em que será aplicado o projeto, os mesmos deverão focar na entrega de incrementos

do produto dentro do prazo preestabelecido, trabalhando de forma interdisciplinar e auto-

organizável.

b. Dono do Produto [product owner]: não necessariamente é o dono do

produto, mas é o responsável por gerenciar a lista de produto [product

backlog].

Segundo Shuterland apud Cruz e Sabbagh (2011), o product owner deve ter

características como: garantir que o investimento no projeto traga retorno; deve sempre

atualizar o backlog (será visto a seguir) e disponibilizá-lo a todos; deve ser indicado pelo

cliente; as decisões tomadas por ele devem ser respeitadas por todos.

O dono do produto (product owner) neste caso será o professor da disciplina em que

será aplicado o projeto, o mesmo dará a lista de produto que deseja que seja realizado, sempre

visando incrementos que tragam maior retorno.

c. Mestre do Scrum [scrum master]: responsável por fazer com que o scrum

seja entendido, e aplicado, o mesmo deve ainda ajudar o time a ser auto-

organizável e interdisciplinar, deve ser um líder/facilitador, protegendo o

Time de interferências externas e removendo impedimentos, deve auxiliar os

gerentes e clientes na identificação de um product owner, e facilitar o trabalho

do mesmo.

O mestre scrum (scrum master) no caso deste projeto será o próprio autor, que irá

aplicar o scrum.

Segundo Schwaber e Shuterland apud Cruz e Sabbagh (2011), o scrum tem uma

visão dos papéis, onde, enquanto alguns estão comprometidos com os resultados e objetivos a

serem alcançados que é o Time scrum, os outros estão envolvidos no projeto, não devendo os

envolvidos dizerem o que os comprometidos devem dizer. A figura a seguir ilustra esta visão:

14

Figura 2 – envolvimento x comprometimento

Fonte: Cruz e Sabbagh,2011

8.4.2.2 Visão do Produto

Segundo Shuterland apud Cruz e Sabbagh (2011), para iniciar o desenvolvimento do

produto, o product owner ter e apresentar uma visão de como deve ser o produto, está visão

deve ser expressa em um documento com no máximo duas (02) folhas, que deve abranger as

partes mais importantes do produto. Podem ser utilizadas também ferramentas para auxiliar a

melhor visão do produto, como por exemplo, a modelagem de mapas mentais, que consiste

em um diagrama contendo o objetivo, as funcionalidades, as metas não funcionais, critérios

de sucesso, descrição básica das tecnologias e arquitetura do projeto.

Figura 3 – Modelagem de Mapa Mental

Fonte: Cruz e Sabbagh,2011

Ainda de acordo com Shuterland apud Cruz e Sabbagh (2011), esta visão do produto

permite ao time saber qual é a meta do produto, e o resultado esperado.

15

O autor consultado sugere que a elaboração da visão do produto, seja realizada pelo

product owner, que seria o professor da disciplina em que o projeto será inserido, no entanto é

interessante que os acadêmicos desenvolvam esta habilidade e de outros artefatos seguintes

que deveriam ser de responsabilidade do product owner. Devendo os mesmos, acompanhar o

desenvolvimento destes artefatos.

8.4.2.3 Product Backlog

Segundo Shuterland apud Cruz e Sabbagh (2011), o product backlog se trata de um

artefato do scrum onde é reunida a lista de requisitos de forma priorizada, o product backlog

deve ser realizado pelo product owner, podendo usar como base para elaborá-la, as práticas de

engenharia de requisitos.

De acordo com Shuterland apud Cruz e Sabbagh (2011), o product owner pode usar

também uma ferramenta vinda da metodologia XP, chamada de estória de usuário (user

story). Ela consiste em questionar os usuários ou futuros usuários do software sobre o que eles

gostariam que o mesmo possuísse para trazer um valor de negocio na sua função.

Supondo que o software a ser desenvolvido na disciplina em que o projeto será

inserido fosse um sistema para armazenar os trabalhos dos acadêmicos, os usuários poderiam

por exemplo criar as seguintes estórias:

Como acadêmico (usuário) eu gostaria de visualizar os trabalhos via web (valor de

negócio);

Como professor (usuário) eu gostaria que o sistema comparasse a semelhança entre

os trabalhos (valor de negócio).

Segundo Shuterland apud Cruz e Sabbagh (2011), após a identificação dos requisitos,

os mesmos devem ser colocados no product backlog de forma priorizada, dando uma visão de

como deverá ser o produto, permitindo ao time criar uma estratégia para as entregas.

Segundo Shuterland apud Cruz e Sabbagh (2011), o product owner deve elaborar a

priorização dos itens do product backlog colocando uma nota para cada item de acordo com a

sua importância para o negocio.

16

Seguindo o exemplo dado anteriormente, segue a tabela abaixo com as pontuações:

Figura 4 – Pontuação de valor de negócio dos itens do product backlog.Item Valor de NegócioComo acadêmico eu gostaria de visualizar os trabalhos via web

100

Como professor eu gostaria que o sistema comparasse a semelhança entre os trabalhos

80

Como coordenador eu gostaria de receber uma notificação sempre que um novo trabalho for inserido.

60

Fonte: elaborado pelo próprio autor.

8.4.2.4 Sprint [corrida curta e rápida]

Antes de abordar a sprint, é interessante compreender o conceito de timebox [tempo

embutido em uma caixa], que segundo Shuterland apud Cruz e Sabbagh (2011), se trata de um

conceito utilizado para controlar o tempo de duração da sprint e dos eventos que ocorrem

dentro dela.

O conceito de timebox é muito marcante dentro do Scrum devido à questão do tempo

que deve ser tratada com rigidez dentro do mesmo.

Segundo Shuterland apud Cruz e Sabbagh (2011), a sprint se trata de uma timebox que

pode durar de uma (01) a quatro (04) semanas, devendo ser definido anteriormente. Dentro de

cada sprint deve ter uma meta representando o que o cliente deseja que se incremente no

software naquele timebox, ficando ao encardo dos membros do Time dizer através de uma

estimativa, que itens do desejo do cliente é possível fazer de dentro daquele timebox.

Ainda de acordo com Shuterland apud Cruz e Sabbagh (2011), durante a sprint o Time

não deve receber nenhum tipo de influencia externa que possa afetar as metas, ficando a cargo

do Scrum Master, proteger o Time. Caso os itens da sprint não façam mas sentido, a sprint

poderá ser cancelada pelo product owner e somente por ele, podendo receber influência das

partes interessadas no cancelamento. Caso a sprint seja cancelada, os itens do product backlog

que foram concluídos são revisados e aceitos se representarem um incremento que possa ser

entregue. O restante dos itens deve voltar para o product backlog com as estimativas iniciais.

8.4.2.5 Sprint Planning Meeting [Reunião de Planejamento da Sprint]

Segundo Shuterland apud Cruz e Sabbagh (2011), a sprint planning meeting tem uma

duração pré-fixada que pode ser de aproximadamente cinco por cento (5%) do tamanho total

17

da sprint, e é dividida em duas partes que consomem tempos iguais. Na primeira o product

owner apresenta ao time os itens com maior valor de negócio, e o time deve estimar o

tamanho e complexidade desses itens, com base nisso decidir o que será feito na sprint. A

estimativa de tempo de esforço necessário para cada item deve ser feita através da técnica de

planning poker, que consiste em cartas com várias pontuações (similares as de baralho)

divididas entre os membros do Time, e estes usam as mesmas para pontuar o tempo de

esforço necessário para cada item de acordo com a opinião pessoal, a pontuação é somada e a

média representa o quanto de esforço de tempo aquele item exige. Se for a primeira sprint é

utilizado apenas o product backlog, já a partir da segunda sprint deve-se utilizar também a

capacidade do Time em desenvolver tarefas em um sprint (quantos itens conseguem realizar)

e o histórico de desempenho (velocidade).

Figura 5 - cartas de planning poker

Fonte: Cruz e Sabbagh, 2011

Ainda de acordo com Shuterland apud Cruz e Sabbagh (2011), após ser definido o que

fazer na primeira parte da reunião, deve-se partir para a segunda parte, que aborda como

devem ser realizados os itens selecionados e transformados em incremento, deve também

identificar as tarefas necessárias para realizar cada item. As tarefas devem ser decompostas

para que possam ser feitas em menos de um dia, após a conclusão das atividades, serão

convertidos os itens do product backlog em pedaços funcionais do produto final. A lista das

tarefas a serem realizadas na sprint é chamada de sprint backlog.

Segundo Shuterland apud Cruz e Sabbagh (2011), além do Time, devem participar

também da reunião: o Scrum Master agindo como um facilitador, o product owner para que o

18

Time possa negociar com ele a quantidade de trabalho caso não estejam de acordo, e pode ser

convidada ainda uma pessoa para fornecer conselhos técnicos ou sobre o domínio da questão.

8.4.2.6 Daily Scrum Meeting [Reunião Diária do Scrum]

Segundo Shuterland apud Cruz e Sabbagh (2011), a daily scrum meeting, como o

próprio nome sugere, é uma reunião feita todos os dias, no mesmo horário e local, com o

timebox quinze (15) minutos. Nesta reunião são tratadas as questões: o que foi feito no dia

anterior, o que será feito no dia atual e quais são os impedimentos.

De acordo com Shuterland apud Cruz e Sabbagh (2011), deve participar da reunião: o

Time, respondendo as questões citadas anteriormente e o scrum master conduzindo a reunião

e evitando que a mesma saia do foco.

Shuterland apud Cruz e Sabbagh (2011), afirma que esta reunião traz como vantagem

a melhora da comunicação, a identificação e remoção de impedimentos, ressalta e promove a

tomada rápida de decisões, deixa o time mais entrosado com o projeto, e traz uma melhor

visualização do progresso do projeto.

8.4.2.7 Sprint Review Meeting [reunião de revisão da sprint]

Segundo Shuterland apud Cruz e Sabbagh (2011), a sprint review meeting é uma

reunião realizada no final de cada sprint, o seu tempo de duração não pode exceder cinco por

cento (5%) do tempo total da sprint. Nesta reunião o Time deve apresentar o que foi realizado

de incremento e responder a questionamentos. O product owner identifica o que foi feito e o

que deixou de ser feito durante a sprint, discute o product backlog e projeta datas de entrega

com base em hipóteses de velocidade. Em seguida, todos discorrem sobre o que foi visto e

discutem sobre o que fazer daí em diante.

8.4.2.8 Sprint Retrospective Meeting [reunião de retrospectiva da sprint]

Segundo Shuterland apud Cruz e Sabbagh (2011), a sprint retrospective meeting deve

ocorrer após a reunião de revisão da sprint, a mesma deve ter uma duração de três (03) horas.

Nela é revisada a sprint passada e são abordadas questões como: o que funcionou bem, o que

não funcionou bem e o que precisa ser melhorado. Concluindo a reunião com a adoção de

melhorias para a próxima sprint.

19

8.4.2.9 Fluxo de Trabalho

Segundo Shuterland apud Cruz e Sabbagh (2011), o fluxo do scrum é simples de ser

compreendido, mas a implementação do mesmo é difícil porque requer uma mudança na

cultura da empresa onde será implementado.

Da mesma forma espera-se encontrar uma resistência por parte dos envolvidos no

projeto, isso deve ser um dos pontos analisados pelo autor do projeto.

A baixo uma visão de todo o Fluxo do processo do scrum:

Figura 6 - Fluxo de processo do scrum

Fonte: Cruz e Sabbagh, 2011

20

9 CRONOGRAMA

10 REFERÊNCIAS

ATIVIDADESFev

2013

Mar

2013

Abr

2013

Mai

2013

Jul

2013

Ago

2013

Set

2013

Out

2013

Nov

2013

1. Escolha do

Tema.

2. Desenvolvimento

do projeto.

3. Revisão do

projeto.

4. Entrega do

projeto.

5. Apresentar os

Conceitos do

Scrum à equipe.

6. Aplicar o

Scrum.

7. Realizar

entrevista.

8. Entrega do

trabalho.

21

BROD, Cesar. Uma introdução ao scrum. Disponível em:< http://www.divus.com.br/bibliotecaVirtual/IntroducaoScrum.pdf>. Acesso em:10 de out. 2012.

ELDER, Allan. As cinco doenças do gerenciamento de projetos- Introdução: Por que seus projetos atrasam e o que fazer sobre isso? Tradução de Adail Muniz Retamal. Disponível em:< http://www.heptagon.com.br/5dgp>. Acesso em: 12 de out. 2012.

GREENFIELD, Jack. O caso das fábricas de software, v.1, n.1, 2004. Disponível em:<msdn.microsoft.com/pt-br/library/aa480032.aspx>. Acesso em: 10 de outubro de 2012.

OLIVEIRA, Carlos E. M.; SCAFF, Vinicius P.; STANO, Rita C. M. T. Aspectos Técnicos e Pedagógicos no Desenvolvimento de Softwares Educacionais: Um Estudo de Caso em uma Escola Municipal de Itajubá. Disponível em:< http://www.aedb.br/seget/artigos06/914_OLIVEIRA_Software.pdf>. Acesso em: 12 de out. 2012.

SCHWABER, Ken, SUTHERLAND, Jeff. Guia do Scrum: Um guia definitivo para o Scrum: As regras do jogo. Tradução de Fábio Rodrigues Cruz; Rafael Sabbagh. Disponível em:< http://www.divus.com.br/bibliotecaVirtual/GuiaScrum.pdf>. Acesso em: 10 de out. 2012.