FACULDADE ANHANGUERA DE BELO HORIZONTE

FELIPE CORSINO SAVIOTTE

APLICAO DA METODOLOGIA GIL SCRUM NO MERCADO DE TRABALHO

BELO HORIZONTE 2012

FACULDADE ANHANGUERA DE BELO HORIZONTE

FELIPE CORSINO SAVIOTTE

APLICAO DA METODOLOGIA GIL SCRUM NO MERCADO DE TRABALHO

Trabalho de concluso de curso apresentado a Faculdade de Informtica da Anhanguera Educacional, como requisito parcial obteno do grau de Bacharel em Sistemas de Informao, sob a orientao do professor Mestre Helio de Sousa Lima Filho.

BELO HORIZONTE 2012

FELIPE CORSINO SAVIOTTE

APLICAO DA METODOLOGIA GIL SCRUM NO MERCADO DE TRABALHO

Trabalho de concluso de curso apresentado a Faculdade de Informtica da Anhanguera Educacional, como requisito parcial obteno do grau de Bacharel em Sistemas de Informao, sob a orientao do professor Mestre Helio de Sousa Lima Filho.

Aprovada em 11 de Dezembro de 2012.

BANCA EXAMINADORA

Prof. Helio de Sousa Lima Filho Anhanguera Educacional Ltda

Prof. Ma. Zilma Gusmo Anhanguera Educacional Ltda

Prof. Ma. Tnia Mara Anhanguera Educacional Ltda

Dedico este trabalho a minha futura esposa Elizngela, meus pais e irmos e meus professores Helio de Sousa Lima Junior e Zilma Gusmo.

AGRADECIMENTOS

Agradeo este trabalho ao meu Deus pela tamanha ajuda imensurvel, agradeo a ele pela fora me dada em noites perdidas e manhs exaustivas, a voc toda minha glria. Obrigado meu Pai. Aos meus pais pelo incentivo financeiro e afetivo, pela cobrana, carinho e fora nos momentos precisos e em que estive para desistir. Agradeo minha dignssima Me por ser Me, Pai, Amiga. Obrigado querida Me. Aos meus irmos pelo companheirismo de sempre. A minha futura esposa, Elizngela, pelo carinho e dedicao ao meu lado, pela compreenso em disponibilizar o seu tempo para eu dedicar a este trabalho e por estar junto comigo no mesmo sonho em busca de um futuro melhor. Ao professor e orientador Helio de Sousa Lima Junior que me recebeu prontamente para me ajudar e me orientar na realizao desse trabalho com muita pacincia, compreenso, incentivo e oportunidades de aprendizado. A professora revisora de portugus Zilma Gusmo, pela prontido em ajudar, pelo ensino com qualidade e pelas dicas de imenso valor. E a meus colegas de faculdade e de trabalho pelo compartilhamento de conhecimento e experincias que direta ou indiretamente contriburam para a realizao deste trabalho. Que os vossos esforos desafiem as impossibilidades, lembrai-vos de que as grandes coisas do homem foram conquistadas do que parecia impossvel. (Charles Chaplin)

RESUMO

O objetivo deste estudo identificar o impacto da metodologia gil Scrum na produtividade e agilidade em uma equipe de desenvolvimento de software. Pretende-se demonstrar uma viso geral do processo de software e as diretrizes para a execuo de Projetos de Software; descrever a metodologia gil Scrum aplicada as necessidades do mercado atual; demonstrar as especificidades da Metodologia, a partir das caractersticas da Scrum; identificar a eficincia da Scrum para os indicativos de desempenho com equipes de projetos e avaliar o impacto da mudana cultural em uma Fbrica de Software, determinando os processos em equipes com o uso da Scrum. A metodologia do estudo orientou-se por um estudo de caso em uma Fbrica de Software, com a finalidade de identificar o impacto da metodologia gil na agilidade e produtividade em uma equipe de desenvolvimento de software com a aplicao da metodologia Scrum.

Palavras-chave: Processo de Software, Metodologias geis, Scrum.

ABSTRACT

The objective of this study is to identify the impact of the Scrum agile methodology in productivity and agility in a software development team. We intend to demonstrate an overview of the software process and guidelines for the implementation of Software Projects; describe the Scrum agile methodology applied current market needs; demonstrate the specifics of the methodology, based on the characteristics of Scrum; identify efficiency Scrum for the indicative performance with project teams and evaluate the impact of cultural change on a Software Factory, determining the processes in teams using the Scrum. The methodology of this study was guided by a case study in a Software Factory, in order to identify the impact of agile methodology in agility and productivity in a software development team in implementing Scrum methodology.

Keywords: Software Process, Agile Methodologies, Scrum.

SUMRIO 1 INTRODUO .......................................................................................................09 2 REFERENCIAL TERICO .....................................................................................11 2.1 O Processo de Software......................................................................................11 2.1.1 Modelos de Processos de Software .................................................................13 2.1.1.1 Modelo Cascata ............................................................................................14 2.1.1.2 Modelo em Espiral.........................................................................................15 2.1.1.3 Modelo Incremental.......................................................................................17 2.1.1.4 Modelo baseado em Componentes...............................................................19 2.1.2 Projeto de Software ..........................................................................................20 2.2 Metodologias geis .............................................................................................26 2.2.1 Histrico do Surgimento dos Mtodos geis (MA) e do SCRUM .....................27 2.2.2 O Manifesto gil ...............................................................................................29 2.3 Especificidades da Metodologia SCRUM ............................................................31 2.3.1 Caractersticas da Metodologia SCRUM ..........................................................31 2.3.2 Viso Geral do Ciclo do SCRUM......................................................................33 2.3.3 Planejamento da Sprint ....................................................................................35 2.3.4 Papis e Responsabilidades ............................................................................39 2.3.5 Principais Artefatos ..........................................................................................40 2.3.5.1 Product Backlog ............................................................................................40 2.3.5.2 Sprint Backlog ...............................................................................................41 2.3.5.3 Grfico de Burndown do Sprint .....................................................................41 2.3.5.4 Taskboard .....................................................................................................42 2.3.6 Fases do SCRUM ............................................................................................43 2.3.7 Detalhamento das fases...................................................................................45 3 O IMPACTO DA METODOLOGIA GIL SCRUM NA AGILIDADE E

PRODUTIVIDADE EM UMA EQUIPE DE DESENVOLVIMENTO DE SOFTWARE 48 3.1 Aspectos Metodolgicos......................................................................................48 3.2 Estudo de Caso Fbrica de Software ...............................................................48 3.2.1 Projeto ..............................................................................................................48 3.2.2 Planejamento ...................................................................................................49 3.2.3 Planejamento do Sprint (Sprint Planning).........................................................50

3.2.4 Reunies Dirias (Daily Scrum) .......................................................................50 3.2.5 Sprint Review ...................................................................................................51 3.2.6 Sprint Retrospective .........................................................................................51 3.2.7 Burndown Chart dos Sprint ..............................................................................52 3.3 Histria da Empresa ............................................................................................60 3.4 Mudana Cultural ................................................................................................62 3.5 A Situao da Empresa Atual..............................................................................63 4 CONSIDERAES FINAIS ...................................................................................65 REFERNCIAS BIBLIOGRFICAS ..........................................................................66 ANEXOS ...................................................................................................................72 Anexo A - Oitavo Sprint (Sprint Backlog, Reunies Dirias, Burndown Chart)..........72 Sprint Backlog ...........................................................................................................72 Reunies Dirias .......................................................................................................75 Burndown Chart ........................................................................................................76 Anexo B O Manifesto gil e os 12 princpios, guia dos valores geis ....................77

1 INTRODUO O mercado altamente competitivo exige sempre mais respostas rpidas e eficientes para produzir softwares de forma flexvel em um ambiente em constantes mudanas, com a necessidade de simplificao de processos e de alta produtividade. Com esta necessidade, os processos de desenvolvimento de software tradicionais no foram avaliados como uma alternativa eficiente para o caso, em contrapartida os mtodos geis se mostraram como uma alternativa eficiente a estas situaes impostas. Segundo Pressman (2006), essa prtica de projetar todo o sistema para s ento implementar obsoleta para o cenrio atual. praticamente impossvel prever com antecedncia todos os detalhes de um sistema, devido s condies mutveis de mercado e a freqente evoluo das necessidades do usurio final. A hiptese do estudo pressupe que nos casos de organizaes que lidam com engenharia de software sob o modelo de gerncia de projetos, tendo como foco a qualidade e a competitividade esto se adaptando aos mtodos geis (MA). A alternativa pelo uso de novas metodologias (MA) se caracteriza pela agilidade e assertividade que proporcionam na gerao de projetos de sucesso. Neste sentido, a delimitao do estudo compreende a anlise situacional da metodologia gil sob o processo da Scrum em uma fbrica de software. Nessa perspectiva a problemtica de estudo aponta a seguinte questo: Qual o impacto da metodologia gil sob o processo da Scrum na produtividade e agilidade no processo de desenvolvimento de software em ambientes complexos como uma fbrica de software? O objetivo deste estudo identificar o impacto da metodologia gil Scrum na produtividade e agilidade em uma equipe de desenvolvimento de software. Pretende-se demonstrar uma viso geral do processo de software e as diretrizes para a execuo de Projetos de Software; descrever a metodologia gil Scrum; demonstrar as especificidades da Metodologia, a partir das caractersticas da Scrum; identificar a eficincia da Scrum para os indicativos de desempenho com equipes de projetos e avaliar o impacto da mudana cultural em uma Empresa de Software, determinando os processos em equipes com o uso da Scrum.

10

A metodologia do estudo orientou-se por um estudo de caso em uma Fbrica de Software, com a finalidade identificar o impacto da metodologia gil Scrum na agilidade e produtividade de uma equipe de desenvolvimento de software. A Justificativa para a escolha do tema tem base no reconhecimento das dificuldades das equipes na utilizao deste tipo de metodologia, alm de mostrar que a metodologia gil Scrum pode ser adaptada a sua necessidade, mas ainda sim mantendo suas caractersticas. A monografia est formada por quatro captulos e as consideraes finais. A introduo apresenta uma viso geral sobre as Metodologias geis (MA), enfocando-se a problemtica, a hiptese, os objetivos, a justificativa e a relevncia do estudo. O primeiro captulo trata de uma viso geral sobre processos de software, os modelos de Processos de Software, a caracterizao do Processo de Software e as diretrizes para a execuo de Projetos de Software. O segundo captulo apresenta uma anlise sobre as metodologias geis, enfocando-se o histrico do surgimento e do Manifesto gil, faz-se no captulo um comparativo entre metodologias tradicionais e as metodologias geis. O terceiro captulo demonstra as especificidades da Metodologia, a partir das caractersticas da Scrum, apresentando as caractersticas da Scrum, os papeis e responsabilidades, os principais artefatos, como funciona o ciclo do Scrum e as fases da metodologia Scrum. O quarto captulo explora um estudo de caso com base no impacto da metodologia gil Scrum na produtividade e agilidade em uma equipe de desenvolvimento de software, a mudana cultura da Empresa de Software e a situao da empresa atual. As consideraes finais so uma sntese sobre o estudo, de forma que apresenta uma viso geral e pessoal do estudo.

11

2 REFERENCIAL TERICO

2.1 O Processo de Software

De acordo com Rocha, Maldonado e Weber (2001), existem diversos aspectos a serem abordados durante a definio de um processo de software. No ncleo de um processo de desenvolvimento esto as atividades-chave desse processo que se caracteriza pela anlise e especificao de requisitos e o desenvolvimento de testes. Sendo estas a base sobre a qual o processo de desenvolvimento deve ser construdo para garantir a qualidade do produto. As atividades de um processo implicam na escolha de um modelo de ciclo de vida, o detalhamento (decomposio) de suas macro-atividades; a escolha de mtodos, tcnicas e roteiros (procedimentos) para a sua realizao e a definio de recursos e artefatos necessrios e produzidos. Para Crtes (2001), no se pode definir um processo de Software de uma forma nica e universal. De modo a se atingir eficcia e de se conduzir construo de produtos de boa qualidade, um processo deve ser adequado ao domnio da aplicao e ao projeto especfico. Dessa forma, os processos precisam ser definidos caso a caso, considerando-se as especificidades da aplicao, a tecnologia a ser adotada na sua construo, a organizao onde o produto ser desenvolvido e o grupo de desenvolvimento. Tendo por objetivo, favorecer a produo de sistemas de alta qualidade, atingindo as necessidades dos usurios finais, dentro de um cronograma e oramentos previsveis. Segundo Antonioni (1995) o ponto de partida para a definio de um processo de desenvolvimento de software esta na escolha de um modelo de ciclo de vida. Este organiza as macro-atividades bsicas, estabelecendo precedncia e dependncia entre as mesmas. Um modelo de ciclo de vida pode ser definido como sendo passos ou atividades que devem ser executados durante um projeto. Segundo Borges e Falbo (2001, p. 2):
Um processo de software pode ser visto como um conjunto de atividades, mtodos, ferramentas e prticas que so utilizadas para construir um produto de software. O processo de software um conjunto de tarefas de engenharia de software necessrias para transformar os requisitos dos usurios em software. Na definio de um processo de software devem ser

12

consideradas as seguintes informaes: atividades a serem realizadas, recursos necessrios, artefatos requeridos e produzidos, procedimentos adotados e o modelo de ciclo de vida utilizado.

Ainda segundo os autores Borges e Falbo (2001), o processo de software um processo de engenharia que implica em mtodos e ferramentas apropriadas para a execuo de software de qualidade, as equipes que integram as atividades devem planejar todas as atividades-chave para definir e executar de forma precisa e detalhada todos os requisitos. Segundo Leite (2007), um processo pode ser visto como uma instncia de um modelo de processo ou mtodo com suas tcnicas e ferramentas associadas. O processo definido durante a etapa de planejamento, no qual as atividades que o compem foram alocadas aos membros da equipe de desenvolvimento, com prazos definidos e mtricas para se avaliar como elas esto sendo realizadas. Na viso de Soares (2010, p. 1):
Um processo de software (ou metodologia de desenvolvimento de software) um conjunto de atividades e resultados associados que auxiliam na produo de software. Dentre as vrias atividades associadas, existem por exemplo a anlise de requisitos e a codificao. O resultado do processo um produto que reflete a forma como o processo foi conduzido.

