Referências para aprender Metodologias Ágeis?

Deixo aqui dois links que considero ainda muito atuais para quem quer aprender metodologias ágeis:

1) Em 2009, fiz um post no blog do GUMA-RS sobre livros, sites e outros recursos legais sobre o assunto.

2) Em 2011, fiz uma survey sobre eXtreme Programming junto com o Guilherme Lacerda, e ali fizemos uma base falando de várias metodologias ágeis. Também muita referência para quem está buscando aprendizado, nas últimas páginas do documento. E claro, o artigo em si dá uma bela visão sobre o assunto.

E para descontrair, deixo dois vídeos engraçados sobre Scrum, e com várias coisas sobre o que não fazer.

Continuar a ler

About these ads

Para viver uma grande retrospectiva? Criando um momento para aprendizado e melhoria contínua!

É preciso antes de tudo entender que:

Independente do que descobrirmos, entendemos e acreditamos que todos fizeram o melhor trabalho que poderia ser feito, dado o que era sabido no momento, habilidades, recursos disponíveis e a situação em questão.

Esta é a Primeira Diretiva para retrospectivas. Todos vamos entender que foi feito o melhor trabalho que poderia ser feito. Também entendemos que trabalhamos com profissionais que se dedicam ao que fazem e possuem consciência das suas responsabilidades.

Montei um vídeo para falar do assunto e nele vou comentar sobre seis etapas importantíssimas que devem ser levadas em um exercício de retrospectiva:

Continuar a ler

Agile Kickstart – Papo sobre Cultura Organizacional e Cultura Ágil

Fiz uma palestra para uma galera fera de Porto Alegre sobre cultura organizacional e cultura ágil.

Um time que está iniciando o caminho nas metodologias ágeis, deve ter um foco muito forte na cultura. No trabalho de entender sua cultura e ver formas de como trabalhar cultura de prevenção, cultura de aprendizado e cultura de melhoria contínua.

Nesta palestra falo um pouco sobre eXtreme Programming, sobre Scrum e sobre Lean, sempre puxando aspectos importantes que um time deveria dar atenção quando o assunto é a mudança cultural.

Dia 19 e 20 tem evento do GUMA-RS + TecnoTalks!

Uma série de dinâmicas para você aprender mais sobre metodologias ágeis e boas práticas de programação.

No dia 20 (dia 2) estarei colaborando com o evento, com uma eXtreme Hour.

O evento vai começar com um pequeno tutorial sobre eXtreme Programming e depois faremos a dinâmica.

É uma hora bem intensa trabalhando nela.
E depois fazemos um fechamento, uma retrospectiva.

Uma dinâmica para brincar de Métodos Ágeis – A hora extrema!

A prática é a melhor forma de demonstrar e criar conhecimento. Desenhar, refletir, discutir, concordar e discordar.

A primeira vez que participei de uma dinâmica da hora extrema (eXtreme hour), foi em 2004, e o exemplo utilizado foi a criação de um caixa eletrônico. Hardware e software. :-)

Desde então, sempre que tenho a oportunidade, faço a dinâmica para poder ensinar um pouco sobre Agilidade e demonstrar disciplinas do eXtreme Programming aliadas a práticas que ajudam a maximizar comunicação e compreensão do que se quer alcançar no software.

Que materiais você precisa para fazer a eXtreme Hour?

Cartões para se poder escrever as histórias e brincar com o conceito 3C.
Folhas de papel brancas e coloridas
Canetas coloridas
Réguas
Tesouras
Fitas adesivas
Colas

Para que tudo isto? Para se poder montar telas, fazer mockups, e poder trabalhar com a prática do paper prototyping. Nesta uma hora, provaremos as histórias através da “execução” dos protótipos de papel.

E quanto tempo dura a dinâmica? A dinâmica deve durar 1 hora! O tempo total do evento pode ser mais de 1 hora, considerando uma ambientação com agilidade e eXtreme Programming, e depois um fechamento do evento.

