Scrum e as práticas de engenharia de software

O Scrum é uma metodologia adaptativa e voltada à gestão. Deixa lacunas em termos de riscos e engenharia. Por isso, o Scrum, de acordo com o contexto de cada projeto, deve ser combinado com outras práticas como, por exemplo, a gerência de riscos do PMI e práticas de engenharia de software. Neste post cito 2 práticas de engenharia do XP (Extreme Programming):

- Refactoring (refatoração): muito importante para que o código tenha um design cada vez mais limpo, elegante e flexível. Como o Scrum é um processo ágil, ocorrem vezes em que, devido ao prazo de entrega do release ao final do Sprint, um determinado código é entregue sem estar de acordo com o ideal. Isto gera um débito técnico (tech debt). Ou seja, quem entregou o código mentaliza que assim que houver a possibilidade, este código será melhorado, se tornará mais semântico, que aquele dado método que está muito grande será quebrado em métodos menores etc. E implementa estas melhorias! Para o usuário do software, o refactoring não muda nada, já que as mesmas funcionalidades serão mantidas. Porém, para o Time que desenvolveu o software, é um grande ganho de qualidade e, também, de tempo quando for necessário atender a requisitos de evolução relativos à manutenção, adaptação ou adição de novas funcionalidades.

- Pair Programming (programação em pares): visa a propriedade coletiva do código. Tem como meta a melhoria contínua do código e a idéia de que, em casos onde haja alguma dificuldade de imaginar a implementação de alguma estória, 2 cabeças pensem melhor que uma. Devido à questão da propriedade coletiva do código, a sugestão é que não se utilizem sempre os mesmos pares. O piloto deve trocar com o co-piloto e, também, as pessoas devem formar pares diferentes. Ao mesmo tempo, ninguém é obrigado a trabalhar em par o dia inteiro. Pode, por exemplo, trabalhar em par na parte da manhã e individualmente na parte da tarde. Ou vice versa! Pode trabalhar individualmente e, quando sentir a necessidade, devido a algum bloqueio de inspiração, programar em par. A programação em pares não deve ser imposta, mas uma atitude de convencimento através da conversa e da pontuação de seus benefícios.

Muitas empresas ainda não entendem a utilidade da programação em pares, com a mentalidade “pago o salário individualmente, não em par”. E muitos desenvolvedores dizem que é uma prática “furada”, sem nunca tê-la experimentado. Não se pode dizer que algo é ruim sem antes experimentar.

Scrum: por que fazer reuniões diárias?

O objetivo das reuniões diárias é que não somente o Scrum Master, mas todos os membros do Time, tenham um acompanhamento e feedback diário do Sprint. Nesta reunião, cada membro da equipe deve responder a 3 simples perguntas:

- O que fiz ontem?
- O que farei hoje?
- Houve algum impedimento?

É uma reunião rápida, realizada em pé e com um timebox de no máximo 15 minutos. Caso o(s) membro(s) reporte(m) impedimentos, o Scrum Master é responsável por, somente após a reunião, tratá-los e removê-los. Exemplos de impedimentos: solicitações referentes a outras atividades que não digam respeito ao projeto, problemas no servidor de teste, dificuldades com a tecnologia, entre outras.

O melhor horário para realizar esta reunião é na parte da manhã, quando todos os integrantes do Time tiverem chegado. Caso não seja possível, pode-se realizá-la em outro horário na parte da manhã ou da tarde. Mas é importante que sempre seja realizada em um horário fixo.

Esta reunião não é para expor um membro da equipe caso esteja com alguma dificuldade. É exatamente para que haja um feedback precoce e quaisquer dificuldades sejam sanadas. Assim, o Time se manterá sempre produtivo. Por outro lado, esta reunião também faz com que o Scrum Master detecte facilmente o “morcegão”, aquele integrante que "não quer nada com nada". Este tipo de profissional detesta Scrum.

