Novos Desafios…

September 27, 2009

… na Globo.com!

Desde o início do mês estou fazendo parte de um novo time. Trata-se do Time Beta (Peleteiro, Meyer, Cainã Nunes e eu), responsável pelo desenvolvimento de novos produtos (ou novas versões de produtos existentes). Nosso primeiro produto é o Baixatudo, cujo release inicial já está no ar. Consideramos esse release uma versão bem básica do produto. Temos muito trabalho ainda pela frente e esperamos nos próximos releases entregar um produto cada vez melhor.

O lado ruim dessa mudança é sair do time de webmedia, onde tive a oportunidade de trabalhar com pessoas fodas e aprendi bastante! Nesse tempo que estive lá, trabalhamos em projetos bem interessantes. Além disso, acredito que tivemos algumas evoluções significativas, como:

  • Melhor preparação do backlog, envolvendo os especialistas de UX junto com o PO para deixar as histórias prontas pro time implementar (ainda há muito que melhorar nisso, mas acredito que foi dado um importante primeiro passo). Mais sobre isso em um post que já está tempo demais no meu drafts;
  • Cultura de deixar bem explícito os problemas que estamos enfrentando, com dados concretos, mostrando os impactos no projeto;
  • Grande preocupação com práticas ágeis como programação em par, desenvolvimento outside-in, TDD, BDD, integração contínua, etc. Sempre feito de forma pragmática, ou seja, focado em melhorar o desempenho do time e não por se tratar da última moda.

Por outro lado, no novo time estou bastante empolgado pois volto a exercer um papel mais de desenvolvimento. Tenho certeza que vou aprender e evoluir bastante e espero poder contribuir para o sucesso dos nossos projetos.

Ah, não se esqueça, estamos contratando!


InfoFundos

March 23, 2009

Está no ar o InfoFundos, um site onde é possível acompanhar as rentabilidades de todos os fundos de investimento do mercado financeiro brasileiro. Mas este post não é sobre o site em si, e sim sobre o seu desenvolvimento.

O site é um projeto pessoal desenvolvido por mim com ruby e rails. O legal deste tipo de trabalho solo é a possibilidade de experimentar ideias, práticas, técnicas, etc.

Como não poderia deixar de ser, o desenvolvimento seguiu – e continua seguindo – os princípios e valores dos métodos ágeis. Ou seja, o site está sendo desenvolvido de forma incremental e evolutiva. A ideia é ir colhendo feedback para evoluir continuamente. Cada funcionalidade é desenvolvida da forma mais simples que poderia funcionar (simplest thing that could possibly work), com refactoring constante para deixar o código o mais limpo possível.

Uma técnica que pude usar desde o início e que ajuda a garantir a aplicação dos princípios e valores acima é o desenvolvimento outside-in sugerido pelo BDD. Cada funcionalidade é descrita por uma feature do cucumber guiada por selenium. Um passo dessa feature é escrito e, obviamente, ele falha. Então é preciso escrever apenas código suficiente para fazer este passo passar. Para isso, escrevo um spec com rspec e depois apenas o código necessário para este spec passar. Continuo assim sucessivamente, escrevendo specs e código, de fora para dentro, ou seja, das camadas mais externas até as mais internas, até que o passo esteja passando. Então, repito o ciclo continuando com o próximo passo até que toda a feature esteja passando. O ciclo completo seria algo mais ou menos assim:

feature > step > spec > implementação para spec passar > repete spec e implementação até step passar > repete step até feature passar

No final, tenho uma funcionalidade totalmente coberta por testes de aceitação com cucumber/selenium e com 100% de cobertura com rspec. Isso ajuda a garantir um código limpo, podendo ser refatorado e evoluído com bastante segurança.

Tenho diversas ideias de funcionalidades futuras para o InfoFundos e, certamente, qualquer assunto relacionado ao seu desenvolvimento será postado aqui.


Retrabalho Não Combina Com Equipes Ágeis

January 9, 2009

