ESCOLA SUPERIOR ABERTA DO BRASIL ESAB CURSO DE PS-GRADUAO LATO SENSU EM ENGENHARIA DE SISTEMAS

VALDIR CALIXTO DA SILVA

SCRUM DESENVOLVIMENTO GIL

VILA VELHA (ES) 2012

VALDIR CALIXTO DA SILVA

SCRUM DESENVOLVIMENTO GIL

Monografia apresentada ao Curso de Ps-Graduao em Engenharia de Sistemas, da Escola Superior Aberta do Brasil, como requisito para obteno do Ttulo em Engenharia de Sistemas, sob orientao do Prof. Me. Jesse Gomes Dos Santos.

VILA VELHA (ES) 2012

VALDIR CALIXTO DA SILVA

SCRUM DESENVOLVIMENTO GIL

Monografia aprovada em .....de.................de 2012. Banca examinadora:

______________________________ ______________________________ ______________________________

VILA VELHA (ES) 2012

AGRADECIMENTO

Agradeo a minha esposa, pelo incentivo, fora e por entender minha ausncia em vrios momentos e que esta comigo nos momentos bons e ruins. Tambm agradeo a Deus e ela, por trazer nosso filho com sade, um presente que recebi durante este projeto. Agradeo a todos professores, que elaboraram o material do curso, que forneceu uma base slida para o conhecimento da matria. Ao meu orientador pela competncia. A minha me, pois tudo que sou devo a ela.

A estratgia sem ttica o caminho mais lento para a vitria. Ttica sem estratgia o rudo antes da derrota. Sun Tzu

RESUMO
Este trabalho tem como objetivo principal demonstrar os fundamentos e caractersticas do framework scrum para gerenciamento de projetos e suas vantagens em relao ao Modelo Tradicional, desta forma abordamos todo o seu workflow. O scrum, apontado como a metodologia gil, que mais utilizado em empresas, cujo o foco Internet, seja na rea de entretenimento, e-commerce ou social Midia posso citar por exemplo, Yahoo, Google, Dafiti, Shoes4you, o framework scrum nada mais que uma boa prtica para gerenciamento de projetos, que tem como base um processo incremental e interativo, ideal para projetos que esto em constantes mudanas, sejam tecnolgicas ou de requisitos de sistemas, utilizando o framework scrum de forma correta, empresas e profissionais tm melhores resultados, tanto no que tange prazos, custos e satisfao final do cliente. Atravs da pesquisa, pretende-se chegar a uma concluso que favorea o framework scrum, demostrando suas TimeBox, papis e responsabilidades. Abordou-se ainda uma forma de se iniciar o gerenciamento de projetos com o framework scrum, demostrando como se iniciar o ciclo de desenvolvimento, acompanhamento ou cancelamento. Palavras-chave: scrum. Gerncia de Projetos. Mtodos geis. Mtodos Tradicionais.

SUMRIO
1 INTRODUO.....................................................................................................9 2 FUNDAMENTAO TERICA..........................................................................13 2.1 PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE.............................13 2.2 MTODOS GEIS............................................................................................15 3 SCRUM................................................................................................................17 3.1 FRAMEWORK SCRUM....................................................................................17 3.2 SPRINT - CICLO DE DESENVOLVIMENTO INCREMENTAL........................18 3.3 PAPIS NO SCRUM.........................................................................................20 3.4 O PRODUCT OWNER......................................................................................20 3.5 SCRUM MASTER.............................................................................................21 3.6 SCRUM TEAM..................................................................................................22 4 ARTEFATOS E INDICADORES..........................................................................23 4.1 ARTEFATOS.....................................................................................................23 4.2 PRODUCT BACKLOG......................................................................................23 4.3 SPRINT BACKLOG..........................................................................................24 4.4 BURNDOWN CHART.......................................................................................25 5 REUNIES..........................................................................................................28 5.1 SPRINT PLANNING MEETING........................................................................28 5.2 DAILY SCRUM MEETING................................................................................29 5.3 SPRINT REVIEW MEETING............................................................................30 5.4 SPRINT RETROSPECTIVE.............................................................................31 6 PREPARANDO A EQUIPE..................................................................................33 6.1 EVANGELIZAO DA EQUIPE.......................................................................33 6.2 COMO CRIAR SPRINTS..................................................................................34 6.3 CALCULANDO O ESFORO E VELOCIDADE...............................................35 6.4 INICIANDO UM SPRINT..................................................................................37 6.5 CANCELANDO UM SPRINT............................................................................37 7 COMPARAO COM A METODOLOGIAL TRADICIONAL.............................39 7.1 MODELOS TRADICIONAIS.............................................................................39 7.2 MODELO BALBRDIA.....................................................................................40 7.3 CICLO DE VIDA CLSSICO CASCATA...........................................................41

7.3.1 Definio de requisitos...............................................................................42 7.3.2 Projeto de software......................................................................................42 7.3.3 Desenvolvimento.........................................................................................43 7.3.4 Testes de sistema........................................................................................44 7.3.5 Implantao..................................................................................................44 7.4 SCRUM X MODELOS TRADICIONAIS............................................................46 8 CONCLUSO......................................................................................................47

1 INTRODUO
Exposio do assunto: O desenvolvimento de software se tornou uma das mais importantes atividades econmicas do nosso tempo, assim, gerando uma das maiores indstrias, do sculo XXI. Gerando milhes de empregos ao redor do mundo, atravs desta indstria so criados diversos produtos de software, dos quais muitos so de suma importncia para ns, seja para o nosso estilo de vida, sade, educao, comrcio, segurana, cincia e outras reas da vida. O produto de software, criado atravs das diversas tcnicas de desenvolvimento de software e linguagens de programao, tornou-se um dos maiores valores de propriedade intelectual. Este mercado, que sempre esta em constantes mudanas e evoluindo rapidamente, um dos setores econmicos mais competitivos, para os profissionais da rea e empresas, neste mbito o mercado consumidor desta indstria, inevitavelmente vai distingui as melhores prticas e as piores, exigindo cada vez mais produtos de softwares melhores, com entregas rpidas, e quer realmente atendam as necessidades dos clientes, consumidores deste produto. Existem diversas metodologias de desenvolvimento de softwares, mas sem dvida alguma os mtodos geis para desenvolvimento uma marco para empresas e para os profissionais que esto envolvidos no produto de software, acelerando os prazos para desenvolvimento dos projetos, aumentando a satisfao do cliente final, gerando a entrega de um produto final com melhor qualidade e que agregue valor. Como melhorar a qualidade de software utilizando scrum para gerenciamento de projetos?

10 Justificativa para escolha do tema: O desenvolvimento do produto de software reconhecido como um processo, cheio de possibilidades e muitas vezes complexo. Sabe-se que um produto de software, no construdo sempre da mesma maneira, havendo mudanas dentro das equipes, mudanas de pensamentos de desenvolvimento de software e de tecnologias. importantssimo reconhecer, como sendo um processo relativo, que composto do imprevisto e que tem ferramentas de ao corretiva para serem utilizadas dentro do processo de desenvolvimento do produto de software. Metodologias de desenvolvimento geis tem como principal caracterstica, serem extremamente adaptveis, levando em considerao o tamanho da equipe, do projeto, nvel de conhecimento tcnico dos envolvidos no processo de criao do produto de software, problemas que podem ocorrer durante o desenvolvimento, sem a necessidade de avaliar tudo anteriormente, ao inicio do projeto. Avaliaes prvias aumentam o custo do projeto e o prazo, alm de tornar muito difcil qualquer alterao de planejamento no decorrer do projeto, salientando, que o problema no a mudana, porque ela vai ocorrer em qualquer projeto e metodologia que esteja sendo aplicada, a grande questo como lidar com estas mudanas, e que em muitos casos levam ao fracasso do projeto, ou a entrega de um produto de baixa qualidade ao cliente final. Utilizando uma metodologia clssica, muitos produtos de software so

desenvolvidos por completo, e s na entrega acaba-se descobrindo que o produto no serve mais para o fim que foi desenvolvido, porque inevitavelmente muitos requisitos e regras podem mudar, durante o desenvolvimento do produto de software, e as mudanas se tornam to complexas que acabam ficando inviveis, para serem implementadas no produto de software. Utilizando metodologias de desenvolvimento geis, uma de suas premissas, o feedback constante, que permiti adequar-se rapidamente a mudanas nos requisitos, e o framework scrum tambm trabalha com esta premissa, um ponto que

