Fim de ano sempre é sinônimo de reflexão, seja no aspecto pessoal ou profissional. Paramos para refletir sobre o que funcionou e o que não funcionou no ano que termina, fazendo novos planos para o ano que chega. O que podemos melhorar em nossa vida pessoal? E na profissional? Seja qual for sua profissão, uma coisa é sempre certa: seu objetivo é solucionar problemas. O marceneiro resolve o problema da dona de casa ao construir uma nova mesa, o dentista resolve algum problema de carie, o motorista um problema de trânsito e o analista de sistemas um problema de software. Cada um em sua especialidade, sempre procurando a melhor solução.
O famoso físico alemão Albert Einstein dedicou a sua vida a solucionar o maior problema da física até hoje: encontrar uma teoria que explicasse, de forma única, o funcionamento de tudo o que existe no universo. Ele não teve sucesso. Hoje existem algumas teorias que tentam resolver o mesmo problema, entretanto não são soluções simples. Destaquei a palavra simples por um motivo. Einstein acreditava que toda solução deveria ser simples para ser correta. Até os últimos instantes de sua vida ele perseguiu esse ideal. Eu acredito que ele estava certo. Durante o dia nos deparamos com inúmeros desafios, mas será que aplicamos as soluções mais simples? Leia a pequena estória abaixo:

Recentemente recebi um email com um video onde um palestrante contava um caso que ocorreu em uma grande empresa. Era uma fabricante de pastas de dentes, e eles estavam enfrentando alguns processos de clientes que alegavam ter comprado caixas de pastas de dentes vazias. Havia uma falha no processo que fazia com que aleatoriamente algumas caixas não recebessem o tubo de creme dental. Para resolver o problema, os diretores da empresa contrataram uma equipe de engenheiros. Após muitos estudos e testes, os engenheiros criaram um complexo mecanismo composto de uma balança super sensível e um braço mecânico que, ao constatar que a caixa que percorria a esteira estivesse com um peso menor do que o normal, parava a linha de produção e removia a caixa vazia.
O sistema foi colocado em produção e em pouco tempo as reclamações dos clientes pararam. Após alguns meses um dos donos da fábrica foi até a linha de produção averiguar como estavam as coisas, e lá ocorreu o seguinte dialogo com um dos operadores:
- O que vocês acharam do novo sistema?
- Na verdade nós não gostamos muito, porque toda hora a esteira ficava parando pro braço mecânico retirar a caixa. Atrapalhava muito o nosso trabalho e acabamos por deixa-lo desligado – disse o operador.
- Ué, mas ele ficou desligado esse tempo todo? – disse espantado o empresário
- Ficou sim senhor.
- Mas como, se as reclamações dos clientes pararam?
- Na verdade nós resolvemos o problema do nosso jeito. Fizemos uma vaquinha e compramos um ventilador grande pra colocar na altura da esteira. Quando uma caixa vazia passava o vento era mais forte e a jogava pra fora da esteira.
(empresário atônito e mudo)
Quantas vezes não agimos como os caríssimos engenheiros e criamos braços mecânicos para resolver os problemas encontrados diariamente? Será que, como Einstein acreditava, as melhores soluções não são as mais simples? Lembre-se que não basta ter o conhecimento, temos que aplicá-lo com sabedoria, na dose certa. Se para fazer um sistema de venda você teve que aplicar todos os padrões de projeto (design pattern) que conhece, provavelmente não foi a solução mais simples. O algoritmo super complexo que você criou pode ser a prova de erros e resolver todos os problemas que você pensou que fossem ocorrer, em um futuro desconhecido, mas será que foi a melhor escolha agora? Muitas vezes uma solução complexa que resolve todos os problemas de uma vez é mais custosa e trabalhosa de ser mantida do que várias soluções simples, isso porque simples + simples + simples é sempre igual a simples, enquanto o complexo tende a ficar cada vez mais complexo. Em desenvolvimento de software essas situações são freqüentes e pretendo abordar alguns casos em breve. Até lá e um ótimo ano novo.

Antes que você estranhe o título acima, informo que este não será um artigo sobre engenharia civil, e sim de engenharia de software. Aproveitei a relação entre as duas engenharias para fazer uma analogia entre ambas e tentar quebrar um pouco a ‘rigidez’ predominante nos processos de desenvolvimento de software atuais. Falar de modelagem hoje é uma tarefa delicada, pois modelagem é uma das etapas mais importantes e também uma das mais difíceis do ciclo de desenvolvimento de um sistema de informação. Dependendo do modelo de desenvolvimento que sua equipe pratica, a modelagem estará presente em praticamente todas as fases de seus projetos, seja durante o levantamento de requisitos até a entrega. Um trabalho de criação de modelo bem feito é – quase sempre – o detalhe que definirá o sucesso ou fracasso de sua empresa. Até então creio não ter levantado nada de novo. Se você se sente bem com suas ferramentas de modelagem atuais ou é fã de modelos como CMMI ou MPS.br, provavelmente não irá gostar do que vou dizer aqui, porém, se quer continuar a leitura, considere-se advertido de que não costumo respeitar muito a tradição, independente do prestígio gozado por ela.

