Responsible Design

Meus amigos deveriam ver isto: InfoQ: Responsive Design (Kent Beck)

(infelizmente, sem tempo para escrever a respeito...)

Exceptional Software Explained: Embrace Error

Depois de ouvir um keynote do Robert M. Lefkowitz (aka. r0ml) na PyCon 2007 sobre The Importance of Programming Literacy, virei fã desse cara...


PDF com os slides sobre The Importance of Programming Literacy

Sua forma de conduzir seus discursos é fantástica, fora o "meta-discurso", já que na maior parte do tempo ele faz justamente o que está sendo pregado no discurso, seguindo as diversas etapas da retórica.

Hoje encontrei um vídeo da OSCON 2008 no qual ele fala sobre sua metodologia de desenvolvimento, baseada nas comunidades de software open source.

Lefkowitz compara MSF, XP, e sua metologia de software Excepcional de forma muito bem humorada e com profundos desdobramentos:

Domingo de treinamento Scrum

Continuando meu relato sobre o treinamento de Scrum que tivemos na globo.com neste final de semana, agora vou falar do segundo dia.

No fim do sábado estávamos falando sobre os Papéis de Scrum, e foi esse tema que iniciou a manhã de domingo. Já no sábado tivemos bastante discussão sobre como isso estava sendo feito na globo.com e como acreditamos que deveria ser.

A problemática está em torno de que os papéis do processo não são como posições ou cargos na empresa. Pelo que pude perceber com o pouco tempo de empresa e com o contato com o pessoal que participou do treinamento, isso não está tão claro para todos os times. Muitos Scrum Masters eram gerentes no processo cascata, e não aderiram a Agilidade. Vestem a roupa do Scrum mas continuam empurrando o processo.

Isso vai contra a idéia do processo/sistema puxado vs. empurrado. No empurrado, as pessoas são designadas a cumprir tarefas, tem a estrutura hierárquica forçando o funcionamento do sistema, enquanto que no puxado, cada um assume a responsabilidade que lhe cabe.

Uma analogia industrial seria falar de uma fábrica em que uma máquina recebe como entrada matéria-prima e retorna algo processado para seguir para uma nova máquina. As máquinas não estão em sincronia, e se a segunda tem capacidade de trabalho menor que a primeira, teremos a formação de um gargalo.
No processo puxado, a última máquina, quando livre, solicita insumo da anterior, que recursivamente vai pedindo material da máquina que lhe precede.

Retomando os papéis, no Scrum temos o Scrum Master, o Product Owner e a Team/Equipe.
As responsabilidades são as seguintes:

• Scrum Master
• Cuidar da Equipe
• Trabalhar com o Product Owner
• Revomer impedimentos
• Manter o processo funcionando
• Socializar Scrum na Organização

• Equipe
• Estimar o tamanho dos itens do Backlog (conjunto de tarefas a serem realizadas)
• Assumir compromisso com a entrega de um incremento de software funcional
• e entregá-lo
• Manter o seu próprio progresso (com o auxílio do Scrum Master)
• Auto-organizados, responsáveis pela entrega daquilo prometido para o Product Owner

• Product Owner
• Trabalhar numa visão compartilhada
• Levantar requisitos
• Gerenciar e priorizar o Product Backlog
• Aceitar o Software no final de cada interação
• Gerenciar o Release Plan
• Responsável pela lucratividade do projeto (ROI)

Ontem, segunda-feira, tive a oportunidade de conversar com um amigo, o Bruno Nascimento, que é gerente numa empresa de desenvolvimento, sobre essa problemática de quem deve assumir cada responsabilidade. Ele me contou que ele tem que conferir e homologar cada código que um desenvolvedor gera, num trabalho manual e centralizado em suas mãos.

Quer dizer que a responsabilidade do código não está na mão da equipe, e sim do gerente. Esse formato acaba causando o efeito "mijada", quando o gerente é cobrado por um software bugado, e ele então passa a culpa para os seus subordinados (a mijada descendo as escadas...), e por aí vai até chegar no pobre coitado estagiário que estava lá trabalhando insatisfeito, fazendo coisas por obrigação, mas que não interferiam diretamente na vida dele (a não ser pela já esperada mijada).

