INSTITUTO DE EDUCAO SUPERIOR DA PARABA

BACHARELADO EM SISTEMAS DE INFORMAO

ANTNIO ALVES DA SILVA NETO

OS BENEFCIOS DO DOCUMENTO DE ESPECIFICAO NA

METODOLOGIA SCRUM EM UM AMBIENTE DE
DESENVOLVIMENTO DE SISTEMAS DE GRANDE PORTE

CABEDELO-PB
2011

ANTNIO ALVES DA SILVA NETO

OS BENEFCIOS DO DOCUMENTO DE ESPECIFICAO NA

METODOLOGIA SCRUM EM UM AMBIENTE DE
DESENVOLVIMENTO DE SISTEMAS DE GRANDE PORTE

Monografia apresentada ao curso de

Bacharelado em Sistemas de Informao,
do IESP-PB, como requisito para a
concluso do curso e obteno do ttulo de
Bacharel em Sistemas de Informao.

ORIENTADOR: PROF. ESP. MAXWELL ANDERSON IELPO DO AMARAL

CABEDELO-PB
2011

Dados de acordo com: AACR2, CDU e Cutter

Biblioteca Central IESP Faculdades PB
S586b

Silva Neto, Antnio Alves da

Os benefcios do documento de especificao na
metodologia scrum em um ambiente de desenvolvimento de
sistemas de grande porte / Antnio Alves da Silva Neto.
Cabedelo, PB: [s.n], 2011.
45f.
Monografia (Graduao) Instituto de Educao Superior
da Paraba (IESP) - Curso de Sistemas de Informao, 2011.
1. Anlise de sistemas. 2. Desenvolvimento de software. 3.
Scrum. I. Ttulo.
CDU 004.414.2(043.4)

INSTITUTO DE EDUCAO SUPERIOR DA PARABA

BACHARELADO EM SISTEMAS DE INFORMAO
ANTNIO ALVES DA SILVA NETO

OS BENEFCIOS DO DOCUMENTO DE ESPECIFICAO NA

METODOLOGIA SCRUM EM UM AMBIENTE DE
DESENVOLVIMENTO DE SISTEMAS DE GRANDE PORTE

Monografia apresentada ao curso de

Bacharelado em Sistemas de Informao,
do IESP-PB, como requisito para a
concluso do curso e obteno do ttulo de
Bacharel em Sistemas de Informao.

Aprovada em: 15 de dezembro de 2011.

BANCA EXAMINADORA:
_______________________________________________
Maxwell Anderson Ielpo do Amaral
(Presidente)
_______________________________________________
Luciano Henrique Gomes de Almeida
(Membro)
_______________________________________________
Wellington Cavalcanti de Arajo
(Membro)

CABEDELO-PB
2011

AGRADECIMENTOS
Deus, o meu criador, meu perdoador e razo do meu viver. Esquecido por
alguns, ignorado por outros, mas s, para mim, o motivo de seguir em frente. Em Ti eu
encontro a melhor filosofia de vida que algum poderia encontrar. A Ti, Senhor e Rei, o meu
agradecimento por esta realizao. Sem Ti, Senhor, eu no conseguiria... jamais. Toda a glria
e honra sejam dadas a Ti.
minha esposa, Juliana, e minha filha, Anelise, por tudo o que representam
para mim.
Ao meu pai, Gilvan, e minha me, Pedrineida, por tudo que fizeram por mim,
por tudo que me ensinaram, pelo homem que me formaram, e por serem quem so: meus pais.
Sei que esto felizes por isso, e saibam que vocs so tudo para mim. E minha irm, Eneida,
a quem eu amo demais, por todas as oraes que fez em meu favor, para que eu conseguisse.
Te amo.
Unimed Norte/Nordeste, principalmente ao Infomed Tecnologia, por me dar
a oportunidade de conhecer a metodologia Scrum, tema deste trabalho, bem como ter o
convvio com profissionais da mais alta competncia e conhecimento.
Ao analista de sistemas Francisco Jos Rodrigues Gomes, o "Chico", que desde
a poca do meu estgio obrigatrio (curso tcnico), no ano 2000, me incentivou a fazer um
curso superior. Posso dizer, Chico, que esta minha vitria tem a sua participao em tudo.
Ao professor Ms. Jos Teixeira de Carvalho Neto, o "Neto", que foi professor
desta instituio de ensino e que me fez gostar de anlise de sistemas.
Ao professor Esp. Maxwell Anderson Ielpo do Amaral, meu orientador, que
mesmo com o curto espao de tempo que teve, as vrias atividades paralelas que tem, fez
realmente o papel de orientador deste trabalho, me mostrando o lugar correto a seguir.
professora Ms. Josemary Marcionila Freire dos Santos, coordenadora do
curso de Sistemas de Informao desta instituio, pelas palavras (e aes) de incentivo, que
me ajudaram a terminar este curso. No tenho palavras para te agradecer.

Ao meu amigo, quase um irmo de sangue, Adriano Barroso Silvestre, o qual

esteve comigo no curso tcnico que fiz, na primeira software-house que trabalhamos, na
primeira doao de sangue que fizemos, na primeira entrevista de emprego na Unimed N/NE,
no primeiro dia de trabalho no Infomed, e nas vrias "corridas" que fizemos, atravessando a
BR-230, para chegarmos ao IESP. A voc, meu companheiro de todas as horas, o meu
agradecimento.
minha turma de origem do IESP, os "sobreviventes": Clebson, Emanoel,
Jansen, Ineilton, Pedro Ivo, Walter, Wellington e Willdemark. Demos boas risadas juntos.
Que Deus os faa excelentes profissionais desta rea de tecnologia.

...no h qualquer tecnologia, tcnica

ou prtica que incremente em grande
magnitude a produtividade,
confiabilidade ou simplicidade no
desenvolvimento de software.
(Frederick Brooks, 1987)

RESUMO

Com o passar dos anos, o desenvolvimento de sistemas de informtica vem crescendo e, com
este crescimento, a necessidade de se estabelecer regras, normas e processos para o mesmo,
foi tornando-se algo inevitvel. No seria mais possvel conceber a produo de software sem
uma mnima organizao dos procedimentos que norteariam o desenvolvimento. Partindo
desta necessidade, foram surgindo vrias metodologias de desenvolvimento e, em meados de
2001, surgiu uma corrente de pensamento chamada Manifesto gil, que props, dentre outras
filosofias de trabalho, que era prefervel ter um sistema funcionando em um curto espao de
entrega, do que possuir uma extensa documentao. E, baseado neste manifesto, surgiu o
Scrum, que um framework focado em entregar ao cliente, no menor tempo possvel, aquilo
que o mesmo est esperando. Porm, com a implantao do Scrum em ambientes de
desenvolvimento de grande porte com sistemas complexos, em tamanho e em regras de
negcio, percebeu-se que, para alguns casos, as estimativas de entrega no saram como o
esperado, principalmente quando o escopo da implementao era sobre algo novo; talvez em
uma nova tecnologia ou baseado em alguma legislao especfica. Alm desta dificuldade em
estimar, surge a questo do legado da informao. O que est sendo deixado para os futuros
desenvolvedores com relao s funcionalidades complexas do sistema? Tentando responder
estas questes, o presente trabalho avaliou o cenrio de desenvolvimento em algumas
empresas de Joo Pessoa-PB, utilizando um questionrio e, percebeu-se, alm de outras
informaes que, as empresas que utilizam o Scrum, possuem um procedimento de anlise
prvia; algumas gerando artefatos prprios para, s ento, iniciar o desenvolvimento. Tanto o
referencial terico, quanto a pesquisa realizada, serviram de base para a elaborao de um
modelo de documento (artefato) de especificao, a fim de auxiliar na resoluo de grandes
requisitos dentro da metodologia Scrum.

Palavras-chave: Anlise de sistemas, Scrum, desenvolvimento de software.

ABSTRACT

