Scrum no Burndown

Gosto de olhar para o Scrum e pensar nele sendo uma filosofia de trabalho e que, se analisarmos mais a fundo, não deixa de ser uma filosofia de vida.

Em nossa trajetória de vida planejamos tudo o que gostaríamos de fazer e em determinados momentos paramos para realizar um balanço e realinhamento dos planos. Quem tem este saudável hábito consegue reconhecer falhas antes mesmo de afetarem significativamente suas metas. Muitas vezes os próprios planos são alterados  por uma ou diversas razões, afinal a vida é um mar de possibilidades e, nestas paradas para reavaliação é que conseguimos identificar as correções necessárias para atingirmos os novos objetivos.

Planejar requer olhar para o presente e estar atento ao cenário em que está inserido:

  1. O que eu quero fazer? (meta)
  2. O que eu preciso fazer? (tarefa)
  3. O que é prioritário fazer? (relevância)
  4. Como posso fazer? (meio)
  5. Quando posso fazer? (requisito para começar)
  6. Existe algum impedimento? (dificuldades)
  7. Quando posso concluir? (prazo)
  8. O que eu fiz atende as expectativas? (resultado)

Antes de qualquer coisa é necessário que esteja muito claro, para você e para as pessoas envolvidas ao seu redor, o que você quer realmente fazer. Isto é importante para que haja uma colaboração entre as pessoas responsáveis para o cumprimento desta meta.

Tendo a meta estabelecida claramente, é hora de saber o que é preciso fazer, efetivamente, para se aproximar do objetivo. Muitas vezes você não sabe o que realmente deve ser feito, mas existe sempre alguém, entre as pessoas envolvidas, que saberá esta informação, ou seja, a importância evidente de todo o grupo estar ciente de onde querem chegar.

Quando se tem em mente o que é preciso ser feito, fica fácil determinar a prioridade de execução para que todas as pessoas envolvidas colaborem e gastem suas energias na mesma direção. Sem dúvida este esforço coletivo e harmonioso vai levar com maior rapidez e eficiência o grupo ao cumprimento de cada tarefa e, consequentemente, atingir a meta principal.

Uma vez identificado o que deve ser feito e qual a prioridade, é hora de determinar os meios para a realização, ou seja, a melhor maneira de executar cada tarefa. Analisar o melhor método de executar algo requer entender se existem requisitos a serem satisfeitos antes de começar o trabalho. Identificar eventuais impedimentos e delegar para que alguém do grupo, com habilidades referentes, esclareça paralelamente, certamente dará uma dinâmica maior.

Após as dificuldades sanadas e nenhuma questão pendente, você tem condições de estabelecer uma estimativa para a conclusão desta tarefa que o grupo identificou como prioritária, analisou e desmistificou dúvidas e dificuldades existentes. Uma vez que todos estes cuidados foram tomados, a estimativa tende a ser o mais próxima da realidade.

Tarefa executada e sua proposta, dentro do seu entendimento, foi cumprida. Agora é preciso confrontar o resultado obtido com o que foi solicitado. Se estiver tudo de acordo, o esforço aproximou o grupo do objetivo principal mas, se precisar de algum ajuste está em tempo.

Note que todo este exercício feito dentro de pequenos intervalos de tempo nos permite realizar correções pontuais na trajetória sem que haja uma perda de tempo significativa. Você pode aplicar esta filosofia nas realizações da sua vida, assim como em projetos, sejam eles em qualquer área. Especificamente vamos abordar tudo isto dentro de projetos de TI através do Scrum.

Mecanismo Scrum

scrumLifecycle

Eu mencionei, anteriormente, a respeito da importância das questões a serem levantadas em curtos espaços de tempo e, também, sobre as pessoas envolvidas para que sua meta principal seja atingida. No contexto anterior poderíamos estar falando até mesmo do papel que sua família desempenha na sua vida para que você chegue ao seu tão almejado título de Doutor e presidente de uma grande multinacional. Mas aqui vamos tratar da abordagem de uma equipe de trabalho multifuncional e auto-gerenciável.

Não existe uma fórmula a ser calculada para encontrar datas de entregas no Scrum. A preocupação está em entregar pacotes funcionais para que o cliente veja o resultado esperado a cada semana, colocando um fim nos intermináveis projetos onde os problemas somente aparecem na entrega do produto final, impedindo que o cliente comece a fazer uso do produto contratado.

O Time Scrum é composto pelo Product Owner, o Time de Desenvolvimento e o Scrum Master, que serão melhor descritos e estudados em artigos próprios que vou escrever. O Time Scrum escolhe qual a melhor forma para completar seu trabalho, em vez de serem dirigidos por outros de fora do Time. Times multifuncionais possuem todas as competências necessárias para completar o trabalho sem depender de outros que não fazem parte da equipe. O modelo de time no Scrum é projetado para aperfeiçoar a flexibilidade, criatividade e produtividade.

O mecanismo básico de funcionamento do Scrum determina a elaboração de um produto completo a ser entregue. Este produto é composto por uma lista de funcionalidades e chamamos de Product Backlog.

O Product Backlog é fracionado em pequenos pacotes funcionais. Cada pacote é chamado Sprint Backlog e deve ser entregue no término de cada período proposto chamado Sprint. A duração de um Sprint é, conceitualmente, composta por 30 dias úteis. Eu gosto de colocar desta maneira porque já precisei remodelar alguns parâmetros do Scrum de acordo com o perfil e necessidades da empresa ou de um cliente ou até mesmo de um projeto específico. O que quero dizer é que Scrum não é uma metodologia engessada, mas sim um conceito de trabalho, um framework que deve ser adaptado às circunstâncias encontradas.

É importante ter uma definição de “Pronto” comum ao Time de Desenvolvimento e ao Product Owner, ou seja, determinar o mínimo de exigência para que o produto seja aceito e validado pela área a ser atendida. A cada final de Sprint apresenta-se o produto ao Product Owner e, dando o termo de aceite do pacote, agenda-se a melhor data para implantação. Sim, isto mesmo, colocar o pacote em produção para que a área comece a desfrutar desta parcela do produto solicitado. Este é um dos grandes diferenciais quando completamos todo o ciclo de trabalho no Scrum. Esta é a razão de haver um bom planejamento dos pacotes e um grande conhecimento de negócios por parte do Product Owner.

Agora é hora de partir para o próximo Sprint e começar todo o ciclo novamente para a entrega do próximo pacote.

Este é um resumo do mecanismo Scrum e vou detalhar os papéis e artefatos que compõem este framework, mas farei em um artigo exclusivo porque o assunto será um pouco extenso. Quero colocar sempre as customizações possíveis, experiências obtidas e até algumas sugestões para que possam extrair o melhor do Scrum em sua empresa.

Anúncios

6 Respostas para “Scrum no Burndown

  1. Pingback: Product Owner dita as regras | Andrey Kurka·

  2. Pingback: Scrum Master “Agile Man” | Andrey Kurka·

  3. Pingback: Scrum no Burndown | Profissionais TI·

  4. Pingback: Desenvolvimento Versátil | Andrey Kurka·

  5. Pingback: Artefatos e ferramentas Scrum | Andrey Kurka·

  6. Pingback: Microsoft: uma plataforma produtiva | Andrey Kurka·

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s