Um bom teste para verificar se os membros do Time entenderam o significado da Daily Scrum é o Scrum Master deixar de aparecer na reunião um dado dia. Se o Time se reunir e realizar a reunião, isto significa que entendeu o seu significado.

Assim como todas as práticas sugeridas pelo Scrum, a reunião diária não deve ser imposta no estilo: “vocês vão fazer esta reunião diária porque eu sou o chefe e quero assim”. Deve-se, através da comunicação e negociação contínua, fazer com que as pessoas entendam o seu significado, passem a aderir e, conseqüentemente, apoiar sua utilidade e reconhecer seu grande valor no processo.

Scrum (Parte 4): Reuniões

Scrum – Reuniões (Cerimônias):

Sprint Planning (Planejamento do Sprint): o que vamos construir no Sprint e como iremos construir. O Product Owner (PO) explica o escopo (o que é mais importante para a dada iteração). Ele escreve as tarefas de cada história em alto nível (funcionalidades a serem construídas). Depois, o time estima a complexidade. O time escolhe o sprint backlog e escreve as tarefas para cada estória. O Time Boxed máximo para esta reunião é de 4 horas.

Daily Scrum (Reunião Diária): reunião diária para levantar como está ocorrendo o sprint. A sugestão é fazer a reunião todo dia pela manhã, se possível no começo do dia, se todos chegam no mesmo horário. O que fiz desde a última reunião? O que farei até a próxima reunião? Algum impedimento? Esta reunião é feita em pé para que seja rápida. O Scrum Master anota os impedimentos, se houverem, para depois da reunião tratá-los. Não é uma reunião de discussão. A reunião não é para o chefe, mas para o time. Um bom teste para o chefe é faltar uma vez ou outra para verificar se a equipe faz a reunião. Se não fizer, então a equipe não entendeu o propósito das reuniões diárias. Nesta reunião ninguém pode ficar exposto por não estar conseguindo realizar certas tarefas. A função do Scrum Master neste caso é escutar, depois "chamar para um café", detectar as dificuldades e pensar numa solução para esta pessoa (ex.: treinamento, ou colocar algum profissional mais experiente para auxiliá-lo). Esta reunião dá visibilidade a um processo que é empírico por natureza. As reuniões diárias visam também uma melhora constante da comunicação entre as pessoas e isso faz com que muito do que teria que ter sido escrito possa ser resolvido na base da conversa. E se uma pessoa sai da empresa, em uma equipe de 5? As outras 4 pessoas conhecem muito bem o projeto e dividirão as estórias que a pessoa que saiu deixar. Nada substitui uma boa conversa. A reunião diária leva ao feedback constante do projeto. É ESSENCIAL que pelo menos o Scrum Master e o time inteiro estejam presentes. Já o Product Owner deve estar disponível para ser consultado pelo Time diversas vezes ao longo do dia, para o caso de dúvidas em relação aos requisitos ilustrados nas estórias. Time boxed máximo: 15 minutos.

Sprint Review (Revisão do Sprint): onde o Tiime mostra o resultado do sprint (Team demo). É informal, sem slides. Todos podem participar, mas somente 'pigs' (Time, Product Owner e Scrum Master) podem falar. O Product Owner dará a nota para o Sprint, podendo aceitá-lo ou rejeitá-lo. O time boxed máximo é 2 horas.

Sprint Retrospective: lições (o que foi bom? O que precisa melhorar? O que o time pode resolver? O que a empresa precisa resolver?). Participam Product Owner, Scrum Master e Time). O time boxed máximo é de entre 2 horas.

Scrum (Parte 3): Papéis

Scrum – Papéis:

O Scrum possui os seguintes papéis:

1) Comprometidos:

- Product Owner (Dono do Produto): interage com os stakeholders (participantes do projeto) constantemente para alinhar a visão, ou seja, garantir que o seu entendimento, do Time e do Scrum Master está de acordo com as expectativas com o cliente. A palavra final do produto é do Product Owner, mas ele deve ser colaborativo com a equipe e não deve agir como um gerente de projetos centralizador. Ele depende do time e o time depende dele. No Scrum o foco é a equipe! Faz a interface Time e Scrum Master x Cliente. Atende aos requisitos do cliente e, por isso, se comporta como o próprio cliente do projeto. Desta forma, deve estar disponível ao Time para elucidação de dúvidas referentes aos requisitos contidos nas estórias. Tem responsabilidade sobre a elicitação dos requisitos e, conseqüentemente, o controle do Product Backlog. Sabe, define e redefine o nível de importância das estórias. Por exemplo, em caso de cronograma apertado, pode retirar uma estória do Sprint e deixá-la para o próximo. Monitora o projeto contra os objetivos de ROI e visão, prioriza e refina o Product Backlog medindo seu sucesso. Decide datas para apresentação dos releases. E, também, aceita ou rejeita o resultado do trabalho realizado pelo Time no final do Sprint. O perfil do Product Owner é muito mais voltado às questões do negócio do que às questões técnicas do projeto.

- Scrum Master (Mestre Scrum): guardião do processo, monitorando-o para garantir o sucesso da equipe. Remove obstáculos (por exemplo, problemas no servidor de teste). Blinda o time contra perturbações externas (por exemplo, outras pessoas fora da equipe que ficam pedindo favores e atrasando o Sprint). Promove rápidas reuniões diárias a fim de monitorar o andamento do processo. Organiza as reuniões de planejamento, retrospectiva e revisão de cada Sprint. Protege valores e princípios (não pode ser um profissional genérico, tem que entender de software e como é o dia-a-dia do desenvolvedor). Mantém a equipe mais funcional e produtiva (dentro do budget, busca ferramentas de apoio, trabalha motivação, consegue cursos para a equipe etc). Apóia e incentiva a colaboração no time; Facilita integração. O Scrum Master pode até ajudar a equipe de desenvolvimento (por exemplo, dar um upgrade no Hybernate) para acelerar o processo, mas não é parte do Time. Ele não aloca tarefa, ou seja, não diz "você vai implementar esta estória". O time gerencia e auto-organiza o próprio trabalho. Mas ele pode sugerir: por exemplo, ele percebe que um membro do time escolheu uma estória para a qual ainda não tenha habilidade suficiente para implementar. Ele vai conversar e negociar sobre o fato, para que o membro do Time escolha uma estória mais condizente com a sua habilidade. É responsável por manter o equilíbrio.

- Team (Time): Desenvolve as estórias do Sprint Backlog. Expande as estórias em tarefas mais detalhadas. Completa 100% de cada tarefa escolhida. Diariamente inspeciona o projeto para atingir os objetivos do Sprint. Normalmente é pequeno (5 a 9 pessoas). O Product Owner e o Scrum Master são outros papéis, não fazem parte do Time. Ou seja, a equipe pode ter 9 integrantes do Time mais o Product Owner mais o Scrum Master. É importante que o time tenha múltiplas habilidades distribuídas (ex.: profissional com habilidades SQL, outro de orientação a objeto, outro de teste, outro de webdesign, outro de redes etc). O time do projeto deve estar full time allocated, sem impedimentos ou interferências externas. Se não puder, definir quais e quantas pessoas "bombeiras" (ex.: 2) deverão dar suporte a outro(s) projeto(s). O Time é auto-organizado e responsável pela qualidade e em estimar complexidade das tarefas. Os bombeiros sentem a vantagem de não serem obrigadas a estarem 100% comprometidas com o projeto, mas sentem a desvantagem de não conseguir focar no projeto como gostariam.

2) Envolvidos: Clientes e usuários finais.

Scrum (Parte 2): Preceitos

Scrum – Preceitos

- Indivíduos e interações são mais importantes que processos e ferramentas.

- Software funcionando é mais importante do que documentação pesada.

- A colaboração com o cliente deve sobressair em relação à negociação do contrato. Isto é uma via de mão dupla, mas se o cliente percebe o nosso interesse no projeto, a parceria tende a ocorrer naturalmente.

