Xtreme Programming - On Demand

Olá pessoal, estou de volta e dessa vez vou falar sobre um dos temas mais polêmicos do Extreme Programming que é o Pair Programming.

O Pair Programming consiste em dois desenvolvedores atuando no mesmo problema no mesmo computador, sendo um o Piloto e o outro o Navegador. Semelhante ao que temos nas corridas de Rally :p .

Bom, o primeiro grande desafio da programação em par é convencer os nossos chefes de que não será improdutivo manter duas pessoas no mesmo computador full-time. O segundo desafio é a equipe, infelismente nem todos estão aptos a trabalhar com Pair Programming. Muitos, ao invés de serem navegadores, serão simplesmente passageiros, enquanto o piloto desenvolve o passageiro apenas contempla a paisagem e não presta atenção nem mesmo no caminho que está sendo tomado.

Pois bem, na minha opnião, não é necessário ter dois desenvolvedores juntos full-time nas tarefas do projeto, eu acredito mais no Pair Programming On Demand, ou seja, para tarefas mais específicas, desafios maiores, requisitos que possuem maior risco, complexidade. Até porque, pensem comigo, para que ter dois desenvolvedores na implementação de uma solução simples, getters and setters, binds, dao's, ou seja, tarefas rotineiras que já estão no sangue da equipe de desenvolvimento, nestes casos penso que Pair Programming não agrega muito.

Agora quando temos uma rotina complexa, onde temos um grande risco envolvido, ou uma refatoração mais delicada, aí sim, acho que é muito válido a aplicação do Pair Programming para que o problema, o desafio seja resolvido, por isso que digo que acredito mais no Pair Programming On Demand, ou seja, aquele que só é aplicado quando surge uma demanda específica que justifique duas cabeças pensando no problema.

Os defensores mais ferenhos da técnica podem dizer que assim não temos o código completamente compartilhado pela equipe, ou que não inibimos o XGH, ou que decisões podem ser tomadas por um único programador.

No caso das decisões de design, eu diria que o ideal não é nem envolver só dois desenvolvedores mas todos. Em nosso projeto o que tem acontecido é que quando detectamos algum ponto que pode ser melhorado ou quando nos deparamos com algum requisito que demandará a aplicação de algum pattern ou criação de alguma biblioteca nova, sentamos e discutimos.

Com isso, quando forem aplicar Extreme Programming, como tudo na vida, usem e abusem do bom-senso e preste atenção na composição da equipe, certifique-se que os são porcos e não galinhas, e para perceber isso basta observar o comportamento dos desenvolvedores quando não estão pilotando, ou seja, se ele fizer um papel de navegador, tem grandes chances de ser um porco, se fizer papel de passageiro, tem grandes chances de ser galinha.

É isso pessoal, não tenham medo nem vergonha de "parear" em suas equipes, sem dúvida nenhuma duas cabeças pensam melhor do que uma, mas tenhamos bom-senso, pares para get e set, factories, singleton, binds e outras atividades tão triviais do nosso dia-a-dia... na minha opnião não fazem sentido.

Um grande abraço.

Testes Unitários

Olá pessoal, Apesar do tempo longe ainda estou vivo. Pois bem, as últimas semanas tem sido muito corridas, em especial por dois fatos: Testes e GUI.

Bom, em relação a GUI vou deixar para outro post. Hoje quero falar sobre testes unitários.

Há um tempo ouvi falar de um tal de teste unitário. Um negócio meio estranho de escrever um código para testar seu próprio código. Uma parada meio louca mas que todo mundo diz que é bom e funciona =). Talvez essa seja a sensação que a maioria dos programadores tem quando lê sobre testes unitários a primeira vez.

Hoje muito se fala em teste unitário, mas acredito que infelizmente muita gente ainda não faz. No projeto em que eu estava anteriormente, era bem complicada a adoção de testes unitários, não tínhamos um modelo bem definido, não tínhamos separação lógica de camadas, a GUI tinha praticamente toda a inteligência do negócio, a persistência também estava na GUI, sem contar na ferramenta defasada, enfim, um clássico projeto legado que precisa ser mantido e evoluído ao mesmo tempo. Por este cenário, era quase utópico pensar em testes unitários, em cobertura de testes então, era quase impossível.