Essa situação pode ser diferente se a responsabilidade de entregar código testado for da equipe. Eles vão se certificar de fazer seu melhor, e sabem que são os responsáveis diretos pela falha. O problema é que estamos sempre procurando alguém para culparmos, e esse alguém sempre precisa de outro alguém para passar a culpa e tirar o seu da reta... É um processo defensivo, não jogamos para ganhar, e sim para esconder o fracasso que estamos temendo. Devemos jogar para ganhar!

Finalizada a discussão sobre os papéis e como colocar na cabeça dos que não querem ter seu queijo mexido que não podemos continuar com a mentalidade anterior, fizemos uma lista dos impedimentos mais comuns que temos no nosso dia-a-dia. E seguimos falando de como implementar o Scrum, das reuniões de planejamento (Estimation Meeting, Planning Meeting, Daily Meeting, Sprint Review).


Foi o momento para falar do conceito de "done" ou "pronto". Já vi discussões sobre isso em diversas listas sobre Agile, nacionais ou internacionais, e o que acaba acontecendo é que cada um tem uma opinião e que funciona. Alguns consideram pronto quando a equipe termina as tarefas da história, outros quando o P.O. aceita, outros quando está em produção, etc.
O importante é ter um conceito bem definido e difundido dentro da equipe, de forma que todos saibam qual é o objetivo, onde "parar" pois o software já está hmm.... pronto!

Fizemos uma atividade de escrever User Stories (estórias) para um Terminal de Auto-Atendimento, identificando o tipo de usuário a que se destina a estória, a funcionalidade e o benefício que esta traz.

As estórias são "lembretes para um conversa futura". Surgiu com o pessoal de Extreme Programming (XP), como forma de indicar o que o software deve fazer. Seria, para os que querem uma comparação, uma forma simples de declarar os casos de uso.

Então, separados em 4 equipes, escremos os cartões (estórias...) com o que nossos terminais deveriam ter/fazer e, em seguida, cada grupo apresentou suas idéias e como cada uma delas funcionava do ponto de vista do usuário, que benefício ele teria caso aquele estória fosse implementada.

Chegou então o momento em que falamos sobre planejar. No XP sabemos que mais vale o ato de planejar do que seguir um plano (que pode se mostrar incoerente com a realidade).
O Juan Bernabó fez essa distinção através de duas outras palavras: estratégia e tática.
Usou o exemplo de uma guerra: um geral pode definir a estratégia de um ataque anos antes do mesmo ser realizado. A estratégia é o "pra que?". A razão de invadir o país pode ser "para conquistar território", para "lutar contra o terror", etc...

Agora a tática, o "como?", se definida 5 anos antes do ataque, só garante uma coisa: o fracasso. Em pouco tempo o campo de batalha pode mudar drasticamente. Fontes de energia podem ser construídas, bases militares mudam de local, sistemas de comunicação mudam, enfim, não podemos prever como será um país com anos de antecedência... nem mesmo meses..., se o ataque fosse mesmo acontecer, a tática seria definida o mais tarde possível. Vem então mais uma idéia do Lean, de evitar tomar decisões cedo, tomá-las sempre no último momento possível.

Posteriormente falamos das estimativas, e do Planning Poker. Em equipe, estimamos pontos para nosso projeto de caixa eletrônico. Neste momento surgiu alguma dificuldade em acertar o valor relativo que a equipe definia para cada item. Com a ajuda do Juan conseguimos entrar num consenso, poderiam jogar valores sem nos preocupar tanto e ir ajustando os pesos de cada item ao longo das outras estimativas.

Então foi mais ou menos assim: pegamos uma estória por vez, e para aquela história colocávamos na mesa uma carta do Planning Poker, como o valor que julgávamos apropriado (0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100 ou "?"). Se o conseso fosse imediato, o a complexidade da estória estava definida (lembrando que não estimamos tempo...). Caso houvesse disparidade, os extremos explicavam porque colocaram um valor mais baixo ou alto e então novamente jogávamos as cartas, visando o consenso.

