MODELO DE DESENVOLVIMENTO ÁGIL SCRUM

MODELO DE DESENVOLVIMENTO ÁGIL SCRUM

CEETEPS CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA FATEC DE TAUBATÉ HABILITAÇÃO: ANÁLISE E DESENVOLVIMENTO DE SISTEMAS TEMA MODELO DE DESENVOLVIMENTO ÁGIL: Scrum Anderson Henrique Botelho da Silva Bruno de Almeida Pereira Thiago Gonçalves Prudêncio Victor Cunha Romeiro Taubaté SP 2014

SUMÁRIO 1. INTRODUÇÃO...5 2. OBJETIVO...6 3. DESENVOLVIMENTO...7 3.1 SCRUM...7 3.1.1 HISTÓRIA...8 3.1.2 CICLO...8 3.2 RESPONSABILIDADES...8 3.2.1 SCRUM MASTER...9 3.2.2 SCRUM TEAM...9 3.2.3 PRODUCT OWNER... 10 3.3 ETAPAS DO SPRINT... 10 3.3.1 SPRINT PLANNING... 10 3.3.2 DAILY SCRUM... 11 3.3.3 SPRINT REVIEW... 11 3.3.4 SPRINT RETROSPECTIVE... 12 3.4 ARTEFATOS DO SCRUM... 12 3.4.1 PRODUCT BACKLOG... 12 3.4.1.1 PLANNING POKER... 13 3.4.2 SPRINT BACKLOG... 14 3.4.3 IMPEDIMENT BACKLOG... 14 3.4.4 BURNDOWN CHART... 15 3.5 O PROCESSO SCRUM... 16 4. APLICAÇÃO... 17 4.1 EXEMPLO DE SOFTWARE... 17 4.1.1 PAPÉIS... 17 4.1.2 ESCOPO... 17 4.1.3 PRODUCT BACKLOG... 18 4.1.4 REUNIÃO DE PLANEJAMENTO DE SPRINT... 18 4.1.5 INÍCIO DO SPRINT... 19

4.1.5.1 REUNIÕES DIÁRIAS SCRUM... 20 4.1.5.2 BURNDOWN CHART... 20 4.1.6 REVISÃO FINAL DO SPRINT... 21 5. CONCLUSÃO... 23 5.1 CONSIDERAÇÕES FINAIS... 23 REFERÊNCIAS... 24

5 1. INTRODUÇÃO Com o passar dos anos o desenvolvimento de software cresceu de forma muito acelerada, principalmente com o fato das ferramentas da informática serem mais acessíveis e estarem presente em toda parte. Este crescimento fez surgir uma variedade de estratégias de desenvolvimento de software.estas estratégias têm como objetivo organizar o projeto de software e o time desenvolvimento, aumentando a eficácia e diminuindo os prazos e custos destes mesmos projetos de software. Algumas técnicas foram criadas para terminar os softwares rapidamente de maneira eficaz, este tipo de técnica foi categorizada com o nome de Desenvolvimento Ágil, onde a velocidade e o dinamismo são os pontos principais. Nos modelos de Desenvolvimento Ágil, o principal objetivo é obter um produto rapidamente e com qualidade. Para isto, as metodologias que participam desta categoria de modelos se caracterizam por um gerenciamento de projeto em que um líder de time esteja frequentemente organizando, inspecionando, apoiando e garantindo que o time esteja bem, ao mesmo tempo que os resultados do projeto de software vão atendendo as necessidades do cliente. Implementar uma metodologia ágil requer uma mudança de mentalidade nas pessoas que participam do processo de desenvolvimento. Em certos casos, a mudança de papéis e as novas responsabilidades podem gerar desconforto nos participantes durante a implantação do modelo. O scrum é um método de desenvolvimento ágil e seu principal objetivo é fazer transparecer a eficácia relativa das suas práticas de desenvolvimento para que você possa melhorá-las, enquanto provê um framework dentro do qual produtos complexos podem ser desenvolvidos de maneira rápida e eficaz.

6 2. OBJETIVO Realizar uma pesquisa com o intuito de aprender e compreender o método ágil scrum, e analisar como ele pode ser importante dentro de uma organização, visando às áreas onde deve ser investido o Método Ágil Scrum.

