Profissionais TI - Pra quem respira informação

Muito se fala em framework, técnicas ágeis de desenvolvimento de software, em equipes auto gerenciáveis, e etc.

Mas algumas pessoas ainda tem dificuldade para entender o básico do Scrum, um dos frameworks ágeis mais utilizados e conhecidos mundialmente falando.

E lá vamos nós.. 

Antes de qualquer coisa, vale a leitura no Manifesto Ágil, onde os princípios básicos são:

• Indivíduos e interação entre eles mais que processos e ferramentas
• Software em funcionamento mais que documentação abrangente
• Colaboração com o cliente mais que negociação de contratos
• Responder a mudanças mais que seguir um plano

O Manifesto completo pode ser lido nesse link aqui.

Pronto. Agora podemos falar de Scrum!!

O QUE É?

Scrum é um framework! Dentro qual pessoas devem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível. Scrum não é um processo ou uma técnica para construir produtos; é um framework dentro do qual você pode empregar vários processos ou técnicas. O framework deixa claro a eficácia relativa das práticas de gerenciamento e desenvolvimento de produtos, de modo que você possa melhorá-las.

Logo: não é uma metodologia, não é um processo.. é um FRAMEWORK!!!!!

QUEM USA?

Várias empresas conhecidas utilizam práticas ágeis para desenvolvimento de software, entre elas:

• Microsoft
• Google
• Yahoo!
• Philips
• Siemens
• Nokia

TIPOS DE PROJETOS FEITOS COM SCRUM

• Software comercial
• Desenvolvimento de projetos internos
• Projetos de preço fixo
• Aplicações financeiras
• Sistemas embarcados
• Sistemas 24×7
• Games
• Websites

PAPÉIS NO SCRUM

PRODUCT OWNER

O Product Owner (PO) é um membro da equipe de Scrum que é responsável pela visão do produto, pelos itens do Backlog de Produto (requisitos) e sua priorização, do ponto de vista empresarial. Ele é o “dono do produto” no time.

EQUIPE DE DESENVOLVIMENTO

São os membros da equipe que são responsáveis pelas tarefas de desenvolvimento de software dentro de uma equipe de Scrum, indo da especificação de requisitos, codificação e testes. É quem realmente “põe a mão na massa”.

Sobre o tamanho da equipe de desenvolvimento :

• Menos de três membros na equipe diminuem a interação e resultam em um ganho menor de produtividade;
• Equipes de desenvolvimento menores podem encontrar restrições de habilidades durante a Sprint, gerando uma Equipe de Desenvolvimento incapaz de entregar um incremento potencialmente utilizável;
• Havendo mais de nove integrantes é exigida muita coordenação. Equipes de Desenvolvimento grandes geram muita complexidade para um processo empírico gerenciar.

Nota: Aqui onde trabalho mantemos um time de 6 pessoas no desenvolvimento. Funciona bem tranquilo a interação.

SCRUM MASTER

Responsável por ajudar a equipe (e a empresa) a aplicar o Scrum e entender o uso em um projeto. Aqui chamamos de “guardião”, que nos mostra as regras e o que precisamos fazer no time para as técnicas ágeis andarem conforme esperamos e não ocorrerem desvios.

EVENTOS DO SCRUM

Eventos prescritos são usados no Scrum para criar uma rotina e minimizar a necessidade de reuniões não definidas no Scrum. O Scrum usa eventos time-boxed, onde todo evento tem uma duração máxima. Isto garante que uma quantidade adequada de tempo seja gasta no planejamento sem permitir perdas no processo de planejamento.

SPRINT

Um ciclo fixo, ou iteração, durante o qual a equipe de desenvolvimento deverá transformar requisitos selecionados em um incremento do produto potencialmente entregável.

A Sprint é o coração do Scrum! Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior. As Sprints são compostas por uma reunião de planejamento da Sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e a restrospectiva da Sprint.

