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.

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.

O argumento mais óbvio é o ganho de espaço para visualização simultânea de várias janelas, mas somente isso não é suficiente; devemos utilizar esse espaço adicional de forma inteligente. E tudo começa com um conceito que aparentemente não tem relação alguma com monitores: “contexto mental”.

Segundo Andy Hunt, em seu livro “Pragmatic Thinking”, contexto mental é o conjunto de fatos, estados e/ou objetos em que estamos focados em um certo momento. Por exempo, quando participamos de uma reunião, o assunto em pauta, a entonação de voz do interlocutor, sua aparência, a sala, a mesa, a iluminação, até mesmo aquela cadeira desconfortável, tudo se une para formar o contexto. Pense nele como o conjunto de informações para as quais você dedica sua atenção em um certo momento e que estão carregadas na sua memória de curta-duração.

Atenção é a palavra chave. Nossa atenção é muito facilmente dividida, de modo que dificilmente algo recebe nossa total atenção. E, sem total atenção, perdemos o foco, deixando escapar muitos detalhes do contexto. É o que acontece quando recebemos um email ou uma chamada do MSN durante a resolução daquele problema difícil. Nossa atenção é desviada, o foco é perdido e o contexto mental é alterado.

A alteração de contexto mental é um fator crítico para a produtividade. Nós não trocamos de contexto mental com facilidade. Se algo nos interrompe, quebrando nosso fluxo de idéias, é realmente custoso recuperar novamente a linha de pensamento. Estudos indicam que, mesmo sendo a interrupção breve, perdemos de 10 a 20 minutos para restaurar todo o contexto mental anterior. Assim, quanto maior a frequência da troca de contexto mental, menor a produtividade.

Bem, e onde entram os monitores nessa teoria toda?

O dual view, quando bem utilizado, ajuda a manter o contexto mental da tarefa.

Como? Evitando ou minimizando a necessidade de swap de janelas (o famoso CTRL-TAB).

Nossa equipe trabalha diariamente com várias ferramentas ao mesmo tempo; utilizamos uma ferramenta para controle de versão, outra para controle de chamados, Delphi como ferramenta de desenvolvimento, vários plugins e suas respectivas janelas, mais email, navegadores, agenda, etc. Antes, para realizarmos os checkins e checkouts do fonte, tínhamos que alternar o tempo todo entre o controle de versão e o Delphi. Com o dual view, conseguimos manter todas essas ferramentas visíveis simultaneamente. Não perdemos mais o contexto mental da tarefa de programação. Outro exemplo: podemos depurar nosso sistema rodando o Delphi em um monitor e o executável no segundo monitor. Tudo continua dentro do mesmo contexto mental, sem aquelas irritantes trocas de janela entre o depurador e nosso sistema.

A foto abaixo mostra uma parte da sala após instalarmos os monitores. Hoje toda a equipe possui 2 monitores, e já estamos pensando em aumentar para 3.

Assim, pela nossa experiência, o dual view pode, quando bem utilizado, ajudar a melhorar o foco da equipe e, consequentemente, sua produtividade.

E, é claro, existem outras formas de controlar ou minimizar o ‘context switching’.

Como gestor da área de desenvolvimento, recebo muitos emails diariamente. Quase sempre, assim que chegava o aviso de um novo email, eu parava o que estava fazendo para lê-lo (e obviamente mandava pelo ralo todo meu contexto mental). Para contornarmos isso, instalamos um ótimo aplicativo para gerenciamento de desktops virtuais (Dexpot), que nos ajuda a manter contextos mentais muito diferentes totalmente separados. Passamos a trabalhar com 3 desktops virtuais: no primeiro mantemos as ferramentas de desenvolvimento; no segundo, somente email e acesso à internet; e no terceiro assuntos sem importância. É como se trabalhássemos com três pares de monitores. Colocando o aplicativo de email no 2º desktop, conseguimos reduzir muito a troca de contexto, pois não vemos mais o email chegando. A leitura de emails é feita no início do dia, um pouco antes do almoço e no final da tarde, mantendo sob controle a troca dos contextos mentais.

Pense em como você pode controlar seu ‘context switching’. Você vai se surpreender com os resultados.