Para Leite (2007), enquanto um mtodo algo terico, o processo deve determinar aes prticas a serem realizadas pela equipe com prazos definidos. O processo o resultado do planejamento e precisa ser gerenciado no decorrer de sua execuo. Os processos de software, por muitas vezes, so decompostos em subprocessos, como, por exemplo, processo de desenvolvimento, processo de garantia de qualidade, processo de gerncia de projetos etc. Esses processos so compostos por atividades que tambm podem ser decompostas em sub-atividades. Para cada atividade importante saber quais so suas pr-atividades (atividades que devem preced-las), os artefatos de entrada (insumos) e sada (produtos), os recursos necessrios (humanos, software, hardware, entre outros) e os

procedimentos (mtodos, modelos de documento, tcnicas etc) a serem utilizados para a sua realizao (FALBO, 2005). A Tabela 1 esquematiza os elementos que compem um processo de software.

13

Tabela 1: Elementos que compem um processo de software

Fonte: FALBO, 2005, p. 05

Pressman (2006) define processo de software como um arcabouo para as tarefas que so necessrias para construir software de alta qualidade. O processo de software pode ser definido ento como todas as atividades que envolvem as interaes entre recursos humanos capacitados, artefatos, ferramentas e conhecimentos na gerao do produto.

2.1.1 Modelos de Processos de Software

Segundo Pressman (2006), os modelos de processo de software definem um conjunto de atividades, aes, tarefas, marcos, e produtos de trabalho necessrios para construir produtos de software de alta qualidade. O autor admite que, apesar de no serem perfeitos, estes modelos so de suma importncia para a construo de um software, ao fornecer os caminhos necessrios para conduzir projetos de software em conformidade com a Engenharia de Software.

14

2.1.1.1 Modelo Cascata

O modelo cascata descreve um mtodo de desenvolvimento que linear e seqencial. Na primeira vez que uma fase de desenvolvimento completada, o desenvolvimento prossegue para a prxima fase e no h retorno. A vantagem do desenvolvimento cascata que ele permite controle departamental e gerencial. Um planejamento pode ser atribudo com prazo final para cada estgio de desenvolvimento e um produto pode prosseguir no processo de desenvolvimento, teoricamente ser entregue no prazo. O desenvolvimento move do conceito, atravs do projeto (design), implementao, teste, instalao, descoberta de defeitos e termina com a operao e manuteno. Cada fase de desenvolvimento prossegue em uma ordem estrita, sem qualquer sobreposio ou passos iterativos (PRESSMAN, 2006). A desvantagem do desenvolvimento em cascata que ele no permite muita flexibilidade ou reviso. A primeira vez que uma aplicao est em estgio de teste muito difcil retornar e mudar alguma coisa que no foi bem pensada no estgio conceitual, com isto o cliente acaba tendo uma viso do sistema somente no final. As vantagens do modelo permitir a identificao de documentaes produzidas durante o ciclo de vida do projeto. Pressman (2006) aponta alguns problemas identificados neste ciclo de vida como: dificuldade de seguir o fluxo seqencial que o modelo prope; dificuldade para o cliente declarar todas as exigncias explicitamente; dificuldade de acomodar a incerteza natural que existe no comeo de muitos projetos; o cliente s tem uma verso de trabalho dos programas em um ponto tardio do cronograma, assim um erro no for detectado no incio, pode ter resultados comprometidos. O modelo cascata inicia de uma abordagem orientada a projetos para a engenharia de software. O projeto considerado uma tarefa claramente delineada para a qual os resultados desejados podem ser determinados completamente e sem ambigidade. A Figura 1 mostra uma representao deste modelo:

15

Figura 1: Representao do Modelo em Cascata Fonte: PRESSMAN, 2001, p. 123

Para Rocha, Maldonado e Weber (2001), esse modelo apresenta algumas dificuldades na medida em que atualmente os projetos raramente podem ser produzidos com base na sequncia que o modelo determina, quando se aplicam processos de iterao ocorrem problemas devido ao processo linear que no favorece solues diante de incertezas. Outros modelos se caracterizam pela capacidade de manter interfaces interativas que tem passado por constantes mudanas e aperfeioamentos.

2.1.1.2 Modelo em Espiral

O modelo espiral, originalmente proposto por Boehm em 1988 usa uma abordagem evolucionria engenharia de software, capacitando o desenvolvedor e o cliente a entender e reagir aos riscos em cada fase evolutiva. O modelo espiral usa a prototipao como um mecanismo de reduo de riscos, mas, o que mais

16

importante, possibilita que o desenvolvedor aplique a abordagem de prototipao em qualquer etapa da evoluo do produto. Ele mantm a abordagem de passos sistemticos sugerida pelo ciclo de vida clssico, mas incorpora-a numa estrutura iterativa que reflete mais realisticamente o mundo real. O modelo espiral exige uma considerao direta dos riscos tcnicos em todas as etapas do projeto e, se adequadamente aplicado, deve reduzir os riscos antes que eles se tornem problemticos (PRESSMAN, 2006). O modelo clssico no continha esse relevante avano que a adaptao ao longo da vida do software, por exemplo, sempre que uma modificao iniciada, o processo comea do ponto de entrada adequado, por exemplo, aperfeioamento de produto. Segundo Santos e Rocha (2012, p. 3):
O modelo original em espiral organiza o desenvolvimento como um processo iterativo em que vrios conjuntos de quatro fases se sucedem at se obter o sistema final. Um ciclo se inicia com a determinao de objetivos, alternativas e restries (primeira tarefa) onde ocorre o comprometimento dos envolvidos e o estabelecimento de uma estratgia para alcanar os objetivos. Na segunda tarefa, avaliao de alternativas, identificao e soluo de riscos, executa-se uma anlise de risco.

Este modelo uma abordagem mais realista do desenvolvimento de sistemas e softwares de grande porte. Como o software evolui medida que o processo avana, o desenvolvedor e o cliente entendem melhor e reagem aos riscos de cada nvel evolucionrio (PRESSMAN, 2006). A Figura 2 mostra uma representao desse modelo:

17

Figura 2: Representao do Modelo Espiral Fonte: PRESSMAN, 2006, p. 45

Na viso de Macoratti (2012) o modelo original em espiral organiza o desenvolvimento como um processo iterativo em que vrios conjuntos de quatro fases se sucedem at se obter o sistema final. Um ciclo se inicia com a determinao de objetivos, alternativas e restries (primeira tarefa) onde ocorre o comprometimento dos envolvidos e o estabelecimento de uma estratgia para alcanar os objetivos. Na segunda tarefa, anlise e avaliao de alternativas, identificao e soluo de riscos, executa-se uma anlise de risco. Prototipao uma boa ferramenta para tratar riscos. Se o risco for considerado inaceitvel, pode parar o projeto. Na terceira tarefa ocorre o desenvolvimento do produto. Neste quadrante pode-se considerar o modelo cascata. Na quarta tarefa o produto avaliado e se prepara para iniciar um novo ciclo.

2.1.1.3 Modelo Incremental

O modelo incremental segundo Pressman (2006) combina elementos do modelo cascata sendo aplicado de maneira interativa. O modelo de processo incremental interativo igual prototipagem, mais diferente a prototipagem o

18

incremental tem como objetivo apresentar um produto operacional a cada incremento realizado. importante notar que a filosofia do Modelo Incremental tambm usada por todos os modelos de processos geis. A Figura 3 mostra uma representao deste modelo:

Figura 3: Representao do Modelo Incremental (Adaptado) Fonte: PRESSMAN, 2006, p. 40

O modelo ideal para a coleta inicial dos requisitos para o planejamento de projeto, com maior abertura para a participao do cliente, favorece os procedimentos de anlise de risco (PETERS, 2001). O Modelo de Processo Incremental, como a prototipagem e outras abordagens evolucionrias, iterativo por natureza. O Modelo Incremental tem o objetivo de apresentar um produto operacional a cada incremento. O

desenvolvimento incremental particularmente til quando no h mo-de-obra e/ou

19

recursos tcnicos disponveis para a implementao completa, dentro do prazo comercial de entrega estabelecido para o projeto (PRESSMAN, 2006). De acordo com Macoratti (2012) um exemplo do funcionamento do modelo seria: numa primeira iterao deve-se identificar a viso global e determinar a viabilidade econmica do sistema, efetuar a maior parte da anlise e um pouco de desenho e implementao. Numa segunda gerao, deve-se concluir a anlise, fazer uma parte significativa do desenho e um pouco mais de implementao. Numa terceira iterao, deve-se concluir o desenho, fazer-se parte substancial da implementao, testar e integrar um pouco, etc. Ou seja, a principal conseqncia da aproximao iterativa que os produtos finais de todo o processo vo sendo amadurecidos e completados ao longo do tempo, mas cada iterao produz sempre um conjunto de produtos finais.

2.1.1.4 Modelo baseado em Componentes

Conforme Reis (2003) o modelo baseado em componentes tem sido um dos meios da Engenharia de Projetos para favorecer a melhoria da qualidade e aumento da produtividade. No entanto, equipes de projetos de software ainda encontram certas dificuldades em razo da necessidade de interdependncia em relao aos fornecedores, levando-se em considerao a dificuldade de controle sobre o produto. Pressman (2006) caracteriza esse modelo como incorporador do modelo espiral com uma abordagem iterativa para a criao de software. Atravs desta abordagem uma biblioteca de classes construda com as classes identificadas no desenvolvimento do software e a partir de ento toda iterao da espiral dever verificar o contedo da biblioteca que pode ser reutilizado ou identificar se novas classes devem ser inseridas na biblioteca para posterior reuso. Goulo (2002, p. 2) avalia que:
O desenvolvimento de software baseado em componentes encarado como uma abordagem que permite simultaneamente reduzir custos no desenvolvimento, encurtar o perodo necessrio ao desenvolvimento do software e aumentar a sua qualidade.

20

Segundo Pressman (2006), este mtodo simplifica setenta por cento do trabalho do desenvolvedor, sendo composto de aplicaes a partir de componentes de software previamente preparados, similar classes ou pacotes orientados a objeto. Seguindo o pensamento do autor, essa maneira pode ser comparada aos softwares de prateleira, que so formuladas de forma a atender quaisquer empresas de acordo com o tipo de sistema desenvolvido. A Figura 4 mostra as fases do desenvolvimento baseado em componentes:

Figura 4: Representao das fases do modelo baseado em componentes Fonte: PRESSMAN, 2006, p. 48

Contudo, sendo um mtodo evolucionrio, o modelo de desenvolvimento baseado em componentes de engenharia de software utilizado quando se tem parte do cdigo pronto para reuso, simplificando parte do trabalho.

2.1.2 Projeto de Software

Na Engenharia de Software os procedimentos de um projeto exige critrios para a anlise de riscos, j que as probabilidades so maiores que em outras reas na medida em que no existe um procedimento de padronizao. Embora seja necessria a existncia de planejamento e gerenciamento de Software, essa rea

21

tem muitos desafios e dificuldades, considerando-se que o software um produto intangvel. Conforme Gusmo & Moura (2008, p. 2):
O desenvolvimento de software pode ser considerado uma atividade de risco e diversos estudos e autores atuais comprovam que muitos dos problemas envolvidos em projetos de grande porte esto muito mais associados s falhas em atividades de gerenciamento do que falhas em atividades tcnicas.

Portanto, segundo Martins (2009), no h um processo de software que seja regido por um padro, j que na Engenharia de Software os projetos so freqentemente nicos, embora do mesmo modo exijam por parte das equipes de stakeholders os mesmos aspectos formais comuns dos projetos em outras reas. De acordo com Pressman (2001) existem alguns princpios para o projeto de software que, quando adotados pelos mtodos e tcnicas usados para o seu desenvolvimento, podem tambm auxiliar no processo de suas futuras evolues. A modularizao do sistema, promovendo mdulos com baixo acoplamento e alta coeso, pode facilitar a capacidade de entendimento de cada parte separadamente e a sua consequente modificao. Nesse sentido, a anlise de risco em projetos contempla as metodologias de avaliao da viabilidade tcnica, scio-ambiental e financeira que fazem parte da etapa de planejamento e varia conforme o tipo de projeto. So definidos, ento, os indicadores de viabilidade e de riscos inerente s atividades do projeto. Esse conhecimento possibilita a deciso de implantar os projetos. Segundo Oliveira Filho (2007, p. 16):
Projeto um termo freqentemente usado, em muitas organizaes e instituies, por muitas pessoas e nos mais variados contextos, inclusive significando inteno. Como ocorre com outros termos que so amplamente usados, mas raramente definidos, os significados podem variar bastante e essas diferenas podem, eventualmente, prejudicar a compreenso e a comunicao.

Compreende-se, portanto, que o projeto se realiza em variados contextos institucionais que devero ser considerados de acordo com a realidade da organizao. No entanto, existem algumas particularidades comuns aos projetos que permitem chegar seguinte definio.

22

Segundo Oliveira Filho (2007, p. 1):

Projeto um conjunto de atividades ou medidas planejadas para serem executadas que dependem de certos requisitos das equipes como responsabilidade de execuo definida; objetivos determinados; escopo definido; prazo delimitado e recursos especficos.

Alm disso, um projeto caracterizado por criar algo novo, algo que no havia sido feito antes da mesma maneira, que envolve um escopo planejado e os requisitos necessrios para o desenvolvimento de aes de riscos na fase de planejamento dever ser clara no projeto. Essas variveis permitem orientar as aes do projeto (OLIVEIRA FILHO, 2007). O escopo do projeto representa no processo a somativa dos produtos e das metas contidos na proposta do projeto, bem como s principais atividades necessrias para garantir a entrega desses produtos e o alcance dessas metas. A definio das responsabilidades importante tanto para poder alocar as pessoas com as suas diversas funes dentro do projeto, quanto para conhecer as relaes que o projeto tem com a organizao e o comprometimento das instncias superiores e de outros envolvidos no projeto. Segundo Wiermann (2006, p. 1):
Um projeto considerado bem sucedido quando desenvolvido dentro das expectativas de tempo, custo e qualidade, alm do cliente ter ficado satisfeito e a moral da equipe ter se mantida alta durante todo o ciclo de vida do projeto. Entretanto, nem sempre a existncia de um bom planejamento de prazos, recursos, custos e qualidade suficiente para garantir o sucesso de um projeto. Muitas vezes, fatores externos tm influncia decisiva no sucesso ou fracasso de um empreendimento, o que evidencia a ateno que deve ser dispensada ao gerenciamento de riscos.

Neste contexto, um projeto para ser considerado fator de sucesso quando verificado vrios aspectos importante no seu ciclo de vida como tempo, custo e qualidade. Portanto, devem-se afastar todos os riscos de fracasso durante o processo de criao do produto. Para Oliveira Filho (2007) o escopo deve ser claro para no ultrapassar as limitaes que qualquer projeto tem, seja em termos de competncia institucional, seja pela complexidade do trabalho ou do objeto ou ainda pelas mudanas que pretende implementar.