11 tambm a destacar-se, nas metodologias de desenvolvimento geis so as entregas constantes dos artefatos do produto de software, assim o cliente final no precisa, aguardar a entrega final do produto de software, ele pode ir acompanhando as entregas e verificar partes do produto de software em funcionamento e se no estiver dentro das suas expectativas, as mudanas so efetuadas e os problemas resolvidos, dando continuidade ao projeto e integrando os artefatos. Objetivos geral e especificos: O objetivo geral da pesquisa apresentar o framework scrum em suas diversas funcionalidades e formas de aplicao para diversos tipos de projetos e equipes de tamanhos e nveis de conhecimento tcnico diferentes. Abordando seu desempenho para gerenciamento de projetos em diversos nveis, em que solues devem ser desenvolvidos, com agilidade, qualidade, dentro do escopo, prazo e qualidade definidos, demostrando suas vantagens em relao ao mtodo tradicional de gerenciamento de projetos. - Compreender a dinmica da metodologia scrum; - Descrever todos os processos de desenvolvimento de software utilizando scrum; - Relacionar os processos do scrum com o sucesso dos projetos no qual foi aplicado; - Foco no produto de software incremental; - Construo de artefatos empricos. Delimitao: Este trabalho tem como objetivo principal abordar a metodologia de desenvolvimento de software gil framework scrum, que utilizado por diversas empresas da indstria de tecnologia, para gerenciamento dos projetos de desenvolvimento de softwares e suas vantagens em relao Metodologia Tradicional de desenvolvimento de software.. Metodologia de Pesquisa: A pesquisa foi toda desenvolvida com base na leitura e anlise de livros, artigos, peridicos abordando as diferentes vises sobre scrum, os benefcios alcanados, as diferentes formas de se implementar scrum em equipes

de

desenvolvimento,

comparao

com

metodologia

tradicional

12 de

desenvolvimento e porque scrum, faz tanto sucesso e os projetos so cada vez mais bem sucedidos, trazendo ganho de performance dos profissionais envolvidos, melhorando a comunicao entre as reas envolvidas no projeto e o recursos financeiros so melhores aproveitados evitando gastos desnecessrios.

13

2 FUNDAMENTAO TERICA
Este captulo aborda, como implementado o processo de desenvolvimento de software, atravs da engenharia de software. Na seo 2.1, abordam-se as caractersticas do processo de desenvolvimento de software, fundamentos essenciais envolvidos no processo como requisitos, implementao, validao e manuteno. Com base nos conceitos da seo 2.1 a seo 2.2 aborda os mtodos geis, destacando suas caractersticas e levantado as principais metodologias geis de desenvolvimento mais conhecidas no mercado e praticadas. A seo 2.3 faz um breve levantamento histrico sobre o surgimento das metodologias geis, destacando seus principais mentores e suas diretrizes. Na seo 2.4 tem-se a transcrio do manifesto gil.

2.1 PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE

Processo de software so conjuntos de atividades, que os resultados auxiliam no processo de desenvolvimento do produto de software, que pode ser resultado de uma ou diversas metodologias utilizadas, sabe-se da existncia de diversas metodologias para gerenciamento de desenvolvimento de softwares, mas todas devem ter conceitos fundamenteis, especificao do produto de software, implementao, validao e manuteno do produto de software (PRESSMAN, 2006). O levantamento de requisitos de um produto de software, o que deve ser realizado no primeiro momento para sua criao, mesmo que o cliente tenha convico do produto de software que ele necessita, para esta etapa o profissional dever ter larga experincia (PRESSMAN, 2006). Na etapa de especificao, elaborado o documento que vai descrever exatamente o produto de software que deve ser implementado (PRESSMAN, 2006).

14 Projeto e implementao a etapa onde o produto de software em si desenvolvido de acordo com as especificaes e utilizando uma linguagem de programao (PRESSMAN, 2006). Validao do produto de software desenvolvido verificado se realmente o software atende todas as especificaes e funcionalidades levantadas (PRESSMAN, 2006). Manuteno do produto de software a continuidade do produto de software com relao a sua evoluo e necessidade de novas funes ou mudanas de requisitos para o produto de software continuar a ser til para o cliente (PRESSMAN, 2006). Toda metodologia de desenvolvimento deve lidar com problemas novos e requisitos, a manuteno uma etapa importante do desenvolvimento de software, e deve lidar com esta etapa do processo de desenvolvimento de software, boa parte do tempo de desenvolvimento gasto com reparos, e correes de requisitos que no foram levantados ou que deixaram questes em aberto (PRESSMAN, 2006). H muito tempo vem se tentando encontrar processos ou metodologias ideais para o gerenciamento de desenvolvimento de software, para melhorar qualidade do produto, custo e tempo de entrega, o primeiro modelo foi processo em Cascata, uma metodologia pesada e que tem como um dos seus pr-requisitos larga documentao, antes de desenvolver qualquer linha de cdigo (PICHLER, 2011). A engenharia de software responsvel por tratar todos os aspectos do desenvolvimento do produto de software, desdes as etapas iniciais dos requisitos at a Manuteno do produto de software, tambm parte importante para a engenharia de software, as metodologias, ferramentas e mtodos que os profissionais e empresas desenvolvedoras do produto de software baseiam-se para que os projetos sejam bem sucedidos (PRESSMAN, 2006). Uma metodologia nada mais que uma abordagem estruturada de como se deve desenvolver um produto de software, seguindo boas prticas que foram utilizadas

15 por outros indivduos, empresas e que estes projetos foram realizados com sucesso (COHN, 2011). utopia afirmar a existncia de um mtodo ideal, tudo depende do ambiente de desenvolvimento, projeto, pessoas e produto, existem mtodos que funcionam melhor e trazem resultados importantes para o gerenciamento de projetos (PRESSMAN, 2006).

2.2 MTODOS GEIS

So mtodos de desenvolvimento que permitem a equipe de programadores foco total no produto de software, em virtude de aplicaes que esto em constantes mudanas nos requisitos, a documentao no parte mais importante do sistema, estes mtodos tem como principal abordagem a interatividade para especificao, desenvolvimento e entrega dos incrementos do produto de software, assim gerando uma diviso do sistema em sub sistemas, garantido a entrega de um produto de software funcional de maior produtividade e qualidade (PHAM, 2011). As metodologias geis so utilizadas para gerencia de projetos com a adoo de um conjunto de tcnicas, princpios e boas prticas para gerenciamento de projetos (SCHWABER, 2004). FOWLER (2005), afirma para os mtodos geis, as mudanas so parte do

processo e bem-vindas, os mtodos geis se tornam mais fortes e adaptveis dentro das organizaes e no decorrer deste processo evolutivo. Os mtodos geis quebram paradigmas tradicionais do gerenciamento de projetos, em relao como deve-se tratar as mudanas no escopo do projeto no decorrer dos projetos (KNIBERG, 2007). Mtodos tradicionais tratam o escopo sempre de forma fixa e no so flexveis as

16 mudanas de escopo, sempre controlando o mximo possvel, para que no haja este fluxo nos projetos em qual o mtodo tradicional aplicado (SURDEK; WOODWARD; GANIS, 2010). Todas as metodologias geis um dos princpios mais importantes ter um escopo manipulvel e ser flexvel, segundo o manifesto gil, Mudana de requisitos so bem vindas, mesmo em estgios tardios do desenvolvimento (SIMS; JOHNSON, HILLARY, 2007). Atualmente existem diversas metodologia de desenvolvimento, que tem como foco o manifesto gil, as mais importantes so: scrum, eXtreme Programming, Feature Driven Development, Crystal, DSDM e Lean. Estas metodologias tem seus princpios e tcnicas e a forma como gerenciam projetos, mas todas em comuns seguem os princpios do manifesto gil (VODDE; LAMAN, 2009). Scrum a mais importante e mais utilizada dentro das organizaes de diferentes seguimentos e tamanhos, principalmente em empresas do mercado de Internet, um mercado em constante evoluo que exige adaptao rpida e desenvolvimento gil para suas plataformas que esto em constantes mudanas e evoluindo diariamente, sejam elas, de comrcio eletrnico, Social Mida, entretenimento e informao (VODDE; LAMAN, 2009).

17

3 SCRUM

