Desenvolvimento Ágil com Metodologia SCRUM

Projetos de software sempre atrasam

Projetos atrasados, mudança de escopo e insatisfação por parte de quem irá receber o SISTEMA são problemas comuns vividos nos projetos de desenvolvimento de software. Boa parte destes problemas se deve a falta de um processo definido para o desenvolvimento ou no uso de processos inadequando para o desenvolvimento de projetos sem escopo claramente definidos. Isso acontece pois geralmente os processos de desenvolvimento de software são criados por grandes multinacionais para grandes projetos com escopos e papéis bem definidos. Geralmente uma boa ideia ou uma lista de desejos para um novo projeto de software não tem um escopo claramente definido. Muitas empresas de desenvolvimento de software exigem um escopo de seus clientes antes de iniciar um desenvolvimento para poder precificar precisamente o projeto. Definir um escopo pode deixar um projeto demorado e caro além de tolher a riqueza da interação entre o solicitante e o desenvolvedor. Neste cenário - quando não se tem um escopo claramente definido mas sim uma lista de desejos e necessidades do que se espera que o software faça, o modelo de desenvolvimento baseado nas metodologias SCRUM+Kanban permite excelentes resultados num curto intervalo de tempo pois a filosofia "Libere cedo Entregue sempre" direciona as entregas para aquilo que o cliente realmente precisa.

Entendendo o SCRUM

O SCRUM é uma metodologia de desenvolvimento ágil de software com foco em entregas rápidas, incrementais e relevantes. Ele é constituído por um conjunto muito simples de práticas, regras e poucos papéis, utilizadas para gerenciar e controlar todo o desenvolvimento. O foco de todos os envolvidos neste processo é fazer a entrega o mais rápido possível.

O processo de desenvolvimento ágil SCRUM está embasado em três pilares: Transparência, inspeção e adaptação.

  • Transparência: garante que todos os aspectos relevantes ao sucesso do processo se mantenham visíveis e conhecidos por todos de modo a garantir que a entrega feita para o cliente seja equivalente ao que ele realmente pediu
  • Inspeção: é feita com finalidade de se detectar qualquer impedimento que possa vir a prejudicar os resultados da equipe
  • Adaptação: a partir da identificação da irregularidade são feitas adaptações rápidas no processo ou no material em processo, reduzindo a probabilidade de um resultado insatisfatório

A metodologia SCRUM funciona com apenas três papéis, cinco regras e três artefatos.

Os três papéis são

  • Product Owner também conhecido como P.O
  • ScrumMaster também conhecido como S.M
  • Equipe

As cinco regras são

  • Sprint Planning Meeting (Reunião de Planejamento da Iteração)
  • Daily Scrum Meeting (Reunião Diária do Sprint)
  • Sprint (Ciclo de 2 semanas de desenvolvimento)
  • Sprint Review Meeting (Reunião de Apresentação do resultado do Sprint)
  • Sprint Retrospective Meeting (Reunião de Retrospectiva do Sprint)

Nestas 5 regras estão o “coração” do Scrum, onde é feito todo o controle e adaptação necessária para alcançar o sucesso na realização do trabalho

As ferramentas (artefatos) de controle e acompanhamento são

  • Product Backlog (Lista de funcionalidades do produto)
  • Sprint Backlog (Lista de funcionalidades para a iteração)
  • Burndown Chart (Gráfico de acompanhamento do 'planejado x entregue' em cada Sprint)
  • O Scrum utiliza em sua estrutura o conceito do modelo espiral, onde cada ciclo da espiral de desenvolvimento é conhecido como Sprint (Iteração).

Importante: A metodologia de desenvolvimento ágil da 4Linux (Libere Cedo Entregue Sempre) que você vai conhecer na sequência é baseada na metodologia SCRUM mas não segue rigorosamente esta metodologia. Ela foi adaptada para a realidade e necessidade da 4Linux.

Integrando o SCRUM ao Kanban

O Kanban é uma ferramenta de processo criada para a linha de produção da Toyota. Seu principal objetivo é minimizar o trabalho em andamento, evitando assim os gargalos em determinadas fases do processo e os desperdícios da superprodução em outras fases.

Para esse controle o Kanban utiliza 3 regras básicas: visualizar o fluxo de trabalho; minimizar o trabalho em andamento e calcular o tempo médio para conclusão de cada tarefa. Estas regras estão alinhadas com os 3 pilares do SCRUM: transparência, inspeção e adaptação. 

Para visualizar o fluxo do trabalho, o Kanban utiliza um quadro ( vide imagem abaixo) onde são feitas divisões que correspondem as etapas do fluxo do trabalho. Nesse quadro são fixados cartões que correspondem as tarefas a serem executadas. Parte da tarefa é executada em cada etapa do fluxo e após a sua conclusão o cartão é movido para a próxima etapa. Ao passar pela última etapa do fluxo, a tarefa deverá estar concluída.

Integrando o SCRUM ao Kanban

Conhecendo os 3 papéis do SCRUM

No SCRUM existem apenas três papéis para gerência e execução de todo o processo, ao contrário dos processos tradicionais onde existe toda uma hierarquia e definição detalhada de cada papel.

O Scrum exige que exista uma pessoa dentro da CONTRATANTE que tenha uma visão de negócio do produto e que esteja focado no retorno do investimento. Essa pessoa é o Product Owner. (PO). Ele é o responsável por direcionar e prioriza o trabalho da equipe a cada Sprint e por manter os interesses da CONTRATANTE.

