1 ano de Coding Dojos na AdaptWorks

No começo desse mês, completamos 1 ano de Coding Dojos aqui na AdaptWorks (o primeiro foi em 04/05/2010).

Nesse período, realizamos 13 sessões (que temos algum registro. Tivemos outras sessões, mas não guardamos nada delas), das quais 64 pessoas participaram (e 8 pessoas vieram em mais de 10 sessões).

A nossa menor sessão contava com 6 pessoas (sem contar o Fabio Massa e eu) e a maior teve 23 (ontem!).

Pessoas no Dojo

A sessão de ontem foi bem interessante. Além de ser o nosso recorde de público com 23 pessoas e Scala ser a linguagem do Dojo (valeu Paulo!) tivemos alguns participantes da Alemanha. Como eles não falam português (e nós não falamos alemão), escolhemos inglês como a lingua oficial da sessão.

Participantes me ajudando a organizar a montanha de post-its

Isso foi tão bem aceito na retrospectiva que decidimos escolher a lingua que será falada no início de cada sessão, assim além de praticar técnicas de programação, também poderemos praticar inglês durante as sessões.

Enfim, muito obrigado a todos que participaram dos Coding Dojos da AdaptWorks e que sejam ainda mais divertidas as próximas sessões.

Nenhum comentário »

Categorias deste post

Dojo

Testes devem ser independentes

Testes devem começar dessa forma:

Primeiro, Deus criou o céu e a terra…
E Deus disse, “Haja luz”…

E devem terminar da seguinte:

a besta que viste, era e não é, está para emergir do abismo e caminha para a destruição

Quando você começa a escrever o teste, não deve existir nenhuma dependência com o estado de um teste anterior. Se você vai usar o banco, ele deve estar vazio. Se vai usar uma classe que guarda estado em um campo static (ugh!), precisa (além de refatorar esse código), reiniciá-la.

Tem uma razão para que isso seja feito. Cada teste deve se comportar como um experimento que sempre dará o mesmo resultado (desde que você não mude o código) não importa quantas vezes você o rode.

Porque você quer isso? Para que não aconteçam falsos negativos e nem falsos positivos. Seus testes precisam ser confiáveis ou você vai passar a ignorá-los.

Imaginem o seguinte caso:


public void testaQueSalvaOsDados(){
	//Código que salva "bobagem"
	
	String dado = //código que recupera "bobagem";
	assertEquals("bobagem", dado);
}

public void testaQueListaDados(){
	List<String> dados = //código que busca todos os dados;
	
	assertEquals(1, dados.size());
	assertEquals("bobagem", dados.get(0));
}

Se você rodasse esses testes, o segundo teste passaria apenas na primeira vez. Após isso, ele iria falhar no primeiro assert (o do tamanho da lista).

Esse é um caso bem óbvio de utilização de efeitos colaterais de outro teste. E pode acontecer coisa pior. Imagine que depois de rodar os testes a primeira vez, você quebra o “código que busca todos os dados” e ele passa a trazer apenas o primeiro encontrado. Você terá um bug muito difícil de encontrar, porque os testes passam.

Novamente, esse é um caso bem óbvio. Interações bem mais sutis que essas podem acontecer e você vai sofrer muito para encontrar.

Por isso, sempre que seu teste causar algum efeito colateral, desfaça esse efeito. A sanidade dos programadores que vão dar manutenção no seu código agradece.

Se quiser aprender mais sobre testes, dê uma olhada em nosso treinamento Scrum Developer Skills.

Nenhum comentário »

Categorias deste post

Agile, Técnico

A minha parte eu fiz.

Semana passada eu presenciei uma cena inusitada (talvez nem tanto). Estava esperando minha namorada sentado em um estabelecimento comercial, quando o dono do lugar sobe as escadas nitidamente irritado e, sem ligar muito para mim ou os outros dois clientes que estavam na sala, começa a discutir com a secretária, perguntando porque Fulano não foi fazer a entrega à Ciclano. A resposta da secretária foi curta, simples e precisa. “A minha parte eu fiz”. Ela complementou a frase com algo que nem lembro mais, mas essa primeira frase foi marcante.

