Anda di halaman 1dari 46
INSTITUTO DE EDUCAÇÃO SUPERIOR DA PARAÍBA BACHARELADO EM SISTEMAS DE INFORMAÇÃO ANTÔNIO ALVES DA SILVA NETO

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

CABEDELO-PB

2011

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 de Bacharelado em Sistemas de Informação, do IESP-PB, como requisito para a conclusão do curso e obtenção do título de Bacharel em Sistemas de Informação.

ORIENTADOR: PROF. ESP. MAXWELL ANDERSON IELPO DO AMARAL

CABEDELO-PB

2011

Dados de acordo com: AACR2, CDU e Cutter Biblioteca Central – IESP Faculdades – PB

S586b

Silva Neto, Antônio Alves da

Os

benefícios

do

documento

de

especificação na

metodologia scrum em um ambiente de desenvolvimento de sistemas de grande porte / Antônio Alves da Silva Neto. – Cabedelo, PB: [s.n], 2011.

45f.

Monografia (Graduação) – Instituto de Educação Superior da 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

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 de Bacharelado em Sistemas de Informação, do IESP-PB, como requisito para a conclusão do curso e obtenção do título de Bacharel 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-PB

2011

AGRADECIMENTOS

À Deus, o meu criador, meu perdoador e razão do meu viver. Esquecido por

alguns, ignorado por outros, mas És, para mim, o motivo de seguir em frente. Em Ti eu encontro a melhor filosofia de vida que alguém poderia encontrar. A Ti, Senhor e Rei, o meu

agradecimento por esta realização. Sem Ti, Senhor, eu não conseguiria e honra sejam dadas a Ti.

...

jamais. Toda a glória

À 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écnica

ou 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

21

LISTA DE TABELAS

Tabela 1 - Classificação do porte

28

Tabela

2

-

Classificação

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 ALGUMAS

EMPRESAS 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 COM DESENVOLVIMENTO DE SOFTWARE EM JOÃO PESSOA

42

43

1 INTRODUÇÃO

Atualmente, para as empresas nas mais diversas áreas de negócio e de todos os portes, 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 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.

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.

  • 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 qualquer empresa é 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 desenvolvimento 1 , 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 Sprints 2 .

  • 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 que seguissem 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.

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 de desenvolvimento, 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.

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 embarcados 3 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ção do 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.

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.

E se existe um ponto muito importante, na análise de sistemas, é a formalização do que

3 SCRUM: UMA ABORDAGEM INICIAL

Algumas questões de análise, como vimos anteriormente, e a necessidade de entregas rápidas ao cliente, bem como a organização no processo de software, motivaram, em 2001, a elaboração do Manifesto Ágil 4 e, com base nos seus valores e princípios, definiu-se o Scrum 5 , 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, segundo Kniberg. 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.

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 em 1995, 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.

  • 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. É o dia a dia do desenvolvimento.

  • 3.2.3 Scrum Team:

Este é o nome dado a um time de desenvolvimento no Scrum. Em um projeto podem existir 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).

Figura 1 - Taskboard Scrum Fonte: http://mudandouma pequenaempresa.blogspot.com/2007/11/livro-de-refer ncia-para-scrum.html O Taskboar d é um excelente indicador

Figura 1 - Taskboard Scrum

Fonte: http://mudandouma pequenaempresa.blogspot.com/2007/11/livro-de-refer ncia-para-scrum.html

O Taskboar d é um excelente indicador para o Scrum

Master, porque através

dele o mesmo pode saber o que está sendo feito no momento da Spri nt, bem como para os

próprios integrantes dos tim es Scrum se auto-gerenciarem.

3.3.2 Burnd own Chart:

É um gráfi co bem interessante (Figura 2) que indica

se o andamento das

estórias estão de acordo co m o planejado nas cerimônias, que iremos fal ar mais à frente.

Figura 1 - Taskboard Scrum Fonte: http://mudandouma pequenaempresa.blogspot.com/2007/11/livro-de-refer ncia-para-scrum.html O Taskboar d é um excelente indicador

Figura 2 - Burndown Chart

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

3.4 Fluxo d o Scrum

Baseados n o gráfico da figura 3, iremos resumidamen te, falar sobre o que acontece na Sprint e fora d ela.

3.4 Fluxo d o Scrum Baseados n o gráfico da figura 3, iremos resumidamen te, falar

Fig ura 3 - Processo de desenvolvimento com Scrum

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