A engenharia de software, assim como é abordada pela maioria dos cursos de graduação ou pós no Brasil e em boa parte do mundo, define um arsenal de artefatos dos mais diversos tipos (leia-se UML, documento de especificação de requisitos e outros) que devem ser usados como ferramentas para documentação e desenvolvimento da modelagem de um sistema de informação (SI). São eles também os responsáveis por permitirem a separação de papeis entre o analista e o programador. Enquanto um faz a modelagem, o outro ‘apenas’ a executa, convertendo o resultado de um artefato em outro (UML em código fonte, por exemplo). Considerando o que foi dito até agora, fica impossível não fazermos uma analogia com a engenharia civil (finalmente chegamos ao ponto proposto pelo título), onde o arquiteto modela o empreendimento e os construtores/pedreiros executam, convertendo um artefato em outro. Agora, vou abusar um pouco e pedir que use sua imaginação para uma pequena experiência: imagine que, ao invés de modelar usando régua, papel e lápis, os engenheiros civis pudessem modelar usando tijolos, areia, ferro e cimento! Abstraia o fato de isso ser impraticável, e observe apenas os benefícios que resultariam de tal fato se ele fosse possível (financeiramente e fisicamente). Poder ver em tempo real o resultado da modelagem poderia trazer inúmeras vantagens. Testes mais concretos poderiam ser executados. O cliente poderia ter retorno mais rapidamente e com mais frequência. Os problemas de comunicação e entendimento – sempre comuns – durante a fase do levantamento de requisitos seriam detectados bem mais cedo e eventuais alterações no projeto seriam mais fáceis e menos custosas. O quesito ROI (retorno sobre investimento) bateria próximo da casa dos cem por cento.

Se você me acompanhou até aqui, chegou a hora de extrapolarmos o mesmo raciocínio para o que realmente nos interessa: a engenharia de software. Analogamente à engenharia civil, podemos dizer que a planta está para um diagrama de classes assim como o tijolo está para o código fonte. Modelar com tijolos seria como modelar com código fonte. Fazer isso em engenharia civil está descartado por diversos motivos, onde o maior deles é o preço. Fazer e desfazer uma parede ou um cômodo até finalizar o projeto é algo no mínimo insano. Agora eu pergunto: em software, seria da mesma maneira? Não poderia modelar uma classe em C# ou Java, com direito a alterações sem que tal fato implique em um custo acima do aceitável, tendo em vista os benefícios? Arrisco responder que sim: modelar usando código é perfeitamente possível, e, se feito com critério, é mais barato, rápido e muitos benefícios serão colhidos, entre eles:

• Diminuição do hiato existente entre levantamento de requisitos e entrega de resultado significativo (usável);
• Fusão do papel de analista e programador, com aproveitamento maior do potencial dos membros de sua equipe (aprofundarei mais esse item em outro artigo);
• Detecção de falhas de projeto mais cedo e consequentemente com menores custos;
• Código fonte mais legível e autodocumentado (clean code com TDD);
• Maior autonomia para a equipe de desenvolvimento, que, se bem usada, deve render inúmeros benefícios, como o uso de tecnologias mais eficientes e soluções mais criativas;

Saliento aqui que, ao contrário do que parece, não basta esquecer as ferramentas de modelagens existentes e partir para a anarquia. Modelar com o código requer muita prática e conhecimento de técnicas como o TDD (que falei e voltarei a falar aqui no AgileZ) que suprirão as necessidades que antes eram exclusividade de ferramentas como a UML. Outro ponto que deve ser considerado é a maturidade de sua equipe. Geralmente times formados com ênfase em especialistas (olá CMMI!) com grupos de analistas, dbas, programadores, arquitetos e testadores não são candidatos a esse tipo de abordagem. Equipes agiles (olá scrum!) quase sempre tem mais probabilidade de trabalhar dessa forma com sucesso.

Há uma diferença nem sempre valorizada entre equipes agilistas e as tradicionais, que fazem com que essa primeira se destaque. Entre os motivos pra isso destaco a liberdade de criação proporcionada pelo ambiente ágil relacionada à menor segregação de papeis por pessoas distintas. Mas isso rende assunto para vários outros artigos, que espero aprofundar mais em breve. Até lá.

