Metodologias Ágeis para Desenvolvimento de programas
Metodologias Ágeis para Desenvolvimento de programas
Scrum é uma metodologia ágil para gestão e planejamento de projetos de software. Se você chegou até aqui interessado em fazer uma das certificações disponíveis para Scrum, veja por que dizemos não à certificação?
No Scrum, os projetos são dividos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que são chamadas de Sprints no caso do Scrum.
As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog.
A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada Daily Scrum. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia.
Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento do próximo Sprint. Assim reinicia-se o ciclo. Veja a ilustração abaixo:
http://improveit.com.br/scrum
No Brasil você pode encontrar sites de comunidades do Scrum em :
- scrumcom/
- scrum.org.br/
Noticia na infoabril de 5 sites onde você pode estudar scrum de graça:
Tutorial de 60 páginas sobre scrum:
SCRUM, muito simples de usar
A metodologia SCRUM está entrando na moda aqui no Brasil, após já haver conquistados inúmeras empresas da indústria de software na América do Norte.
Particularmente, eu considero o SCRUM uma proposta extremamente prática e honesta. Defino por prática neste contexto a facilidade de compreensão e aplicação em nosso ambiente de desenvolvimento de software. Defino por honesta a fidelidade entre a proposta do método e o resultado que podemos obter após aplicá-lo.
SCRUM, nome utilizado inicialmente pelos japoneses Hirotaka Takeuchi e Ikujiro Nonaka, descrevia um tipo de processo de desenvolvimento de produto utilizado no Japão.Também o nome SCRUM foi escolhido pela similaridade entre o jogo de Rugby e o tipo de desenvolvimento de produto comentado. Ambos são adaptativos, rápidos e promovem a auto-organização.
Para explicar SCRUM, utilizarei uma estratégia que foi usada pelo Ken Schwaber em seu livro chamado Agile Project Development with SCRUM. Na minha leitura, este é o melhor livro disponível lançado até a presente data.
Iniciando um projeto, há uma formalização de todas as coisas que se pretende fazer ou que se precisa construir no projeto. Cada item desta lista representa um requisito funcional, ou requisito não funcional, ou questão de tecnologia / infra-estrutura. Esta lista é denominada Product Backlog.
Podemos traduzir Product Backlog como uma lista de todos os requisitos de um produto priorizados, ou, em outras palavras, é qualquer coisa que represente um trabalho que precisa ser feito para o produto. Os itens com maior prioridade nesta lista são os requisitos mais desejados pelo produto. No projeto real, o Product Backlog nunca é finalizado. Existe uma natural evolução e maturidade dos requisitos nesta lista. Requisitos novos podem aparecer, requisitos existentes podem perder prioridade e podem até serem eliminados. Apesar de se permitir que áreas usuárias manifestem seus pedidos nesta lista, somente o Product Owner pode priorizar o Backlog.
O Product Owner possui a responsabilidade de definir a ordem que os requisitos serão produzidos pela equipe de desenvolvimento. Esta equipe deve ser pequena, multi-disciplinar e capaz de desenvolver todos os requisitos. Esta equipe recebe o nome de SCRUM Teams. A preparação dos trabalhos é denominada SPRINT Planning.
SPRINT Planning é composta dos seguintes ingredientes: Product Backlog, a capacidade de desenvolvimento da equipe, as condições e exigências do negócio, as características da tecnologia a ser usada e o comprometimento em entregar produtos executáveis incrementais. A mistura são revisões, administração e organização. Os resultados são SPRINT Goal e SPRINT.
O SCRUM Team deve desenvolver os itens separados pelo Product Owner em um determinado prazo previamente combinado. Este prazo é definido como Time Box e o trabalho de desenvolver os itens separados neste time box é denominado SPRINT. Estes itens separados do Product Backlog fazem parte de uma nova lista. Esta lista, chamada SPRINT Backlog, será de total responsabilidade do SCRUM Team que deverá mantê-la e organizá-la de tal forma a atender os objetivos do específico SPRINT.
É permitido ter mais de um SCRUM Team trabalhando no mesmo Product Backlog, por isso os requisitos são devidamente separados em SPRINT Backlog distintos por equipe. Uma idéia deste ciclo é verificada na imagem abaixo.
Figura 1 - Ciclo demonstrando SPRINT
A liderança destas equipes é exercida por um papel denominado SCRUM Master. O SCRUM Master é um facilitador da gestão dos requisitos e direcionador da gestão das equipes. Este papel deve garantir a correta utilização das práticas de SCRUM, deve ajudar a equipe a tomar decisões e apoiar a equipe para adquirir os recursos necessários para o desenvolvimento do produto.
Este método de liderança é exercido através de 3 recorrentes tipos de reunião: SCRUM Daily Meeting, SPRINT Review e Retrospective. Começando pelo SPRINT Review que é a reunião típica de final de SPRINT (alguns SCRUM Team também a fazem no meio do SPRINT) para validar o produto executável que a equipe conseguiu incrementar.
Explicando a Retrospective, é uma reunião que também acontece ao final do SPRINT com o objetivo de fortalecer a unidade de ação da equipe. Três perguntas deverão ser respondidas com seriedade por todos os membros do SCRUM Team:
- O que você fez e gostou neste SPRINT?
- O que você fez e não gostou neste SPRINT?
- O que você vai fazer diferente no próximo SPRINT?
O desenvolvimento de projetos de software é um desafio constante, é uma atividade complexa. Todo processo complexo exige uma intensa comunicação entre todos os membros do projeto. SCRUM Daily Meeting é a resposta para promover a comunicação da equipe.
Todos os dias, obrigatoriamente, todo o SCRUM Team irá se reunir por 15 minutos aproximadamente para responder a 3 importantes perguntas. Sugerimos que está reunião seja de pé, pois temos verificado bons resultados em nossas práticas.
As perguntas são:
- O que eu fiz desde a última SCRUM Daily Meeting até agora?
- O que eu vou fazer hoje?
- O que pode me impedir?
Adicionalmente as técnicas apresentadas neste artigo, temos observado que a utilização de KANBAN (ver figura abaixo) ajuda a maximizar o comprometimento da equipe e a comunicação de todos os comprometidos e envolvidos com o projeto.
Figura 2 - Nossa implementação de KANBAN na empresa REPOM dirigida pelo SCRUM Master Marcelo Martins.
As cores amarela e laranja representam diferentes complexidades das atividades. A cor pink representa atividades não planejadas no SPRINT que foram incluídas por motivo de força maior.
Por se tratar de um extenso assunto, abordaremos detalhes explicativos sobre o que é KANBAN e como se utiliza em projetos de software no nosso próximo artigo técnico.
Para saber mais recomendamos os livros:
Agile Project Management by Jim Highsmith.
Agile Software Development with SCRUM by Ken Schwaber e Mike Beedle.
Agile Project Management with SCRUM by Ken Schwaber.
Treinamento MSF Agile + SCRUM + Agile Methods em http://www.fcamara.com.br
Considerações Finais
Nós, praticantes das metodologias ágeis, acreditamos que todos os projetos são diferentes. As tecnologias destes projetos são diferentes. As pessoas, os requisitos, idem. Nós não queremos ser indivíduos críticos do que existe há muito tempo na engenharia de software, nós queremos sugerir, proporcionar e fundamentar alternativas novas para resolver problemas antigos.
Na grande maioria das consultorias que ministro sob a titulação de "coaching" para fins de crescimento dos resultados qualitativos e produtivos de equipes de desenvolvimento de software, encontro pessoas que, utilizando-se de métodos tradicionais ou simplesmente de improviso diário (também denominado "ausência de métodos"), revelam-me uma estranha e frustrante sensação - A Síndrome do Trabalho Vazio.
A STV é a sensação que ocorre depois de um intenso dia de trabalho repleto de aborrecimentos e de atividades urgentes, quando percebe-se que, no final, todas as atividades planejadas para aquele dia não puderam ser implementadas. É uma constatação que é uma espécie de marionete do tempo, da empresa e dos clientes.
A utilização de métodos ágeis, com a adequação mental conforme os princípios estabelecidos pelas metodologias ágeis, mudaram minha vida profissional perante o cenário anteriormente descrito. Eu consigo fazer atividades planejadas, consigo priorizar atividades importantes e tenho um pequeno índice de atividades urgentes no meu dia-a-dia. Eu me sinto protagonista do meu dia.
As metodologias ágeis são uma positiva proposta para as empresas desgastadas com os resultados proporcionados por "waterfall approach to software development" ou pela ausência de métodos. Para iniciantes em metodologias ágeis, eu recomendo o SCRUM. Para praticantes de métodos ágeis que não conhecem o SCRUM, permitam-se mais uma evolução.
Sucesso em seus projetos.
Fábio Camara é MVP VSTS, MCT, MCP, MCSD, MCTS, MCPITP, MCPD, MSF Practitioner, Certified SCRUM Master, e Certified ITIL Foundations. Escreveu mais de 15 livros nesta última década. Atua como consultor de produtividade em desenvolvimento de projetos e professor de disciplinas ágeis de engenharia de software. Pode ser localizado no site www.fcamara.com.br.
http://imasters.com.br/artigo/10699/gerencia/scrum_uma_metodologia_agil/
Conceitos, fases e artefatos do Scrum
Qui, 06 de Agosto de 2009 00:00 Douglas Hideki Matsudo
Para realizar o planejamento, a execução e o controle o método possui artefatos e técnicas para o desenvolvimento do produto. Os principais documentos são os Backlog do Produto (Product Backlog), Backlog de Impedimentos e o Burndown Chart (Pereira, Torreão e Marçal, 2007).
Mas antes de definir cada documento é necessário entendermos o conceito de Sprint, como foi citado no início do Scrum, ele trabalha com uma série de iterações, são diversos ciclos chamados de Sprint, um ou o conjunto de Sprints executados se consegue montar uma ou mais funcionalidades do sistema, o conjunto de funcionalidade integrada forma o sistema.
Cada Sprint normalmente leva de 2 a 4 semanas para ser executada, esse período é chamado de Time Box.
O Backlog de Produto, lista todas as funcionalidades que serão necessárias no sistema e suas prioridades, associado ao valor de negócio para que se consiga calcular o retorno do projeto. Com esse documento a Equipe e o Scrum Master conseguem ter a visão do projeto, e listar as tarefas que deverão ser executadas para cada funcionalidade e quais as funcionalidades deverão ser priorizadas nos Sprints.
O Backlog de Impedimentos é a lista de impedimentos conhecidos que impedem a equipe de progredir na execução das tarefas ou dos Sprints, o Scrum Master possui a responsabilidade de resolver essas dificuldades, com isso não paralisando o trabalho da equipe.
Estimar as funcionalidades - Planning Poker
Para estimar as funcionalidades do Backlog de Produto usa-se a técnica do Planning Poker, essa técnica consiste em um jogo de cartas com a sequência numérica do Fibonacci(1,2,3,5,8,13,21, etc.).
A aplicação do Planning Poker acontece da seguinte forma como explica Marçal (2007):
Cada participante da reunião (equipe, Scrum Master e Product Owner) fica com um conjunto de cartas em mãos. A atribuição do grau de dificuldade de cada item do Backlog de Produto é feita com as cartas. Primeiro se atribui o tenha um consenso dos integrantes. É importante ter um moderador para que o processo de atribuição seja produtivo e não perca o foco do trabalho.
Controle
Para o controle do desenvolvimento e desempenho da equipe se monta o Burndown Chart. (Marçal, 2007)
O Burndown Chart, é um gráfico que demonstra a quantidade de horas e dias previstos para a realização do Sprint, com o que foi realizado, observando esse documento é fácil entender se o projeto está sendo realizado no prazo ou se está atrasado.
Fonte: MARÇAL, Ana Sofia; PEREIRA, Paulo; TORREÃO, Paula. Entendendo Scrum para Gerenciar Projetos de Forma Ágil. Acesso em: 01 dez 2008.
Última atualização em Seg, 10 de Agosto de 2009 21:56
http://www.matsudo.com.br/scrum/1-conceitos-fases-e-artefatos-do-scrum
Metodologia Scrum para gerenciamento de projetos de software
Scrum é um processo ágil para construir software incrementalmente em ambientes complexos, onde os requisitos não são claros ou mudam com muita freqüência.
A ilustração a seguir representa o Processo Dextra para Desenvolvimento em Scrum:
Metodologias ágeis foram criadas para atender melhor a natureza de projetos em ambientes de requisitos instáveis, pouco definidos ou muito sujeitos a mudanças.
Algumas de suas principais características visando minimizar os riscos são :
- Divisão do projeto em pedaços menores e curtos, variando de uma semana a um mês.
- Comunicação entre a equipe e o Cliente em tempo real.
- Participação ativa do Cliente.
- Alta capacidade de resposta a mudanças.
Cliente :
Nesse modelo o Cliente é uma parte importante no processo e sua participação ativa, mesmo que não presente fisicamente, é essencial para garantir o sucesso do projeto. É sua responsabilidade priorizar as funcionalidades que serão implementadas em cada um dos pedaços de software e eventualmente escolher aquelas que serão despriorizadas. Seu feedback constante alimenta o planejamento do projeto e definição de atividades pela equipe.
Como funciona :
Entenda como funciona o desenvolvimento baseado em Scrum na Dextra Sistemas
No Scrum o projeto será dividido em ciclos periódicos chamados Sprints. Cada Sprint, geralmente variando entre uma semana e um mês, representa um volume de esforço pré-definido dentro do qual um grupo de atividades deverá ser executado e seu produto final será um software funcional. O processo é iterativo e incremental.
As funcionalidades que o Cliente deseja implementar em um software são registradas em um Product Backlog, definido antes do início do projeto através de técnicas especiais de levantamento e registro de requisitos. Cada funcionalidade é estimada (esforço e prazo) e, em função da quantidade de profissionais envolvidos no projeto, este é dividido em Sprints.
No começo de cada Sprint é realizado um Sprint Planning Meeting, uma reunião de planejamento no qual o Product Owner define prioridades dentro do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint sendo iniciado. As tarefas definidas para cada Sprint são realocadas do Product Backlog para um Sprint Backlog.
Diariamente é realizada pela equipe uma breve reunião (Daily Scrum), geralmente pela manhã, cujo objetivo é disseminar conhecimento sobre as atividades realizadas no dia anterior, identificar riscos e problemas, e priorizar as tarefas no dia corrente.
A cada término de Sprint a equipe apresenta as funcionalidades implementadas na Sprint Review Meeting, quando é realizada uma Sprint Retrospective e os membros do time planejam o próximo Sprint, reiniciando o ciclo.
http://www.dextra.com.br/servicos/scrum.htm
Comentários
Postar um comentário