• Como era o método XYZ da classe FooBar na versão 2.0.3.12 do projeto?

• Quais foram as alterações feitas para incluir suporte à NF-e?

• Quando esta linha de código foi adicionada ao método XYZ?

• Consigo compilar e executar o sistema na versão 2.0.2.15 para reproduzir e consertar o bug de um cliente?

Se o seu controle de versão não consegue responder a estas perguntas, então está na hora de rever as práticas do seu time. Uma ferramenta de controle de versão não deve servir somente como um backup do código fonte, onde, ao final do dia, o desenvolvedor deposita seu trabalho inacabado. Ela deve ser um santuário, o repositório sagrado que exige do desenvolvedor todo respeito e cuidado. Afinal, o artefato mais valioso de um projeto, o código fonte, está guardado ali. Portanto, não basta instalar um controle de versão e sair usando. O time deve rever seus conceitos e absorver as mudanças necessárias, que podem ser dolorosas. No entanto, após um tempo, o time começa a colher os frutos do terreno bem preparado.

Há pouco tempo li um artigo muito bom do Eduardo Miranda sobre gerência de versionamento, onde ele cita algumas práticas boas e ruins. Vamos a elas:

Boas práticas

1. O código-fonte no servidor deve estar sempre pronto para compilação. Ou seja, a qualquer momento do dia deve ser possível buscar a cópia da última versão disponível do servidor e compilar uma nova versão da aplicação.

2. Toda changelist (conjunto de alterações que foram submetidas juntas) submetida visa melhorar o produto, nunca piorar. O código fonte é sagrado e deve ser total e completamente respeitado. Uma changelist corrige um defeito, adiciona uma funcionalidade, refatora um trecho de código. O desenvolvedor não pode submeter changelists que quebrem o build, seja pela adição de erros de compilação ou pela quebra dos testes automatizados. O time com o qual trabalho tem uma prática problemática que é fazer chekins parciais de código para compartilhar com outro desenvolvedor as alterações feitas. Não tem problema, desde que feito em um ramo de versão temporário especialmente criado para isso (também conhecido como branch). Assim, o ramo principal (o chamado trunk) não fica ‘contaminado’ com códigos incompletos. Somente quando toda codificação estiver terminada e os testes unitários completos, podemos fazer um merge do ramo temporário com o ramo principal. Claro que o trabalho é maior devido ao merge, mas a maioria das atuais ferramentas de CVS oferecem um bom suporte para isso.

3. Submeta suas alterações o mais rápido possível e com freqüência. Quanto mais tempo um arquivo fica em alteração mais difícil se torna seu merge e mais aumenta o risco de quebra do build. Divida suas alterações em pequenos pacotes compiláveis e testáveis e submeta sempre.

4. Oh-oh! Atenção, build quebrado! Se o build está quebrado não submeta alterações nem sincronize sua cópia de trabalho. Um build break é um estado que deve ser tratado com a máxima prioridade. Neste estado não é possível garantir que a sua alteração compila e não quebra testes, portanto não é possível garantir sua qualidade. Por outro lado, sincronizar sua cópia de trabalho irá corrompê-la, o que te impedirá de compilar e testar as funções localmente.

5. Controle tudo que é necessário para compilar e instalar a aplicação. Código-fonte não é a única matéria prima para compilação e instalação dos aplicativos. Sua aplicação pode depender de bibliotecas de terceiros. Neste caso, é necessário armazenar no repositório uma cópia do binário na versão utilizada pela aplicação. Em caso de atualização, a nova versão deve ser submetida junto com toda a alteração no código-fonte da sua aplicação necessária para suportar a versão.

6. Estabeleça critérios de qualidade. Código sem erros de compilação é o mínimo aceitável. A partir do momento que o objetivo passa a ser melhorar a aplicação, novos parâmetros de qualidade devem ser adotados para aprovação de um check in: código sem warnings e hints, testes unitários executados, métricas de complexidade mantidas, etc.

Práticas ruins

Qualquer prática que vá de encontro ao objetivo de ter no repositório uma versão compilável, testada e sempre melhor da aplicação, é uma prática ruim e deve ser evitada. Mas algumas são típicas e merecem destaque:

• Não submeta alterações em cima da hora. Sexta-feira, 18h, você louco para ir embora e não estará no sábado de amanhã de prontidão para resolver algum problema.

• Não segure as alterações em sua cópia de trabalho por muito tempo. Código-fonte fora de repositório estraga como comida fora da geladeira. Tentar submeter uma alteração feita há 2 meses no repositório gera um trabalho enorme e um elevado risco de quebra de build.

• Nunca ignore a política de check in. Mesmo alterações simples podem quebrar um build.

Finalizando

O controle de versão é provavelmente a ferramenta mais útil e fundamental no desenvolvimento de software e uma das mais utilizadas no dia-a-dia do desenvolvedor. É necessário sempre se preocupar com a facilidade de uso, para que ela não atrapalhe a produtividade nem caia em desuso, sem, contudo, abrir mão dos seus objetivos primordiais.

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 (21)

1. Nossa maior prioridade é satisfazer o cliente através de entregas rápidas e contínuas de software funcional.
2. Abrace as mudanças de requisitos do projeto, mesmo que ocorram tardiamente. Os processos ágeis apóiam a mudança como uma vantagem competitiva para o cliente.
3. Entregue software funcionando com uma freqüência de duas semanas a dois meses, escolhendo sempre a menor escala de tempo possível.
4. O pessoal de negócio e os desenvolvedores devem trabalhar juntos no projeto diariamente.
5. Construa os projetos com pessoas motivadas. Forneça o ambiente, os equipamentos e as ferramentas de que elas precisam e confie que elas farão o trabalho.
6. Uma conversa cara a cara é a melhor forma de transmitir e receber informação do time de desenvolvimento.
7. Software funcionando é a principal medida de progresso.
8. Processos ágeis promovem um desenvolvimento sustentado. Gerência, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.
9. A atenção contínua à excelência técnica e a um bom design aumentam a agilidade.
10. Simplicidade – a arte de maximizar a quantidade de trabalho desnecessária – é essencial.
11. As melhores arquiteturas, designs e requisitos surgem de times auto-gerenciados.
12. A intervalos regulares, o time reflete sobre como se tornar mais eficaz, e então ajusta seu comportamento de acordo com as reflexões.

Pare por um momento e reflita sobre os princípios acima. Serão tão radicais e impossíveis como algumas pessoas acham ou simplesmente seguem o bom senso? Será tão difícil fazer os projetos funcionarem desta forma? Você realmente acredita que seu cliente prefere uma ótima e farta documentação a um sistema funcionando em um curto prazo? Ou que um e-mail substitua um bom bate-papo? E que tal fazer somente o necessário, sem ficar ‘viajando na maionese’?

Estes princípios formam um senso comum e prático, sobre o qual podemos alicerçar nossos esforços para a construção de um software de sucesso.

(Referência: Agile Modelling – Scott Ambler)

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

É uma historinha bem humorada do dia a dia de negociações com nossos Product Owners. O André fez uma tradução livre para o português. O post original pode ser visto em One Day in Kanban Land.

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.

No entanto, a dificuldade em planejar não é desculpa para não fazê-lo. O planejamento reduz o risco, diminui a incerteza, ajuda na tomada de decisões, estabelece uma maior confiança e dissemina informações. Infelizmente, o planejamento tradicional não vem funcionando. Ao tentar combinar e responder às necessidades do trio escopo\cronograma\recursos, o planejamento tradicional não nos leva a respostas e produtos satisfatórios.

E por que o planejamento tradicional não funciona? Mike Cohn, em seu livro Agile Estimating and Planning, elenca 5 causas para as falhas de planejamento.

1. O planejamento é baseado nas tarefas necessárias e não nos recursos desejados.
   É vital o time manter o foco nos requisitos solicitados; são eles que agregam valor para o cliente (veja “Você entrega algo de valor para seu cliente?”). Tarefas por si só não agregam valor algum. Além disso, os planejamentos tradicionais, por basearem-se em tarefas, preocupam-se com a dependência entre elas. Assim, atrasos em qualquer tarefa acumulam-se no final do cronograma, pois são repassados pela cadeia de dependência.