7 3. DESENVOLVIMENTO Scrum é um framework para desenvolver e manter produtos complexos. Esta definição consiste em papéis, eventos, artefatos e as regras do Scrum que unem os demais e os mantém integrados. 3.1 SCRUM Scrum é uma estrutura processual (framework) para suportar o desenvolvimento e manutenção de produtos complexos. O Scrum consiste em Equipes do Scrum associadas a seus papéis, eventos, artefatos e regras. Cada componente dentro do framework serve a um propósito específico e é essencial para o uso e o sucesso do Scrum. Scrum é fundamentado nas teorias empíricas de controle de processo, ou empirismo. O empirismo afirma que o conhecimento vem da experiência e de tomada de decisões baseadas no que é conhecido. O Scrum emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos. Três pilares apoiam a implementação de controle de processo empírico: transparência, inspeção e adaptação. Transparência Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados. Está transparência requer aspectos definidos por um padrão comum para que os observadores compartilharem um mesmo entendimento do que está sendo visto. Inspeção Os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção ao objetivo, para detectar indesejáveis variações. Esta inspeção, não deve no entanto, ser tão frequente que atrapalhe a própria execução das tarefas. As inspeções são mais benéficas quando realizadas de forma diligente por inspetores especializados no trabalho a se verificar. Adaptação Se um inspetor determina que um ou mais aspectos de um processo desviou para fora dos limites aceitáveis, e que o produto resultado será inaceitável, o

8 processo ou o material sendo produzido deve ser ajustado. O ajuste deve ser realizado o mais breve possível para minimizarmais desvios. 3.1.1 HISTÓRIA Tem função intermediária e instrumental, ou seja, tratam dos aspectos concretos que serão abordados na pesquisa e que irão contribuir para se atingir o objetivo geral. É com base nos objetivos específicos que o pesquisador irá orientar o levantamento de dados e informações. 3.1.2 CICLO O Scrum tem o progresso de desenvolvimento baseado em iterações com duração entre duas e seis semanas, chamadas de Sprints. A primeira etapa dentro do Sprint é a reunião de planejamento onde o time do scrum e o cliente definem o que será implementado.a próxima etapa é a de execução, onde o time detalha as tarefas necessárias para implementar o que foi solicitado pelo cliente e posteriormente inicia a execução das mesmas. Ao final do Sprint é realizada uma reunião para a validação da entrega, o time de desenvolvimento realiza reuniões diárias para averiguar a o progresso do projeto. Ao final do Sprint é realizada uma reunião para a validação da entrega onde o cliente e quem mais tiver interesse no produto pode verificar se o objetivo do Sprint foi atingido. Logo após, o time de desenvolvimento organiza uma reunião onde o Sprint é avaliado sob a perspectiva de processo, time ou produto, quais foram os acertos e os erros com o objetivo de melhorar o processo de trabalho. 3.2 RESPONSABILIDADES Em um Scrum Team os participantes são chamados porcos. Qualquer outro indivíduo é chamada de galinha. Galinhas não podem dizer aos porcos como eles devem fazer seu trabalho. Galinhas e porcos vêm da seguinte história:

9 Uma galinha e um porco estão juntos quando a galinha diz: Vamos abrir um restaurante! O porco reflete e então diz: Como seria o nome desse restaurante? A galinha diz: Presunto com Ovos! O porco diz: Não, obrigado, eu estaria comprometido, mas você estaria apenas envolvida! No desenvolvimento do produto, não só cada um têm suas responsabilidades, mas o time como um todo às possui. Entretanto há certas diferenças nas responsabilidades individuais, estas que serão explicadas nos ícones abaixo. 3.2.1 SCRUM TEAM A junção da Equipe de Desenvolvimento, do Product Owner e do Scrum Master, forma o time scrum(scrum team). Esse que é altamente capacitado a tomar decisões entre si sem depender de terceiros, decisões essas que ao decorrer e final do projeto se tornam eficientes e eficazes. O modelo de equipe utilizado no scrum induz os participantes ao aprimoramento da flexibilidade, criatividade e produtividade tanto individual quanto do grupo. Os resultados do produto são entregues de forma iterativa por uma versão funcional(executável) em curtos períodos de tempo, especificados no início, para que mudanças possam ser incrementadas e o produto melhorado. Os times são geralmente compostos por 5/7 pessoas, pois com um número inferior talvez não haja total interação entre os membros, e com um número maior de integrantes é necessária uma coordenação maior e o dinamismo das decisões seja afetado. 3.2.2 SCRUM MASTER Membro guia, não gerenciador, responsável por manter o scrum team aderido às regras e práticas do scrum a fim de alcançar a eficiência máxima.