O que estava acontecendo? Uma entrega não foi feita. Um cliente está insatisfeito. Um chefe está irritado e a secretária não quer correr o risco de ser culpada pela entrega não feita.

Já viram algo semelhante na empresa onde trabalham? Acho que muitos vão responder afirmativamente.

A ação do dono do lugar nitidamente foi uma caça às bruxas. Ele nem pensou que talvez resolver o problema do cliente fosse melhor que procurar o culpado.

Mas o que me chamou a atenção dessa vez foi a ação da secretária.

Sem pensar duas vezes, ela se exime da culpa. Após se eximir da culpa, ela foi tentar solucionar o problema. Essa sequencia de ações mostra que existe algo de muito errado dentro dessa empresa.

Se antes de procurar qualquer solução a pessoa precisa deixar claro que não é culpado, nitidamente existe uma relação de opressão (afinal, se ela for a culpada e o cliente importante, ela pode ser demitida). A cultura dessa empresa não permite erros. Se não permite erros, não permite aprendizado.

Deixemos essa empresa de lado e pensemos em nossas empresas. Trabalhamos com TI, correto? Seja desenvolvendo, gerenciando, dando treinamentos, ou qualquer outra coisa. Para TI, aprendizado e inovação são simplesmente vitais. A cada dia temos que fazer coisas que ninguém nunca fez antes. Cada linha de código nunca foi escrita antes (pelo menos não por aquela pessoa naquele projeto). Com certeza vamos errar. E quando errarmos, o que vai acontecer? Se você estiver em um ambiente opressivo, aprendizado não vai ser a sua primeira preocupação.

Uma das coisas que aprendi lendo o Artful Making do Lee Devin (e depois com o incrível treinamento homônimo também do Lee) é que para trabalhos criativos (como é o desenvolvimento de software) é necessário que exista um ambiente seguro para você errar, pois senão não conseguirá ir para frente. Errar deve fazer parte do seu dia a dia e não ser algo temido. Deve ser visto como uma oportunidade de aprendizado e não como um atraso no projeto.

Scrum é um processo empírico, correto? E processo empírico implica em errar e aprender com os erros. Para que Scrum funcione corretamente na sua empresa muitas vezes são necessárias mudanças culturais e comportamentais. Essa é uma delas.

Nenhum comentário »

Categorias deste post

Agile

Conversa Rápida Junho

No dia 13 de Junho, das 19:30 às 22:00, teremos a segunda edição do Conversa Rápida aqui na AdaptWorks.

Para os que não viram a primeira edição, todas as palestras estão no YouTube.

Nessa edição do Conversa Rápida, teremos 10 palestras de aproximadamente 5 minutos.

Os palestrantes confirmados são:

Como temos poucos lugares, caso tenha interesse em assistir as palestras, por favor envie um email para jabreu@adaptworks.com.br confirmando.

2 Comentários »

Categorias deste post

Eventos

Tiny Types

Enquanto eu resolvia o primeiro desafio de expressividade que postei no VidaGeek.net, me deparei com uma situação comum para programadores Java.

Eu precisava que a classe java.lang.String fosse capaz de fazer coisas (como inverter a string) que ela não é.

A solução mais comum seria criar uma classe Strings (seguindo o padrão da java.util.Collections) que conteria o comportamento.

Daí para usá-la, seria da seguinte forma:


Strings.inverte(suaString);

O problema é que isso espalha o comportamento que deveria pertencer à String (que não temos como alterar).

Ao invéz de solucionar o problema dessa forma, resolvi usar um Tiny Type para encapsular essa string (chamei de BinaryString).

Essa BinaryString é capaz de se inverter, além de eu poder dar os nomes que eu quiser para os métodos (deixando mais expressivo).

Mas a maior vantagem de ter usado esse Tiny Type é que ele me abriu possibilidades que não existiam no código sem ele e eu mudei completamente a solução que pretendia criar. A nova solução ficou (na minha opnião) mais elegante e expressiva.

