Categories
Scrum XP

XP complementa o Scrum

As metodologias que conhecemos hoje em dia como “metodologias ágeis” se baseiam nos mesmos princípios e no manifesto ágil. Talvez seja por isso que muitas práticas dessas metodologias são muito parecidas ou até mesmo iguais, só mudando seu nome.

Estou falando mais especificamente de Scrum e eXtreme Programming (XP). O Scrum, particularmente, é um framework focado principalmente em planejamento e gerência. Já o XP é mais focado em práticas de desenvolvimento. Mesmo assim, várias práticas são coincidentes entre Scrum/XP como sprint/desenvolvimento iterativo, daily scrum/daily meeting, sprint planning/planning game, e por aí vai.

A principal diferença que vejo entre as duas é que Scrum não te diz nada sobre práticas de desenvolvimento de software ágil, até porque você pode usar Scrum não só para fazer sistemas, como também para fazer carros, aviões ou bolos.

Minha visão é que as práticas de XP complementam o Scrum. Certas práticas de desenvolvimento, que vejo como essenciais para o bom andamento de um projeto de software, não fazem parte do escopo do Scrum mas fazem parte do XP, como desenvolvimento guiado por testes, integração contínua, build de 10 minutos, design incremental, metáforas, código coletivo, programação em par, refatoração e por aí vai. Por isso, não só acho que é bom fazer essa combinação, como acho que é bastante recomendável.

Mas para fazer isso não seria melhor usar XP puro ou invés de Scrum? Não vejo dessa forma. Scrum tem algumas diferenças que acho interessantes, como a retrospectiva fazendo parte do processo, uma grande ênfase na gerência do backlog (e em quem é o “responsável” por cada backlog: o P.O. pelo backlog do produto e o time pelo Sprint backlog) e a forma de planejamento e acompanhamento dos Sprints.

Categories
Agile Engenharia de software Refactoring Testes

Test infection: por onde começar?

Fala GC!

Cara, o que voce faria se entrasse em um projeto para implementar umas melhorias, mas esse projeto não tivesse nenhum tipo de teste, o código não fosse testável e você soubesse que daqui a 3 meses ia sair do projeto? Você perderia tempo fazendo refactoring, implementando testes, configurando CruiseControl e tal, ou ia simplesmente ligar o foda-se???

Isso acontece pelo menos 32409 vezes todos os dias em algum lugar do planeta.

Os desenvolvedores acostumados a programar com testes têm uma dificuldade enorme de trabalhar em aplicações que não tem testes. A primeira coisa que os desenvolvedores mais experientes fazem quando pegam uma aplicação nova é olhar a base de testes. Por alí já é possível descobrir uma série de comportamentos e detalhes da implementação do sistema, bem como as intenções de quem o programou. Mas o que você faz quando cai de pára-quedas num projeto que não tem um mísero teste sequer? Você não pode deixar esse problema para outra pessoa? É você o infeliz que tem que resolver o problema e fazer a faxina?

Minha resposta para essa pergunta é bem simples: SIM, você é o infeliz que tem que resolver o problema.

<história>
Uma vez eu trabalhava numa empresa e meu chefe me pediu para fazer um protótipo de um sistema que integrava um website com um PABX para fazer determinadas tarefas. Como era um protótipo e eu só tinha duas semanas, eu fiz ZERO testes (e a aplicação funcionava por milagre divino). Só que para o meu azar, esse protótipo era para fazer uma demonstração para um cliente, que adorou a idéia e comprou na mesma hora! Como meu chefe achava que já estava parcialmente pronto e funcionando, meu prazo para terminar era de mais quatro semanas. Duas semanas depois eu estava desesperado por não conseguir avançar na aplicação e não conseguir fazer o negócio funcionar. Aconteciam bugs estranhos, daqueles que te fazem pensar que você está na profissão errada. Todos os dias eu me arrependia profundamente de ter deixado os testes para trás. Meu chefe ficou desesperado e colocou mais um desenvolvedor para me ajudar. No primeiro dia ele me perguntou: “GC, onde estão os testes para eu dar uma olhada?”. Er.. bom… não tinham testes… E eu fiquei totalmente desmoralizado, fui humilhado, massacrado e apanhei quase até a morte.
</história>

