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

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.

Empresa muda do eXtreme Programming para o Scrum. Hein?

Como assim? A gente viaja e lê coisas por aí e não vê tudo… não vou citar aqui nome de empresa nem pessoas, mas vou só dar uma opinião sobre o assunto do título.

Primeiro, que eu acredito que Scrum é uma excelente forma de um time começar a trabalhar com Agilidade. Excelente para criar ritmo, de conhecer cerimônias, de trabalhar transparência e uma série de valores que são importantes em times ágeis.

Só que chega um momento que este time não vai mais conseguir avançar no assunto. A velocidade não aumenta, e ainda aparecem problemas relacionados a testes, a escrita de histórias, as entregas não estão consistentes, entre outros assuntos.

Este time vai precisar melhorar processos de teste, processos de aceitação com o cliente, de deploy, enfim, questões relacionadas a práticas de engenharia de software.

Quer dizer que Scrum é ruim? Não… o Scrum é incompleto de propósito. Ele é excelente para estruturar um time e ajudar em questões de planejamento e gestão de projetos.

Não é que o time deixa de usar Scrum e passa a usar por exemplo o eXtreme Programming. Simplesmente o que o time faz é agregar aos seus processos atuais práticas de engenharia de software muito bem documentadas pelo eXtreme Programming, assim adicionando mais qualidade de software ao seu dia a dia. Seja do XP ou do FDD (Feature Driven Development) ou de outra prática que este time andou estudando, exemplo Getting Real. O que se busca são melhores formas para desenvolver produtos.

Mas não para por aí. Depois este time vai querer eliminar mais restrições ainda e vai querer entender onde ele está sendo limitado, e vai querer encontrar formas de entregar mais, de minimizar variabilidade, de aumentar fluxo e aí este time começa a entender e ler mais sobre Lean, começando a fazer sentido a importância dos processos de melhoria contínua (Kaizen!) e eliminação sistemática de desperdícios.

Aí este time começa também a ler mais sobre algumas coisas que vem acontecendo no mundo de hoje, exemplo DevOps, Continuous Delivery, Startups, Lean Startup, e por aí vai…

O ponto é que ao ler uma matéria estilo case, estilo press release, de uma empresa que usava eXtreme Programming há oito anos e escreve no título que passa a usar Scrum… bom, desculpe… mas não faz sentido!

Dizer que está se deixando de usar o XP para usar Scrum, não faz sentido por alguns motivos:

- XP tem foco nas disciplinas de engenharia de software

- Scrum tem foco em cerimônias que apoiam a gestão de projetos iterativos e incrementais.

- As práticas organizacionais do eXtreme Programming são baseadas no Scrum, Planning Game, Stand Up Meeting e por aí vai. Logo, elas não concorrem!!

- Se a empresa estava usando XP há mais de 8 anos, ao passar a usar Scrum sem seguir com as disciplinas do eXtreme Programming estaria fazendo um retrocesso. Se vai deixar de focar em testes automatizados, seja unitário, funcional ou de integração, seja usando TDD (Test Driven Development) ou não. Vai deixar de usar integração contínua, e outras disciplinas essenciais nos dias de hoje em times de desenvolvimento? Eu acho que não… porque não faz sentido!

- O Scrum não define nada sobre vários assuntos. Quando se inicia um “Sprint”, é uma grande caixa preta. Coloque ali os processos que você quiser. Eles devem fazer sentido para sua equipe e para o tipo de trabalho que é desenvolvido. Quando se fala de backlog, escreva do jeito que quiser. Scrum não vai definir nada. Por isto que ele pode funcionar em qualquer área de atuação, não apenas Tecnologia da Informação.

- O normal em uma empresa que está usando eXtreme Programming entregando iterações curtas e muito feedback dos usuários seria passar a adotar princípios e práticas do Lean, para eliminar mais e mais restrições, passando a funcionar em um ciclo de desenvolvimento incremental.

- Uma equipe XP que trabalha com iterações, pode usar todas as cerimônias do Scrum no seu dia a dia e adicionar a isto as práticas de engenharia de software que são formadas como disciplinas do eXtreme Programming.

O mercado brasileiro precisa aprender. E mesmo com todo o movimento nacional, de Agile Brazil, eventos locais, de grupos de usuários locais, a exemplo do GUMA-RS aqui do Rio Grande do Sul, infelizmente os assuntos de verdade não aparecem. Infelizmente acabo vendo matérias sobre estas, que faz parecer é que esta empresa na verdade nunca usou eXtreme Programming.

