Archive for August, 2008

Simplicidade

Saturday, August 30th, 2008

Há mais ou menos um mês terminei de ler o livro Presentation Zen do Garr Reynolds. O livro é muito legal e tem excelentes dicas sobre como fazer apresentações baseadas nos princípios Zen. O Garr trabalhou durante muito tempo na Apple fazendo design de apresentações e é fato que a Apple arrebenta nesse quesito. Depois de assistir apresentações que foram verdadeiros shows na Apple WWDC decidí ler o livro e tentar aprender alguma coisa sobre o que eles fazem.

Quando eu estava lendo o livro, um trecho de um capítulo que fala sobre os princípios de design acendeu uma lâmpada na minha cabeça e me fez atentar para uma coisa que acontece diariamente no desenvolvimento de software:

“Design can make things easier for the viewer or the user. Design is not decoration. If anything, design is more about subtraction than addition. Visually, we do not want to include too much, nor do we want to exclude too much. Generally, people err on the side of including too much visual information, which often results in clutter and confusion.

É verdade. Existe uma tendência grande das pessoas acharem que mais funcionalidades e complexidade é sempre melhor. As pessoas pensam exatamente como descreve o livro Getting Real da 37 Signals:

“Conventional wisdom says that to beat your competitors you need to one-up them. If they have four features, you need five (or 15, or 25). If they’re spending x, you need to spend xx. If they have 20, you need 30.

This sort of one-upping Cold War mentality is a dead-end. It’s an expensive, defensive, and paranoid way of building products. Defensive, paranoid companies can’t think ahead, they can only think behind. They don’t lead, they follow.

Transportando para o mundo do desenvolvimento de software, eu vejo que muitos desenvolvedores adoram entulhar seus códigos com todos os design patterns que já ouviram falar, adoram usar EJBs em qualquer coisa, adoram inventar seus frameworks malucos… Enfim, adoram fazer tudo que é complexo e trabalhoso. Assim como no design, entulhar o código com essas coisas só fazem ele ficar muito mais difícil de ser mantido e entendido!

Talvez um dos motivos disso acontecer seja que nem sempre o desenvolvedor tem senso de urgência e visão do negócio. Nem sempre ele entende que não dá para perder 3 dias fazendo um menu JavaScript que abre e fecha, ou passar 80% do tempo tentando encaixar design patterns no código, ou criar uma arquitetura com 36 camadas para diminuir o acoplamento. Essas coisas podem ser extremamente prejudiciais para o projeto, porque o cliente está esperando triplicar o faturamento e o número de visitantes do seu site e essas coisas não vão ajudar em absolutamente nada. A oportunidade de usar design patterns, criar camadas no software ou qualquer outra coisa surgirá naturalmente no decorrer do projeto. Se isso não acontecer, então simplesmente não os use.

Uma dica para descobrir se você ou alguém está fazendo uma coisa útil ou não é tentar responder a seguinte pergunta: “Qual problema será resolvido com isso?”. Ultimamente tenho feito essa pergunta para todo mundo e percebí que muito mais da metade das coisas não são justificáveis. É incrível como as pessoas criam coisas sem nenhum motivo, que só deixam o software mais complexo sem necessidade, tanto internamente (código) quanto externamente (interface).

Por isso eu gosto e recomendo trabalhar sempre com uma das regras básicas do XP. Independente de usar XP ou não, a simplicidade é uma ótima regra:

“A simple design always takes less time to finish than a complex one. So always do the simplest thing that could possibly work. If you find something that is complex replace it with something simple. It’s always faster and cheaper to replace complex code now, before you waste a lot more time on it. Keep things as simple as possible as long as possible by never adding functionality before it is scheduled. Beware though, keeping a design simple is hard work.”

Se você é desenvolvedor e adora complicar tudo, pare de brincar de professor pardal e pense simples, ou é isso que vai acontecer com a sua empresa:

Houston, we have a problem!

Sunday, August 24th, 2008