Over the years the computer area has achieved a height level of growth, but due to this it is
necessary to create and define rules and process to make it manageable. Today it's impossible
to produce software without a minimum level of organization. From this need many
methodologies were created and in 2001 a new school of think, called Agile Manifest, defined
that it's more important to have a system running, delivering it in the shortest time possible,
than to have a system with a extensible documentation. Following this line of thought the
Scrum framework was created, with it the main focus been to deliver to the customer the final
product in the shortest time possible. However, with the deployment of Scrum in large
development environments, system with high level of complexity, in both business rules and
size, it was noticed that in some cases that the estimated time has not achieved the expected
result, especially when the project included a new feature, perhaps due to a new technology or
some new legislation. A part from difficulty in estimate the development time there's another
question, about the legacy, with less documentations how future developers will understand
how the complex features and functionalities works? Trying to answer these questions, this
study evaluated the stage of development in some companies in Joo Pessoa-PB, using a
questionnaire it was realized that many companies using Scrum, have a procedure for prior
review, generating some artifacts for themselves, only then, they start the development. Using
this survey and theoretical knowledge as base it was created an specification document
(artifact), with the goal to assist in resolving the problems involving big requirements inside
an Scrum project.

Keywords: Systems analysis, Scrum, software development.

LISTA DE FIGURAS
Figura 1 - Taskboard Scrum ..................................................................................................... 20
Figura 2 - Burndown Chart ...................................................................................................... 20
Figura 3 - Processo de desenvolvimento com Scrum ............................................................... 21

LISTA DE TABELAS
Tabela 1 - Classificao do porte ............................................................................................. 28
Tabela 2 - Classificao das empresas ..................................................................................... 28
Tabela 3 - Utilizao de metodologias de desenvolvimento .................................................... 29
Tabela 4 - Procedimentos para estrias grandes ....................................................................... 30

SUMRIO
1 INTRODUO ..................................................................................................................... 12
1.1 JUSTIFICATIVA ............................................................................................................... 13
1.2 OBJETIVO GERAL ........................................................................................................... 13
1.3 OBJETIVOS ESPECFICOS ............................................................................................. 13
1.4 METODOLOGIA............................................................................................................... 14
2 ANLISE DE SISTEMAS: O DESAFIO ............................................................................ 15
3 SCRUM: UMA ABORDAGEM INICIAL ............................................................................ 17
3.1 O Scrum .............................................................................................................................. 18
3.2 Alguns conceitos importantes ............................................................................................. 18
3.2.1 Product Backlog: ............................................................................................................. 18
3.2.2 Sprint: .............................................................................................................................. 19
3.2.3 Scrum Team: .................................................................................................................... 19
3.2.4 Scrum Master: ................................................................................................................. 19
3.3 Algumas ferramentas de apoio ........................................................................................... 19
3.3.1 Taskboard/Dashboard: .................................................................................................... 19
3.3.2 Burndown Chart: ............................................................................................................. 20
3.4 Fluxo do Scrum................................................................................................................... 21
3.4.1 Reunio de planejamento................................................................................................. 21
3.4.2 Sprint e Reunio Diria ................................................................................................... 22
3.4.3 Reunio de reviso........................................................................................................... 22
3.4.4 Reunio de retrospectiva ................................................................................................. 23
4 ESTIMAR SEM CONHECER, EIS A QUESTO .............................................................. 24
5 A REALIDADE DO DESENVOLVIMENTO DE SOFTWARE EM ALGUMAS
EMPRESAS DE JOO PESSOA-PB ...................................................................................... 27
6 O DOCUMENTO DE ESPECIFICAO NA METODOLOGIA SCRUM ........................ 31
6.1 Proposta de documento....................................................................................................... 32
6.1.1 Ttulo, nmero e analista(s) envolvido(s): ....................................................................... 32
6.1.2 Descrio principal: ......................................................................................................... 32
6.1.3 Limitaes tcnicas (caso existam): ................................................................................ 33
6.1.4 Especificao: .................................................................................................................. 33
6.2 Como aplicar o documento nas Sprints Scrum ................................................................... 35
7 CONSIDERAES FINAIS ................................................................................................ 37
REFERNCIAS ....................................................................................................................... 39

ANEXOS .................................................................................................................................. 41
ANEXO 1 - QUESTIONRIO APLICADO EM ALGUMAS EMPRESAS COM
DESENVOLVIMENTO DE SOFTWARE EM JOO PESSOA............................................ 42
ANEXO 2 - MODELO DE DOCUMENTO DE ESPECIFICAO PARA O SCRUM ....... 43

1 INTRODUO

Atualmente, para as empresas nas mais diversas reas de negcio e de todos os

portes, a utilizao de sistemas de apoio essencial. Nesse mbito, e a fim de garantir e
acompanhar as inovaes e tendncias, o desenvolvimento e sustentao de aplicaes se
mostra primordial. Entretanto, comum deparar-se com equipes de desenvolvimento
heterogneas em experincia, conhecimento, produtividade, e que sofrem com prazos curtos
de entrega, presso externa dos clientes e um domnio de negcio extremamente complexo.
Devido a esse cenrio, as entregas podem ser comprometidas, e consequentemente, a
credibilidade e at a qualidade do sistema de informao.
Diante deste contexto, algumas perguntas so necessrias: como controlar o
que a equipe de desenvolvimento est produzindo? Como aproveitar o tempo curto e montar
um plano de ao que ajude na correo de falhas do sistema de forma rpida? Quais os
papis dos envolvidos neste processo? E por fim, como disseminar conhecimento para
equipes que hoje so especialistas apenas em algumas reas? Estas, talvez, sejam perguntas
emblemticas para este cenrio, contudo, as mesmas motivaram a elaborao do Manifesto
gil. Baseado tambm, nestes valores e princpios, foi criado o Scrum, que se prope a ser um
processo gil de desenvolvimento de software, sugerindo mtodos e aes de trabalho que
sero realizadas no decorrer de todo o processo de desenvolvimento de software.
Porm, como toda framework, o Scrum possui algumas limitaes.
Principalmente quando falamos em grandes requisitos ou sistemas de grande porte, j que o
Scrum baseia-se, no na elaborao de documentao abrangente, mas na agilidade em
entregar o produto.
O presente trabalho vem tentar avaliar uma soluo para este cenrio,
utilizando um documento (artefato) de especificao para requisitos grandes em sistemas de
grande porte. Este documento no teria muitas restries, e serviria somente para resolver esta
lacuna do Scrum, de documentao tcnica escassa, no cenrio j apresentado.

12

1.1 JUSTIFICATIVA
Nunca se falou tanto em tecnologia e na automao de processos, quanto nos
dias atuais. Portanto, o desenvolvimento de softwares que contribuem no dia a dia de qualquer
empresa pea chave do processo. Porm, quando os sistemas so muito grandes e
complexos, faz-se necessria a utilizao de boas prticas que contribuam para o sucesso dos
aplicativos desenvolvidos. E dentro das metodologias geis de desenvolvimento1, existem
algumas limitaes para requisitos grandes, pois no se baseiam em documentaes
abrangentes.
Foi pensando em resolver esta problemtica que este trabalho est sendo
proposto, a fim de avaliar o uso do artefato de especificao para desenvolvimento de
requisitos grandes, em sistemas de grande porte, ou em sistemas complexos.
1.2 OBJETIVO GERAL
Analisar os benefcios, ou no, do documento de especificao, agregado
framework Scrum, a fim de melhorar o desenvolvimento de grandes requisitos nas Sprints2.
1.3 OBJETIVOS ESPECFICOS

Entender como funciona, mesmo que inicialmente, a framework Scrum,

como ferramenta para auxiliar no processo de desenvolvimento de
software;

Identificar, especificamente, o cenrio de desenvolvimento em

empresas de grande e mdio porte, levantando as vantagens e
dificuldades encontradas;

Saber como algumas empresas locais funcionam, relacionado s

frameworks, mais especificamente, com o Scrum;

Verificar os benefcios do documento de especificao em requisitos de

grande durao, avaliando os ganhos e perdas.

Metodologia gil de desenvolvimento um termo que passou a descrever abordagens de desenvolvimento que
seguissem alguns princpios, dentre eles a agilidade na entrega de solues para o cliente.
2
Sprint o nome do ciclo de desenvolvimento na Metodologia Scrum.