Quer conhecer mais sobre eXtreme Programming? Fica a dica de uma publicação que fiz com Guilherme Lacerda, com o título Conhecendo o eXtreme Programming. Este foi um trabalho feito na disciplina de Engenharia de Software da UFRGS, ministrada pelo Professor Marcelo Pimenta.
Referência:
Wildt,D. ; Lacerda, G. Conhecendo o eXtreme Programming (XP). In: Coletânea dos Trabalhos de CMP-102 – Engenharia de Software 2010, PPGC-UFRGS, 31 pp, disponível na internet em http://www.slideshare.net/dwildt/conhecendo-o-extreme-programming

en: Card, Conversation, Confirmation (a.k.a 3C’s)

index cards
Index cards are a great way to keep track of new ideas for a software product. The good thing about them is because they are limited. You can’t get all information into one. And that’s a really good thing. Trust me.

Back in 2003 when I started learning eXtreme Programming, I’ve heard of a story from Ron Jeffries about 3C. And that’s something truly valuable I teach every time I have the chance to.

The 3C concept is based on writing down an idea to an index card, so we can remember about that idea later on. That’s our first “C”.

What we need next is to generate conversations. We need to validate that new idea, with people that can help on that topic. The best thing about having conversations, is to come up with examples that can validate the idea. If it’s a calculation, samples of those. This way, the card becomes “executable”. A card may have extra documentation to help on that process.
And that’s our second “C”. These conversations can help the team to identify some card attributes, like a sense of “value”, priority, risk, whatever-attributes-your-team-likes-to-use.

The third “C” is about confirmation. Having conversations with customers will help us to understand how to validate that card, to make sure that new functionality is ready to go. So that’s what you have to look for, confirmation! From your customers! They will validate and make your idea grow.

What else for index cards?


I saw Jessica Hagy’s Indexed website by a reference from my sister. You can find a book from her at Amazon if you want to.

The thing is: an index card can do a lot to you. Even help you to keep a great conversation flow with your customers. Try it!

en: The Lean Startup Experience

I saw an infographic @pinterest asking if we are getting into another “dot com” bubble. That infographic was built by Udemy, great job. I agree with that, and I believe we have better tools and techniques today to help companies to play in startup mode.

One of the things we surely need to focus on is the concept “Lean Startup“. Lots of ways to describe can be found. My way, as an eXtreme Programming and Agile practitioner is to think about a real way to help companies to leverage products to a real experience. With real software engineering + marketing and customer development practices.

But… delivering fast is not enough. Actually it never was! We need to understand who is caring about what is delivered. We need to measure not only progress with real software, but measure how are our clients enjoying the experience during the process. So yes, we have to speak to final users, get feedback, understand what are they looking for. They know the next killer feature of your product. True.

So playing with startups and lean startups is about building experiments and testing ideas and learning from those experiences. Really about learning.

Having that in place, we can grow ideas. I like that term. It’s not about building ideas. But actually grow them.

Last week of June/2011 during Agile Brazil 2011 I’ve done a workshop called “From vision to production”, where I was focused on talking to people about techniques teams using Agile Methodologies like Lean and eXtreme Programming to deliver products and features can use. How do you know if those features are the top ones?

During the practice, I’ve challenged teams to understand about how to build something that can be used to test the idea. Not tested by some xUnit framework, but tested by the market. If possible not even using a real software but using simple tools like a survey, interviews and paper prototyping.

Simple and small experiments that can help a team to learn faster. And prepare it to the next experiment. One of them may result in a software. One of them may result in many new users. One of them may take the company to a next level.

The whole thing is not about getting rich or getting money in a easy way. You know why?

One of those experiments may shutdown your idea, and “help you” to move to some other venture. But, how long would that take? One week? A Month? One whole year?

The thing is about failing as fast as possible, so you can pivot, so you can change direction, plan again, and try again.

Getting to the end…

This post was about sharing things I’m playing a lot.
I’m helping a product to grow for seven months now, since its official launch.
It’s not easy. But it can be fun.

And the “experiences” I will share here, will be related also to other ideas I will help to grow.

Failure is expected. Always. But I’m not about winning all the time (although it’s very good).
I’m about learning.
And you should be too. :-)

So, to finish “The Lean Startup Experience” post, we should think about a song…

Hey Yo (The pivot song :-))
Hey Yo, where you goin’ with that idea in your head?
Hey Yo, I said, where you goin’ with that idea in your head?
I’m goin’ down to shut my old one baby
I caught her metrics and they are poor man
I’m goin’ down to start a new one baby
I’ll start messin’ round again

* Any relation with The Jimi Hendrix Experience… is that I’m a left handed guitar player too. Just that. \o/