23

Marquioni (2008, p. 3) avalia que:

Quando se trata de projetos de software, o termo escopo costuma referenciar apenas o contedo do produto a desenvolver mais precisamente, uma lista geral dos requisitos que fazem parte do produto de software. Curiosamente, so raros os casos em que h meno explcita ao escopo do projeto segundo sua definio conceitual original, que envolve a identificao e formalizao das atividades que devem ser executadas para desenvolver ou manter o produto de software. Mesmo quando utilizado o termo escopo do projeto, a inteno dos gestores de software parece ser referenciar o escopo do produto gerado a partir da execuo do projeto.

A correta descrio do escopo fundamental para o sucesso do projeto, pois favorece a realizao de melhores estimativas de prazos, recursos, custos e riscos, e, com isso, previne a ocorrncia de mudanas constantes ou que poderiam ser evitadas por meio de planejamento. De acordo com TCU (2006), o prazo delimitado uma caracterstica bsica e essencial do projeto e a falta de planejamento em relao ao tempo poder contribuir para fatores de risco. O fato de ele ter incio e fim definidos facilita enormemente o seu planejamento, que deve ser realista. Um projeto depende de recursos, como qualquer atividade. Para a realizao de um planejamento realista, a dimenso dos recursos precisa ser conhecida para no correr o risco de se fazer um planejamento fictcio. Os recursos no se restringem apenas aos financeiros. Na maioria das vezes, o fator decisivo so os recursos humanos adequados. Leite (2006) avalia que o gerente de projetos dever determinar em sua rotina alguns procedimentos bsicos como: monitorar e avaliar os prazos, os custos do oramento, a postura da equipe diante da alocao de tarefas, as ferramentas e sua utilidade e adequao para o tipo de projeto, o planejamento das atividades e na anlise de qualidade do produto averiguar os modelos, prottipos e documentos e identificar se o software produzido tem qualidade. Todos esses fatores reduzem riscos e promovem aes que permitem a busca de solues nos casos de perdas e impactos gerados. Portanto, a gerncia deve manter certa padronizao de comportamento que permita manter os mecanismos de monitoramento e elaborao de relatrios para facilitar os processos e uma tecnologia altura do projeto.

24

Silva (2004, p. 14):

Para se conduzir um projeto de software de forma bem sucedida, atendendo com qualidade os custos e prazos previamente estabelecidos, deve-se ter a capacidade de gerir este processo. Destaca-se ento, a necessidade de um gerenciamento de projeto eficaz que possibilite no s conduzir o processo de forma compreensiva e organizada, mas que permita tambm, medir a qualidade deste processo e, por conseqncia, do produto criado.

Esse cenrio, praticamente, exige o emprego de metodologias e prticas modernas, enfatizando, assim, a importncia de Projetos. Projetos diferem de processos, uma vez que determinam tempo de execuo e resultados especficos que em sua maioria so nicos. Conforme Knob et al. (2006, p. 1):
O fato de ser um empreendimento nico nunca antes realizado uma das principais caractersticas que diferenciam um projeto de uma operao continuada. esta mesma caracterstica que faz com que os projetos tornem-se ambientes de incertezas. A grande complexidade presente nos projetos de desenvolvimento de software s faz aumentar o nvel de incerteza. Falta de conhecimento tcnico, mudana ou incompatibilidade de tecnologias, mudanas de escopo e rotatividade da equipe so apenas alguns exemplos de incertezas que podem influenciar o andamento do projeto.

Nesse sentido, uma definio clssica para Projeto deve considerar a convergncia de aes para a realizao de um resultado. Um Projeto, contudo, apresenta carter temporrio, pois possui incio e fim previamente estipulados. Projetos, portanto, no se confundem com processos. Um Projeto um empreendimento temporrio com o objetivo de criar um produto ou servio nico. (Project Management Body of Knowledge, apud Possi et al 2004). Todo Projeto visa mudana de uma situao ou processo, quer seja por melhorias e aprimoramento, quer seja por inovao. Nesse sentido, a avaliao anterior de sua viabilidade tcnica e financeira faz parte da etapa de planejamento e varia conforme o tipo de projeto. So definidos, ento, os indicadores que possibilitam a deciso de implantar os projetos. Segundo Wiermann (2006), geralmente os projetos so classificados em termos de investimento e retorno esperado, como, por exemplo: investimento com retorno esperado para stakeholders; investimento com retorno esperado para os

25

processos internos; investimento com retorno esperado para a preservao de dados ou servios. Nesse princpio, um mesmo projeto pode receber mais de uma classificao, isto , tanto pode estar trazendo benefcios para as partes interessadas. Atualmente a questo da qualidade na Engenharia de Software estabelece claramente como os suportes para garantir a melhoria de processos quanto ao ciclo de vida de desenvolvimento do projeto. A qualidade de processos envolve a gerncia de riscos no ciclo de qualidade e custo do produto com base na viso de planejamento. Tsukumo et al. (2009, p. 4) avalia que:
A aplicao de mtodos de anlise de riscos, gesto de configurao; controle de documentos; registros da qualidade, medio; regras, prticas e convenes; ferramentas e tcnicas; aquisio; produto de software includo e treinamento devem fazer parte de um projeto, nesse sentido, deve ser determinada em conjunto com outras reas da empresa, de maneira que todas as possibilidades de investimento e retorno sejam avaliadas.

A implementao de desenvolvimento de solues voltadas para anlise de riscos em projetos de software trouxe um grande avano na qualidade. Com base nos estudos de Teixeira Filho (2001), sobre a composio de um Projeto, a seguir est relacionada s principais etapas na elaborao de um Projeto dever ser em primeira mo a definio da equipe; o mapeamento das fontes a serem usadas para a obteno dos dados e todas as informaes; a modelagem da base de dados; a definio da tecnologia a ser adotada; a coleta de informaes; a anlise de informaes; a divulgao dos resultados para os usurios e a fase de avaliao e planejamento do ciclo de expanso do sistema. De acordo com Pressman (2001, p. 88):
A gerncia um item fundamental dentro de um projeto de software, e deve estar presente durante todo o ciclo de vida do desenvolvimento de um sistema. A XP, como qualquer outra metodologia de desenvolvimento, precisa de gerenciamento. Por outro lado, prezando sempre a simplicidade e a comunicao, no pode ser gerenciada da mesma maneira que as metodologias tradicionais de desenvolvimento.

Portanto, verifica-se que a gerncia muito relevante em todas as fases do projeto, portanto o gerenciamento de projetos fundamental para definir nos processos: definio, planejamento, execuo, controle e aprendizagem.

26

2.2 Metodologias geis

Segundo Santos (2007), uma das principais caractersticas de um projeto de desenvolvimento de software a grande instabilidade de requisitos. As solicitaes de mudanas por parte do cliente so constantes e com as metodologias tradicionais de desenvolvimento de software muito complicado que um projeto possa ser entregue no prazo firmado, no custo previsto e, principalmente, com a qualidade desejada. De acordo com Soares (2010), as Metodologias geis tm sido apontadas como uma alternativa s abordagens tradicionais para o desenvolvimento de software. As metodologias tradicionais, conhecidas tambm como pesadas ou orientadas a planejamentos, devem ser aplicadas apenas em situaes em que os requisitos do sistema so estveis e requisitos futuros so previsveis. Entretanto, em projetos em que h muitas mudanas, em que os requisitos so passveis de alteraes, onde refazer partes do cdigo no uma atividade que apresenta alto custo, as equipes so pequenas, as datas de entrega do software so curtas e o desenvolvimento rpido fundamental, no pode haver requisitos estticos, necessitando ento de metodologias geis. Alm disso, o ambiente das organizaes dinmico, no permitindo ento que os requisitos sejam estticos. Segundo Zanatta (2003), o recente surgimento dos mtodos geis no cenrio do desenvolvimento de software pode requerer que a atual rea da engenharia de requisitos repense alguns de seus procedimentos. Isto se deve principalmente porque estes mtodos abdicam, em parte, de controles e documentao to presentes nesta rea. Os mtodos geis em geral no mencionam como realizam, por exemplo, a documentao da especificao de requisitos, ou como mantm a rastreabilidade dos requisitos. Os princpios apresentados pelo manifesto gil mostram que certos valores relacionados com a rea de engenharia de requisitos continuam sendo importantes, como o entendimento dos requisitos, porm preocupam-se em no gerar muita

documentao que, justificam, provavelmente nunca ser lida.

27

2.2.1 Histrico do Surgimento dos Mtodos geis (MA) e do SCRUM

O surgimento das Metodologias geis (MA) veio como resultados do avano no desenvolvimento de software com a finalidade de superar os mtodos clssicos considerados pesados e sem flexibilidade. Nos anos 1990, havia um grande descontentamento com a forma como o desenvolvimento de software vinha sendo abordado nas ltimas dcadas. Como resposta, surgiram ento diversas metodologias consideradas leves, como o Scrum, o Extreme Programming e o Crystal, entre outras (COCKBURN, 2007; SCHUH, 2005). De acordo com Armony (2010), a evoluo da tecnologia permitiu tambm um progresso contnuo na Engenharia de Software atravs da proposio de novas metodologias para tornar os processos de desenvolvimento de software mais simplificado em relao s burocracias comuns nos modelos clssicos. Os novos mtodos geis favorecem a participao dos clientes, processos de adaptao e inspeo, permitindo equipe atingir a qualidade no produto. Ainda segundo Armony (2010), o uso de metodologias geis vem se popularizando no mercado de projetos de tecnologia da informao (TI) como uma alternativa bem-sucedida s prticas e metodologias tradicionais, que muitas vezes no so adequadas ao cenrio de mudanas e de trabalho criativo de projetos de TI, e assim vem sendo responsabilizadas pelo alto ndice de fracasso em projetos que as aplicam nessa rea. No entanto, a prtica dos valores geis por equipes de TI, essenciais para o sucesso no uso das metodologias e frameworks geis, pode representar uma quebra de paradigma de difcil realizao para a maioria das equipes. A utilizao de mtodos geis tem se tornado adequado na realidade de organizaes complexas que atuam com equipes multifuncionais e em situaes que exigem procedimentos de qualidade. De acordo com Soares (2010), a ideia das metodologias geis o enfoque nas pessoas e no em processos ou algoritmos. Alm disso, existe a preocupao de gastar menos tempo com documentao e mais com a implementao. Uma caracterstica das metodologias geis que elas so adaptativas ao invs de serem preditivas. Com isso, elas se adaptam a novos fatores decorrentes do desenvolvimento do projeto, ao invs de procurar analisar previamente tudo o que pode acontecer no decorrer do desenvolvimento.

28

Neste sentido uma das grandes vantagens das metodologias geis a constituio de novos padres no desenvolvimento de software que possuem novas abordagens que superam os modelos clssicos inapropriadas para projetos que podem sofrer modificaes. O Scrum, juntamente com as outras metodologias que surgiram a partir das mesmas necessidades de agilizar o processo de desenvolvimento de software, acarretaram no surgimento do Manifesto gil (2001) no qual foram expostos os princpios do desenvolvimento gil: desenvolvimento e projetos que atendam aos clientes, projetos flexveis e indivduos e iteraes ao invs de processos e ferramentas (MANIFESTO GIL, 2001). De acordo com Estudo de Arajo (2009) a Scrum foi criada por Jeff Sutherland, Ken Schwaber e John Scumniotales na dcada de 1990, a SCRUM uma metodologia gil para gerenciamento de projetos, geralmente de software, mas pode ser utilizada para outros tipos, como desenvolvimento de produtos fsicos, ou projetos diversos. Baseada no Pensamento Lean (Lean Thinking), desenvolvimento iterativo e incremental, e novas estratgias de criao de produtos. Sua aplicao no est limitada a projetos de software. As razes do SCRUM esto num artigo que sumarizam as 10 melhores prticas em empresas japonesas, escrito por Takeuchi e Nonuka, cujo ttulo "O jogo do desenvolvimento de novos produtos" que foi publicado na Harvard Business Review em janeiro de 1986. Este artigo introduziu o termo SCRUM, que se refere ao jogo de Rugby, quando os jogadores se organizam em crculo para planejar a prxima jogada. uma forma de mostrar que o projeto deve ser conduzido em pequenos ciclos, mas com uma viso de longo prazo, que ganhar o jogo. Jeff Sutherland um dos criadores do SCRUM e era vice-presidente da Easel Corporation em 1994, quando introduziu algumas das prticas do SCRUM, com base neste artigo (MARTINS, 2009).

29

2.2.2 O Manifesto gil

Em fevereiro de 2001, um grupo de dezessete representantes dessas metodologias de desenvolvimento de software consideradas leves se reuniu em Snowbird, Utah para levantar pontos em comum entre suas metodologias. No havia a inteno de uma unificao de metodologias e a expectativa de se chegar a qualquer tipo de consenso era limitada e variada entre os participantes. No entanto, os participantes concordaram em importantes pontos e, ao final de dois dias, estabeleceram o termo gil para representar o novo movimento em comum e escreveram e assinaram o que ficou conhecido como Manifesto gil. Esse manifesto contm um conjunto de valores e princpios que devem balizar o desenvolvimento gil de software. Nesse encontro tambm foi formada a Agile Alliance, entidade responsvel por atualizar e manter os valores geis (COCKBURN, 2007; FOWLER & HIGHSMITH, 2001). O intuito inovador de profissionais gabaritados nesta rea favoreceu a idealizao de novos princpios adotados em forma de metodologias para ser usadas por equipes no desenvolvimento de software (FUGGETTA, 2002). A inovao das diretrizes se constitui de um tipo de metodologia mais gil para a superao das metodologias clssicas consideradas pesadas e pouco eficientes em ambientes complexos. A evoluo embora, lenta produziu

transformaes qualitativas que ganharam grande fora diante da necessidade de favorecer uma nova cultura de trabalho gil e voltada para posto qualidade, em seus mltiplos aspectos. Segundo Sato (2007, p. 10):
O manifesto gil apresenta uma nova filosofia para o desenvolvimento de software. Sob seus valores e princpios aparecem diversas abordagens mais especficas com diferentes idias, comunidades e lderes. Cada comunidade forma um grupo distinto, porm todas seguindo os mesmos princpios. comum inclusive a troca de conhecimento e prticas entre membros de diferentes comunidades, formando um ecosistema em torno de diversos mtodos.