10 O mestre pode ser qualquer um dos integrantes, exceto o dono do produto, entretanto caso participe ativamente do sprint podem haver pequenos conflitos nas decisões de realização de tarefas. 3.2.3 PRODUCT OWNER O dono do produto tem papel fundamental em seu desenvolvimento, ele será o único membro responsável no gerenciamento do Backlog. É dele o dever de mostrar claramente ao team como deve ser o resultado final do produto. 3.3 ETAPAS DO SPRINT É na Sprint que o projeto começa a ser desenvolvido, projeto esse que é composto por diversas sprints seqüenciais, de maneira que ao término de uma, outra já é planejada e iniciada. São por meio de reuniões que as metas e meios de chegar ao resultado são especulados. Cada sprint tem por volta de um mês de duração e ao final de cada mês um executável do produto deve estar nas mãos do product owner. A fim de obter resultados sempre mais precisos e confiáveis a sprint é divida em etapas que são: Sprint Planning; Daily Scrum; Sprint Review; Sprint Retrospective; 3.3.1 SPRINT PLANNING Etapa de planejamento da sprint. É nela que a iteração, a maneira repetitiva e eficiente de entrega, é planejada. A reunião deve durar 8 horas exatas para sprints de um mês e durações proporcionalmente menores para sprints menores. Ela é divida em duas partes, cada uma com 4 horas duração, que são:

11 Parte 1 - O que será Concluído nessa Sprint? Nesta parte o Product Owner apresenta para todos do scrum team os itens de Backlog do produto para que todos possam colaborar com o entendimento do trabalho que será realizado na sprint. Cabe a equipe de desenvolvimento avaliar o que pode ser feito dos itens de Backlog do produto durante a sprint. O time Scrum determina o objetivo a ser alcançado, a meta, fornecendo apoio aos desenvolvedores na incrementação. Parte 2 De que maneira a meta será atingida? Aqui são traçados os meios com os quais os incrementos serão feitos. A equipe de desenvolvimento que é auto-organizável se organiza para realizar a demanda do Backlog, isso acontece tanto durante a reunião de planejamento quanto durante a sprint, caso necessário. Portanto a equipe ao final desta etapa já deve ser capaz de descrever ao Scrum Master e ao Product Owner como pretende alcançar o objetivo devido na primeira parte. 3.3.2 DAILY SCRUM Trata-se de uma reunião diária com duração de 15 minutos, na qual cada membro de cada time explica: O que fez; O que pretende fazer e Quais obstáculos enfrentou. É o scrum master que guia esse evento time-boxed, assim tornando a equipe ainda mais comunicativa e criativa visando completar o trabalho do Backlog da sprint. 3.3.3 SPRINT REVIEW Ao término de cada sprint é feita uma reunião com intuito de revisar todo o trabalho feito durante o período em que essa esteve ativa. A reunião corre de maneira informal com partipação de toda equipe, o que inclui: Scrum Master, Product Owner, Scrum Team.

12 Cada um demonstra o que foi feito, quais problemas ocorreram e se algo pode ser mudado. E é a partir dessa reunião que tem duração fixa de 4 horas, que planos para próximas sprints já começam a ser criados. 3.3.4 SPRINT RETROSPECTIVE Após a reunião de revisão, inicia-se a reunião de retrospectiva, com duração fixa de 3 horas, guiada pelo Scrum Master com a finalidade de observar tanto os pontos de falhas, os quais podem ser melhorados quantos os que já correram bem para que a próxima sprint se torne ainda mais eficiente e eficaz. 3.4 ARTEFATOS DO SCRUM 3.4.1 PRODUCT BACKLOG De forma direta, o Product Backlog contém as funcionalidades de negócio, em formato de lista, sejam estes os requisitos técnicos e também erros de sistema que, após definidos, devem ser aprimorados. É importante ressaltar que o Product Backlog de forma alguma é "encadeado", ou seja, necessita de evolução contínua. Os motivos podem surgir baseados em novos requisitos de negócio, pela manutenção técnica da aplicação ou seu refatoramento. O Product Backlog deve estar pronto antes de um Sprint Planning, apesar de não fazer parte do Sprint Planning a usabilidade do mesmo para a definição das tarefas de priorização completa e estimativa pode fazer com que o Sprint Planning leve dias ao invés de horas para ser concluído. Sua principal função é manter suas prioridades listadas e exibir de forma clara e objetiva à equipe de desenvolvimento as perspectivas do projeto. O Product Backlog torna-se um dos principais desafios do Scrum, é essencial que o mesmo esteja organizado e relacionado com as prioridades da aplicação, para o devido cumprimento de suas histórias. Toda história que constar no Product Backlog tem como objetivo possuir valor de negócio e sua complexidade associada. O valor de negócio é estipulado pelo Product Owner e o segundo fator pelo time de desenvolvimento, que é reavaliado constantemente durante o decorrer do desenvolvimento.