Este captulo tem como foco principal abordar o processo de desenvolvimento de software, gerenciado atravs do framework scrum utilizando o conceitos de desenvolvimento incremental e interativo. Na seo 3.1 destacando o conceito de product backlog e stakeholders relacionando aos requisitos de software para construo do produto de software. Na seo 3.2 feita uma anlise do ciclo de desenvolvimento do produto de software dentro do framework scrum, priorizao, planejamento e entrega. Na seo 3.3 encontra-se a estrutura dos papis destacando todos os envolvidos durante o ciclo de vida do desenvolvimento. Seo 3.4 so destacadas as principais atribuies do product owner. Seo 3.5 encontrase as tarefas do scrum master e relacionamos ao product owner, para o trabalho em conjunto. Na seo 3.6 abordado o scrum team, suas funes e grau de independncia e sua relao com o scrum master e demais membros da equipe.

3.1 FRAMEWORK SCRUM

O scrum um framework de desenvolvimento gil de software interativo e incremental para gerenciamento de equipes e projetos, que aborda toda a complexidade do processo do desenvolvimento do produto de software, destacandose ferramentas de controle de inspeo e visibilidade, implantando regras e prticas, os controles no significam controle para criar o que foi planejado, mais sim controlar o processo que orienta o trabalho em progresso a um produto de software, com valor agregado grande e qualidade (PICHLER, 2011). Com base nestes conceitos, o framework scrum sugere a abordagem interativa e incremental da seguinte forma, no inicio de cada interao, o time analisa o trabalho que deve ser desenvolvido, seleciona os itens que podem tornar-se um incremento que agrega valor ao produto de software no trmino da interao. As pessoas envolvidas, fazem o melhor para executar o desenvolvimento da interao e

18 conseguir entregar o incremento da funcionalidade do produto de software, para os stakeholders, avaliarem e solicitarem modificaes posteriores nos momentos certos (PICHLER, 2011). O Product Backlog o corao do scrum, normalmente uma lista de requisitos, estrias, coisas, funcionalidades que o cliente deseja. A cada nova interao o time deve avaliar os requisitos, as tecnologias envolvidas e domnio tcnico da equipe, para que haja a diviso do trabalho, para construir e entregar o produto de software dentro dos padres de qualidade exigido pelo cliente, respeitando prazos e tratando diariamente os problemas e surpresas que surgem durante o desenvolvimento do produto de software (KNIBERG, 2007) .

3.2 SPRINT - CICLO DE DESENVOLVIMENTO INCREMENTAL

O planejamento fundamental dentro do framework scrum, crtico e indispensvel, atravs do planejamento a equipe tem uma viso do produto de software ou partes dele que ser desenvolvido, neste momento so levantadas dvidas, questionamentos sobre as tarefas que compem o Product Backlog, a equipe deve colher todas as informaes suficientes para o desenvolvimento do trabalho (KNIBERG, 2007) . O product Owner o responsvel por priorizar e fornecer a lista de requisitos (Product Backlog) sejam eles funcionais ou no funcionais, qualificando as tarefas por ordem de importncia e prioridade, que agreguem mais valor ao produto de software (PHAM, 2011). Como boa prtica o framework scrum recomenda a diviso do Product Backlog, em releases, em muitos casos o contedo, as prioridades e agrupamento do Product Backlog podem sofrer mudanas a partir do momento que o projeto se inicia. Estas mudanas nada mais so que alteraes nos requisitos de negcios e rapidamente a equipe deve transform-los em um produto de software (PHAM, 2011) .

19 Normalmente cada sprint deve ter a durao entre duas e quatro semanas, todos os stakeholders (pessoas envolvidas no projeto), devem participar da reunio de sprint Planning Meeting, reunio que antecede o inicio de cada sprint, neste momento o product Owner e a equipe definem o sprint Backlog, tarefas que tem que ser entregues ao final do ciclo do sprint Backlog, a cada tarefa composta de trs variveis, escopo, importncia e estimativa (PICHLER, 2011) . Qualidade ponto importante, quando se trata de scrum seja ela interna ou externa, qualidade externa o que visto pelos usurios, qualidade interna refere-se a questes que no so observados pelo usurio, tal como estrutura do cdigo, testes de unidade, refatorao de cdigo (PHAM, 2011) . Geralmente um sistema com boa qualidade interna pode ter uma qualidade externa inferior, mas o caso inverso raramente vai ocorrer, este ponto importante porque em diversas ocasies o product Owner tentar espremer a estimativa do scrum team, isto no deve comprometer o cdigo, o ideal rever o escopo da tarefa (PHAM, 2011) . A equipe compromete-se a desenvolver e entregar as tarefas do sprint, em contra partida o product Owner tambm garante no trazer novos requisitos para serem desenvolvidos durante o ciclo do sprint Backlog. Requisitos funcionais e no funcionais podem mudar, mas sempre devem ocorrer fora do sprint Backlog (PHAM, 2011) . Ao final do planejamento do sprint deve-se chegar ao resultado final que indica, o objetivo do sprint, o sprint backlog, estimativa das tarefas, data para entrega do sprint e data e horrios para as reunies dirias (PHAM, 2011) . A partir do momento que a equipe comear a trabalhar no sprint Backlog, ela deve manter o foco no mesmo a fim de atingir o objetivo firmado, novos requisitos funcionais ou no funcionais no devero ser aceitos (KNIBERG, 2007) .

20 Diariamente o scrum team realiza a reunio chamada Daily, com durao de 15 minutos, para alinhar o trabalho da equipe e informar o scrum master sobre eventuais impedimentos no processo de desenvolvimento dos artefatos, definidos no sprint Planning (KNIBERG, 2007). Ao final de cada sprint BackLog, ocorre o sprint Review Meeting, neste momento o scrum team faz a entrega do produto de software desenvolvido no sprint (KNIBERG, 2007) . Antes de cada novo sprint, os stakeholders se renem para o Retrospective Meeting, no qual avaliada toda a pratica do scrum e o que precisa ser feito para melhorar o prximo sprint (SCHWABER, 2004) . A juno de todas estas prticas, fazem parte do ciclo de desenvolvimento dentro do framework scrum, no que contempla as diferentes etapas de um sprint, no sendo mandatria nenhuma etapa, mas sim considerada como boa prtica dentro do framework scrum, para atingir os objetivos (SCHWABER, 2004).

3.3 PAPIS NO SCRUM

O framework scrum tem como base uma estrutura iterativa e incremental, no qual se apoio em trs papis de suma importncia para a metodologia, o product Owner, o scrum master, o scrum team, a responsabilidade de todo o projeto compartilhada por estes papis, eles ento formam os pilares de sustentao do framework scrum, as equipes se organizam de forma dinmica e so capazes de exercer diversas funes (KNIBERG, 2007). Toda equipe que trabalha com a metodologia de desenvolvimento scrum deve ser projetada para aprimorar a criatividade e produtividade (PHAM, 2011) .

21

3.4 O PRODUCT OWNER

Todo o projeto que utiliza o framework scrum para gerenciamento, obrigatoriamente tem um product Owner e toda a equipe tem que saber quem exerce este papel dentro do projeto (SCHWABER, 2004) . responsvel por apresentar, maximizar e representar os interesses dos stakeholders no projeto define e gerenciar os requisitos do projeto, atravs do Product Backlog, deve expressar ordenar, priorizar e garantir que os itens do Backlog esto descritos de forma clara (SCHWABER, 2004) . O product Owner o responsvel pelo produto de software entregue aos stakeholders, toda e qualquer mudana no Product Backlog deve ser aprovada pelo product Owner, para o sucesso do projeto. Toda a companhia dever respeitar suas tomadas de deciso e jamais a equipe deve trabalhar em requisitos diferentes dos aprovados e priorizados por ele (KNIBERG, 2007) .

3.5 SCRUM MASTER

o responsvel por todo o processo scrum, garantir sua aplicao, por dissemin-lo para todas as pessoas envolvidas no projeto, um lder facilitador na Daily Meeting e durante todo o sprint, tornando uma cultura na companhia, e tem uma tarefa muito importante que , garantir que toda a equipe trabalhe conforme as regras e as boas prtica do framework scrum, afim de tornar uma metodologia consistente dentro da equipe (KNIBERG, 2007) . O scrum master tem o papel tambm importante que ajudar, todos aqueles fora da equipe scrum, a entender as interaes com a equipe, que trazem benefcios e quais no trazem, protegendo a equipe e assegurando o no compromisso em relao as tarefas que no podem ser realizadas durante o sprint (SURDEK, 2010) .