Se tiverem maior interesse sobre Tiny Types, eu escrevi sobre o assunto aqui e tem um post do Darren Hobbs que é onde eu entrei em contato com o assunto.

Além disso, no nosso novo treinamento Scrum Developer Skills, vários assuntos relacionados à expressividade são abordados, incluindo Tiny Types.

4 Comentários »

Categorias deste post

Técnico

Dizer sim ao Kanban não significa dizer não ao Scrum

Durante o ano passado fui bastante questionado sobre qual era a minha posição quanto ao uso do Kanban em projetos de desenvolvimento de software. Como naquele momento meu contato com este método ainda era pequeno, eu me reservei o direito de por várias vezes dar a simples resposta “Ainda não tenho uma posição totalmente formada sobre o assunto, a princípio algumas coisas fazem bastante sentido para mim e outras me deixam preocupados.”. Pois bem, depois de bons meses de pesquisa, estudo e algumas aplicações práticas, compartilho com vocês o que acho sobre o assunto.

Recapitulando

Conforme mencionado em recente post do Tiago Motta aqui no blog AdaptWorks, o Kanban que estamos falando aqui é uma espécie de derivação do modelo de cartões do Sistema Toyota de Produção para o desenvolvimento de software. Esta derivação, popularizada sob a liderança do David J. Anderson (aquele do time que criou a FDD – Feature-Driven Development), é formada principalmente por três princípios: fluidez, valor e pessoas. Estes princípios criam forma através de práticas bem interessantes, como a definição de um Limited Work-In-Progress nas filas de trabalho.

Talvez o ponto de maior diferenciação deste Kanban para os mais conhecidos métodos ágeis, como Scrum e Extreme Programming, seja o fato dele trabalhar com um fluxo cadenciado, enquanto os outros focam seu trabalho no conceito de time-box.

Caso você ainda não esteja familiarizado com a idéia do Kanban para desenvolvimento de software, sugiro fortemente a leitura do seguinte material:

Menos prescrição

Se você trabalha ou conhece bem os conceitos do Scrum, provavelmente ao ler sobre Kanban fará alguma das perguntas abaixo:

  • Cadê o Product Owner? E o ScrumMaster?
  • Meu time não é multi-disciplinar?
  • Não faço planejamento de uma Sprint? Como assim não há Sprint?
  • E a melhoria contínua? Não paro para pensar em como melhorar produto e processo?

Veja, essas perguntas não são tão diferentes das que muitos fazem quando estão partindo de um método waterfall-like para os ágeis:

  • Cadê o Gerente de Projetos?
  • Não há hierarquias nos papéis?
  • Não faço um planejamento detalhado no início do projeto? Como assim não há escopo fechado?
  • E meus artefatos? Cadê meu cronograma?

Essa reação sempre se repetirá quando você estiver de saída de um processo mais prescritivo para um mais leve, com menos coisas definidos. E da mesma forma que Scrum é menos prescritivo que muitos dos métodos waterfall-like, o Kanban é sim menos prescritivo que o próprio Scrum.

Hmmm, então significa que Kanban é uma evolução do Scrum? Não é bem por aí. Adaptabilidade é algo maravilhoso e que obviamente sempre será beneficiada  quando do uso de métodos menos prescritivos. No entanto o quão “adaptável” deve ser o seu processo é, na minha opinião, mais uma das decisões que você deve tomar empiricamente, projeto a projeto. Em algumas situações uma solução com mais processos definidos pode sim ser mais adequada que uma com menos. Já em outras isso pode travar as pessoas e burocratizar o trabalho. Scrum pode ser burocrático demais para alguns cenários? Não tenho dúvida que sim, mas também pode ser aberto demais para outros. O mesmo digo em relação ao Kanban.

Fluxo ou pacote?