- Responder a uma mudança é muito mais importante que seguir o plano. O Scrum, por ser adaptativo, acolhe mudanças. A equipe trabalha para produzir aquilo que traz valor ao negócio. Se uma regra do negócio mudar, o Scrum acolhe as mudanças e as implementam. O Scrum não tem dó nem piedade de jogar um projeto fora se o barco estiver rumando em um sentido oposto. Mas isso se aplica melhor a um ambiente organizacional interno. Em empresas que prestam serviços para outras empresas, a negociação terá de ser feita de forma mais abrangente, pois envolve contrato e custo.

- É colaborativo na sua essência e ideal para projetos de desenvolvimento de software em um cenário onde os requisitos mudam constantemente.

- Não fala sobre muitas disciplinas que o RUP e o XP implementam, mas não impede e estimula que adaptemos estas disciplinas. É mais focado na gestão do processo, enquanto o RUP e o XP são mais focados nas questões de engenharia.

- Cada composição de processos de engenharia deve ocorrer de acordo com cada contexto organizacional. Não se podem engessar as questões de engenharia de software. Por exemplo, escolher Scrum como processo e não atentar às lacunas que ele deixa.

- O Scrum aceita mudanças e não condena erros. Erros de cronograma, por exemplo: ao invés de apresentar o incremento com 10 estórias estimadas implementadas, apresenta o produto com 6 estórias implementadas. As outras 4, joga para o próximo sprint. Assim, a velociadade da equipe vai sendo ajustada de sprint em sprint até chegar a uma estimativa próxima do ideal.

- Comunicação melhorada, comprometimento, verdade e transparência.

- Times auto-organizados: o time é auto-organizado dentro dos limites delegados pelo Scrum Master, que é o guardião do processo. Quanto mais tempo um time está junto, mais conhecimento um do outro há e, portanto, melhor será a produtividade e a qualidade do projeto.

- Produto progride em sprints de 15 dias cada.

- Rever os problemas e levantar as lições aprendidas para melhoria constante do processo.

- Software funcionando, sempre como entrega. Ao final de cada sprint, o time deve apresentar um release, que deve ser um potencial entregável. Isto faz com que o cliente já tenha os subsistemas do software em produção e trazendo ROI (retorno ao investimento) a cada sprint de 3 semanas, o que é muito mais produtivo e lucrativo do que esperar meses ou anos para o projeto como um todo ser concluído.

Scrum (Parte 1): Introdução

Scrum - Introdução

Segundo o dicionário, Scrum significa “uma parte de um jogo de Rugby”. Em um jogo de Rugby os jogadores movem-se rápido para tentar apanhar a bola.

No mundo dos negócios, Scrum é um método ágil, iterativo e incremental para o Gerenciamento de Projetos, baseado nos princípios da comunicação, colaboração, simplicidade, negociação, alinhamento do negócio e resposta rápida ao mercado e à mudança constante dos requisitos.

Este método moderno compartilha os poderes, não possui aquela figura do gerente de projeto centralizador que o PMBOK defende.

Com Scrum o foco é na Equipe!

É compatível com CMMI 3 e ISO9001. Porém, somente a utilização do Scrum não basta (não é a bala de prata), uma vez que é uma metodologia voltada para a gestão de projetos, deixando lacunas em relação a questões de engenharia de software e riscos.

Deve-se analisar o que pode ser mesclado com Scrum, de acordo com o contexto de cada projeto, como por exemplo:
- Práticas como gerência de riscos do PMI;
- Disciplinas de engenharia do XP: trabalhar orientado a testes (TDD: Test Driven Development), refactoring, programação em pares e integração contínua.
- Disciplinas de engenharia do RUP: gerenciamento de configuração e mudanças.

Em empresas que utilizam processos tradicionais, ou nenhum processo consagrado, não necessariamente deve-se quebrar todos os paradigmas e sair adotando Scrum. Mas pode-se ir adotando práticas aos poucos para melhorar o trabalho, a organização e a produtividade.