13 A elaboração dos valores de negócio é extremamente complexa. É importante que estas tenham o enfoque em pontos críticos e essenciais, ao invés de ressaltar características irrelevantes para o resultado final. Pode-se exemplificar esta etapa de forma simples, imagina-se que o Product Owner precise construir uma casa e para esta tarefa receba 10.000 (dez mil) pontos de complexidade. Como seu volume de pontos é limitado, pelo lógica os valores serão gastos aos itens imprescindíveis (Base, Paredes, Telhado, Sistemas Hidráulico e Elétrico), deixando assim menos pontos aos itens que neste exemplo seriam menos importantes (Pintura, Mobília, etc.). Este modelo facilita, já que o Product Owner possui limite para gastar, assim como um orçamento limitado. 3.4.1.1 PLANNING POKER O Planning Poker se torna um exercício, realizado em conjunto do Product Backlog, podendo ser realizado em grupo, que utiliza da sequência de FIbonacci (1, 2, 3, 5, 8, 13, 21,...) para a avaliação de complexidade. A lógica que se associa a utilização desta sequência está na diferença existente entre cada uma, permitindo a visão clara do quão complexa é cada uma das funcionalidades. Através das diferenças, pode-se mapear melhor as incertezas associadas a avaliação. Inicia-se selecionando o item considerado por todos como o mais fácil de implementar, associando a ele o menor valor na sequência. Posteriormente, avaliase os demais itens considerando sua complexidade relativa a de menor valor. Os participantes interagem definindo nota de complexidade para cada história, caso o consenso seja firmado a complexidade é validada e atribuída a história. No caso de divergência, é aberto debate entre os membros que mostraram maior diferença e cada um pode expor seus pensamentos. A seguir, é realizada nova rodada até que se encontre o consenso. Cabe a responsabilidade ao Scrum Master intervir caso não se consiga chegar ao consenso da complexidade de uma história. É necessário que a equipe mantenha o Product Backlog com estimativas coerentes à sua velocidade de desenvolvimento. Por esta razão a cada Sprint a equipe deve separar uma parcela de tempo para rever o Backlog do produto e caso seja necessário realizar novas estimativas ou corrigir estimativas já realizadas utilizando experiência do projeto corrente.

14 3.4.2 SPRINT BACKLOG O Sprint Backlog é criado com o uso das histórias do Product Backlog e que serão utilizadas durante o Sprint. Durante o Sprint Planning as histórias recebidas pelo time são desmembradas em tarefas menores, com o máximo de um dia, para serem acompanhadas pelo time ao longo do Sprint. Além disso, deve-se redigir as histórias e registradas para o Sprint, gerando novas tarefas à equipe. Este processo recebe o nome de Sprint Backlog, dele fazem parte todas as ações necessárias para que o objetivo do Sprint seja alcançado com sucesso. Vale lembrar que ao longo do Sprint, podem surgir novas tarefas, seja porque foram esquecidas ou determinada tarefa exigirá que seja dividida, integrando o Sprint e o Sprint Backlog. Ao longo do Sprint, caso todas as tarefas que compõe o Sprint Backlog tenham sido realizadas é possível que a equipe, em consenso do Product Owner, adicione mais histórias do Product Backlog ao Sprint Backlog. Caso isto ocorra, a equipe deve assumir o compromisso de que tudo esteja finalizado ao fim do Sprint. Tanto o Sprint Backlog quanto o Burndown Chart devem estar em constante acompanhamento pela equipe. Apenas com este olhar crítico é que a equipe pode prever com antecedência alguma possibilidade de não conseguir entregar histórias do Sprint. É importante ressaltar que as histórias do Backlog geralmente não devem ser desenvolvidas em paralelo. Isto só deve acontecer se já não existirem mais atividades na história anterior que não possam ser feitas. O objetivo de se tentar evitar o paralelismo visa chegar ao fim do Sprint com todas as histórias quase prontas, mas não completamente finalizadas. No caso perde-se o conceito de velocidade da equipe, visto que não se pode estimar o tempo real que será exigido para terminar as tarefas finais em paralelo. 3.4.3 IMPEDIMENT BACKLOG A constituição do impediment Backlog se baseia na lista de impedimentos que podem ocasionar problemas na entrega, seja de todo o Projeto ou de um Sprint. Costuma se relacionar a tarefas não realizadas pela equipe por pendências