Retrabalho significa jogar tempo, dinheiro, etc. fora. Certamente, ninguém quer isso. Para tentar evitar esse retrabalho, normalmente a solução proposta envolve especificar “bem especificado”, planejar “bem planejado”, tudo com muita antecedência. É a velha muscle memory agindo. Sabemos que isso não funciona. Simplesmente porque é impossível prever o futuro.

A solução que eu acredito funcionar é aplicar as práticas de XP. E não basta aplicar uma ou outra, temos que aplicar todas. Juntas elas promovem uma sinergia que não existe quando são utilizadas de forma isolada.

Práticas como TDD, refactoring, integração contínua, programação em par, cliente presente, sentar-se junto, design incremental garantem uma base de código saudável, com design simples. Com isso o custo de mudança permanece constante ou mesmo pode cair com o tempo.

Kent Beck viu em muitos times XP que ao longo do tempo os sistemas desenvolvidos por esses times ficavam cada vez mais flexíveis e fáceis de mudar ao invés do que estamos mais acostumados a ver, que são aqueles sistemas legados cujo custo de mudança cresce exponencialmente com o tempo. Tal afirmativa pode parecer ir contra o senso comum mas faz todo o sentido quando temos as práticas do XP aplicadas corretamente.

O custo de um time XP competente é inegavelmente alto. Mas compensa no longo prazo por permitir que sistemas não precisem ser reescritos do zero a cada x anos. Além disso, outros motivos existem para se ter um time competente. Por exemplo, evitar o custo dos Net Negative Producing Programmers. Ou seja, na minha opinião vale a pena pagar pelos melhores.

Tenho vendido a idéia de que se uma equipe ágil está funcionando bem, nunca haverá retrabalho e sim, simplesmente, trabalho.


Priorização de Histórias

December 7, 2008

Nos métodos ágeis, o Cliente ou Product Owner deve priorizar as histórias que serão desenvolvidas de forma a maximizar o Return On Investment (ROI).

Vamos supor dois cenários de projeto diferentes. Num, o cliente estipula uma data limite para o release do projeto mas não podemos prever quais histórias estarão prontas até lá. No outro, o cliente define o conjunto mínimo de histórias necessário para o release mas não temos como saber quando elas estarão prontas.

No primeiro cenário é bem claro qual a vantagem em priorizar as histórias. Quando chegar a data limite para o release, o time terá desenvolvido as histórias que agregam o maior valor para o cliente. Ficará de fora aquilo que é menos importante.

No segundo cenário poderia se argumentar que a priorização não é importante. Como todas as histórias serão desenvolvidas de qualquer maneira, tanto faz a ordem. Mas isso não é verdade. A priorização nesse cenário é tão importante quanto no anterior.

Em primeiro lugar, a decisão de só fazer o release quando o conjunto de histórias estiver pronto pode mudar. Por exemplo, pode surgir um novo projeto, mais importante, e se decidir por fazer o release com o que estiver pronto. Nesse caso, é importante que o que estiver pronto seja o que agrega mais valor.

Além disso, mesmo que a estratégia inicial seja mantida e o produto só seja lançado quando o conjunto de histórias estiver todo pronto, a priorização é importante para manter o foco no problema que se quer resolver com o produto. Isso ajuda a definir claramente para todos os envolvidos qual a visão para o produto.


Falando em Agile 2008

October 22, 2008

Nesta quinta e sexta-feira (23 e 24/10/2008) estarei em SP para o Falando em Agile, um grande evento sobre métodos ágeis. Organizado pela Caelum, contará com palestras de Guilherme Chapiewski, Phillip Calçado, Antônio Carlos Silveira e Danilo Bardusco, entre outros.

Certamente promete!


Mudança nos Requisitos

March 12, 2008