Considere que você vai fazer de duas a três iterações, e que neste tempo está incluído o papo inicial do cliente, e também uma retrospectiva da dinâmica. O cliente segue disponível durante toda a dinâmica, a menos que você adicione uma restrição para ele “sumir” por alguns minutos. E assim o time poder ver como se comporta. Eu normalmente faço duas iterações. Elas já servem para demonstrar as ideias e surgem muitos pontos de discussão a partir disto. E normalmente crio restrições em alguma das iterações para ser mais difícil falar com o cliente.

Comentei que o exemplo usado é sobre construção de caixa eletrônico, com seu software e hardware. Aqui então mando uma lista que itens que você pode vir a requisitar para as equipes construírem:

  • No hardware do caixa eletrônico, o seu formato. Pensar na forma da retirada de dinheiro, se tem leitor de código de barras, forma de entrada do cartão (chip, magnético ou se vai fazer leitura da digital). Se vai ter impressão de recibos ou envio dos mesmos por email?
  • Tipos de uso pelo cliente, se vai fazer uso com o cartão do banco ou sem o cartão do banco. Exemplo, sem o cartão é possível fazer impressão de extrato ou saldo. Para fazer saque e pagamento, será necessário cartão do banco.
  • Sobre funcionalidades do software, temos várias opções, com saque, consultas de conta, pagamentos com ou sem código de barras, transferências, doc e ted, e outras funções que um caixa eletrônico possui. Escolha um banco e pense nas funcionalidades que o caixa eletrônico oferece. Dica: ao pensar no saque, pense em limitações de valor e horário, para que os times possam exercitar situações de exceção e erro.

IMG_4806

E sobre todas estas possibilidades, você deve indicar para as equipes coisas que quer ou que gostaria de ter. Não necessariamente precisa indicar o que é prioridade. :-) O que normalmente ajuda a gerar resultados bem diferentes e interessantes. A prioridade pode ficar como algo “não falado” nos primeiros minutos da explicação, para ver se as equipes vão fazer perguntas ao cliente ou se elas vão simplesmente executar o que o cliente falou, na ordem que ele falou. Que não necessariamente vai ser a ordem de importância. O ponto aqui é ver se as equipes estão buscando entrega de valor e comunicação com o cliente, aproveitando a presença do mesmo.

Costumo dividir as equipes em 7 pessoas. Evite muitas equipes, para que possa gerenciar tudo sendo apenas 1 cliente.

Quanto ao tempo, uma sugestão de uso pode ser a seguinte:

  • 3 mins – As equipes se organizam e definem quem faz o que (quem faz design, escrita de histórias, validações, a criação dos protótipos, tira dúvidas com o cliente, manter o tempo, e por aí vai). Lembre que as equipes devem ser multidisciplinares. Então as pessoas podem se ajudar em atividades.
  • 7 mins – Apresentação do problema. Aqui você como facilitador usa sua imaginação e pensa em funções que o caixa eletrônico vai ter, qual o público alvo e restrições do jogo, exemplo tempo disponível para tirar dúvidas, e outras questões neste sentido.
  • 15 mins – Primeira iteração. Nesta iteração, o time deve fazer planning (2mins de sugestão), execução da iteração e retrospectiva. Na metade do tempo da iteração, deve fazer uma “diária”. Então considere que cada dia termina depois de 7mins. E neste momento existe 1 min de reunião diária para o time alinhar o que está ocorrendo. No décimo terceiro minuto, o time deve fazer sua retrospectiva da iteração, para entender o que pode ser melhorado para a próxima iteração.
  • 5 mins – Tirar dúvidas com os times e mostrar insights que foram vistos durante a primeira iteração. Normalmente equipes focam demais em planejamento e não em execução. Outras equipes focam demais em execução. Outras equipes não se organizaram e todos fazem de tudo e não entregam nada. Aqui não se resolve nada muito profundo, o objetivo é dar pequenas dicas para deixar visível aos times oportunidades de melhoria na sua comunicação e tática.
  • 15 mins – Segunda iteração. Mesmo ciclo da primeira iteração, os times tentam entregar mais um grupo de funcionalidades.
  • 15mins – Retrospectiva do exercício, aqui serve como momento de reflexão e gerar uma discussão com os participantes sobre agilidade e metodologias ágeis.