Se você programa em alguma linguagem de programação orientada a objeto, com certeza conhece os termos “Private”, “protected” e “public” e muito provavelmente sabe para que eles servem. Métodos ou membros públicos são aqueles que podem ser acessados por outras classes, os protegidos apenas pelos descendentes e os privados só possuem visibilidade local, ou seja, dentro da própria classe. Parece simples, porém, é muito comum encontrar programadores que parecem não seguir critério algum ao definir o nível de visibilidade dos membros de suas classes, ou então aplicam alguma metodologia aleatória para este fim. Propriedades que eram protegidas são publicadas durante o desenvolvimento de outras classes clientes, conforme a necessidade. Classes “amigáveis” (class friendly) são criadas para permitir acesso a funções protegidas. Práticas como essas acabam por criar uma arquitetura extremamente confusa, com componentes de difícil entendimento, difíceis de serem testados e expandidos. Qual seria então o melhor critério para evitar esse tipo de problema?

Ao desenhar uma classe devemos ter uma ideia bem clara de qual a responsabilidade dela, caso contrário, coloque em dúvida a necessidade de criá-la. O raciocínio é simples: se não sabemos o que a classe deve fazer, então não precisamos dela. Após a definição clara de qual é a responsabilidade da classe, levando em consideração a coesão e nível de acoplamento desejado, devemos pensar sobre a sua interface. Para entender melhor, basta imaginar como a classe deve ser vista por suas classes clientes, ou seja, as classes ou componentes que irão utilizá-las. Apenas métodos e propriedades que permitam acesso e manipulação de dados relacionados à responsabilidade da classe devem ser públicos. Você deve fazer isso não para impedir que outros acessem dados internos de suas classes, mas, principalmente, para garantir que elas sejam mais legíveis, inteligíveis e fáceis de usar. O ideal é que qualquer programador do mundo possa, apenas lendo os métodos públicos de sua classe, dizer qual a responsabilidade dela, e quais métodos chamar, e como chamá-los para conseguir usufruir de suas funcionalidades. Se você não se preocupar em publicar apenas o que for necessário, sua classe corre o risco de ficar confusa demais e difícil de utilizar.

Uma analogia com o mundo real pode ajudá-lo a entender melhor esse raciocínio: imagine um carro onde, junto com os pedais de freio e embreagem, tivessem outros controles estranhos, como um pedal pra regular o nível do óleo e outro para ativar e controlar a bomba de gasolina. Esse carro faria com que o condutor ficasse bem confuso, e tentasse regular o consumo de gasolina manualmente enquanto dirige (um absurdo, não?).

Voltando ao mundo dos bits, por exemplo, se sua classe possuir uma coleção de itens, seria bom deixar claro se ela é dona deles e apenas ela deve poder removê-los ou incluí-los em seu container. Para isso, não disponibilize em sua interface métodos que dão acesso direto a lista, procurando sempre usar o encapsulamento onde for necessário e disponibilizando um iterador.

Se ela exigir passagem de parâmetros de inicialização, providencie construtores personalizados, onde a classe cliente possa passar os parâmetros necessários. Esse tipo de design facilita a leitura e entendimento de quem a for utilizar.

Tenha sempre esse conceito em mente: as classes clientes visualizam apenas os métodos publicados, e devem – apenas se baseando no que enxergam – entender a responsabilidade e como usar os recursos da classe servidora. Algumas ferramentas muito importantes, como o TDD (desenvolvimento orientado a testes) são extremamente eficazes e – se usadas corretamente – funcionam automaticamente como guias forçando o desenvolvedor a escrever uma interface simples e fácil de usar. Pretendo escrever um artigo sobre esse tema relacionado ao TDD em breve. Até lá.

Com o decorrer dos anos e o surgimento da internet, um novo canal de compartilhamento de informações nasceu. Quanto mais popular e acessível a rede mundial de computadores ficava, mais fácil e palpável o conhecimento se tornava. Enquanto o autodidata de outrora era limitado pelos livros disponíveis – muitas vezes caros e em idioma estrangeiro – o autodidata dos tempos atuais tem a sua disposição bilhões de fontes de conteúdo a um clique do mouse. Começava então uma era onde o conhecimento se tornava comum e, consequentemente, deixava de ser considerado como critério de classificação e diferenciação entre as pessoas.

Se o conhecimento se tornou tão ordinário, qual seria então o novo parâmetro para diferenciação? Inteligência?

Segundo a Wikipédia:

A inteligência pode ser definida como a capacidade mental de raciocinar, planejar, resolver problemas, abstrair ideias, compreender ideias e linguagens e aprender. Embora pessoas leigas geralmente percebam o conceito de inteligência sob um escopo muito maior, na Psicologia, o estudo da inteligência geralmente entende que este conceito não compreende a criatividade, a personalidade, o caráter ou a sabedoria.