Por fim, para terminar o treinamento, executamos 2 sprints no "Jogo da Velocidade", que nada mais era que o XPGame com um nome diferente!
Foi legal trabalhar em equipe, conhecer pessoas novas e trocar idéias.

Do sábado para o domingo, assisti a um vídeo da palestra do Bardusco sobre a implantação do Scrum na globo.com, que me ajudou a entender melhor "aonde estamos". Já havia lido sobre a transição nos diversos blogs, mas ouvir o Bardusco pareceu mais interessante.

Enfim, um final de semana muito bom! (Enquanto meus amigos da universidade se divertiam em Arraial do Cabo... haha)

Uma semana de globo.com e Dinâmicas Ágeis (Scrum)

Na quinta-feira completei 1 semana na globo.com!
Estou muito feliz com o novo ambiente de trabalho, sem largar o Labase no NCE/UFRJ.

A propósito, a experiência adquirida durante um ano e meio no Labase tem sido muito relevante em minha vida e carreira. Como se não bastasse Agile no ambiente de trabalho, sempre me identifiquei com as metodologias a ponto de aplicar diversas coisas na minha vida pessoal.

Lá no Labase nós somos uma equipe de Extreme Programming (XP), porém meus estudos na área de metodologias de desenvolvimento e gerenciamento de projetos sempre foi com uma visão mais abrangente, de forma que fui procurar entender os métodos tradicionais, o waterfall, o RUP, e outras "estranhezas sem sentido". E no mundo ágil, apesar de simpatizar totalmente com o XP, e encarar as práticas técnicas que assustam muitos desenvolvedores, também acabei vendo o Scrum, que tem sido melhor vendido no Brasil se comparado ao XP.

Tudo isso para tentar entender melhor como funciona da dinâmica atual do mercado, porque o modelo tradicional é o que é, porque precisamos mudar a mentalidade, e como eu posso impactar positivamente essa mudança de paradigma.

O marketing do Scrum tem sido mais feliz, parece que XP é extremo demais para pessoas normais... E lá na globo.com nós seguimos o Scrum. Bem, como pode ser constatado em outros blogs, entamos em processo de implantação do Scrum, de mudança da mentalidade de muita gente. Alguns compram a idéia do Agile e fazem funcionar, outros já ficam com medo e acabam querendo proteger seu trabalho a todo custo... o medo de evoluir, ou de ser descartado... vai entender.

O fato é que a globo.com tem investido pesado em treinamentos e consultorias. E trabalhamos com o que há de melhor no mercado, com o pessoal da Teamware, na maioria das vezes representada pela pessoa do Juan Bernabó. Eu conheci o Juan numa palestra em agosto.
Apesar do pouco tempo de empresa, já estou participando de um desses treinamentos neste final de semana. O Juan realizou conosco algumas dinâmicas, e pudemos conversar, discutir diversos aspectos aplicados à nossa realidade.

Voltando a experiência no Labase, foi lá que me deparei pela primeira vez com o mundo Ágil, e me apaixonei. Quem conversa comigo talvez já tenha ouvido meu relato de que a cada instante que aprendo mais eu falo "ué, e não é assim que funciona a engenharia de software tradicional?!"... ou coisas do tipo...

E no Labase não ficamos só no papel, nós procurarmos vencer as dificuldades (muitas vezes impostas por ainda estarmos cursando nossa graduação), e tive o grande prazer de nos últimos meses estar numa posição de liderança que muito agregou.

Como contei em outro post, nós realizamos no NCE a dinâmica do XPGame em uma versão adaptada para os alunos do mestrado, e pretendemos fazer nessa semana (agora com data marcada!) uma dinâmica da Fábrica de Aviões.

Bem, hoje no treinamento da Teamware adicionei em minha bagagem mais dois itens interessantes. Primeiro nós realizamos uma atividade de criação de um folder para marcianos.
Era uma atividade introdutória, muito relevante para perceber que precisamos ter muito claro o conceito de "pronto" (quando uma tarefa está concluída), o foco no que o cliente quer, trabalhar no produto entregável que traz valor para o cliente ao invés de gerar especificações, etc.