2. Executar tarefas simultaneamente agora acaba gerando atrasos no futuro.
   Com a melhor das intenções, o time pode ver a multitarefa como uma possível solução para atrasos. No entanto, ao trabalhar em duas tarefas ao mesmo tempo, um membro do time provavelmente prorrogará o término das duas. Como outras tarefas dependem das primeiras (lembra do item anterior?), é quase certo que um atraso será embutido na cadeia de dependência, refletindo-se no prazo de entrega final.
3. Não se atende aos requisitos pela prioridade dos mesmos.
   O pensamento tradicional diz que, se todo trabalho é completado, não importa a ordem em que é feito. Nesse caso, é natural que a seqüência e priorização das tarefas siga a conveniência do time de desenvolvimento e não a importância dos requisitos para o cliente. Como conseqüência, é muito provável que no final do projeto, para manter o cronograma, o time acabe descartando requisitos importantes que não foram corretamente priorizados.
4. O planejamento antecipado sempre contém um certo grau de incerteza que é ignorado.
   O planejamento tradicional não considera as incertezas presentes em todo projeto de software. Ele assume que a análise inicial será completa e perfeita e que coletará todos os requisitos do produto. Assume também que os usuários não mudarão de idéia, que nenhuma necessidade nova aparecerá durante a execução do projeto e que sabemos exatamente como os requisitos serão  implementados. É claro que isso não é verdade; tudo o que não sabemos no início do projeto é uma incerteza que deve ser considerada no planejamento, e a melhor forma de lidar com as incertezas é através de iterações curtas com feedbacks rápidos e constantes.
5. Estimativas com alto nível de incertezas e baixa probabilidade de acerto acabam se tornando compromissos.
   Dentro de cada estimativa está embutida uma probabilidade do trabalho ser finalizado no tempo previsto. Uma probabilidade varia de 0 a 100%. Portanto, ao estimar a duração de uma tarefa estamos dizendo que existe uma probabilidade de x % de terminarmos a tarefa em y dias. O problema é que compromissos não podem ser assumidos sobre probabilidades; eles são assumidos sobre uma data.

O planejamento ágil ataca esses problemas focando nos requisitos. A unidade mínima de entrega é um requisito completo; não importa quantas tarefas foram terminadas, se um requisito não está completamente implementado, ele não está entregue. A priorização baseia-se nos requisitos de maior valor para o cliente e não nas tarefas do time de desenvolvimento. O time todo trabalha para entregar um requisito, por isso praticamente não existe multitarefa. O planejamento é incremental; assume-se que no início do projeto sabemos muito pouco sobre o que será feito e sobre como será feito. O time encontrará essas respostas gradativamente, conforme implementa requisito por requisito.

Parece utópico, mas funciona. Qualquer um que desenvolveu software sabe que nunca conseguimos levantar todos os requisitos necessários para um sistema, por maior que seja o esforço. Conheço uma pessoa que trabalha para uma grande empresa indiana que possui a famosa certificação CMM5. Há 2 anos ela realiza levantamento de requisitos para o sistema de um grande banco brasileiro. Dois longos anos de trabalho da equipe; nenhuma linha de código foi escrita, nenhum requisito foi entregue; somente algumas centenas de artefatos obrigatoriamente gerados pela especificação do CMM5. Claro, CMM5 garante qualidade, mesmo que a um custo altíssimo, certo? Mas qual a probabilidade dos requisitos levantados há dois anos ainda serem válidos? Será que ainda representam o que o cliente quer atualmente? Acho pouco provável.

E você, qual sua opinião?

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.

Programar muitas vezes é considerado como sinônimo de codificar, ou seja, escrever código para ser compilado. A importância de um bom algoritmo na qualidade final de um software é indiscutível e não pretendo levantar discussões a este respeito por aqui, mas colocar em pauta outro aspecto – que também é programação – porém nem sempre tem a atenção merecida: a interface gráfica, ou, mais precisamente, a interface de usuário (IU).