13

1.4 METODOLOGIA
As metodologias aplicadas neste trabalho foram: consulta bibliogrfica, que
alicerou a pesquisa com opinies de vrios autores que tm experincia na rea de
desenvolvimento, bem como uma pesquisa de campo.
Na pesquisa, foi utilizado um questionrio (anexo 1) entregue em 12 (doze)
empresas de desenvolvimento de software (rea fim ou meio) na cidade de Joo Pessoa-PB,
no perodo entre outubro e novembro de 2011. O questionrio consta de 11 (onze) questes,
objetivas e subjetivas, no que auxiliou na quantificao dos dados que o trabalho se prope a
oferecer.
Uma avaliao crtica foi realizada, ao final do trabalho, a fim de verificar a
utilizao de um documento de especificao nos cenrios propostos. O resultado dos
questionrios serviu de base para isso.

14

2 ANLISE DE SISTEMAS: O DESAFIO

Quando analisamos o momento atual, no que diz respeito velocidade da

informao, de nos surpreender-nos. Talvez os nossos antepassados, duas ou trs geraes
atrs, nem imaginariam que hoje poderamos ligar um telefone celular, palm, Pager, iPad, e
conversar com o mundo inteiro com dispositivos que esto na palma de nossas mos. O
hardware (equipamento de informtica) de suma importncia neste aspecto. O avano na
eletrnica, automao, industrializao e aumento da mo de obra na fabricao de
eletrnicos, tambm vm somar a este progresso. Porm, nada disso seria possvel, se os
programas embarcados3 e de computadores, existissem. O software quem comanda todo o
gerenciamento das mquinas, gerando a informao e o resultado obtido. E isto podemos ver
em todas as reas da sociedade. No se imagina, por exemplo, uma indstria ou escritrio,
controlar toda a sua produo (manual ou intelectual) sem um software de computador. Neste
sentido, Kruchten fala que o software o combustvel dos negcios modernos, com o qual se
conectam melhor controles governamentais e sociedades (KRUCHTEN, 2003, p. 3).
Com toda esta importncia que o software tem, fcil perceber que a produo
do mesmo deve ser priorizada, no podendo ser encarada como simples ou de pouca
priorizao, j que, a partir dela, os negcios sero gerenciados. E ao contrrio do que muitos
imaginam, a produo de software no algo simplista, que tenha prazo determinado e
planejamento 100% cumprido. Falando do risco na produo do software, muitas
organizaes trabalham num modo de negativa de risco, clculo e planejamento continuado,
como se todas as variveis fossem conhecidas, o trabalho fosse mecnico e o pessoal,
substituvel (KRUCHTEN, 2003, p. 99).
E dentro da construo do software e em qualquer metodologia de
desenvolvimento, direta ou indiretamente, existe a fase de anlise, e esta serve para, na
medida do possvel, detectar a maioria dos problemas e solucion-los, antes que os mesmos
aconteam. Este, talvez, seja um dos maiores desafios no desenvolvimento de software e, o
entendimento da importncia da anlise de sistemas, d equipe de desenvolvimento uma
viso mais concreta para a construo de um software.

Embarcado, ou aplicaes embarcadas, so aplicativos que rodam (executam) em equipamentos fechados,

por exemplo: geladeiras, celulares, microondas, etc.

15

E se existe um ponto muito importante, na anlise de sistemas, a

formalizao do que encontrado ou detectado. E a documentao de um software (artefatos
de usurio e anlise) tambm faz parte do mesmo (SOMMERVILLE, 2003, p. 5) e alguns
formalismos, por menores que sejam, so importantes, a fim de registrar o que se deseja
seguir. Os direcionamentos formalizados so uma ponte para a equipe de desenvolvimento
seguir o rumo certo. Para isso, o analista deve levar em considerao alguns pontos e
dificuldades:
O entendimento de desafios enfrentados pela equipe de desenvolvimento e pelo
ambiente de negcios, nos quais so operados, origina o nvel correto de
formalidade de processo. (POLLICE, 2002, p.4)

Os documentos produzidos, durante uma anlise de requisitos servem, na

maioria das vezes, como ponto de partida para o desenvolvimento. Porm, este processo de
anlise e produo de especificao leva tempo. Mas o fato que, quase impossvel ns
pensarmos em analisar requisitos sem a existncia de algum artefato de anlise. Sommerville,
um dos grandes cones na rea de Engenharia de Software, diz que o processo de engenharia
de requisitos "leva produo de uma documentao de requisitos, que a especificao para
o sistema" (SOMMERVILLE, 2003).
Mas o que fazer quando o tempo exguo e as entregas de software devem ser
realizadas em um curto espao de tempo? As metodologias geis surgem neste cenrio, o qual
veremos atravs de uma metodologia especfica, na prxima seo.

16

3 SCRUM: UMA ABORDAGEM INICIAL

Algumas questes de anlise, como vimos anteriormente, e a necessidade de

entregas rpidas ao cliente, bem como a organizao no processo de software, motivaram, em
2001, a elaborao do Manifesto gil4 e, com base nos seus valores e princpios, definiu-se o
Scrum5, que se prope a ser um processo gil de desenvolvimento de software, sugerindo
mtodos e aes de trabalho que sero realizadas no decorrer de todo o processo de
desenvolvimento de software.
Bem, se por um lado, precisa-se de qualidade e planejamento no
desenvolvimento de software, por outro lado, o mercado atual e emergente nos impulsiona a
ter resultados rpidos. As metodologias geis surgem para tentar resolver esta problemtica,
por isso, acredita-se que com um bom processo a chance de se obter o sucesso nos projetos
claramente maior (PEREIRA, 2011).
dentro das frameworks geis que surge o Scrum, que trabalha, dividindo-se o
tempo em pequenas e curtas iteraes de durao fixa (geralmente duas a quatro semanas),
com cdigo potencialmente entregvel demonstrado depois de cada iterao, segundo
Kniberg. A otimizao do plano de entrega e atualizao constante de prioridades com o
cliente, tambm faz parte da metodologia. Isto traz um processo reajustvel, com
retrospectivas depois de cada iterao, e trabalho constante no que o cliente deseja.
Porm, a framework Scrum prev a produo somente da documentao
necessria, j que o foco atender os requisitos do cliente e no o desenvolvimento de um
processo perfeito. Isto traz alguns malefcios, como falta de material de consulta para novos
membros da equipe e dificuldades em dar estimativas mais complexas para o produto que ser
entregue, entre outras dificuldades.
Antes de verificarmos esta possvel "problemtica", vejamos, objetivamente,
como funciona a framework Scrum, no que se refere ao dia a dia de uma equipe de

O Manifesto para o Desenvolvimento gil de Software, frequentemente chamado apenas de Manifesto gil,
e o termo Desenvolvimento gil passaram a descrever abordagens de desenvolvimento que seguissem alguns
princpios, dentre eles a agilidade na entrega de solues para o cliente.
5
Scrum uma framework gil para gerncia de projetos. Ela baseada em ciclos de dias chamados Sprints,
onde se trabalha para alcanar objetivos bem definidos. Estes objetivos so representados no Product Backlog,
uma lista de coisas para fazer, que constantemente atualizada e repriorizada.

17

desenvolvimento. Ser uma abordagem rpida, pelo fato do presente trabalho no se dedicar
ao "esgotamento" da metodologia Scrum.
3.1 O Scrum
A origem do nome Scrum, geralmente atribuda jogada do Rugby, esporte
americano, na qual alguns jogadores se juntam em um crculo, a fim de atingir um objetivo
definido, aps uma penalidade no jogo. Porm, o nome foi utilizado pelos japoneses Hirotaka
Takeuchi e Ikujiro Nonaka, antes disso, para descrever um tipo de processo de
desenvolvimento de um produto utilizado no Japo (CMARA, 2001).
O Scrum, como framework, foi criado por Ken Schwaber e Jeff Sutherland em
1995, e o Ken Schwaber fala que o Scrum um framework para gesto de equipes envolvidas
na execuo de tarefas, focada em entregar ao cliente, no menor tempo possvel, aquilo que o
mesmo est esperando (SCHWABER, 2001). O fato que o Scrum baseia-se no Manifesto
gil, principalmente nos pontos abaixo:

Os indivduos e as interaes so mais importantes que os processos e as

ferramentas;

A colaborao com o cliente mais eficiente que aquilo que est escrito no
contrato;

Mudanas so encorajadas nas tarefas previamente definidas;

Prefere-se software funcionando, no menor tempo, a possuir uma extensa

documentao.

3.2 Alguns conceitos importantes

Para entendermos o Scrum, precisamos entender alguns conceitos inerentes
metodologia. Com a viso destes conceitos, poderemos prosseguir neste trabalho:
3.2.1 Product Backlog:
O Product Backlog, ou mesmo Backlog, a lista de tarefas que o cliente deseja
para o seu software. Ele deve ser constantemente atualizado por uma pessoa, denominada pelo
Scrum, de Product Owner (PO). O Backlog composto por requisitos, que refletem a
necessidade do cliente. Estes requisitos so novas funcionalidades, novos comportamentos, e
alguns ajustes a serem realizados no sistema.
18

3.2.2 Sprint:
Uma Sprint o ciclo do Scrum, que geralmente dura de 2 (duas) a 4 (quatro)
semanas. Dentro da Sprint so feitas, a anlise, o desenvolvimento e os testes das estrias. o
dia a dia do desenvolvimento.
3.2.3 Scrum Team:
Este o nome dado a um time de desenvolvimento no Scrum. Em um projeto
podem existir vrios times, que iro desenvolver, corrigir, testar e entregar as funcionalidades
em uma cerimnia da qual falaremos depois.
3.2.4 Scrum Master:
o elo de ligao mais forte entre o PO e os times. Um Scrum Master deve
garantir o funcionamento da Sprint nas equipes, evitando impedimentos e gerenciando, na
medida do possvel, os atropelos que possam surgir.
3.3 Algumas ferramentas de apoio
3.3.1 Taskboard/Dashboard:
O quadro, conhecido por alguns tambm como quadro Kanban (KUKIER,
2011) , talvez, o maior identificador visual da metodologia Scrum. Nele so colados post-its
com as tarefas a serem executadas pelos membros da equipe. Apesar de cada empresa de
desenvolvimento ter as suas prprias sees no quadro, trs sees bsicas geralmente
existem: planejado, iniciado e pronto (Figura 1).

19

Figura 1 - Taskboard Scrum

Fonte: http://mudandoumapequenaempresa.blogspot.com/2007/11/livro-de-referncia
http://mudandoumapequenaempresa.blogspot.com/2007/11/livro
referncia-para-scrum.html

O Taskboard
askboard um excelente indicador para o Scrum Master,
Master porque atravs
dele o mesmo pode saber o que est sendo feito no momento da Sprint,
Sprint bem como para os
prprios integrantes dos times Scrum se auto-gerenciarem.
3.3.2 Burndown Chart:
Chart
um grfico bem interessante
interessante (Figura 2) que indica se o andamento das
estrias esto de acordo com o planejado nas cerimnias, que iremos falar mais frente.

Figura 2 - Burndown Chart

Fonte: http://www.scrumalliance.org/articles/55

20

3.4 Fluxo do Scrum

Baseados no grfico da figura 3, iremos resumidamente, falar sobre o que
acontece na Sprint e fora dela.

Figura 3 - Processo de desenvolvimento com Scrum

Fonte: http://blog.marciel.org/?tag=scrum

3.4.1 Reunio de planejamento

Esta fase do Scrum realizada aps a priorizao das estrias/bugs
estrias/
pelo PO.
Divide-se
se em dois momentos:
Sprint Planning 1 - Cerimnia, geralmente com o PO, que apresenta as tarefas
j priorizadas para a equipe;
Sprint Planning 2 - Cerimnia feita entre os membros de cada equipe, onde os
mesmo selecionam as tarefas apresentadas pelo PO, para a sua equipe. Neste momento,
momento eles
tero que fazer uma estimativa de cada tarefa, no muito precisa, mas que permita ao Scrum
Master saber se estas estrias iro caber na Sprint.
Ainda na Sprint Planning 2, os integrantes dos times iro dividir as estrias em
tarefas menores, atravs dos post-its, que so fixados no taskboard na seo Planejado. Em
cada post-it dever ter uma descrio sucinta, porm clara, do que deve ser feito.
Bem, em se tratando da
d documentao gerada aps a fase de anlise, o nico
artefato que temos na metodologia,
metodologia basicamente, so os post-its
its no quadro. Alguns
evangelistas, defensores de metodologias geis,, bem como uma parte dos consultores de

21

MPS.Br6, que orientam a implantao do Scrum, afirmam que, o que existe nos post-its deve
ser suficientemente necessrio para o desenvolvimento, no precisando de outro mecanismo
para tal.
Um outro ponto muito importante nas reunies de planejamento, o fato de
que praticamente tudo que se define nas Sprint Plannings 1 e 2 so a base para o
desenvolvimento. Kniberg fala sobre o assunto, frisando:
O planejamento de Sprint uma reunio crtica, provavelmente o evento mais
importante no Scrum (na minha opinio, claro). Um encontro de planejamento de
Sprint mal feito pode bagunar totalmente um Sprint. (KNIBERG, 2007, p.25)

Em outras palavras, caso exista um erro de estimativa ou mesmo especificaes

em post-its mal feitas, o andamento da Sprint pode ser comprometido.
3.4.2 Sprint e Reunio Diria
Aps

as

duas

cerimnias

de

planejamento

realizadas,

comea

desenvolvimento nos times, dentro da Sprint. Uma outra cerimnia tambm realizada, s que,
diariamente, a Daily Scrum. uma reunio rpida, de 10 (dez) a 15 (quinze) minutos, no
mximo, na qual cada integrante do time responde a trs perguntas bsicas:

O que foi feito ontem?

O que deve ser feito hoje?

H alguma tarefa impedida de ser executada? Quais so as razes?

A Daily Scrum tambm um bom momento para revisar as tarefas do

taskboard. Neste momento, todo o time fica sabendo o que est acontecendo na equipe, e
pode cobrar, de todos os integrantes, os resultados.
3.4.3 Reunio de reviso
Esta cerimnia no Scrum com a presena do PO, na qual as estrias so
apresentadas e o PO aceita ou rejeita cada implementao.

Melhoria de Processos do Software Brasileiro simultaneamente um movimento para a melhoria da

qualidade (Programa MPS.BR) e um modelo de qualidade de processo (Modelo MPS) voltada para a realidade
do mercado de pequenas e mdias empresas de desenvolvimento de software no Brasil.

22

3.4.4 Reunio de retrospectiva

Esta a ltima cerimnia antes da entrega do produto para o cliente. um
momento de avaliar o que aconteceu na(s) Sprint(s) passada(s) e levantar os pontos positivos
e negativos, verificando, no caso dos negativos, qual a lio aprendida. importante a
participao de todos os times e o Scrum Master, nesta reunio.
Bem, nivelando este conhecimento bsico sobre o Scrum, iremos avaliar a sua
aplicao em ambientes com sistemas de grande porte e/ou estrias complexas.

23

4 ESTIMAR SEM CONHECER, EIS A QUESTO

notvel que as metodologias geis foram criadas para preencher uma lacuna
nos cenrios atuais de desenvolvimento. Grande parte dos estudiosos atribuem isso ao fato de
que elas produzem uma quantidade menor de artefatos e formalismos, agilizando o processo,
como um todo. Mas as metodologias geis conseguem resolver todos os problemas
relacionados ao desenvolvimento? claro que no. Um dos mais renomados engenheiros de
software da histria, Frederick Brooks, disse certa vez, em um de seus escritos:
[...] no h qualquer tecnologia, tcnica ou prtica que incremente em grande
magnitude a produtividade, confiabilidade ou simplicidade no desenvolvimento de
software (BROOKS, 1987, p.10)

Isto s refora a idia de que, o objetivo de uma equipe de software,