Pois bem, neste novo projeto, produto novo, sendo concebido do zero, seguindo uma série de boas práticas, guiados pelo DDD, não tínhamos porque não fazer testes unitários. Primeiramente pensamos logo no TDD, mas como não tínhamos muita experiência com testes unitários, resolvemos adotar o teste unitário, mesmo que depois do código pronto, para depois, dentro de alguns sprints, adotarmos o TDD.

Começamos o projeto, escrevendo nossos testes baseado em alguns artigos que encontramos. Procurei alguns livros mas não encontrei nenhum aqui no Brasil que me despertasse interesse. Tinham alguns em sites lá de fora mas o prazo de entrega era muito longo, e não poderíamos esperar para começar a escrever, decidimos então fazer com o pouco conhecimento que tínhamos, as dúvidas pesquisaríamos e iríamos vencendo os obstáculos a medida que fossem aparecendo, além de refatorar os mesmos quando necessários.

Iniciamos os sprints, escrevendo nossos testes com o NUnit, adquirimos o NCover para nos auxilliar na cobertura, para identificar o que não estava coberto por testes unitários, bom, mas isso não vem ao caso pois cobertura de testes vai ser assunto para outro post.

Durantes nossos testes, não tivemos poucas dificuldades, tivemos MUITAS. A prática traz a excelência e como não tínhamos prática, estávamos muito distante da tal excelência(como ainda estamos).

Vou compartilhar agora alguns questionamentos que passamos:

· “O que testar ?“ - Apesar de ser um questionamento simples, tivemos esta dúvida. Testamos a persistência, o facade e o repositório ? Não parece redundante ? Mas pode haver alguma falha de comunicação entre as camadas, se não testarmos não pegaremos estes erros ? Devemos testar os Get e Set do modelo ? e por aí vai...

“Como testar a persistência ?” - Se temos uma camada única de persistência, usando NHibernate, não seria redundante escrever os testes de update, delete, getById, getList etc... para cada modelo ? Não teríamos apenas que testar estes métodos uma vez ? Não teríamos apenas que testar os mapeamentos dos modelos ? Não teríamos como fazer isso de forma automática ? Além disso, temos que garantir que o banco de dados seja o mesmo ao final do teste, para não impactar testes futuros, como gerar estes dados ? Como garantir a estabilidade do ambiente ? e por aí vai....

· “Usar ou não usar Mocks” – Quando devemos usar Mocks ? Para que eles servem ? Usando Mocks não estamos fazendo com que o ambiente de teste seja “forjado”, fugindo da realidade ? e por aí vai...

· “Que padrões adotar para testes” – Uma classe de teste para cada classe de negocio ? Quais padrões de nomenclaturas ? Como separar os namespaces e assemblies de testes ? e por aí vai...

Nós sabíamos que não seria fácil, o começo é a parte mais traumática de qualquer novo desafio, e não contentes com estas dúvidas, fomos atrás de respostas. Durante nossas pesquisas, vimos inúmeros exemplo simples, como por exemplo, testando os Get e Set, testando o somar, subtrair, testando uma rotina de desconto, validação de dados, enfim... De certa forma nos decepcionamos, a sensação que tivemos é de que testes unitários, cobertura de testes era uma lenda. Todo mundo dizia que era bom, todo mundo dizia que era importante, mas ninguém dizia como fazer de fato em um projeto real.

Pois bem, não desistimos, sabíamos da importância dos testes, sabíamos que só dependia de nós. Estudamos mais um pouco, erramos mais um pouco, refatoramos muito e continuamos a escrever nossos testes.

Na falta de padrões de mercado que nos dessem segurança, seguimos de acordo com o que achávamos ser o mais correto e coerente baseado em tudo o que havíamos lido, feito e discutido. Decidimos que todas as classes seriam testadas, criamos um método genérico para testar o mapeamento de todas as classes no NHibernate, separamos os testes em dois assemblies, um de testes de interface e outro para os testes do Selenium, para a nomenclatura usaríamos em português de forma mais clara possível, mesmo que as vezes o nome fique gigante rs.