Para Pressman (2001), o manifesto gil conseqncia do saber acumulado que se aplica na implementao de novos e melhores meios de fazer para gerar metodologias de mudana fundamental nos pressupostos da mensurao do desempenho. A introduo da Filosofia gil e dos conceitos de mudana em

30

ambientes complexos vem fugindo do tradicional modelo sequencial e focados em documentao. importante salientar que o movimento gil no contrrio definio de um processo. Segundo Fowler e Highsmith (2001), os desenvolvedores geis adotam a modelagem, mas no apenas para arquivar diagramas em gavetas empoeiradas; adotam a documentao, mas no para produzir pilhas de papis desatualizados e nunca consultados; e adotam o planejamento, mas reconhecendo os seus limites em um ambiente turbulento. As organizaes que decidem pelas metodologias geis evidenciam o contexto de mudana na cultura do trabalho, dos quais iro depender do trabalho com um grupo de pessoas que preservavam um conjunto de valores compatveis. As relaes interpessoais nas organizaes so consideradas atualmente como um fator de cultura para inserir nos rumos da empresa, como formadores da identidade organizacional. A definio de cultura organizacional diversa por que pressupe uma espcie de modelo, cujo processo de aprendizagem se incorpora nos processos de trabalho, relaes interpessoais e nas formas de trabalho com as Metodologias geis. Pressman (2001) avalia que as mudanas no determinam uma nometodologia ou a incorporao de medidas que finalizam o uso de documentos e contratos, mas apenas medidas de agilidade e superao do uso excessivo de controles. Para esse processo as metodologias geis tm como diferencial o uso de modelagem, o planejamento tambm representa uma mudana, mas no uma superao desse relevante processo em ambientes complexos. Para Fuggetta (2002), o Manifesto gil trouxe uma nova concepo de metodologias que podem ser consideradas leves em relao s tradicionais, as novas metodologias agilidade e adaptatividade, valoriza o processo nas fases de desenho e construo, favorece uma maior interao com outras metodologias, no implica no uso de modelos especficos de modelagem, apresenta desenvolvimento iterativo, tem foco no cliente e na qualidade do produto e permite adaptaes e mudanas eficientemente para ambientes complexos.

31

2.3 Especificidades da Metodologia Scrum

2.3.1 Caractersticas da Metodologia SCRUM

Scrum um framework (ou arcabouo) gil para a gerncia de projetos de desenvolvimento iterativo e incremental de software, que trabalha com iteraes curtas de desenvolvimento, ao final das quais h adio de valor ao produto. Scrum define valores e prticas para a gerncia do projeto, sem especificar prticas mais especficas de desenvolvimento, testes ou levantamento de requisitos, por exemplo. Dessa forma, Scrum funciona bem combinado com ou complementado por outros mtodos (ARMONY, 2010). Segundo Maral (2007, p. 3), o Scrum pode ser descrito da seguinte forma:
O Scrum um mtodo que aceita que o desenvolvimento de software imprevisvel e formaliza a abstrao, sendo aplicvel a ambientes volteis. Ele se destaca dos demais mtodos geis pela maior nfase dada ao gerenciamento do projeto. Rene atividades de monitoramento e feedback, em geral, reunies rpidas e dirias com toda a equipe, visando identificao e correo de quaisquer deficincias e/ou impedimentos no processo de desenvolvimento.

O mtodo gil Scrum oferece as condies de auxiliar no processo de definio do projeto e no desenvolvimento do produto com maior participao dos anseios dos clientes, favorecendo a implementao de planos para a melhoria das equipes de projetos (ZANATTA; VILAIN, 2009). Segundo Zanatta e Vilain (2009), as prticas gerenciais do Scrum so: Product Backlog, Daily Scrum, Sprint, Sprint Planning Meeting, Sprint Backlog e Sprint, Review Meeting. As prticas so relacionadas rea de requisitos no mtodo gil Scrum. O Product Backlog o ponto inicial do Scrum, sendo considerada a prtica responsvel pela coleta dos requisitos. Nesta prtica, atravs de reunies com todos stakeholders no projeto, so apontados os itens com todas as necessidades do negcio e os requisitos tcnicos a serem desenvolvidos, ou seja, o Product Backlog uma lista de atividades que provavelmente sero desenvolvidas durante o projeto. As prticas gerenciais da Scrum favorecem os indicativos corporativos de qualidade no ambiente interno de equipes no desenvolvimento distribudo de software em cada uma das prticas gerenciais.

32

Vale ressaltar que as prticas do SCRUM podem ser aplicadas em qualquer contexto onde pessoas precisem trabalhar juntas para atingir um objetivo comum. SCRUM recomendado para projetos de outras reas alm de software principalmente para projetos de pesquisa e inovao (CHAPIEWSKI, 2009). A Scrum tem como foco as equipes pequenas e os clientes em ambientes complexos e requisitos instveis. A partir da gesto, podem-se determinar iteraes mais curtas que so divididas em um prazo de 30 dias, os chamados Sprints (ANTONIONI, 1995, p. 13). O uso da metodologia gil Scrum permite a administrao do tempo do projeto de software que consiste no prprio ato de planejar as atividades aos perodos de execuo, na realidade um mtodo de controlar o tempo e assim trazer mais fidedignidade ao projeto ao ponto que elabora um cronograma de aes e parte para execut-lo, a partir de reunies. Soares (2009, p. 5) avalia que:
A Scrum apresenta uma abordagem emprica que aplica algumas idias da teoria de controle de processos industriais para o desenvolvimento de softwares, reintroduzindo as idias de flexibilidade, adaptabilidade e produtividade. O foco da metodologia encontrar uma forma de trabalho dos membros da equipe para produzir o software de forma flexvel e em um ambiente em constante mudana.

Na Scrum existem reunies de acompanhamento dirias. Nessas reunies, que so preferencialmente de curta durao (aproximadamente quinze minutos), so discutidos pontos como o que foi feito desde a ltima reunio e o que precisa ser feito at a prxima. As dificuldades encontradas e os fatores de impedimento (bottlenecks) so identificados e resolvidos (SOARES, 2010). Segundo Schwaber (2004), SCRUM no um processo previsvel, ele no define o que fazer em toda circunstncia. Ele usado em trabalhos complexos nos quais no possvel prever tudo o que ir ocorrer e oferece um framework e um conjunto de prticas que torna tudo visvel. Isso permite aos praticantes do SCRUM saber exatamente o que acontece ao longo do projeto e fazer os devidos ajustes para manter o projeto se movendo ao longo do tempo, visando alcanar os seus objetivos. Logo, o SCRUM no vai dizer exatamente o que fazer, no ir resolver todos os seus problemas, mas com certeza os problemas sero mais facilmente

33

identificados. Por ser um framework, ir servir como um guia de boas prticas para atingir o sucesso. Entretanto, as decises de quando e como us-Io, quais tticas e estratgias seguir para obter produtividade e realizar as entregas ficam por conta de quem aplicar. O conhecimento das suas prticas permite a aplicao das mesmas de forma variada e este um dos aspectos positivos do SCRUM, a adaptabilidade (SCHWABER, 2004).

2.3.2 Viso Geral do Ciclo do SCRUM

Um dos conceitos mais importantes so o Backlog do produto (ou Product Backlog) e o Backlog de Impedimentos - lmpediment Backlog, ambos considerados o corao do SCRUM. O Product Backlog contm uma lista de itens priorizados que incluem tudo o que precisa ser realizado, que possa ser associado com valor de negcio e para a finalizao do projeto, sejam requisitos funcionais ou no. importante ressaltar que cada item no Backlog do produto deve ter um valor de negcio associado - Business Value, no qual podemos medir o retorno do projeto e priorizar a realizao dos itens (SCHWABER, 2004). O Impediment Backlog contm todos os itens que impedem o progresso do projeto e geralmente esto associados a riscos. Estes itens no possuem uma priorizao, mas esto geralmente associados a algum item de Backlog do produto ou s tarefas do item, exemplos: "instalar ambiente para os desenvolvedores", "Instalao de banco de dados do projeto" e etc. O controle desses itens muito importante e o SCRUM Master o grande responsvel pela liberao desses impedimentos, abrindo caminho para o time de desenvolvimento executar a realizao dos itens do Backlog do produto (SCHWABER, 2004). Existem muitas formas para gerenciar o Product Backlog e o Impediment Backlog, todas elas precisam que cada item seja identificado e estimado, em tempo ou tamanho, e que a sua ordem de importncia seja estabelecida pelo cliente. Com esses atributos, possvel ter os itens em uma ordem de priorizao (SCHWABER, 2004). O ciclo do SCRUM tem o seu progresso baseado em uma srie de iteraes bem definidas, chamada Sprints, cada uma com durao de duas a quatro semanas, chamada de Time-box. Antes de cada Sprint, realiza-se uma Reunio de

34

Planejamento - Sprint Planning Meeting em que o time de desenvolvedores tem contato com o cliente - Product Owner para priorizar o trabalho que precisa ser feito, selecionar e estimar as tarefas que o time pode realizar dentro da Sprint. A prxima fase a Execuo da Sprint (ARAJO, 2009). O Sprint engloba todas as fases convencionais do desenvolvimento de software, determinando em perodos com durao de uma a quatro semanas de estimativas de procedimentos para aplicao de requisitos (ZANATTA E VILAIN, 2009). Durante a execuo da Sprint, o time controla o andamento do desenvolvimento realizando Reunies Dirias Rpidas - Daily Meeting, no mais que 15 minutos de durao, e observando o seu progresso usando um grfico chamado Sprint Burndown. Ao final de cada Sprint, feita uma reviso no produto entregue para verificar se tudo realmente foi implementado (PEREIRA et al., 2012). Ao final de cada Sprint, acontece a reunio de reviso. Nela, o time entrega o produto testado e revisado realizando uma demonstrao prtica. Este o momento do Product Owner inspecionar o produto final e verificar se o mesmo est como foi pensando. Aps esta reunio, a reunio de retrospectiva realizada, podendo ser chamada tambm de "lies aprendidas". Nesta, o time levanta tudo de bom e ruim que ocorreu e procura estabelecer pontos de melhoria. Estas aes so levadas para a prxima Sprint melhorando o processo e/ou produto. O ciclo do SCRUM repetido at que todos os itens do Product Backlog tenham sido finalizados, atendidos e/ou o produto final tenha sido aceito pelo cliente (PEREIRA et al., 2007). Uma representao deste ciclo de desenvolvimento do SCRUM de forma simplificada pode ser vista na Figura 5.

Figura 5: Ciclo de desenvolvimento do SCRUM de forma simplificada Fonte: ARMONY, 2010, p.32

35

SCRUM torna-se ideal para projetos dinmicos e suscetveis a mudanas de requisitos, sejam eles novos ou apenas requisitos modificados. No entanto para aplic-Io, preciso entender antes os seus papis, responsabilidades, conceitos e artefatos das fases de seu ciclo (PEREIRA et al., 2012). Neste sentido, o Sprint estabelece o tempo que deve ser um dos elementos avaliados na elaborao do projeto devendo-se para isso construir um cronograma com base nas aes e seqncia das mesmas, a fim de que todas as etapas sejam complementadas e que principalmente os prazos pr-estabelecidos sejam efetivados em sua previso. , portanto, uma metodologia gil para gerenciamento de projetos.

2.3.3 Planejamento da Sprint

A atividade que precede o incio da Sprint chama-se Sprint Planning Meetinq reunio de planejamento da Sprint. Essa atividade muita importante e precisa de alguma preparao. Deve-se ter cuidado para que essa reunio no extrapole a durao planejada e seu objetivo (PEREIRA et al., 2012). lgico que a equipe precisa de tempo para poder estimar com segurana, mas ela deve ser sempre guiada pelo SCRUM Master para que seja produtiva e no disperse e perca o foco (PEREIRA et al., 2012). Segundo Arajo (2009), o planejamento da Sprint o Product Backlog deve estar pronto antes de cada reunio. Mas o que significa isso? Que todos os requisitos tm que estar perfeitamente definidos e que as estimativas iniciais devem estar corretas? Que todas as prioridades esto finalizadas? No, necessrio garantir tambm: Que o Product Backlog exista e cada item esteja estimado; Deve existir apenas um Product Backlog e um Product Owner; Todos os itens devem ter uma nota em funo de sua importncia; Essa nota serve apenas para organizar os itens por importncia; O Product Owner deve entender todos os itens do Product Backlog, normalmente ele o autor do mesmo, mas em alguns casos outras pessoas podem ter colocado itens no Backlog;

36

Ele no precisa saber como cada item dever ser feito, mas precisa saber o motivo do item estar l; Apenas o Product Owner tem o poder de associar a nota de importncia de cada item do Product Backlog.

De acordo com Schwaber (2004), estando preparados os itens acima, podese iniciar a reunio de planejamento. O objetivo da reunio priorizar os itens que sero executados na Sprint, alm de dar ao time informao suficiente para que o mesmo possa validar e estimar o esforo em horas para cada item. Vale lembrar que esta reunio muito crtica para o sucesso do projeto e que uma reunio mal planejada pode afetar em muito o andamento da Sprint e causar danos grandes ao prazo do projeto. Com o Product Backlog priorizado, o time seleciona os itens que acha possvel de executar durante a Sprint. As dvidas do time so esclarecidas e ao final temos ento o Sprint Backlog, que so os itens do Backlog priorizados para a Sprint. Para cada item, o time inicia o detalhamento de suas atividades, estimando em horas, a durao de cada uma delas. No mandatrio, mas sugerido que cada tarefa no ultrapasse a durao de 16h. Se for necessrio, deve-se quebrar a tarefa at que individualmente todas as tarefas estejam dentro do limite de 16h. Uma vez que todas as tarefas foram estimadas, o time questiona se realmente consegue assumir o compromisso de realizar tarefas dentro da Sprint e finalizar o item selecionado (SCHWABER, 2004). Uma tcnica muito interessante e objetiva conhecida como Planning Poker pode ser usada para realizar a estimativa de horas/tamanho da atividade. De acordo com Pereira et al. (2012), Planning Poker uma forma de estimativa em conjunto, podendo ser feita como um jogo. Todos os membros do time, inclusive o Product Owner, participam de forma democrtica para chegar a um consenso de estimativa, para cada item do Backlog, de forma objetiva e divertida. O primeiro passo do jogo fornecer para cada membro da equipe um conjunto de cartas com uma sequncia numrica. A sequncia de Fibonacci (1,2,3,5,8,13,21, etc.) usada. Quanto maior o nmero da carta maior a dificuldade. O jogo iniciado selecionando o item de Backlog que o Product Owner e o time acreditam que seja o mais fcil de implementar, e a ele associado o menor nmero da sequncia. Depois o prximo item selecionado, e comparado o seu