Oi Guilherme, tudo bom?

Eu tenho uma curiosidade, como vcs aí da Globo fazem quando no Scrum um item que teve pontuação baixa na reunião de planning (algo como 3 ou 5) na realidade é um abacaxi de 40, 50?

De acordo com a mecânica do Scrum, no Sprint Planning o time e o P.O. definem juntos um objetivo para a próxima iteração, que é o Sprint Goal (um exemplo de goal seria “prover serviços para que um usuário possa despublicar seus vídeos do site”). Após a definição do Sprint Goal, é selecionada uma porção do Product Backlog para que esse objetivo seja atendido.

A partir daí você tem o Sprint Backlog, que é o conjunto de histórias que serão trabalhadas no próximo Sprint.

Se no meio de um Sprint você percebe que uma dessas histórias é um monstro 10 vezes maior do que parecia, você pode fazer uma das duas coisas:

1) Se essa história puder ser removida sem afetar o Sprint Goal, basta tirar a história do Sprint. É importante no entanto que se descubra as causas disso ter acontecido (pode ser na Sprint Retrospective) para que não aconteça novamente. As estimativas têm uma margem de erro implícita, mas quando alguma coisa multiplica tantas vezes assim de tamanho pode ser que o time não esteja conversando o suficiente sobre as funcionalidades antes de estimar. Muita gente fala inclusive que o principal produto de uma reunião de estimativas não são as estimativas em sí, mas o conhecimento que o time adquiriu discutindo sobre os problemas.

2) Se essa história for fundamental para atender ao Sprint Goal, o Sprint deve ser cancelado e um novo Sprint Planning deve ser feito. Se você não pode trabalhar na coisa que adiciona mais valor para o projeto, ou seja, uma história que atende diretamente ao goal definido junto com o P.O., é preciso fazer um novo planejamento para descobrir no que trabalhar. No Sprint planning pode-se decidir várias coisas, desde quebrar essa história em histórias menores até descobrir que dada a nova estimativa o custo-benefício da história não vale a pena e ela deve perder a prioridade no backlog.

Por isso é muito importante ter objetivos muito bem definidos. Um bom Sprint goal ajuda o time a se reorganizar em caso de problemas, além é claro de ajudar a focar no que é mais importante para o projeto no momento.

No mais, recomendo a leitura dos capítulos 3.5 e 3.6 do Agile Software Development with Scrum que falam sobre a definição do goal no Sprint Planning e a mecânica dos Sprints, incluindo uma parte sobre cancelamento de Sprints.

[Agile 2008 Conference] Vídeos e fotos da conferência

Sunday, August 24th, 2008

Para quem quiser saber um pouco mais sobre o que rolou na Agile 2008 Conference, veja a página especial do InfoQ sobre a conferência. Foram filmadas 18 apresentações que serão disponibilizadas conforme o calendário que está no site. Assistam no mínimo 10 Ways to Screw Up with Scrum and XP do Henrik Kniberg, que inclusive comentei aqui no blog! Essa é muito legal!

Além disso têm algumas fotos que você pode ver no meu Flickr e no do Marcello Azambuja. Enjoy!

[Agile 2008 Conference] From High-performing to Hyper-performing Agile teams

Saturday, August 23rd, 2008

Voltei depois de quase duas semanas para fazer meu último comentário sobre a Agile 2008 Conference (antes tarde do que nunca!). Esses dias foram um pouco agitados e acabei não conseguindo escrever antes…

O painel de discussões entitulado From High-performing to Hyper-performing Agile teams com a participacao de Jeff Sutherland, Rob Mee e Jason Titus foi ótimo para mim. Eu não esperava ouvir certas coisas que ouví, mas foi ótimo para pensar e abrir mais ainda a cabeça.