Bom, seguimos escrevendo nossos testes, buscando o máximo de cobertura possível. Ainda existem alguns desafios como por exemplo a automatização dos teste de GUI, estamos amadurecendo no uso do Selenium e em breve postarei sobre isso.

Bom, não sei se consegui transmitir aqui a mensagem desejada. O que eu queria deixar claro é que fazer testes unitários NÃO é tão fácil quanto parece. Existe uma grande possibilidade de você desanimar e chutar o balde diante das dificuldades iniciais, e continuar desenvolvendo sem testes unitários, a sensação que você pode ter no inicio é de que isso é uma lenda e não funciona.

Mas eu lhes digo, é apenas uma sensação inicial, testes unitários funcionam e eu não consigo me imaginar desenvolvendo sem eles. Em breve postarei aqui sobre os benefícios que percebi após adoção dos testes unitários.

Meu recado final é: Façam testes unitários. Superem as dificuldades. No início eles não serão os testes mais elegantes e eficientes do mundo, mas com o tempo você pega o jeito, refatora os mesmos e logo logo não conseguirá mais programar sem eles, portanto, se for para desenvolver um projeto de software, faça testes unitários, sempre que possível.

P.S.:É claro que estes testes devem estar em um ambiente automatizado, com cobertura medida e tudo mais, mas isso é assunto para um outro post, neste limito-me a algumas das experiência vividas com Testes Unitários, sem nem mesmo entrar no mérito do TDD ainda. Caso alguém tenha um livro para indicar sobre testes unitários, padrões e boas práticas de testes unitários, TDD para nos indicar, fiquem a vontade =) =). Fiquem a vontade também para compartilhar suas experiências, vamos mostrar para o mundo que SIM, teste unitário funciona e é fundamental para o desenvolvimento de softwares de qualidade.

Até logo pessoal, um grande abraço.

De volta, de novo, novamente, Again!!!

Olá pessoal, esse meu último afastamento foi o maior de todos, alguns meses se passaram sem posts no blog. :/

Mas agora, estou "de-volta, de-novo, novamente, Again!!!", a redundancia é proposital, para enfatizar as ida

Pois bem, agora estou de volta com força total. Neste post vou atualizar vocês com algumas coisas que aconteceram nestes últimos tempos.

Para começar, quem conhece sabe que a adoção de métodos ágeis não é fácil. Eu acredito até que seja mais dificil do que um processo formal, ditado por regras e documentações extensivas.

Até mesmo em um ambiente digamos "propício" a uma metodologia ágil, com uma equipe experiente, motivada, uma liderança forte e bem definida, com um cliente participativo no projeto, mesmo neste ambiente, é complexo adotar metodos ágeis e suas técnicas e práticas.

Agora imaginem somar a esta complexidade, um projeto legado que precisa ser mantido e evoluído, em paralelo com outro projeto que está sendo concebido. Consegum imaginar este cenário ? Um único líder e uma única equipe, para lidar com os dois projetos.
O projeto A que já está no mercado em dezenas de clientes, com uma certa demanda de manutenção e evolução, e o projeto B, que está sendo construído em paralelo e conta com um cliente interno. Além disso, o projeto A é em Delphi voltado para Win32 e o projeto B é em .NET voltado para WEB.

Bom, até um tempo atras eu imaginava que isso era possível, talvez por otimismo, talvez pela motivação do desafio, ou por qualquer outro motivo, eu acreditava que era possível no meu cenário(talvez em outros cenários seja mais viável), vi que estava equivocado e diante disso, compartilho com vocês algumas dificuldades que encontrei:

• Manutenção, ainda mais de projetos legados, são complicadas, muitas vezes imprevisíveis. Além disso, a correção de erros precisa ser priorizada, dessa forma os SLA's de manutenção acabam interferindo no desenvolvimento das stórias do sprint.
• A mudança de foco entre problema, tecnologia, cenário, plataforma do projeto A e do B, afetavam a produtividade e o crescimento da equipe. Ao invés de termos uma equipe com aquela tradicional curva de aumento de produtividade ao longo dos ciclos, tinhamos uma equipe com pouco ganho de produtividade, pois ela acabava não se dedicando inteiramente a um único projeto.
• A gestão de tarefas fica mais complicada, pois temos que misturar tarefas de dois projetos diferentes, com prioridades e complexidades diferentes, com processos e equipes de homologação diferentes.
  
• Algumas demandas de customização, prendiam membros da equipe por dias, atrapalhando a evolução do ciclo.

Motivado pelo desafio, buscamos customizações no processo e no ambiente, de forma a suportar este cenário. Eu admito que o resultado não foi ruim, mas estava distante do ideal. O Projeto A estava controlado com as customizações e correções sendo atendidas no prazo. Por outro lado o Projeto B estava se movimentando a 30km/h, mas o product owner precisava que este projeto se movimentasse a 100km/h.

Diante disso, em uma reunião com o Product Owner, foi decidido pelo caminho talvez mais óbvio: A divisão da equipe. Definimos um período de transição, e uma data de corte, quando a equipe do projeto B seria desligada do projeto A. Fiquei como ScrumMaster do projeto B, sem ter que me preocupar mais com o legado e as manutenções do projeto A. Ou seja, a partir de agora, eu e a equipe poderiamos ter Foco.

Escolhi os membros que melhor se enquadravam e fizemos a migração.

Desde então retomamos de forma mais consistente a adoção de Agile e o projeto está começando a ganhar mais volume e força.

Nos próximos posts comentarei mais sobre essa nossa nova experiência, falando sobre as práticas que estamos utilizando, os padrões que estamos seguindo, as dificuldades que estamos encontrando, enfim, sobre nossa experiência Agile.

Por hora é isso, desculpem-me pelo afastamento, e espero nos próximos dias, semanas, meses, anos, compartilhar muitas experiências de adoção de métodos ágeis com vocês.

Abraço.

Voltando ao batende... De novo... rs

Olá pessoal, aqui estou eu, novamente, mais uma vez, de novo (a redundancia é proposital)rsrs...

Pois bem, mais um mês se passou, com ele mais uma turbulência, mas agora estou conseguindo me reorganizar e certamente conseguirei voltar a postar mais aqui no blog.

Antes de mais nada, gostaria de atualizar vocês com o status de nossa experiência Agile.

Vamos lá, vocês já devem estar imaginando né, se teve turbulência então o processo de implantação de Agile ou melhor, implantação/evangelização(esse tema merece um post dedicado rs), parou.

Pois acertaram em parte. Como muita coisa aconteceu, problemas, novas demandas e mudanças estruturais na empresa, acabou ficando quase que impossível manter o processo de adoção do Agile.

Não cabe aqui entrarmos no mérito do detalhe do que ocorreu, vale ressaltar apenas que, de fato, durante uma mudança de conceito, metodologia, pensamento etc... uma turbulência é tudo o que não precisamos e foi exatamente o que aconteceu.

Por outro lado, apesar de ter estado no meio da turbulência, nunca tirei da cabeça a certeza de que Agile é o caminho. O que quero dizer com isso é que apesar de estar o tempo todo ocupado com a turbulência, em todos os momentos não tirei da cabela onde queriamos chegar e o que precisariamos fazer para isso, ou seja, todos aqueles erros que cometemos e que já postei aqui no blog, ainda estão aqui, dentro de mim e é deles que partirei para a retomada.

Já de imediato, para a próxima semana, teremos as seguintes medidas para marcar nossa retomada:
- Reafirmar os valores e principios do Agile
- Fazer uma retrospectiva de retomada
- Retomar as reuniões do Scrum
- Iniciar o treinamento da equipe(Falarei especificamente sobre o que será aborado em um outro post)

Para a próxima semana a meta é esta, também não adianta sonharmos em mudar tudo do dia para a noite pois já vimos que isso não dá certo.

É isso pessoal, fico feliz por estar de volta e espero que nossa experiência possa agregar algo a vocês que nos acompanham.