Essa, na minha opinião, é a principal pergunta que você deve fazer quando da decisão de usar Kanban ou não. O conceito de time-box, rigidamente utilizado pela maioria dos métodos ágeis, dá lugar à procura por fluidez dentro de um processo baseado em fluxo unitário. O jogo funciona mais ou menos assim:

  • uma padaria waterfall planeja no início do dia a quantidade total de pães que precisará e então os produz faseadamente. Teremos todos os pães prontos de uma única vez, talvez, ao final do dia.
  • uma padaria Scrum define time-box’s rígidos e no início de cada “rodada de produção” estima quantos pães é capaz de fazer dentro daquele tempo. Teremos, por exemplo, pequenas fornadas de pão saindo a cada hora.
  • uma padaria Kanban trabalhará de forma fluída: planejando, construindo e entregando pão a pão continuamente. O primeiro pão pode ficar pronto em 02 minutos, e já estar disponível para o consumo, o outro pode vir 05 minutos depois, o outro 01 minutos, e por aí vai, fluindo.

Lógico que o pão aqui é apenas uma analogia, mas com ela espero que você consiga perceber que, dependendo do que você precisa, uma dinâmica pode parecer mais interessante que a outra. Um Product Owner pode muitas vezes se perguntar do por que dele precisar ficar esperando o fim da Sprint para receber uma funcionalidade X que já está pronta. Ele adoraria já ir recebendo cada funcionalidade quando esta estivesse pronta sem ter que esperar o “pacote” estar pronto. Já um outro Product Owner poderia achar isso péssimo, já que ele gostaria de poder programar melhor as entregas e não enxergaria valor em ter apenas uma daquelas funcionalidades na sua mão. Tudo depende.

Minha perspectiva

Depois de assistir algumas boas palestras de Kanban, das quais destaco a do Karl Scotland no Scrum Gathering de Amsterdam, participar do treinamento de Kanban aqui da AdaptWorks e ler muitas coisas a respeito, decidi então partir para a prática.

Nos últimos três meses me envolvi no trabalho com três times Kanban. Todos fazem parte de empresas que já estão há algum tempo fazendo algo relacionado à Agile, um exemplo disso é que todos os três times estavam vindo de Scrum. Abaixo compartilho um pouco desta experiência bem como minha percepção sobre ela.

Por que eu sugeri a transição de Scrum para Kanban?

Nestes casos específicos ficou evidente que o conceito de pacotes do Scrum tornava o ambiente “duro” demais. Algumas características deste cenário que me levaram a pensar sobre Kanban:

  • O Product Owner não conseguia ter uma quantidade de requisitos READY para o planejamento de uma Sprint, visto que muitas coisas “apareciam” e “eram descobertas” ao longo da sua execução.
  • O time estava extremamente “estressado” pois todo planejamento era mudado (!) ao longo da Sprint.
  • O tal “pacote” da Sprint era composto por coisas sem nenhuma relação, muitas vezes até de produtos ou áreas diferentes.
  • Sprints eram interrompidas frequentemente para fazer “algo urgente” e, veja, este algo não surgia por falta de planejamento ou incompetência das pessoas envolvidas. Ele surge porque a dinâmica do negócio daquela empresa é assim mesmo.

O que há de comum em todos os problemas que citei acima? Todos são derivados do conceito de time-box. E foi durante a busca da causa raiz destes problemas que me convenci que para aquele time uma outra dinâmica no fluxo de trabalho melhoraria diversos pontos.

E como ficaram as outras práticas do Scrum já que não eram mais obrigatórias?

Se você conversasse comigo há alguns meses atrás escutaria que um dos maiores medos que eu tinha em relação ao Kanban era o de que times poderiam “relaxar” com algumas das práticas essenciais de Agile que agora passariam a ser opcionais (percebe que este é o mesmo medo sentido pela turma do XP quando alguém fala de Scrum). Felizmente o que percebi na prática foi que, uma vez que um time ou uma organização aprende que multi-disciplinaridade e auto-organização – dentre outros conceitos – são benéficos para seus resultados, elas não mais abrirão mão deles.

Ainda tenho dúvidas quanto a este ponto quando penso em um time que nunca utilizou algum método ágil indo diretamente para Kanban.

