Aplicação dos Seis Chapéus na Retrospectiva

O pai dos seis chapéus é o medico Edward De Bono. É uma técnica que ajuda a equipe a pensar de forma colaborativa e paralela. E isso é muito útil na reunião de retrospectiva, mas deixo claro que não serve apenas para reunião de retrospectiva.

Cada chapéu tem um foco de pensamento. A idéia que a cada troca de chapéu, os integrantes da equipe trabalhem o foco. Ou seja, vistam o chapéu.

O tempo de uma reunião de retrospectiva com os seis chapéus é de uma hora. Claro que pode ultrapassar, dependendo do que esta sendo trabalhado.

Objetivos dos seis chapéus na retrospectiva:

• A equipe discute o foco;
• Evitar discussões inúteis e conflitos;
• Incentivar a participação das pessoas, principalmente dos tímidos.

Neste artigo vamos trabalhar a seguinte ordem dos seis chapéus: azul, branco, amarelo, preto, verde e vermelho.

Chapéu Azul (5 minutos de duração)

Foca os objetivos.

O chapéu azul também é facilitador e condutor da reunião. Também é aconselhável que papel do facilitador ou condutor seja rotativo para estimular o ambiente democratico na equipe.

Chapéu branco (10 minutos de duração)

Foca análise dos fatos e informações. Sem emoções e julgamentos.

Chapéu amarelo (10 minutos de duração)

Foca os pontos positivos.

Chapéu preto (10 minutos de duração)

Foca as críticas, coisas ruins que aconteceram e riscos. Tudo que precisa ser melhorado.

Chapéu verde (10 minutos de duração)

Foca a criação de alternativas ou respostas para o problema.

Chapéu vermelho (5 minutos de duração)

Foca os sentimentos e emoções, sem julgamentos.

No final, retornasse ao chapéu azul. Que tem papel de condutor da reunião. Esse fará uma conclusão da retrospectiva e, através dela terá instrumentos necessários para melhorar a nova iteração.

Fonte:

“6 Thinking Hats Retrospective Plan” by rob bowley:

http://blog.robbowley.net/2009/08/29/6-thinking-hats-retrospective-plan/

“Podcast #3 – Retrospectiva dos 6 Chapéus” by  Luiz Faias Jr:

http://bluesoft.wordpress.com/2010/01/07/podcast-3-retrospectiva-dos-6-chapeus/

“Six Thinking Hats”:

http://en.wikipedia.org/wiki/Six_Thinking_Hats

Ta-ta for now

Escritório Ágil: Um Ambiente Aberto para Comunicação

O ambiente ágil é fundamental para comunicação aberta da equipe, proporcionando uma colaboração eficaz entre a mesma.

O deslocamento em um ambiente ágil deve se fácil. Algumas observações no ambiente ágil:

• Os membros da equipe estão próximos. De preferência de frente um para outro;
• Há uma área da equipe centralizada, onde o trabalho é feito individualmente;
• As paredes são usadas para postagem de notas, mapas, gráficos e demais informativos;
• Os membros da equipe devem ter acesso fácil aos quadros ou gráficos de papéis para colaboração rápida entre equipe.

O que acontece se você não pode colocar todos os membros da equipe na mesma sala? E se membros da equipe estão países diferentes? Isso pode ser um processo de aprendizagem, que independe da localização dos membros da equipe, o objetivo essencial é a entrega de valor para o cliente.

Uma equipe pode ser distribuída, porém os membros desta equipe devem aderir aos princípios da colaboração e aprendizado. Algumas práticas que ajudam são: a teleconferência e a videoconferência. Mas não há nenhuma bala de prata, sem o manifesto ágil e os princípios por trás do manifesto ágil em mente.

Fonte:

“Agile Team Room – Open Office for Communication” by AGILESCOUT.COM

http://agilescout.com/agile-team-room-open-office/

Ta-ta for now

Suíte de Teste usando JUnit

Com o crescimento do número de testes unitários, torna-se necessário uma suíte de teste para gerenciamento da coleção de testes.

No exemplo abaixo, estamos usando a classe TestSuite para gerenciar uma coleção de testes unitários, composta pelos seguintes testes:

• PessoaFisicaTest
• FoneFisicaTest

Código da suíte de teste:

import junit.framework.Test;

import junit.framework.TestCase;

import junit.framework.TestSuite;

public class Suite extends TestCase{

    public Suite(String testName){

        super(testName);

}

public static Test suite(){

TestSuite suite = new TestSuite();

suite.addTestSuite(PessoaFisicaTest.class);

suite.addTestSuite(FoneFisicaTest.class);

return suite;

}

}

Obs.: Os testes executarão na ordem que foram adicionados na suíte.

Ta-ta for now

Dicas para Criar uma Equipe Auto-Organizável

Yves Hanoulle compartilha dicas para criar uma equipe auto-organizável no Agileee Conference 2009:

Vídeo: http://vimeo.com/7874231

Slides: http://www.slideshare.net/YvesHanoulle/leadership-self-organizing-teams

Vale a pena conferir.

Fonte:

http://vimeo.com/7874231

http://www.slideshare.net/YvesHanoulle/leadership-self-organizing-teams

Ta-ta for now

Ambiente Informativo Ágil

A sala da equipe deve refletir o projeto. Qualquer pessoa ao entrar na sala em poucos segundos tem uma base do andamento do projeto.

Práticas para ambiente informativo:

• Scrum (Quando usar Scrum): Um quadro que apresenta o andamento das tarefas, mas sem limitação do trabalho em processo;
• Kanban (Quando usar Kanban): Um quadro que apresenta o fluxo das tarefas e limitação do trabalho em progresso.
• O gráfico de burndown e defeitos;

Todas estas práticas facilitam a comunicação da equipe.

No caso de optar por software de Kanban, Scrum ou outros softwares, a facilidade de acesso ao andamento do projeto deve ser a mesma das ferramentas manuais.

Fonte:

” Livro Scrum e XP direto das Trincheiras” by Henrik Kniberg

http://www.infoq.com/br/minibooks/scrum-xp-from-the-trenches

Ta-ta for now

A Colaboração do Cliente é Fundamental

A colaboração do cliente é fundamental para bom desenvolvimento ágil. Sabemos que um cliente não poderá passar 100% do tempo com equipe. Mas o cliente poderá enviar um representante.

Também temos o papel do PO no Scrum que trabalha com negócio esta em contato com cliente e equipe. Caso PO tenha um perfil mais técnico do que o analista de negócios, a presença de analista de negócios (BA) é necessária para o contato com cliente trabalhando junto PO.

Na verdade, o cliente tem um papel importantíssimo para andamento de projeto de software que usa a cultura ágil.

Fonte:

“Manifesto para Desenvolvimento Ágil de Software”

http://agilemanifesto.org/iso/ptbr/

“Extreme Programming” by Vinícius Manhães Teles

http://improveit.com.br/xp

Ta-ta for now

Vantagens da Cultura Ágil para Requerimentos de Negócios

É importante entregar a cada iteração o maior valor de negócio possível, para que o cliente receba resultado quantificável. As empresas estão sob pressão para entregar resultados e, na maioria das vezes, não conseguem sustentar uma vantagem competitiva, se tiver que esperar um longo período para receber valor de negócio da equipe.

Nem todos os requerimentos têm o mesmo valor para o cliente, alguns requisitos são essenciais para o negócio, outros como infraestrutura não são tão importantes. Os requisitos que refletem o valor do negócio devem receber uma alta priorização a cada iteração. Desta forma, a cada iteração, a equipe agrega valor de negócio para o cliente.

Em suma:

• Identificar os requisitos de um sistema que são importantes para o cliente, muitas vezes é a fase mais importante na medição do projeto de desenvolvimento de software com sucesso;
• Priorizar os requisitos para que o cliente receba o software que forneça resultado quantificável a cada iteração;
• Melhorar o valor de negócio entregue ao cliente a cada iteração;

Fonte:

“Agile’s Advantages for Business Requirements” by AccuRev

http://www.accurev.com/blog/2010/02/04/agile%E2%80%99s-advantages-for-business-requirements/

Ta-ta for now

Falando de Estória

Estórias são escritas em cartões e usadas no planejamento, porém esclareço que são estórias curtas com algumas informações. A equipe utiliza o diálogo com o cliente para conhecer os detalhes de cada estória. Assim, o registro da estória é feito no cartão e serve como lembrete do diálogo entre equipe e cliente. Esse registro envolve o trabalho em conjunto do cliente e equipe.

Um conjunto de cartões de estórias para desenvolvedor o produto do cliente é a famosa lista de requisitos. A tendência é que com o passar das iterações, as estórias de prioridade baixa sejam descartadas, pois geralmente não são utilizadas. Isso é uma vantagem do desenvolvimento iterativo e incremental, saber a cada iteração a satisfação do cliente em relação ao que foi desenvolvido do produto. Por exemplo, depois de dez iterações o cliente fica satisfeito com produto desenvolvido, porque o produto irá suprir suas necessidades. Automaticamente as estórias não desenvolvidas são descartadas.

No planejamento, a equipe estima cada estória e coloca o valor da estimativa no cartão. Com base na velocidade de desenvolvimento da iteração anterior ou utilizando cálculo de fator de foco para estimativa de velocidade, a equipe fornece um orçamento para o cliente e mostra a quantidade de estórias que poderão ser desenvolvidas na iteração que se inicia. O cliente sabendo da estimativa para iteração prioriza as estórias que em conjunto possam gerar valor ao final da iteração.

Exemplo de cartão de estória:

Fonte:

” Livro Scrum e XP direto das Trincheiras” by Henrik Kniberg

http://www.infoq.com/br/minibooks/scrum-xp-from-the-trenches

“Extreme Programming” by Vinícius Manhães Teles

http://improveit.com.br/xp

Ta-ta fo now

Benefícios da Programação em Par

A programação em par é uma das práticas mais conhecidas do método extreme programming. Mas é polemica, nem todas as equipes, pessoas ou empresas visualizam seus benefícios.

Na programação em par temos o piloto que desenvolve e co-piloto que analisa e revisa.

Alguns benefícios da programação em par:

• Aumenta a qualidade do código;
• Aumenta o foco da equipe;
• Muitos desenvolvedores que não apreciam, quando experimentam, gostam da programação em par;
• Trocar os pares freqüentemente facilita a comunicação de toda equipe e a troca de conhecimento, uma alta interação entre equipe;
• Programação em par nivela o conhecimento da equipe;
• Fornece uma revisão de código pelo co-piloto, uma espécie de compilador humano;
• Fornece uma analise do negócio pelo co-piloto.

Fonte:

” Livro Scrum e XP direto das Trincheiras” by Henrik Kniberg

http://www.infoq.com/br/minibooks/scrum-xp-from-the-trenches

Ta-ta for now