Conhecimento não é nada sem uso. A inteligência é a competência que torna possível colocar o conhecimento em prática. Aplicar o conhecimento da forma como ele foi apresentado implica apenas em replicar um padrão testado e cujos resultados são previsíveis e facilmente copiados. Falando em mercado de trabalho, uma empresa formada por colaboradores que detêm apenas o conhecimento não tem qualidade alguma que a diferencia das demais. Da mesma forma, se possuir apenas conhecimento e inteligência, estará produzindo resultados que podem ser facilmente igualados pelos concorrentes. O que seria necessário então para o profissional contemporâneo se destacar dos demais? A resposta é: criatividade.

Criatividade representa a emergência de algo único e original.
(Anderson, 1965)

A capacidade de, a partir do conhecimento comum, criar alguma solução inovadora é o que diferencia um profissional de outro. Desenvolver produtos que resolvem problemas antigos, mas, de forma criativa, é a chave para o sucesso da empresa moderna. Isso é particularmente verdade para nós que trabalhamos na área de TI, especificamente em engenharia e desenvolvimento de software.

Hoje em dia, aprender a programar é algo quase banal. Uma rápida pesquisa no Google é suficiente para retornar várias centenas de resultados de cursos e livros prometendo ensinar a programar em poucos dias. Com isso, o mercado de trabalho está um pouco saturado de programadores ‘made in Google’ que pouco sabem criar e muito sabem copiar.

A imaginação é mais importante que o conhecimento.
(Albert Einstein)

Empresas diferenciadas são as que conseguem incluir em seu processo de recrutamento uma forma de identificar e diferenciar as pessoas criativas das que apenas detém o conhecimento. Dessa forma, um bom currículo não basta. Ter cursos, graduações, certificações e outros títulos são apenas pré-requisitos, pois o que conta é a forma como o conhecimento será aplicado para criação de produtos e soluções inovadoras que colocarão a empresa em destaque no mercado. Mais que isso, uma empresa de futuro também deve adotar metodologias de trabalhos que incentivem e valorizem os colaboradores mais criativos. Repensar as metodologias que valorizam o especialista e adotar as que incentivam a pluralidade de competências é uma boa forma de libertar o ente criador que há em cada profissional. Mas isso é assunto pra outro artigo. Até lá.

Desenvolvi uma lista com algumas questões que devem ser observadas por todo programador. (lista baseada no artigo de Alberto Gutierrez ).

1. Seja disciplinado:
No nosso dia-a-dia nos deparamos com diversas interrupções e tarefas paralelas. Telefone tocando, email, mensagem instantânea, colega chamando e diversas outras. Ser disciplinado significa estabelecer uma metodologia para que essas interrupções prejudiquem o menos possível o seu desempenho e produtividade. Utilização de técnicas como a técnica do pomodoro, por exemplo, é uma excelente metodologia para manter o foco em uma tarefa por vez.

2. Seu ego não é tudo:
Ser autoconfiante e ter uma boa auto-estima é diferente de ter um grande ego. Programadores precisam ter segurança e domínio do que fazem para serem colaborativos expressando sua opinião, mas, não exagere. Escute o que os seus colegas têm a dizer. Mantenha a mente aberta e analise as opções de todos antes de se apegar a sua solução como se fosse a melhor de todas. Se estiver errado sobre algo, não se envergonhe de dizer “você tem razão” ou “eu estava errado”.

3. Seja um bom comunicador:
Facilidade em falar e desinibição são apenas algumas das habilidades requeridas para uma boa comunicação. Seja conciso ao falar. Evite fugir do assunto e usar termos prolixos sem necessidade. Em uma discussão, procure ouvir e entender a outra parte antes de responder. Ser educado também faz parte de uma boa comunicação. Evite gírias fora de contexto.

4. De novo…o cliente:
Não faça de uma tarefa de codificação a sua diversão acima de tudo. Acredito que muitos programadores devem adorar ficar experimentando e especulando arquiteturas e algoritmos, mas não exagere. A entrega para o cliente nunca deve ser penalizada. Se houve um comprometimento de prazo com o cliente é melhor abrir mão de “seu código-arte” e focar na melhor estratégia que de retorno imediato para o cliente. Resolva o problema primeiro.

5. Não esqueça o que é prioridade:
Sempre existem funcionalidades que são mais importantes que outras, e essa priorização deve ficar clara e ser respeitada. Esse item é um complemento ao anterior. A procura por novas tecnologias, componentes e arquiteturas devem ser feitas com cautela de forma a não prejudicar o que foi priorizado.

6. Existe um mundo além do código:
Codificar é apenas umas das competências que um programador deve ter. Existe um mundo lá fora. Autogerenciamento, atenção aos prazos e metas, colaboração com a equipe, atenção aos horários, manutenção de um bom ambiente de trabalho evitando que o mau humor e o pessimismo contaminem os demais membros da equipe são apenas algumas das coisas que o programador deve ter em mente.