37

grau de dificuldade com os dos itens j estimados. Neste momento, cada participante da reunio seleciona uma carta, onde se acredita ter o grau de dificuldade associado ao item e o participante espera que todos os outros participantes terminem as suas selees. Quando todos selecionaram as suas cartas, as mesmas so exibidas. E assim, havendo um consenso geral nas selees feitas, o nmero da carta que corresponde ao tamanho associado ao item. Segundo Pereira et al. (2012), em caso de divergncia, necessrio que os participantes expliquem os motivos de sua escolha, para que todos possam refletir e validar a sua escolha. Finalizada a discusso realiza-se uma nova rodada para que todos tenham a oportunidade de reavaliar seus julgamentos. Esse processo segue at que seja encontrado um consenso. importante que exista um moderador para que as discusses sejam produtivas e no polemizadas. Esse ciclo seguido at que todos os itens do Backlog sejam estimados. Uma vez decidido o item, o time passa para o prximo e esse processo continua at que todos os itens do Sprint Backlog sejam validados. Nesse momento, no so alocados os recursos para as tarefas; apenas se estabelece as estimativas em horas para cada uma. Aps a estimativa refinada, pode-se calcular o total de horas necessrio para realizar todas as tarefas. importante deixar sempre uma folga, j que mesmo detalhando a estimativa sempre podem aparecer surpresas (PEREIRA et al., 2012). Ainda segundo PEREIRA et al. (2012) uma vez ajustados os valores e com o time se comprometendo com a execuo das tarefas, existe um ambiente completo para a produo do resultado final da Sprint. O prximo passo iniciar a execuo da Sprint. importante lembrar que a Sprint possui um limite de horas disponvel. Este limite conhecido por LHS (Limite de Horas da Sprint) que pode ser medido utilizando uma frmula simples:

LHS= (R x H) x D Onde: R = Total de recursos do time H = Total de horas disponveis para cada recurso D = Total de dias teis da Sprint

38

Note que se tiver o H variando para alguns recursos, importante considerar isso na frmula. A relao de 1 homem/dia efetivo = 6 homens/hora efetiva mais real dependendo do tipo do projeto. Isso significa que se devem considerar apenas seis horas efetivas de cada recurso das oito normalmente trabalhadas, apenas 75% do tempo real do recurso considerado produtivo para a Sprint. Esta sobra importante, pois fornece uma idia mais realista da produtividade de cada recurso e tambm garante uma margem de segurana para eventuais imprevistos. Com a simulao a seguir, pode se entender melhor como calcular o LHS (PEREIRA et al., 2012). Para uma Sprint com time-box padronizado em 5 dias e um time possui 5 recursos em que 3 so de 8h, um de 6h e outro de 8h, mas apenas alocado por 50% de seu tempo, temos o LHS dirio considerando a relao acima sugerida de (PEREIRA et al., 2012):

8hx75% = 6h (3) 6hx75% = 4,5h (1) 8hx50% = 4h x 75% = 3h (1) Dias teis da Sprint = 5 logo, ((3x6) + (4,5) + (3)) = 31,50 (dia) LHS= 5 x 31,50 = 157,50 h

Segundo Arajo (2009), esses so clculos bem simples e voc vai precisar us-los apenas antes de cada planejamento da Sprint, pois o LHS que vai indicar se voc est alocando as horas corretas para a equipe. Ainda, segundo Arajo (2009), importante salientar que uma vez estabelecido a durao da Sprint no deve alterar sua data final, pois todo o projeto guiado por essa durao. Logo, adiantar ou atrasar no interessante para ningum. Outro motivo importante para se manter o padro de durao da Sprint a relao de produtividade do time dentro da Sprint. A mtrica de esforo (velocity) para o grupo de itens que foram priorizados na Sprint que vai dizer se conseguimos medir para um mesmo time-box o total de itens que foram finalizados

39

por Sprint, e isso comparado a um histrico. Esta mtrica muito importante, e apenas ser real se as Sprints forem de tamanhos iguais.

2.3.4 Papis e Responsabilidades

De acordo com o Pereira et al. (2012) e o Estudo de Isotton Neto (2008), o Scrum implementa um esqueleto interativo e incremental atravs de trs papis principais: o Product Owner, o Scrum Master e o Scrum Team como descrito abaixo: Product Owner: o dono do produto ele representa o cliente o principal responsvel pelo retorno financeiro (ROI) do produto responsvel tambm por garantir que a equipe SCRUM agregue valor ao negcio. Portanto, desempenha o papel de moderador entre os interesses do cliente e do TEAM, tendo como responsabilidade principal manter a equipe funcional e produtiva. De forma resumida, o Product Owner responsvel por: Representa o cliente e os interesses do mesmo; Definir os requisitos do produto; Defini a data de release e o que deve conter nela; Prioriza os requisitos de acordo com o seu valor de mercado e pode mudar os requisitos e prioridades a cada Sprint; Aceita ou rejeita o resultado de cada Sprint; Elabora e mantm o Product Backlog.

SCRUM Master: o gerente de projeto gil, representante do cliente no projeto, desempenha um papel de facilitador, responsvel pela remoo de impedimentos (problemas tcnicos, administrao de conflitos, itens no planejados etc.) que eventualmente surjam durante o decorrer do projeto. Preocupa-se com o uso correto do processo SCRUM e a aplicao das suas regras. De forma resumida, o SCRUM Mster responsvel por: Garantir a aplicao dos valores e prticas do SCRUM, bem como ensinar o SCRUM aos membros do projeto; Garantir que o time esteja totalmente funcional e produtivo; Eliminar os impedimentos do time; Atuar como escudo para interferncias externas;

40

Garantir que o processo esteja sendo seguido, conduzindo e participando das reunies dirias, reviso da Sprint, e planejamento.

SCRUM Team: So os responsveis pelo desenvolvimento do projeto, sendo composto geralmente por um grupo de cinco a nove integrantes multifuncionais. So responsveis por organizar e gerenciar suas prprias atividades e normalmente so dedicados integralmente ao projeto. Resumindo, a equipe SCRUM responsvel por: Fazer as estimativas necessrias; Seleciona, entre os itens priorizados, os que iro ser executados durante a Sprint; Tem todo o direito de realizar o que quiser dentro da Sprint para cumprir o objetivo da iterao; Garantir a qualidade do produto; Ao final da Sprint, apresentar o produto finalizado ao cliente.

2.3.5 Principais Artefatos

Alm dos artefatos comuns s metodologias tradicionais, o SCRUM apresenta alguns novos. De acordo com o Estudo de Isotton Neto (2008), so eles:

2.3.5.1 Product Backlog

Segundo Armony (2010), o product backlog uma lista incompleta e dinmica dos requisitos do produto ordenada pela prioridade que eles tm em serem colocados em desenvolvimento. Assim, os itens do alto da lista, que sero implementados primeiro, devem ser de menor granularidade e devem possuir mais detalhes, como uma melhor descrio e podem possuir algum tipo de estimativa de esforo de desenvolvimento. Essa prioridade dada, para um determinado momento, pelo valor que ir gerar para o cliente ou pelo risco que a sua no implementao representa. O product backlog nunca est completo, pois deve evoluir medida que o produto e seu ambiente evoluem. Essa lista pode conter funcionalidades, correes de problemas, tecnologias e melhorias que constituem a mudana que dever ser implementada no produto. Conforme descrito

41

anteriormente, o Product Owner o responsvel por atualizar, priorizar e dar visibilidade ao product backlog.

2.3.5.2 Sprint Backlog

O sprint backlog composto por uma lista dos itens que sero desenvolvidos durante a sprint, suas tarefas correspondentes, o andamento do desenvolvimento dessas tarefas e suas estimativas de tempo de desenvolvimento, (se a equipe optar por utilizar estimativas). Seus itens so selecionados do product backlog na reunio de planejamento da sprint, onde cada um dos itens selecionados quebrado em tarefas. O sprint backlog modificado ao longo da sprint, de forma que suas estimativas, quando utilizadas, so atualizadas e tarefas podem surgir para os itens j existentes. A equipe de desenvolvimento responsvel pelo sprint backlog e deve garantir que ele tenha alta visibilidade e que se mantenha atualizado. Uma representao comum do sprint backlog um quadro afixado na parede da sala de trabalho dividido em colunas, contendo cartes ou papis adesivos que indicam, dependendo de sua coluna, cada item que faz parte da sprint e as cada uma das tarefas correspondente a cada um dos itens (alinhadas horizontalmente a eles), divididas geralmente em trs colunas que indicam o progresso do desenvolvimento da tarefa: a fazer, em desenvolvimento (ou em progresso) e pronto (ARMONY, 2010).

2.3.5.3 Grfico de burndown do sprint

Segundo Armony (2010), o grfico de burndown do sprint (figura 6) utilizado para acompanhar o progresso do desenvolvimento em direo ao final de uma sprint. Esse grfico criado na reunio de planejamento da sprint e deve ser atualizado diariamente. Ele mostra a soma dos tempos estimados restantes (ou outra unidade de medida de trabalho restante em uso) das tarefas que fazem parte do sprint backlog pelo tempo, representado pelos dias de desenvolvimento da sprint. A Figura 6 mostra duas linhas longas com ponto que representam o passar dos dias, a linha em vermelho representa o ideal de acordo com as estimativas feitas inicialmente. A linha azul o real, tempo em que foi realizado o desenvolvimento, se

42

observamos a figura fica ntido um desenvolvimento muito mais rpido do que o esperado, ao final sobraram 200 horas.

Figura 6: Grfico de burndown chart Fonte: ISOTTON NETO, 2008, p. 22

De acordo com Isotton Neto (2008), o principal grfico de controle do SCRUM. Representa o trabalho total restante dentro de um sprint, de um release ou produto.

2.3.5.4 Taskboard

O taskboard (figura 7) um grande painel onde podem ser colocadas vrias informaes importantes para o acompanhamento do sprint. O sprint backlog, as atividades concludas, e o andamento das atividades ficam sempre visveis e disponveis para todos os interessados no projeto. O TEAM responsvel por manter o taskboard atualizado, que por meio deste, aliadas ao posicionamento das descries das atividades, geralmente em post-its, torna-se possvel a qualquer um observar o andamento do projeto, de maneira clara e intuitiva (ISOTTON NETO, 2008).

43

Figura 7: Taskboard Fonte: PEREIRA et al., 2012, p.08

A Figura 7 mostra um taskboard com 5 fases: Item de Backlog: a atividade macro que ser desmembrada em atividades menores, para que possa ser dividida entre a equipe; Para Fazer: So todas as atividades desmembradas em atividades menores que tem para fazer e no foi iniciada; Em Andamento: So as atividades desmembradas em atividades menores que j fora iniciadas por algum integrante da equipe; Para Verificar: So as atividades que esto em teste; Concludo: So as atividades que foram desenvolvidas e testadas e que no apresentaram erros.

2.3.6 Fases do SCRUM

Segundo Schwaber (1996), o SCRUM possui os seguintes grupos de fases:

44

Pr-Game: Planning: Definio da nova entrega baseada na lista de atividades conhecidas (backlog), juntamente com uma estimativa de tempo e custo. Se um novo sistema est sendo desenvolvido, esta fase consiste em concepo e anlise do produto. Se um sistema existente est sendo aprimorado, esta fase consiste basicamente em anlise. Architecture/High Level Design: Desenho de como os itens do backlog sero implementados. Esta fase inclui modificaes na arquitetura do sistema e atividades de design de alto nvel.

Game: Development (sprints): Fase de desenvolvimento das funcionalidades da nova entrega, com constante respeito s variveis de tempo, requisitos, qualidade, custo e competio. A inter-relao entre essas variveis define o final dessa fase. Normalmente existem mltiplos sprints, ou iteraes, que so usados para evoluir incrementalmente o sistema.

Ps-Game: Closure: Preparao para a entrega, incluindo documentao do produto e testes.

A Figura 8 apresenta uma viso das fases da metodologia gil SCRUM, iniciada no Pr-Game (Planejamento e arquitetura), depois seguida do Game que um ciclo de desenvolvimento, at que seja entregue um produto ao cliente no PsGame.

45

Figura 8: Fases do Scrum Fonte: SCHWABER, 1996, p. 12

A figura acima (figura 8) mostra as fases principais do SCRUM seguidas por suas atividades a serem realizadas dentro de cada fase, que ser apresentado uma descrio dessas atividades no prximo tpico, segundo o autor Schwaber (1996).

2.3.7 Detalhamento das fases

A seguir apresenta-se uma descrio das atividades a serem realizadas em cada fase do SCRUM segundo Schwaber (1996): Planning: (Planejamento) Desenvolvimento claro e objetivo de uma lista de atividades do produto; Definio da data de release e funcionalidades de um ou mais sprints; Definio do release mais apropriada para comear o ciclo de desenvolvimento;

46

Mapeamento e estimativa das atividades a serem includas na lista de atividades do produto; Definio do time do projeto; Avaliao e controle de riscos; Avaliao das ferramentas de desenvolvimento e infra-estrutura do projeto; Estimativa de custos incluindo desenvolvimento, documentao, marketing, treinamento e implantao.

Architecture/High Level Design: (Arquitetura / Design de Alto Nvel) Reviso e possveis ajustes a lista de atividades do produto; Identificao das mudanas necessrias para implementar as

atividades do backlog; Realizar a anlise de domnio; Refinar a arquitetura do sistema para suportar o novo contexto e exigncias; Identificao de possveis problemas ou impedimentos na

implementao dos requisitos; Reunio de reviso do design, onde so apresentados cada proposta de implementao de cada item do backlog.

Development (Sprint): (Desenvolvimento) A fase de desenvolvimento um ciclo repetitivo e iterativo. A gesto determina o tempo e as funcionalidade que sero desenvolvidas. Esta fase composta pelos seguintes macro processos: Reunies dirias (daily SCRUM) com os membros da equipe para revisar o andamento do projeto; Reviso e ajustes nos requisitos do projeto; Sprints iterativos at que o produto seja considerado pronto para a entrega. Um sprint um conjunto de atividades de desenvolvimento realizadas durante um perodo pr-definido, normalmente de uma a quatro semanas. O intervalo baseado na complexidade do produto, avaliao de risco e grau de superviso

47

