NoSummit – Um evento sem cúpulas

Manoel Pimentel lançou a ideia do NoSummit, um evento que não possui cúpulas e é 100% auto-organizado. Pessoas se colocaram como catalizadores de ideias e definiram pontos de ebulição espalhados pelo Brasil. Cada ponto de ebulição escolhe um assunto para tratar. Simples assim.

O resultado é o evento que ocorre em várias cidades neste sábado, 22 de setembro de 2012.

Em Porto Alegre, estarei puxando um destes pontos, com o apoio da ThoughtWorks. Faremos das 15h as 18h um OpenSpace sobre Empreendedorismo, puxando assuntos como Lean Startup, Desenvolvimento de Produtos e Serviços, MVPs, Métricas, Métodos Ágeis e outros assuntos que possam aparecer e ser de interesse dos participantes.

O processo é todo emergente e de longe pode parecer totalmente caótico. Eu acho totalmente excelente. Porque permite que as pessoas se adaptem ao contexto. Não sabemos quem vai aparecer lá. Quais são suas demandas, dores e expectativas relacionadas ao assunto empreendedorismo. Alguns podem querer contar histórias, outros podem apenas querer ouvir, outros podem querer tirar dúvidas sobre os primeiros passos, outros podem estar com dúvidas existenciais.

Quer fazer parte disto? Então se apresse e se inscreva, porque as vagas são limitadas!

Eventbrite - NoSummit - Porto Alegre

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!

#StartupDojo!! Mais um chegando a Porto Alegre!

Dia 18 de setembro vamos nos reunir no Tecnopuc para mais uma edição do #StartupDojo Porto Alegre!

Bateu a curiosidade? O que é o StartupDojo? O StartupDojo é um ambiente para praticar modelos de negócio. E antes disto é um espaço de networking. E antes disto é um espaço para aprender e ensinar.

Então, se você não sabe nada sobre criação de produtos e negócios, venha aprender e ganhar novas referências, links e amigos. Se você já conhece do assunto, venha compartilhar e ensinar.

As vagas são limitadas! Interessou? Se inscreva!

E neste evento teremos uma apresentação do pessoal da Rally, que está patrocinando o evento. E legal contar com o apoio do Grupo RBS também concedendo o local para fazermos o evento!

E ah, se quiser ficar atento a próximas oportunidades de evento, ficam os canais:

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.

Projeto Startup no DUG-RS inicia sábado 26 de maio de 2012!

Uma das coisas que acredito, é que um desenvolvedor deve ser capaz de desenvolver um software por completo. Gestão, comunicação, análise, codificação, testes, automação, infra… e desenvolvimento de produtos! Ser um empreendedor, ser inovador, sempre em busca de desafios.

Mas como conseguir evoluir em todas estas áreas? Primeiro, o ponto é entender quais destas áreas você realmente gosta e quer ter excelência técnica. E buscar formas de criar, aprender, inovar.

O Grupo de Usuários Delphi do Rio Grande do Sul inicia neste sábado o “Projeto Startup“. A ideia é reunir a comunidade Delphi e criar algo, com as seguintes características:

  • Conceber um produto, usando técnicas de desenvolvimento de produtos, como se este grupo fosse uma startup. Criar experimentos e buscar criar um produto que cresça e ajude um determinado segmento de clientes.
  • Desenvolver e promover o software livre, criando um ambiente de colaboração e liberdade para quem desenvolve com Delphi e quer aprender e ensinar.
  • Permitir que as pessoas possam evoluir em áreas onde tenham interesse, seja análise, design, usabilidade, programação, infra estrutura.
  • Buscar inovação, sejam com tecnologias do Delphi ou tecnologias relacionadas, exemplo Amazon Web Services.
  • Permitir evolução técnica da comunidade Delphi.
  • Uso de práticas e disciplinas e princípios das Metodologias Ágeis.

E onde eu entro nesta? Bom, fundei o DUG-RS em 2004 e estarei sempre ajudando a comunidade a se manter. E neste evento específico, estarei iniciando este trabalho com o pessoal, através de uma versão “extra-super-light” do Workshop Da visão a  Produção, ajudando o pessoal a desenvolver um novo produto, entendendo o que pode ajudar algum nicho de mercado e entregar de forma efetiva e constante um produto desenvolvido de forma colaborativa pela comunidade.