aproveitar todos os benefcios das metodologias disponveis a fim de agilizar o processo de
produo de sistemas com qualidade. No existe uma nica metodologia que resolva todos os
problemas para todos os cenrios possveis de desenvolvimento. Em outras palavras, como
diria o prprio Brooks, no existe uma "bala de prata", capaz de solucionar todas as
dificuldades de todos.
E trazendo para a metodologia Scrum, como utilizar o seu potencial mximo
em benefcio do processo de desenvolvimento? A metodologia Scrum, por si s, j tem uma
certa organizao (cerimnias), realiza um controle visual, prega o auto-gerenciamento e a
viabilizao de entregas rpidas. Porm, como a metodologia se comporta quando aparecem
estrias de alta complexidade na Sprint Planning 1? Esta uma realidade em empresas de
mdio/grande porte e/ou com sistemas complexos, no que tange ao negcio.
Vamos exemplificar com um caso fictcio, porm prtico. Vamos assumir que,
uma dada empresa trabalha com produo de software (automao comercial) de uma grande
rede de supermercados, que abrange 3 (trs) estados da federao, com mais de 70 (setenta)
unidades e cerca de 500 (quinhentos) PDVs (pontos de venda).
Esta rede de supermercados, atravs de sua rea de TI e dirigentes, fez uma
solicitao de melhoria para o software, no qual o mesmo deveria aumentar o nvel de
segurana em compras com cheques, e o sistema deveria realizar o reconhecimento facial de
24

cada cliente, quando esta modalidade de venda (cheque) fosse escolhida. Estamos partindo do
pressuposto que esta funcionalidade foi requisitada pelo cliente e o mesmo no abriu mo
desta solicitao, aguardando a implementao o mais rpido possvel.
No outro lado, a empresa de desenvolvimento, que trabalha com o Scrum, tm
as Sprints no tempo de 3 (trs) semanas, mas nenhum desenvolvedor tem know-how7 em
reconhecimento facial.
Porm, fato que o desenvolvimento desta funcionalidade no levar um
tempo menor que uma Sprint, nem mesmo se pode ter uma estimativa precisa para esta
estria, na cerimnia Sprint Planning 2.
Neste caso, o Scrum Master e o PO tm uma difcil misso, que analisar o
que pode ser feito nesta Sprint, e ainda assim ficar difcil o PO se programar para uma
entrega de software ao cliente, porque nem ele e nem a equipe tm previses concretas a
oferecer.
No caso acima, temos dois problemas a destacar:
1. Como estimar sem conhecer o "terreno" no qual se est pisando?
2. Como deixar um "legado", para os desenvolvedores futuros, acerca da forma
de implementao daquela nova tecnologia?
Estas so duas questes que, no mnimo, necessitam de uma ateno para este
cenrio de desenvolvimento, to comum em sistemas grandes. No exemplo acima,
necessrio um plano de ao que possibilite:

atender ao cliente (mais importante);

disseminar o conhecimento tcnico sobre a estria, entre a equipe;

dar condies ao PO de planejar quando sair a implementao, para

negociaes com o cliente final, e;

ser gil.

Bem, reconhecemos que esta uma difcil tarefa, porm, um dos pontos acima
deve ser priorizado: dar condies ao PO de planejar quando sair a implementao,
7

O know-how, ou conhecimento processual, o conhecimento de como executar alguma tarefa.

25

para negociaes com o cliente final. Ou seja, estimar corretamente (com margem mnima
de erro) a fim de facilitar o planejamento das Sprints futuras. Estimar preciso.
Como a quantidade de material terico, sobre este assunto especfico, no to
comum, foi interessante avaliar o procedimento praticado por algumas empresas em Joo
Pessoa-PB, que desenvolvem software, ao se depararem com circunstncias semelhantes s do
exemplo citado.

26

5 A REALIDADE DO DESENVOLVIMENTO DE SOFTWARE EM

ALGUMAS EMPRESAS DE JOO PESSOA-PB

Para avaliar a problemtica neste cenrio, uma pesquisa de campo foi

realizada, em 12 (doze) empresas de desenvolvimento de software situadas em Joo PessoaPB, no perodo entre outubro e novembro de 2011. A pesquisa, no modo questionrio
(anexos), apresentou 11 (onze) questes, entre objetivas e subjetivas. Das 12 (doze) empresas,
obtivemos a resposta da metade, 6 (seis), e os dados seguem abaixo. A identificao das
empresas foi preservada.
O objetivo da pesquisa era avaliar o porte das empresas e, de forma objetiva,
verificar qual o procedimento utilizado para tarefas de alta complexidade e de grande porte.
Perguntas como: "qual a metodologia utilizada" e "qual o ganho que a mesma trouxe para a
produo de software", foram utilizadas tambm.
Relacionado classificao das empresas, no quesito porte, foi utilizada a
abordagem abaixo, somente para diferenciar os grupos de empresa pesquisadas. A frmula
utilizada, criada para este trabalho, foi a seguinte:
PORTE = (Qtde. de func. na empresa x 1) + ((Qtde. analistas + Qtde. desenvolvedores) x 2)
Esta frmula serviu somente para categorizar, as empresas envolvidas na
pesquisa, por tamanho, a fim de avaliarmos o desenvolvimento de software em ambientes de
desenvolvimento com um porte considervel, o qual chamamos aqui de GRANDE. A
quantidade de analistas e desenvolvedores foi considerada com peso 2 (dois), porque
entendemos que, para quantificar (neste trabalho) o tamanho de uma empresa, a quantidade de
membros na equipe, que est diretamente envolvida com o desenvolvimento, tem um peso
maior. Vale ressaltar que a frmula supracitada no serve para afirmao cientfica alguma.
Baseado no resultado do porte de cada empresa, foi gerada a seguinte
classificao:

27

PORTE

CLASSIFICAO

1 a 24

PEQUENO

25 a 99

MDIO

>= 100

GRANDE
Tabela 1 - Classificao do porte

Reforando, nesta classificao, o porte da empresa no est diretamente ligado

quantidade de todos os funcionrios, mas principalmente quantidade de analistas e
desenvolvedores que, na proporo, tm peso duplicado.
A primeira fase da anlise foi classificar as empresas quanto ao porte das
mesmas. Segue tabela informativa:
QTDE. DE
EMPRESA

FUNCIONRIOS NA
EMPRESA

QTDE. DE ANALISTAS + QTDE.

DE DESENVOLVEDORES

PORTE

CLASSIFICAO

EMPRESA A

17

12

41

MDIO

EMPRESA B

10

18

PEQUENO

EMPRESA C

100

108

GRANDE

EMPRESA D

150

50

250

GRANDE

EMPRESA E

80

45

170

GRANDE

EMPRESA F

PEQUENO

Tabela 2 - Classificao das empresas

Dentro de nossa abordagem, iremos dar mais nfase (inicialmente) s empresas

C, D e E, que foram classificadas como empresas de porte grande e que, como veremos na
tabela 3, tem maiores chances de utilizar alguma metodologia de desenvolvimento.

28

QUAL A METODOLOGIA UTILIZADA

EMPRESA

CLASSIFICAO

EMPRESA A

MDIO

No existe metodologia formalmente

EMPRESA B

PEQUENO

No existe metodologia formalmente

EMPRESA C

GRANDE

No existe metodologia formalmente

EMPRESA D

GRANDE

SCRUM

EMPRESA E

GRANDE

SCRUM

EMPRESA F

PEQUENO

No existe metodologia formalmente

PARA O DESENVOLVIMENTO?

OBSERVAES

Softwares terceirizados

Tabela 3 - Utilizao de metodologias de desenvolvimento

A primeira anlise que fazemos, a grosso modo que, quanto maior for o
tamanho da empresa, maior a sua preocupao com a definio de alguma metodologia que
contribua com a produo de software. Exceto 1 (uma), que optou em no desenvolver
softwares, preferindo a aquisio de terceiros.
Porm, como o nosso trabalho relacionado com a estimativa de estrias
grandes em um ambiente complexo de desenvolvimento, importante verificar qual o
procedimento, que as empresas de porte grande e que utilizam a metodologia Scrum, utilizam
para este cenrio.
Duas perguntas foram feitas, relacionadas a este assunto e, baseado nelas,
iremos caminhar. Vamos limitar o escopo das respostas s duas empresas de porte grande que
utilizam a metodologia Scrum. As perguntas realizadas foram:
1. Qual o procedimento do desenvolvimento, quando se v diante de uma
implementao grande (complexidade e tempo)? e;
2. De que maneira o procedimento, citado na questo anterior, atende
demanda de implementaes grandes?
Vejamos as respostas das questes na tabela 4:

29

1. PROCEDIMENTO REALIZADO EM

EMPRESA

EMPRESA D

2. ATENDE DEMANDA?

IMPLEMENTAES GRANDES
Fazemos estrias de anlise para se identificar os

Atende, mas com

pormenores do esforo; elabora-se um documento de

muitos atropelos

especificao completo; divide-se tudo que foi levantado

em

etapas;

considerando

parte-se
a

para

construir

fragmentao

identificada

soluo
como

necessria.
EMPRESA E

A implementao dividida em tarefas, das quais todos

Atende perfeitamente

os membros da equipe, com capacidade nivelada, pegam

as devidas atividades e as desenvolvem no tempo
definido, em anlises.
Tabela 4 - Procedimentos para estrias grandes

interessante perceber que as duas empresas tm procedimentos similares, no

que se refere a implementaes grandes. A complexidade de algumas estrias "foram"
algumas equipes de desenvolvimento que utilizam o Scrum, a buscar adequaes na
metodologia, a fim de conseguir xito na entrega das funcionalidades.
Uma metodologia de desenvolvimento bem conhecida, e que pode ser bastante
forte na produo de artefatos, o RUP, e a mesma prov alguns documentos que auxiliam na
anlise de alguns requisitos do usurio.

30

6 O DOCUMENTO DE ESPECIFICAO NA METODOLOGIA SCRUM

O RUP, Rational Unified Process, um framework criado pela Rational

Software, que atualmente subsidiria da IBM (PINTO, 2011), e uma metodologia iterativa
de desenvolvimento que pode ser customizada para diversos tipos e tamanhos de produtos
(VASCO, 2005, p.2). O RUP fala bastante sobre a anlise de requisitos grandes. Alguns
desenvolvedores e analistas que trabalham com RUP, acham que o mesmo a soluo para
todos os problemas, neste cenrio (POLLICE, 2002).
Existe um grupo de pessoas que defendem tambm que, pelo fato do RUP ser
um framework adaptvel, o mesmo pode ser mais gil, mesmo com a grande quantidade de
artefatos de anlise que o mesmo produz. Martin Fowler, um dos engenheiros de software que
assinou o Manifesto gil (j comentado neste trabalho), falou em um de seus artigos:
Minha experincia com RUP me diz que o seu problema so as suas variaes
infinitas [...] O que me impressionou foi o desejo de algumas pessoas, em aceitar o
RUP como o nico processo, e que levou a um resultado onde as eles podem fazer
praticamente qualquer coisa e cham-lo RUP [...] Apesar de tudo isso h algumas
pessoas muito fortes na comunidade RUP que esto muito alinhadas com o
pensamento gil (FOWLER, 2005, pargrafo 130, traduo minha).

Em outras palavras, possvel utilizar o RUP atrelado a alguns conceitos geis,

como: iterao, diminuio de artefatos, etc., mas este no o objetivo deste trabalho. O
grande benefcio do RUP, para o nosso estudo, so os artefatos de anlise que so
produzidos atravs dele, dentre eles, o SAD (Software Architeture Document).
O Documento de Arquitetura de Software (SAD), d um panorama geral da
arquitetura do sistema, descrevendo diversos aspectos do sistema. Por exemplo, caso o SAD
fosse um artefato produzido pela empresa fictcia citada no captulo 4 deste trabalho, o mesmo
iria trazer as questes tcnicas, casos de uso8 e a lgica de toda a funcionalidade do
reconhecimento facial para compras com cheques, que foi o caso citado.

Na Engenharia de Software, um caso de uso (ou use case) um tipo de classificador que representa uma
unidade funcional provida pelo sistema, subsistema, ou classe. bem descrito na UML (Unified Modeling
Language), que uma linguagem de modelagem visual, e pode ser representado por uma elipse contendo,
internamente, o nome do caso de uso.

31

O SAD um exemplo de um documento de especificao do RUP, e que pode

ser adotado por equipes Scrum para o desenvolvimento de grandes estrias. O importante,
nesta fase de anlise, definir claramente o que deve ser feito nas prximas Sprints pelos
times de desenvolvedores Scrum, independente do modelo utilizado.
6.1 Proposta de documento
Verificou-se que, para grandes requisitos, quer seja em tempo ou
complexidade, a adoo de um documento/artefato, que direcione as equipes, muito
importante. Baseado nesta necessidade, foi elaborado, neste trabalho, um modelo de
documento, bastante simples, mas que pode ser utilizado por equipes de desenvolvimento
para especificaes mais detalhadas do que, simplesmente, os post-its no taskboard.
O objetivo aqui prover uma modesta soluo para que os analistas das
equipes possam estimar o esforo para o desenvolvimento, facilitando o trabalho, dividindo
tarefas, tentando antecipar perigos que s seriam detectados no desenvolvimento, e
produzindo um documento para futuras consultas daqueles que ainda no tem o conhecimento
sobre aquela rea do sistema.
Para exemplificar este documento, fez-se o uso do caso fictcio de
reconhecimento facial de clientes em compras com cheques, levantado no captulo 4 deste
trabalho. O modelo deste documento tambm est disponvel nos anexos (anexo 2).
6.1.1 Ttulo, nmero e analista(s) envolvido(s):
Aqui estaro ttulo do requisito, nmero de controle e analista(s) envolvido(s)
na especificao desta estria. Para o nosso caso prtico, o ttulo ser "Reconhecimento facial
em vendas com cheques", o nmero "#5438" e os analistas envolvidos "Joo da Silva /
Belarmino Cassandro". basicamente o cabealho da estria de anlise.
6.1.2 Descrio principal:
Aqui descrito, de forma sucinta, porm clara, o que o cliente realmente deseja
com esta funcionalidade. No nosso caso, o reconhecimento facial para a venda com cheques:

O Sistema SIS-SUPER, deve, a partir de agora, utilizar o reconhecimento

32

facial de cada cliente, quando a modalidade de venda cheque for escolhida.

As outras formas de pagamento no precisam desta funcionalidade, por
enquanto.

6.1.3 Limitaes tcnicas (caso existam):

Tudo o que houver relacionado a limitaes tcnicas, necessidade de
treinamento, questes de legislao, dificuldades preliminares encontradas, etc. Tudo que for
causar algum tipo de barreira para o problema ser solucionado:

Questes de hardware; cmeras para leitura de face; conhecimento sobre a

integrao do reconhecimento com a ferramenta de desenvolvimento.

6.1.4 Especificao:
Aqui constar a especificao mais detalhada do que deve ser feito. Detalhes
importantes no podem ser omitidos, porque serviro de base para qualquer desenvolvedor
implementar as estrias criadas pelo PO, a partir desta especificao:
1. Anlise de outras solues no mercado de reconhecimento facial:
Verificar na internet;
Contactar empresas especializadas no fornecimento de hardware;
Verificar compatibilidade do hardware com a linguagem de
programao utilizada.
2. Cotao de cmeras para o desenvolvimento:
Acionar responsveis para aquisio de hardware;
3. Criao de componentes que integraro o reconhecimento facial na
linguagem de programao:
Deixar componentes/funes modularizados;
Criar repositrio comum para futuras reutilizaes.
4. Criar/alterar tabelas no BD para autenticao facial:
Criar tabela para guardar LOGs para cada autenticao;
Criar campo na tabela de clientes, que indicar o hash de
reconhecimento facial nico;
33

 Criar atributo na tabela de cheques, indicando a obrigatoriedade de