1. Focar no cliente
O cliente é a razão de tudo. Sem ele não existiria o seu departamento, e, provavelmente, a sua empresa. Por isso, tenha em mente que você deve satisfazer o cliente, entregando coisas que agregam valor para ele. Focar no cliente também inclui abrir a mão de algumas coisas para entregar o que ele precisa. Por exemplo: se aquela refatoração vai atrasar a entrega de uma funcionalidade exigida pelo cliente, abra mão dela por enquanto (faça-a em outro momento mais oportuno).

2. Zele pela qualidade de seu código
Se preocupe primeiramente em manter um código simples, legível e eficiente. Não caia na tentação de desenvolver complexos frameworks ou bibliotecas para algo que só vai ser utilizado uma vez ou que não vai agregar valor para o cliente. Códigos complexos são mais difíceis de manter, e exige mais conhecimento e capacidade de sua equipe.

3. Invista em sua equipe
Desenvolvimento não existe sem pessoas. Por isso certifique-se de que sua equipe esteja capacitada para assumir os desafios do dia-a-dia. Tecnologias aparecem e somem de uma hora para outra, e é difícil, porém indispensável, que todos na equipe sejam bem atualizados. Estimule a pro atividade, a criatividade e a tomada de decisões. Não desencoraje opiniões divergentes, mas modere as discussões com sensatez.

4. Entregue algo com freqüência
Não demore a mostrar resultados. Se o cliente não recebe o que precisa, mesmo que de forma parcial, ele terá a impressão de que sua equipe não está produzindo. Por isso, adote o desenvolvimento iterativo. Se sua equipe utiliza scrum, deixe bem definido o tamanho de suas iterações (sprint) e certifique-se de que algo de valor seja entregue ao final delas.

5. Testes automatizados
Não existe outra maneira de garantir a integridade de um sistema sem teste. Por isso, se sua equipe não desenvolve testes unitários, não há como garantir que o código está integro, e, consequentemente, haverá retrabalho. Retrabalho é mais custoso do que manter um conjunto de testes unitário.

6. Refatoração não é só para código legado
Depois de muitos anos de experiência com desenvolvimento, aprendi que não importa o quanto você pensa, analisa e detalha a solução de um problema antes de codificar. O seu código NUNCA vai estar perfeito. E, por incrível que pareça, a qualidade não está diretamente relacionada ao tempo gasto para analisar e modelar a solução. Por isso procure não perder muito tempo e mantenha o código simples e legível. Faça refatorações sempre que necessário.

7. Comunicação é tudo
Se a comunicação entre os membros da equipe não for boa, coisas erradas poderão acontecer. Não deixe de notar quando esse problema ocorrer. Se alguém diz ‘faça x’ e outra pessoa executa ‘y’, provavelmente houve um mal entendido. Certifique-se de usar palavras adequadas para se comunicar, e confirme que todos entenderam. Se for necessário, peça para anotarem e repetirem o que deve ser feito para evitar perda de tempo e retrabalho posterior. Não aceite informações implícitas. Explicite tudo o que for importante antes que seja tarde demais.

8. Evite desperdícios
Se sua equipe passa muito tempo em reuniões ou em tarefas secundárias, tenha certeza de que elas são realmente necessárias. Se não puder abrir mão das reuniões, adote medida para aperfeiçoar o tempo gasto. Antes de cada reunião defina claramente o objetivo para todos os participantes, e, principalmente, quanto tempo há disponível para alcançar esse valor. Não faça reunião sem uma meta, e muito menos sem uma hora de término definida.

Você se considera uma pessoa produtiva no trabalho ou em sua vida pessoal? Quanto tempo consegue se concentrar em uma determinada tarefa antes de ser interrompido ou mudar o foco? A produtividade de uma pessoa está diretamente ligada a capacidade que ela tem de manter o foco. Quanto mais focada for, melhor e mais rápida vai atingir o objetivo, seja no campo profissional ou pessoal.

Porém, nem sempre ‘mais’ significa ‘melhor’. O cérebro humano tem um limite, e não consegue produzir com qualidade satisfatória após um determinado tempo de esforço contínuo. Cada pessoa tem um ritmo e os intervalos regulares são necessários, seja pra ver emails, conversar, fazer uma ligação ou tomar um café.

Foi um italiano, Francesco Cirillo, que, em meados de 1980, criou uma técnica chamada Pomodoro, inicialmente como forma de desafio aos colegas de faculdade: “Você pode estudar – verdadeiramente – por 10 minutos?”. O nome diferente veio da forma usada para medir o tempo: um timer de cozinha que tinha o formato de um pomodoro (um tipo de tomate em italiano).