E era isto! Espero que todos se divirtam!

Deixo algumas fotos da dinâmica que ocorreu no Agile Games Night, evento que ocorreu no UniRitter/Porto Alegre em junho de 2012.

E agradecimentos ao Thiago Esser! Ele ajudou a priorizar este post! Espero que possa ser útil!

Caso tenha interesse em levar esta dinâmica para sua empresa, ou evento, ou alguma palestra, faça! Só peço uma coisa em troca! Faça um post contando da experiência e comente por aqui fazendo uma referência! Quero saber quem anda brincando com a eXtreme hour por aí!

Update 24/set/2012Thiago Esser manda feedback da dinâmica que ele fez!

Porque você não deve testar seu software!

Dia 23/agosto tenho uma palestra no evento do Grupo de Usuários de Teste de Software do RS. O evento ocorre em Porto Alegre, na PUC-RS a partir das 19h15min.

Depois complemento este post com um resultado da palestra, mas de imediato deixo o resumo da palestra:

O objetivo é mostrar todos os benefícios de não testar software. Ao melhor estilo “dilbert”, ir contra as práticas, que acabam sendo uma forma diferente de refletir e aprender um determinado assunto. Falar dos “benefícios” :-) de se não testar e não se preocupar com a qualidade do seu software. E principalmente toda a emoção que estas práticas irão trazer para o dia a dia do seu time. Tudo isto através de uma reflexão coletiva com a platéia.

Convido a todos para irem assistir esta palestra e participar de todas atividades da noite do GUTS-RS.

UPDATE!

Claro que a palestra foi uma “tirada” sobre equipes e profissionais que ainda acreditam que são muito bons e que testes, automação e outras técnicas para garantir qualidade não se aplica a eles. E também para empresas que consideram os processos de teste como algo “inútil”.

Fora histórias que vivi no passado de empresas que vendiam seus serviços ao mercado com ou sem testes. Até projetei nos slides o que seria esta empresa que “consegue” fazer entrega sem testes. :-)

Depois comecei a puxar aspectos de algumas metodologias ágeis e trazer algumas reações que já vi equipes e pessoas terem a respeito das práticas e sua associação com processos de teste e de garantia da qualidade.

A mensagem no final, é sempre lembrarmos que o processo de testes deve ser uma atividade de prevenção. Nunca de reação. Que o modo de medição do profissional de testes, não pode ser atrelado a quantidade de defeitos que a pessoa acha. E sim a qualidade que este profissional consegue adicionar na sua equipe de trabalho. O quanto ele consegue fazer funcionalidades passarem por todo o ciclo de trabalho e chegarem a produção de uma forma mais consistente. Pareamento com analistas, desenvolvedores, foco total na criação de conhecimento.

Fecho o post com a apresentação realizada hoje.

Uniinfo 2012 – Palestra “Da métrica a diversão” na Semana Acadêmica da Unisinos!

Nesta quarta-feira 30 de maio estarei palestrando no Uniinfo, a Semana Acadêmica de Informática da Unisinos.

Estarei fazendo por lá a palestra “Da métrica a diversão“, uma palestra que gosto muito, por poder discutir assuntos como formação de equipes, melhoria contínua, e podendo mostrar práticas de automação de testes, discutindo eXtreme Programming e Lean. Dependendo do lado que for a discussão, ainda pode dar tempo de bater um papo sobre carreira e Lean Startup.

A palestra começa as 21h, no Auditório Central da Unisinos São Leopoldo. A dica é estacionar próximo do Bloco 1A, entrando pelo portão A. Auditório Central fica localizado em frente ao Bloco 1H.