Eventos do Scrum – Retrospectiva da Sprint (Sprint Retrospective)

A Retrospectiva da Sprint (Sprint Retrospective), é o último evento dentro da Sprint, ocorre logo após finalizada a reunião de revisão da Sprint e antes do próximo Sprint Planning e é a oportunidade para identificar as lições aprendidas na Sprint.

O foco da reunião não é o produto em si, mas sim o processo. Essa reunião é fundamental para construir uma equipe mais interativa, motivada, produtiva e colaborativa.

Como todos os eventos, esse evento é “Time-Boxed” e tem duração máxima de 3 horas para uma Sprint de 30 dias. Neste evento participam todos os membros do time de desenvolvimento e o Scrum Master. Já o Product Owner não é obrigatório.

Basicamente, são respondidas 3 questões:

  1. O que fizemos de bom e devemos manter?
  2. O que pode ser melhorado?
  3. Como vamos implementar as ações para melhorar?

Continue lendo “Eventos do Scrum – Retrospectiva da Sprint (Sprint Retrospective)”

Eventos do Scrum – Daily Scrum – Reunião diária

Após terminada a reunião de planejamento, é dado início às atividades definidas no backlog da Sprint, que serão realizadas para entregar o item do backlog do produto, ou seja, o trabalho de desenvolvimento para entregar o software pronto é iniciado.

Diariamente, os membros do time de desenvolvimento se reúnem para realizar a “Daily Scrum” ou reunião diária. Essa reunião é um evento Time-Boxed de 15 minutos. É importante que o tempo não seja excedido, mas pode ser menor caso todos já tenham falado e o objetivo for alcançado.

Nesta reunião, devem ser respondidas 3 perguntas básicas:

  1. O que eu fiz desde a última reunião, que contribui para o time alcançar a meta da Sprint.
  2. O que farei até a próxima reunião, para atingir a meta da Sprint.
  3. Há algum impedimento no meu trabalho.

Continue lendo “Eventos do Scrum – Daily Scrum – Reunião diária”

Eventos Scrum – Planejamento da Sprint (Sprint Planning)

A Sprint começa pelo planejamento, logo o Sprint Planning é o primeiro evento oficial do framework Scrum dentro da Sprint.

Essa reunião é realizada por todo o time Scrum, ou seja, Dono do Produto, Time de Desenvolvimento e Scrum Master, dividida em duas partes iguais, com tempo máximo de 4 horas cada parte (total de 8 horas) para uma Sprint de 30 dias (para sprints menores que 30 dias, normalmente o tempo da reunião é menor proporcionalmente) e aonde são respondidas duas questões chaves:

  1. O que será desenvolvido na Sprint?
  2. Como será desenvolvido?

Continue lendo “Eventos Scrum – Planejamento da Sprint (Sprint Planning)”

Eventos do Scrum – A Sprint

O Scrum possui 5 eventos ou cerimônias em seu framework, dos quais, todos são obrigatórios. Esses eventos são todos “Time-Boxed”, tem tempo máximo definido. Apenas o Sprint, uma fez definida a sua duração, ela é fixa e não pode ser encurtado e nem alongado, os demais eventos, podem ser encerrados antes, desde que o seu objetivo tenha sido alcançado.

Esses eventos servem para manter os 3 pilares do Scrum, que são a transparência, inspeção e adaptação, não realizar ou realizar somente parte dos eventos, irão prejudicar esses 3 pilares.

Se caso a empresa ou a equipe decidir não realizar algum destes eventos, por julgar desnecessário, deve-se repensar se a empresa está preparada para o Scrum ou as pessoas não entenderam o Scrum, pois retirar qualquer um destes eventos não é possível implantar o Scrum na empresa. Lembre-se, o Scrum é fácil de entender, mas difícil de dominar.

Continue lendo “Eventos do Scrum – A Sprint”

Scrum Master em Ação

O papel do Scrum Master é de extrema importante dentro de uma organização que deseja implantar o Scrum ou que já o tem implantado.

É ele quem garante que as regras e cerimônias sejam cumpridas e assim aumentar a produtividade e eficiência do time Scrum.

Veja um verdadeiro Scrum Master em Ação no vídeo abaixo:

SSPersonal Manager Web

Olá pessoal,

Acabei de liberar a versão teste do SSPersonal Manager WEB. Sistema on-line, para gerenciamento de finanças pessoais. Em breve, ele conterá novas funcionalidades para organizar seu dia-a-dia, tudo em um único sistema, com acesso pela internet de qualquer dispositivo.

Ele foi desenvolvido para que seja possível acesso pelo computar, tablet e celulares.

Para saber mais, acesse a página do sistema, aqui no blog mesmo.

Como ainda é uma versão de testes, os dados poderão ser apagados quando transferir o sistema para um servidor definitivo e alguns erros poderão surgir (alguns por conta do próprio servidor, que é temporário).

Sugestões de melhorias e implementações futuras, são bem vindas. Deixe nos comentários.

 

Os Papéis do Scrum – O Scrum Master

O último papel descrito no Framework Scrum, é o do Scrum Master. Pode parecer estranho, mas o Scrum Master é uma posição de gerenciamento, não de pessoas, ou do desenvolvimento ou do projeto, mas sim um gerente de processos.