15 externas. Este item é tratado diretamente pelo Scrum Master, que possui o papel de facilitador na resolução dos impedimentos. Tarefas simples como a instalação de um servidor ou de um software realizados por um help desk podem fazer parte do Impediment Backlog, itens que fazem parte de rotinas dos desenvolvedores e estão diretamente ligadas a entregas. É comum a formação de equipes, constituída por Gerentes e Diretores, com objetivo de auxiliar na resolução de problemas da companhia. A formação desta equipe é trabalhosa e geralmente difícil, porém em vários casos se mostra como a melhor escolha na busca de resultados a longo prazo. É comum parar muitos de dentro da empresa problemas recorrentes não serem vistos e passarem despercebidos, relacionados a estrutura. Esta equipe possui o papel de intervir, e com o auxilio da maturidade mútua, quebrar tais paradigmas e torná-la uma empresa ágil. 3.4.4 BURNDOWN CHART O acompanhamento das tarefas realizadas pelo time é gerenciado pelo próprio time. É importante lembrar que o time não deve ser influenciado por eventos externos, sendo assim, o acompanhamento diário de tarefas é realizado atrás do Daily Meeting. Durante os Daily Meetings a participação ativa é constituída por time e Scrum Master, podendo haver participantes externos, porém apenas como ouvintes. Tendo concluído as perguntas e respostas do Daily Meeting, as tarefas antes distribuídas são finalizadas e novas são repassadas ao time. Esta distribuição é feita pelo time e a seleção é realizada seguindo a ordem de execução previamente estabelecida pelo próprio time. Utilizando as informações de tarefas dos dias anteriores, criasse um gráfico para demonstrar visualmente a completude das tarefas do Sprint e seu andamento em relação ao projeto todo planejado.

16 3.5 O PROCESSO SCRUM Como anteriormente descrito, o processo Scrum é constituído por três etapas: o início, marcado pela reunião de todo o planejamento, o ciclo de desenvolvimento (etapa denominada Sprint) e sua conclusão (reunião de revisão do Sprint). Abaixo pode-se observar um exemplo do que se constitui o processo Scrum.

17 4. APLICAÇÃO 4.1 EXEMPLO DE SOFTWARE Com o objetivo de demonstrar todo o processo, utilizaremos um exemplo de projeto a ser desenvolvido voltado ao streamming de vídeo pela internet. 4.1.1 PAPÉIS De forma prática, são descriminados os membros correspondentes a seus devidos papeias no processo da criação da nossa ferramenta, portanto, conforme o processo Scrum define: Proprietário do Produto: Anderson Scrum Master: Victor Time de Desenvolvimento: Thiago e Bruno 4.1.2 ESCOPO Encerrada a etapa de definição de papéis, o Proprietário do Produto (Product Owner) Anderson, após várias reuniões entre as equipes empresariais, define-se o escopo do projeto, seus primeiras histórias. "O sistema de Streamming de vídeo funcionará através da internet, de maneira que usuários externos possam ter acesso, criar seus cadastros, armazenar, compartilhar e gerenciar seus vídeos. Suas principais funcionalidades serão a de transformar o vídeo bruto recebido em um arquivo ágil e leve, com armazenagem de baixo custo e que se mostre rápido na visualização através da Internet; cadastro de acesso; comentários voltados ao vídeo em questão pelos usuários; notas para os vídeos; notas para os vídeos; interface para gerenciamento de conta; sistema de busca; sistema que reconheça o áudio do vídeo (para proteção contra direito autorais); proteção contra SPAM; sistema para criação de legendas próprias para os vídeos; área para interação (grupos) de usuários e vídeos."