Então é isto. Sábado, 26 de maio de 2012, a partir das 08h45min, na Faculdade Dom Bosco em Porto Alegre, inicia o Projeto Startup do DUG-RS! Se você gosta de delphi, análise de negócios, desenvolvimento de produtos, startups, open source, métodos ágeis, este é o momento! Apoie e ajude!

Não quero gerentes, mas pessoas capazes de gerenciar

Em um determinado post, o Nicolas Iensen, fala assim:

O maior equívoco da história da gestão foi acharem que não existe gerencia sem gerentes.

Eu comentei em um evento do Grupo de Métodos Ágeis do RS que na minha equipe não existem gerentes. Mas estava sendo injusto. Muito injusto.

O ponto é que eu acredito em algumas coisas como:

  • Quanto mais tempo de empresa as pessoas possuem, mais liberdade elas terão.
  • A responsabilidade de uma pessoa aumenta de forma diretamente proporcional a sua liberdade.
  • Não acredito em gestão centralizada – acredito em pessoas diferentes liderando assuntos que fazem sentido para elas. Lidere suas causas! Assim seu trabalho vira diversão.
  • Todos do time são responsáveis por todos do time. Ou não é trabalho em equipe?
  • Auto organização – quem sabe a melhor forma de funcionar, de acertar uma tática, é o próprio time.
  • Auto gerenciamento – quem sabe onde está doendo e definir ações, retomadas, ações em crise, também é a equipe.
  • Não acredito em gerentes, mas sim em pessoas capazes de gerenciar. E através de vivência prática, trabalhando e vivendo problemas reais.
  • As pessoas devem ser capazes de gerenciar seu próprio tempo. Assim podem gerenciar melhor o tempo do seu time e por consequência da empresa.
  • … dá para fazer um livro disto, mas enfim, estes já mostram meu ponto.

O grande “problema” disto pode ser quando a equipe fica muito grande. Já passamos por situações assim e em breve vamos passar novamente. Grande para mim é uma equipe com mesmo foco, com mais de 20 pessoas ok? Você pode escolher ter várias destas células com poucas pessoas, e o problema volta a ficar menor na gestão da equipe, e aumenta na gestão entre equipes, mas isso também pode ser assunto para outro post. 🙂

Mas… medo não tenho. Porque eu tenho uma equipe que ao encontrar um desafio de comunicação, vai enfrentar este desafio. E aí vai para outro ponto que para mim é muito importante. Atitude! Que atitude você quer presente na sua equipe?

Joel Spolsky fala em se “falar menos“, e os problemas de comunicação quando temos “muitas pontas” para amarrar.  Os problemas que acabamos tendo em grandes grupos. Acredito nisto, mas o bom senso aparece nestes casos. Vamos trabalhar em duplas ou trios para um determinado assunto. Não com a equipe toda. E vamos ter eventos onde todos serão envolvidos. E saber dosar isto. E saber dos prós e contras de ter um excesso de comunicação ocorrendo.

Se não controlarmos estes pontos, não será possível trabalhar no trabalho, porque vamos ficar apenas em reuniões e discutindo assuntos que podem ser discutidos em um grupo menor de pessoas. Por isto que devemos ter foco. E confiar no trabalho da equipe.

REST e os Códigos de Resposta HTTP

Em uma reunião, se pergunta como avisar o usuário do resultado de uma chamada de um serviço, em se usando uma abordagem baseada em REST.

Minha resposta foi algo simples tipo, ah, 200 vai indicar que funcionou show de bola, 201 quando um objeto foi inserido, 400 quando a requisição for mal feita, 501 quando o usuário chamar um recurso que não temos. Note o uso correto da palavra recurso.

Fiquei falando um minuto mais ou menos, sobre alguns códigos de retorno HTTP. Eis que hoje olhando o Twitter do Daniel Barden encontro este tweet da @DanaDanger, que resume tudo isto:

Como se tornar um melhor mensageiro

Eu sempre tive uma necessidade de ter mensagens e apoiar quem está assistindo uma apresentação através de texto, muito texto. De vez em quando algumas imagens.

Em 1999 fiquei vermelho, e bem nervoso, quando fiz a apresentação do meu trabalho de conclusão. Depois outras lembranças que tenho são a partir de 2002, quando comecei a palestrar de forma mais constante. E não parei desde então. E a cada nova apresentação, uma nova lição, uma nova piada para fazer a platéia rir, e por aí vai.

