7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 1/46
INSTITUTO DE EDUCAÇÃO SUPERIOR DA PARAÍBABACHARELADO EM SISTEMAS DE INFORMAÇÃO
ANTÔNIO ALVES DA SILVA NETO
OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA
METODOLOGIA SCRUM EM UM AMBIENTE DEDESENVOLVIMENTO DE SISTEMAS DE GRANDE PORTE
CABEDELO-PB
2011
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 2/46
ANTÔNIO ALVES DA SILVA NETO
OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA
METODOLOGIA SCRUM EM UM AMBIENTE DE
DESENVOLVIMENTO DE SISTEMAS DE GRANDE PORTE
Monografia apresentada ao curso deBacharelado em Sistemas de Informação,do IESP-PB, como requisito para a
conclusão do curso e obtenção do título deBacharel em Sistemas de Informação.
ORIENTADOR: PROF. ESP. MAXWELL ANDERSON IELPO DO AMARAL
CABEDELO-PB2011
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 3/46
Dados de acordo com: AACR2, CDU e CutterBiblioteca Central – IESP Faculdades – PB
S586b Silva Neto, Antônio Alves da
Os benefícios do documento de especificação nametodologia scrum em um ambiente de desenvolvimento desistemas de grande porte / Antônio Alves da Silva Neto. –Cabedelo, PB: [s.n], 2011.
45f.
Monografia (Graduação) – Instituto de Educação Superiorda Paraíba (IESP) - Curso de Sistemas de Informação, 2011.
1. Análise de sistemas. 2. Desenvolvimento de software. 3.Scrum. I. Título.
CDU 004.414.2(043.4)
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 4/46
INSTITUTO DE EDUCAÇÃO SUPERIOR DA PARAÍBA
BACHARELADO EM SISTEMAS DE INFORMAÇÃO
ANTÔNIO ALVES DA SILVA NETO
OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA
METODOLOGIA SCRUM EM UM AMBIENTE DE
DESENVOLVIMENTO DE SISTEMAS DE GRANDE PORTE
Monografia apresentada ao curso deBacharelado em Sistemas de Informação,do IESP-PB, como requisito para aconclusão do curso e obtenção do título deBacharel em Sistemas de Informação.
Aprovada em: 15 de dezembro de 2011.
BANCA EXAMINADORA:
_______________________________________________Maxwell Anderson Ielpo do Amaral
(Presidente)
_______________________________________________Luciano Henrique Gomes de Almeida
(Membro)
_______________________________________________Wellington Cavalcanti de Araújo
(Membro)
CABEDELO-PB2011
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 5/46
AGRADECIMENTOS
À Deus, o meu criador, meu perdoador e razão do meu viver. Esquecido poralguns, ignorado por outros, mas És, para mim, o motivo de seguir em frente. Em Ti eu
encontro a melhor filosofia de vida que alguém poderia encontrar. A Ti, Senhor e Rei, o meu
agradecimento por esta realização. Sem Ti, Senhor, eu não conseguiria... jamais. Toda a glória
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 mãe, Pedrineida, por tudo que fizeram por mim,
por tudo que me ensinaram, pelo homem que me formaram, e por serem quem são: meus pais.
Sei que estão felizes por isso, e saibam que vocês são tudo para mim. E à minha irmã, Eneida,
a quem eu amo demais, por todas as orações 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
convívio com profissionais da mais alta competência e conhecimento.
Ao analista de sistemas Francisco José Rodrigues Gomes, o "Chico", que desde
a época do meu estágio obrigatório (curso técnico), no ano 2000, me incentivou a fazer um
curso superior. Posso dizer, Chico, que esta minha vitória tem a sua participação em tudo.
Ao professor Ms. José Teixeira de Carvalho Neto, o "Neto", que foi professor
desta instituição de ensino e que me fez gostar de análise de sistemas.
Ao professor Esp. Maxwell Anderson Ielpo do Amaral, meu orientador, que
mesmo com o curto espaço de tempo que teve, as várias 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 Informação desta instituição, pelas palavras (e ações) de incentivo, que
me ajudaram a terminar este curso. Não tenho palavras para te agradecer.
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 6/46
Ao meu amigo, quase um irmão de sangue, Adriano Barroso Silvestre, o qual
esteve comigo no curso técnico que fiz, na primeira software-house que trabalhamos, na
primeira doação de sangue que fizemos, na primeira entrevista de emprego na Unimed N/NE,
no primeiro dia de trabalho no Infomed, e nas várias "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 faça excelentes profissionais desta área de tecnologia.
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 7/46
“...não há qualquer tecnologia, técnicaou prática que incremente em grande
magnitude a produtividade,confiabilidade ou simplicidade no
desenvolvimento de software”.(Frederick Brooks, 1987)
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 8/46
RESUMO
Com o passar dos anos, o desenvolvimento de sistemas de informática vem crescendo e, com
este crescimento, a necessidade de se estabelecer regras, normas e processos para o mesmo,
foi tornando-se algo inevitável. Não seria mais possível conceber a produção de software sem
uma mínima organização dos procedimentos que norteariam o desenvolvimento. Partindo
desta necessidade, foram surgindo várias metodologias de desenvolvimento e, em meados de
2001, surgiu uma corrente de pensamento chamada Manifesto Ágil, que propôs, dentre outras
filosofias de trabalho, que era preferível ter um sistema funcionando em um curto espaço de
entrega, do que possuir uma extensa documentação. E, baseado neste manifesto, surgiu o
Scrum, que é um framework focado em entregar ao cliente, no menor tempo possível, aquilo
que o mesmo está esperando. Porém, com a implantação do Scrum em ambientes de
desenvolvimento de grande porte com sistemas complexos, em tamanho e em regras de
negócio, percebeu-se que, para alguns casos, as estimativas de entrega não saíram como o
esperado, principalmente quando o escopo da implementação era sobre algo novo; talvez em
uma nova tecnologia ou baseado em alguma legislação específica. Além desta dificuldade em
estimar, surge a questão do legado da informação. O que está sendo deixado para os futuros
desenvolvedores com relação às funcionalidades complexas do sistema? Tentando responder
estas questões, o presente trabalho avaliou o cenário de desenvolvimento em algumas
empresas de João Pessoa-PB, utilizando um questionário e, percebeu-se, além de outras
informações que, as empresas que utilizam o Scrum, possuem um procedimento de análise
prévia; algumas gerando artefatos próprios para, só então, iniciar o desenvolvimento. Tanto o
referencial teórico, quanto a pesquisa realizada, serviram de base para a elaboração de um
modelo de documento (artefato) de especificação, a fim de auxiliar na resolução de grandes
requisitos dentro da metodologia Scrum.
Palavras-chave: Análise de sistemas, Scrum, desenvolvimento de software.
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 9/46
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 João 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.
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 10/46
LISTA DE FIGURAS
Figura 1 - Taskboard Scrum ..................................................................................................... 20
Figura 2 - Burndown Chart ...................................................................................................... 20
Figura 3 - Processo de desenvolvimento com Scrum ............................................................... 21
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 11/46
LISTA DE TABELAS
Tabela 1 - Classificação do porte ............................................................................................. 28
Tabela 2 - Classificação das empresas ..................................................................................... 28
Tabela 3 - Utilização de metodologias de desenvolvimento .................................................... 29
Tabela 4 - Procedimentos para estórias grandes ....................................................................... 30
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 12/46
SUMÁRIO
1 INTRODUÇÃO ..................................................................................................................... 12
1.1 JUSTIFICATIVA ............................................................................................................... 13
1.2 OBJETIVO GERAL ........................................................................................................... 13
1.3 OBJETIVOS ESPECÍFICOS ............................................................................................. 13
1.4 METODOLOGIA ............................................................................................................... 14
2 ANÁLISE 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 Reunião de planejamento................................................................................................. 21
3.4.2 Sprint e Reunião Diária ................................................................................................... 22
3.4.3 Reunião de revisão........................................................................................................... 22
3.4.4 Reunião de retrospectiva ................................................................................................. 23
4 ESTIMAR SEM CONHECER, EIS A QUESTÃO .............................................................. 24
5 A REALIDADE DO DESENVOLVIMENTO DE SOFTWARE EM ALGUMASEMPRESAS DE JOÃO PESSOA-PB ...................................................................................... 27
6 O DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM ........................ 31
6.1 Proposta de documento ....................................................................................................... 32
6.1.1 Título, número e analista(s) envolvido(s): ....................................................................... 32
6.1.2 Descrição principal: ......................................................................................................... 32
6.1.3 Limitações técnicas (caso existam): ................................................................................ 33
6.1.4 Especificação: .................................................................................................................. 33
6.2 Como aplicar o documento nas Sprints Scrum ................................................................... 35
7 CONSIDERAÇÕES FINAIS ................................................................................................ 37
REFERÊNCIAS ....................................................................................................................... 39
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 13/46
ANEXOS .................................................................................................................................. 41
ANEXO 1 - QUESTIONÁRIO APLICADO EM ALGUMAS EMPRESAS COMDESENVOLVIMENTO DE SOFTWARE EM JOÃO PESSOA ............................................ 42
ANEXO 2 - MODELO DE DOCUMENTO DE ESPECIFICAÇÃO PARA O SCRUM ....... 43
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 14/46
12
1 INTRODUÇÃO
Atualmente, para as empresas nas mais diversas áreas de negócio e de todos osportes, a utilização de sistemas de apoio é essencial. Nesse âmbito, e a fim de garantir e
acompanhar as inovações e tendências, o desenvolvimento e sustentação de aplicações se
mostra primordial. Entretanto, é comum deparar-se com equipes de desenvolvimento
heterogêneas em experiência, conhecimento, produtividade, e que sofrem com prazos curtos
de entrega, pressão externa dos clientes e um domínio de negócio extremamente complexo.
Devido a esse cenário, as entregas podem ser comprometidas, e consequentemente, a
credibilidade e até a qualidade do sistema de informação.Diante deste contexto, algumas perguntas são necessárias: como controlar o
que a equipe de desenvolvimento está produzindo? Como aproveitar o tempo curto e montar
um plano de ação que ajude na correção de falhas do sistema de forma rápida? Quais os
papéis dos envolvidos neste processo? E por fim, como disseminar conhecimento para
equipes que hoje são especialistas apenas em algumas áreas? Estas, talvez, sejam perguntas
emblemáticas para este cenário, contudo, as mesmas motivaram a elaboração do Manifesto
Ágil. Baseado também, nestes valores e princípios, foi criado o Scrum, que se propõe a ser umprocesso ágil de desenvolvimento de software, sugerindo métodos e ações de trabalho que
serão realizadas no decorrer de todo o processo de desenvolvimento de software.
Porém, como toda framework , o Scrum possui algumas limitações.
Principalmente quando falamos em grandes requisitos ou sistemas de grande porte, já que o
Scrum baseia-se, não na elaboração de documentação abrangente, mas na agilidade em
entregar o produto.
O presente trabalho vem tentar avaliar uma solução para este cenário,
utilizando um documento (artefato) de especificação para requisitos grandes em sistemas de
grande porte. Este documento não teria muitas restrições, e serviria somente para resolver esta
lacuna do Scrum, de documentação técnica escassa, no cenário já apresentado.
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 15/46
13
1.1 JUSTIFICATIVA
Nunca se falou tanto em tecnologia e na automação de processos, quanto nos
dias atuais. Portanto, o desenvolvimento de softwares que contribuem no dia a dia de qualquerempresa é peça chave do processo. Porém, quando os sistemas são muito grandes e
complexos, faz-se necessária a utilização de boas práticas que contribuam para o sucesso dos
aplicativos desenvolvidos. E dentro das metodologias ágeis de desenvolvimento1, existem
algumas limitações para requisitos grandes, pois não se baseiam em documentações
abrangentes.
Foi pensando em resolver esta problemática que este trabalho está sendo
proposto, a fim de avaliar o uso do artefato de especificação para desenvolvimento de
requisitos grandes, em sistemas de grande porte, ou em sistemas complexos.
1.2 OBJETIVO GERAL
Analisar os benefícios, ou não, do documento de especificação, agregado à
framework Scrum, a fim de melhorar o desenvolvimento de grandes requisitos nas Sprints2.
1.3 OBJETIVOS ESPECÍFICOS
• Entender como funciona, mesmo que inicialmente, a framework Scrum,
como ferramenta para auxiliar no processo de desenvolvimento de
software;
• Identificar, especificamente, o cenário de desenvolvimento em
empresas de grande e médio porte, levantando as vantagens e
dificuldades encontradas;
•
Saber como algumas empresas locais funcionam, relacionado às
frameworks, mais especificamente, com o Scrum;
• Verificar os benefícios do documento de especificação em requisitos de
grande duração, avaliando os ganhos e perdas.
1 Metodologia ágil de desenvolvimento é um termo que passou a descrever abordagens de desenvolvimento queseguissem alguns princípios, dentre eles a agilidade na entrega de soluções para o cliente.2 Sprint é o nome do ciclo de desenvolvimento na Metodologia Scrum.
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 16/46
14
1.4 METODOLOGIA
As metodologias aplicadas neste trabalho foram: consulta bibliográfica, que
alicerçou a pesquisa com opiniões de vários autores que têm experiência na área dedesenvolvimento, bem como uma pesquisa de campo.
Na pesquisa, foi utilizado um questionário (anexo 1) entregue em 12 (doze)
empresas de desenvolvimento de software (área fim ou meio) na cidade de João Pessoa-PB,
no período entre outubro e novembro de 2011. O questionário consta de 11 (onze) questões,
objetivas e subjetivas, no que auxiliou na quantificação dos dados que o trabalho se propõe a
oferecer.
Uma avaliação crítica foi realizada, ao final do trabalho, a fim de verificar a
utilização de um documento de especificação nos cenários propostos. O resultado dos
questionários serviu de base para isso.
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 17/46
15
2 ANÁLISE DE SISTEMAS: O DESAFIO
Quando analisamos o momento atual, no que diz respeito à velocidade da
informação, é de nos surpreender-nos. Talvez os nossos antepassados, duas ou três gerações
atrás, nem imaginariam que hoje poderíamos ligar um telefone celular, palm, Pager , iPad , e
conversar com o mundo inteiro com dispositivos que estão na palma de nossas mãos. O
hardware (equipamento de informática) é de suma importância neste aspecto. O avanço na
eletrônica, automação, industrialização e aumento da mão de obra na fabricação de
eletrônicos, também vêm somar a este progresso. Porém, nada disso seria possível, se os
programas embarcados3 e de computadores, existissem. O software é quem comanda todo o
gerenciamento das máquinas, gerando a informação e o resultado obtido. E isto podemos ver
em todas as áreas da sociedade. Não se imagina, por exemplo, uma indústria ou escritório,
controlar toda a sua produção (manual ou intelectual) sem um software de computador. Neste
sentido, Kruchten fala que o “software é o combustível dos negócios modernos, com o qual se
conectam melhor controles governamentais e sociedades” (KRUCHTEN, 2003, p. 3).
Com toda esta importância que o software tem, é fácil perceber que a produçãodo mesmo deve ser priorizada, não podendo ser encarada como simples ou de pouca
priorização, já que, a partir dela, os negócios serão gerenciados. E ao contrário do que muitos
imaginam, a produção de software não é algo simplista, que tenha prazo determinado e
planejamento 100% cumprido. Falando do risco na produção do software, “muitas
organizações trabalham num modo de ‘negativa de risco’, cálculo e planejamento continuado,
como se todas as variáveis fossem conhecidas, o trabalho fosse mecânico e o pessoal,
substituível” (KRUCHTEN, 2003, p. 99).
E dentro da construção do software e em qualquer metodologia de
desenvolvimento, direta ou indiretamente, existe a fase de análise, e esta serve para, na
medida do possível, detectar a maioria dos problemas e solucioná-los, antes que os mesmos
aconteçam. Este, talvez, seja um dos maiores desafios no desenvolvimento de software e, o
entendimento da importância da análise de sistemas, dá à equipe de desenvolvimento uma
visão mais concreta para a construção de um software.
3 Embarcado, ou aplicações embarcadas, são aplicativos que rodam (executam) em equipamentos fechados,por exemplo: geladeiras, celulares, microondas, etc.
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 18/46
16
E se existe um ponto muito importante, na análise de sistemas, é a
formalização do que é encontrado ou detectado. E a documentação de um software (artefatos
de usuário e análise) também faz parte do mesmo (SOMMERVILLE, 2003, p. 5) e alguns
formalismos, por menores que sejam, são importantes, a fim de registrar o que se deseja
seguir. Os direcionamentos formalizados são uma ponte para a equipe de desenvolvimento
seguir o rumo certo. Para isso, o analista deve levar em consideração alguns pontos e
dificuldades:
O entendimento de desafios enfrentados pela equipe de desenvolvimento e pelo
ambiente de negócios, nos quais são operados, origina o nível correto de
formalidade de processo. (POLLICE, 2002, p.4)
Os documentos produzidos, durante uma análise de requisitos servem, na
maioria das vezes, como ponto de partida para o desenvolvimento. Porém, este processo de
análise e produção de especificação leva tempo. Mas o fato é que, é quase impossível nós
pensarmos em analisar requisitos sem a existência de algum artefato de análise. Sommerville,
um dos grandes ícones na área de Engenharia de Software, diz que o processo de engenharia
de requisitos "leva à produção de uma documentação de requisitos, que é a especificação para
o sistema" (SOMMERVILLE, 2003).
Mas o que fazer quando o tempo é exíguo e as entregas de software devem ser
realizadas em um curto espaço de tempo? As metodologias ágeis surgem neste cenário, o qual
veremos através de uma metodologia específica, na próxima seção.
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 19/46
17
3 SCRUM : UMA ABORDAGEM INICIAL
Algumas questões de análise, como vimos anteriormente, e a necessidade deentregas rápidas ao cliente, bem como a organização no processo de software, motivaram, em
2001, a elaboração do Manifesto Ágil4 e, com base nos seus valores e princípios, definiu-se o
Scrum5, que se propõe a ser um processo ágil de desenvolvimento de software, sugerindo
métodos e ações de trabalho que serão 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 rápidos. As metodologias ágeis surgem para tentar resolver esta problemática,
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 iterações de duração fixa (geralmente duas a quatro semanas),
com código potencialmente entregável demonstrado depois de cada iteração, segundoKniberg. A otimização do plano de entrega e atualização constante de prioridades com o
cliente, também faz parte da metodologia. Isto traz um processo reajustável, com
retrospectivas depois de cada iteração, e trabalho constante no que o cliente deseja.
Porém, a framework Scrum prevê a produção somente da documentação
necessária, já que o foco é atender os requisitos do cliente e não o desenvolvimento de um
processo perfeito. Isto traz alguns malefícios, 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 possível "problemática", vejamos, objetivamente,
como funciona a framework Scrum, no que se refere ao dia a dia de uma equipe de
4 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
princípios, dentre eles a agilidade na entrega de soluções para o cliente.5 Scrum é uma framework ágil para gerência de projetos. Ela é baseada em ciclos de dias chamados Sprints,onde se trabalha para alcançar objetivos bem definidos. Estes objetivos são representados no Product Backlog,uma lista de coisas para fazer, que é constantemente atualizada e repriorizada.
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 20/46
18
desenvolvimento. Será uma abordagem rápida, pelo fato do presente trabalho não se dedicar
ao "esgotamento" da metodologia Scrum.
3.1 O Scrum
A origem do nome Scrum, geralmente é atribuída à jogada do Rugby, esporte
americano, na qual alguns jogadores se juntam em um círculo, a fim de atingir um objetivo
definido, após uma penalidade no jogo. Porém, 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 Japão (CÂMARA, 2001).
O Scrum, como framework , foi criado por Ken Schwaber e Jeff Sutherland em1995, e o Ken Schwaber fala que o Scrum é um framework para gestão de equipes envolvidas
na execução de tarefas, focada em entregar ao cliente, no menor tempo possível, aquilo que o
mesmo está esperando (SCHWABER, 2001). O fato é que o Scrum baseia-se no Manifesto
Ágil, principalmente nos pontos abaixo:
• Os indivíduos e as interações são mais importantes que os processos e as
ferramentas;
•
A colaboração com o cliente é mais eficiente que aquilo que está escrito no
contrato;
• Mudanças são encorajadas nas tarefas previamente definidas;
• Prefere-se software funcionando, no menor tempo, a possuir uma extensa
documentação.
3.2 Alguns conceitos importantes
Para entendermos o Scrum, precisamos entender alguns conceitos inerentes à
metodologia. Com a visão 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 são novas funcionalidades, novos comportamentos, e
alguns ajustes a serem realizados no sistema.
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 21/46
19
3.2.2 Sprint :
Uma Sprint é o ciclo do Scrum, que geralmente dura de 2 (duas) a 4 (quatro)
semanas. Dentro da Sprint são feitas, a análise, o desenvolvimento e os testes das estórias. É odia 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 vários times, que irão desenvolver, corrigir, testar e entregar as funcionalidades
em uma cerimônia da qual falaremos depois.
3.2.4 Scrum Master :
É o elo de ligação 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 possível, os atropelos que possam surgir.
3.3 Algumas ferramentas de apoio
3.3.1 Taskboard/Dashboard :
O quadro, conhecido por alguns também como quadro Kanban (KUKIER,
2011) é, talvez, o maior identificador visual da metodologia Scrum. Nele são colados post-its
com as tarefas a serem executadas pelos membros da equipe. Apesar de cada empresa de
desenvolvimento ter as suas próprias seções no quadro, três seções básicas geralmente
existem: planejado, iniciado e pronto (Figura 1).
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 22/46
Fonte: http://mudandouma
O Taskboar
dele o mesmo pode saber
próprios integrantes dos ti
3.3.2 Burnd
É um gráfi
estórias estão de acordo co
Figura 1 - Taskboard Scrum
pequenaempresa.blogspot.com/2007/11/livro-de-refer
é um excelente indicador para o Scrum
o que está sendo feito no momento da Spri
es Scrum se auto-gerenciarem.
wn Chart :
o bem interessante (Figura 2) que indica
o planejado nas cerimônias, que iremos fal
Figura 2 - Burndown Chart
Fonte: http://www.scrumalliance.org/articles/55
20
ncia-para-scrum.html
aster , porque através
nt , bem como para os
se o andamento das
ar mais à frente.
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 23/46
3.4 Fluxo d
Baseados n
acontece na Sprint e fora d
Fig
3.4.1 Reuni
Esta fase d
Divide-se em dois moment
Sprint Plan
já priorizadas para a equipe
Sprint Plan
mesmo selecionam as tare
terão que fazer uma estim
Master saber se estas estóri
Ainda na Sp
tarefas menores, através d
cada post-it deverá ter uma
Bem, em se
artefato que temos na
evangelistas, defensores d
Scrum
gráfico da figura 3, iremos resumidame
la.
ura 3 - Processo de desenvolvimento com Scrum
Fonte: http://blog.marciel.org/?tag=scrum
o de planejamento
Scrum é realizada após a priorização das
os:
ing 1 - Cerimônia, geralmente com o PO, q
;
ing 2 - Cerimônia feita entre os membros d
as apresentadas pelo PO, para a sua equipe.
tiva de cada tarefa, não muito precisa, mas
as irão caber na Sprint .
rint Planning 2, os integrantes dos times irã
s post-its, que são fixados no taskboard n
descrição sucinta, porém clara, do que deve
tratando da documentação gerada após a f
etodologia, basicamente, são os post-its
e metodologias ágeis, bem como uma par
21
te, falar sobre o que
stórias/ bugs pelo PO.
e apresenta as tarefas
cada equipe, onde os
Neste momento, eles
que permita ao Scrum
dividir as estórias em
seção Planejado. Em
ser feito.
se de análise, o único
no quadro. Alguns
te dos consultores de
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 24/46
22
MPS.Br6, que orientam a implantação do Scrum, afirmam que, o que existe nos post-its deve
ser suficientemente necessário para o desenvolvimento, não precisando de outro mecanismo
para tal.
Um outro ponto muito importante nas reuniões de planejamento, é o fato de
que praticamente tudo que se define nas Sprint Plannings 1 e 2 são a base para o
desenvolvimento. Kniberg fala sobre o assunto, frisando:
O planejamento de Sprint é uma reunião crítica, provavelmente o evento mais
importante no Scrum (na minha opinião, claro). Um encontro de planejamento de
Sprint mal feito pode bagunçar totalmente um Sprint. (KNIBERG, 2007, p.25)
Em outras palavras, caso exista um erro de estimativa ou mesmo especificações
em post-its mal feitas, o andamento da Sprint pode ser comprometido.
3.4.2 Sprint e Reunião Diária
Após as duas cerimônias de planejamento realizadas, começa o
desenvolvimento nos times, dentro da Sprint . Uma outra cerimônia também realizada, só que,
diariamente, é a Daily Scrum. É uma reunião rápida, de 10 (dez) a 15 (quinze) minutos, no
máximo, na qual cada integrante do time responde a três perguntas básicas:
• O que foi feito ontem?
• O que deve ser feito hoje?
• Há alguma tarefa impedida de ser executada? Quais são as razões?
A Daily Scrum também é 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 Reunião de revisão
Esta cerimônia no Scrum é com a presença do PO, na qual as estórias são
apresentadas e o PO aceita ou rejeita cada implementação.
6 Melhoria de Processos do Software Brasileiro é simultaneamente um movimento para a melhoria daqualidade (Programa MPS.BR) e um modelo de qualidade de processo (Modelo MPS) voltada para a realidadedo mercado de pequenas e médias empresas de desenvolvimento de software no Brasil.
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 25/46
23
3.4.4 Reunião de retrospectiva
Esta é a última cerimônia 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 positivose negativos, verificando, no caso dos negativos, qual a lição aprendida. É importante a
participação de todos os times e o Scrum Master , nesta reunião.
Bem, nivelando este conhecimento básico sobre o Scrum, iremos avaliar a sua
aplicação em ambientes com sistemas de grande porte e/ou estórias complexas.
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 26/46
24
4 ESTIMAR SEM CONHECER, EIS A QUESTÃO
É notável que as metodologias ágeis foram criadas para preencher uma lacuna
nos cenários 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 não. Um dos mais renomados engenheiros de
software da história, Frederick Brooks, disse certa vez, em um de seus escritos:
[...] não há qualquer tecnologia, técnica ou prática que incremente em grande
magnitude a produtividade, confiabilidade ou simplicidade no desenvolvimento de
software (BROOKS, 1987, p.10)
Isto só reforça a idéia de que, o objetivo de uma equipe de software, é
aproveitar todos os benefícios das metodologias disponíveis a fim de agilizar o processo de
produção de sistemas com qualidade. Não existe uma única metodologia que resolva todos os
problemas para todos os cenários possíveis de desenvolvimento. Em outras palavras, como
diria o próprio Brooks, não existe uma "bala de prata", capaz de solucionar todas as
dificuldades de todos.
E trazendo para a metodologia Scrum, como utilizar o seu potencial máximo
em benefício do processo de desenvolvimento? A metodologia Scrum, por si só, já tem uma
certa organização (cerimônias), realiza um controle visual, prega o auto-gerenciamento e a
viabilização de entregas rápidas. Porém, como a metodologia se comporta quando aparecem
estórias de alta complexidade na Sprint Planning 1? Esta é uma realidade em empresas de
médio/grande porte e/ou com sistemas complexos, no que tange ao negócio.
Vamos exemplificar com um caso fictício, porém prático. Vamos assumir que,
uma dada empresa trabalha com produção de software (automação comercial) de uma grande
rede de supermercados, que abrange 3 (três) estados da federação, com mais de 70 (setenta)
unidades e cerca de 500 (quinhentos) PDVs (pontos de venda).
Esta rede de supermercados, através de sua área de TI e dirigentes, fez uma
solicitação de melhoria para o software, no qual o mesmo deveria aumentar o nível desegurança em compras com cheques, e o sistema deveria realizar o reconhecimento facial de
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 27/46
25
cada cliente, quando esta modalidade de venda (cheque) fosse escolhida. Estamos partindo do
pressuposto que esta funcionalidade foi requisitada pelo cliente e o mesmo não abriu mão
desta solicitação, aguardando a implementação o mais rápido possível.
No outro lado, a empresa de desenvolvimento, que trabalha com o Scrum, têm
as Sprints no tempo de 3 (três) semanas, mas nenhum desenvolvedor tem know-how7 em
reconhecimento facial.
Porém, é fato que o desenvolvimento desta funcionalidade não levará um
tempo menor que uma Sprint , nem mesmo se pode ter uma estimativa precisa para esta
estória, na cerimônia Sprint Planning 2.
Neste caso, o Scrum Master e o PO têm uma difícil missão, que é analisar o
que pode ser feito nesta Sprint , e ainda assim ficará difícil o PO se programar para uma
entrega de software ao cliente, porque nem ele e nem a equipe têm previsões 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 implementação daquela nova tecnologia?
Estas são duas questões que, no mínimo, necessitam de uma atenção para este
cenário de desenvolvimento, tão comum em sistemas grandes. No exemplo acima, é
necessário um plano de ação que possibilite:
• atender ao cliente (mais importante);
• disseminar o conhecimento técnico sobre a estória, entre a equipe;
• dar condições ao PO de planejar quando sairá a implementação, para
negociações com o cliente final, e;
• ser ágil.
Bem, reconhecemos que esta é uma difícil tarefa, porém, um dos pontos acima
deve ser priorizado: dar condições ao PO de planejar quando sairá a implementação,
7 O know-how, ou conhecimento processual, é o conhecimento de como executar alguma tarefa.
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 28/46
26
para negociações com o cliente final. Ou seja, estimar corretamente (com margem mínima
de erro) a fim de facilitar o planejamento das Sprints futuras. Estimar é preciso.
Como a quantidade de material teórico, sobre este assunto específico, não é tãocomum, foi interessante avaliar o procedimento praticado por algumas empresas em João
Pessoa-PB, que desenvolvem software, ao se depararem com circunstâncias semelhantes às do
exemplo citado.
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 29/46
27
5 A REALIDADE DO DESENVOLVIMENTO DE SOFTWARE EMALGUMAS EMPRESAS DE JOÃO PESSOA-PB
Para avaliar a problemática neste cenário, uma pesquisa de campo foi
realizada, em 12 (doze) empresas de desenvolvimento de software situadas em João Pessoa-
PB, no período entre outubro e novembro de 2011. A pesquisa, no modo questionário
(anexos), apresentou 11 (onze) questões, entre objetivas e subjetivas. Das 12 (doze) empresas,
obtivemos a resposta da metade, 6 (seis), e os dados seguem abaixo. A identificação 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
produção de software", foram utilizadas também.
Relacionado à classificação das empresas, no quesito porte, foi utilizada a
abordagem abaixo, somente para diferenciar os grupos de empresa pesquisadas. A fórmula
utilizada, criada para este trabalho, foi a seguinte:
PORTE = (Qtde. de func. na empresa x 1) + ((Qtde. analistas + Qtde. desenvolvedores) x 2)
Esta fórmula 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 considerável, 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 demembros na equipe, que está diretamente envolvida com o desenvolvimento, tem um peso
maior. Vale ressaltar que a fórmula supracitada não serve para afirmação científica alguma.
Baseado no resultado do porte de cada empresa, foi gerada a seguinte
classificação:
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 30/46
28
PORTE CLASSIFICAÇÃO
1 a 24 PEQUENO
25 a 99 MÉDIO
>= 100 GRANDE
Tabela 1 - Classificação do porte
Reforçando, nesta classificação, o porte da empresa não está diretamente ligado
à quantidade de todos os funcionários, mas principalmente à quantidade de analistas e
desenvolvedores que, na proporção, têm peso duplicado.
A primeira fase da análise foi classificar as empresas quanto ao porte das
mesmas. Segue tabela informativa:
EMPRESA
QTDE. DE
FUNCIONÁRIOS NA
EMPRESA
QTDE. DE ANALISTAS + QTDE.
DE DESENVOLVEDORESPORTE CLASSIFICAÇÃO
EMPRESA A 17 12 41 MÉDIO
EMPRESA B 10 4 18 PEQUENO
EMPRESA C 100 4 108 GRANDE
EMPRESA D 150 50 250 GRANDE
EMPRESA E 80 45 170 GRANDE
EMPRESA F 3 2 7 PEQUENO
Tabela 2 - Classificação 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.
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 31/46
29
EMPRESA CLASSIFICAÇÃOQUAL A METODOLOGIA UTILIZADA
PARA O DESENVOLVIMENTO?OBSERVAÇÕES
EMPRESA A MÉDIO Não existe metodologia formalmente
EMPRESA B PEQUENO Não existe metodologia formalmente
EMPRESA C GRANDE Não existe metodologia formalmente Softwares terceirizados
EMPRESA D GRANDE SCRUM
EMPRESA E GRANDE SCRUM
EMPRESA F PEQUENO Não existe metodologia formalmente
Tabela 3 - Utilização de metodologias de desenvolvimento
A primeira análise que fazemos, a grosso modo é que, quanto maior for o
tamanho da empresa, maior é a sua preocupação com a definição de alguma metodologia que
contribua com a produção de software. Exceto 1 (uma), que optou em não desenvolver
softwares, preferindo a aquisição de terceiros.
Porém, como o nosso trabalho é relacionado com a estimativa de estórias
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 cenário.
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
implementação grande (complexidade e tempo)? e;
2. De que maneira o procedimento, citado na questão anterior, atende à
demanda de implementações grandes?
Vejamos as respostas das questões na tabela 4:
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 32/46
30
EMPRESA1. PROCEDIMENTO REALIZADO EM
IMPLEMENTAÇÕES GRANDES2. ATENDE À DEMANDA?
EMPRESA D Fazemos estórias de análise para se identificar os
pormenores do esforço; elabora-se um documento de
especificação completo; divide-se tudo que foi levantado
em etapas; parte-se para construir a solução
considerando a fragmentação identificada como
necessária.
Atende, mas com
muitos atropelos
EMPRESA E A implementação é dividida em tarefas, das quais todos
os membros da equipe, com capacidade nivelada, pegam
as devidas atividades e as desenvolvem no tempo
definido, em análises.
Atende perfeitamente
Tabela 4 - Procedimentos para estórias grandes
É interessante perceber que as duas empresas têm procedimentos similares, no
que se refere a implementações grandes. A complexidade de algumas estórias "forçam"
algumas equipes de desenvolvimento que utilizam o Scrum, a buscar adequações na
metodologia, a fim de conseguir êxito na entrega das funcionalidades.
Uma metodologia de desenvolvimento bem conhecida, e que pode ser bastante
forte na produção de artefatos, é o RUP, e a mesma provê alguns documentos que auxiliam na
análise de alguns requisitos do usuário.
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 33/46
31
6 O DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
O RUP, Rational Unified Process, é um framework criado pela Rational
Software, que atualmente é subsidiária 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 análise de requisitos grandes. Alguns
desenvolvedores e analistas que trabalham com RUP, acham que o mesmo é a solução para
todos os problemas, neste cenário (POLLICE, 2002).
Existe um grupo de pessoas que defendem também que, pelo fato do RUP ser
um framework adaptável, o mesmo pode ser mais ágil, mesmo com a grande quantidade de
artefatos de análise 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 experiência com RUP me diz que o seu problema são as suas variações
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 estão muito alinhadas com o
pensamento ágil (FOWLER, 2005, parágrafo 130, tradução minha).
Em outras palavras, é possível utilizar o RUP atrelado a alguns conceitos ágeis,
como: iteração, diminuição de artefatos, etc., mas este não é o objetivo deste trabalho. O
grande benefício do RUP, para o nosso estudo, são os artefatos de análise que são
produzidos através dele, dentre eles, o SAD (Software Architeture Document ).
O Documento de Arquitetura de Software (SAD), dá um panorama geral daarquitetura do sistema, descrevendo diversos aspectos do sistema. Por exemplo, caso o SAD
fosse um artefato produzido pela empresa fictícia citada no capítulo 4 deste trabalho, o mesmo
iria trazer as questões técnicas, casos de uso8 e a lógica de toda a funcionalidade do
reconhecimento facial para compras com cheques, que foi o caso citado.
8
Na Engenharia de Software, um caso de uso (ou use case) é um tipo de classificador que representa umaunidade 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.
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 34/46
32
O SAD é um exemplo de um documento de especificação do RUP, e que pode
ser adotado por equipes Scrum para o desenvolvimento de grandes estórias. O importante,
nesta fase de análise, é definir claramente o que deve ser feito nas próximas 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 adoção 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 especificações mais detalhadas do que, simplesmente, os post-its no taskboard .
O objetivo aqui é prover uma modesta solução para que os analistas das
equipes possam estimar o esforço 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 não tem o conhecimento
sobre aquela área do sistema.
Para exemplificar este documento, fez-se o uso do caso fictício de
reconhecimento facial de clientes em compras com cheques, levantado no capítulo 4 deste
trabalho. O modelo deste documento também está disponível nos anexos (anexo 2).
6.1.1 Título, número e analista(s) envolvido(s):
Aqui estarão título do requisito, número de controle e analista(s) envolvido(s)
na especificação desta estória. Para o nosso caso prático, o título será "Reconhecimento facial
em vendas com cheques", o número "#5438" e os analistas envolvidos "João da Silva /
Belarmino Cassandro". É basicamente o cabeçalho da estória de análise.
6.1.2 Descrição principal:
Aqui é descrito, de forma sucinta, porém 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
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 35/46
33
facial de cada cliente, quando a modalidade de venda cheque for escolhida.
As outras formas de pagamento não precisam desta funcionalidade, por
enquanto.
6.1.3 Limitações técnicas (caso existam):
Tudo o que houver relacionado a limitações técnicas, necessidade de
treinamento, questões de legislação, dificuldades preliminares encontradas, etc. Tudo que for
causar algum tipo de barreira para o problema ser solucionado:
Questões de hardware; câmeras para leitura de face; conhecimento sobre aintegração do reconhecimento com a ferramenta de desenvolvimento.
6.1.4 Especificação:
Aqui constará a especificação mais detalhada do que deve ser feito. Detalhes
importantes não podem ser omitidos, porque servirão de base para qualquer desenvolvedor
implementar as estórias criadas pelo PO, a partir desta especificação:
1. Análise de outras soluções no mercado de reconhecimento facial:
• Verificar na internet;
• Contactar empresas especializadas no fornecimento de hardware;
• Verificar compatibilidade do hardware com a linguagem de
programação utilizada.
2. Cotação de câmeras para o desenvolvimento:
• Acionar responsáveis para aquisição de hardware;3. Criação de componentes que integrarão o reconhecimento facial na
linguagem de programação:
• Deixar componentes/funções modularizados;
• Criar repositório comum para futuras reutilizações.
4. Criar/alterar tabelas no BD para autenticação facial:
• Criar tabela para guardar LOGs para cada autenticação;
• Criar campo na tabela de clientes, que indicará o hash dereconhecimento facial único;
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 36/46
34
• Criar atributo na tabela de cheques, indicando a obrigatoriedade de
reconhecimento facial;
• Criar parâmetro geral no sistema que dirá se os PDVS irão 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 opção na manutenção de clientes para receber
reconhecimento facial;
• Colocar opção para remover reconhecimento facial;• Colocar opção 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 opção para cadastrar reconhecimento facial para hashs nãocadastrados.
Para cada tópico são especificados sub-tópicos, que descreverão as atividades a
serem realizadas.
6.1.5 Testes:
É uma área importante, na qual o analista envolvido na especificação irá
antecipar alguns casos de testes que atenderão à funcionalidade. Não é necessário aqui riqueza
de detalhes e nem casos de testes complexos, mas testes básicos 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;
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 37/46
35
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 através
dela é que o mesmo poderá planejar os próximos ciclos de desenvolvimento.
Horas de implementação/documentação/testes: 100 horas
Caso seja possível, o ideal seria que a estimativa fosse por tópico da
especificação, a fim de facilitar o dimensionamento.
6.2 Como aplicar o documento nas Sprints Scrum
A aplicação 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; estórias grandes aparecerem na Sprint Planning 1; quando
houver falta de conhecimento da equipe relacionada a alguma inovação tecnológica ou
legislação inesperada; ou mesmo quaisquer outros motivos que impossibilitem dimensionar o
tamanho do esforço para a implementação de uma certa funcionalidade, seria necessário, não
"retirar" a estória da Sprint , mas colocá-la como uma análise (em princípio) e o fruto desta
estória seria um documento de especificação com as informações de como implementar,
bem como a estimativa, que ajudará o PO a planejar as estórias para as próximas Sprints
O documento supracitado servirá de base para os membros da equipe dividirem
os post-its nas Sprints, que serão implementadas as tarefas. Em uma análise abrangente, cada
tópico poderia ser uma estória e, como sugestão, poderemos colocar em cada post-it , 1 (um)
sub-tópico da especificação, caso o mesmo possa ser executado em 1 (um) dia por
desenvolvedor. Sendo assim, para o tópico 1, da especificação no exemplo anexo, teríamos:
1. Análise de outras soluções no mercado de reconhecimento facial:
• Verificar na internet;
•
Contactar empresas especializadas no fornecimento de hardware;
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 38/46
36
• Verificar compatibilidade do hardware com a linguagem de programação
utilizada.
Neste caso, o tópico 1 (um) seria transformado em uma estória, e cada sub-
tópico em uma tarefa ( post-it ) para ser fixado no taskboard :
Estória: Análise de outras soluções no mercado
Post-its:
O interessante nesta abordagem, é que o documento de especificação, que
serviu para estimar o tempo e entender melhor o que se deve fazer, não veio para mudar ou
concluir que a metodologia Scrum não serve para estórias de cunho complexo, mas, pelocontrário, veio para somar à metodologia, fornecendo informações importantes para a Sprint
Planning 2 e, consequentemente, para o melhor andamento da Sprint .
Verificar
compatibilidadedo hardware coma linguagem deprogramaçãoutilizada.
Contactar
empresasespecializadas nofornecimento dehardware
Verificar na
internet
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 39/46
37
7 CONSIDERAÇÕES FINAIS
O Scrum é sim uma excelente metodologia de trabalho e, como filosofia de
trabalho, contribui (e muito) para a disseminação do conhecimento entre as equipes, devido à
quantidade de cerimônias que ela possui e que forçam o repasse natural das informações. E
embora o "Scrum dependa do auto-gerenciamento, bem como de regras simples e orientação
constante" (SCHWABER, 2001), os times que trabalham com esta metodologia, geralmente,
falam do grande benefício que as reuniões 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, é incontestável. Porém, é certo também que a aplicação das
metodologias ágeis e, no nosso caso específico, o Scrum, traz consigo uma redução de
artefatos, que poderiam, em determinados momentos, contribuir com a agilidade no
desenvolvimento. Parece um contra-senso, mas não é. A aplicação do Scrum, sem nenhuma
adequação a requisitos de porte considerável, 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 também o Scrum, em alguns tipos de
implementações, concentram o conhecimento em algumas cabeças das equipes, o que não é
bom. Sobre isso, Carlos Vasco, mencionando a filosofia ágil e o XP, exemplifica:
"A pouca evidência de artefatos do XP, com foco em estórias de usuário e código, é
visto como um fator que aumenta o risco do projeto, o conhecimento fica vinculado
aos desenvolvedores e ao código" (VASCO, 2005, p.5)
Este trabalho também foi importante porque trouxe a experiência de algumas
empresas da cidade de João 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
dedicação da equipe que trabalha com o Scrum em tratar requisitos de alta complexidade,
deve ser diferenciada. Em outras palavras, a análise dos requisitos, bem como a especificação,
não deve ser vista apenas como post-its pregados no quadro taskboard . É algo além disso.
9
XP ou Programação extrema (do inglês eXtreme Programming), é uma metodologia ágil para equipespequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança. Para isso,adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante odesenvolvimento de software.
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 40/46
38
Um outro ponto positivo deste trabalho foi a criação de um modelo de
documento (artefato) de especificação. 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 adesão de um padrão, 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, "não
há um único processo adequado para todas as situações, reduzido ou diferente" (POLLICE,
2002, p.4). O grande desafio, na análise de sistemas e gerenciamento de projetos, é aproveitar
o máximo 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 produção 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 produção de
software, talvez considerado inalcançável, mas não podemos deixar de "perseguir" este
caminho.
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 41/46
39
REFERÊNCIAS
AKITA, Fabio. Desmistificando o método Kanban. Disponível em:
<http://info.abril.com.br/noticias/rede/gestao20/gestao/desmistificando-o-metodo-kanban/>.
Acessado em: 22 de março de 2011.
BEEDLE, Mike et al. Manifesto para o desenvolvimento ágil de software. Disponível 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.
CÂMARA, Fábio. SCRUM : Uma Metodologia Ágil. Disponível 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). Disponível 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 nós fazemos Scrum. Editores: Diana
Plesa; Felipe Rodrigues. 2007 (Disponível em: http://www.infoq.com).
KRUCTHEN, Philippe. Introdução ao RUP – Rational Unified Process. Rio de Janeiro:
Editora Ciência Moderna Ltda., 2003.
KUKIER, Daniel. Kanban. Disponível em: <http://blog.locaweb.com.br/metodologias-
ageis/kanban/>. Acessado em 13 de novembro de 2011.
PAIVA, Nicholas A. M. da S. Implantação e avaliação dos resultados do framework
Scrum para o gerenciamento de tarefas no ambiente do setor de suporte técnico de
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 42/46
40
tecnologia da informação do SETURN/NatalCard, após a implantação da bilhetagem
eletrônica. Natal: Universidade Gama Filho, 2010. 42 p.
PELOCHE, Luciano. Lean para todos. Disponível em:<http://leanparatodos.blogspot.com/2011/01/kanban-na-praia.html>. Acessado em: 22 de
março de 2011.
PEREIRA, Flávia Cruz. A síndrome da “bala de prata” na gestão de projeto. São Paulo:
Revista MundoPM, janeiro de 2011. págs. 40 a 45.
PINTO, Sérgio Crespo C. S. RUP x Metodologias Ágeis: uma análise crítica. Disponível 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 e não pela duração. Disponível em:
<http://exocortex.com.br/blog/2009/10/estimando-pelo-tamanho-e-no-pela-durao/>. Acessado
em: 22 de março 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 introdução ao Scrum. Disponível 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. São Paulo: Addison Wesley, 2003.
TELES, Vinícius Manhães. Extreme Programming. São Paulo: NOVATEC Editora, 2004.
VASCO, Carlos G. VITHOFT, Marcelo Henrique. ESTANTE, Paulo Roberto C.
Comparação entre Metodologias RUP e XP. Curitiba: PUCPR, 2005.
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 43/46
41
ANEXOS
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 44/46
42
ANEXO 1 - QUESTIONÁRIO APLICADO EM ALGUMAS EMPRESASCOM DESENVOLVIMENTO DE SOFTWARE EM JOÃO PESSOA
QUESTIONÁRIO APLICADO NAS EMPRESAS DA ÁREA DE TIDADOS SOBRE A EMPRESA/SETOR DE DESENVOLVIMENTO
1.
Quantidade de funcionários na empresa: ___
2.
Quantidade de desenvolvedores na empresa: ___
3.
Quantidade de analistas na empresa: ___
4.
Quantidade total da área de TI: ___
5. Média de entrada de desenvolvedores/analistas na empresa, por ano: ___
6.
Média de saída de desenvolvedores/analistas na empresa, por ano: ___
7. Existem estagiários no Desenvolvimento? ( ) Sim ( ) Não
DADOS SOBRE O DESENVOLVIMENTO
8. Qual a Metodologia utilizada para o Desenvolvimento?
( ) Não 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 implementação
grande (complexidade e tempo)? Detalhar, na medida do possível.
Exemplo: dividimos a implementação em partes menores; colocamos para duas
pessoas trabalharem; encaminhamos para analistas especificarem; documentos são
elaborados; etc.
11. De que maneira o procedimento, citado na questão 10, atende à demanda de
implementações grandes?
( ) Não atende;
( ) Atende, mas com muitos atropelos;
( ) Atende, com problemas;
( ) Atende satisfatoriamente;
( ) Atende perfeitamente.
Comentários: _____________________________________________________________
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 45/46
43
ANEXO 2 - MODELO DE DOCUMENTO DE ESPECIFICAÇÃO PARAO SCRUM
Título: RECONHECIMENTO FACIAL EM VENDAS COM CHEQUES
Número: #5438
Analista(s) envolvido(s): João da Silva / Belarmino Cassandro
Descrição principal:
O Sistema SIS-SUPER, deve, a partir de agora, utilizar o reconhecimento facial decada cliente, quando a modalidade de venda cheque for escolhida.
As outras formas de pagamento não precisam desta funcionalidade, por enquanto.
Limitações técnicas (caso existam):
Questões de hardware; câmeras para leitura de face; conhecimento sobre aintegração do reconhecimento com a ferramenta de desenvolvimento.
Especificação:
1. Análise de outras soluções no mercado de reconhecimento facial:
• Verificar na internet;• Contactar empresas especializadas no fornecimento de hardware;• Verificar compatibilidade do hardware com a linguagem de programação
utilizada.
2. Cotação de câmeras para o desenvolvimento:
• Acionar responsáveis para aquisição de hardware;
3. Criação de componentes que integrarão o reconhecimento facial na linguagemde programação:
•
Deixar componentes/funções modularizados;• Criar repositório comum para futuras reutilizações.
4. Criar/alterar tabelas no BD para autenticação facial:
• Criar tabela para guardar LOGs para cada autenticação;• 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 parâmetro geral no sistema que dirá se os PDVS irão trabalhar cm
reconhecimento facial;• Criar atributo do cliente para isentá-lo de reconhecimento facial, só
7/24/2019 OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM
http://slidepdf.com/reader/full/os-beneficios-do-documento-de-especificacao-na-metodologia-scrum 46/46
permitido via administrador do sistema.
5. Alterar tela de cadastro de clientes para cadastrar hash de reconhecimentofacial:
•
Colocar opção na manutenção de clientes para receber reconhecimentofacial;
• Colocar opção pra remover reconhecimento facial;• Colocar opção 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 comcheque:
• Integrar tela de vendas c/ cheque com o componente desenvolvido parareconhecimento facial;
• Colocar opção para cadastrar reconhecimento facial para hashs nãocadastrados.
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 implementação/documentação/testes: 100 horas