Foram quase duas horas de discussão sobre vários assuntos, até o famoso mito do “Rails não escala” entrou em pauta. Mas o que eu quero falar é de uma boa parte da discussão que foi relacionada à PatientKeeper, empresa na qual o Jeff é CTO e na qual concebeu o Scrum para desenvolver vários sistemas na área da medicina que fazem desde o controle do histórico de pacientes e armazenamento digital de exames até soluções para ajudar a organizar enfermarias, departamentos administrativos e o que mais você imaginar que um hospital tem. A PatientKeeper é inclusive citada no livro do Ken Schwaber e reconhecida como o início da existência do Scrum.

A primeira coisa que me surpreendeu é saber que 80% dos testes desses sistemas não são automatizados. Por incrível que pareça, a justificativa do Jeff é muito razoável: todos os sistemas da PatientKeeper são feitos para funcionar numa variedade enorme de dispositivos, desde Palms até iPhones e computadores convencionais. Basicamente o sistema tem que funcionar onde os médicos se sentirem mais confortáveis para usar. Ele argumentou que é muito difícil automatizar testes de interface em todos esses dispositivos, e por isso eles têm uma equipe de testes responsável por fazer este trabalho.

Antes de tudo, não, eu não acho isso ideal, inclusive eu sou um grande adepto dos testes de aceitação automatizados. Mas no caso deles não é possível automatizar os testes, então, bola para frente oras!

Recentemente no meu time na Globo.com passamos por algo parecido quando acabamos optando por não fazer testes de uma aplicação da forma que achavamos ideal. Como já diz o ditado, o ótimo é inimigo do bom. O que nós precisavamos era de uma solução suficientemente boa e que fosse implementável. A solução ideal demoraria muito para ser implementada e daria um trabalho enorme para ser mantida. Já a solução que demos, apesar de não ser perfeita, já está pronta e começando a render seus frutos.

Resumindo isso tudo, temos que tomar cuidado para não sermos utópicos – algumas vezes temos que ser pragmáticos e fazer o que resolve o problema.

A segunda coisa é que me surpreendeu é que, para cada grande funcionalidade que eles fazem, é feito antes do desenvolvimento todo o design e um protótipo do sistema para aprovação de todos os usuários (os médicos) e só depois de aprovado o protótipo o sistema é desenvolvido.

Mais uma vez, eu não acho ideal. Definidas as necessidades do projeto e sabendo onde se quer chegar com o produto, o melhor é que o time inteiro trabalhe junto, história por história, criando pequenos incrementos de software até que tudo esteja pronto. Inclusive eu cheguei a perguntar se ele não estaria fazendo uma espécie de “Scrum waterfall”, e ele nem pensou para responder categoricamente que não. Em primeiro, esse esquema não é feito para qualquer coisa, mas sim para as grandes funcionalidades e mudanças ou para sistemas novos. E em segundo, ele disse que alguns médicos são extremamente resistentes para usar o software no início, e se eles suspeitarem que há qualquer problema no projeto do software ou que “aquele botãozinho está difícil de enxergar”, eles simplesmente destroem o produto e perdem a vontade de usar. Considerando tudo isso e ainda que as mesmas coisas têm que funcionar numa dezena de dispositivos diferentes, deve ser realmente um desafio e tanto projetar essas interfaces para terem uma boa experiência de uso. Por isso tudo o design das telas é crítico para eles, e para ajudar a lidar com essa questão o processo de trabalho foi adaptado para ter esse “pré-projeto” dos sistemas.

A mensagem que devemos tirar dessas experiências é que não dá para ficar preso a uma metodologia! As metodologias servem para ajudar e não para te impedir de atender aos seus clientes e entregar software da maneira que é mais adequada para eles. Indivíduos e interações são mais importantes que processos ou ferramentas, e é entender isso plenamente que te faz ser verdadeiramente ágil. Os processos ágeis como o Scrum são adaptativos, e é sim recomendável que você siga eles à risca no início mas nada te impede de fazer ajustes ao longo do caminho – desde que você não quebre os pilares básicos como o desenvolvimento iterativo e incremental e as práticas/reuniões/papéis no caso do Scrum.

Pense fora da caixa!

