Page 1

ESCOLA SUPERIOR ABERTA DO BRASIL – ESAB CURSO DE PÓS-GRADUAÇÃO 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 Pós-Graduação em Engenharia de Sistemas, da Escola Superior Aberta do Brasil, como requisito para obtenção do Título em Engenharia de Sistemas, sob orientação 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

Agradeço a minha esposa, pelo incentivo, força e por entender minha ausência em vários momentos e que esta comigo nos momentos bons e ruins. Também agradeço a Deus e ela, por trazer nosso filho com saúde, um presente que recebi durante este projeto. Agradeço a todos professores, que elaboraram o material do curso, que forneceu uma base sólida para o conhecimento da matéria. Ao meu orientador pela competência. A minha mãe, pois tudo que sou devo a ela.


“A estratégia sem tática é o caminho mais lento para a vitória. Tática sem estratégia é o ruído antes da derrota”. Sun Tzu


RESUMO Este trabalho tem como objetivo principal demonstrar os fundamentos e características do framework scrum para gerenciamento de projetos e suas vantagens em relação 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 prática para gerenciamento de projetos, que tem como base um processo incremental e interativo, ideal para projetos que estão em constantes mudanças, sejam tecnológicas ou de requisitos de sistemas, utilizando o framework scrum de forma correta, empresas e profissionais têm melhores resultados, tanto no que tange prazos, custos e satisfação final do cliente. Através da pesquisa, pretende-se chegar a uma conclusão que favoreça o framework scrum, demostrando suas TimeBox, papéis 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. Gerência de Projetos. Métodos Ágeis. Métodos Tradicionais.


SUMÁRIO 1 INTRODUÇÃO.....................................................................................................9 2 FUNDAMENTAÇÃO TEÓRICA..........................................................................13 2.1 PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE.............................13 2.2 MÉTODOS ÁGEIS............................................................................................15 3 SCRUM................................................................................................................17 3.1 FRAMEWORK SCRUM....................................................................................17 3.2 SPRINT - CICLO DE DESENVOLVIMENTO INCREMENTAL........................18 3.3 PAPÉIS 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 REUNIÕES..........................................................................................................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 EVANGELIZAÇÃO DA EQUIPE.......................................................................33 6.2 COMO CRIAR SPRINTS..................................................................................34 6.3 CALCULANDO O ESFORÇO E VELOCIDADE...............................................35 6.4 INICIANDO UM SPRINT..................................................................................37 6.5 CANCELANDO UM SPRINT............................................................................37 7 COMPARAÇÃO COM A METODOLOGIAL TRADICIONAL.............................39 7.1 MODELOS TRADICIONAIS.............................................................................39 7.2 MODELO BALBÚRDIA.....................................................................................40 7.3 CICLO DE VIDA CLÁSSICO CASCATA...........................................................41


7.3.1 Definição 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 Implantação..................................................................................................44 7.4 SCRUM X MODELOS TRADICIONAIS............................................................46 8 CONCLUSÃO......................................................................................................47


9

1 INTRODUÇÃO Exposição do assunto: O desenvolvimento de software se tornou uma das mais importantes atividades econômicas do nosso tempo, assim, gerando uma das maiores indústrias, do século XXI. Gerando milhões de empregos ao redor do mundo, através desta indústria são criados diversos produtos de software, dos quais muitos são de suma importância para nós, seja para o nosso estilo de vida, saúde, educação, comércio, segurança, ciência e outras áreas da vida. O produto de software, criado através das diversas técnicas de desenvolvimento de software e linguagens de programação, tornou-se um dos maiores valores de propriedade intelectual. Este mercado, que sempre esta em constantes mudanças e evoluindo rapidamente, é um dos setores econômicos mais competitivos, para os profissionais da área e empresas, neste âmbito o mercado consumidor desta indústria, inevitavelmente vai distingui as melhores práticas e as piores, exigindo cada vez mais produtos de softwares melhores, com entregas rápidas, e quer realmente atendam as necessidades dos clientes, consumidores deste produto. Existem diversas metodologias de desenvolvimento de softwares, mas sem dúvida alguma os métodos ágeis para desenvolvimento é uma marco para empresas e para os profissionais que estão envolvidos no produto de software, acelerando os prazos para desenvolvimento dos projetos, aumentando a satisfação 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, não é construído sempre da mesma maneira, havendo

mudanças

dentro

das

equipes,

mudanças

de

pensamentos

de

desenvolvimento de software e de tecnologias. É importantíssimo reconhecer, como sendo um processo relativo, que é composto do imprevisto e que tem ferramentas de ação corretiva para serem utilizadas dentro do processo de desenvolvimento do produto de software. Metodologias de desenvolvimento ágeis tem como principal característica, serem extremamente adaptáveis, levando em consideração o tamanho da equipe, do projeto, nível de conhecimento técnico dos envolvidos no processo de criação do produto de software, problemas que podem ocorrer durante o desenvolvimento, sem a necessidade de avaliar tudo anteriormente, ao inicio do projeto. Avaliações prévias aumentam o custo do projeto e o prazo, além de tornar muito difícil qualquer alteração de planejamento no decorrer do projeto, salientando, que o problema não é a mudança, porque ela vai ocorrer em qualquer projeto e metodologia que esteja sendo aplicada, a grande questão é como lidar com estas mudanças, 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

clássica,

muitos

produtos

de

software

são

desenvolvidos por completo, e só na entrega acaba-se descobrindo que o produto não 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 mudanças se tornam tão complexas que acabam ficando inviáveis, 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 mudanças nos requisitos, e o framework scrum também trabalha com esta premissa, um ponto que


