Building Minds - o Blog da OnCast

Olá.

Aproveitando o espírito natalino de fé e o final de ano que se aproxima, segue abaixo umas frases que estão no Guide Scrum.

Sei que muitos de vocês são verdadeiras feras mas sempre é bom lembrar de coisas legais em nossa profissão e que reforçam os valores que precisamos manter todos os dias.

Um forte abraço do Marcucci e um ótimo final de ano a todos!

O SCRUMMASTER

O ScrumMaster é responsável por garantir que o Time Scrum esteja aderindo aos valores do Scrum, às práticas e às regras.

O ScrumMaster ajuda o Time Scrum e a organização a adotarem o Scrum.

O ScrumMaster educa o Time Scrum treinando-o e levando-o a ser mais produtivo e a desenvolver projetos e produtos de maior qualidade.

O ScrumMaster ajuda o Time Scrum a entender e usar o autogerenciamento e interdisciplinaridade. No entanto, o ScrumMaster não gerencia o Time Scrum; o Time Scrum é auto-organizável.

O time se auto-organiza para se encarregar e se responsabilizar pelo trabalho contido no Backlog da Sprint, tanto durante a Reunião de Planejamento da Sprint quanto no próprio momento da execução.

O ScrumMaster trabalha com os clientes e a gerência para identificar e designar um Product Owner. O ScrumMaster ensina ao Product Owner como fazer seu trabalho. Espera-se dos Product Owners que eles saibam como conseguir otimizar valor através do Scrum. Se eles não souberem, consideramos o ScrumMaster responsável.

PILARES

1) TRANSPARÊNCIA

A transparência garante que aspectos do processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os resultados. Esses aspectos não apenas devem ser transparentes, mas também o que está sendo visto deve ser conhecido. Isto é, quando alguém que inspeciona um processo acredita que algo está pronto, isso deve ser equivalente à definição de pronto utilizada.

2) INSPEÇÃO

Os diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que variações inaceitáveis no processo possam ser detectadas. A frequência da inspeção deve levar em consideração que qualquer processo é modificado pelo próprio ato da inspeção. O problema acontece quando a frequência de inspeção necessária excede a tolerância do processo à inspeção.

Os outros fatores são a habilidade e a aplicação das pessoas em inspecionar os resultados do trabalho.

3) ADAPTAÇÃO

Se o inspetor determinar, a partir da inspeção, que um ou mais aspectos do processo estão fora dos limites aceitáveis e que o produto resultante será inaceitável, ele deverá ajustar o processo ou o material sendo processado.

Esse ajuste deve ser feito o mais rápido possível para minimizar desvios posteriores.

Existem três pontos para inspeção e adaptação em Scrum.

3.1 A Reunião Diária é utilizada para inspecionar o progresso em direção à Meta da Sprint e para realizar adaptações que otimizem o valor do próximo dia de trabalho.

3.2 A Revisão da Sprint e de Planejamento são utilizadas para inspecionar o progresso em direção à Meta da Versão para Entrega e para fazer as adaptações que otimizem o valor da próxima Sprint.

3.3  A Retrospectiva da Sprint é utilizada para revisar a Sprint passada e definir que adaptações tornarão a próxima Sprint mais produtiva, recompensadora e gratificante.

A finalidade da Retrospectiva é inspecionar como ocorreu a última Sprint em se tratando de pessoas, das relações entre elas, dos processos e das ferramentas.

A inspeção deve identificar e priorizar os principais itens que correram bem e aqueles que, se feitos de modo diferente, poderiam ter deixado as coisas ainda melhores. Isso inclui a composição do time, preparativos para reuniões, ferramentas, definição de “pronto”, métodos de comunicação e processos para transformar itens do Backlog do Produto em alguma coisa “pronta”.

No final da Retrospectiva da Sprint, o Time Scrum deve ter identificado medidas de melhoria factíveis que ele implementará na próxima Sprint. Essas mudanças se tornam a adaptação para a inspeção empírica.

SOBRE O TIME SCRUM

Se o time sentir que se comprometeu com mais do que podia, ele se encontra com o Product Owner para remover ou reduzir o escopo do Backlog do Produto selecionado para a Sprint.

Se o time sentir que sobrará tempo, ele pode trabalhar junto ao Product Owner para selecionar mais do Backlog do Produto.

Quando um Time começa com o Scrum, Sprints de duas semanas o permite aprender sem se afundar na incerteza. Sprints desse tamanho podem ser sincronizadas com outros Times adicionando-se dois incrementos juntos.

admin Metáforas

Muitas vezes temos a necessidade de executar um mesmo teste repetidas vezes mudando apenas alguns parâmetros. A solução mais simples caso sejam poucos testes é replicar o método de testes e mudar as variáveis, ou então criar um método com as asserções desejadas e chamá-lo com os diferentes parâmetros.

Ambas as possibilidades apresentadas pecam, pois não respeitam o princípio DRY. Uma solução muito mais elegante é usar os testes parametrizados, uma possibilidade que para quem usa JUnit existe a partir da versão 4.

O funcionamento é simples: um método no teste, anotado com Parameters, deve retornar uma coleção de arrays, que serão os parâmetros de execução:

@Parameters
public static Collection<Object[]> parameters() {
    List<Object[]> list = new ArrayList<Object[]>();
    list.add(new Object[] {"asshole!", "jerk!"});
    list.add(new Object[] {"what the hell?", "what the heck?"});
    return list;
}

Cada array desta coleção fornecerá os argumentos para o construtor do teste, possibilitando assim que estes valores sejam salvos em campos da classe, e utilizados por quem precisar dos mesmos:

public ProfanityFilterTest(String input, String output) {
    this.input = input;
    this.output = output;
    filter = new ProfanityFilter();
}

A classe de testes deve ser configurada para rodar com um runner específico, o Parameterized:

@RunWith(Parameterized.class)
public class ProfanityFilterTest {
[...]

Com estes passos básicos, ao rodar a classe testes, cada teste será chamado uma vez com os parâmetros fornecidos.

Para conferir o código completo baixe ProfanityFilter.java e ProfanityFilterTest.java.

Renato Besen Arquitetura de Software, Auto-gestão