E mudou tudo?

Em ambas as empresas nas quais pratiquei Kanban, o Scrum foi mantido para a maioria dos times. Em um dos casos, de um total de treze times ágeis, apenas dois fizeram a transição para Kanban. Por que? Porque o Scrum, seus timeboxes e outros conceitos continuou se mostrando a melhor opção, ou pelo menos a mais adequada para muitos deles.

Isto não é sobre ser mais fácil ou menos invasivo, isto é sobre escolher a opção mais adequada

Não gosto quando vejo alguém falando que irá começar a utilizar Kanban pelo fato de não ter conseguido utilizar Scrum, ou pelo fato de Kanban ser menos invasivo. Ora, se vou utilizar Kanban tem que ser porque, para aquele propósito, o considero melhor que Scrum, XP, Crystal, Waterfall, etc., e não simplesmente porque é mais fácil!

Para finalizar este post entenda que eu faço parte daquele grupo de pessoas que não acredita que há ou haverá um único processo correto, capaz de combater todos os tipos de problemas e se adequar à todos os cenários. Tenho adorado minhas recentes aventuras com Kanban, e continuo vibrando com o que Scrum pode fazer – e tem feito – por muitos times e empresas.

No nosso treinamento “Sistema Kanban para desenvolvimento de software” são abordados importantes detalhes sobre o uso deste método. Veja as datas de nossas próximas turmas.

11 Comentários »

Categorias deste post

Agile, Kanban, Scrum

Conversa Rápida – Retrospectiva e Palestras

A primeira edição do Conversa Rápida foi realizada nessa segunda feira, dia 2.

(Se estiver interessado apenas nas palestras, pode pular para o fim do post)

Além de ter sido muito divertido para os palestrantes e participantes, o formato do evento agradou a todos. Isso era uma preocupação da organização, pois nunca tínhamos feito algo assim.

Basicamente, foram 12 palestras de 5 minutos (mais uma orientação do que uma regra). Mas o que tornou o evento mais interessante, além dos palestrantes (muito obrigado Alexandre, Fabiano, Edmilson e Juliano) e o público (muito obrigado a todos que vieram até a AdaptWorks em uma segunda feira com trânsito recorde), é que apenas os palestrantes sabiam sobre o que iam falar. Propositadamente não houve divulgação das palestras. E isso foi bem recebido pelo público.

O objetivo da não divulgação das palestras é tirar todos da zona de conforto e poder discutir sobre assuntos que voluntariamente muitos não procurariam, mas que fazem muito sentido para Desenvolvimento Ágil.

Além disso, houve uma boa variedade de formatos de palestras, o que tornou tudo ainda mais dinâmico. Alguns palestrantes usaram apresentações mais tradicionais (slides), outros usaram o quadro branco, e em algumas não foi usado material de apoio. Até mesmo uma dinâmica de grupo aconteceu durante uma das apresentações.

Após a sequência de palestras, precisávamos colher o feedback do público. Ao invés de usar os tradicionais questionários, optamos por uma Retrospectiva Ágil. Além de diversos post-its elogiando o evento, conseguimos identificar vários problemas a serem resolvidos para a próxima edição.

Novamente, muito obrigado a todos que puderam vir. E para os que não puderam, todas as palestras foram filmadas e estão agora no youtube. Segue a lista delas:

A internet não é a sua casa – Jonas Abreu
Ambiente para Inovação – Jonas Abreu
Certificados Digitais – Juliano Alves
Criando Melhores Apresentações – Edmilson Miyasaki
E quando a empresa não é ágil? – Juliano Alves
Expressividade de Código – Jonas Abreu
Liderança técnica não é sinônimo de bons líderes – Fabiano Milani
Opressor x Oprimido – Jonas Abreu
ProductOwner – Ação Requerida – Alexandre Magno
Recursão – Jonas Abreu
ScrumMaster – Ação Requerida – Alexandre Magno
Time – Ação Requerida – Alexandre Magno

4 Comentários »

Categorias deste post

Eventos