A outra dinâmica foi a das bolas de tênis. Tínhamos um conjunto de bolas, e cada bola que passasse na mão de todos os participantes e voltasse para o primeiro contaria um ponto. O objetivo era obter o maior número de pontos possíveis no time-box de 2 minutos.
A restrição é que as bolas não poderiam ser passadas para um pessoa imediatamente ao seu lado de forma conduzida.

Fizemos seis sprints, e em cada um deles tínhamos que estimar um mínimo e um máximo para o número de pontos que conseguiríamos entregar. Como de se esperar, a primeira estimativa foi muito difícil, pois não fazíamos idéia da complexidade da tarefa. Estimamos entre 5 e 10 bolas.
Entregamos 12 bolas, passando as bolas em zigue-zague num corredor de pessoas e o último lançava a bola de volta ao primeiro para completar o ponto.

Vimos que poderíamos melhor bastante, e de fato melhoramos, chegando a entregar 87 pontos no quinto sprint. Tudo fruto de trabalho em equipe, de uma equipe auto-gerida e que cuidou a cada interação da melhoria da sua forma de trabalhar, de seu processo. Diferente do que conhecemos como "mundo real", não tem uma pessoa de fora de dizendo como fazer algo no qual você é especialista. Não existe o papel do gerente ou que quer seja ditando como você deve fazer seu trabalho.

Esta atividade foi citada diversas vezes durante a apresentação do Scrum e dos papéis no Scrum, e junto a toda discussão tiramos algumas dúvidas de como aplicar tudo aquilo em nossas equipes, como fazer a metodologia funcionar de verdade.

Foi um sábado muito proveitoso, e amanhã tem mais!

Dinâmica Ágil: Jogos Estatísticos

O Luiz Parzianello divulgou na lista do XPRio [1] um post em seu blog sobre dinâmicas ágeis, em especial sobre uma de sua autoria [2].

Ele sugere que a maioria das dinâmicas existentes " aborda a essência dos princípios ágeis de uma forma metafórica distante do modelo mental analítico predominante nos profissionais da área de software". E com isso o resultado não é totalmente satisfatório para o aprendizado e aplicação do novo conhecimento no dia-a-dia.

Concordo com o Luiz, já participei de algumas dinâmicas e tive a oportunidade de ajudar a organizar uma com alunos de mestrado do NCE/UFRJ, e a impressão que fica é de "e não é que isso funciona!". Em geral, sinto que as pessoas tem o seu queijo mexido... mas, o qual o resultado a longo prazo? Realmente uma aborgadem menos direta facilita que os conhecimentos fiquem guardados em um canto e não participem da rotina profissional.

Luiz realizou dinâmicas que chamou de "Jogos Estatísticos para a Promoção de Práticas Ágeis", tendo inclusive participado do evento Ágiles 2008.
Por hora, são três jogos baseados em:

