• 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.

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)

É 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.

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?

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!

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.

Utilizávamos um quadro de feltro verde que não recomendo. Por baixo do feltro o que existe é um papelão fajuto (isso mesmo!) que após alguns furos perde o tônus e não segura mais nada. Por sorte, encontramos uma alternativa bem legal e de baixo custo. São placas de cortiça auto-colante que podem ser fixadas diretamente na parede.

Na foto abaixo mostramos um pacote com 6 placas dessas. Cada pacote custa R$ 26,90 e cobre meio metro quadrado.

A montagem é muito simples; basta remover o plástico protetor e posicionar a placa no local desejado. Deve-se ter cuidado com a colocação da primeira, pois as outras placas serão alinhadas com ela. Se ela estiver torta o quadro ficará fora de prumo.

Após a colocação da primeira placa, continue colando as placas seguintes, montando o resto do quadro.

Após várias colagens, este é o resultado final.

O legal é que podemos aumentar o quadro se necessário. Basta acrescentar mais placas. Além disso, a cortiça não tem o problema do quadro de feltro, pois ela se fecha quando removemos o alfinete.

Para montar este quadro usamos 3 pacotes de placas, com um custo total de R$ 80,70. É uma ótima opção, que recomendo a todos que quiserem montar um agile board. Espero que gostem da idéia.