desejado. A velocidade e a intensidade do sprint fator determinante para a sua durao. Riscos so avaliados de forma contnua. Cada sprint consiste em uma ou mais equipes executando o seguinte: Develop: Definio das mudanas necessrias para a implementao dos requisitos do backlog, implementao dos requisitos, anlise de domnio, concepo, atividades de implementao/desenvolvimento, atividades de teste e documentao das mudanas realizadas. Wrap: Empacotamento da verso e gerao de um executvel. Review: Todos os membros da equipe se renem para apresentar os resultados do sprint e analisar o progresso. Se necessrio, novos itens so includos na lista de atividades do produto e os riscos so revisados. Adjust: Consolidao das informaes da reunio de reviso e ajustes ao processo. Cada sprint seguido por uma reunio de retrospectiva, cujas caractersticas so: Todos os membros da equipe e os envolvidos participam; Pode participar clientes, setores de vendas e marketing e outros; avaliado o que pode ser modificado para melhorar a produtividade do prximo sprint; Uma demonstrao aos stakeholders com os resultados do sprint organizada; Novos itens podem ser introduzidos no backlog e distribudos em equipes como parte da reviso. Pode alterar o contedo e o sentido das entregas

Closure: (Encerramento/Fechamento) Esta fase prepara o produto desenvolvido para o entrega final. Integrao, teste de sistemas, documentao do usurio, material de treinamento e material de marketing so atividades tpicas dessa fase.

48

IMPACTO

DA

METODOLOGIA

GIL

SCRUM

NA

AGILIDADE

PRODUTIVIDADE EM UMA EQUIPE DE DESENVOLVIMENTO DE SOFTWARE

3.1 Aspectos Metodolgicos Optou-se neste estudo sobre a apresentao de um Estudo de Caso que possa demonstrar o impacto da mudana com equipes de projeto com o uso de metodologia gil, tendo como foco a nova abordagem para desenvolvimento de software atravs do uso da metodologia Scrum. A pesquisa para o detalhamento do estudo de caso foi realizada em uma Fbrica de software, existente no mercado a mais de 25 anos, certificada CMMI (Capability Maturity Model Integration) pelo SEI (Software Engineering Institute). O Estudo de caso em questo foi caracterizado como uma pesquisa descritiva e uma pesquisa de campo, pois foi realizado atravs da anlise presencial em uma Fbrica de Software, em especfico, uma equipe de desenvolvimento de software que adotou a metodologia gil Scrum como metodologia de desenvolvimento de softwares e manteve como base bibliogrfica pressupostos tericos de autores que expuseram fundamentos para o enriquecimento do trabalho. Quanto natureza da pesquisa deste estudo, do ponto de vista da abordagem do problema pode ser classificada como pesquisa-ao. Segundo Franco (2005) a pesquisa-ao um tipo de pesquisa no qual os pesquisadores fazem parte efetivamente do trabalho estudado, contribuindo com idias realizando aes na tomada de deciso e revelando acontecimentos que determinam e envolvem diversos momentos da realidade estudada.

3.2 Estudo de Caso Fbrica de Software

3.2.1 Projeto A empresa A uma fbrica de desenvolvimento de software e trabalha com o gerenciamento de projetos clssicos. Aps uma pesquisa da rea de qualidade sobre metodologias geis, a empresa decidiu aplicar a metodologia gil Scrum em seus projetos. O primeiro projeto a se basear nessa metodologia foi um projeto cuja

49

finalidade principal gerenciar o processo de registro de possveis clientes, bem como seu acompanhamento dentro do fluxo de trabalho dos agentes de negcios da Empresa contratante, Construtora a nvel nacional, at que esse possvel cliente se torne um cliente com contrato fechado. O sistema ser denominado neste estudo como MORPHEU. A equipe designada para este projeto composta de um Product Owner (Cliente), um Gerente de projetos (Scrum Master), um Analista de negcio, um Analista de Teste, um Arquiteto de Software (meio perodo) e dois Analistas desenvolvedores (perodo integral). As estimativa foram feitas utilizando nvel de complexidade, utilizou-se a escala de Fibonacci (1,2,3,5,8 e ?(caso no tenha idia formada)) e a quantidade de horas para realizao da atividade de 1 a 8 e ?(caso no tenha idia formada). O projeto encontra-se no seu nono Sprint.

3.2.2 Planejamento

Antes de iniciar o planejamento do projeto, o SCRUM Master juntamente com o Analista de negcio e o Diretor Administrativo/Executivo reuniu com os Product Owners (Clientes) do respectivo projeto para realizar um estudo sobre a viabilidade do projeto baseado na viso apresentada. Ao validar a viabilidade de desenvolvimento do projeto, o SCRUM Master e o Analista de negcio juntamente com o Product Owner do projeto construram o Product Backlog. Em seguida o Product Owners definiu os requisitos a serem incorporados no Product Backlog. Alm de definidos, os requisitos foram priorizados com base no valor de negcio que eles representam. Aps esta definio de prioridades eles estabeleceram que o Sprint teria durao de 10 dias teis, totalizando 160 horas de desenvolvimento, retirando o primeiro dia que seria correspondente ao Sprint Planning e o ltimo do Sprint review e retrospectiva. O clculo realizado para a definio de 160 horas foi: N de dias de desenvolvimento = 8 N de horas dos participantes/recursos = (2 desenvolvedores integral e 1 arquiteto meio perodo) Clculo: 8 (dias) x 20 (horas) = 160(horas).

50

3.2.3 Planejamento do Sprint (Sprint Planning)

Aps o levantamento e estudo do Product Backlog, no segundo momento todos os integrantes se renem para que seja feito o Sprint Planning, que aborda questes e definies do projeto e atividades a serem desenvolvidas, tambm foi feito neste momento a estimativa de esforo e tempo de cada item do Product Backlog que ir fazer parte do Sprint que comea. Neste momento o Time utilizou a tcnica Planning Poker. Durante o Sprint Planning o Time quebra os itens do Product Backlog de acordo com a prioridade que o Product Owner definiu em tarefas menores, criando assim o Sprint Backlog. O Sprint Backlog contm todas as tarefas a serem feitas para que os itens definidos para o Sprint sejam implementados, e no final algum produto potencialmente implantvel seja entregue.

3.2.4 Reunies Dirias(Daily Scrum)

A fim de verificar o andamento dos projetos, o SCRUM Master realizou reunies dirias com um tempo de durao mximo de 15 minutos. Estas reunies eram realizadas com todos os membros do Time, e estes respondiam a trs perguntas: 1. O que se fez desde a ltima reunio diria? 2. O que se pretende fazer ate amanh? 3. Tm alguma coisa impedindo o trabalho? Com as informaes extradas destas perguntas e ao traar o Burndown Chart do projeto, o SCRUM Master tinha o poder de visualizar o andamento do projeto, e de dizer se o projeto estava atrasado, adiantado, ou se estava ocorrendo conforme o planejado. Alm disso, as respostas da terceira pergunta permitiram que o SCRUM Master juntamente com o Product Owner pudesse sanar os problemas levantados o quanto antes, pois so os principais responsveis por resolver os impedimentos do projeto. As reunies dirias do projeto MORPHEU referente ao oitavo Sprint podem ser vistas no Anexo I juntamente com seu respectivo Sprint Backlog e.Burndown Chart.

51

3.2.5 Sprint Review

No final de todo Sprint, o SCRUM Master juntamente com o Time define um integrante que ir apresentar o que foi realizado no Sprint, nesta apresentao esto presentes todos os integrantes da equipe, inclusive o Product Owner e demais stakeholders, pois a apresentao do produto produzido durante todo o Sprint voltada principalmente a eles. Durante a apresentao do Sprint Review algumas adaptaes e ajustes so dados como sugesto de melhoras pelos Product Owner e demais stakeholders. Estes ajustes so incorporados no prximo Sprint como reviso de cdigo.

3.2.6 Sprint Retrospective

No final de todo Sprint, o SCRUM Master juntamente com todos os integrantes da equipe, inclusive o Product Owner caso queira participar se renem e todos respondem a duas perguntas: 1. O que foi bom durante o Sprint? 2. O que pode ser melhorado? Com estas informaes o SCRUM Master avaliava os pontos que poderiam ser melhorados e tenta fornecer recursos necessrios para que as mudanas possam acontecer. Durante o primeiro Sprint Retrospective deste projeto, foi perguntado ao Time o que foi bom durante o Sprint, e o Time respondeu que o planejamento das atividades foi essencial para o trmino das tarefas do primeiro Sprint e que entendimento da equipe estava ficando cada vez mais alinhado. Foi perguntado tambm o que poderia ser melhorado para os prximos Sprints e o Time respondeu que seria melhor quebrar mais os itens do Product Backlog em tarefas menores no Sprint Backlog e detalh-los ainda mais, pois assim no aconteceria sobrecarga de atividades e atividades mal estimadas, tambm foi pedida a presena do Product Owner mais no projeto nesta fase inicial, pois as regras de negcio eram complexas e por ltimo foi orientado pelo Product Owner uma estratgia caso o servidor de banco de dados e o CRM ficasse fora por algum tempo.

52

No segundo Sprint Retrospective foram feitas as mesmas perguntas do primeiro e o Time respondeu que a quebra dos itens do Product Backlog em tarefas menores, compondo assim o Sprint Backlog, foi essencial para o sucesso deste Sprint, pois aumentou a viso do sistema a ser desenvolvido como um todo, tambm foi citado como fundamental para o Sprint a presena do Product Owner para o esclarecimento de dvidas nas regras de negcio. Na segunda pergunta o Time o respondeu que as atividades ainda sim foram mal estimadas pelo Time e que fora isto a princpio estava tudo dentro do planejado e no havia pontos a serem melhorados. No terceiro Sprint Retrospective foram feitas as mesmas perguntas do segundo e o Time respondeu que a estimativa agora foi correta o que fez com que no houvesse sobrecarga de atividades e que tambm no ficasse nenhuma atividade sem ser desenvolvida. Na segunda pergunta o Time respondeu que fora isto a princpio estava tudo dentro do planejado e no havia pontos a serem melhorados, mas novamente foi orientado pelo Product Owner criar uma estratgia caso o servidor de banco de dados ficasse fora por algum tempo. No quarto, quinto e sexto Sprint Retrospective o Time apenas elogiou a alinhamento da equipe com as regras de negcio e que no havia nada a ser melhorado. No stimo Sprint Retrospective foi informado pelo analista de teste uma dificuldade grande de fazer teste regressivo, devido o projeto est crescendo e sempre est incorporando regras novas, ento a partir deste Sprint est sendo estudada a incluso do teste automatizado, do TDD, como uma forma de evitar este teste regressivo. No oitavo Sprint Retrospective foi informado novamente pelo analista de teste uma dificuldade grande de fazer teste regressivo, o arquiteto do projeto estuda uma forma mais vivel de implantar o teste automatizado, juntamente com o processo de Integrao Contnua com o TFS(Team Foundation Server).

3.2.7 Burndown Chart dos Sprints

Durante o andamento do projeto foi traado o Burndown Chart de cada Sprint. Com ele pode-se perceber se o projeto est sendo desenvolvido conforme o

53

planejamento se est atrasado ou at mesmo adiantado. Abaixo esto as imagens do Burndown Chart de cada Sprint e as tarefas principais desenvolvidas no mesmo, as Figuras contemplam uma breve descrio dos itens previstos, no previstos, observaes e o burndown chart do Sprint. A Figura 9 representa o Burndown Chart do Sprint 1, mostra-se uma breve descrio dos itens previstos que foram entregues, no h itens no previsto e nem observaes. O Burndown Chart do Sprint 1 mostra um desenvolvimento equilibrado sem muitas oscilaes, todas as atividades do sprint foram entregues.

Figura 09: Burndown Chart do Sprint 1 Fonte: SAVIOTTE, 2012

A Figura 10 representa o Burndown Chart do Sprint 2, mostra-se uma breve descrio dos itens previstos que foram entregues, h itens no previsto que foram desenvolvidos e entregues tambm e no se tem observaes. O Burndown Chart do Sprint 2 mostra um desenvolvimento um pouco mais rpido que o anterior tambm foi equilibrado sem muitas oscilaes, todas as atividades do sprint foram entregues.

54

Figura 10: Burndown Chart do Sprint 2 Fonte: SAVIOTTE, 2012

A Figura 11 representa o Burndown Chart do Sprint 3, mostra-se uma breve descrio dos itens previstos que foram entregues, h itens no previsto que foram desenvolvidos e entregues tambm e no se tem observaes. O Burndown Chart do Sprint 3 mostra um desenvolvimento ainda mais rpido que os anterior, todas as atividades do sprint foram entregues.

55

Figura 11: Burndown Chart do Sprint 3 Fonte: SAVIOTTE, 2012

A Figura 12 representa o Burndown Chart do Sprint 4, mostra-se uma breve descrio dos itens previstos que foram entregues, h itens no previsto que foram desenvolvidos e entregues tambm e no se tem observaes. O Burndown Chart do Sprint 4 mostra um desenvolvimento equilibrado sem muitas oscilaes, todas as atividades do sprint foram entregues.

56

Figura 12: Burndown Chart do Sprint 4 Fonte: SAVIOTTE, 2012

A Figura 13 representa o Burndown Chart do Sprint 5, mostra-se uma breve descrio dos itens previstos que foram entregues, no h itens no previsto, neste sprint ouve a ausncia de um dos desenvolvedores ento ouve o remanejamento das atividades para o prximo sprint. O Burndown Chart do Sprint 5 mostra um desenvolvimento de 3 dias sendo apenas um desenvolvedor.

57

Figura 13: Burndown Chart do Sprint 5 Fonte: SAVIOTTE, 2012

A Figura 14 representa o Burndown Chart do Sprint 6, mostra-se uma breve descrio dos itens previstos que foram entregues, h itens no previsto que foram desenvolvidos e entregues tambm e no se tem observaes. O Burndown Chart do Sprint 6 mostra um desenvolvimento equilibrado sem muitas oscilaes, todas as atividades do sprint foram entregues.

58

Figura 14: Burndown Chart do Sprint 6 Fonte: Saviotte, 2012

A Figura 15 representa o Burndown Chart do Sprint 7, mostra-se uma breve descrio dos itens previstos que foram entregues, no h itens no previsto a uma observao informando para Agendar apresentao, isto se deve devido a este sprint e os outros dois passados no terem sido apresentado, devido as atividade no comporem um pacote desejvel de entrega ao Product Owner. O Burndown Chart do Sprint 7 mostra um desenvolvimento equilibrado sem muitas oscilaes, todas as atividades do sprint foram entregues.

59

Figura 15: Burndown Chart do Sprint 7 Fonte: SAVIOTTE, 2012