Hoje em dia não abro mão dos testes. Se você entregar uma aplicação que não funciona, a culpa é sua! Então, faça tudo que é possível para garantir que tudo esteja funcionando.

Finalmente, respondendo o e-mail do meu amigo acima (que não posso dizer o nome porque não tenho permissão), eis algumas dicas para você não ficar em maus lençóis:

Dica número 1: faça sempre o melhor que puder! Mesmo que você ache que vai ficar 2 semanas ou 3 meses em um projeto, seu gerente pode mudar de idéia e você pode acabar ficando bem mais tempo do que isso. Então, tire essa idéia da cabeça já e comece a se preocupar com os testes. E mesmo que você com certeza absoluta só fique 3 meses, como que você vai sair de cabeça erguida e com a certeza de que o que você fez está funcionando se você não tem os testes para comprovar?

Dica número 2: conserte as janelas quebradas. Se alguém chega na sua casa e metade das janelas estão quebradas, então não tem muito problema se quebrar mais uma. Porém, se todas as janelas estiverem impecáveis, quebrar uma janela é péssimo! Siga este mesmo princípio para o seu código, não tenha janelas quebradas. Se você tiver 90% de cobertura de testes, todos eles forem impecáveis e nenhum falhar no CruiseControl, o próximo desenvolvedor que chegar se sentirá na obrigação de manter tudo funcionando da mesma forma, porque esta é a cultura do projeto. Já se todos os testes estiverem quebrados ou não houverem testes, não faz a menor diferença.

Dica número 3: não abraçe o mundo com as pernas! Não precisa refatorar a aplicação inteira de uma vez, até porque você corre um grande risco de tudo parar de funcionar e você ser demitido, além de que não vai conseguir implementar as features. Neste caso, minha estratégia seria refatorar o código na medida que precisasse implementar as features. Faria o ciclo normal de TDD: implementaria os testes fazendo refactor na implementação para torná-la testável, implementaria a feature, garantiria seu funcionamento e depois um novo refactor para deixar tudo bonito.

Dica número 4: get them Test Infected! Faça um workshop com os outros desenvolvedores do time e mostre para eles a importância de escrever testes. Ensine-os a usar o CruiseControl, JUnit, JMock, injeção de dependência e tudo mais que for necessário para que os testes aconteçam. Mesmo que você “perca” dois ou três dias de trabalho, com certeza ganhará muito mais desse dia em diante.

<piada>
Dica número 5: só por via das dúvidas, para ajudar nos momentos de fraqueza, coloque alguém para te vigiar em tempo integral. O “Dijkstra is watching” é ótimo para isso, tenha ele sempre por perto.
</piada>

Categories
Scrum

Scrum checklists

Sei que isso já é um pouco antigo, porém, antes tarde do que nunca! 🙂

Para quem está começando a praticar o Scrum, às vezes é um pouco complicado lembrar de todas as regras (apesar de serem poucas). Entretanto, é altamente recomendável seguir todas essas regras à risca, especialmente no início da adoção quando ainda não se tem muita experiência/conhecimento sobre o framework.

Por estes motivos as checklists são muito úteis! O objetivo delas é que você possa ter um micro guia de referência, para andar debaixo do braço e te ajudar a seguir e lembrar das regras.

Recomendo duas:

1) Checklist do Boris Gloger/SPRiNT-iT: essa foi a primeira que eu conhecí e a que mais usei. Quando fiz o curso de Scrum Master, o Boris deu uma versão impressa para os alunos, que é de excelente qualidade (tanto no conteúdo como no material). Ela é feita em papel duro e tem um espaço para anotações ao lado das páginas. Se você imprimir este PDF numa gráfica, deve ficar show de bola!