22 O scrum master fornece vrios servios para todos os envolvidos no projeto, como o product Owner o scrum team e a para a Companhia, realizando as comunicaes dos avanos de forma clara e objetiva, orientando e liderando a equipe, seja no ambiente organizacional, removendo impedimentos, praticando a agilidade, alinhando os objetivos do Backlog para o desenvolvimento emprico de produtos (SIMS, 2007) .

3.6 SCRUM TEAM

a equipe de desenvolvimento dentro de um determinado projeto que utilizado o framework scrum para gerenciamento, responsvel por estima de esforo para cada histria do Product Backlog, desenvolver as funcionalidades do produto de software e o sucesso do projeto, composta por product Owner, scrum master e o prprio time de desenvolvimento (SIMS, 2007) . Tipicamente uma equipe de scrum composta entre 4 e 8 pessoas, mas tem que ser suficientemente pequena para que seja realmente gil e no muito grande para no que seja necessrio uma coordenao muito grande, tem a capacidade de ser auto gerencivel, so multifuncionais e escolhem a forma que o trabalho vai ser realizado, dentro das equipes scrum no se tem a necessidade da diviso funcional (COHN, 2011). Usando como base papis tradicionais, todos os indivduos trabalham em parceria e so responsveis por concluir o trabalho que comprometeram-se em cada sprint plainning, durante cada interao no h mudanas de membros dentro de uma equipe scrum (COHN, 2011). Equipes que utilizam o framework scrum, tm como principais caractersticas, produtividade, criatividade e so extremamente flexveis, sempre esto produzindo entregas incrementais, que do garantia a um verso til do produto de software (COHN, 2011) .

23

4 ARTEFATOS E INDICADORES

Este captulo abordar todos os artefatos do framework scrum e os indicadores. Na seo 4.1 listam-se os artefatos e o que trazem de positivo para o processo de gerenciamento de projetos atravs do framework scrum. Na seo 4.2 aborda-se o product backlog e como estruturar um backlog, responsabilidade de priorizao e estimativas e adequao durante o ciclo de desenvolvimento. Na seo 4.3, como organizar o sprint backlog utilizando como base o product backlog, atualizao, andamento do sprint backlog, visibilidade e objetivo do sprint, que sempre deve ser definido antes do seu inicio. Na seo 4.4 traz o burndown chart, como utilizar e melhores prticas para monitoramento e andamento do sprint backlog.

4.1 ARTEFATOS
Os artefatos demonstram o trabalho de vrias maneiras, so indicadores durante todo o ciclo de desenvolvimento, so benficos por oferecer transparncia e oportunidades para acompanhamento e adaptao, so projetados para dar mais transparncia e garantir que as equipes scrum, tenham sucesso ao entregar o incremento do produto de software, composto por Product Backlog, sprint Backlog e o Burndown Chart (KNIBERG, 2007) .

4.2 PRODUCT BACKLOG

uma lista de itens ordenados, contendo tudo ou partes dos requisitos funcionais ou no funcionais, melhorias e consertos que podem ser necessrios para o produto de software, a fonte de mudanas a serem implementadas no produto de software (COHN, 2011) . Esta lista de itens apresentada e priorizada pelo product Owner, ele o nico que

24 pode incluir, retirar e definir a o ordem do Product Backlog, todos os itens so compostos por descrio, prioridade e estimativa de tempo (KNIBERG, 2007). Esta lista nunca completa no inicio do projeto, sendo formado apenas atravs de requisitos conhecidos no inicio, desta forma dinmica, evoluindo medida que o projeto vai sendo desenvolvido, desta forma pode ser modificada a qualquer momento no projeto (SURDEK, 2010) . Para atender algo no produto de software, que seja mais importante para tornar lo mais competitivo e a medida que o conhecimento do produto de software aumenta novas funcionalidades se fazem necessrias desta forma importantssimo a adequao do Product Backlog (KNIBERG, 2007).

O framework scrum no recomenda e no determina um padro de como esta lista deve ser formada, deixando livre para o product Owner definir como ele vai capturar os requisitos e apresent-los ao scrum team, em todos os projetos que utilizam o framework scrum para gerenciamento optam por utilizar a tcnica de listar cada item como uma estria, podendo ser inseridas em cartes pregados a paredes, quadros brancos ou utilizar softwares de gerenciamento de projetos que tem como plataforma o framework scrum (KNIBERG, 2007). A medida que um produto de software disponibilizado ao mercado consumidor de produtos de software, e ganha valor, inevitavelmente o mercado vai oferecer uma realimentao para o Product Backlog, requisitos no vo parar de mudar, a tecnologia no vai parar de evoluir tornando esta lista mais completa e longa, desta forma o Product Backlog um artefato em constante mudana (VODDE, 2009).

4.3 SPRINT BACKLOG

um conjunto de estrias do Product Backlog, um plano com detalhes que demonstram as mudanas em progresso e que possam ser entendidas no scrum

25 dirio, so selecionadas com base nas prioridades estipuladas pelo product Owner (PHAM, 2011). uma previso da equipe de desenvolvedores sobre as funcionalidades e o trabalho necessrio para realizar o desenvolvimento, testes e entrega da estria, inclui tambm a estratgia para obter o incremento do produto de software e realizar a entrega do sprint Backlog dentro do ciclo de vida determinado do sprint (KNIBERG, 2007). O sprint Backlog deixa visvel todo o trabalho da equipe de desenvolvimento, identifica o que necessrio para atingir o objetivo do sprint, a equipe de desenvolvimento, deve somente se comprometer com as estrias que efetivamente, sejam capazes de entregar dentro do ciclo de vida do sprint (PICHLER, 2011). No ciclo de vida do sprint, o scrum master, sempre vai manter o sprint Backlog, atualizado utilizando o grfico BurnDown Chart (KNIBERG, 2007). Assim toda a equipe pode acompanhar o andamento e avanos das estrias, refletindo as estrias prontas e as estrias a serem desenvolvidas, desta maneira demonstrando o quanto de tempo ainda necessrio para concluir as estrias em aberto e se a equipe est no prazo, a frente do tempo estimado ou atrasada em relao as estimativas de tempo para cada estria (KNIBERG, 2007). Durante o ciclo de vida de um sprint, possvel ter situaes no comuns, e que devem ser evitadas para que os projetos que utilizam o framework scrum para gerenciamento possam ser bem sucedidos, que a insero de estrias dentro de um sprint Backlog em andamento, estas estrias so tratadas como INTRUDERS, e se faz necessrio estimar novamente a quantidade de estrias do sprint Backlog, para que a equipe no seja sobrecarregada e consecutivamente o objetivo do sprint no seja cumprido (KNIBERG, 2007).

26

4.4 BURNDOWN CHART

Com o Burndown Chart, possvel realizar o monitoramento do progresso do projeto, exibir no decorrer de um determinado perodo de tempo o quanto de trabalho que ainda deve ser realizado, desta forma permitindo a todos os membros da equipe acompanhar a evoluo dos artefatos do sprint Backlog, o principal artefato para acompanhar o andamento de cada ciclo de vida do sprint (COHN, 2011). construindo a partir da lista do sprint Backlog, sempre atualizado diariamente pelo scrum team, tem como base o nmero de dias existentes para o fim do sprint Backlog, somando-se a quantidade de horas para terminar cada estria do sprint Backlog, chegamos ao resultado final de quantas horas ainda so necessrias para finalizar o ciclo de vida do sprint, a medida que as estrias so finalizadas no decorrer dos dias do ciclo de vida do sprint, a linha base do grfico vai decrescendo at chegar ao nmero de horas zero (KNIBERG, 2007). No eixo Y do grfico Burndown Chart, tm-se os nmero de horas que foram estimadas para o ciclo de vida do sprint, enquanto no eixo X o nmero de dias do ciclo de vida do sprint (KNIBERG, 2007). Com base no grfico, pose-se visualizar de forma clara a velocidade de desenvolvimento das estrias do sprint Backlog dentro do ciclo de vida do sprint, este grfico sofre oscilaes durante o sprint e isto permite a tomada de decises, em virtude da velocidade de desenvolvimento e entregas estarem muito abaixo ou muito acima do esperado para a concluso do sprint, para a montagem do grfico e base de clculo das estimativas das estrias finais de semana e feriados no so contabilizados, pois raramente trabalhos so executadas nestes perodos (KNIBERG, 2007). Dois pontos que no podem ser deixados de lado, se a linha de progresso esta muito acima da linha base, temos um problema no sprint, que podem ser estrias