11 também a destacar-se, nas metodologias de desenvolvimento ágeis são as entregas constantes dos artefatos do produto de software, assim o cliente final não 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 não estiver dentro das suas expectativas, as mudanças são 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 aplicação para diversos tipos de projetos e equipes de tamanhos e níveis de conhecimento técnico diferentes. Abordando seu desempenho para gerenciamento de projetos em diversos níveis, em que soluções devem ser desenvolvidos, com agilidade, qualidade, dentro do escopo, prazo e qualidade definidos, demostrando suas vantagens em relação ao método tradicional de gerenciamento de projetos. - Compreender a dinâmica 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; - Construção de artefatos empíricos. Delimitação: Este trabalho tem como objetivo principal abordar a metodologia de desenvolvimento de software ágil framework scrum, que é utilizado por diversas empresas da indústria de tecnologia, para gerenciamento dos projetos de desenvolvimento de softwares e suas vantagens em relação à Metodologia Tradicional de desenvolvimento de software.. Metodologia de Pesquisa: A pesquisa foi toda desenvolvida com base na leitura e análise de livros, artigos, periódicos abordando as diferentes visões sobre scrum, os benefícios alcançados, as diferentes formas de se implementar scrum em equipes


de

desenvolvimento,

a

comparação

com

a

metodologia

tradicional

12 de

desenvolvimento e porque scrum, faz tanto sucesso e os projetos são cada vez mais bem sucedidos, trazendo ganho de performance dos profissionais envolvidos, melhorando a comunicação entre as áreas envolvidas no projeto e o recursos financeiros são melhores aproveitados evitando gastos desnecessários.


13

2 FUNDAMENTAÇÃO TEÓRICA Este capítulo aborda, como é implementado o processo de desenvolvimento de software, através da engenharia de software. Na seção 2.1, abordam-se as características do processo de desenvolvimento de software, fundamentos essenciais envolvidos no processo como requisitos, implementação, validação e manutenção. Com base nos conceitos da seção 2.1 a seção 2.2 aborda os métodos ágeis, destacando suas características e levantado as principais metodologias ágeis de desenvolvimento mais conhecidas no mercado e praticadas. A seção 2.3 faz um breve levantamento histórico sobre o surgimento das metodologias ágeis, destacando seus principais mentores e suas diretrizes. Na seção 2.4 tem-se a transcrição do manifesto ágil.

2.1 PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE Processo de software são 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 existência de diversas metodologias para gerenciamento de desenvolvimento de softwares, mas todas devem ter conceitos fundamenteis, especificação do produto de software, implementação, validação e manutenção 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 criação, mesmo que o cliente tenha convicção do produto de software que ele necessita, para esta etapa o profissional dever ter larga experiência (PRESSMAN, 2006). Na etapa de especificação, é elaborado o documento que vai descrever exatamente o produto de software que deve ser implementado (PRESSMAN, 2006).


14 Projeto e implementação é a etapa onde o produto de software em si é desenvolvido de acordo com as especificações e utilizando uma linguagem de programação (PRESSMAN, 2006). Validação do produto de software desenvolvido é verificado se realmente o software atende todas as especificações e funcionalidades levantadas (PRESSMAN, 2006). Manutenção do produto de software é a continuidade do produto de software com relação a sua evolução e necessidade de novas funções ou mudanças 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 manutenção é 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 correções de requisitos que não foram levantados ou que deixaram questões 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 documentação, antes de desenvolver qualquer linha de código (PICHLER, 2011). A engenharia de software é responsável por tratar todos os aspectos do desenvolvimento do produto de software, desdes as etapas iniciais dos requisitos até a Manutenção do produto de software, também é parte importante para a engenharia de software, as metodologias, ferramentas e métodos 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 práticas que foram utilizadas


15 por outros indivíduos, empresas e que estes projetos foram realizados com sucesso (COHN, 2011). É utopia afirmar a existência de um método ideal, tudo depende do ambiente de desenvolvimento, projeto, pessoas e produto, existem métodos que funcionam melhor e trazem resultados importantes para o gerenciamento de projetos (PRESSMAN, 2006).

2.2 MÉTODOS ÁGEIS São métodos de desenvolvimento que permitem a equipe de programadores foco total no produto de software, em virtude de aplicações que estão em constantes mudanças nos requisitos, a documentação não é parte mais importante do sistema, estes métodos tem como principal abordagem a interatividade para especificação, desenvolvimento e entrega dos incrementos do produto de software, assim gerando uma divisão do sistema em sub sistemas, garantido a entrega de um produto de software funcional de maior produtividade e qualidade (PHAM, 2011). As metodologias ágeis são utilizadas para gerencia de projetos com a adoção de um conjunto de técnicas, princípios e boas práticas para gerenciamento de projetos (SCHWABER, 2004). FOWLER (2005), afirma para

os métodos ágeis, as mudanças são parte do

processo e bem-vindas, os métodos ágeis se tornam mais fortes e adaptáveis dentro das organizações e no decorrer deste processo evolutivo. Os métodos ágeis quebram paradigmas tradicionais do gerenciamento de projetos, em relação como deve-se tratar as mudanças no escopo do projeto no decorrer dos projetos (KNIBERG, 2007). Métodos tradicionais tratam o escopo sempre de forma fixa e não são flexíveis as


16 mudanças de escopo, sempre controlando o máximo possível, para que não haja este fluxo nos projetos em qual o método tradicional é aplicado (SURDEK; WOODWARD; GANIS, 2010). Todas as metodologias ágeis um dos princípios mais importantes é ter um escopo manipulável e ser flexível, segundo o manifesto ágil, “Mudança de requisitos são bem vindas, mesmo em estágios tardios do desenvolvimento” (SIMS; JOHNSON, HILLARY, 2007). Atualmente existem diversas metodologia de desenvolvimento, que tem como foco o manifesto ágil, as mais importantes são: scrum, eXtreme Programming, Feature Driven Development, Crystal, DSDM e Lean. Estas metodologias tem seus princípios e técnicas e a forma como gerenciam projetos, mas todas em comuns seguem os princípios do manifesto ágil (VODDE; LAMAN, 2009). Scrum é a mais importante e mais utilizada dentro das organizações de diferentes seguimentos e tamanhos, principalmente em empresas do mercado de Internet, um mercado em constante evolução que exige adaptação rápida e desenvolvimento ágil para suas plataformas que estão em constantes mudanças e evoluindo diariamente, sejam elas, de comércio eletrônico, Social Mida, entretenimento e informação (VODDE; LAMAN, 2009).