A Figura 16 representa o Burndown Chart do Sprint 8, mostra-se uma breve descrio dos itens previstos que foram entregues, no h itens no previsto e no se tem observaes. O Burndown Chart do Sprint 8 mostra um desenvolvimento equilibrado at a metade do sprint depois ouve uma atividade mais complexa que demandou mas tempo , devido a isto ouve uma oscilao considervel, mas ao final do sprint todas as atividades foram entregues.

60

Figura 16: Burndown Chart do Sprint 8 Fonte: SAVIOTTE, 2012

Com base nas figuras apresentada, pode-se reparar uma produtividade muito alta, visto que, praticamente todos os sprint foram entregues por completo, apenas um ouve a ausncia de um desenvolvedor e ouve a necessidade de remanejamento das atividades para o prximo, atrasando assim o projeto em uma semana apenas.

3.3 Histria da Empresa A Empresa onde foi realizada o estudo de caso uma empresa brasileira com matriz localizada em Belo Horizonte - MG e escritrios regionais no Rio de JaneiroRJ, Braslia-DF, Campinas-SP e Lavras-MG. Hoje emprega centenas de

colaboradores em todo o Brasil que atuam estrategicamente por vertical atravs de uma estrutura tcnica e comercial focada em: Governo, Telecom, Finanas, Indstria, Comrcio e Servios. 1987 Fundao da empresa. Empresa nacional altamente especializada no desenvolvimento de produtos e servios em software. 1988 Criao de aplicaes completas em Cobol.

61

1991 - Criao de aplicaes completas em Delphi, com acesso aos bancos de dados Paradox, Access e Interbase. 1994 - Criao de uma soluo contra pirataria destinada a proteger aplicativos nativos desenvolvidos em linguagens compiladas compatveis com sistemas operacionais Windows 32 bits. 1995 Disponibilizao de servios de consultoria, desenvolvimento de sistemas e treinamento especializado. Parceria com a Borland amplia a expertise no gerenciamento do ciclo de vida da aplicao. 1996 Criao de um Sistema de Imposto de Renda - A Empresa ajuda a elaborar, junto a rgo governamental, o primeiro sistema de Imposto de renda para Windows. Neste ano foram disponibilizados os primeiros servios de consultoria e treinamento em Delphi. 1998 Oferecimento de outsourcing, alocando profissionais especializados para integrar as equipes de TI de seus principais clientes. 2000 A Empresa estrutura sua Fbrica de Software, trabalhando solues para desenvolvimento de projetos customizados, manuteno de sistemas, modernizao de sistemas legados e fbrica de testes. (Fabrica de Software). 2004 Nova parceria tcnica-comercial com a IBM nas linhas Rational e WebSphere. 2005 A Empresa consolida sua atuao na iniciativa privada, em Minas Gerais, atendendo a empresas consolidadas no setor de Telefonia. 2006 Presena da Empresa em uma Companhia de Tecnologia da Informao. 2007 A Empresa expande sua atuao em mbito nacional, em instituies governamentais, autarquias e empresas privadas em diversos estados do Brasil. 2008 Criao da nova sede da Empresa em Belo Horizonte-MG. Empresa certificada CMMI nvel 2, ttulo oficializado pelo SEI - Software Engineering Institute. criado ento um conjunto de normas e tcnicas prprio da Empresa com as metodologias de processos para o desenvolvimento de software. 2009 - Criao das unidades do Rio de Janeiro e Braslia. A Empresa alcana a certificao CMMI nvel 3, aps rgidos processos de avaliao.

62

2010 - Em parceria com a Faculdade Presbiteriana Gammon FAGAMMON inaugurada, na cidade de Lavras-MG, uma moderna Fbrica de Software e um Centro de Treinamento que oferta minicursos para aperfeioamento e qualificao. 2011 - Contrato com o BNDES (Banco Nacional de Desenvolvimento Econmico e Social) aportando recurso financeiro que coloca a Empresa em patamares mais elevados no mbito da governana corporativa e expanso nos mercados nacional e internacional. 2012 - Incio da execuo dos projetos financiados com recursos do BNDES e FINEP. Com a assinatura de novos contratos no estado de So Paulo, a Empresa expande suas aes em mais um escritrio estrategicamente localizado em Campinas.

3.4 Mudana Cultural

As mudanas culturais so complexas e compreendem um grande desafio organizacional na atualidade. A pesquisa na empresa demonstrou que Atualmente, as empresas sobrevivem em um ambiente competitivo e de constantes mudanas que determinam a necessidade de conhecimento dos desdobramentos em negcios e do controle de processos para o aumento da produtividade no ambiente organizacional. A cultura compreende nesta fase as noes de mudanas que devem compreender valores, comportamentos, gostos e hbitos relacionados s novas caractersticas do trabalho. Os recursos humanos so os alvos de planejamentos para alicerar processos educativos corporativos. Drucker (2003) considera que uma mudana ocorre a partir da transposio de um estado de existncia para outro que poder se d forma abrupta ou em processos transitrios podendo apresenta avanos e recuos. a passagem de uma situao anterior para uma nova. No campo das empresas pode ser de ordem diversa: novos objetivos organizacionais, novas polticas gerenciais, diferentes tecnologias, aquisio de novos equipamentos e sistemas, novos mtodos e processos de operao, novos produtos ou servios, etc. Os desafios se constituram na superao de modelos clssicos pouco iterativos, com muita documentao e processos burocrticos.

63

De incio a equipe permaneceu insegura em relao reduo de documentos e do excesso de padres, mas com a aplicao centrada mantendo os conceitos e prticas bsicos da metodologia gil Scrum, a equipe cada vez mais ficou confiante no processo e pode crescer juntamente com o projeto. Assim, constatou-se no estudo que houve poucas dificuldades em relao a aplicao da metodologia gil Scrum os desafios e os impactos foram completamente amenizados com a aplicao correta e principalmente com o comprometimento da equipe em relao ao projeto. Neste contexto, ao aderir a uma metodologia mais flexvel como a Scrum, as equipes conseguiram superar seus medos e se fortaleceram.

3.5 A Situao da Empresa Atual

Atualmente a fbrica de software aderiu metodologia gil Scrum em vrios projetos em face de sua contribuio ao planejamento estratgico, atravs do uso do Scrum Master, as equipe obtiveram maiores condies de realizar um planejamento adequado, eficiente e flexvel. Sob essa perspectiva, as equipes tm acesso a um padro de planejamento que envolve mudanas e processos dinmicos e contnuos. A escolha por uma metodologia gil voltada para a uma prtica dinmica em planejamentos de forma a ser aplicado em ambientes complexos. Atualmente a empresa est aplicando a metodologia gil Scrum em outros projetos e tem obtido desempenhos na produtividade na medida em que a metodologia gil produziu um impacto muito positivo sobre a produtividade das equipes. O desempenho satisfatrio atual das equipes est voltado aos

multiprofissionais, que preferem os desafios de trabalhar com mtodos geis que permitem uma maior dinmica e flexibilidade aos projetos, acostumados ao ritmo de mudanas, alm de oferecer diversas interfaces que facilitam as condutas pelo monitoramento de riscos nos resultados finais do produto. A anlise de desempenho na empresa ocorre em outros pontos estratgicos como indicadores de desempenho em qualidade e nos processos que tem o foco na satisfao dos clientes e dos stakeholders.

64

Neste sentido, a insero da metodologia gil Scrum na empresa produziu um efeito de ordenamento gerencial das equipes, um maior entendimento e comprometimento com o projeto, uma maior aproximao do cliente, maior satisfao de clientes, maior produtividade, alm de produzir uma intensa motivao na realizao de projetos.

65

4 CONSIDERAES FINAIS

O estudo permitiu evidenciar que a insero de metodologias geis resultado de uma evoluo na Engenharia de Software, a tecnologia trouxe mudanas e as organizaes precisaram se enquadrar sob o ponto de vista da competitividade para sobreviverem. O avano atual das metodologias geis vem responder a uma necessidade do aumento da produtividade e da qualidade em um processo que se adapta realidade organizacional complexa e a situaes de mudanas. O foco de qualidade voltado para o cliente projetou a necessidade da Engenharia de software avanar na participao do cliente atravs de meios para permitir mudanas exigidas. Atualmente as organizaes que geram grandes demandas de projetos procuram introduzir mtodos geis que favorecem uma previso geral do produto e estabelece etapas definidas para a execuo de requisitos. A escolha da metodologia gil Scrum se deve sua associao direta com a melhoria e qualidade das equipes nos processos e as diretrizes relacionadas ao planejamento estratgico. Considerou-se que essa metodologia totalmente adaptvel realidade de situaes complexas em processo de desenvolvimento de software. Os resultados do estudo permitiram avaliar que a equipe desfrutou de grande motivao e enfrentaram os desafios de insero de uma metodologia gil que implicam em processos mais dinmicos e flexveis, garantindo tambm uma alta produtividade e satisfao do cliente. Neste sentido, a insero da metodologia gil Scrum na empresa produziu um efeito de ordenamento gerencial das equipes, um maior entendimento e comprometimento com o projeto, uma maior aproximao do cliente, maior satisfao de clientes, maior produtividade, alm de produzir uma intensa motivao na realizao de projetos.

66

REFERNCIAS

ANTONIONI, J. A. Qualidade em software: manual de aplicao da ISO 9000. So Paulo: Makron, 1995.

ARAJO, Leonardo Bruno Pereira de. Estudo comparativo de compatibilidade entre as melhores prticas do PMI e SCRUM. Monografia. So Paulo: Faculdade de Informtica e Administrao Paulista, 2009. Disponvel em:

<http://www.gestaopm.com.br/documentos/PMI_SCRUM.pdf> Acesso em: 03 Fev, 2012.

ARMONY, Rafael Sabbagh. Fatores Crticos para a Prtica de Valores geis em Equipes de Tecnologia da Informao. Dissertao de Mestrado para obteno do ttulo de Mestre pelo programa de Ps-Graduao em Administrao de Empresas da PUC-RIO. 2010. Disponvel em: <http://rsabbagh.com/site/downloads/Dissertacao _RafaelSabbagh.pdf> Acesso em: 03 Jun, 2012.

BORGES, Lgia da Motta Silveira; FALBO, Ricardo de Almeida. Gerncia de Conhecimento sobre Processos de Software. Disponvel em:

<http://webcache.googleusercontent.com/search?q=cache:nyPaFtNfZYAJ:www.inf.uf es.br/~falbo/download/pub/BorgesWqs2001.pdf+processos+de+software&hl=ptBR&gl=br> Acesso em: 14 Ago, 2012.

CHAPIEWSKI, G. Como estamos indo com a adoo de SCRUM na Globo.com. 2009. Disponvel em: <http://gc.blog.br/2008/05/27/como-estamos-indo-com-a-

adocao-descrum-na-globocom/>. Acesso em: 02 Mar, 2012.

CIDRAL, Alexandre. Metodologia de aprendizagem de competncias para o gerenciamento de projetos de implementao de sistemas de informao. Tese de Doutorado. 243 fls. Universidade Federal de Santa Catarina. Florianpolis, 2003.

COCKBURN, A. Agile software development: the cooperative game. 2 ed. Reading, MA, Estados Unidos: Addison-Wesley, 2007.

67

CRTES, M. L. Modelos de Qualidade de Software. Campinas: UNICAMP, 2001.

CORDEIRO, Edson dos Santos. Introduo a processos de software. 2009. Disponvel em: <http://www.cordeiro.pro.br/aulas/engenharia/processoDeSoftware /Processo.pdf>. Acesso em: 20 Mar, 2012.

DRUCKER, Peter F. Inovao e Esprito Empreendedor: Prtica e princpios. 1 ed. So Paulo: Pioneira, 2003.

FALBO, Ricardo de A., Engenharia de Software: Notas de Aula. 2005. Disponvel em: <http://www.inf.ufes.br/~falbo/download/aulas/es-g/2005-2/NotasDeAula.pdf>.

Acesso em: 08 Out, 202012.

FRANCO, M. A. S. Pedagogia da pesquisa-ao. Educao e Pesquisa, So Paulo, 2005.

FUGGETTA, A. Software process: a roadmap, in Finkelstein. A. (ed.) The Future of Software Engineering, ACM Press, 2002.

FOWLER, Martin; HIGHSMITH, Jim. The Agile Manifesto. Dr. Dobbs Portal, ago., 2001. Disponvel em: <http://www.ddj.com/architect/184414755> Acesso em: 20 Nov, 2011.

GOULO, Miguel Carlos Pacheco Afonso. Engenharia de Software Baseado em Componentes: uma Abordagem Quantitativa. 2002. Disponvel em:

<http://ctp.di.fct.unl.pt/QUASAR/Resources/Papers/2003/IntencaoPhDmgoul.pdf> Acesso em: 05 Nov, 2011.

GUSMO, C. M. G. ; MOURA, H. P. . Gerncia de Risco em Processos de Qualidade de Software: uma Anlise Comparativa. Artigo. Universidade Federal de Pernambuco (UFPE). 2008. Disponvel em <http://pt.scribd.com/doc/97850674/ Gerencia-de-Risco-em-Processos-de-Qualidade-de-Software> Acesso em: 05 Ago, 2012.

68

ISOTTON NETO, Erasmo. Scrumming: Ferramenta Educacional para Ensino de Prticas do SCRUM. Trabalho de Concluso. Faculdade de Informtica. Porto Alegre: Rio Grande do Sul: Pontifcia Universidade Catlica do Rio Grande do Sul, 2008. Disponvel em: <http://www.inf.pucrs.br/~rafael/Scrumming/Scrumming.pdf> Acesso em: 05 Ago, 2012.

LEITE,

Jair

C.,

Processo

de

Software.

2007.

Disponvel

em:

<http://engenhariadesoftware.blogspot.com.br/2007_03_01_archive.html> em: 08 Out, 2012.

Acesso

MACORATTI, Jos Carlos. O processo de Software. Disponvel em: < http://www.macoratti.net/proc_sw1.htm> Acesso em: 01 Ago, 2012.

MANIFESTO GIL, 2001. Disponvel em: <http://www.manifestoagil.com.br/> Acesso em: 20 Jun. 2012.

MARQUIONI, Carlos Eduardo. Escopo de Projeto x Escopo de Produto: A Engenharia de Requisitos como subsdio para a Gesto de Software. Artigo apresentado no III Simpsio Internacional de Administrao e Marketing/V Congresso de Administrao da ESPM realizado na ESPM/SP. 2008. Disponvel em: <http://www.marquioni.com.br/manter_artigos/arquivos/ c906ff3022b7ffe52c4533fcc66a7b44.pdf> Acesso em: 05 Jun, 2012.