reconhecimento facial;
Criar parmetro geral no sistema que dir se os PDVS iro trabalhar
cm reconhecimento facial;
Criar atributo do cliente para isent-lo de reconhecimento facial, s
permitido via administrador do sistema.
5. Alterar tela de cadastro de clientes para cadastrar hash de reconhecimento
facial:
Colocar opo na manuteno de clientes para receber
reconhecimento facial;
Colocar opo para remover reconhecimento facial;
Colocar opo para atualizar o reconhecimento facial;
Colocar atributo, por cliente, para isent-lo do reconhecimento.
6. Altera tela do PDV para receber reconhecimento facial para clientes com
cheque:
Integrar tela de vendas c/ cheque com o componente desenvolvido
para reconhecimento facial;
Colocar opo para cadastrar reconhecimento facial para hashs no
cadastrados.
Para cada tpico so especificados sub-tpicos, que descrevero as atividades a
serem realizadas.
6.1.5 Testes:
uma rea importante, na qual o analista envolvido na especificao ir
antecipar alguns casos de testes que atendero funcionalidade. No necessrio aqui riqueza
de detalhes e nem casos de testes complexos, mas testes bsicos sobre a funcionalidade do
sistema, lembrando que a filosofia da metodologia gil continua a ser premissa para o
trabalho.

1. Testar cadastro de reconhecimento facial no cadastro de clientes;

2. Testar cadastro de reconhecimento facial no PDV;

34

3. Testar vendas com cheques, como um todo.

6.1.6 Estimativa inicial:

Esta, talvez, seja uma das reas mais importantes para o PO, porque atravs
dela que o mesmo poder planejar os prximos ciclos de desenvolvimento.

Horas de implementao/documentao/testes: 100 horas

Caso seja possvel, o ideal seria que a estimativa fosse por tpico da
especificao, a fim de facilitar o dimensionamento.
6.2 Como aplicar o documento nas Sprints Scrum
A aplicao deste modelo, poderia se encaixar em uma ou mais Sprints e, tanto
para o PO quanto para o Scrum Master, ficaria bastante claro que: quando existirem
dificuldades para estimativas; estrias grandes aparecerem na Sprint Planning 1; quando
houver falta de conhecimento da equipe relacionada a alguma inovao tecnolgica ou
legislao inesperada; ou mesmo quaisquer outros motivos que impossibilitem dimensionar o
tamanho do esforo para a implementao de uma certa funcionalidade, seria necessrio, no
"retirar" a estria da Sprint, mas coloc-la como uma anlise (em princpio) e o fruto desta
estria seria um documento de especificao com as informaes de como implementar,
bem como a estimativa, que ajudar o PO a planejar as estrias para as prximas Sprints
O documento supracitado servir de base para os membros da equipe dividirem
os post-its nas Sprints, que sero implementadas as tarefas. Em uma anlise abrangente, cada
tpico poderia ser uma estria e, como sugesto, poderemos colocar em cada post-it, 1 (um)
sub-tpico da especificao, caso o mesmo possa ser executado em 1 (um) dia por
desenvolvedor. Sendo assim, para o tpico 1, da especificao no exemplo anexo, teramos:

1. Anlise de outras solues no mercado de reconhecimento facial:

Verificar na internet;

Contactar empresas especializadas no fornecimento de hardware;

35

Verificar compatibilidade do hardware com a linguagem de programao

utilizada.

Neste caso, o tpico 1 (um) seria transformado em uma estria, e cada subtpico em uma tarefa (post-it) para ser fixado no taskboard:
Estria: Anlise de outras solues no mercado
Post-its:
Verificar na
internet

Contactar
empresas
especializadas no
fornecimento de
hardware

Verificar
compatibilidade
do hardware com
a linguagem de
programao
utilizada.

O interessante nesta abordagem, que o documento de especificao, que

serviu para estimar o tempo e entender melhor o que se deve fazer, no veio para mudar ou
concluir que a metodologia Scrum no serve para estrias de cunho complexo, mas, pelo
contrrio, veio para somar metodologia, fornecendo informaes importantes para a Sprint
Planning 2 e, consequentemente, para o melhor andamento da Sprint.

36

7 CONSIDERAES FINAIS

O Scrum sim uma excelente metodologia de trabalho e, como filosofia de

trabalho, contribui (e muito) para a disseminao do conhecimento entre as equipes, devido
quantidade de cerimnias que ela possui e que foram o repasse natural das informaes. E
embora o "Scrum dependa do auto-gerenciamento, bem como de regras simples e orientao
constante" (SCHWABER, 2001), os times que trabalham com esta metodologia, geralmente,
falam do grande benefcio que as reunies produzem, bem como do repasse de conhecimento
e os ganhos que o Scrum acarreta.
O fato de que as metodologias geis trouxeram um novo paradigma no
desenvolvimento de software, incontestvel. Porm, certo tambm que a aplicao das
metodologias geis e, no nosso caso especfico, o Scrum, traz consigo uma reduo de
artefatos, que poderiam, em determinados momentos, contribuir com a agilidade no
desenvolvimento. Parece um contra-senso, mas no . A aplicao do Scrum, sem nenhuma
adequao a requisitos de porte considervel, pode gerar problemas de diversos tipos, os quais
j citamos aqui, como: dificuldades em estimativas, repasse de conhecimento, entre outros.
Metodologias geis como o XP9, e tambm o Scrum, em alguns tipos de
implementaes, concentram o conhecimento em algumas cabeas das equipes, o que no
bom. Sobre isso, Carlos Vasco, mencionando a filosofia gil e o XP, exemplifica:
"A pouca evidncia de artefatos do XP, com foco em estrias de usurio e cdigo,
visto como um fator que aumenta o risco do projeto, o conhecimento fica vinculado
aos desenvolvedores e ao cdigo" (VASCO, 2005, p.5)

Este trabalho tambm foi importante porque trouxe a experincia de algumas

empresas da cidade de Joo Pessoa-PB, que trabalham com desenvolvimento de software de
alguma forma (rea fim ou meio). E foi importante constatar, por meio desta pesquisa que, a
dedicao da equipe que trabalha com o Scrum em tratar requisitos de alta complexidade,
deve ser diferenciada. Em outras palavras, a anlise dos requisitos, bem como a especificao,
no deve ser vista apenas como post-its pregados no quadro taskboard. algo alm disso.
9

XP ou Programao extrema (do ingls eXtreme Programming), uma metodologia gil para equipes
pequenas e mdias e que iro desenvolver software com requisitos vagos e em constante mudana. Para isso,
adota a estratgia de constante acompanhamento e realizao de vrios pequenos ajustes durante o
desenvolvimento de software.

37

Um outro ponto positivo deste trabalho foi a criao de um modelo de

documento (artefato) de especificao. E este artefato, mesmo que simples, pode servir de
base para outras pesquisas, bem como ser comparado a artefatos de outras metodologias, a
fim de melhor-lo para a adeso de um padro, se que podemos chamar assim um
documento desta natureza. Ou seja, este trabalho pode ser um ponto de partida.
Com certeza, parafraseando o Frederick Brooks, e citando o Gary Pollice, "no
h um nico processo adequado para todas as situaes, reduzido ou diferente" (POLLICE,
2002, p.4). O grande desafio, na anlise de sistemas e gerenciamento de projetos, aproveitar
o mximo das metodologias que se apresentam para ajudar, e conseguir extrair todo o
potencial dos analistas, desenvolvedores, testadores, engenheiros e arquitetos de software, a
fim de obter o sucesso na produo de sistemas. A meta : menos bugs, mais qualidade,
menos tempo para entrega, mais clientes satisfeitos, menos problemas no processo e mais
lucros para a empresa, consequentemente. Este seria o "mundo ideal" na produo de
software, talvez considerado inalcanvel, mas no podemos deixar de "perseguir" este
caminho.

38

REFERNCIAS

AKITA,

Fabio.

Desmistificando

mtodo

Kanban.

Disponvel

em:

<http://info.abril.com.br/noticias/rede/gestao20/gestao/desmistificando-o-metodo-kanban/>.
Acessado em: 22 de maro de 2011.
BEEDLE, Mike et al. Manifesto para o desenvolvimento gil de software. Disponvel em:
<http://www.manifestoagil.com.br/>. Acessado em 25 de outubro de 2010.
BROOKS, Frederick P. Essence and Accidents to Software Engineering. IEEE Computer,
1987. Vol.4, n. 3.
CMARA,