17

3 SCRUM

Este capítulo tem como foco principal abordar o processo de desenvolvimento de software, gerenciado através do framework scrum utilizando o conceitos de desenvolvimento incremental e interativo. Na seção 3.1 destacando o conceito de product backlog e stakeholders relacionando aos requisitos de software para construção do produto de software. Na seção 3.2 é feita uma análise do ciclo de desenvolvimento do produto de software dentro do framework scrum, priorização, planejamento e entrega. Na seção 3.3 encontra-se a estrutura dos papéis destacando todos os envolvidos durante o ciclo de vida do desenvolvimento. Seção 3.4 são destacadas as principais atribuições do product owner. Seção 3.5 encontrase as tarefas do scrum master e relacionamos ao product owner, para o trabalho em conjunto. Na seção 3.6 é abordado o scrum team, suas funções e grau de independência e sua relação 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 inspeção e visibilidade, implantando regras e práticas, os controles não significam controle para criar o que foi planejado, mais sim controlar o processo que orienta o trabalho em progressão 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 interação, 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 término da interação. As pessoas envolvidas, fazem o melhor para executar o desenvolvimento da interação e


18 conseguir entregar o incremento da funcionalidade do produto de software, para os stakeholders, avaliarem e solicitarem modificações posteriores nos momentos certos (PICHLER, 2011). O Product Backlog é o coração do scrum, normalmente é uma lista de requisitos, estórias, coisas, funcionalidades que o cliente deseja. A cada nova interação o time deve avaliar os requisitos, as tecnologias envolvidas e domínio técnico da equipe, para que haja a divisão do trabalho, para construir e entregar o produto de software dentro dos padrões 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, é crítico e indispensável, através do planejamento a equipe tem uma visão do produto de software ou partes dele

que

será

desenvolvido,

neste

momento

são

levantadas

dúvidas,

questionamentos sobre as tarefas que compõem o Product Backlog, a equipe deve colher todas as informações suficientes para o desenvolvimento do trabalho (KNIBERG, 2007) . O product Owner é o responsável por priorizar e fornecer a lista de requisitos (Product Backlog) sejam eles funcionais ou não funcionais, qualificando as tarefas por ordem de importância e prioridade, que agreguem mais valor ao produto de software (PHAM, 2011). Como boa prática o framework scrum recomenda a divisão do Product Backlog, em releases, em muitos casos o conteúdo, as prioridades e agrupamento do Product Backlog podem sofrer mudanças a partir do momento que o projeto se inicia. Estas mudanças nada mais são que alterações nos requisitos de negócios e rapidamente a equipe deve transformá-los em um produto de software (PHAM, 2011) .