MARAL, Ana Sofia Cysneiros. Estendendo o SCRUM segundo as reas de processo de gerenciamento de projetos do CMMI. 2007. Disponvel em: <http://www.inf.ufes.br/~monalessa/PaginaMonalessaNEMO/ES_Mestrado/Artigos/ EstendendoScrumSegundoAreasDeGerenciaNoCMMI.pdf> Acesso em: 15 Jun, 2012.

MARTINS, J.C.C. Tcnicas para gerenciamento de projetos de software. So Paulo: Brasport, 2009.

69

NONAKA, Ikujiro; TAKEUCHI, Hirotaka. Criao de Conhecimento na empresa: Como as empresas japonesas geram a dinmica da inovao. Rio de Janeiro: Editora Campus, 1997.

OLIVEIRA FILHO, Jos Alceu de. Gesto de Projetos no setor pblico. Universidade Gama Filho. POSEAD Educao Distncia, Braslia, DF, 2007.

PEREIRA P.; TORREO, P.; MARAL, A. S. Entendendo SCRUM para gerenciar projetos de forma gil. Disponvel em: <http://www.siq.com.br/DOCS/ EntendendoScrumparaGerenciarProjetosdeFormaAgil.pdf>. Acesso em: 10 Jun 2012.

PETERS, JAMES F. Engenharia de Software: Teoria e Prtica. Rio de Janeiro, Editora Campus, 2001.

PMBOK, Guia. Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos - (3 edio). 2004. Disponvel em: <http://www.riosoft.softex.br/media/ PMBOK_2004_Portugues.pdf> Acesso em: 20 Jun, 2012.

POSSI, M. et al. Capacitao em gerenciamento de projetos. Rio de Janeiro: BRASPORT, 2004.

PRESSMAN, Roger S., Engenharia de Software. 5 ed. So Paulo: MacGraw-Hill, 2001.

PRESSMAN, Roger S., Engenharia de Software. 3 ed. So Paulo: Makron Books, 1995.

PRESSMAN, Roger S., Engenharia de Software. 6 ed. So Paulo: McGraw-Hill, 2006.

REIS, Christian Robolton. Caracterizao de um Processo de Software para Projetos de Software Livre. Dissertao de Mestrado (Cincias Matemticas e da Computao) Universidade de So Paulo USP, So Carlos, 2003.

70

KNOB, Flvio, SILVEIRA, Filipi, ORTH, Afonso Incio, PRIKLADNICKI, Rafael. RiskFree Uma Ferramenta de Gerenciamento de Riscos Baseada no PMBOK e Aderente ao CMMI. Artigo. Pontifcia Universidade Catlica do Rio Grande do Sul PUCRS. 2006. Disponvel em: < http://www.lbd.dcc.ufmg.br/colecoes/sbqs/2006/ 014.pdf> Acesso em: 20 Jun, 2012.

ROCHA, A. R. C.; MALDONADO, J. C.; WEBER, K. C. Qualidade de software: teoria e prtica. So Paulo: Prentice-Hall, 2001.

SANTOS, Marta; ROCHA, Vera. Processo de Software: Modelo em Espiral. Disponvel em: <http://www.cin.ufpe.br/~cadcn/files/Monitoria/Monitoria%20-

%20Gradua%E7%E3o/material%20de%20apoio/esperial.pdf> Acesso em: 23 Abr, 2012.

SATO, Danilo Toshiaki. Uso eficaz de mtricas em mtodos geis de desenvolvimento de software. Fls. 134. Dissertao de Mestrado em Cincias da Computao. Universidade de So Paulo. So Paulo, 2007.

SCHWABER, Ken. SCRUM Development Process. Burlington, MA, USA, 1996. Disponvel em: <http://www.jeffsutherland.org/oopsla/schwapub.pdf> Acesso em: 05 Jun, 2012.

SCHWABER, Ken. Agile project management with Scrum. Redmond, WA, Estados Unidos: Microsoft Press, 2004.

SCHUH, Peter. Integrating agile development in the real world. Hingham, MA, Estados Unidos: Charles River Media, 2005.

SILVA, talo Alves da. O impacto do fator humano no desenvolvimento de software: Um estudo exploratrio de ferramentas de Case. FUNDAO GETLIO VARGAS FGV Management. 2004. Disponvel em:

<www.apaebrasil.org.br/arquivo.phtml?a=10230> Acesso em: 21 Abr, 2012.

71

SOARES, Michel dos Santos. Metodologias geis Extreme Programming e Scrum para o Desenvolvimento de Software. Disponvel em:

<http://revistas.facecla.com.br/index.php/reinfo/article/viewFile/146/38> Acesso em: 19 Abr, 2012.

SOARES, Michel dos Santos. Comparao entre Metodologias geis e Tradicionais para o Desenvolvimento de Software. Disponvel em:

<http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf> Acesso em: 22 Abr, 2012.

TCU (Tribunal de Contas da Unio). Manual de Gesto de Projetos. 2006. Disponvel em: <http://portal2.tcu.gov.br/portal/pls/portal/docs/2058942.PDF>

Acesso em: 09 de Out, 2012.

VALIATI, Antnio Csar. Gerenciamento de projetos em indstrias de regime permanente: Uma proposta de organizao por equipes autnomas.

Dissertao de Mestrado. Fls. 164. Universidade Federal de Santa Catarina. Florianpolis, 2000.

ZANATTA, Alexandre L. ;VILAIN, Patrcia. Uma anlise do mtodo gil Scrum conforme abordagem nas reas de processo de Gerenciamento e

Desenvolvimento de Requisitos do CMMI. Passo Fundo RS. 2003. Disponvel em: <http://pt.scribd.com/doc/98846056/Alexandre-Zanatta> Acesso em: 20 Jun, 2012.

WIERMANN, Gustavo Garcia. Riscos em Projetos: aprenda a conviver com eles. Artigo. Belo Horizonte: IETEC, 2006.

72

Anexos
Anexo A - Oitavo Sprint (Sprint Backlog, Reunies Dirias, Burndown Chart)

Sprint Backlog

Histrias Criar servio de carga de oportunidades ganhas no CRM para base clientes (para sinalizao / contestao); Retornando Data Venda Contrato Cliente Email Telefone Atendimento Corretor. Alterar a nomenclatura: de 100% para bonificaes identificadas, 50% para bonificaes compartilhadas e 0% para bonificaes no identificadas; Adicionar parmetro do sistema: qtde de dias a partir do inicio do ms corrente, para disponibilizao do relatrio de sinalizao de bonificao de vendas oportunidades; Criar paginao nos relatrios de vendas, para exibir a cada 100 registros encontrados; Criar dois "radios" para "Minhas Bonificaes" "Todas

ID

Tarefas Criar consulta que retorne as informaes Data Venda, N. Contrato, Cliente, Email, Telefone Cliente, N Atendimento, Corretor, Ajustar arquitetura do Banco (criar tabela para armazenar informaes de oportunidades ganhas no CRM) Criar servio que copia os dados sobre as Oportunidades Ganhas no CRM para a base Clientes Alterar a nomenclatura: de 100% para bonificaes identificadas, 50% para bonificaes compartilhadas e 0% para bonificaes no identificadas;

Complexidade

Horas

Atividade

Desenvolver

Desenvolver

Desenvolver

Desenvolver

Adicionar parmetro do sistema: qtde de dias a partir do inicio do ms corrente, para disponibilizao do relatrio de sinalizao de bonificao de vendas oportunidades;

Desenvolver

Criar paginao nos relatrios de vendas, para exibir a cada 100 registros encontrados; Criar dois "radios" para "Minhas Bonificaes" "Todas Bonificaes" e que pesquise pelo

Desenvolver

Desenvolver

73

Bonificaes" e que pesquise pelo Nome de todos os Atendentes vinculados

Nome de todos os Atendentes vinculados

Criar servio para sinalizao de vendas e apresentar certeza de bonificao

10

Criar funo para pesquisar na base de Cliente algum registro que tenha Nome ou Telefone ou Email que seja igual ao Nome, telefone e Email preenchidos na Oportunidade. Criar funo para pesquisa de atendimentos passando uma lista de Cliente e perodo (Parmetro de sistema) Criar funo para listar colaboradores envolvidos nos atendimentos do Cliente (Passar lista de clientes e parmetro de sistema(Perodo)) Adaptao da interface de exibio conforme as informaes que deveram ser exibidas; Criar coluna para exibir todos os atendimentos que possivelmente esto relacionados com a Oportunidade; Criar coluna para exibir todos NOMEs dos Atendentes Participantes sem repetio;

Desenvolver

Desenvolver

Desenvolver

Adaptao da interface de exibio conforme as informaes que deveram ser exibidas

11

Desenvolver

Criar funo que permita abrir os Atendimentos somente para leitura; Gerar funo para Gerar Arquivo Excell das vendas retornadas Gerar funo para criar Massa de Dados;

12

Criar funo que permita abrir os Atendimentos somente para leitura; Gerar funo para Gerar Arquivo Excell das vendas retornadas Gerar funo para criar Massa de Dados para Clientes; 1000 registros Parte 1 Gerar funo para criar Massa de Dados para Clientes; 1000 registros Parte 2

Desenvolver

13

Desenvolver

14

Desenvolver

15

Desenvolver

74

16 Gesto de log de execuo de servios, tratamento para falhas, sucesso, envio de emails e demais comunicaes

17

18 19 20

Gerar funo para criar Massa de Dados para Clientes; 1000 registros Parte 3 Criar tabelas de LOG_SERVIOS e LOG_SERVIIOS_EXE CUO Criar procedure de insert Adaptar servios existentes para receber a nova arquitetura; Criar funo de envio de email padro

Desenvolver

Desenvolver

3 5 5

4 8 8

Desenvolver Desenvolver Desenvolver

Relatrio de "Mdias por Consultor" - Query para pesquisa analtica. Relatorio de "Mdias por Consultor" - Query para grfico Pizza. Relatrio de "Mdias por Consultor" - Criar Chart do grfico de Pizza. Relatrio de "Mdias por Consultor" - Criar Design da tela de detalhamento. Relatrio de "Resultados por Loja" - Criar RDLC do detalhamento. Obter informaes sobre arquitetura de banco CRM Criar Branch e publicar ambiente de QAS Ajustar Planilha de funcionalidades Corrigir publicao em QAS Relatrio de "Mdias por Cidade" - Criar tela de filtros. Relatrio de "Mdias por Cidade" - Criar tela com filtros, incluir funcionalidades. Relatrio de "Mdias por

21

Desenvolver

22

Desenvolver

23

Desenvolver

24

Webdesigner

25

Desenvolver

26

Analise

27 28 30 Corrigir publicao em QAS 2

6 2 4

Analise Analise Correo

29

Webdesigner

30

Desenvolver

31

Desenvolver

75

Cidade" - Query para pesquisa analtica. Relatrio de "Mdias por Cidade" - Query para grfico Pizza. Relatrio de"Mdias por Cidade" - Criar Chart do grfico de Pizza. Relatrio de"Mdias por Cidade" - Criar Design da tela de detalhamento. Relatrio de "Mdias por Cidade" - Criar RDLC do detalhamento.

32

Desenvolver

33

Desenvolver

34

Webdesigner

35

Desenvolver

Reunies Dirias

Dia

O que j foi feito? Nada (inicio do sprint) Atividades 17, 18 e metade da 19. Atividades 19 e 20. Atividades 14. Atividades 15. Atividades 16. Atividades 4, 5 e 12. Atividades 13, 21, 22, 23 e 25. Atividades 30, 31, 32, 33 e 35.

O que eu Tm alguma coisa pretendo fazer ate impedindo meu trabalho? amanh? Atividades 17 e 18. No

08/05

09/05 10/05 11/05 14/05 15/05

Atividades 19 e 20. Atividades 14. Atividades 15. Atividades 16. Atividades 4, 5 e 12.

No No No No No

16/05

Atividades 13 e 21. Atividades 30, 31, 32, 33 e 35. Sem tarefa (dia do sprint review)

No

17/05 18/05

No No

76

Burndown Chart

Figura 19: Burndown Chart do Sprint 8 Fonte: SAVIOTTE, 2012

77

Anexo B O Manifesto gil e os 12 princpios, guia dos valores geis

O Manifesto gil pode ser visto abaixo (FOWLER & HIGHSMITH, 2001): Estamos descobrindo maneiras melhores de desenvolver software fazendo-o ns mesmos e ajudando outros a faz-lo. Atravs deste trabalho, passamos a valorizar: - Indivduos e interaes mais que processos e ferramentas - Software em funcionamento mais que documentao abrangente - Colaborao com o cliente mais que negociao de contratos - Responder a mudanas mais que seguir um plano Ou seja, mesmo havendo valor nos itens direita, valorizamos mais os itens esquerda. Para sustentar os valores geis, foram criados doze princpios que devem ser seguidos em projetos de desenvolvimento gil de software. Esses princpios servem de guia que os valores geis sejam colocados em prtica. Eles esto listados abaixo (FOWLER & HIGHSMITH, 2001): 1. Nossa maior prioridade satisfazer o cliente atravs da entrega contnua desde cedo de software com valor. 2. Mudanas de requisitos so bem-vindas, mesmo tardiamente no e

desenvolvimento. Processos geis utilizam a mudana em favor da vantagem competitiva do cliente. 3. Entregar frequentemente software em funcionamento, desde a cada duas semanas at a cada dois meses, com uma preferncia por prazos mais curtos. 4. Pessoas do negcio e desenvolvedores devem trabalhar em conjunto diariamente por todo o projeto. 5. Construa projetos em torno de indivduos motivados. D-lhes o ambiente e o suporte que precisam e confie neles para fazerem o trabalho. 6. O mtodo mais eficiente e eficaz de se transmitir informao para e entre uma equipe de desenvolvimento a conversao face a face.

78

7. Software em funcionamento a medida primria de progresso. 8. Os processos geis promovem o desenvolvimento sustentvel. Os

patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante indefinidamente. 9. A ateno contnua excelncia tcnica e a um bom projeto aumenta a agilidade. 10. Simplicidade - a arte de se maximizar a quantidade de trabalho no feito - essencial. 11. As melhores arquiteturas, requisitos e projetos emergem de equipes que se auto-organizam. 12. Em intervalos de tempo regulares, a equipe reflete sobre como se tornar mais eficaz, para ento aprimorar e ajustar seu comportamento de acordo.