Grande abraço.
Ricardo Coelho.

Voltando ao batente...

Olá pessoal... há mais de um mês que não posto nada. Pois é, o mês de Julho foi péssimo, me envolvi em um projeto externo, crítico para a empresa, agora as coisas estão estabilizando e estarei voltando a postar com mais frequencia.

Pois bem, o mês de junho foi muito bom com o inicio da adoção oficial de praticas ágeis e do Scrum, com o cumprimento de todas as metas.

È senhores, já o mês de Julho foi o caos e eu tenho que admitir para vocês que não foi fácil.

Houve falha de comunicação na equipe em um determinado momento, ocacionando na sobreposição de uma base de testes do desenvolvimento.

Os valores do Agile ainda não foram completamente absorvidos.

Implantar Agile, ou melhor PENSAR Agile, VIVER Agile, SER Agile não é tão simples quanto muitas vezes parece.

Eu posso resumir Julho em uma frase: Não fomos Àgeis. Nem na postura, nem no pensamento, tampouco no comportamento. E isso é péssimo, é realmente frustrante. Mas.....

..... A boa notícia é que como bom Brasileiro e bom Potencial Agilista eu não desisto, ou melhor nós não desistimos.

Na ultima segunda-feira, fizemos uma retrospectiva e levantamos muitos problemas, a grosso modo chegamos aos seguintes problemas e soluções:

1 - Problema: Indisponibilidade do P.O

Solução: O P.O deverá eleger um Sub P.O, alguém que na ausencia dele possa aprovar os sprints e priorizar o backlog.

2 - Problema: Nao realização das reuniões diárias

Solução: Colocamos no servidor, agendado para as 17:45 um script para enviar uma mensagem para a maquina de todos os desenvolvedores lembrando da Daily Meeting.

3 - Problema: Não absorção dos valores do Agile

Solução: Fixar na parede e próximo ao Kanban os valores e principios do Agile e toda vez que pegarmos um ao outro violando o principio deveremos apontar para o mesmo, indicando que estamos indo contra o que pregamos.

4 - Problema: Kanban não muito claro

Solução: Divisão do kanban em outros quadros, agora teremos dois quadros para o kanban, um quadro terá dois projetos novos e o outro terá as atividades do produto atual em manutenção, separando o que é correção de bugs e o que é customização. Além disso teremos um terceiro quadro onde iremos colocar o BurnDown de cada projeto.

Em resumo é isso pessoal. Tivemos até mais falhas do que as descritas àcima, mas sinceramente são 01:09 da manhã e meus neurônios já não estão fazendo muitas Sinapses, não to me recordando dos outros itens rsrsrs

É isso, Julho foi complicadíssimo mas não desistimos, nem desistiremos, seguimos firmes e fortes nessa batalha.

Em breve trarei mais novidades, como a nova organização do Kanban, novidades no planning poker, dentre outras.

Agora tudo o que mais preciso é durmir rsrs

Um grande abraço a todos e uma ótima noite.
Ricardo Coelho.

Planning Poker

Olá pessoal, faz um tempinho que não posto mas é porque as coisas estão muito corridas, estou preparando um treinamento para a equipe, para dar uma nivelada no conhecimento e para nos prepararmos para implantar algumas práticas do XP. Quando tiver mais detalhes do treinamento posto aqui, hoje vou falar sobre o planning poker que realizamos na última planning.

Tivemos que improvisar um baralho de papel para um membro da equipe rsrs mas estaremos providenciando um baralho mais decente para os próximos plannings. rsrs

O importante é a técnica e os benefícios da mesma. =)

Foi nosso primeiro planning poker, foi bem interessante pois podemos perceber os beneficios desta técnica. Em algumas tarefas as diferenças foram consideráveis, chegando a variar e 5 a 13 horas, em outras parecia que tinhamos combinado, o que segnifica que a equipe possui um certo alinhamento. O legal foi perceber que cada um tinha uma visão da tarefa, cada um enxergava problemas e facilidades e o fato de as cartas serem apresentadas juntas, reduziu a zero qualquer possibilidade de influência entre os membros da equipe. Com isso, a cada rodada do poker com uma divergência muito grande, haviam as explicações que serviam para esclarecer a tarefa, expor possiveis obstáculos e facilidades.