19 Normalmente cada sprint deve ter a duração entre duas e quatro semanas, todos os stakeholders (pessoas envolvidas no projeto), devem participar da reunião de sprint Planning Meeting, reunião 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 três variáveis, escopo, importância e estimativa (PICHLER, 2011) . Qualidade é ponto importante, quando se trata de scrum seja ela interna ou externa, qualidade externa é o que é visto pelos usuários, qualidade interna refere-se a questões que não são observados pelo usuário, tal como estrutura do código, testes de unidade, refatoração de código (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 ocasiões o product Owner tentar espremer a estimativa do scrum team, isto não deve comprometer o código, 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 também garante não trazer novos requisitos para serem desenvolvidos durante o ciclo do sprint Backlog. Requisitos funcionais e não 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 horários para as reuniões diárias (PHAM, 2011) . A partir do momento que a equipe começar a trabalhar no sprint Backlog, ela deve manter o foco no mesmo a fim de atingir o objetivo firmado, novos requisitos funcionais ou não funcionais não deverão ser aceitos (KNIBERG, 2007) .


20 Diariamente o scrum team realiza a reunião chamada Daily, com duração 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 reúnem para o Retrospective Meeting, no qual é avaliada toda a pratica do scrum e o que precisa ser feito para melhorar o próximo sprint (SCHWABER, 2004) . A junção de todas estas práticas, fazem parte do ciclo de desenvolvimento dentro do framework scrum, no que contempla as diferentes etapas de um sprint, não sendo mandatória nenhuma etapa, mas sim é considerada como boa prática dentro do framework scrum, para atingir os objetivos (SCHWABER, 2004).

3.3 PAPÉIS NO SCRUM

O framework scrum tem como base uma estrutura iterativa e incremental, no qual se apoio em três papéis de suma importância para a metodologia, o product Owner, o scrum master, o scrum team, a responsabilidade de todo o projeto é compartilhada por estes papéis, eles então formam os pilares de sustentação do framework scrum, as equipes se organizam de forma dinâmica e são capazes de exercer diversas funções (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) . É responsável por apresentar, maximizar e representar os interesses dos stakeholders no projeto define e gerenciar os requisitos do projeto, através do Product Backlog, deve expressar ordenar, priorizar e garantir que os itens do Backlog estão descritos de forma clara (SCHWABER, 2004) . O product Owner é o responsável pelo produto de software entregue aos stakeholders, toda e qualquer mudança no Product Backlog deve ser aprovada pelo product Owner, para o sucesso do projeto. Toda a companhia dever respeitar suas tomadas de decisão e jamais a equipe deve trabalhar em requisitos diferentes dos aprovados e priorizados por ele (KNIBERG, 2007) .

3.5 SCRUM MASTER É o responsável por todo o processo scrum, garantir sua aplicação, por disseminá-lo para todas as pessoas envolvidas no projeto, é um líder 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 prática do framework scrum, afim de tornar uma metodologia consistente dentro da equipe (KNIBERG, 2007) . O scrum master tem o papel também importante que é ajudar, todos aqueles fora da equipe scrum, a entender as interações com a equipe, que trazem benefícios e quais não trazem, protegendo a equipe e assegurando o não compromisso em relação as tarefas que não podem ser realizadas durante o sprint (SURDEK, 2010) .


22 O scrum master fornece vários serviços para todos os envolvidos no projeto, como o product Owner o scrum team e a para a Companhia, realizando as comunicações dos avanços 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 empírico de produtos (SIMS, 2007) .

3.6 SCRUM TEAM É a equipe de desenvolvimento dentro de um determinado projeto que utilizado o framework scrum para gerenciamento, responsável por estima de esforço para cada história do Product Backlog, desenvolver as funcionalidades do produto de software e o sucesso do projeto, é composta por product Owner, scrum master e o próprio 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 não muito grande para não que seja necessário uma coordenação muito grande, tem a capacidade de ser auto gerenciável, são multifuncionais e escolhem a forma que o trabalho vai ser realizado, dentro das equipes scrum não se tem a necessidade da divisão funcional (COHN, 2011). Usando como base papéis tradicionais, todos os indivíduos trabalham em parceria e são responsáveis por concluir o trabalho que comprometeram-se em cada sprint plainning, durante cada interação não há mudanças de membros dentro de uma equipe scrum (COHN, 2011). Equipes que utilizam o framework scrum, têm como principais características, produtividade, criatividade e são extremamente flexíveis, sempre estão produzindo entregas incrementais, que dão garantia a um versão útil do produto de software (COHN, 2011) .


23

4 ARTEFATOS E INDICADORES

Este capítulo abordará todos os artefatos do framework scrum e os indicadores. Na seção 4.1 listam-se os artefatos e o que trazem de positivo para o processo de gerenciamento de projetos através do framework scrum. Na seção 4.2 aborda-se o product backlog e como estruturar um backlog, responsabilidade de priorização e estimativas e adequação durante o ciclo de desenvolvimento. Na seção 4.3, como organizar o sprint backlog utilizando como base o product backlog, atualização, andamento do sprint backlog, visibilidade e objetivo do sprint, que sempre deve ser definido antes do seu inicio. Na seção 4.4 traz o burndown chart, como utilizar e melhores práticas para monitoramento e andamento do sprint backlog.

4.1 ARTEFATOS Os artefatos demonstram o trabalho de várias maneiras, são indicadores durante todo o ciclo de desenvolvimento, são benéficos por oferecer transparência e oportunidades para acompanhamento e adaptação, são projetados para dar mais transparência 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 não funcionais, melhorias e consertos que podem ser necessários para o produto de software, é a fonte de mudanças 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 são compostos por descrição, prioridade e estimativa de tempo (KNIBERG, 2007). Esta lista nunca é completa no inicio do projeto, sendo formado apenas através de requisitos conhecidos no inicio, desta forma é dinâmica, 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 necessárias desta forma é importantíssimo a adequação do Product Backlog (KNIBERG, 2007).

O framework scrum não recomenda e não determina um padrão 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 técnica de listar cada item como uma estória, podendo ser inseridas em cartões 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 realimentação para o Product Backlog, requisitos não vão parar de mudar, a tecnologia não vai parar de evoluir tornando esta lista mais completa e longa, desta forma o Product Backlog é um artefato em constante mudança (VODDE, 2009).

4.3 SPRINT BACKLOG É um conjunto de estórias do Product Backlog, um plano com detalhes que demonstram as mudanças em progresso e que possam ser entendidas no scrum


25 diário, são selecionadas com base nas prioridades estipuladas pelo product Owner (PHAM, 2011). É uma previsão da equipe de desenvolvedores sobre as funcionalidades e o trabalho necessário para realizar o desenvolvimento, testes e entrega da estória, inclui também a estratégia 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 visível todo o trabalho da equipe de desenvolvimento, identifica o que é necessário para atingir o objetivo do sprint, a equipe de desenvolvimento, deve somente se comprometer com as estórias 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 gráfico BurnDown Chart (KNIBERG, 2007). Assim toda a equipe pode acompanhar o andamento e avanços das estórias, refletindo as estórias prontas e as estórias a serem desenvolvidas, desta maneira demonstrando o quanto de tempo ainda é necessário para concluir as estórias em aberto e se a equipe está no prazo, a frente do tempo estimado ou atrasada em relação as estimativas de tempo para cada estória (KNIBERG, 2007). Durante o ciclo de vida de um sprint, é possível ter situações não comuns, e que devem ser evitadas para que os projetos que utilizam o framework scrum para gerenciamento possam ser bem sucedidos, que é a inserção de estórias dentro de um sprint Backlog em andamento, estas estórias são tratadas como INTRUDERS, e se faz necessário estimar novamente a quantidade de estórias do sprint Backlog, para que a equipe não seja sobrecarregada e consecutivamente o objetivo do sprint não seja cumprido (KNIBERG, 2007).


26

4.4 BURNDOWN CHART Com o Burndown Chart, é possível realizar o monitoramento do progresso do projeto, exibir no decorrer de um determinado período de tempo o quanto de trabalho que ainda deve ser realizado, desta forma permitindo a todos os membros da equipe acompanhar a evolução 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 número de dias existentes para o fim do sprint Backlog, somando-se a quantidade de horas para terminar cada estória do sprint Backlog, chegamos ao resultado final de quantas horas ainda são necessárias para finalizar o ciclo de vida do sprint, a medida que as estórias são finalizadas no decorrer dos dias do ciclo de vida do sprint, a linha base do gráfico vai decrescendo até chegar ao número de horas zero (KNIBERG, 2007). No eixo Y do gráfico Burndown Chart, têm-se os número de horas que foram estimadas para o ciclo de vida do sprint, enquanto no eixo X o número de dias do ciclo de vida do sprint (KNIBERG, 2007). Com base no gráfico, pose-se visualizar de forma clara a velocidade de desenvolvimento das estórias do sprint Backlog dentro do ciclo de vida do sprint, este gráfico sofre oscilações durante o sprint e isto permite a tomada de decisões, em virtude da velocidade de desenvolvimento e entregas estarem muito abaixo ou muito acima do esperado para a conclusão do sprint, para a montagem do gráfico e base de cálculo das estimativas das estórias finais de semana e feriados não são contabilizados,

pois

raramente

trabalhos

são

executadas

nestes

períodos

(KNIBERG, 2007). Dois pontos que não podem ser deixados de lado, é se a linha de progresso esta muito acima da linha base, temos um problema no sprint, que podem ser estórias


27 mau estimadas, itens não planejados foram colocados nos sprint BackLog, e então deve haver uma readequação, se a linha de progresso estiver muito abaixo a estimativa

da

estórias

podem

estar

erradas

também,

ou

a

equipe

de

desenvolvimento tem capacidade para um sprint maior do que fora definido neste ponto cabe ressaltar a importância de incluir novas estórias no sprint BackLog, que a equipe seja capaz de finalizar durante o período restante do ciclo de vida do sprint. A equipe deve sempre seguir a ordem da estórias conforme a prioridade definida pelo product Owner, estórias de prioridade mais alta devem sempre ser as primeiras a serem desenvolvidas e entregues (KNIBERG, 2007).


28

5 REUNIÕES

Este capítulo aborda as reuniões que fazem parte do framework, destacando as características de cada uma delas e seus objetivos. Na seção 5.1 referencia-se a reunião mais importante do scrum o sprint plainning meeting, que engloba a definição dos escopos do sprint backlog, destacando a participação dos stakesholders. Na seção 5.2 é especificada a reunião diária durante o ciclo de vida de um sprint e como conduzi-la. Na seção 5.3 aborda-se a reunião que marca o fim do ciclo de vida de um sprint, demostrando o que realmente foi entregue ao final do ciclo de desenvolvimento. Na seção 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 reunião 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 reunião o product Owner fala sobre as estórias e a ordem de prioridade de cada uma delas, a equipe interage realizando questionamentos sobre as tarefas, para que possa analisar tecnicamente a solução e o esforço que vai ser gasto para cada desenvolvimento, todas as estórias discutidas no sprint Planning Meeting, faram parte do sprint Backlog (PICHLER, 2011). Se o sprint Backlog for muito grande em relação a velocidade da equipe, se faz necessário a descrição e discussão técnica somente das estórias definidas com a maior prioridade, ficando para o próximo sprint Planning Meeting as tarefas de prioridade menor (PICHLER, 2011).. Na segunda parte o scrum team, se reúne para efetivamente define o que será


29 necessário para realização das estórias, 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 descrição do que deve ser alcançado ao final do ciclo de desenvolvimento, as estimativas de esforço não devem sofrer influência dos stakeholders e do Product Owner, cabe ao Scrum team definir de forma mais assertiva o possível o grau de complexidade das estórias (KNIBERG, 2007). Durante o período ciclo de vida do sprint, os membros da equipe tem a liberdade de escolher quais estórias desejam trabalhar, estórias que ocupam o espaço de desenvolvimento maior que um dia, são quebradas em sub tarefas, para sempre ter um incremento novo da estória principal (PHAM, 2011). Diariamente é realizada a reunião Daily scrum Meeting, para uma breve discussão sobre o andamento das estórias, será visto um pouco mais sobre esta reunião nos tópicos a seguir (PHAM, 2011) . Após o ciclo de vida do sprint, ele deve ser avaliado de acordo com o objetivo traçado, na reunião de sprint Review Meeting, analisando os pontos positivos, negativos, todas as lições devem ficar no histórico 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 horário e local, é indicado realizar durante o período matutino, todos os participantes scrum team ou Ouvintes devem ficar em pé e por convenção não deve passar de 15 minutos (KNIBERG, 2007). Nessa reunião todos os membros do scrum team, relatam o que fizeram no dia


30 anterior e o que pretendem fazer no dia, em relação as estórias do sprint, os ouvintes não são autorizados a falar no Daily scrum Meeting, através da Daily scrum Meeting é possível, identificar impedimentos que bloqueiam o desenvolvimento e conclusão de qualquer estória que compõem o Product Backlog do sprint (VODDE, 2009). O scrum master é responsável por tratar os impedimentos de forma rápida e objetiva para que a equipe possa avançar com as estórias, com os relatos do que foi feito, o que vai ser feito hoje e se há impedimentos (KNIBERG, 2007). É possível realizar priorização de estórias dentro de um dia de trabalho e a equipe acaba com uma visão mais ampla do andamento do sprint, em relação as estórias já finalizadas e as que ainda devem ser desenvolvidas (KNIBERG, 2007). Na reunião de Daily scrum Meeting, não se deve resolver problemas, se por ventura algum problema for levantado, ele dever ser discutido fora da reunião, somente com os membros do scrum team envolvidos na estória 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, não dever ser encarada como uma ferramenta para atualização de status do scrum team para o scrum master, mas sim para interação entre as pessoas e a proliferação do conhecimento entre scrum team, scrum master e Ouvintes participantes do Meeting, existem ferramentas apropriadas que podem fornecem atualização 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, reunião para demostrar as estórias concluídos durante o sprint, que são exibidas em um formato


31 pré-produção das funcionalidades incrementais do produto de software (KNIBERG, 2007). Esta reunião tem como participantes o scrum master, scrum team, product Owner e os StakeHolders, no decorrer da reunião o sprint finalizado é avaliado, no qual é levantado se o objetivo do sprint foi atingido, se as estórias inseridas do Product Backlog para o Product Backlog do sprint estão de acordo com os requisitos e se de uma forma geral a equipe conclui o ciclo de vida do sprint de forma satisfatória, analisando se os objetivos foram atingidos de forma satisfatória 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 reunião para realizar uma retrospectiva sobre o sprint passado, realizada em uma sala fechada e todos os participantes sentados, não deve durar mais que 2 duras horas, de forma alguma esta reunião 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 reunião, deve-se identificar e expôr o que deve ser melhorado no processo do ciclo de vida do sprint, observar se todas as práticas do scrum realmente estão sendo seguidas pelo membros da equipe, desta reunião sempre surgem novas ideias, sugestões e novas práticas, que podem melhorar o processo de desenvolvimento e boas práticas do scrum (KNIBERG, 2007). É responsabilidade do scrum master exibir o sprint Backlog e com a ajuda do scrum team, faz uma breve explanação do sprint, velocidade estimada da estórias e velocidade real ao concluir cada estória, analisando se a diferença entre as duas


32 velocidades é grande, tenta-se achar o que causou tamanha discrepância (COHN, 2011). A diferença entre velocidade estimada, velocidade atingida, pode ser causada por erros de estimativa, interferência externa, como por exemplo desenvolvedores sendo requisitados a realizar tarefas que não fazem parte do ciclo de vida do sprint, de forma alguma isto pode ocorrer, conforme a equipe vai adquirindo experiência no produto de software e com o framework scrum erros de estimativa são 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 capítulo abordamos como implementar scrum em equipes que nunca utilizaram

métodos

ágeis

de

desenvolvimento

ou

outra

ferramenta

para

gerenciamento de projetos. Na seção 6.1 destaca-se como evangelizar o time e a flexibilidade do scrum, que pode ser combinado com outros métodos de desenvolvimento, sua curva de aprendizado estritamente pequena e fácil. Na seção 6.2, defini-se como criar sprints, organizar o backlog e o jogo plainning poker para torna as estimativas mais dinâmicas e atraentes para os participantes. Na seção 6.3, entra-se no tema cálculos de esforços, que técnica é 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 seção 6.4 como inicia o sprint e as melhores práticas para gerenciamento e monitoramento. Na seção 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 EVANGELIZAÇÃO DA EQUIPE De

forma

geral,

equipes

que

nunca

trabalharam

com

frameworks

para

gerenciamento de projetos, quando são colocados frente a frente com o scrum, tendem a colocar barreiras e impedimentos, devido a sua estrutura de planejamento, gerenciamento, por não conhecer o scrum ou por que a maioria das pessoas não gosta de mudanças ou impõem 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 é tão flexível que pode ser combinado com outros frameworks de desenvolvimento que a equipe já esteja utilizando em seus projetos, desta forma não impedimentos ou barreiras que impeçam sua implantação.


34 A curva de aprendizado é pequena, porque scrum tem conceitos muito bem definidos, de fácil assimilação e permiti a adaptação 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 tópicos 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 estórias, 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 estórias 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 estórias, ou softwares específicos, Jira, Versionone, Firescrum, ferramentas que permitem um feedback rápido. Estes softwares, ajudam no agrupamento, geração de relatórios de desempenho e um histórico maior do escopo, testes e desenvolvimento. Para obter estimativas, pode-se utilizar a técnica de Planning Poker, um conjunto de cartas que contém uma determinada numeração, que cada membro do scrum team tem em sua posse, que ajuda na definição do esforço que é necessário para a entrega de uma determina estória do sprint Backlog. Baseado-se no conceito de pontos por história, as estimativas de esforço são


35 individuais e cada membro deve mostrar sua carta, com o esforço que julga necessário para desenvolver a estória, no momento em que for solicitado, as estimativas menores e maiores para uma estória devem ser justificadas, para que a equipe seja capaz de definir um esforço em comum e para que todos se sintam confortáveis para trabalhar na estória que esta sendo estimada. Ao finalizar a estimavas tem-se o quanto de esforço é necessário para conclusão 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 ESFORÇO E VELOCIDADE Esta etapa do scrum é importantíssima, e não deve ser definido pelo product Owner ou scrum master, o esforço é determinado pela equipe utilizando a unidade de medida “Pontos por Estória”, que determinar o esforço para uma determinada estória. 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 esforço estimado pelo scrum team. O product Owner pode não estar de acordo com alguma estimativa, ele pode re priorizar alguma tarefa ou mudar o escopo da estória, então a equipe pode re estimar o esforço para a estória que sofreu alteração. Pode-se calcular esforço e velocidade, através de três técnicas o cálculo de velocidade, o tempo de ontem ou o cálculo simples de recursos. Utilizando a técnica cálculo de velocidade, defini-se a velocidade estimada e quanto estórias pode ser adicionada ao sprint, a velocidade é medida através da quantidade de trabalho realizado, ao final do sprint é feita a comparação entre velocidade


36 estimada e velocidade real, que são efetivamente as estórias terminadas e entregues, estórias não prontas ou não iniciadas ao final do sprint tem valor 0.

A velocidade é dependente do grau de experiência do desenvolvedores, estimativas iniciais e problemas que não foram previstos no momento da estimativas, extremamente útil quando esta velocidade não 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 técnica tempo de ontem, que consiste em avaliar os sprints já terminados e a comparação entre estórias do sprint atual com as estórias de sprints anteriores, mas só é possível para equipes que já tenham efetivamente concluído um ciclo sprint, que o número de membros e grau de experiência seja o mesmo e forma de trabalho seja inalterada. O cálculo simples de recurso, é obtido através da velocidade do sprint anterior, dividido, pelo número de desenvolvedores, multiplicado pelo número 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 disponíveis, 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, então tem-se aqui o fato de foco do desenvolvedores, se o sprint for de 10 dias então a capacidade máxima da equipe é 120 pontos de estória, 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 estória de acordo com o seu entendimento e para que não tenha uma combinação prévia do esforço para se concluir uma determinada estória, é jogo no qual cada membro recebe um baralho com os pontos por estória que podem atribuir, desta


37 forma provocando uma discussão maior sobre o escopo e as discrepâncias existentes, que é muito melhor serem descobertas antes e discutidas.

6.4 INICIANDO UM SPRINT Após o término da reunião de planning, dá-se o inicio ao sprint que é monitorado, via ferramenta de software apropriada ou quadro branco, colocado sempre em local que fique visível a todos os participantes da equipe. Recomenda-se ter um grupo de e-mail para realizar a comunicação de fatos importantes para todos os membros scrum team. A qualquer tempo e circunstância o trabalho total ou parcial para ser atingir o objetivo pode ser sumarizado, utilizando quadro brancos, gráficos e planilhas eletrônicas, no intuito de fornecer uma evolução visual ao membros da equipe de desenvolvimento e stakeholders. O acompanhamento do sprint, reuniões diárias são de responsabilidade de todo o scrum team, o foco principal é entrega incremental de cada estória, 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 estórias, analisando as estórias que estão abaixo ou acima das estimativas iniciais, realizando ajustes e eliminando os imprevistos. Deve também 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 Não é usual, ma o cancelamento de um sprint é possível somente antes que o seu prazo tenha terminado, raramente ocorre devido a sua curta duração, 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 mudanças 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 COMPARAÇÃO COM A METODOLOGIAL TRADICIONAL

Este capítulo enfoca a metodologia tradicional de desenvolvimento balbúrdia e cascata, abordando seus paradigmas e conceitos, é realizada também uma comparação em relação ao framework scrum. Na seção 7.1 são levantados a essência do workflow do modelo tradicional e foco nos requisitos não no desenvolvimento do produto de software. Na seção 7.2 aborda-se o modelo balbúrdia e sua estrutura defasada. Na seção 7.3 trata-se do ciclo de vida clássico 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 seção 7.4 é realizada a comparação entre scrum e os modelos tradicionais, evidenciando e demostrando como scrum é extremamente vantajoso em relação 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 mudanças de requisitos que o produto de software possa sofrer, este esforço é totalmente desnecessário, acarretando custo elevado ao projeto e desperdiçando tempo de analistas, para projetos que acabam não sendo finalizados, devido a diversos fatores, como atrasos e mudanças constantes nos requisitos do produto de software durante o seu ciclo de implementação. Nos modelos tradicionais um sistema deve ser totalmente elaborado antes de iniciar qualquer código fonte, pois após o inicio do desenvolvimento do software, alterações de requisitos elevariam os custos, além do problema para alterar códigos fontes já


40 implementados. Estes modelos em muitas empresas e projetos, acabam se tornando inviáveis para o gerenciamento de projetos, devido a quantidade de membros na equipe. Este modelo é totalmente focado na documentação e análise, tornando os projetos demorados, em virtude que se houver mudança nos requisitos uma nova documentação deve ser elaborado para estar em conformidade com os requisitos, desta forma o tempo do projeto vai aumentando, quando finalizados em muitos casos já estão obsoletos, não atendendo mais as necessidade do cliente.

7.2 MODELO BALBÚRDIA Este modelo era utilizado no inicio da tecnologia da informação, para determinar o sequenciamento

do

desenvolvimentos

de

softwares,

não

existia

nenhum

planejamento ou metodologia, tudo era feito com base na conhecimento e experiências do analistas e programadores, não existia nenhum controle sobre os requisitos, funcionais e não funcionais, prazos, escopos e testes. Na atualidade hoje é conhecido como modelo Balbúrdia o desenvolvimento de software, sem nenhum tipo de projeto ou documentação, tornando difícil o desenvolvimento, manutenção e entendimento dos requisitos. Cada vez mais esta prática é rejeitada no mercado competitivo do desenvolvimento de software, seja ele no âmbito de softwares Web, aplicações comerciais ou aplicações para desktops. Nas diversas literaturas que foi realizada a leitura e análise utilizam diversos nomes para demonstrar o módulo balbúrdia, 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 CLÁSSICO 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 próxima, é uma abordagem sequencial ao desenvolvimento de software, este é um modelo clássico e antigo, é conhecido como ciclo de vida Clássico. Teve como origem os modelos antigos praticados na engenharia de software, na elaboração e desenvolvimento de projetos. O desenvolvimento de software e a tecnologia avançam 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 clássico tem como base uma sequencia de eventos executados, atrelados ao processo de desenvolvimento em si.

É um modelo totalmente inflexível, 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 número de projetos encerrados antes do término devido a sua inflexibilidade e as métricas utilizadas para cálculos de estimativas, normalmente os prazos também não são compridos, devido a todo o planejamento ser realizado no começo do projeto. As etapas descritas abaixo, são as mais relevantes no modelo cascata, mas podem existir sub-etapas, pois existem uma variação grande entre um projeto e outro, mas sempre respeitando o formato sequencial, ou seja só se inicia uma etapa ao término da anterior. Pressman (2006) define que o ciclo de vida clássico é o paradigma mais utilizando


42 na engenharia de software e também o mais antigo e até mesmo os mais fiéis defensores deste modelo, passaram a questionar o seu ciclo de etapas e planejamento.

7.3.1 Definição de requisitos É a definição dos requisitos para todas as partes do sistema e continua com a atribuição de vários subconjuntos de requisitos, as informações são de suma importância, em virtude de que o software deve ter interface com outros elementos. Engloba o levantamento de todos os requisitos em nível de sistema e entendimento do domínio do problema, tudo é documentado e depois revisado, procura-se identificar um problema que precisa da tecnologia da informação, para agregar valor e competitividade a um negócio 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 domínio da informação, desempenho, função e interfaces fundamentais para o produto de software, gerando a documentação que é revisada com o cliente, é nesta fase que que os analistas fazem as atividades de análise do problema e avaliação e descrição do produto.

7.3.2 Projeto de software Conforme Pressman (2006), Projeto é a representação, de algo que vai ser construído, é a abstração de algo do mundo real, que ao seu término 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 documentação, que engloba os modelos e entidades que serão desenvolvidas com base nos requisitos de um determinado sistema. Após 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 através de uma representação de produto de software, com informações detalhadas para que possa ser implementado, reforçando 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 definição de requisitos, quando mais detalhada esta fase a construção será mais objetiva não gerando problema de interpretação e atrasos na construção do produto de software.

7.3.3 Desenvolvimento Conforme Pressman (2006), a etapa de desenvolvimento é o ato de transformar, utilizando ferramentas e linguagens de programação, o projeto de software em um produto de software utilizável pelo cliente. É nesta etapa que é criado o código fonte do produto de software, em conformidade com o Projeto de software, utilizando linguagem de programação adequado ao projeto. No inicio do desenvolvimento de software utilizava-se linguagens estruturadas, hoje em dia se utilizam-se linguagens orientadas a objetos, não se deve misturar diferentes linguagens no mesmo produto de software, pois isto dificulta a manutenção da aplicação, também nesta etapa é criada toda a estruturada de dados.


44 Após o encerramento da etapa de desenvolvimento, segue-se para etapa de testes e avaliação do produto de software gerado, avaliando se o objetivo do produto de software realmente atende aos requisitos anteriormente definidos e se as condições de aceite do produto estão em conformidade.

7.3.4 Testes de sistema Conforme Pressman (2006), testes são parte do ciclo de execução de um produto de software, que o principal objetivo é avaliar a codificação implementada, com o intuito de encontrar erros de estrutura e lógica. Os testes têm como objetivo principal evitar a má codificação do produto de software, analisando o comportamento da aplicação em relação aos requisitos, para garantir os testes, todos os recursos da aplicação são testados, realizando uma avaliação do comportamento esperado e do comportamento que a aplicação efetivamente produziu, todas as entradas de dados devem ser testadas também. 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 revisão final das fases de análise, projeto e desenvolvimento. É importante que todos os testes sejam documentados, e ser realizado o planejamento prévios de casos de testes para o sistema de acordo com os requisitos funcionais e não funcionais, todos os testes devem estar bem definidos e os objetivos estar em conformidade com o produto de software.


45

7.3.5 Implantação Conforme Pressman (2006), implantação é a entrega do produto de software para o usuário final, a partir deste momento o usuário 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 análise de requisitos. Toda e qualquer modificação deve ser documentada para dar inicio a manutenção do produto de software se este for o caso, neste momento o cliente final pode não 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 implantação. Para o produto de software pode ser necessário manutenção, quando erros forem encontrados e novas funcionalidades são requisitadas para atender o domínio do problema, toda manutenção 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 série de característica do framework Scrum e da Metodologia Tradicional Cascata. Scrum:

Metodologia Tradicional Cascata:

- Totalmente adaptável;

- Não é adaptável;

- Planejamento contínuo;

- Totalmente previsível;

- Somente a documentação essencial é elaborada;

- Controle total das mudanças;

- Mudanças rápidas;

- Extremamente burocrático;

- Prioriza os aspectos humanos do desenvolvimento;

- Foco total na documentação e todas as fases do projeto;

- Totalmente orientado a mudanças;

- Planejar muito bem antes;

- Requisitos ordenados e formando o Product Backlog;

- Entender o domínio do problema;

- Incremento do produto de software entregue ao final de cada sprint;

- Não é possível gerar incremento de software;

- Validação do incremento entregue no último dia do ciclo de vida do sprint;

- Só pode se iniciar uma etapa após terminar a anterior;

- Projeto utiliza como base o Product Backlog;

- Alto risco do não aceite do cliente ao final do projeto;

- Reuniões diárias e de planejamento a cada ciclo de vida do sprint;

- Não permiti reutilização;

- Feedback e interação constante com o cliente;

- Não tem feedback e interação constante com o cliente;

- Entregas constantes, diminuindo as expectativas do cliente em relação ao produto - Atrasos afetam o projeto como um tudo; de software; - Mais satisfação do cliente. Quadro 1: Comparação entre Scrum e Metodologia Tradicional Cascata. Fonte: Elaboração própria (2012).

- Entrega somente ao final do projeto.


47

8 CONCLUSÃO

No inicio deste estudo o objetivo foi identificar como melhorar a qualidade de software utilizando scrum para gerenciamento de projetos? Nas páginas anteriores, foi realizada uma comparação 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 dinâmico, por ser incremental, interativo e por ter participação constante dos indivíduos envolvidos em todo o processo. Todas as etapas de desenvolvimento de software são avaliadas constantemente desta forma as tomadas de decisões são mais assertivas e no tempo certo, com o objetivo de entregar um produto final dentro dos padrões 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 redução de custos, aliada a necessidade de desenvolver produtos de softwares cada vez mais rápido e com qualidade, a metodologia de desenvolvimento aplicada sem dúvida alguma, faz grande diferença dentro desta indústria. As boas práticas devem ser seguidas para que empresas e negócios possam se sobressair perante os seus concorrentes, empresas com métodos de desenvolvimento que não tem como foco o feedback constante ao cliente, uma integração com a equipe de analistas, desenvolvedores e qualidade, estão sujeita ao fracasso dos projetos e consequentemente prejuízos extremos.


48 Utilizando de forma correta o framework scrum, todos os processos são organizados de forma fácil e dinâmica, em todas áreas das empresas, facilitando o processo de comunicação, especificação e entrega de um produto de

software com

acompanhamento do cliente, atingindo as metas, reduzindo custos e prazos de forma organizada. A metodologia scrum é totalmente flexível e pode ser utilizada em conjunto com outros métodos ágeis existentes no mercado, também não existe uma fórmula mágica de implementação ou conduta, mas sim princípios básicos que ajudam na implantação do framework dentro das equipes e no decorrer do tempo equipes mais maduras podem perfeitamente definir novos princípios e práticas 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 são importantes tal como o processo de codificação e a evolução das linguagens de desenvolvimento, as metodologias não devem ficar alheias os avanços tecnológicos e o aumento do grau de experiência de todos os envolvidos no processo, este trabalho faz estudo do workflow padrão do framework Scrum, mas vários 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 não duas, a quebra de estórias e micros tarefas, a participação das áreas envolvidos na solicitações como parte do processo de validação do produto e qualidade, deve ser realizada a comparação com outros metodologias de desenvolvimento, tais como Crystal, Lean, XP, RUP e CMMI.


49

REFERÊNCIAS

SIMS, Chris; JOHNSON, Hillary Louise. The Elements of Scrum. Califórnia: Dymaxicon, 2007. KNIBERG, Henrik. SCRUM AND XP FROM THE TRENCHES. Estocolmo: Lightning Source, 2007. COHN, Mike. Desenvolvimento de software com Scrum - Aplicando Métodos Ágeis com Sucesso. São 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: Disponível 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. São Paulo: McGraw-Hill Brasil, 2006. PICHLER, Roman. Gestão de Produtos com Scrum - 2011. São Paulo: Campus, 2011. PHAM, Andrew; PHAM, Phuong Van. Scrum em Ação. São Paulo: Novatec, 2011.

monografia  

scrum desenvolvimento ag

Advertisement