A técnica foi evoluindo, e hoje ficou assim:

• Só se trabalha em uma tarefa por vez, e por 25 minutos (um pomodoro);
• A cada pomodoro, descansa-se de 3 a 5 minutos;
• A cada 4 pomodoros, o descanso é maior, 15 minutos (o tamanho pode variar e chegar até 30 minutos);
• Se por algum motivo o pomodoro for interrompido, a contagem deve ser reiniciada;
• Procure pensar em pomodoros ao invés de horas (‘vou levar 4 pomodoros pra concluir esta tarefa x’).

Com o objetivo de controlar seus pomodoros enquanto trabalha no computador, foi criado o Agile Focus, um aplicativo windows escrito em C#, que pode ser configurado para funcionar de acordo com o seu ritmo, e, a cada fim de pomodoro ou intervalo, pode mostrar um aviso na tela, tocar um som no formato wav, ou mostrar um aviso (balloon hint) ao lado do relógio. É possível também configurar até quatro paradas agendadas, como almoço, janta, café e etc.

Estou disponibilizando para download gratuíto a primeira versão. Gostaria que contribuissem com sugestões e problemas encontrados.

Requer o Microsoft.net Framework 3.5 para funcionar.

Baixe agora o Agile Focus – Agile Focus (264)

Quem trabalha com desenvolvimento de software sabe que um dos nossos maiores desafios é conseguir mensurar o tamanho de cada tarefa com uma boa precisão, e, conseqüentemente, conseguir prever quando determinado recurso deverá ser concluído. A forma como fazemos nossas estimativas tem um grande impacto na confiabilidade de nossos prazos, porém, nem sempre as equipes tomam consciência desse fato, e continuam dando pouco valor ou dedicando menos esforço do que deveriam a essa atividade.

Seja qual for a metodologia de trabalho que sua equipe utiliza (scrum + XP ou outra mais tradicional) você pode utilizar diversas técnicas de estimativas. Neste artigo vou apresentar a que é mais utilizada por equipes que empregam metodologias ágeis: o Planning Poker.

Antes de começar, devo introduzir um conceito que pode não ser conhecido ou aceito por todos: uma estimativa é da equipe e não de um programador ou analista em específico, ou seja, o ato de estimar é uma atividade de TODA a equipe, e esse detalhe é primordial para o sucesso do Planning Poker. Com isso em mente, vamos à definição:

O Planning Poker é uma técnica de estimativa baseada no consenso de toda a equipe, onde é utilizado um conjunto de cartas com valores específicos que podem representar pontos relativos ou até mesmo horas (esses valores podem seguir a seqüência de fibonacci) e é praticado como se fosse um jogo. Uma pessoa apresenta a tarefa ou estória para o time, e, após uma breve discussão, cada um escolhe uma carta e coloca virada para baixo sobre uma mesa. Quando todas as cartas estiverem lançadas, elas são viradas e caso não haja consenso nos valores escolhidos, as diferenças são discutidas de forma breve, e uma nova rodada acontece até que haja a convergência.

Vale notar que eu enfatizei que as discussões devem ser breves. Esse ponto é muito importante, pois tem o objetivo de evitar longas argumentações técnicas, que não devem de forma alguma ser o foco de uma estimativa.
Exemplo: quatro membros da equipe jogaram o valor 3 para uma determinada tarefa, e um quinto jogou o valor 8. Houve uma diferença muito grande, e por isso o quinto jogador deve argumentar brevemente porque entendeu que a tarefa demanda mais esforço. Pode ser porque ele não entendeu bem o que deve ser feito, ou porque tem mais experiência naquele tipo de tarefa e conseguiu prever algumas dificuldades que os demais não conseguiram.

Algumas vantagens do Planning Poker:

· Equipe mais comprometida, pois todos participam;

· Força a equipe a ter um conhecimento de negócio mais homogêneo;

· Aumenta bastante a precisão das estimativas, pois considera a experiência de todos;

· Mais atraente (divertida) que as demais técnicas.

Se seu time está tentando implementar o scrum, algumas considerações:

· Estórias são funcionalidades, na forma como tem valor para o cliente (no scrum, o PO ou Product Owner). Exemplo: Eu como usuário quero poder cadastrar um produto;

· Tarefas são as implementações que devem ser feitas para que a funcionalidade seja entregue. Uma estória pode possuir uma ou mais tarefas;

· Nós só conseguimos estimar com precisão as tarefas pequenas. Se estiver estimando em horas, um valor maior que oito já é considerado um ‘chute’, e geralmente significa que aquela tarefa deve ser particionada em pelo menos duas partes, e reestimada, portanto, é recomendável assumir que cada tarefa deve ser pequena o suficiente para poder ser executada em um dia;