Vou usar uma situação que aconteceu em um projeto que eu trabalhei recentemente para mostrar como um método ágil de desenvolvimento e um contrato de escopo negociável lidam (ou melhor, lidariam) bem com requisitos que mudam/evoluem. Um dos requisitos do sistema era permitir que o usuário cadastrasse uma ficha. Em outro momento, um usuário iria preencher essa ficha no sistema. Antes do sistema existir, o cliente utilizava o Excel para criação e preenchimento dessas fichas. Simplificando um pouco, uma ficha continha quadros que por sua vez continha itens. Itens podiam ser de diversos tipos: campo texto de livre preenchimento, seleção única, seleção múltipla, etc.

O projeto adotava oficialmente RUP como metodologia de desenvolvimento. Mas, na prática, era um verdadeiro cascata. Longas fases iniciais onde todos os requisitos eram detalhados de forma exaustiva. Logo em seguida, o modelo de dados era totalmente especificado (por questões que estavam além do controle de nós desenvolvedores, o foco da modelagem eram os dados do sistema e não o modelo de domínio do sistema). Assim, o modelo de dados da ficha havia sido especificado nessas fases iniciais do projeto, utilizando como base algumas fichas de exemplo que o cliente utilizava no dia a dia das suas atividades naquela época. A implementação dessa funcionalidade só aconteceu meses depois. Pouco após ela ficar pronta, descobriu-se que o cliente não estava mais usando as fichas que foram utilizadas para definir o modelo de dados. As fichas tinham evoluído para uma nova versão. Pior, o modelo de dados existente não suportava essa nova versão das fichas.

Aí é que começam os problemas. A empresa onde eu trabalhava simplesmente não podia aceitar essa mudança de requisito. O contrato definia prazo, custo e escopo e estipulava multas caso alguma dessas variáveis não fosse atendida. Se a empresa aceitasse implementar a mudança, certamente estouraria prazo/custo e seria multada. Por outro lado, a funcionalidade, da forma como estava implementada, simplesmente tinha valor zero para o cliente. Não servia para nada. Percebe-se que a metodologia em cascata junto com o contrato fixo criou uma situação onde ambos fornecedor e cliente saem perdendo. Fornecedor e cliente até poderiam usar documentos do projeto, contratos, etc. para definir de quem é a culpa para tal situação. Mas isso não resolveria o problema que é ter a funcionalidade implementada de forma que traga valor para o cliente. Para contornar o problema, cliente e fornecedor teriam que sentar para renegociar o contrato, aumentando prazo/custo ou talvez adiando a implementação da funcionalidade para uma futura versão do sistema. Certamente uma solução pouco satisfatória e que ainda por cima geraria um atrito grande na relação cliente/fornecedor. Não sei dizer como foi resolvido o problema, pois saí do projeto antes.

Por outro lado, se fosse adotado um método ágil junto com um contrato de escopo negociável, a situação narrada não seria um problema, e sim algo normal, esperado de acontecer. Assim, a funcionalidade seria implementada no menor tempo possível e de forma que agregasse valor para o cliente. Vejo dois cenários possíveis.

No primeiro, quando a funcionalidade fosse priorizada para implementação, a nova versão da ficha em Excel já estaria sendo utilizada pelo cliente. Como seria somente nesse momento que a funcionalidade seria detalhada, a modelagem já seria feita baseando-se na nova versão. Ou seja, ao deixar a modelagem desta funcionalidade para que fosse feita no Último Momento Responsável (Last Responsible Moment), evitaria-se um retrabalho.

No segundo cenário, a funcionalidade já estaria implementada quando a versão da ficha fosse alterada. Nesse caso, surgiria uma nova história para adequar a ficha à nova versão, que seria priorizada juntamente com as demais histórias restantes. Provavelmente ela seria priorizada logo na iteração seguinte, tendo em visto o valor que traz para o cliente. O retrabalho não teria sido evitado, mas a alteração seria algo trivial e não demandaria uma burocracia excessiva nem geraria atritos fornecedor/cliente. Isso porque métodos ágeis em geral criam um ambiente que favorece mudanças, ao contrário de metodologias mais tradicionais que tentam evitar esse tipo de mudança a qualquer custo.


Follow

Get every new post delivered to your Inbox.