3.4.1 Reuniã o de planejamento

Esta fase do

Scrum é realizada após a priorização das

estórias/bugs pelo PO.

Divide-se em dois moment os:

Sprint Plann ing 1 - Cerimônia, geralmente com o PO, q ue apresenta as tarefas já priorizadas para a equipe ;

Sprint Plann ing 2 - Cerimônia feita entre os membros d e cada equipe, onde os mesmo selecionam as tare fas apresentadas pelo PO, para a sua equipe . Neste momento, eles terão que fazer uma estima tiva de cada tarefa, não muito precisa, mas que permita ao Scrum Master saber se estas estóri as irão caber na Sprint.

Ainda na Sp rint Planning 2, os integrantes dos times irão tarefas menores, através d os post-its, que são fixados no taskboard na

dividir as estórias em seção Planejado. Em

cada post-it deverá ter uma descrição sucinta, porém clara, do que deve ser feito.

Bem, em se tratando da documentação gerada após a fa se de análise, o único

artefato que temos na

metodologia,

basicamente,

são

os

post-its

no quadro. Alguns

evangelistas, defensores d e metodologias ágeis, bem como uma par te dos consultores de

MPS.Br 6 , 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 apresentadas e o PO aceita ou rejeita cada implementação.

PO,

na

qual as

estórias

são

6 Melhoria de Processos do Software Brasileiro é simultaneamente um movimento para a melhoria da qualidade (Programa MPS.BR) e um modelo de qualidade de processo (Modelo MPS) voltada para a realidade do mercado de pequenas e médias empresas de desenvolvimento de software no Brasil.

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 positivos e 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.

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 de segurança em compras com cheques, e o sistema deveria realizar o reconhecimento facial de

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

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ão comum, 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.

5 A REALIDADE DO DESENVOLVIMENTO DE SOFTWARE EM ALGUMAS 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 de membros 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:

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 DESENVOLVEDORES

PORTE

CLASSIFICAÇÃO

EMPRESA A

17

12

41

MÉDIO

EMPRESA B

10

  • 4 PEQUENO

18

EMPRESA C

100

  • 4 GRANDE

108

EMPRESA D

150

  • 50 GRANDE

250

EMPRESA E

80

  • 45 GRANDE

170

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.

EMPRESA

CLASSIFICAÇÃO

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

EMPRESA

1. PROCEDIMENTO REALIZADO EM IMPLEMENTAÇÕES GRANDES

 

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

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 da arquitetura 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 uso 8 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 uma unidade funcional provida pelo sistema, subsistema, ou classe. É bem descrito na UML (Unified Modeling Language), que é uma linguagem de modelagem visual, e pode ser representado por uma elipse contendo, internamente, o nome do caso de uso.

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:

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 a integraçã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 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 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ão cadastrados.

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;

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;

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:

Verificar na

 

Contactar

 

Verificar

internet

empresas especializadas no fornecimento de hardware

compatibilidade do hardware com a linguagem de programação utilizada.

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, pelo contrário, veio para somar à metodologia, fornecendo informações importantes para a Sprint Planning 2 e, consequentemente, para o melhor andamento da Sprint.

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 XP 9 , 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 equipes pequenas 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 o desenvolvimento de software.

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.

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

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 março de 2011.

em:

22

de

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.

ANEXOS

ANEXO 1 - QUESTIONÁRIO APLICADO EM ALGUMAS EMPRESAS COM DESENVOLVIMENTO DE SOFTWARE EM JOÃO PESSOA

QUESTIONÁRIO APLICADO NAS EMPRESAS DA ÁREA DE TI

 

DADOS 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

(

 

(

) Lean

 

(

) PMBOK

(

) Scrum

(

) RUP

(

) Kanban

(

) 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 satisfatoriamente;

(

) Atende, mas com muitos atropelos;

(

) Atende perfeitamente.

(

) Atende, com problemas;

Comentários: _____________________________________________________________

ANEXO 2 - MODELO DE DOCUMENTO DE ESPECIFICAÇÃO PARA O 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 de cada 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 a integraçã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 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 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 reconhecimento

facial:

Colocar opção na manutenção de clientes para receber reconhecimento facial; 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 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ão cadastrados.

Testes:

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

  • 2. Testar cadastro de reconhecimento facial no PDV;

  • 3. Testar vendas com cheques, como um todo.

Estimativa inicial:

Horas de implementação/documentação/testes: 100 horas