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.

Um conceito simples, mas nem sempre bem entendido e aplicado. ‘Programar para uma interface e não para uma implementação’, você sabe o que isto significa?

Apesar deste conceito ser aplicável a projetos de software, é mais antigo que ele, e é utilizado bem antes do primeiro compilador ser desenvolvido. Um exemplo bem obvio do que é isto, pode ser encontrado na casa de qualquer pessoa: um interruptor de luz. ‘Como assim José?’.

Um interruptor de luz é um exemplo muito bom. Consiste em um botão, que liga e desliga a luz. Uma interface simples, que esconde os detalhes de implementação de quem vai utilizá-la. Para ligar a luz, basta apertar o botão, e para desligá-la, adivinhem? Aperte novamente. A implementação está bem encapsulada – o usuário não precisa entender nada de pólo positivo, neutro, 127v, amperagem ou resistência. Qual foi o pensamento do designer ao projetar um interruptor de luz? Com certeza foi algo parecido com: ‘qual o mínimo possível de informação o usuário do meu produto precisa para usá-lo?’.

Falando em programação de software, podemos aplicar este conceito a vários pontos. Quando estamos codificando, ao criar uma nova classe, devemos sempre nos fazer a mesma pergunta que o designer do interruptor de luz fez: ‘quais operações e atributos eu devo tornar públicos para que o usuário possa usá-la de forma simples?’ e a cada nova implementação: ‘será que eu preciso expor estes parâmetros? E esse novo atributo?’. Classes com menos operações e atributos públicos, geralmente são mais simples de serem utilizadas. Lembre-se sempre: outros programadores terão que interagir com as classes e bibliotecas que você desenvolveu. Mantenha a simplicidade e procure ser objetivo.

Ao criar uma nova tela de cadastro, analogamente: ‘quais controles o usuário vai precisar para executar as operações a qual a janela se destina?’. Um erro muito comum cometido por projetistas de interfaces gráficas é transmitir a forma de funcionamento interno do algoritmo para o usuário. O clássico exemplo são as telas de cadastro. Todo mundo desenvolve, ou já desenvolveu, uma tela com os famosos botões novo, editar, cancelar, excluir e salvar, pois é a forma como o seu algoritmo funciona, e fica mais fácil publicar essa característica para o usuário. Mas, será que o usuário realmente precisa de um botão ‘editar’ quando ele quer editar um registro? Não seria mais fácil o seu sistema detectar que alguém está tentando alterar um registro e simplesmente entrar em modo de edição, como funciona, por exemplo, um editor de texto? Um botão a menos na tela, na maioria das vezes, pode significar uma interface mais simples – que é o sonho de todo usuário.

Poderia citar dezenas de exemplo aqui, mas a idéia não muda. Um carro com câmbio automático é muito melhor do que um no qual você precisa apertar a embreagem para trocar de marcha. E ambos funcionam, só que o primeiro é mais simples.

É lógico que, ao começar a pensar dessa forma, o programador vai sentir necessidade de amparo por algumas técnicas que ele pode ainda não dominar – técnicas que serão abordadas por aqui – como padrões de projetos ou Grasp. Um caminho que provavelmente não terá volta, e fará de você um melhor projetista de software.