[Agile 2008 Conference] Henrik Kniberg: 10 ways to screw up with Scrum and XP

Thursday, August 7th, 2008

Gostei muito da apresentação do Henrik Kniberg “ensinando” 10 maneiras para arruinar seus projetos mesmo usando XP e Scrum. É óbvio que eu não quero acabar com os meus projetos, mas é legal debater sobre os erros mais comuns nas adoções de metodologias ágeis e seus motivos para poder evitá-los.

Uma coisa interessante é que o Henrik costuma usar com sucesso a mesma combinação de XP e Scrum que usamos na Globo.com. Não por acaso, tanto o seu livro Scrum and XP from the Trenches quanto a apresentação (mesmo quando ainda não tinha assistido) e o seu blog sempre foram boas fontes de referência para mim.

Resumidamente, as 10 maneiras mais comuns de arruinar projetos com XP e Scrum são:

  • Futilidades: debates homéricos sobre coisas como “vamos usar cartões ou post-its” quando o time sequer tem um P.O.! Os problemas devem ser atacados em ordem de importância. Além disso, a aplicação do processo não precisa ser perfeita desde o início. Good enough is good enough.
  • Definition of Done: muitos times não tem uma definição de pronto ou não respeitam essa definição. Isso não só é essencial como também é preciso que o cumprimento desta definição esteja dentro do controle do time.
  • Velocidade: não é conhecida, usada ou é muito variável ao longo das iterações.
  • Retrospectivas: não há retrospectivas e o time não evolui suas práticas ao longo do tempo aproveitando-se dos aprendizados obtidos nas iterações.
  • Comprometimento do time: time é cobrado e sempre culpado por erros em estimativas. Isso faz com que eles sempre se comprometam com menos do que podem fazer, com medo de serem culpados novamente.
  • Débito técnico: é totalmente ignorado e só cresce ao longo das iterações.
  • Trabalho em equipe: não há trabalho em equipe e existem tarefas fixas para determinadas pessoas, o que faz com que várias histórias sejam implementadas em paralelo.
  • Product Backlog: não existe ou não está priorizado corretamente.
  • Integrações da base de código: não existe um branch onde o código pode ser lançado em produção a qualquer momento e a gerência da base de código não é agil.
  • Sprint Backlog/quadro de tarefas: não existe, está longe do time, é muito complicado ou não é usado durante o Daily Scrum e atualizado diariamente.

É óbvio que essas não são as únicas maneiras de fazer besteiras em projetos com XP e Scrum e pode até ser também que tenham algumas maneiras mais “eficazes” que essas. No entanto esses problemas são muito comuns e acho que por isso mereceram destaque na apresentação.

Você pode encontrar os slides da apresentação no site do Henrik Kniberg. Esses slides são de uma apresentação um pouco mais antiga mas não há muitas diferenças.

[Agile 2008 Conference] Mary Poppendieck: The five dimensions of a system

Wednesday, August 6th, 2008

Agile 2008 - Mary PoppendieckPela primeira vez tive a oportunidade de assistir uma apresentação da Mary Poppendieck, e devo dizer que fiquei impressionado pela qualidade da apresentação… A mulher é simplesmente uma enciclopédia humana!

A Mary começou falando sobre histórias de “plank roads” (estradas de tábuas de madeira). Há muito tempo, quando todas as estradas eram de terra e cheia de buracos, alguém teve a idéia de fazer estradas de tábuas de madeira. Os benefícios foram muitos e enormes para a época: os transportes ficaram muito mais rápidos, o desgaste dos carros ficou muito menor, e por aí vai. Como essas estradas tinham um custo muito alto para serem produzidas, estimou-se que seriam necessários dez anos para que elas se pagassem. No entanto, quando as estradas ficaram com cinco ou seis anos começaram a se deteriorar, e era seria necessário fazer uma grande reforma para que elas voltassem a ser usáveis. Desta forma as estradas de tábuas se mostraram um péssimo negócio, pois com esse ciclo de implementação e manutenção jamais se pagariam. E aí a Mary levantou uma questão: assim como acreditava-se que as estradas de tábuas de madeira resolveriam todos os problemas do mundo até que os pontos negativos foram percebidos, será que o desenvolvimento ágil também não é uma estrada de tábuas e a qualquer momento vamos achar seus problemas?

