ALINE LIMA BARBOSA
MÉTODO ÁGIL APLICADO NO DESENVOLVIMENTO DE SOFTWARE
Rio de Janeiro Julho/2015
ALINE LIMA BARBOSA
MÉTODO ÁGIL APLICADO NO DESENVOLVIMENTO DE SOFTWARE
Trabalho apresentado ao Curso MBA em
Gerenciamento de Projetos,
Pós-Graduação lato sensu, da Fundação Getúlio Vargas como requisito parcial para a obtenção do Grau de Especialista em Gerenciamento de Projetos.
ORIENTADOR: Prof. André Baptista Barcaui
Rio de Janeiro Julho/2015
FUNDAÇÃO GETULIO VARGAS PROGRAMA FGV MANAGEMENT
MBA EM GERENCIAMENTO DE PROJETOS
Trabalho de Conclusão de Curso
Método ágil aplicado no desenvolvimento de software
Elaborado por Aline Lima Barbosa
E aprovado pela Coordenação Acadêmica do Curso de MBA em Gerenciamento de Projetos, foi aceito como requisito parcial para a obtenção do certificado do curso de pós-graduação, nível de especialização do Programa FGV Management.
Rio de Janeiro, 07 de Julho de 2015.
____________________________ André Barcaui
Coordenador do MBA em Gestão de Projetos
__________________________ André Barcaui
TERMO DE COMPROMISSO
A aluna Aline Lima Barbosa, abaixo assinado, do curso de MBA em Gerenciamento de Projetos, Turma GP84 do Programa FGV Management, realizado no período de 20/09/2012 a 05/03/2014, declara que o conteúdo do Trabalho de Conclusão de Curso intitulado Título do trabalho, é autêntico, original e de sua autoria exclusiva.
Rio de Janeiro, 07 de Julho de 2015.
_________________________________________________ Aline Lima Barbosa
AGRADECIMENTOS
Dedico a todas as pessoas que tanto se esforçam, estudando e trabalhando, para conquistar seus objetivos e se realizarem. Aos colegas da turma GP84 que estiveram comigo nessa caminhada, em especial a minha querida amiga Ana Cristina.
Destaco também o companheirismo de Claudio, meu amado marido.
Aos meus pais meus eternos agradecimentos pois sempre acreditaram e investiram em mim, José e Maria.
RESUMO
Este trabalho apresenta o histórico e conceitos sobre a utilização dos métodos ágeis aplicados a projetos empíricos. Detalha ainda características e práticas das três metodologias: Extreme Programming (XP), Kanban e Scrum. Apresentando mais detalhes sobre uma nova forma de trabalho em equipe no desenvolvimento de softwares. Além disso, compara as práticas dessas três metodologias e sua aplicação em sistemas.
PALAVRAS-CHAVE: Metodologia ágil; desenvolvimento de software; Scrum, XP; Kanban.
ABSTRACT
This work presents the history and concepts about the use of agile methods applied empirical projects. Details still characteristics and practices of three methods: Extreme Programming ( XP ), Scrum and Kanban. Featuring more details on a new form of work of team software development. In addition, comparing practices this three methodologies and its systems application.
LISTA DE FIGURAS
Figura 1: Metodologia Ágil...4
Figura 2: Processo Empírico X Processo Definido...5
Figura 3: Ciclo de vida do XP... 6
Figura 4: Práticas do XP...9
Figura 5: Quadro Kanban...15
Figura 6: Ciclo de desenvolvimento do Scrum...17
Figura 7: Burndown Chart...1
LISTA DE QUADROS E TABELAS
SUMÁRIO
1. INTRODUÇÃO...12
2. METODOLOGIA ÁGIL...13
2.1. Histórico...13
2.2. Conceitos básicos...14
2.3. Por que ser ágil?...16
3. Extreme Programming (XP)...17 3.1. Práticas de XP………...18 3.2. Papéis...………...21 3.2.1. Gerente de Projeto...…...21 3.2.2. Coach...………...21 3.2.3. Analista de Teste..………...21 3.2.4. Redator Técnico ...22 3.2.5. Desenvolvedor..……...…...22
3.3. Quando não usar o XP...22
4. KANBAN...23
4.1. Como funciona...24
5. SCRUM...26
5.1. Ciclo de desenvolvimento Scrum...27
5.2. Personagens………...29 5.2.1. Scrum Master...…...29 5.2.2 Scrum Team...29 5.2.3 Product Owner...29 5.3. Artefatos...…...29 5.3.1 Product Backlog...30 5.3.2 Planning Pocker...30 5.3.3 Sprint Backlog...31 5.3.4 Burndown Chart…...32 5.4. Meetings…...…...33
5.4.1. Sprint Planning Meeting...33
5.4.3. Sprint Review Meeting...33
5.4.4. Sprint Retrospective Meeting...34
6. ANÁLISE COMPARATIVA...34
7. CONCLUSÃO...36
1. INTRODUÇÃO
Com a necessidade de se obter resultados rápidos, as empresas de desenvolvimento de software reúnem esforços para melhorar seu processo para criar sistemas mais eficientes. Com isso, muito capital tem sido empregado no desenvolvimento de boas soluções.
O processo de desenvolvimento de software, normalmente envolve riscos, como o atraso de cronograma, mudanças nos requisitos, longas iterações e grandes chances de se cancelar o projeto.
Em busca de otimizar o desenvolvimento de software de forma mais rápida e eficiente, foram pensados os métodos ágeis. Em determinadas variações podem ser usados por empresas de diversos portes afim de agilizar seus processos.
Com objetivo de produzir software de qualidade, dentro do prazo do gerenciamento do projeto garantindo a satisfação do cliente e agregando valor ao resultado final, que é o produto de software. Com isso surge o grande diferencial: os métodos ágeis.
Para implementar as práticas da metodologia ágil, é necessária uma mudança na cultura das pessoas que participarão do processo além de uma quebra de paradigma na empresa. A mudança de papéis e as novas responsabilidades podem gerar desconforto nos funcionários durante a implantação.
Neste trabalho, o objetivo é mostrar as práticas ágeis de desenvolvimento de software. Não ser muito extenso, e sim, o mais prático e direto possível para que quem leia tire suas próprias conclusões e escolha qual a metodologia se encaixe melhor em suas necessidades.
O trabalho está organizado nos seguintes capítulos: Metodologia ágil, Extreme Programming (XP), Kanban, Scrum, Análise comparativa entre as metodologias apresentadas e finalizando com a conclusão.
2. METODOLOGIA ÁGIL
“Incerteza é inerente e inevitável em desenvolvimento de software, processos e produtos” - Hadar Ziv
“Em um novo sistema, os requisitos não serão completamente conhecidos até que os usuários o tenham usado” - Watts Humphrey
“Não é possível especificar completamente um sistema interativo” - Peter Wegner
2.1 Histórico
Desde a década de 80 se fala em metodologias ágeis, mas o termo “Metodologia Ágil” se tornou popular em 2001, quando especialistas em processos de desenvolvimento de software estabeleceram princípios comuns compartilhados por todos esses métodos. Segundo BECK (2001), o resultado desse encontro foi a identificação de 12 princípios e a criação do “Manifesto Ágil” que os representa com 4 premissas:
● Indivíduos e interações ao invés de processos e ferramentas.
● Software executável ao invés de documentação.
● Colaboração do cliente ao invés de negociação de contratos.
● Respostas rápidas a mudanças ao invés de seguir planos.
KALERMO e RISSANEN (2002) apontam os 12 princípios mencionados acima: 1. Prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado;
2. As mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente;
3. Frequentes entregas do software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo;
4. As pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto;
5. Os projetos devem ser construídos em torno de indivíduos motivados. Dando o ambiente e o suporte necessário e confiança para fazer o trabalho;
equipe de desenvolvimento é através de conversa face a face; 7. Software funcionando é a medida primária de progresso;
8. Os processos ágeis promovem desenvolvimento sustentável. Ospatrocinadores,
desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente;
9. Contínua atenção a excelência técnica e bom design aumentam a agilidade;
10. Simplicidade para maximizar, a quantidade de trabalho não realizado é essencial; 11. As melhores arquiteturas, requisitos e designs emergem de equipes auto organizáveis;
12. Em intervalos regulares, a equipe deve refletir sobre como tornar-se mais efetiva, e então, ajustar-se de acordo com seu comportamento.
A metodologia ágil não está aqui para contrariar as metodologias tradicionais. O Manifesto Ágil propõe uma nova maneira na forma de desenvolver projetos seja de software ou não.
O Manifesto Ágil, segundo FILHO (2008), ressalta o que mais tem valor para as metodologias ágeis, a importância de como lidar com pessoas, assim como ter o cliente colaborando para encontrar a melhor solução, entregar o software com qualidade e se adaptar às mudanças.
2.2 Conceitos básicos
Método ágil é um grupo de metodologias de desenvolvimento de software baseadas no desenvolvimento iterativo e incremental, onde os requisitos e soluções evoluem através da colaboração de times auto organizáveis e multidisciplinares.
O método de desenvolvimento ágil visa reduzir o ciclo de vida do software desenvolvendo uma versão mínima, integrando as funcionalidades por um processo iterativo baseado na participação ativa do cliente e testes ao longo de todo o ciclo de desenvolvimento. Uma característica das metodologias ágeis é que elas são adaptativas ao invés de serem preditivas.
Como afirmam Schwaber e Beedle (2002), elas se adaptam a novos fatores decorrentes do desenvolvimento do projeto, ao invés de procurar analisar previamente tudo o que pode acontecer no decorrer do desenvolvimento.
Os princípios e valores propostos pelo Manifesto Ágil propõem uma nova maneira de pensar em desenvolvimento e gerenciamento de software, tendo em mente um conjunto de valores compatíveis, baseados na confiança e respeito pelos companheiros de equipe e promovendo modelos organizacionais simplificados e centrados em pessoas e em colaboração.
Figura 1 – Metodologia ágil
Fonte: https://marcosvperboni.wordpress.com/2013/02/15/adocao-de-metodologias-ageis Acesso em: 10/06/2015
2.3. Por que ser ágil?
A necessidade de tornar o desenvolvimento de software ágil surgiu no reconhecimento em se admitir um processo empírico ao invés de continuar como um modelo de processo definido.
No processo definido, projetos de engenharia por exemplo, são modelos apropriados para trabalhos repetitivos, linha de produção, modelo cascata, entrada e saída bem definidas e custo mais barato.
Na quebra de paradigmas reconhece-se que o desenvolvimento de software da forma ágil não é um processo repetitivo, pouco ou nada previsível, tem um cenário dinâmico, é totalmente criativo, necessita de melhoria contínua inerente do produto e do processo sendo assim seu custo é maior. Caracterizando-se um processo empírico.
Figura 2 – Processo Definido X Processo Empírico
Fonte:http://pt.slideshare.net/amaraldn/magp-2011-versaoweb. Acesso em: 25/06/2015
3. EXTREME PROGRAMMING (XP)
A Extreme Programming foi criada no ano de 1996 por Kent Beck, Ward Cunningham e Ron Jeffries durante o desenvolvimento do sistema C3, para a montadora de automóveis Chrysler, nos Estados Unidos.
Extreme Programming é um processo de desenvolvimento de software formado por um conjunto bem definido de valores, princípios e práticas que oferece condições para que se desenvolva software com requisitos vagos e em constante mudança, mesmo nos estágios finais do ciclo de vida do projeto. O XP adota valores que servem como critérios que norteiam as pessoas envolvidas no desenvolvimento de software que são: comunicação, simplicidade, feedback e coragem, SIAU (2007).
Além dos valores apresentados, o XP define um conjunto de princípios que ajudará na solução de problemas durante o projeto.
Feedback rápido: os participantes do projeto (cliente, programadores e gerentes) devem estar sempre se comunicando para facilitação de dúvidas, problemas e eventuais ações de contingência.
Assumir simplicidade: todo problema deve ser tratado e resolvido da forma mais simples. O problema de hoje deve ser resolvido hoje.
Mudança incremental: as mudanças devem ser incrementais e feitas aos poucos.
Abraçando mudanças: as mudanças devem ser sempre benvindas independente da fase do projeto. Isso é muito utilizado em projetos cujo requisitos são voláteis e o cliente não sabe o que quer.
Trabalho de qualidade: No XP qualidade é ter um sistema que atenda aos requisitos do cliente, onde 100% dos casos de teste funcionam e agregam valor para o negócio do cliente.
Figura 3 – Clico de vida do XP
Fonte:www.devmedia.com.br/agile-development-xp-e-scrum-em-uma-abordagem-comparativa/30808.
Acesso em: 21/06/2015
3.1 Práticas de XP
Extreme Programming possui 12 práticas que foram criadas com base nos ideais pregados pelos valores e princípios. De acordo com BECK (1999) essas práticas não são novidades e já vêm sendo utilizadas a muitos anos, em projetos de software. Elas foram reunidas no XP e devem ser avaliadas em conjuntos e não individualmente, devem ser usadas coletivamente, de forma a reduzir as fraquezas umas das outras.
De acordo com FRANCO (2007) são descritas as práticas do XP:
• Jogo de planejamento (Planning game): O planejamento de um release ou iterações são feitos com bases nas histórias (casos de uso simplificados) e conta com a colaboração de toda a equipe, inclusive a do cliente. Nesta prática existe uma grande interação entre o cliente e os programadores. Os programadores estimam o esforço necessário para implementar as estórias definidas pelo cliente e este, decide sobre o escopo e duração das iterações.
• Incrementos curtos e pequenos (Small releases): Um incremento simples e funcional é gerado rapidamente pelo menos uma vez a cada dois ou três meses. Desta forma é possível ter um feedback mais rápido do Cliente em tempo hábil para poder incorporar mudanças e corrigir o produto sendo desenvolvido.
• Metáfora (Metaphor): É elaborado uma descrição que permite todos envolvidos no projeto (clientes, programadores, gerente etc.) explicar como o sistema funciona. Ela cria uma visão geral do sistema em um formato simples podendo ser compartilhado pela equipe. Ela também auxilia os envolvidos a compreender os elementos básicos do sistema e seus relacionamentos, criando um vocabulário comum para o projeto.
• Projeto simples (Simple design): O sistema deve ser projetado da forma mais simples possível de acordo com as necessidades atuais do projeto. As complexidades desnecessárias são removidas assim que são descobertas.
• Testes (Test): O desenvolvimento do software é dirigido por testes. Os testes de unidade são desenvolvidos antes da codificação e são executados continuamente. Os testes funcionais (aceitação) são feitos pelo cliente.
• Reestruturação (Refactoring): São constantes melhorias no sistema para aumentar a capacidade de adaptar-se as mudanças, remover duplicações de código, melhorando a comunicação, simplificando e adicionando flexibilidade.
• Programação em pares (Pair programming): Todo o desenvolvimento em XP é feito com dois programadores escrevendo o código em um único computador; cada programador tem papéis distintos, um parceiro será responsável pela codificação e pensará nos algoritmos e na lógica de programação e outro programador observa o código produzido e tenta pensar mais estrategicamente em como melhorá-lo e torná-lo mais simples, além de apontar possíveis erros.
• Propriedade coletiva (Collective ownership): Qualquer programador pode alterar qualquer parte do código em qualquer lugar do sistema a qualquer momento. A princípio pode-se pensar que esta prática possa gerar problemas, mas como todos devem respeitar um padrão de codificação e devem realizar todos os testes para verificação de erros, esta atividade é feita de uma forma controlada e pode ser facilitada com o uso de uma ferramenta de controle de versão.
• Integração contínua (Continuous integration): O sistema é integrado e são geradas versões internas, diversas vezes ao dia, sempre que uma estória é finalizada.
• Semanas de 40 horas (40-hour work week): Não devem trabalhar mais do que quarenta horas por semana, isto deve ser encarado como uma regra.
• Cliente no local (On-site customer): Um usuário real do produto (Cliente, ou alguém nomeado por ele) deve ser adicionado à equipe de programadores. Ele deve estar disponível em tempo integral para responder as eventuais dúvidas.
• Padrão de codificação (Coding standards): Os programadores escrevem todo o código de acordo com regras que enfatizam a comunicação durante a codificação. Antes do início do projeto deve ser definido um padrão de codificação que deverá ser seguido por toda a equipe de programadores, facilitando o entendimento do código e as alterações.
Figura 4 – Práticas do XP
Fonte: http://ronjeffries.com/xprog/what-is-extreme-programming Acesso: 21/06/2015
3.2 Papéis
3.2.1 Gerente de projeto
Responsável pelo projeto e suas atividades. Lida com o cliente passando as necessidades do desenvolvimento e lida com a equipe do projeto transmitindo as necessidades do cliente. Responsável por resolver assuntos externos do projeto.
3.2.2. Coach
Responsável pela parte técnica do projeto, o coach tem que ter bastante conhecimento do processo de desenvolvimento, dos valores e práticas do XP. Verifica o comportamento da equipe junto ao processo XP, sinalizando os eventuais erros cometidos pela equipe.
3.2.3. Analista de teste
3.2.4. Redator técnico
Pessoa responsável em documentar o sistema. A documentação deve refletir o código escrito e as regras de negócio atendidas pelo sistema.
3.2.5. Desenvolvedor
Responsável em analisar, projetar e codificar o sistema. No XP não existe diferença entre analista, projetista e programador uma vez que em vários momentos do projeto o desenvolvedor estará exercendo alguma destas atividades.
3.3. Quando não usar o XP
Existem alguns fatores que indicam quando não usar o XP: equipes grandes e espalhadas geograficamente, situações onde não se tem controle sobre o código, tecnologia que não dá suporte facilitado para mudanças e cliente ausente. Nem todos os projetos são bons candidatos a usar uma metodologia ágil.
Para equipes grandes o uso do XP não é adequado. O projeto deve possuir uma equipe pequena geralmente até 12 programadores envolvidos no processo de desenvolvimento. Na organização que se pretende aplicar o uso desse método não pode haver a necessidade de diagramas, além de processos formais e burocráticos.
É importante que a organização esteja aberta e queira sair do tradicionalista processo de desenvolvimento de software e que as equipes sejam resilientes e utilize as práticas, valores e princípios estabelecidos nesse método ágil.
4. KANBAN
Kanban é uma palavra japonesa que significa registro, cartão visível ou etiqueta. Foi criado na década de 50 pelo engenheiro da Toyota Motor Company do Japão, Taiichi Ohno. Ele foi também o principal responsável pelo que hoje conhecemos de Sistema Toyota de Produção.
De acordo com MOURA (1989), as ideias de Ohno sobre o Kanban foram inspiradas no supermercado americano, onde as prateleiras eram reabastecidas quando esvaziadas. Como o espaço de cada item era limitado, somente se traziam mais itens quando havia necessidade. A teoria de Ohno diz que tudo que existir além da quantidade mínima de materiais, peças, equipamentos e operários (horas de trabalho), necessária para fazer um dado produto é “perda” e, portanto, só aumenta os custos em todo o sistema.
Para PACE (2003), Kanban é uma técnica mais abrangente, chamada Just-in-time que consiste no emprego de cartões, tanto para requisitar material de um centro produtor para um centro consumidor, quanto para ordenar o centro produtor a produzir determinado produto em determinado momento. Essa técnica visa à redução dos estoques em processo a limites mínimos e à produção somente quando necessário. Ou seja, o centro produtor somente produz quando o centro seguinte (consumidor) ordena. Essa ordem é feita por meio de cartões – daí a origem do nome do sistema. Dessa forma evita-se produzir o que é desnecessário no momento.
O uso do Kanban para o gerenciamento de equipes de desenvolvimento de software foi mais frequente a partir de 2007, quando Rick Garber e David J. Anderson publicaram nas conferências “Lean New Product Development” e “Agile 2007” os resultados obtidos no uso deste método. Desde então, o uso deste método com este foco vem sendo estudado e experimentado SILVA (2013).
Uma das características desse método é evidenciar os problemas existentes no processo das metodologias para o desenvolvimento de software. O Kanban, dentre as formas ágeis, é a menos prescritiva, isso estimula mais as equipes a adotarem esse método. Por ser mais adaptativo do que prescritivo, ele acaba tornando-se bastante empírico.
• Visualize o fluxo de trabalho atual
• Limite o fluxo de trabalho (Work in Progress) • Acompanhe e gerencie o fluxo de trabalho
Para atender a primeira prescrição do Kanban é importante ressaltar que o fluxo de trabalho a ser visualizado deve ser aquele que de fato ocorre e não o que formalmente é definido pela organização.
Já a segunda prescrição, para limitar o fluxo de trabalho é necessário explicitar quantos itens de trabalho são necessários em cada uma das fases do processo. Esse artifício é um dos “pontos chave” do método, uma vez que ele é o responsável por definir Kanban como pull system. Apenas quando um item sair de uma fase é que esta fase poderá receber outro item KNIBERG (2007).
Na terceira prescrição, é definida uma forma de medir e controlar o fluxo de trabalho. Neste ponto é onde os times de desenvolvimento realizam adaptações fortes para, de acordo com os problemas evidenciados, propor formas de controlá-los e contorná-los.
Dadas as prescrições, percebe-se que o Kanban se baseia num processo onde o fluxo de trabalho é contínuo, ou seja, diferente de Scrum, não há um ciclo de trabalho definido onde, conhecida uma atividade, a mesma é estimada e colocada neste ciclo. Kanban controla as entradas de itens de trabalho e a vazão que é dada de acordo com o WIP definido. A esta vazão dos itens de trabalho dá-se o nome de leadtime, que representa o tempo de um item de trabalho desde a sua entrada no fluxo de trabalho mapeado até a sua saída KNIBERG (2007).
4.1. Como funciona
De acordo com as dificuldades encontradas ao decorrer do desenvolvimento do produto e para aumentar a evolução do projeto, foi criado um processo ágil baseado em práticas do Scrum, adaptadas e sem restrições derivando o Kanban.
As tarefas ou itens de trabalho foram representadas por meio de cartões (post-its) fixados em um quadro (cardwall). Esse quadro, por sua vez, era dividido em colunas que representavam as fases do fluxo de trabalho (workflow) da equipe. As
tarefas eram distribuídas sequencialmente nas colunas a medida que o trabalho ia avançando.
Foram identificados os seguintes estados das tarefas ANDERSON (2010): • Próximas: tarefas elegíveis para entrarem em execução;
• Em andamento: tarefas em andamento;
• A implantar: tarefas concluídas e prontas para serem implantadas no sistema em produção;
• Implantadas: tarefas já implantadas e em uso pelos clientes; • Notificadas: tarefas concluídas
Para identificar as tarefas no quadro, foi adotada uma classificação com base nos tipos de solicitações. Essas solicitações foram divididas em categorias. Para as tarefas ficarem mais visível, cada categoria era representada por um post-it com uma cor específica, tornando fácil a identificação e a proporção de tarefas de um determinado tipo que estavam sendo executadas, bastando para isso observar no quadro a quantidade da respectiva cor. As cores escolhidas foram:
• Correção de bugs: vermelho; • Novas funcionalidades: laranja; • Ajustes operacionais: amarelo.
Algumas boas práticas ágeis foram mantidas, outras foram adaptadas. As reuniões diárias, por exemplo, continuaram a ser realizadas no início de cada dia com a equipe posicionada em frente ao quadro de tarefas. As reuniões de planejamento passaram a ter um caráter mais de priorização do que de estimativa de tarefas. As reuniões de retrospectiva e revisões ainda são realizadas em um intervalo de duas semanas.
Figura 5 – Quadro Kanban
Fonte: http://pt.slideshare.net/jotafurtado/apresentao-kanban. Acesso em: 21/06/2015
Com o uso da metodologia Kanban pode-se evitar muitas atividades sendo executadas ao mesmo tempo, porque ele delimita a quantidade de atividades que está sendo executada. Esse método tem como objetivo exibir de forma clara o fluxo de trabalho, organizar as tarefas e fornecer informações aos participantes da equipe. Conseguindo reduzir custos e desperdício, e melhorando sempre a motivação e o desempenho da equipe.
5. SCRUM
No início dos anos 90, Jeff Sutherland foi o primeiro a utilizar o Scrum para o desenvolvimento de software na empresa Easel Corporation. Em 1996, Ken Schwaber formalizou a definição do Scrum e ajudou a implantá-lo no gerenciamento de projetos de software ao redor do mundo.
O Scrum é uma metodologia ágil de maior expressividade, é extensível, antes e durante sua execução. Promete alta qualidade e alta produtividade com isso
gerando maior valor agregado. O Scrum é um framework que se destaca entre os demais métodos ágeis pela ênfase dada ao planejamento e gerenciamento de projetos.
Esse método ágil é baseado por princípios básicos de objetividade, papéis bem prescritos e facilidade de aprendizado. O Scrum é um modelo aberto e de forma alguma é previsível, SCHWABER (2004). Ele oferece um conjunto definido de regras e práticas que tem como objetivo manter o gerenciamento do projeto visível aos usuários do modelo. A metodologia não detalha o que deve ser feito e não resolve os problemas da empresa, seu objetivo é dar visibilidade a estes problemas e servir como guia na resolução dos mesmos. Os caminhos a seguir e estratégias a serem utilizadas são de responsabilidade de quem o implanta.
O SCRUM é fundamentado na teoria do controle de processos empíricos, emprega uma abordagem iterativa e incremental para otimizar previsões e controlar riscos. Três pilares sustentam qualquer implementação de controle de processos empíricos, KNIBERG (2007).
• Transparência: os aspectos do processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os resultados.
• Inspeção: os diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que as variações inaceitáveis no processo possam ser detectadas.
• Adaptação: qualquer ajuste deve ser feito o quanto antes para minimizar desvios posteriores.
5.1 Ciclo de desenvolvimento Scrum
Segundo PEREIRA (2009) o ciclo de desenvolvimento é baseado em iterações (Sprint), cada uma com duração entre duas a quatro semanas. Antes de cada Sprint realiza-se uma reunião de planejamento (Sprint Planning Meeting) onde o time (Team) tem contato com o cliente (Product Owner) para priorizar e estimar as tarefas que
serão realizadas. Durante a Sprint, o time realiza reuniões diárias (Daily Meeting), de pelo menos 15 minutos de duração. Assim é possível verificar o acompanhamento / progresso do desenvolvimento do trabalho. Para isso usa-se um gráfico (Burndown Chart) de acompanhamento das tarefas que são classificadas como: a realizar, em andamento e concluídas.
Ao final da Sprint é realizada uma reunião para a entrega do trabalho desenvolvido, em que o time demonstra o produto gerado na Sprint e o cliente valida se o objetivo foi atingido. Logo após, é realizada, apenas pelo time, uma reunião de retrospectiva (Sprint Retrospective) onde é avaliado sob a perspectiva das pessoas envolvidas no trabalho quais foram os acertos e os erros com o objetivo de melhorar o processo FIGUEIREDO (2009).
Figura 6 – Ciclo de desenvolvimento do Scrum
Fonte: http://blog.marciel.org/?p=66. Acesso em 25/06/2015
Segundo FIGUEIREDO (2009), equipes Scrum são auto gerenciáveis, multidisciplinares e trabalham em iterações. Essa metodologia torna-se ideal para projetos dinâmicos e suscetíveis a mudanças de requisitos. No entanto, para aplicá-lo é preciso entender antes os seus papéis, responsabilidades, conceitos e artefatos das fases de seu ciclo.
5.2 Personagens
5.2.1 Scrum Master
É o responsável por garantir que o processo seja entendido e seguido. É um facilitador para a equipe e ajuda a resolver os problemas, enquanto dissemina e aplica o processo dentro da organização. O Scrum Master tem o papel também de manter o time funcional e produtivo além de protege-los de interferências externas.
5.2.2 Scrum Team
São auto gerenciáveis, multidisciplinares e trabalham em iterações. São responsáveis pelo desenvolvimento do produto, devem também ter autonomia para tomar decisões sobre como executar o seu trabalho. O tamanho típico da equipe varia entre 6 a 10 pessoas. Ultrapassar esse limite de pessoas pode dificultar a comunicação entre a equipe e sua produtividade.
Todos no projeto trabalham juntos e são responsáveis por completar o conjunto de trabalho com o qual se comprometem a cada iteração.
5.2.3 Product Owner
O Product Owner é o cliente de um time, é responsável por representar os interesses dos stakeholders (envolvidos) no projeto e fornecer a visão do negócio. O Product Owner, trabalha em conjunto com a equipe definindo todos os itens de requisitos do projeto numa lista chamada Product Backlog.
5.3 Artefatos
Os artefatos do Scrum representam o trabalho ou o valor para o fornecimento de transparência e oportunidades para inspeção e adaptação. São especificamente projetados para maximizar a transparência das informações chave de modo que todos
tenham o mesmo entendimento dos artefatos SCHWABER e SUTHERLAND (2013).
5.3.1 Product Backlog
É a lista principal de funcionalidades para o desenvolvimento de um produto. O Product Backlog pode mudar no decorrer das sprints tornando-se melhor especificado e mudando as prioridades das entregas.
É função do Product Owner manter a lista com suas prioridades e mostrar para o time quais são as perspectivas para o projeto.
Cada história existente no Product Backlog deve ter um valor de negócio e uma complexidade associada. O primeiro é de responsabilidade do Product Owner e o segundo do time, que deve ser sempre solicitado a reavaliar as estimativas constantes no Product Backlog.
A definição de valor de negócio é extremamente complexa. Uma das técnicas utilizadas para a criação de um Product Backlog inicial é dar um valor de pontos fechado para a Product Owner dividir entre suas histórias.
Isto pode ser descrito da seguinte maneira, imaginemos que o Product Owner precise construir um carro e para isto lhe são dados 2000 (dois mil) pontos de complexidade. Assim ele necessariamente terá um volume de pontos limitado e realmente dará os pontos de valor para aqueles que realmente importam (Carroceria, Motor, Câmbio) deixando menos pontos para aqueles que neste caso por exemplo seriam menos importantes (retrovisor, bancos de couro, etc.).
O modelo anterior facilita, pois, desta forma o Product Owner tem um limite para gastar, da mesma forma que a empresa tem um orçamento limitado. A questão da priorização é resolvida pelas necessidades do negócio e a complexidade geralmente utiliza uma ferramenta chamada Planning Poker.
5.3.2 Planning Poker
O Planning Poker é um exercício de estimativa que pode ser realizada em grupo e usa a sequência de Fibonacci (1,2,3,5,8,13,21,...) como base para a avaliação de
complexidade. A lógica associada a utilização desta sequência está na diferença 10 existente entre cada uma o que permite claramente ver quão complexa é cada funcionalidade.
As diferenças no caso mapeiam melhor as incertezas associadas a avaliação. Tudo começa selecionando-se o item que todos acreditem ser o mais fácil de implementar, sendo a ele associado o menor valor da sequência. Posteriormente os demais itens são avaliados levando-se em consideração sua complexidade relativa a de menor valor. Cada um dos participantes dá sua nota de complexidade para cada história e caso haja consenso entre eles a complexidade é validada e atribuída a história.
Em caso de divergência, cada pessoa que teve uma diferença pode defender seu ponto de vista. Após isto é realizada nova rodada e assim segue até o consenso.
É importante que a equipe sempre mantenha o Product Backlog com estimativas coerentes com a sua velocidade de desenvolvimento. Por este motivo, a cada Sprint o time deve reservar uma parcela de seu tempo para rever o Product Backlog e se necessário fazer novas estimativas ou corrigir estimativas já feitas baseados na experiência do projeto corrente. PEREIRA (2009).
5.3.3 Sprint Backlog
Sprint Backlog representa tudo o que deverá ser feito durante a próxima Sprint do projeto. Ele surge a partir do que foi levantado e listado pelo Product Owner, no Product Backlog. A maioria dos itens que estão no Product Backlog serão implementados, mas para serem considerados para fazer parte do Sprint Backlog eles devem estar detalhados, estimados e priorizados.
Durante uma Sprint, o Scrum Master mantém o Sprint Backlog atualizado para refletir que tarefas serão completadas e quanto tempo a equipe acredita que será necessário para completar aquelas que ainda não estão prontas.
5.3.4 Burndown Chart
O Burndown é um gráfico simples que se baseia em atividades que não ultrapassem um dia de trabalho. O eixo X indica o número de tarefas existentes na Sprint e o eixo Y os dias que representam o tamanho da Sprint. A partir da quantidade de tarefas realizadas diariamente pode-se verificar se a Sprint está dentro do esperado.
Caso as estimativas estejam erradas e o número de tarefas diários não é cumprido a linha azul tende a ir para a direita e distanciar-se da reta de atividades diária. Este é o indicativo de que provavelmente as tarefas foram mal avaliadas ou existe algum outro problema com a equipe.
Figura 7 – Burndown Chart
Fonte: http://www.scrum-institute.org/Burndown_Chart.php. Acesso em 30/06/2015
Além do Burndown, é realizado através de um quadro onde são divididas as tarefas a realizar, em andamento e já realizadas. O acompanhamento diário faz a diferença na entrega das histórias no prazo. Como tarefas podem ser adicionadas diariamente uma análise incorreta do que está acontecendo com o desenvolvimento do Sprint pode gerar um grande atraso e penalizar a Sprint.
5.4 Meetings
5.4.1 Sprint Planning Meeting
É a primeira atividade dentro da Sprint, é feita a seleção das histórias que serão implementadas durante aquele ciclo. É importante ressaltar que o Product Backlog esteja com suas histórias pontuadas e priorizada. Para Pereira (2009), o Product Backlog priorizado e estimado, a equipe de desenvolvimento realiza uma reunião de planejamento para selecionar as histórias que serão incluídas na Sprint de modo a incluí-las dentro do tempo da Sprint e respeitando a priorização definida pelo Product Owner.
5.4.2 Daily Scrum Meeting
O Daily Scrum Meeting tem como objetivo informar o que foi feito no dia anterior. É uma reunião em pé, rápida de mais ou menos 15 minutos que deve ser realizada no mesmo lugar e na mesma hora do dia. Nessa reunião, cada membro da equipe explica entre si o que foi feito desde a última reunião, o que será feito até a próxima e quais foram, se houver, os impedimentos que surgiram.
Essa reunião tem como objetivo, acompanhar o desenvolvimento do projeto e distribuir tarefas. A disciplina é extremamente importante no Scrum, a equipe é auto gerenciável e deve agir como tal. Possíveis atrasos são vistos no dia a dia e devem ser avaliados pelo time.
5.4.3 Sprint Review Meeting
O Sprint Review Meeting, acontece ao final de cada Sprint. Nesta reunião, a equipe apresenta cada uma as histórias implementadas na Sprint, mostrando o seu resultado para o Product Owner. O Product Owner então realizará os testes de cada uma das histórias para verificar se as condições estabelecidas foram satisfatórias.
As histórias reprovadas retornam para o Product Backlog e ficam disponíveis para serem incluídas em uma nova Sprint.
5.4.4 Sprint Retrospective Meeting
Após a reunião de Review, a equipe de desenvolvimento junto ao Scrum Master faz a reunião de Retrospectiva. Nessa reunião, o Product Owner não participa. A equipe compartilha a sua opinião e reflete sobre o que funcionou e o que não funcionou ao longo da Sprint. É feita uma discussão sobre os pontos positivos e negativos da Sprint, com o objetivo de reforçar o que foi bom e levantar soluções para o que foi ruim. Assim, a cada Sprint, a equipe vai aprendendo e melhorando o seu processo de desenvolvimento.
6. ANÁLISE COMPARATIVA
Para facilitar o entendimento do que foi dito nos capítulos anteriores, será demonstrado uma análise comparativa das características entre as metodologias: XP, Scrum e Kanban.
Características XP Scrum Kanban Programação em pares Desenvolvedore s trabalha em pares Desenvolvedor trabalha sozinho Desenvolvedores trabalha em pares Time Equipe comprometida Equipe totalmente comprometida Comprometimento opcional
Timebox Iterações curtas
e com tempo determinado Iterações curtas e com determinado Iterações com timebox opcionais
Velocidade - Usa velocidade
timebox como métrica default para planejamento e melhoria de processo
Usa lead time como métrica default para planejamento e melhoria de processo
Burndown - Obrigatório Nenhum tipo de
diagrama é definido
Estimativa - Definida Opcional
Papéis Gerente de Projeto, coach, analista de teste, redator técnico e desenvolvedor Define 3 papéis (Product Owner, Scrum Master e Time) -Tamanho do projeto
Pequeno Qualquer tamanho Qualquer tamanho
Validação Validação é feita
a todo instante
Somente no final da Sprint
-Quadro 1: -Quadro comparativo entre as metodologias: XP, Scrum e Kanban
Através da análise comparativa entre as metodologias destacadas acima, conclui-se que existe bastante semelhanças entre si e algumas particularidades foram notadas como programação em pares entre o XP e o Kanban, e iterações curtas entre o XP e o Scrum. E características próprias que definem sua aplicação. Afinal o que o método ágil propõe é resolver limitações dos métodos tradicionais no desenvolvimento de software.
7. CONCLUSÃO
Este trabalho procurou mostrar a utilização do método ágil no processo de desenvolvimento de software. Apresentando conceitos e melhores práticas de algumas das metodologias ágeis mais utilizadas atualmente.
O que o método ágil propõe, é simplificar o processo de desenvolvimento de software, tornando mais iterativo e menos repetitivo.
O que ele visa é a quebra de paradigma no desenvolvimento de software, removendo modelos de trabalhos repetitivos. Trazendo um cenário mais dinâmico, criativo, com uma melhoria contínua do produto.
Foram apresentados três tipos de metodologia ágil: Extreme Programming (XP), Kanban e Scrum.
Conclui-se que o Scrum, XP e Kanban poderiam ser empregadas de maneira complementar entre si. O Scrum é um framework iterativo e incremental, podendo ser usado não somente no desenvolvimento de software, mas também em planejamento e gerenciamento de qualquer outro produto. Mesmo assim, várias práticas são coincidentes entre Scrum/XP como sprint/desenvolvimento iterativo, daily scrum/daily meeting, sprint planning/planning game e assim por diante.
O Kanban pode ser utilizado como processo para organizar o trabalho em equipe, através da utilização de cartões. Ele se baseia num processo onde o fluxo de trabalho é contínuo, diferentemente do Scrum, não há um ciclo de trabalho definido.
REFERÊNCIAS BIBLIOGRÁFICAS
ANDERSON, David J. Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press, 2010.
BECK, K. et al. Manifesto for Agile Software Development. 2001. Disponível em: http://www.agilemanifesto.org. Acesso: 05 jun. 2015.
BECK, K.: Extreme Programming explained: Embrace change. Reading, Mass., Addison Wesley.1999.
FIGUEIREDO A. M. As armadilhas do SCRUM. Disponível em:
http://pt.scribd.com/doc/20007366/Armadilhas-do-Scrum. Acesso em: 07 jun. 2015.
FILHO, D. L. B.: Experiências com desenvolvimento ágil. Instituto de Matemática e Estatística da Universidade de São Paulo (Dissertação de Mestrado). 2008
FRANCO, E. F.: Um modelo de gerenciamento de projetos baseado nas metodologias ágeis de desenvolvimento de software e nos princípios da produção enxuta. Escola Politécnica da Universidade de São Paulo (Dissertação de Mestrado). 2007.
KALERMO, J., RISSANEN, J.: Agile software development in theory and practice. Universidade de Jyväskylä, Finlândia (Dissertação de Mestrado). 2002.
KNIBERG, H., Scrum and XP From The Trenches: How We do Scrum. C4Media, 2007.
PEREIRA, P. Entendendo SCRUM para Gerenciar Projetos de Forma Ágil. Disponível em: http://www.cesar.edu.br/docs/paulocaju.pdf. Acesso: 10 jun. 2015.
SCHWABER, K. & BEEDLE, M. Agile Software Development with Scrum,Prentice Hall, 2002.
SCHWABER, Ken. e SUTHERLAND, Jeff. GUIA do SCRUM. 2013. Disponível em: https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-Portuguese-BR.pdf. Acesso: 01 jul. 2015
SIAU, KENG. The Future Of Information Sytems Engineering, In Requeriments Engineering, 2007.