2) Checklist do Henrik Kniberg/Crisp: essa checklist é muito mais resumida, mas também tem várias informações legais. Neste caso não é um livreto, mas um mind map com vários tópicos importantes para se lembrar.

Combinando essas duas checklists você terá um excelente guia de bolso!

Categories
Carreira

10 livros recomendados para desenvolvedores

No início do ano escreví um post sobre a importância de nós, desenvolvedores de software, lermos livros, que rendeu boas discussões. Depois disso recebí algumas mensagens perguntando quais são os livros que considero mais importantes para um desenvolvedor.

Bom, essa pergunta é complicada de responder. Primeiro porque eu ainda não lí todos os livros que deveria, e segundo porque cada pessoa tem seu gosto particular por tecnologias, processos, frutas e etc.

Então, resolví criar a lista dos 10 livros que eu particularmente mais gosto e que recomendo fortemente para qualquer desenvolvedor. Estes livros são alguns dos que mais me influenciaram a melhorar minha forma de trabalhar e programar. Além disso, coloquei link para os sites, blogs ou páginas de informações dos autores, caso alguém ainda não tenha:

Agile Software Development, Principles, Patterns, and Practices Agile Software Development, Principles, Patterns, and Practices
Robert C. Martin
Agile Software Development with SCRUM Agile Software Development with SCRUM
Ken Schwaber e Mike Beedle
Design Patterns: Elements of Reusable Object-Oriented Software Design Patterns: Elements of Reusable Object-Oriented Software
Erich Gamma, Richard Helm, Ralph Johnson e John M. Vlissides
Domain-Driven Design: Tackling Complexity in the Heart of Software Domain-Driven Design: Tackling Complexity in the Heart of Software
Eric Evans
Extreme Programming Explained: Embrace Change (2nd Edition) Extreme Programming Explained: Embrace Change (2nd Edition)
Kent Beck e Cynthia Andres
Introduction to Algorithms Introduction to Algorithms
Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest e Clifford Stein
The Mythical Man-Month: Essays on Software Engineering The Mythical Man-Month: Essays on Software Engineering
Frederick P. Brooks
Patterns of Enterprise Application Architecture Patterns of Enterprise Application Architecture
Martin Fowler
Peopleware: Productive Projects and Teams Peopleware: Productive Projects and Teams
Tom DeMarco e Timothy Lister
The Pragmatic Programmer: From Journeyman to Master The Pragmatic Programmer: From Journeyman to Master
Andrew Hunt e David Thomas

Infelizmente todos os livros são em inglês e nem sei se existe tradução. Se você não souber inglês, matricule-se urgentemente em algum curso porque saber inglês nesta área é muito importante!

Convido vocês a também fazerem suas listas e compatilharem seus livros preferidos 🙂

Categories
Etc.

Procrastination considered harmful?

Procrastination considered harmful? Not anymore!

No ano passado desobrí um negócio chamado structured procrastination. John Perry, o criador da idéia, explica do que se trata:

I have been intending to write this essay for months. Why am I finally doing it? Because I finally found some uncommitted time? Wrong. I have papers to grade, textbook orders to fill out, an NSF proposal to referee, dissertation drafts to read. I am working on this essay as a way of not doing all of those things. This is the essence of what I call structured procrastination, an amazing strategy I have discovered that converts procrastinators into effective human beings, respected and admired for all that they can accomplish and the good use they make of time. All procrastinators put off things they have to do. Structured procrastination is the art of making this bad trait work for you. The key idea is that procrastinating does not mean doing absolutely nothing. Procrastinators seldom do absolutely nothing; they do marginally useful things, like gardening or sharpening pencils or making a diagram of how they will reorganize their files when they get around to it. Why does the procrastinator do these things? Because they are a way of not doing something more important. If all the procrastinator had left to do was to sharpen some pencils, no force on earth could get him do it. However, the procrastinator can be motivated to do difficult, timely and important tasks, as long as these tasks are a way of not doing something more important.