• Modelos de produção Just-in-Time (Lotes de Produção x Produtividade)
• Teoria das Restrições (Eventos Dependentes x Produtividade)
• Teoria das Filas (Fluxo de Produção x Planejamento

As instruções para realização do primeiro jogo, o Lotes de Produção x Produtividade, já se encontra no blog do Luiz, espero que ele poste também sobre os outros jogos!
Confiram!

[1] http://br.groups.yahoo.com/group/xprio
[2] http://parzianello.blogspot.com/2008/08/jogos-estatsticos-lotes-de-produo-x.html

Dinâmica dos aviões

Mais uma vez visitei o blog do Flávio [1]. Ele sempre tem histórias muito legais, e numa ocasião ouvi falar dessa dinâmica também pelo seu blog.

O que valeu esse post é que o Flávio colocou fotos e vídeos da Dinâmica de aviões realizada na PUCRS dia 11/11/2008. Muito bom! Lá no mestrado do NCE queremos realizar essa dinâmica... quem sabe em breve se concretiza e eu posto aqui.

Já realizamos há um tempo uma versão personalizada do XPGame [2].
É isso, pouco tempo para elaborar muito :D
Na verdade, tenho feito várias coisas bacanas e não tenho arrumado tempo para "documentar o que está na minha mente"...

[1] http://mudandoumapequenaempresa.blogspot.com/2008/11/resultado-da-dinmica-de-avies-pucrs.html
[2] http://lifeatmymind.blogspot.com/2008/10/atividades-introdutrias-de-xp-em.html

Atividades introdutórias de XP em treinamentos

Depois de um post do Adam Wildavsky na lista de XP [1], resolvi guardar uma coleção de links para atividades que podem ser utilizadas para introduzir equipes ao Extreme Programming e Métodos Ágeis em geral, além de também servirem para treinar alguns conceitos e princípios.
Ótimo para "mexer no queijo" das pessoas, colocar uma pulga atrás da orelha e trazer mais gente para a reflexão sobre como desenvolvemos software.

Lá no mestrado do NCE já participei aplicando uma versão personalizada do XPGame, foi uma experência muito interessante. Espero que possamos fazer mais!

• http://csis.pace.edu/~bergin/xp/planninggame.html
• http://c2.com/cgi/wiki?ExtremeHour
• http://tech.groups.yahoo.com/group/extremeprogramming/message/60139
• http://xp.be/xpgame.html
• http://blog.excastle.com/2006/07/24/agile-2006-the-lego-xp-game/
• http://sites.google.com/site/tddproblems/

[1] extremeprogramming@yahoogroups.com

Update 2008/11/25: outra atividade interessante é a Dinâmica dos aviões
Update 2008/11/26: mais uma, Jogos Estatísticos

Coding Dojo no Rio

Desde a PyCon Brasil 2008 (realizada aqui no Rio), no mês passado, que fiquei super empolgado em fazermos um Coding Dojo no Rio.
Como bem disse o Cláudio Berrondo, o Dojo é a "a peladinha semanal para programadores"!
Então por que não seguir os passos de nossos amigos paulistas e de outras regiões [5]?
Apesar de já ter lido sobre o assunto antes, minha primeira prática foi na PyCon, sob comando do Hugo Corbucci, que mandou muito bem por sinal.
Nosso Dojo da PyCon não foi gravado, mas tem um vídeo em que o Hugo explica direitinho qual é a idéia [1]. Outros links interessantes em [2] e [3].

Para conseguir juntar um pessoal, espalhei a notícia na PythOnRio, e na XPRio, além de divulgar para amigos da UFRJ. Alguns interessados se apresentaram, e agora só falta marcamos uma "sede".
Pensei a princípio na UFRJ, mas o problema lá é a dificuldade de transporte. Um local que se mostrou muito bom é a Universidade Veiga de Almeida, campus Tijuca, onde foi realizado a PyCon. O pessoal lá foi muito receptivo, e será muito bom se eles nos adotarem ;)

Para começar, além do local também precisamos de uma data. Para agilizar as coisas, criei o grupo Dojo Rio [4]. Todos os interessados são bem-vindos!
Vamos juntar forças com Pythonistas, Agilistas, XPeiros, e demais tribos, todos interessados em boas práticas de desenvolvimento de software, e porque não boas horas de diversão!

[1] http://video.google.com/videoplay?docid=-9174018775255486687
[2] http://www.agilbits.com.br/material/DojoIntroPyconBrasil2008.pdf
[3] http://codingdojo.org/
[4] http://groups.google.com/group/dojo-rio
[5] http://codingdojo.org/cgi-bin/wiki.pl?CodingDojos

Sobre Test-Driven Development

Ontem, no grupo de emails de XP, começou uma conversa sobre dados que suportem o uso de TDD nas grandes empresas. Os detalhes podem ser vistos em:
http://tech.groups.yahoo.com/group/extremeprogramming/message/144501

O que gostaria de deixar aqui são os links postados por Dave Nicolette, listando alguns estudos sobre o tema.

http://delicious.com/rhcarvalho/paper+tdd