· Nem todas as estórias precisam ser detalhadas durante as estimativas. Se você trabalha com scrum, durante o backlog estimate (reunião, geralmente semanal, onde estimamos apenas as estórias de usuário) todas as estórias são reestimadas, e as estórias grandes são quebradas de acordo com a priorização do Product Owner. Dessa forma, as estórias com prioridade mais baixas podem ser estimadas com valores mais altos, e seu detalhamento pode ser postergado para quando se tornarem mais próximas de serem selecionadas para o sprint;

· Estimativas por horas devem ser feitas sem considerar as interrupções, ou seja, o tempo que efetivamente levaríamos para concluir a tarefa em um dia ideal;

· Estimativas por pontos é uma técnica muito boa para se estimar as estórias de usuário e não as tarefas, que usamos estimativas por horas em dias ideais (veja mais sobre estimativas por pontos aqui).

Existe um site bem interessante onde é possível jogar online o Planning Poker com sua equipe: planningpoker.com. Mas note que o poker real, com cartas de papel, é mais recomendável e geralmente mais ágil. Existem vários sites que fornecem as cartas para impressão, como: sprintplanning.com (para mais, deem uma olhada nas referências da Wikipedia).

Aqui tem uma explicação bem legal sobre como funciona a dinâmica do jogo: www.crisp.se/planningpoker

Se você e sua equipe são adeptos do scrum ou outra metodologia ágil provavelmente devem conhecer ou utilizar testes unitários, mas não necessariamente o desenvolvimento orientado a testes (TDD). O teste unitário consiste basicamente em validar dados válidos e inválidos via entrada e saída, já o TDD utiliza teste unitário como parte de sua metodologia cujo principal objetivo não é testar as unidades (é um dos objetivos, mas não o único).

Em um cenário de desenvolvimento ágil, sem uso de TDD, o programador geralmente não conta com um modelo de classes em forma de diagramas – como outras metodologias pesadas. Por isso é comum a modelagem ser feita apenas mentalmente, em algum outro formato (rascunho em papel de pão?) ou até mesmo diretamente no código. As classes, operações e atributos vão surgindo conforme a necessidade, e são constantemente alterados e implementados até a conclusão da tarefa associada. Eventualmente, alguns testes de unidade são implementados baseando-se nas classes já prontas.

Este tipo de abordagem implica em alguns problemas, entre eles:

• o programador não tem segurança em saber quando uma implementação acabou;
• o programador não precisa implementar a classe de forma que ela fique desacoplada das demais;
• o programador tende a não desenvolver para a interface e sim para a implementação;
• métodos não coesos (fazem mais ou menos do que deveriam fazer);
• nomes de atributos e operações não representam adequadamente a funcionalidade.

O TDD pretende resolver todas as deficiências citadas acima e várias outras. Mas, o que é o TDD? TDD ou Test Driven Development pode ser considerada uma metodologia de design de software, onde escrevemos primeiro um teste e depois o código necessário para o teste passar. A idéia é que o desenho das classes seja guiado pelos testes. O TDD força o desenvolvedor a pensar primeiro em o que ele precisa, e em como fazer, via teste unitário, para testar se a implementação a ser feita fará o que deve, nada mais e nada menos. Com isso, se ganha em vários aspectos:

• as classes devem ser desacopladas, senão o teste não pode ser executado;
• os métodos são bem coesos, ou seja, fazem somente o necessário para o teste passar;
• o programador sabe exatamente quando concluiu uma implementação, pois o teste passou;
• o programador consegue validar rapidamente uma alteração que pode ter causado um impacto em outras unidades, apenas rodando um conjunto de testes;
• operações e atributos possuem nomes claros e representam exatamente o que fazem.

O workflow do TDD pode ser descrito basicamente em cinco passos básicos:

1. Crie a classe de teste e o primeiro teste
   1. Nesse ponto o programador deve pensar em como será a assinatura do método testado. O fato de ter que escrever um teste para o método, faz com que, tanto o nome quanto os parâmetros de entrada e saída sejam bem claros e coesos.
2. Compile o teste
   1. O teste não vai compilar. Neste momento, crie a classe e a declaração do método. Recompile e rode o teste. O teste deve falhar, pois o método testado ainda não está implementado.
3. Implemente o código testado de modo que o teste falhe
   1. O objetivo do teste é detectar defeitos, e essa fase é importante para averiguar se o teste está cumprindo seu papel. Geralmente codificar para que o método testado retorne um valor errado é o suficiente. Rode o teste e veja o teste falhar.
4. Agora corrija o código, de forma que o teste passe
   1. Implemente o suficiente para o teste passar. Você deve garantir que o teste exija o suficiente. Se precisar implementar mais do que o necessário para o teste passar, provavelmente seu teste não está bom o suficiente, ou seu método não está coeso. Neste caso, refaça o teste ou corrija a implementação do código testado.