27 mau estimadas, itens no planejados foram colocados nos sprint BackLog, e ento deve haver uma readequao, se a linha de progresso estiver muito abaixo a estimativa da estrias podem estar erradas tambm, ou a equipe de desenvolvimento tem capacidade para um sprint maior do que fora definido neste ponto cabe ressaltar a importncia de incluir novas estrias no sprint BackLog, que a equipe seja capaz de finalizar durante o perodo restante do ciclo de vida do sprint. A equipe deve sempre seguir a ordem da estrias conforme a prioridade definida pelo product Owner, estrias de prioridade mais alta devem sempre ser as primeiras a serem desenvolvidas e entregues (KNIBERG, 2007).

28

5 REUNIES

Este captulo aborda as reunies que fazem parte do framework, destacando as caractersticas de cada uma delas e seus objetivos. Na seo 5.1 referencia-se a reunio mais importante do scrum o sprint plainning meeting, que engloba a definio dos escopos do sprint backlog, destacando a participao dos stakesholders. Na seo 5.2 especificada a reunio diria durante o ciclo de vida de um sprint e como conduzi-la. Na seo 5.3 aborda-se a reunio que marca o fim do ciclo de vida de um sprint, demostrando o que realmente foi entregue ao final do ciclo de desenvolvimento. Na seo 5.4 fala-se sobre retrospectiva e como melhorar o processo do scrum e sprint dentro de equipes.

5.1 SPRINT PLANNING MEETING

O sprint Planning Meeting uma reunio divida em duas parte, na primeira parte participam o product Owner, scrum master, todo o scrum team, e qualquer pessoa interessada que represente os stakeholders (KNIBERG, 2007). Nesta reunio o product Owner fala sobre as estrias e a ordem de prioridade de cada uma delas, a equipe interage realizando questionamentos sobre as tarefas, para que possa analisar tecnicamente a soluo e o esforo que vai ser gasto para cada desenvolvimento, todas as estrias discutidas no sprint Planning Meeting, faram parte do sprint Backlog (PICHLER, 2011). Se o sprint Backlog for muito grande em relao a velocidade da equipe, se faz necessrio a descrio e discusso tcnica somente das estrias definidas com a maior prioridade, ficando para o prximo sprint Planning Meeting as tarefas de prioridade menor (PICHLER, 2011).. Na segunda parte o scrum team, se rene para efetivamente define o que ser

29 necessrio para realizao das estrias, somente o scrum team pode definir o quanto capaz entregar durante o ciclo de vida do sprint (PICHLER, 2011). Em comum acordo product Owner, scrum team e scrum master, determinam um objetivo em comum para o ciclo de vida do sprint, que a descrio do que deve ser alcanado ao final do ciclo de desenvolvimento, as estimativas de esforo no devem sofrer influncia dos stakeholders e do Product Owner, cabe ao Scrum team definir de forma mais assertiva o possvel o grau de complexidade das estrias (KNIBERG, 2007). Durante o perodo ciclo de vida do sprint, os membros da equipe tem a liberdade de escolher quais estrias desejam trabalhar, estrias que ocupam o espao de desenvolvimento maior que um dia, so quebradas em sub tarefas, para sempre ter um incremento novo da estria principal (PHAM, 2011). Diariamente realizada a reunio Daily scrum Meeting, para uma breve discusso sobre o andamento das estrias, ser visto um pouco mais sobre esta reunio nos tpicos a seguir (PHAM, 2011) . Aps o ciclo de vida do sprint, ele deve ser avaliado de acordo com o objetivo traado, na reunio de sprint Review Meeting, analisando os pontos positivos, negativos, todas as lies devem ficar no histrico para melhorar os sprints futuros e todo o ciclo de vida do scrum dentro das equipes (KNIBERG, 2007).

5.2 DAILY SCRUM MEETING

A Daily Scrum Meeting ocorre diariamente, sempre no mesmo horrio e local, indicado realizar durante o perodo matutino, todos os participantes scrum team ou Ouvintes devem ficar em p e por conveno no deve passar de 15 minutos (KNIBERG, 2007). Nessa reunio todos os membros do scrum team, relatam o que fizeram no dia

30 anterior e o que pretendem fazer no dia, em relao as estrias do sprint, os ouvintes no so autorizados a falar no Daily scrum Meeting, atravs da Daily scrum Meeting possvel, identificar impedimentos que bloqueiam o desenvolvimento e concluso de qualquer estria que compem o Product Backlog do sprint (VODDE, 2009). O scrum master responsvel por tratar os impedimentos de forma rpida e objetiva para que a equipe possa avanar com as estrias, com os relatos do que foi feito, o que vai ser feito hoje e se h impedimentos (KNIBERG, 2007). possvel realizar priorizao de estrias dentro de um dia de trabalho e a equipe acaba com uma viso mais ampla do andamento do sprint, em relao as estrias j finalizadas e as que ainda devem ser desenvolvidas (KNIBERG, 2007). Na reunio de Daily scrum Meeting, no se deve resolver problemas, se por ventura algum problema for levantado, ele dever ser discutido fora da reunio, somente com os membros do scrum team envolvidos na estria e as pessoas envolvidas diretamente no problema que podem auxiliar de alguma forma para que o problema seja sanado (SURDEK, 2010). A Daily scrum Meeting, no dever ser encarada como uma ferramenta para atualizao de status do scrum team para o scrum master, mas sim para interao entre as pessoas e a proliferao do conhecimento entre scrum team, scrum master e Ouvintes participantes do Meeting, existem ferramentas apropriadas que podem fornecem atualizao de status e acompanhamento do projeto para o scrum master (KNIBERG, 2007).

5.3 SPRINT REVIEW MEETING

Ao final do ciclo de vida do sprint, realizado o sprint Review Meeting, reunio para demostrar as estrias concludos durante o sprint, que so exibidas em um formato

31 pr-produo das funcionalidades incrementais do produto de software (KNIBERG, 2007). Esta reunio tem como participantes o scrum master, scrum team, product Owner e os StakeHolders, no decorrer da reunio o sprint finalizado avaliado, no qual levantado se o objetivo do sprint foi atingido, se as estrias inseridas do Product Backlog para o Product Backlog do sprint esto de acordo com os requisitos e se de uma forma geral a equipe conclui o ciclo de vida do sprint de forma satisfatria, analisando se os objetivos foram atingidos de forma satisfatria para os interessados no ciclo de vida do Sprint (COHN, 2011).

5.4 SPRINT RETROSPECTIVE

Antes de iniciar um novo ciclo de vida de um sprint, todo o scrum team, scrum master, product Owner e demais interessados, fazem uma reunio para realizar uma retrospectiva sobre o sprint passado, realizada em uma sala fechada e todos os participantes sentados, no deve durar mais que 2 duras horas, de forma alguma esta reunio deve ser interrompida.(KNIBERG, 2007) Sem a sprint Retrospective a equipe vai sempre cometer os mesmos erros, que inevitavelmente trazem impactos negativos ao projeto (KNIBERG, 2007). Nesta reunio, deve-se identificar e expr o que deve ser melhorado no processo do ciclo de vida do sprint, observar se todas as prticas do scrum realmente esto sendo seguidas pelo membros da equipe, desta reunio sempre surgem novas ideias, sugestes e novas prticas, que podem melhorar o processo de desenvolvimento e boas prticas do scrum (KNIBERG, 2007). responsabilidade do scrum master exibir o sprint Backlog e com a ajuda do scrum team, faz uma breve explanao do sprint, velocidade estimada da estrias e velocidade real ao concluir cada estria, analisando se a diferena entre as duas

32 velocidades grande, tenta-se achar o que causou tamanha discrepncia (COHN, 2011). A diferena entre velocidade estimada, velocidade atingida, pode ser causada por erros de estimativa, interferncia externa, como por exemplo desenvolvedores sendo requisitados a realizar tarefas que no fazem parte do ciclo de vida do sprint, de forma alguma isto pode ocorrer, conforme a equipe vai adquirindo experincia no produto de software e com o framework scrum erros de estimativa so cada vez menores, toda e qualquer estimativa deve ser realizada por todos os membros do Scrum Team, e deve ser feita durante o planejamento do ciclo de vida do Sprint (COHN, 2011).