Isso foi o gancho para ela mostrar várias histórias de estradas de tábuas, ou seja, histórias de coisas que acreditava-se que eram excelentes mas que depois foram mostrando seus problemas. Ela citou vários exemplos desde o waterfall até as ferramentas RAD, e levantou vários pontos sobre porque essas idéias fracassaram.

O que estamos tentando fazer hoje com desenvolvimento ágil é uma tentativa de resolver vários desses fracassos que tivemos em experiências passadas. A experiência com esses problemas e o entendimento das suas causas fez com que nascessem várias das linhas de desenvolvimento ágil que temos hoje como o XP, Lean Software Development e Scrum. Ainda acredita-se que o desenvolvimento ágil está no caminho de resolver vários problemas, portanto, respondendo à pergunta inicial, na opinião da Mary ainda não existem evidências de que o desenvolvimento ágil é uma “estrada de tábuas”.

Para encerrar, a Mary falou das cinco dimensões de um sistema e algumas questões sobre essas dimensões. Se você responder sim para todas essas perguntas (ou pelo menos a maioria), você está no caminho certo para desenvolver software de qualidade, de forma eficiente e que atende aos seus clientes.

Motivo/Razão do sistema

  • Os especialistas técnicos estão sempre atualizados com o objetivo geral do sistema?
  • Os técnicos do time vão checar por sí mesmos qual é o verdadeiro problema que o sistema deverá resolver?
  • Existe um líder técnico que é responsável por atingir o objetivo do sistema e que guia o time tecnicamente caso necessário?
  • Existem ciclos de aprendizado para descobrir se o sistema está servindo para o que se propõe e melhorá-lo de acordo com os objetivos?

Estrutura

  • O time tem uma boa visão do todo sobre o que eles estão produzindo, sobre a empresa e sobre como o seu trabalho se encaixa no todo?
  • Existem ciclos de aprendizado que munem os desenvolvedores com feedback sobre o uso do sistema?
  • Os desenvolvedores menos experientes são treinados e supervisionados para garantir que eles produzirão código de boa qualidade que incorpora a aprendizagem de erros cometidos anteriormente?
  • O trabalho é revisado por alguém apropriado?

Integridade do sistema

  • A integridade do sistema é parte integrante do desenvolvimento, e quando ele é finalizado pode-se assumir que o sistema já está completamente testado?
  • O sistema é desenvolvido de tal forma que é necessário um tempo desprezível para merges e testes no final?
  • As falhas são raras e são investigadas a fundo para descobrir padrões que podem servir para resolver e previnir problemas similares no futuro?
  • Esse conhecimento é capturado, consolidado e disseminado de uma maneira efetiva?

Tempo de vida do sistema

  • O tempo de vida e possíveis futuras modificações são considerados no projeto e desenvolvimento do sistema?
  • As pessoas que vão operar o sistema estão envolvidas no seu projeto?
  • O time de desenvolvimento permanece envolvido com o sistema a longo prazo?
  • As recompensas estão estruturadas de forma que desenvolver um sistema robusto que funcione bem ao longo dos anos é o comportamento mais encorajado?

Resultados do sistema

  • O sistema atinge muito bem o seu objetivo e os clientes conseguem antecipar algum retorno sobre o investimento?
  • O sistema atinge seus objetivos financeiros, dentro do seu custo e prazo planejados?
  • O sistema funciona sem falhas e há confiança que ele continuará assim?
  • O sistema atende plenamento àqueles que o operam, usam, suportam, mantém e criam algum valor com ele?

Você pode encontrar os slides da apresentação no site da Mary Poppendieck.