Assim como a parte que fica por debaixo dos panos (o código) a interface gráfica tem uma importância fundamental para o sucesso de seu sistema. Padrões de projeto (Design Patterns), Grasp, POO, POA e etc. São inúmeras as técnicas existentes para auxiliar a construção de excelentes softwares. Mas, quantos de vocês conhecem alguma para desenhos de interfaces gráficas? O que deve ter em mente o programador ou projetista de interface para construir uma boa IU?

Imagine a seguinte situação: você acabou de liberar uma nova versão de seu sistema com um novo e badalado recurso de cálculo de preço, baseado em uma intricada fórmula de previsão de custos, cujo código você morre de orgulho de dizer que foi de sua autoria. A janela que implementa este recurso possui alguns campos para digitação dos materiais aos quais o usuário pretende calcular o preço, e, eventualmente atualizar seu cadastro de produtos com os valores obtidos. O que parecia ter tudo pra ser um sucesso não repercutiu como o esperado, e você logo se pergunta: o que pode ter saído errado? O código está perfeito, fiz testes unitários e utilizeis todos os padrões GoF aplicáveis, entretanto, um recurso que teria tudo pra ser um sucesso não está sendo utilizado como o esperado.

Voltando a atenção à interface do usuário, constatamos que ela possui uma grave falha: o sistema possui um cadastro de produtos extenso, e a nova tela não permite que o usuário faça uma seleção para importar os produtos pelo grupo, por intervalo de código, por classificação ABC ou por algum outro critério. O usuário, frustrado por não conseguir digitar os produtos com facilidade, acaba evitando utilizar o novo recurso. Se uma análise de usabilidade fosse feita ANTES de o recurso ser liberado ao mundo externo, o resultado seria diferente.

A palavra chave, quando falamos em IU, é USABILIDADE. Interfaces gráficas foram feitas para – além de serem bonitinhas – facilitarem o trabalho de quem as utiliza. Beleza sem usabilidade é a mesma coisa que uma Ferrari sem volante. É linda, porém não vai servir para o propósito ao qual foi feita.

A tarefa do projetista de IU não é fácil. Cometemos vários equívocos ao desenhar uma nova janela ou página apenas porque não pensamos como um usuário. E não é pra menos: nós não somos usuários. Se colocar no lugar do usuário é uma tarefa difícil e é o segredo para o sucesso de qualquer IU. Com qual freqüência o recurso será utilizado? É crítico? Velocidade faz diferença? É acessível via teclado ou exige o uso do mouse?

Chega de perguntas. O objetivo é apenas um:

Uma boa IU é aquela que se comporta da forma como o usuário espera que ela se comporte.

Simples, direto, claro. Se você coloca um botão lindo com ícones em 3D, mas não deixa claro para o que ele serve, não está construindo uma interface boa para o usuário. Coloque legendas claras e, se possível, hints explicativos e teclas de atalho explicitas, pois nem todo mundo gosta ou pode ficar utilizando mouse (cansa mais que teclado, principalmente em tarefas repetitivas). Se o padrão do sistema operacional é que em caixas de mensagens o botão OK venha antes do Cancelar, siga desta forma. Se tem um recurso não implementado, não coloque o botão na janela apenas para que o usuário tenha que clicar e ver que nada acontece. Recursos incompletos são piores que a ausência total deles.

Outra característica interessante relacionada ao usuário: eles não gostam de ler. Não adianta fazer um manual explicando como utilizar a nova janela, pois eles não o lerão de forma alguma. Da mesma forma, não adianta escrever caixas de diálogos com textos explicativos muito grandes. Eles não lerão e sequer pensarão em clicar em OK ou Cancelar antes de apertar a tecla ENTER do teclado. Textos curtos e claros são ideais. Ao invés de dizer: ‘Você apertou a tecla X, tem certeza que quer executar o procedimento X?’ utilize ‘Executar X?’.

Muitos usuários também são inseguros, portanto, evite questionar as ações dele a menos que seja necessário. Mensagens do tipo: ‘Tem certeza que deseja fazer isto?’ ou ‘Isto vai finalizar o sistema, tem certeza que quer finalizar o sistema?’ tem efeito negativo, pois sugere ao usuário que ele fez algo que não devia. É mais adequado usar: ‘Sair agora?’ ou ‘Fazer X?’.