33

6 PREPARANDO A EQUIPE

Neste captulo abordamos como implementar scrum em equipes que nunca utilizaram mtodos geis de desenvolvimento ou outra ferramenta para gerenciamento de projetos. Na seo 6.1 destaca-se como evangelizar o time e a flexibilidade do scrum, que pode ser combinado com outros mtodos de desenvolvimento, sua curva de aprendizado estritamente pequena e fcil. Na seo 6.2, defini-se como criar sprints, organizar o backlog e o jogo plainning poker para torna as estimativas mais dinmicas e atraentes para os participantes. Na seo 6.3, entra-se no tema clculos de esforos, que tcnica melhor para equipes que nunca trabalharam com scrum, como realmente saber o quanto a equipe produz e entrega ao final de cada ciclo de desenvolvimento. Na seo 6.4 como inicia o sprint e as melhores prticas para gerenciamento e monitoramento. Na seo 6.5 abordado como cancelar um sprint e o quanto isto traumatizante para equipe, como evitar ou a melhor forma de se conduzir este processo.

6.1 EVANGELIZAO DA EQUIPE

De forma geral, equipes que nunca trabalharam com frameworks para

gerenciamento de projetos, quando so colocados frente a frente com o scrum, tendem a colocar barreiras e impedimentos, devido a sua estrutura de planejamento, gerenciamento, por no conhecer o scrum ou por que a maioria das pessoas no gosta de mudanas ou impem barreira h algo que desconhecem, neste momento chegada a hora de evangelizar a equipe, abordando os principais conceitos, ganho de rentabilidade e visibilidade do trabalho durante projetos que utilizam o framework scrum. O framework scrum to flexvel que pode ser combinado com outros frameworks de desenvolvimento que a equipe j esteja utilizando em seus projetos, desta forma no impedimentos ou barreiras que impeam sua implantao.

34 A curva de aprendizado pequena, porque scrum tem conceitos muito bem definidos, de fcil assimilao e permiti a adaptao para qualquer tipo de equipe e projeto, deixando como foco principal o produto de software a ser desenvolvido e a melhor forma para atingir este objetivo, entregando um produto com qualidade e dentro do escopo definido pelos Stakeholders e patrocinadores do projeto, conforme descrito nos tpicos acima.

6.2 COMO CRIAR SPRINTS

Antes de criar o sprint deve-se ter um Product Backlog, e separar este backlog em sprint Backlog e priorizar as estrias, tarefa a ser realizada pelo product Owner, a partir deste momento podemos montar o sprint e partir para as estimativas no sprint Planning. Deve-se organizar a estrias com ferramentas que foram desenvolvidas para trabalhar com os conceitos do scrum ou que possam ser facilmente adaptadas, que de forma visual, possa ser notado o andamento do sprint, pode-se utilizar uma planilha do excel, quadro branco com postites pregados das estrias, ou softwares especficos, Jira, Versionone, Firescrum, ferramentas que permitem um feedback rpido. Estes softwares, ajudam no agrupamento, gerao de relatrios de desempenho e um histrico maior do escopo, testes e desenvolvimento. Para obter estimativas, pode-se utilizar a tcnica de Planning Poker, um conjunto de cartas que contm uma determinada numerao, que cada membro do scrum team tem em sua posse, que ajuda na definio do esforo que necessrio para a entrega de uma determina estria do sprint Backlog. Baseado-se no conceito de pontos por histria, as estimativas de esforo so

35 individuais e cada membro deve mostrar sua carta, com o esforo que julga necessrio para desenvolver a estria, no momento em que for solicitado, as estimativas menores e maiores para uma estria devem ser justificadas, para que a equipe seja capaz de definir um esforo em comum e para que todos se sintam confortveis para trabalhar na estria que esta sendo estimada. Ao finalizar a estimavas tem-se o quanto de esforo necessrio para concluso do ciclo de vida do sprint, conforme a equipe vai realizando os sprints, as estimativas no decorrer do tempo se tornam cada vez mais assertivas.

6.3 CALCULANDO O ESFORO E VELOCIDADE

Esta etapa do scrum importantssima, e no deve ser definido pelo product Owner ou scrum master, o esforo determinado pela equipe utilizando a unidade de medida Pontos por Estria, que determinar o esforo para uma determinada estria. O scrum master tem a responsabilidade de avaliar as estimativas e a capacidade de entrega da sua equipe, mas de forma alguma deve interferir no esforo estimado pelo scrum team. O product Owner pode no estar de acordo com alguma estimativa, ele pode re priorizar alguma tarefa ou mudar o escopo da estria, ento a equipe pode re estimar o esforo para a estria que sofreu alterao. Pode-se calcular esforo e velocidade, atravs de trs tcnicas o clculo de velocidade, o tempo de ontem ou o clculo simples de recursos. Utilizando a tcnica clculo de velocidade, defini-se a velocidade estimada e quanto estrias pode ser adicionada ao sprint, a velocidade medida atravs da quantidade de trabalho realizado, ao final do sprint feita a comparao entre velocidade

36 estimada e velocidade real, que so efetivamente as estrias terminadas e entregues, estrias no prontas ou no iniciadas ao final do sprint tem valor 0.

A velocidade dependente do grau de experincia do desenvolvedores, estimativas iniciais e problemas que no foram previstos no momento da estimativas, extremamente til quando esta velocidade no sera comparada com sprints anteriores ou futuros. A maneira mais simples de estimar velocidade e capacidade de um equipe que utiliza o framework scrum a tcnica tempo de ontem, que consiste em avaliar os sprints j terminados e a comparao entre estrias do sprint atual com as estrias de sprints anteriores, mas s possvel para equipes que j tenham efetivamente concludo um ciclo sprint, que o nmero de membros e grau de experincia seja o mesmo e forma de trabalho seja inalterada. O clculo simples de recurso, obtido atravs da velocidade do sprint anterior, dividido, pelo nmero de desenvolvedores, multiplicado pelo nmero de dias do ciclo de vida do sprint, por exemplo se temos 4 desenvolvedores e um sprint de 15 dias, tem-se 60 dias de recursos disponveis, e o sprint anterior com uma velocidade de 180 pontos, chega-se ao fator de foco, que auxilia para estimar a capacidade de sprints futuros. Formula: 180 (desenvolvedores x 15) = 3, ento tem-se aqui o fato de foco do desenvolvedores, se o sprint for de 10 dias ento a capacidade mxima da equipe 120 pontos de estria, utilizando como base o fator de foco 3 como citado no exemplo anterior. O Planning Poker uma atividade para que cada membro da equipe, estima a estria de acordo com o seu entendimento e para que no tenha uma combinao prvia do esforo para se concluir uma determinada estria, jogo no qual cada membro recebe um baralho com os pontos por estria que podem atribuir, desta

37 forma provocando uma discusso maior sobre o escopo e as discrepncias existentes, que muito melhor serem descobertas antes e discutidas.

6.4 INICIANDO UM SPRINT

Aps o trmino da reunio de planning, d-se o inicio ao sprint que monitorado, via ferramenta de software apropriada ou quadro branco, colocado sempre em local que fique visvel a todos os participantes da equipe. Recomenda-se ter um grupo de e-mail para realizar a comunicao de fatos importantes para todos os membros scrum team. A qualquer tempo e circunstncia o trabalho total ou parcial para ser atingir o objetivo pode ser sumarizado, utilizando quadro brancos, grficos e planilhas eletrnicas, no intuito de fornecer uma evoluo visual ao membros da equipe de desenvolvimento e stakeholders. O acompanhamento do sprint, reunies dirias so de responsabilidade de todo o scrum team, o foco principal entrega incremental de cada estria, seguindo o escopo, qualidade, prioridade e estimativa. Todo o fato que afete diretamente o ciclo de desenvolvimento deve ser tratado de forma imediata, afim de evitar perca de foco ou atrasos. O scrum master deve estar atento a tudo que pode causar atraso, no desenvolvimento das estrias, analisando as estrias que esto abaixo ou acima das estimativas iniciais, realizando ajustes e eliminando os imprevistos. Deve tambm atuar como um mediador e facilitador entre as demais pessoas e a equipe de desenvolvimento, sempre atento ao andamento do sprint backlog.