Fbio.

SCRUM:

Uma

Metodologia

gil.

Disponvel

em:

<http://imasters.com.br/artigo/10699/gerencia/scrum_uma_metodologia_agil/>. Acessado em:

12 de novembro de 2011.
FOWLER,

Martin.

The

New

Methodology

(2005).

Disponvel

em:

<http://www.martinfowler.com/articles/newMethodology.html>. Acessado em: 18 de novembro

de 2011.

KNIBERG, Henrik. SKARIN, Mattias. Kanban e Scrum: obtendo-se o melhor de ambos.

EUA: InfoQ Enterprise Software Development, 2009.
________. Scrum e XP direto das Trincheiras: Como ns fazemos Scrum. Editores: Diana
Plesa; Felipe Rodrigues. 2007 (Disponvel em: http://www.infoq.com).
KRUCTHEN, Philippe. Introduo ao RUP Rational Unified Process. Rio de Janeiro:
Editora Cincia Moderna Ltda., 2003.
KUKIER, Daniel. Kanban. Disponvel em: <http://blog.locaweb.com.br/metodologiasageis/kanban/>. Acessado em 13 de novembro de 2011.
PAIVA, Nicholas A. M. da S. Implantao e avaliao dos resultados do framework
Scrum para o gerenciamento de tarefas no ambiente do setor de suporte tcnico de

39

tecnologia da informao do SETURN/NatalCard, aps a implantao da bilhetagem

eletrnica. Natal: Universidade Gama Filho, 2010. 42 p.
PELOCHE,

Luciano.

Lean

para

todos.

Disponvel

em:

<http://leanparatodos.blogspot.com/2011/01/kanban-na-praia.html>. Acessado em: 22 de

maro de 2011.
PEREIRA, Flvia Cruz. A sndrome da bala de prata na gesto de projeto. So Paulo:
Revista MundoPM, janeiro de 2011. pgs. 40 a 45.
PINTO, Srgio Crespo C. S. RUP x Metodologias geis: uma anlise crtica. Disponvel em:
<http://unisinos-eslp.blogspot.com/2011/04/rup-x-metodologias-ageis-uma-analise.html>.
Acessado em: 18 de novembro de 2011.
PITTY.

Estimando

pelo

tamanho

no

pela

durao.

Disponvel

em:

<http://exocortex.com.br/blog/2009/10/estimando-pelo-tamanho-e-no-pela-durao/>. Acessado
em: 22 de maro de 2011.
POLLICE, Gary. Utilizando o Rational Unified Process para Pequenos Projetos:
Expandindo no eXtreme Programming. EUA: Rational Software White Paper, 2002.
RAMOS,

Rafael.

Uma

introduo

ao

Scrum.

Disponvel

em:

<http://qualiblog.wordpress.com/2009/10/08/uma-introducao-ao-scrum/>. Acessado em: 26

de outubro de 2010.
SCHWABER, Ken. BEEDLE, Mike. Agile Software Development with Scrum (Series in
Agile Software Development). New Jersey: Prentice Hall, 2001.
SOMMERVILLE, Ian. Engenharia de Software. So Paulo: Addison Wesley, 2003.
TELES, Vincius Manhes. Extreme Programming. So Paulo: NOVATEC Editora, 2004.
VASCO, Carlos G. VITHOFT, Marcelo Henrique. ESTANTE, Paulo Roberto C.
Comparao entre Metodologias RUP e XP. Curitiba: PUCPR, 2005.

40

ANEXOS

41

ANEXO 1 - QUESTIONRIO APLICADO EM ALGUMAS EMPRESAS

COM DESENVOLVIMENTO DE SOFTWARE EM JOO PESSOA
QUESTIONRIO APLICADO NAS EMPRESAS DA REA DE TI
DADOS SOBRE A EMPRESA/SETOR DE DESENVOLVIMENTO
1. Quantidade de funcionrios na empresa: ___
2. Quantidade de desenvolvedores na empresa: ___
3. Quantidade de analistas na empresa: ___
4. Quantidade total da rea de TI: ___
5. Mdia de entrada de desenvolvedores/analistas na empresa, por ano: ___
6. Mdia de sada de desenvolvedores/analistas na empresa, por ano: ___
7. Existem estagirios no Desenvolvimento? ( ) Sim ( ) No

DADOS SOBRE O DESENVOLVIMENTO

8. Qual a Metodologia utilizada para o Desenvolvimento?
( ) No existe metodologia
formalmente
( ) Scrum
( ) Kanban

( ) Lean
( ) PMBOK
( ) RUP
( ) XP

( ) Outra(s) metodologia(s): ____________________________________________________

9.

Qual o ganho que a(s) tecnologia(s) utilizada(s) trouxe(ram) para o desenvolvimento de

software na empresa (0 a 10)? ______

10. Qual o procedimento do desenvolvimento, quando se v diante de uma implementao

grande (complexidade e tempo)? Detalhar, na medida do possvel.
Exemplo: dividimos a implementao em partes menores; colocamos para duas
pessoas trabalharem; encaminhamos para analistas especificarem; documentos so
elaborados; etc.
11. De que maneira o procedimento, citado na questo 10, atende demanda de
implementaes grandes?
( ) No atende;

( ) Atende satisfatoriamente;

( ) Atende, mas com muitos atropelos;

( ) Atende perfeitamente.

( ) Atende, com problemas;

Comentrios: _____________________________________________________________

42

ANEXO 2 - MODELO DE DOCUMENTO DE ESPECIFICAO PARA

O SCRUM
Ttulo: RECONHECIMENTO FACIAL EM VENDAS COM CHEQUES
Nmero: #5438
Analista(s) envolvido(s): Joo da Silva / Belarmino Cassandro
Descrio principal:
O Sistema SIS-SUPER, deve, a partir de agora, utilizar o reconhecimento facial de
cada cliente, quando a modalidade de venda cheque for escolhida.
As outras formas de pagamento no precisam desta funcionalidade, por enquanto.

Limitaes tcnicas (caso existam):

Questes de hardware; cmeras para leitura de face; conhecimento sobre a
integrao do reconhecimento com a ferramenta de desenvolvimento.

Especificao:
1. Anlise de outras solues no mercado de reconhecimento facial:

Verificar na internet;
Contactar empresas especializadas no fornecimento de hardware;
Verificar compatibilidade do hardware com a linguagem de programao
utilizada.

2. Cotao de cmeras para o desenvolvimento:

Acionar responsveis para aquisio de hardware;

3. Criao de componentes que integraro o reconhecimento facial na linguagem

de programao:

Deixar componentes/funes modularizados;

Criar repositrio comum para futuras reutilizaes.

4. Criar/alterar tabelas no BD para autenticao facial:

Criar tabela para guardar LOGs para cada autenticao;

Criar campo na tabela de clientes, que indicar o hash de reconhecimento
facial nico;
Criar atributo na tabela de cheques, indicando a obrigatoriedade de
reconhecimento facial;
Criar parmetro geral no sistema que dir se os PDVS iro trabalhar cm
reconhecimento facial;
Criar atributo do cliente para isent-lo de reconhecimento facial, s

43

permitido via administrador do sistema.

5. Alterar tela de cadastro de clientes para cadastrar hash de reconhecimento
facial:

Colocar opo na manuteno de clientes para receber reconhecimento

facial;
Colocar opo pra remover reconhecimento facial;
Colocar opo pra atualizar o reconhecimento facial;
Colocar atributo, por cliente, para isent-lo do reconhecimento.

6. Altera tela do PDV para receber reconhecimento facial para clientes com
cheque:

Integrar tela de vendas c/ cheque com o componente desenvolvido para

reconhecimento facial;
Colocar opo para cadastrar reconhecimento facial para hashs no
cadastrados.

Testes:
1. Testar cadastro de reconhecimento facial no cadastro de clientes;
2. Testar cadastro de reconhecimento facial no PDV;
3. Testar vendas com cheques, como um todo.

Estimativa inicial:
Horas de implementao/documentao/testes: 100 horas

44