AgileZ

Um código fonte ‘sadio’ é uma das chaves para o sucesso de um projeto, e um CVS (control version system) é uma ferramenta fundamental para manter a saúde do seu código fonte. No entanto, somente uma boa ferramenta não garante um bom controle de versão. Ela deve ser amparada por boas práticas que normatizam sua utilização. Para analisar se você utiliza corretamente seu controle de versão, verifique se pelo menos as seguintes perguntas podem ser rapidamente atendidas:

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

Leia mais…

A fim de ajudar as pessoas a entenderem melhor o desenvolvimento ágil de software, em 2001 os membros da Agile Alliance refinaram o enunciado do Manifesto Ágil, criando doze princípios que as metodologias ágeis devem seguir. Estes princípios são os seguintes:

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)

Como um amigo meu disse certa vez… ‘na internet nada se cria, tudo se copia’. Acabei me rendendo a essa frase, e publicarei uma estorinha já contada em outros blogs. Essa eu peguei do blog do André Dourado (blog muito bom, recomendo). O post original é de Henrik Kniberg, autor do livro ‘Scrum e XP direto das trincheiras’.

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

Estimativa e planejamento são passos críticos para o sucesso de qualquer projeto de desenvolvimento de software. No entanto, planejar é uma atividade difícil e os planos geralmente falham. Estimativas feitas no início de um planejamento ou projeto tem pouquíssima exatidão e a probabilidade de termos uma estimativa correta para um planejamento de 1 ano é muito menor que a probabilidade de acertarmos a estimativa para um planejamento de 2 semanas. Esse refinamento na probabilidade do acerto das estimativas é chamado de cone da incerteza (Boehm, 1981).

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. Leia mais…

Estimativas de tamanho são diferentes das estimativas de duração. Ao estimar a duração tentamos estabeler quanto tempo será necessário para concluir uma tarefa. Mas, ao estimar pelo tamanho, analisamos quanto esforço (ou quanto trabalho) será necessário dispender para executar a tarefa.

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.

Leia mais…

Dual view é a utilização simultânea de 2 monitores no mesmo computador, com a respectiva extensão da área de trabalho disponível. Neste artigo pretendo apresentar argumentos de como uma equipe pode ganhar produtividade utilizando bem não apenas um, mas dois monitores LCD.

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.

Leia mais…

Há alguns meses vi um post muito interessante e criativo sobre a montagem do agile board da BlueSoft. Os curiosos podem acessá-lo aqui. Desde então fiquei tentado a aplicar a idéia na empresa onde trabalho e montar para minha equipe um quadro magnético na parede. No entanto, não é uma solução muito barata, a sala é pequena, e se nossa equipe aumentar teremos que mudar de sala… e lá se vai todo o trabalho de pintura.

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. Leia mais…