Usuários gostam de pensar que recursos parecidos devem se comportar da mesma forma. Então, se vai construir uma janela nova, pergunte-se se não existe um padrão a ser seguido. Não inove sem critério, um aplicativo cujas IUs tem aspectos funcionais diferentes umas das outras são difíceis de usar. Se o botão para sair da janela se chama ‘Sair’, utilize sempre assim e não ‘Fechar’, ‘Encerrar’. Se a tecla ESC fecha a tela, procure disponibilizar o mesmo atalho para todas as janelas. A janela de Contas a pagar pode ser redimensionada, então a janela de Contas a receber também o deve.

Tem dúvida sobre qual melhor abordagem para um recurso? Não invente, pergunte ao usuário, faça um teste de interface com ele, observe como ele interage com os botões, menus e mensagens. É a melhor forma de descobrir.

p.s. Acabei de digitar o texto aqui no Word, e tentei selecionar tudo usando a combinação de teclas CTRL+A, que é padrão na maioria dos editores de texto. Não preciso falar que não funcionou, lembrei que no Word é CTRL+T.

Times ágeis estimam pelo tamanho e separam essa estimativa da estimativa de duração. Utilizarei uma metáfora como exemplo para entendermos melhor essa distinção.

Suponha que, em uma bela manhã de domingo, minha esposa me incumba de recolher uma grande pilha de folhas e lixo de um canto do nosso jardim. Após um café da manhã reforçado, posso olhar aquela enorme pilha, analisar e avaliar minhas ferramentas (uma pá e um carrinho de mão) e estimar imediatamente que levarei 5 horas para terminar o trabalho. Para chegar a esse valor, ignorei qualquer estimativa de tamanho e parti diretamente para uma estimativa de duração.

Agora, imagine que eu olhe para a pilha e estime seu tamanho. Baseando-me nas suas dimensões, estimo que a pilha contem cerca de 10 metros cúbicos de sujeira. Essa é minha estimativa do tamanho da tarefa. Mas, nesse caso, somente uma estimativa de tamanho não é lá muito útil. Como no domingo tem um joguinho de futebol, quero saber quanto tempo vou demorar para limpar toda a sujeira. Ou seja, preciso converter minha estimativa de tamanho em uma estimativa de duração.

Uma etiqueta no meu carrinho de mão informa que o mesmo possui uma capacidade de 0,2 metros cúbicos. Dividindo os 10 metros cúbicos de sujeira pela capacidade do carrinho, concluo que precisarei de 50 viagens para dar um fim na bagunça. Ainda estimo que levarei cerca de 3 minutos para carregar o carrinho, mais 2 minutos para movê-lo até a lixeira e outro minuto para retornar com o carrinho vazio. Isso dá um total de 6 minutos por viagem. Como antecipei que precisaria de 50 viagens, chego à uma duração total de 300 minutos, ou 5 horas, para minha tarefa doméstica.

Em ambas as estimativas cheguei a 5 horas de duração. No entanto, a segunda estimativa é mais confiável, pois analisamos uma dimensão absoluta: o tamanho (ou esforço) da tarefa. Na primeira estimativa trabalhamos diretamente com a duração, que é uma dimensão relativa, pois se meu carrinho tiver uma capacidade de carga maior, a duração da tarefa será menor. E se o carrinho possuir uma capacidade menor, a duração da tarefa será maior.

Similarmente, o processo que agilistas utilizam para estimar um projeto de software segue os seguintes passos:

1. Definir as funcionalidades desejadas;
2. Estimar o tamanho das tarefas;
3. Estimar a duração das tarefas;
4. Programar as datas de entrega.

Existem duas medidas de tamanho que podemos utilizar no desenvolvimento de software: pontos de estória (story points) e dia ideal (ideal time). O que são, quais as diferenças entre essas medidas e como podemos utilizá-las será assunto de um próximo tópico.

Enjoy it!