Sempre me preocupei em passar a mensagem da forma mais objetiva possível, e prática. Isto vem me ajudando ao longo do tempo a fazer palestras menores. Normalmente minhas palestras funcionam no estilo “TED Talk“, focadas em no máximo 20 minutos e gerando alguma mudança. Nada de indiferença! Também gosto muito das palestras menores ainda, as Lightning Talks, com 5 minutos de duração. E eu ajudo a organizar um evento muito legal sobre elas, a #Desconf.

Mas voltando ao assunto de como melhorar suas apresentações… um dos pontos para eu melhorar era ter alguns modelos. Durante muito tempo eu trabalhei como instrutor oficial da Borland/CodeGear e hoje Embarcadeiro. E desde 1998 eu participava de eventos sobre Delphi, com apresentação de funcionalidades, sendo um “mero ouvinte”, e ali tive contato com um cara que sempre foi uma referência na arte de apresentar: Renato Quedas. Ele é um cara que eu respeito muito, e tive a oportunidade de conviver com ele alguns anos, ele na qualidade de Master Trainer, ajudando nós instrutores e consultores e se posicionar melhor em sala de aula, nas apresentações e por aí vai.

Depois estamos falando em 2006/2007, e uma das ações que me ajudaram a ver e buscar algo diferente foi quando tive contato com o material do Garr Reynolds e um livro muito legal chamado Presentation Zen. São dicas legais, mais focadas no design e formas de apresentar as informações para gerar um impacto mais positivo no público.

Outra ação foi o ToastMasters. Já ouviram falar deste programa? Em uma das empresas que trabalhei, existia um programa interno, e eu participava, conseguindo a cada semana ver pessoas apresentando e podendo colher técnicas diferentes. E aprender com o erro dos outros. Isto me fez buscar na internet também diferentes técnicas. Aí comecei a conhecer caras como Guy Kawasaki e Larry Lessig e o Lessig Method. Eles seguem sendo grandes referências para mim.

Claro… Steve Jobs por exemplo e seus keynotes milimétricos também são legais, sem dúvida! Mas o ponto é… que eu sempre gostei do improviso.

Muito.

Em uma situação, fui convidado para palestrar em uma semana acadêmica, e nesta oportunidade tinha decidido que iria falar sem ajuda do Keynote. Cheguei no evento faltando menos de 1h para minha palestra. Aí comecei a ter umas ideias e pronto, em menos de 30min selecionei algumas imagens e montei uma apresentação para me apoiar no evento. E foi show! Pode acontecer de dar errado? Claro. Mas aí é o estilo de cada um… alguns gostam de desarmar bombas. Eu gosto de palestrar contando minhas histórias, improvisando. 🙂

O que eu procuro quando estou montando uma linha de palestra? Momentos para fazer rir/chorar/emocionar, momentos para fixar conhecimento (aprendizado), momentos para impactar (mudança). E isto vai em um ciclo dentro do tempo da palestra. Seja uma palestra de 5 minutos ou um curso de 80 horas.

Deixo o vídeo que apresentei no TTLabs Summit realizado em abril de 2011, falando sobre estas questões. Foi um vídeo de 5 minutos:

E a apresentação que está disponível no slideshare:

Desktop notifications, don’t do that!

Wow, great new feature from Google! You can now enable desktop notifications even using the web browser! That will help you 100 times more to be… interrupted! That’s a bad thing!

If you use GTalk embedded in a browser window as I like to use, here’s a tip to avoid enabling these desktop notifications.

I keep one of my browser windows on top of all others, so I can see it’s title bar, no matter what application I’m using besides the browser. When someone starts to chat with me, the title changes, and it kind of interrupt me, but gives me some seconds to finish up what I’m doing and then I can give the right attention to the chat window. Or defer the talk to the end of my working cycle.

Notifications for emails… no, you don’t want that. You drive your life, not emails. Build a way to make sure you are not every 5mins checking for new messages and cleaning up your inbox.

So, if I can give some tips, here they are:

  • Avoid desktop notifications. Check every desktop notification you have and verify if that one is really important. If not, disable it! But hey, if you work on some mission critical support team… leave that notification active ok?! 🙂
  • Make sure you have a routine to avoid checking emails every 5mins. If something is really important, teach people to call you. Or to ping you by instant messaging, SMS, os some other option that is really going to interrupt you, but for a good reason. If people call you and it’s not that urgent, also tell them they can use emails, and then you can answer back with more time. Actually, in your time.