38

6.5 CANCELANDO UM SPRINT

No usual, ma o cancelamento de um sprint possvel somente antes que o seu prazo tenha terminado, raramente ocorre devido a sua curta durao, a nica pessoa que pode cancelar um sprint o product Owner, inevitavelmente influenciado pelos stakeholders, equipe de desenvolvimento ou scrum master. Este cancelamento ocorre, quando o objetivo principal do sprint torna-se arcaico, em virtude de mudanas no mercado de tecnologia ou at se o cliente resolve mudar de caminho. O cancelamento de um sprint, consome valores, sejam eles financeiros e de tempo e causa um trauma para equipe envolvida no projeto.

39

7 COMPARAO COM A METODOLOGIAL TRADICIONAL

Este captulo enfoca a metodologia tradicional de desenvolvimento balbrdia e cascata, abordando seus paradigmas e conceitos, realizada tambm uma comparao em relao ao framework scrum. Na seo 7.1 so levantados a essncia do workflow do modelo tradicional e foco nos requisitos no no desenvolvimento do produto de software. Na seo 7.2 aborda-se o modelo balbrdia e sua estrutura defasada. Na seo 7.3 trata-se do ciclo de vida clssico um modelo extremamente utilizado no inicio do desenvolvimento de softwares e que nos dias atuais ainda utilizada em diversas empresas de desenvolvimento de software, levando-se todas as fases de desenvolvimento contemplados por esta metodologia. Na seo 7.4 realizada a comparao entre scrum e os modelos tradicionais, evidenciando e demostrando como scrum extremamente vantajoso em relao ao modelo tradicional.

7.1 MODELOS TRADICIONAIS

Estes modelos surgiram em uma poca que o conceito de desenvolvimento de software totalmente oposto do atual. Nas metodologias tradicionais, busca-se primeiramente mapear todos os problemas e mudanas de requisitos que o produto de software possa sofrer, este esforo totalmente desnecessrio, acarretando custo elevado ao projeto e desperdiando tempo de analistas, para projetos que acabam no sendo finalizados, devido a diversos fatores, como atrasos e mudanas constantes nos requisitos do produto de software durante o seu ciclo de implementao. Nos modelos tradicionais um sistema deve ser totalmente elaborado antes de iniciar qualquer cdigo fonte, pois aps o inicio do desenvolvimento do software, alteraes de requisitos elevariam os custos, alm do problema para alterar cdigos fontes j

40 implementados. Estes modelos em muitas empresas e projetos, acabam se tornando inviveis para o gerenciamento de projetos, devido a quantidade de membros na equipe. Este modelo totalmente focado na documentao e anlise, tornando os projetos demorados, em virtude que se houver mudana nos requisitos uma nova documentao deve ser elaborado para estar em conformidade com os requisitos, desta forma o tempo do projeto vai aumentando, quando finalizados em muitos casos j esto obsoletos, no atendendo mais as necessidade do cliente.

7.2 MODELO BALBRDIA

Este modelo era utilizado no inicio da tecnologia da informao, para determinar o sequenciamento do desenvolvimentos de softwares, no existia nenhum planejamento ou metodologia, tudo era feito com base na conhecimento e experincias do analistas e programadores, no existia nenhum controle sobre os requisitos, funcionais e no funcionais, prazos, escopos e testes. Na atualidade hoje conhecido como modelo Balbrdia o desenvolvimento de software, sem nenhum tipo de projeto ou documentao, tornando difcil o desenvolvimento, manuteno e entendimento dos requisitos. Cada vez mais esta prtica rejeitada no mercado competitivo do desenvolvimento de software, seja ele no mbito de softwares Web, aplicaes comerciais ou aplicaes para desktops. Nas diversas literaturas que foi realizada a leitura e anlise utilizam diversos nomes para demonstrar o mdulo balbrdia, tais como: Modelagem do Ciclo de vida; Paradigmas do Ciclo de vida; Modelo Prescritivo de Processo;

41 Paradigmas do Desenvolvimento de software.

7.3 CICLO DE VIDA CLSSICO CASCATA

Seu fluxo de trabalho define cada etapa do ciclo de vida, tem um fluxo linear, onde uma atividade deve ser completada antes de iniciar a prxima, uma abordagem sequencial ao desenvolvimento de software, este um modelo clssico e antigo, conhecido como ciclo de vida Clssico. Teve como origem os modelos antigos praticados na engenharia de software, na elaborao e desenvolvimento de projetos. O desenvolvimento de software e a tecnologia avanam diariamente, com muitas atividades em paralelo, e este modelo no formato sequencial, traz demora, esperas, e problemas quando existe a necessidade de retornar a etapas j concretizadas. O ciclo de vida clssico tem como base uma sequencia de eventos executados, atrelados ao processo de desenvolvimento em si.

um modelo totalmente inflexvel, que deve ser utilizado somente quando requisitos estiverem bem claros, este modelo dominou o gerenciamento de projetos durante muitos anos, apesar dos problemas e o grande nmero de projetos encerrados antes do trmino devido a sua inflexibilidade e as mtricas utilizadas para clculos de estimativas, normalmente os prazos tambm no so compridos, devido a todo o planejamento ser realizado no comeo do projeto. As etapas descritas abaixo, so as mais relevantes no modelo cascata, mas podem existir sub-etapas, pois existem uma variao grande entre um projeto e outro, mas sempre respeitando o formato sequencial, ou seja s se inicia uma etapa ao trmino da anterior. Pressman (2006) define que o ciclo de vida clssico o paradigma mais utilizando

42 na engenharia de software e tambm o mais antigo e at mesmo os mais fiis defensores deste modelo, passaram a questionar o seu ciclo de etapas e planejamento.

7.3.1 Definio de requisitos

a definio dos requisitos para todas as partes do sistema e continua com a atribuio de vrios subconjuntos de requisitos, as informaes so de suma importncia, em virtude de que o software deve ter interface com outros elementos. Engloba o levantamento de todos os requisitos em nvel de sistema e entendimento do domnio do problema, tudo documentado e depois revisado, procura-se identificar um problema que precisa da tecnologia da informao, para agregar valor e competitividade a um negcio ou novo produto de software. Nesta etapa a intensidade maior para o processo de coleta dos requisitos, totalmente focado no produto de software, os engenheiros e analistas devem entender perfeitamente o domnio da informao, desempenho, funo e interfaces fundamentais para o produto de software, gerando a documentao que revisada com o cliente, nesta fase que que os analistas fazem as atividades de anlise do problema e avaliao e descrio do produto.

7.3.2 Projeto de software

Conforme Pressman (2006), Projeto a representao, de algo que vai ser construdo, a abstrao de algo do mundo real, que ao seu trmino vai ser utilizado de tal forma que melhore a qualidade do que era feito anteriormente sem o objeto de software. Na engenharia de software Projeto de software, uma das fases de levantamento e

43 documentao, que engloba os modelos e entidades que sero desenvolvidas com base nos requisitos de um determinado sistema. Aps o levantamento de requisitos, consegue-se identificar o problema que o produto de software, ser capaz de resolver. Nesta etapa do projeto o objetivo principal representar os requisitos levantados atravs de uma representao de produto de software, com informaes detalhadas para que possa ser implementado, reforando os requisitos: arquitetura do software, projeto da interface e a estrutura de dados. A fase de projeto de software deve ser toda documentada, tendo como base a definio de requisitos, quando mais detalhada esta fase a construo ser mais objetiva no gerando problema de interpretao e atrasos na construo do produto de software.

7.3.3 Desenvolvimento
Conforme Pressman (2006), a etapa de desenvolvimento o ato de transformar, utilizando ferramentas e linguagens de programao, o projeto de software em um produto de software utilizvel pelo cliente. nesta etapa que criado o cdigo fonte do produto de software, em conformidade com o Projeto de software, utilizando linguagem de programao adequado ao projeto. No inicio do desenvolvimento de software utilizava-se linguagens estruturadas, hoje em dia se utilizam-se linguagens orientadas a objetos, no se deve misturar diferentes linguagens no mesmo produto de software, pois isto dificulta a manuteno da aplicao, tambm nesta etapa criada toda a estruturada de dados.

44 Aps o encerramento da etapa de desenvolvimento, segue-se para etapa de testes e avaliao do produto de software gerado, avaliando se o objetivo do produto de software realmente atende aos requisitos anteriormente definidos e se as condies de aceite do produto esto em conformidade.