Diante disso, posso citar alguns benefícios imediatos que identifiquei na adoção do planning poker:

- Reduçao do fator "influência" na estimativa da equipe
- Melhor esclarecimento das tarefas
- Exposição de possiveis problemas para todos os membros da equipe
- Toda a equipe por dentro das tarefas(desmembradas a partir das estórias)


É isso aí pessoal, vou ficando por aqui.
Um grande abraço.

Primeira Review e Planning

Boa noite galera.

Hoje foi um dia corrido, foi dia de review e planning com o Product Owner.

Desta vez, corrigindo uma falha cometida por mim no planejamento do primeiro sprint, toda a equipe participou das reuniões junto ao P.O.

Aproveitamos o encontro para reforçar os principios do Agile e o papel do P.O, em resumo, explicitamos o seguinte:
- Product Owner
- Nortear o desenvolvimento através da definição e priorização do BackLog.(É a nossa bússola de negócio/valor)
- Validar o resultado da entrega do sprint.
- Estar disponivel para dúvidas sempre que necessário.
- Equipe
- Se comprometer com aquilo que pode cumprir.
- Se dedicar e se auto-organizar para entregar o que foi acordado.
- Buscar melhorar a sí mesma através das reuniões de retrospectiva.
- ScrumMaster
- Antes de mais nada é um membro da equipe e tem as mesmas responsabilidades da mesma.
- Remover impedimentos da equipe.
- Estimular e potencializar o rendimento da equipe

Após este breve reforço dos papéis e mais uma passada nos principios do Agile, que agora guiam o departamento de desenvolvimento, iniciamos a review.

Durante a review apresentamos o acordado para o primeiro sprint, durante a apresentação o P.O fez algumas ressalvas como por exemplo quanto a usabilidade e layout. Em relação a funcionalidades o mesmo ficou satisfeito com a entrega.

O interessante foi que já notamos um grande benefício da adoção de Agile. O Feedback precoce. Já discutimos mudanças na interface visando melhorar a usabilidade evitando que construissemos novas telas seguindo um padrão não tão produtivo para o usuário.

Após a review já geramos um insumo para o próximo sprint, que seriam os ajustes deste primeiro.

Seguimos da review para o planning, onde discutimos a sequencia dos recursos a serem desenvolvidos.

Após discutirmos os recursos desejados e priorizados pelo P.O, fizemos uma lista com o que seria entregue em duas semanas(Definimos que trabalharemos com o sprint de 10 dias pois o de 5 dias ficou muito apertado). Além disso, solicitamos ao mesmo uma definição de PRONTO para o próximo sprint, dessa forma corrigimos mais uma falha do primeiro sprint, quando isso não foi tão bem definido pelo P.O.

Explicamos que era fundamental essa definição para o próximo sprint pois essa definição iria nos guiar como meta e consequentemente determinar o sucesso ou fracasso do sprint.

Em suma a review e o planning foram isto, foi bem interessante pois sentimos que o P.O gostou e que o mesmo viu o desenvolvimento completamente aberto a mudanças, flexível e focado em gerar valor para o negócio. Sem contar que sentimos que estamos dando passos seguros rumo ao sucesso do projeto além de estarmos todos alinhados com o mesmo(P.O - Equipe - ScrumMaster).

A idéia é já colocar o software em produção em um cliente ao final do próximo sprint. Ou seja, ao final de cerca de um mês(Sprint 1 + Sprint 2), pretendemos ter um produto no ar, algo que jamais conseguimos com outras abordagens. As reuniões de hoje só me reforçaram o sentimento e certeza de que Agile é, atualmente, a melhor forma de se desenvolver projetos de software.

Agora fico por aqui pessoal, feliz e ansioso pelos próximos sprints e evoluções :)

Amanhã tem retrospectiva :) e em breve estarei de volta.

Um abraço.
Até mais.