projeto jailson
Post on 13-Mar-2016
234 Views
Preview:
DESCRIPTION
TRANSCRIPT
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.
top related