7.3.4 Testes de sistema

Conforme Pressman (2006), testes so parte do ciclo de execuo de um produto de software, que o principal objetivo avaliar a codificao implementada, com o intuito de encontrar erros de estrutura e lgica. Os testes tm como objetivo principal evitar a m codificao do produto de software, analisando o comportamento da aplicao em relao aos requisitos, para garantir os testes, todos os recursos da aplicao so testados, realizando uma avaliao do comportamento esperado e do comportamento que a aplicao efetivamente produziu, todas as entradas de dados devem ser testadas tambm. A etapa de testes de um produto de software, uma das fases mais criticas, principalmente porque faz todo o controle da qualidade do produto de software, representando a reviso final das fases de anlise, projeto e desenvolvimento. importante que todos os testes sejam documentados, e ser realizado o planejamento prvios de casos de testes para o sistema de acordo com os requisitos funcionais e no funcionais, todos os testes devem estar bem definidos e os objetivos estar em conformidade com o produto de software.

45

7.3.5 Implantao
Conforme Pressman (2006), implantao a entrega do produto de software para o usurio final, a partir deste momento o usurio final vai avaliar o produto de software entregue e se ele realmente atende as suas expectativas e reais necessidades para solucionar o problema levantados na anlise de requisitos. Toda e qualquer modificao deve ser documentada para dar inicio a manuteno do produto de software se este for o caso, neste momento o cliente final pode no estar de acordo com o produto de software entregue, levando ao fracasso do projeto, por falhas em uma das fases do modelo Cascata e em virtude do cliente tem acesso ao produto de software somente ao final do ciclo de implantao. Para o produto de software pode ser necessrio manuteno, quando erros forem encontrados e novas funcionalidades so requisitadas para atender o domnio do problema, toda manuteno de software que o projeto utiliza o modelo Cascata, cada uma das etapas anteriores deve ser repetida.

46

7.4 SCRUM X MODELOS TRADICIONAIS

O quadro 1 apresenta a uma srie de caracterstica do framework Scrum e da Metodologia Tradicional Cascata.
Scrum: - Totalmente adaptvel; - Planejamento contnuo; - Somente a documentao essencial elaborada; - Mudanas rpidas; - Prioriza os aspectos humanos do desenvolvimento; - Totalmente orientado a mudanas; - Requisitos ordenados e formando o Product Backlog; - Incremento do produto de software entregue ao final de cada sprint; - Validao do incremento entregue no ltimo dia do ciclo de vida do sprint; - Projeto utiliza como base o Product Backlog; - Reunies dirias e de planejamento a cada ciclo de vida do sprint; - Feedback e interao constante com o cliente; de software; - Mais satisfao do cliente. Quadro 1: Comparao entre Scrum e Metodologia Tradicional Cascata. Fonte: Elaborao prpria (2012). Metodologia Tradicional Cascata: - No adaptvel; - Totalmente previsvel; - Controle total das mudanas; - Extremamente burocrtico; - Foco total na documentao e todas as fases do projeto; - Planejar muito bem antes; - Entender o domnio do problema; - No possvel gerar incremento de software; - S pode se iniciar uma etapa aps terminar a anterior; - Alto risco do no aceite do cliente ao final do projeto; - No permiti reutilizao; - No tem feedback e interao constante com o cliente; - Entrega somente ao final do projeto.

- Entregas constantes, diminuindo as expectativas do cliente em relao ao produto - Atrasos afetam o projeto como um tudo;

47

8 CONCLUSO

No inicio deste estudo o objetivo foi identificar como melhorar a qualidade de software utilizando scrum para gerenciamento de projetos? Nas pginas anteriores, foi realizada uma comparao com a metodologia tradicional cascata, abordando todas as fases do desenvolvimento de um produto de software, paradigmas e conceitos das metodologias, foi descrito de forma simples, como implementar dentro de equipes o framework scrum, at mesmo em equipes que nunca utilizam nenhuma metodologia para o desenvolvimento de software. Ao final deste estudo, pode-se afirmar e concluir que o framework de desenvolvimento scrum, efetivamente melhora a qualidade do produto de software, em virtude do seu workflow dinmico, por ser incremental, interativo e por ter participao constante dos indivduos envolvidos em todo o processo. Todas as etapas de desenvolvimento de software so avaliadas constantemente desta forma as tomadas de decises so mais assertivas e no tempo certo, com o objetivo de entregar um produto final dentro dos padres de aceite do cliente e mercado consumidor, em conformidade com os requisitos, respeitando prazos e custos pr estabelecidos no inicio do projeto. Com a competitividade entre empresas desenvolvedoras de software e empresas dos diversos setores de tecnologia, a procura por reduo de custos, aliada a necessidade de desenvolver produtos de softwares cada vez mais rpido e com qualidade, a metodologia de desenvolvimento aplicada sem dvida alguma, faz grande diferena dentro desta indstria. As boas prticas devem ser seguidas para que empresas e negcios possam se sobressair perante os seus concorrentes, empresas com mtodos de desenvolvimento que no tem como foco o feedback constante ao cliente, uma integrao com a equipe de analistas, desenvolvedores e qualidade, esto sujeita ao fracasso dos projetos e consequentemente prejuzos extremos.

48 Utilizando de forma correta o framework scrum, todos os processos so organizados de forma fcil e dinmica, em todas reas das empresas, facilitando o processo de comunicao, especificao e entrega de um produto de forma organizada. A metodologia scrum totalmente flexvel e pode ser utilizada em conjunto com outros mtodos geis existentes no mercado, tambm no existe uma frmula mgica de implementao ou conduta, mas sim princpios bsicos que ajudam na implantao do framework dentro das equipes e no decorrer do tempo equipes mais maduras podem perfeitamente definir novos princpios e prticas para melhorar o scrum, desta forma tornando o processo evolutivo e em conformidade com as necessidades das equipes e produto de software que esta sendo desenvolvido. As metodologias utilizadas para gerenciamento do desenvolvimento de software so importantes tal como o processo de codificao e a evoluo das linguagens de desenvolvimento, as metodologias no devem ficar alheias os avanos tecnolgicos e o aumento do grau de experincia de todos os envolvidos no processo, este trabalho faz estudo do workflow padro do framework Scrum, mas vrios requisitos do framework podem ser modificados e analisado os seus impactos, positivos no gerenciamento de desenvolvimento de software, como por exemplo, sprints de uma semana e no duas, a quebra de estrias e micros tarefas, a participao das reas envolvidos na solicitaes como parte do processo de validao do produto e qualidade, deve ser realizada a comparao com outros metodologias de desenvolvimento, tais como Crystal, Lean, XP, RUP e CMMI. software com acompanhamento do cliente, atingindo as metas, reduzindo custos e prazos de

49

REFERNCIAS

SIMS, Chris; JOHNSON, Hillary Louise. The Elements of Scrum. Califrnia: Dymaxicon, 2007. KNIBERG, Henrik. SCRUM AND XP FROM THE TRENCHES. Estocolmo: Lightning Source, 2007. COHN, Mike. Desenvolvimento de software com Scrum - Aplicando Mtodos geis com Sucesso. So Paulo: Bookman, 2011. SCHWABER, Ken. Agile Project Management With Scrum. Washington: Microsoft Pr, 2004. SCHWABER, Ken; Sutherland, Jef. O guia definitivo do Scrum, as regras do jogo. Jul. 2011. Scrum.org, p.5 p.14. SURDEK, Steffan; WOODWARD, Elizabeth, GANIS Matthew. A Practical Guide to Distributed Scrum. Boston: Ibm Press, 2010. FOWLER, Martin. The New Methodology. MartinFowler, Chicago, dec. 2005: Disponvel em: Acesso em: fev. 2012. VODDE, Bas; LAMAN, Cralg. Scaling Lean & Agile Development-Thinking And Organizational Tools For Large-scale Scrum. Massachusetts: Addison-wesley Professional, 2009. PRESSMAN, Roger. Engenharia de software. So Paulo: McGraw-Hill Brasil, 2006. PICHLER, Roman. Gesto de Produtos com Scrum - 2011. So Paulo: Campus, 2011. PHAM, Andrew; PHAM, Phuong Van. Scrum em Ao. So Paulo: Novatec, 2011.