5. Faça alguma refatoração necessária e reexecute os testes
   1. Na fase anterior nos preocupamos apenas em fazer o teste passar. Nessa etapa, faça uma revisão no código e veja se precisa de alguma refatoração. Em seguida rode todos os testes construídos até agora para certificar-se de que a refatoração não quebrou algum outro código.

Antes que me perguntem: TDD não é burocrático e demorado?.  Não. Usar TDD não implica em aumentar o tempo de desenvolvimento. Desconsiderando o tempo de adaptação de sua equipe, a tendência é que o desenvolvimento com TDD aumente consideravelmente a produtividade, e, consequentemente, a segurança e qualidade dos produtos desenvolvidos. Essa é a experiência de quase toda equipe de aderiu ao TDD, e provavelmente sua equipe só vai se sentir confortável com a idéia quando efetivamente aplicar os conceitos da metodologia.

Neste artigo não abordei as ferramentas de teste unitário, pois não é o foco do TDD, porém praticamente todos os ambientes de desenvolvimento moderno possuem algum framework de testes unitários. Posso citar alguns: NUnit (C#), DUnit (Delphi) e JUnit (Java). Escolha o que melhor se adequar a sua realidade.

Quando trabalhamos com equipes mais enxutas, utilizando metodologias ágeis (como o Scrum), temos um considerável poder de decisão e planejamento sobre o que será implementado em cada build. Digo considerável pois existem vários fatores que influenciam o que fará parte do seu sprint (sprint é uma interação que segue o ciclo PDCA e entrega incremento de software pronto), como a priorização do Product Owner (o cliente), tamanho estimado para cada uma das user stories que farão parte da interação, restrições técnicas e outras.

Durante o processo de estimativa, é comum decompormos as user stories em várias tarefas menores, com o objetivo de facilitar a pontuação de cada uma delas. Esse processo é adequado e, se bem feito, aumenta muito a precisão das estimativas, porém, ao quebrar uma solicitação em atividades menores, corremos um sério risco de perdermos de vista o real objetivo de cada uma das tarefas, que é contribuir para a conclusão de um recurso solicitado pelo cliente. Convém não esquecermos que, para o cliente, essas pequenas atividades geralmente não possuem valor por si, a não ser que todas sejam feitas e a feature solicitada seja entregue.

No parágrafo anterior, introduzi dois conceitos chaves para este artigo: o conceito de feature e valor. Uma Feature pode ser definida como um recurso/funcionalidade e geralmente é escrita da seguinte forma: <ação><resultado><objeto>. Por exemplo <emitir><a nota fiscal><de venda> (para mais detalhes, veja FDD – uma metodologia ágil guiada por funcionalidade). Já valor, neste contexto, é toda feature que traga algum benefício para o cliente, ou seja, é seu cliente (no scrum chamado de Product Owner) quem deve valorar o recurso.

Tendo isto em mente, podemos dizer que uma interação deve ter como principal objetivo entregar uma nova versão/build com novas funcionalidades para o cliente. Toda implementação que não contribua para a inclusão das novas features deve ser considerada tempo perdido e ser removida do sprint. Um pouco radical? Vejamos: refactoring, melhorias visuais, troca de tecnologia, otimizações e outras, será que tudo isto pode ser considerado tempo perdido? A resposta é sim e não. Não se a alteração for necessária para dar estrutura ao desenvolvimento de um novo recurso, e sim se for somente para satisfazer o ego do programador. É claro que tudo tem sua exceção, e uma refatoração visual pode, por exemplo, ser uma necessidade de mercado e ser solicitada pelo departamento de marketing, e por esse motivo ser considerada uma feature de valor devido ao seu significado estratégico para o  mercado.

Ao planejar seu sprint focando em funcionalidades, deverá tomar cuidado para que nenhuma funcionalidade seja entregue pela metade. Por isso, verifique a possibilidade com o cliente de desmembrar recursos maiores em partes, e entregue uma parte a cada final de interação, deixando claro que a cada fim de sprint ele deverá ter uma versão do programa funcionando e com um novo valor agregado.

Relatórios como o Parking Lot, que nos dá uma visão de progresso por feature, são indispensáveis para gerenciar o andamento do sprint e antecipar qualquer problema que implique na não entrega de uma funcionalidade completa para o cliente. Veja abaixo um exemplo:

(imagem de: http://www.featuredrivendevelopment.com/node/1038)

Existem vários outros conceitos utilizados neste relatório, como a divisão de funcionalidades por área de negócio, que não irei explicar aqui neste artigo. Para se aprofundar mais sobre o desenvolvimento dirigido à funcionalidade, leia o excelente livro do Alexandre Magno: FDD em uma casca de banana e veja o que se encaixa na realidade de sua equipe.