O Scrum Master é um grande facilitador e age como um mentor e defensor do Scrum dentro da organização. Ele apoia o time de desenvolvimento para que as regras do Scrum sejam respeitadas, remove impedimentos, apoia o Product Owner na melhor forma de gerir o Backlog do Produto, divulga o Scrum dentro da organização, explica e faz com que as pessoas entendam o framework.

Continue lendo “Os Papéis do Scrum – O Scrum Master”

Papéis do Scrum – O Time de Desenvolvimento (Development Team)

O time de desenvolvimento, como o próprio nome diz, é o responsável por desenvolver o produto. Ele é responsável por transformar itens do Backlog do Produto em incremento de software potencialmente utilizável. Somente membros do Time de Desenvolvimento entregam incrementos do Software, mais ninguém.

É importante frisar de que o Time de Desenvolvimento, não é feito só por programadores. O time precisa ser composto por todas as competências necessárias para que o produto que se deseja desenvolver, seja construído pelo time, sem dependência de qualquer outra pessoa externa ao time.

Por exemplo, se o produto é um software para Web, desenvolvido em Java com banco de dados Oracle, você irá precisar compor o time com analista de sistemas, programadores Java, webdesign, alguém com conhecimento em Oracle ou até um DBA se for algo muito complexo e testadores. Nenhum item de backlog, selecionado por esse time, poderá ser “terceirizado” para outra equipe. Não é correto fazer por exemplo, com que o Webdesign que está em outra equipe, faça o “front-end” para que o time de desenvolvimento faça o “back-end” e teste a solução. O conceito é produto pronto, do inicio ao fim, da criação das tabela, front-end, back-end e testes finais da solução.

O time de desenvolvimento é responsável ainda, pela definição das tarefas necessárias para que um item do backlog do produto seja considerado pronto, no exemplo acima, as tarefas poderão ser separadas, entre Design da tela, construção da camada de negócio, preparação das tabelas do banco de dados, testes unitários, testes funcionais, testes de regressão e por ai vai. É o time de desenvolvimento quem define essas atividades e o tempo estimado para conclusão de cada uma delas. Para que isso funcione, as pessoas deste time precisam ser auto-disciplinadas, elas não precisam ter um chefe dizendo o que elas precisam fazer, pois elas sabem o que deve ser feito e se auto organizam.

Em resumo, um time de desenvolvimento precisa ter pessoas com habilidades específicas e generalistas ao mesmo tempo. Um time de 3 pessoas, aonde um só faz análise, um só programa e um só testa, não irá funcionar no Scrum. Esse time precisa ter um analista que pode ajudar no desenvolvimento e testar, um programador que pode auxiliar nas definições de análise e testar e um testador, que também faça a análise e monte manual do usuário. O time precisa ser multidisciplinar.

O tamanho do Time de Desenvolvimento, segundo o framework Scrum, precisa ser grande o suficiente para conseguir entregar incrementos de software por completo e pronto para uso e pequeno o suficiente para não ser ágil. Recomenda-se que o time seja de 6 +/-3, ou seja, de 3 a 9 integrantes, sem contar o Scrum Master e o Product Owner. Os mesmos só poderão ser considerados, se eles também fizerem entregas do backlog da Sprint, ou seja, se eles também desenvolverem, seja analise, programação, testes, etc.

Ter um time menor do que 3 integrantes, pode ser que não seja possível entregar softwares por completo e também reduz demais as relações interpessoais. Ter mais do que 9 pessoas, o time poderá ser tornar lento e difícil de coordenar, então, tente montar times de 3 a 9.

Ai vem a pergunta, mas e se eu tiver 20 pessoas na empresa? Simples, monte pelo menos 3 times de desenvolvimento, que poderão trabalhar ou em produtos diferentes (com backlogs diferentes) ou no mesmo produto, compartilhando o mesmo backlog do produto.

Em resumo, o que o Time de Desenvolvimento precisa ter:

  • Conhecimento sobre o Scrum, seus papéis, artefatos, cerimônias e regras.
  • Colaboração, trabalho em equipe é essencial;
  • Atuação com transparência;
  • Buscar o máximo de valor ao negócio;
  • Melhoria contínua;
  • Apoiar o dono do produto a manter o backlog do produto;
  • Auto-organização;
  • Comprometimento;
  • Trabalho com qualidade.

Sem dúvida, a essência do Time de Desenvolvimento no Scrum é o comprometimento total ao projeto, auto-organização e trabalho em equipe, sem isso, o processo não irá funcionar. Se na sua empresa, você não tem alguma dessas 3 qualidades no seu time, melhor trabalhar esses pontos que faltam e só depois implantar o Scrum, caso contrário, você irá se frustrar com os resultados.

Time que não tiver comprometimento, mesmo que seja auto-organizado, não vai funcionar. Um time comprometido, mas que não sabe se organizar e trabalhar em equipe, também não irá funcionar.

Mas existe uma pessoa que pode ajudar nesse processo, esse cara é o “Scrum Master”, que veremos no próximo post.

Até breve e um ótimo dia.