A EQUIPE por sua vez é responsável por desenvolver e gerenciar o desenvolvimento do produto. No SCRUM a equipe é composta por volta de 5 a 10 integrantes auto organizados, decidindo pela melhor forma de realizar o trabalho durante a Sprint. A meta da equipe é fazer a entrega.

Para garantir que as práticas do SCRUM sejam seguidas, existe a figura do ScrumMaster (SM). O papel do ScrumMaster é de um facilitador do processo, sendo sua responsabilidade remover todo impedimento encontrado durante o trabalho e gerenciar as regras do Scrum. O ScrumMaster não é o gerente ou supervisor da equipe. A equipe é auto gerenciada.

As ferramentas de controle e o processo SCRUM

O Product Backlog é uma lista com as funcionalidades desejáveis do produto (as funcionalidades são denominadas histórias). O Product Owner prioriza as histórias de acordo com o seu valor para o negócio.

As histórias são textos simples que descrevem uma funcionalidade e devem ser escritas segundo o ponto de vista do usuário. Estas histórias são curtas, simples e claras para que o esforço necessário para implementá-las - chamado de pontos - possa ser o mais previsível e calculável possível.

Durante a reunião de planejamento do Sprint estima-se a complexidade de cada história através de pontos. O P.O. prioriza entre as histórias que estão no Backlog de produto aquelas que ele quer ver atendidas primeiro e a equipe estima a complexidade de cada uma através de pontos. Os pontos são estimados da seguinte forma: escolhe-se uma história de complexidade baixa e de resolução conhecida e atribui-se a ela ponto 2 ou 3 de uma escala específica de pontos, composta pelos primeiros elementos da séria de Fibonacci (1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144...). Desta forma, a escolha de uma quantidade de pontos para uma história, por exemplo o valor 5, significa que o esforço necessário poderá variar entre 3 e 8, sendo 5 o mais provável.

Baseado na pontuação das histórias e na priorização do P.O. monta-se o Sprint Backlog que conterá os itens mais prioritários do Product Backlog a serem desenvolvidos durante o próximo Sprint.

Com o Sprint Backlog montado a equipe faz a Sprint Planing Meeting 2 onde os membros da equipe dividirão as histórias em tarefas e decidirão quem irá assumir cada tarefa. Com isso pronto pode-se começar o Sprint. As histórias e tarefas são dispostas em um quadro Kanban com colunas que demonstram o andamento das tarefas.

Durante a Sprint o acompanhamento do "planejado X executado" será feito pelo Burndown Chart (conforme imagem abaixo) , que é um gráfico mostrando o andamento do Sprint através dos pontos que devem ser entregues no final da Sprint.

 As ferramentas de controle e o processo SCRUM:

Para acompanhamento da Sprint são realizadas as Daily Scrum Meetings, que são reuniões diárias nas quais é possível identificar possíveis riscos e impedimentos do projeto. Essas reuniões são rápidas ( 15 minutos) e são realizadas na frente do quadro Kanban e do Burndown Chart. Nesta reunião os times atualizam o quadro Kanban e respondem a três perguntas feitas pelo S.M. “o que foi feito desde a última reunião?”; “existe algum impedimento?”; e “o que será feito até a próxima reunião?” . O objetivo é encontrar o mais rápido possível os bloqueios do projeto, tudo aquilo que impeça o avanço do desenvolvimento. Se existe impedimentos eles devem ser colocados na fila de impedimentos para que o SM possa buscar solução para o impedimento apresentado.

No final da Sprint é realizada a Sprint Review Meeting (aproximadamente 1 hora) . Nesta reunião, o time apresenta ao Product Owner e outros interessados o resultado do trabalho. Nesse ponto, o produto deve estar funcional, ele já passou por todas as etapas do desenvolvimento: projeto, implementação e testes.

Após a Sprint Review Meeting, é realizado a Sprint Retrospective Meeting (aproximadamente 1 hora). O objetivo dessa reunião é reunir ideias para melhorar o processo. Depois da Sprint Planning Meeting, o Sprint Retrospective Meeting é evento mais importante do processo SCRUM pois é a hora de rever todo o processo e adaptá-lo para que a próxima Sprint seja ainda melhor através de um ciclo de melhoria contínua.

ciclo de 2 semanas

Como colocar preço em um desenvolvimento sem escopo claramente definido?

Sendo a entrega rápida um dos objetivos principais da metodologia de desenvolvimento da 4Linux, a máxima "libere cedo entregue sempre" vale desde o início do projeto.

O desenvolvimento será dividido em 2 fases: "construção" e "evolução".

A fase de "construção" será composta pelo mínimo de funcionalidades necessárias para que o projeto entre em produção e já comece a trazer retorno ao investimento ( libere cedo... ) e também a coletar feed-back dos usuários. A fase de construção tem um "escopo mínimo" fechado na fase de contratação. Durante a fase de construção serão feitas entregas parciais de acompanhamento( sprints) a cada 2 semanas até colocar o software/sistema em produção.

Na fase de evolução acontecem as "entregas incrementais" que também são feitas a cada 2 semanas ( ...entregue sempre) e são compostas por um conjunto de novas funcionalidades priorizadas pelo P.O. . Veja no desenho abaixo como funciona o processo de desenvolvimento ágil da 4Linux:

 

PREÇO EM UM DESENVOLVIMENTO SEM ESCOPO

Baixe Nossa Apresentação

Prestamos serviços de consultoria, suporte e desenvolvimento PHP e Python, atendemos pequenas, médias e grandes empresas de vários segmentos. Somos líderes de mercado em capacitação em ambiente de software livre no Brasil (mais de 50 cursos), nas modalidades presencial e online, com uma equipe altamente especializada. 

 

Baixe Nossa Apresentação Sobre Suporte e Consultoria