Nota: Aqui já utilizei sprints de uma semana para medir produtividade do time e como se comportariam com a forma de trabalho, mas em projetos complexos percebi que sprints de duas semanas são melhores quando contém requisitos maiores. Recomendo não ser maior que duas semanas para manter a colaboração do time fluindo.

SPRINT PLANNING

Essa é a reunião para o planejamento da Sprint, o que iremos realizar no período de tempo definido pela equipe. Olhamos para quantas pessoas temos, o tempo disponível e o número de dias e avaliamos o que podemos entregar e o que nos comprometemos a entregar.

Após isso, debatemos o conceito de “pronto”, quando vamos considerar requisitos como “pronto”. Se é validado pelo cliente, se é testado e implantado em produção.. Aqui depende muito do que você considera o “pronto” nos projetos.

Definimos também um objetivo da Sprint. Por exemplo: Gerar Nota Fiscal Eletrônica. E no final da Sprint é isso que temos que ter entregue.

REUNIÃO DIÁRIA

Eu, particularmente, considero um dos eventos mais importantes a reunião diária. É aqui que pegamos os gargalos do time de desenvolvimento, aqui que detectamos as dificuldades que estão acontecendo e que tarefas as pessoas estão executando!

E assim como é tão importante, a reunião diária possui algumas observações importantes:

• A reunião tem duração de 15 minutos;
• É realizada todo dia no mesmo local com a equipe em pé;
• A reunião não é feita para passar um status ao Scrum Master e sim para o time de desenvolvimento debater;
• Somente o time de desenvolvimento pode falar ou opinar;
• Reuniões diárias facilitam a execução de tarefas, melhoram a comunicação e a colaboração entre a equipe;

Baseada em três perguntas:

1. O que foi feito desde a última reunião?
2. O que será feito até a próxima reunião?
3. Quais os obstáculos que estão no caminho ou o que está impedindo de continuar?

Nota: Seja pontual e destaque a importância desse evento. Os membros da equipe elogiam muito esse tipo de ação, pois permite que todos se sintam envolvidos nos projetos e opinem no bom desenvolvimento do produto.

REVISÃO DA SPRINT

Ao final da sprint é feito uma reunião com a equipe para avaliar como foi o andamento do ciclo definido para execução das tarefas do desenvolvimento. Para uma sprint de um mês essa reunião tem duração de 4 horas, quanto menor a sprint, proporcionalmente a reunião é menor.

Aqui o Srum Master verifica o que ficou “Pronto” e o que não está “Pronto”.

Adaptações do backlog acontecem nessa reunião também! Dessa reunião surgem várias dicas de como planejar o próximo ciclo de trabalho da equipe. Preste atenção nesses insights.

REUNIÃO DE RETROSPECTIVA DA SPRINT

A Retrospectiva da Sprint ocorre depois da Revisão da Sprint e antes da reunião de planejamento da próxima Sprint. Esta é uma reunião time-boxed de três horas para uma Sprint de um mês. Proporcionalmente um tempo menor é alocado para Sprints menores.

Importante destacar junto com a equipe os itens que foram bem executados e os itens que podem ser melhorados, e a partir daí, formar um plano de ação para melhoria do dia-a-dia do time de desenvolvimento.

A Retrospectiva da Sprint  fornece um evento dedicado e focado na inspeção e adaptação, no entanto, as melhorias podem ser adotadas a qualquer momento.

Nota: Reuniões de retrospectiva deixam a equipe mais unida, é uma ótima forma de pegar o feedback das práticas que estão sendo utilizadas, eu particularmente, gosto muito.

Acima são apenas algumas coordenadas e definições de princípios utilizados no framework Scrum, lembrando que os papéis, eventos e artefatos são imutáveis, mas o framework serve como base para outras técnicas e metodologias também. Podendo ser adaptado a realidade de cada time ou empresa. Scrum somente é Scrum quando usado na totalidade.