Structured procrastination means shaping the structure of the tasks one has to do in a way that exploits this fact. The list of tasks one has in mind will be ordered by importance. Tasks that seem most urgent and important are on top. But there are also worthwhile tasks to perform lower down on the list. Doing these tasks becomes a way of not doing the things higher up on the list. With this sort of appropriate task structure, the procrastinator becomes a useful citizen. Indeed, the procrastinator can even acquire, as I have, a reputation for getting a lot done.

Há mais ou menos uns 6 meses decidí adotar gradativamente essas práticas de procrastinação estruturada (ou o certo seria protelação estruturada?). Quanto mais o tempo passa e eu evoluo, mais e mais coisas consigo fazer! Por mais que isso possa parecer uma desorganização total, é muito efetivo.

To-Do listsBasicamente minha única ferramenta é uma lista de coisas a fazer, que procuro manter em ordem de prioridade. Tenho uma meia dúzia de post-its na minha frente com várias coisas que preciso fazer, desde coisas importantíssimas até coisas totalmente supérfluas. Em alguns casos uso até cores para identificar itens mais importantes ou de um certo tipo (como tarefas pessoais ou coisas que se eu não fizer urgentemente posso atrapalhar alguém). Sempre que me lembro de alguma coisa nova, anoto em um post-it e aquilo entra automaticamente na fila. Quando lembro de coisas no meio da rua ou em casa quando estou dormindo, procuro rapidamente anotar em algum lugar para depois poder esquecer tranquilo, e daí quando chego no trabalho eu reorganizo a lista. Ao terminar uma tarefa, simplesmente faço um X do lado para indicar, e de tempos em tempos, faço um refactoring da lista inteira para caber em dois ou três post-its.

Estou bem satisfeito com essa nova forma de trabalhar, porque dessa forma posso tirar o máximo dessa minha característica proteladora! Ultimamente incluí até mesmo tarefas como “ler e-mails” e “blogar” na minha lista, motivo pelo qual só estou blogando depois de quase 3 semanas. Esses últimos dias foram super agitados e minha lista me ajudou a priorizar todas as coisas mais urgentes!

Categories
Engenharia de software

Um exemplo prático de Fluent Interface

Há alguns meses escreví um post sobre Fluent Interfaces, mostrando um trabalho que fizemos aqui na empresa para tornar nossa API interna mais fácil de se utilizar. Depois disso, algumas pessoas me pediram códigos e exemplos de uso da WebMediaAPI, mas o código é da empresa e não posso compartilhá-lo.

Fiquei então com a idéia de criar uma demonstração de uso de Fluent Interfaces na cabeça, mas eu queria usar um domínio fácil para que as pessoas pudessem entender melhor. A WebMediaAPI pode ser até legal, mas o fato é que ninguém conhece o modelo de mídias da Globo.com e fica difícil de explicar ou discutir o que está sendo feito.

Há duas semanas, conversando com o Evandro sobre uma apresentação que faremos mês que vem no evento de tecnologia da Globo.com, ele deu uma idéia super simples e bem legal. Todas as pessoas já trabalharam com e-mail, seja enviando mensagens para outras pessoas ou então escrevendo código para enviar e-mails em diversas linguagens. Esse é um domínio extramanete fácil para todo mundo, e também, é pequeno o suficiente para ser implementado rapidamente em um dia.

Então, nasceu a Fluent Mail API. A Fluent Mail API é uma API simples que utiliza a JavaMail API da Sun para enviar e-mails. Meu objetivo não é criar mais uma ferramenta para envio de e-mails, é apenas demonstrar o uso de Fluent Interfaces como wrapper de um framework maior, simplificando seu uso. A idéia é fazer com que enviar um e-mail seja tão fácil quanto isso:

new EmailMessage()
    .from("demo@guilhermechapiewski.com")
    .to("destination@address.com")
    .withSubject("Fluent Mail API")
    .withBody("Demo message")
    .send();

Você pode ver os códigos-fonte e uma descrição mais detalhada no site do “projeto”. Se alguém quiser discutir, opinar, tirar dúvidas ou qualquer outra coisa, é só comentar.