OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO 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 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





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



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)



INSTITUTO DE EDUCAÇÃO SUPERIOR DA PARAÍBA

BACHARELADO EM SISTEMAS DE INFORMAÇÃO



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



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.



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.



“...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)



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.



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.



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 - 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



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



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



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.



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.



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.



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.



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.



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.



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.



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).



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.



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



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.



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.



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



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.



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.



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:



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.



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:



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.



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.



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



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;



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;



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:


• Verificar na internet;

•

Contactar empresas especializadas no fornecimento de hardware;



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



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.



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.



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



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.



41

ANEXOS



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: _____________________________________________________________



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:


• 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ó



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

Documents

OS BENEFÍCIOS DO DOCUMENTO DE ESPECIFICAÇÃO NA METODOLOGIA SCRUM