18 4.1.3 PRODUCT BACKLOG Após o levantamento das funcionalidades, o proprietário do produto Anderson constrói o Product Backlog para priorizar as mesmas de acordo com sua importância para o cliente e seu valor de mercado. Nesse exemplo, será usado a seguinte notação: Quanto maior o número de prioridade maior será sua prioridade. Ex: 100 - prioridade máxima, 99 - prioridade menor,..., 1 - prioridade quase inexistente. Funcionalidade Prioridade Modelagem de Dados 100 Cadastro e gerenciamento de usuários 99 Conversão de vídeo para visualização na internet 98 Layout 97 Comentário para os vídeos 96 Proteção contra SPAM 95 Sistema de legendas para vídeos 94 4.1.4 REUNIÃO DE PLANEJAMENTO DO SPRINT É realizada a Reunião de Planejamento, em que o proprietário do produto Anderson apresenta aos outros da equipe SCRUM e todos definem a quantidade de horas a ser trabalhada em cada etapa, levando em consideração os aspectos técnicos. Funcionalidade Prioridade Horas Modelagem de Dados 100 40 Cadastro e gerenciamento de usuários Conversão de vídeo para visualização na internet 99 32 98 96 Layout 97 36 Comentário para os vídeos 96 24 Proteção contra SPAM 95 32 Sistema de legendas para vídeos 94 80 TOTAL 340

19 Através do Product Backlog, é possível definir as metas do primeiro Sprint a ser realizado: Modelagem de Dados; Cadastro e Gerenciamento de usuários. Com isso, o ScrumMaster Victor, juntamente com a equipe de desenvolvimento definem o Product Backlog, fazendo com que as grandes tarefas se dividam, a fim de facilitar a execução das mesmas: Funcionalidade Prioridade Horas Modelagem de Dados 100 40 Definição de Dados 100.1 8 Organização de Tabelas 100.2 16 Relacionamento 100.3 10 Implementação do SGBD 100.4 6 Cadastro e gerenciamento de usuários 99 32 Formulário 99.1 6 Interação com cadastro na base de dados 99.2 8 Visualização de Perfil 99.3 8 Mudança de Dados 99.4 5 Relacionamento entre usuários 99.5 5 4.1.5 INÍCIO DO SPRINT Com as metas e tarefas definidas, é hora de iniciar o desenvolvimento do primeiro sprint, que por sua vez, tem como objetivo apresentar uma interface o mais simples possível que faça com que os usuários sejam capazes de se cadastrar, visualizar e comentar vídeos em uma interface crua. Considere-se essa parte como o esqueleto do sistema. No exemplo utilizado, no primeiro sprint tem-se o total de 72 horas de estimativa para ser finalizado. É importante lembrar que esse tempo seve ser ajustado a fim da tarefa não ser finalizada rapidamente ou exceder o prazo estabelecido, no caso, acima de 3 dias e abaixo de 9 dias. Durante o ciclo de

20 desenvolvimento, Bruno e Thiago terão de trabalhar nessas tarefas, seguindo esses sub-ciclos: Desenvolver o produto: Implementação, teste e documentação; Empacotar: Finalização do produto, pronto para ser apresentado e integrado caso necessário; Revisar: Revisão do trabalho com intuito de certificar o que foi feito; Ajustar: Modificação nos requisitos ou planos 4.1.6 REUNIÕES DIÁRIAS SCRUM O ScrumMaster Victor acompanhará o desenvolvimento do projeto por meio de reuniões que serão feitas diariamente para se certificar que a equipe de desenvolvimento esteja bem comprometida com o projeto, saudável e completando as tarefas que foram estabelecidas anteriormente. 4.1.7 BURNDOWN CHART Através das reuniões diárias citadas anteriormente, o ScrumMaster Victor poderá construir o BurnDown Chart, como segue o exemplo:

21 Com o BurnDown Chart é possível ver claramente o andamento do projeto ao longo de seu desenvolvimento, assim como é possível calcular a velocidade que o projeto vai andando, podendo estimar uma data de término para o mesmo. Esse dado de estimativa pode ser comparado ao prazo estipulado pelo Proprietário do produto para o término do projeto, sabendo se tudo será finalizado dentro do prazo ou não. No caso do exemplo, a velocidade média de desenvolvimento do projeto é de 8 horas por dia, terminando no dia 10. Caso o projeto devesse ser finalizado no dia 8, por volta dos 5 primeiros dias de desenvolvimento já seria possível reconhecer que a produtividade estaria baixa, sendo necessário aumentar o numero de horas a ser trabalhadas diariamente, isto é, aumentando de 8 horas por dia para 9 horas por dia seria o suficiente para finalizar o projeto dentro do prazo. O BrunDown Chart se caracteriza por ser um dos pontos mais importantes do processo, devido a possibilidade de gerenciamento do tempo que ele proporciona ao ScrumMaster, no caso, o Victor. 4.1.8 REVISÃO FINAL DO SPRINT Ao final do ciclo de desenvolvimento do Sprint, toda a equipe se reúne e vê quais foram os resultados, enquanto o Proprietário do produto identifica o progresso alcançado pela equipe e revisa o programa desenvolvido. Depois disso, o Proprietário juntamente com o cliente entram em concordância de que as tarefas estipuladas foram cumpridas com êxito e a primeira versão desse sistema web satisfaz a proposta. Sendo assim, os seguintes itens foram eliminados: Modelagem de Dados; Cadastro e gerenciamento de usuários. Com isso, é possível estabelecer novas tarefas que farão parte do próximo Sprint: Conversão de vídeo para visualização na internet; Layout; Comentário para os vídeos.

22 Após a definição das novas tarefas, repete-se todo o processo citado anteriormente, definindo o prazo de entrega e as respectivas prioridades de cada tarefa, construindo o plano de desenvolvimento para o próximo ciclo SCRUM.

23 5. CONCLUSÃO O processo de desenvolvimento ágil tende a facilitar a execução do projeto, como visto anteriormente, além de que seu resultado é eficaz, já que é possível o acompanhamento, seja diário ou por etapas, fazendo com que a chance de satisfazer o cliente final utilizando esse método seja alta. Além disso, sua implementação é simples, tendo apenas como desafio integrá-lo no ambiente da organização, da equipe e do cliente final. Vale ressaltar ainda que a utilização correta do método ágil SCRUM cria equipes motivadas, fazendo com que em futuros projeto a serem desenvolvimento, o sistema seja entregue com uma maior qualidade. Sendo assim, conclui-se que a implementação desse método ágil abordado nesse trabalho, usando o exemplo citado anteriormente como modelo, tende de fato auxiliar ou até mesmo assumir todo o processo de desenvolvimento, adaptando, modificando e descartando recursos sem prejudicar a organização e a equipe envolvida, fazendo com que o SCRUM funcione bem tanto quando implementando sozinho, quanto servindo de container para outras técnicas ou práticas. 5.1 CONSIDERAÇÕES FINAIS Pode-se notar, após a apresentação do método ágil SCRUM e por meio de um exemplo que os objetivos citados no início do trabalho foram cumpridos. Além disso, pode-se destacar alguns pontos a respeito do SCRUM que não foram esclarecidos explicitamente, como: Concentração: Foco na concentração de poucos itens; Coragem: Divisão de responsabilidades, fazendo com que os integrantes da equipe sintam-se mais confortáveis para tomarem decisões; Abertura para comunicação e liberdade: Devido a todos possuírem a mesma meta, são "forçados" a compartilhar sucessos e fracassos cometidos durante o processo, criando uma intimidade maior entre eles; Respeito: Ao compartilhar fracassos e sucessos, os integrantes da equipe tendem a respeitar e ajudar uns aos outros com problemas que podem surgir em meio ao desenvolvimento do projeto.

24 REFERÊNCIAS SCHWABER, K.; BEEDLE, M. Agile Software Development with Scrum. New Jersey: Prentice Hall, 2002. SCHWABER, K. Agile Project Management with Scrum. Redmond: Microsoft Press, 2004. SUTHERLAND, J. GUIA DO SCRUM. Scrum.org, Out de 2011. AGILEMANIFESTO. Manifesto for Agile Development. Disponível em: http://www.agilemanifesto.org Acesso em: 30 ago.2014. SANTOS, F. R. SCRUM Experience, ver. 16. Disponível em: http://www.etecnologia.com.br/ Acesso em 31 ago.2014.