Há algum tempo, o Mike Cohn (autor de Agile Estimating and Planning e User stories applied) postou na lista Scrum Development do Yahoo! Groups uma mensagem falando que ele estava criando um site com o objetivo de centralizar reviews de ferramentas para métodos ágeis. Ele entrou em contato com diversos fabricantes, para que pudessem listar seus produtos no site, e os usuários poderiam então fazer o review das ferramentas, relatando suas experências e ajudando a comunidade como um todo a separar o joio do trigo.
O site está no ar desde Outubro/2008, e já possui algumas reviews de usuários e uma lista consideravel de ferramentas (mais ou menos 50 ferramentas). Estão lá listadas desde as ferramentas mais conhecidas, a brasileiríssima FireScrum, desenvolvida pelo pessoal do C.E.S.A.R.EDU e algumas ferramentas também que eu jamais havia ouvido falar.
Particularmente não gosto de ferramentas on-line para gerir projetos ágeis – na minha opinião, nenhuma dessas ferramentas chega aos pés do bom e velho taskboard – mas, se for necessário usar uma ferramenta dessas, esse site nos dá uma oportunidade de ouvir a comunidade e utilizar algo de bom. Confiram:
Há algum tempo atrás, em uma das discussões da lista Scrum-Brasil do Yahoo! Groups, escrevi uma mensagem que terminou virando post em um blog. Encontrei o post por acaso, em uma pesquisa pelo Google… e mensagem me chamou atenção, pois é uma das coisas mais difíceis que enfrento no meu dia-a-dia às voltas com desenvolvimento ágil de software: cobrar pelo valor, ao invés de horas. Interessante, hoje mesmo troquei idéias com um dos nossos consultores sobre isso: o mercado de desenvolvimento de software precisa mudar. Nós, desenvolvedores, não podemos cobrar pelo nosso trabalho como um trabalhador manual. Gosto de ilustrar com a seguinte estória:
Era uma vez uma empresa transportadora de cargas. Trabalhava transportando cargas bilionárias, petróleo e toda essa espécie de coisas. A menina dos olhos da empresa era um grande e novíssimo navio, que fora fabricado ao custo de 2 bilhões de dólares.
Um dia de serviço desse navio custava à empresa US$ 100.000 dolares. Após somente 6 meses de serviço, o navio simplesmente parou de funcionar. Foram chamados técnicos e mais engenheiros e mais mecânicos do fabricante, que ao término de 1 mês não conseguiram resolver o problema de jeito nenhum. 30 dias com esse navio parado siginificava um prejuízo de 3 milhões de dólares para a empresa, e seus donos estavam à beira de um colapso nervoso quando foi dada a idéia de chamar um especialista independente, que já tinha enfrentado problemas semelhantes e se saído muito bem, devido à sua experiência imensa com a complexa mecânica naval.
Eis que no dia seguinte, chega o especialista. Senta-se em frente a uma das partes do motor, tenta ligar, pressiona alguns botoes, balança a cabeça, murmura algo para si mesmo… e puxa uma chave de fenda da sua caixa de ferramentas. Desaparece por entre os motores por alguns instantes, e ao retornar diz: “problema resolvido”. Apenas ao toque de um botão, o motor responde e o navio começa a funcionar.
O presidente da empresa ficou impressionado, e perguntou ao especialista quanto ele lhe devia. O especialista respondeu:
– A conta é US$ 1 milhão, por favor.
O presidente da empresa ficou indignado, e falou:
– US$ 1 milhão por apenas alguns minutos de trabalho? Para apertar um parafuso? Eu sei que o meu navio é um navio de 2 bilhões de dólares, mas 1 milhão é absurdo! Pagarei somente se receber demonstrativo com todos os detalhes que justifiquem esse valor!
O especialista simplesmente balançou a cabeça afirmativamente e saiu.
Na manhã seguinte, o presidente recebe o demonstrativo com o detalhamento do serviço. Ao terminar a leitura, não hesitou e mandou que fosse paga no ato.
A nota fiscal dizia:
“Serviços realizados:
Visita técnica – cortesia
Apertar um parafuso – US$ 0,10
Saber qual parafuso apertar – US$ 999.999,90“
Em suma, um problema que era remexido há um mês e sem solução foi resolvido em poucos minutos. Um erro comum é querer fazer comparações entre complexidade x tempo. Isso é errado. Quando estimamos utilizando planning poker, levamos em consideração o tamanho de uma história, relativo à sua complexidade – esqueça as horas. Mesmo. Trabalhamos com processos empíricos, lembram?
E no final, uma estimativa é somente uma estimativa – não é uma previsão, não está gravado em pedra, e não precisam ser certas. A definição da palavra “estimativa” comprova isso, procure no Google. Obviamente, quando atingimos uma certa regularidade e melhoramos nossa exatidão das estimativas, ganhamos mais previsibilidade e temos melhores condições de nos planejar para o futuro. Mas isso é uma coisa que vem naturalmente, assim como a velocidade do time, e não pode ser forçada.
O ingrediente secreto do Scrum
E por falar em coisas que não podem ser forçadas, me lembrei de uma coisa que gosto de evidenciar em minhas conversas sobre Scrum e Agilidade: Em um âmbito mais abrangente, desenvolvimento de software é um processo criativo.
Você não pode forçar pessoas a terem idéias. O que podemos fazer é criar um ambiente propenso à boas idéias – como um terreno fértil. E esse é um dos vários ingredientes “secretos” para o sucesso, coisas que não estão escritas em nenhum manual – e que nenhuma ferramenta vai ajudar você à obter.
Luciano Félix publicou em seu BLOG, Código ágil, a tradução de um excelente artigo sobre programação em par:
O Patrick Kua publicou em seu blog algumas dicas interessantes que ele usa quando está trabalhando em pares. Traduzo aqui o texto para vocês.
Entender o estilo de trabalho de cada um
Gosto de entender como a pessoa com quem estou pareando gosta de trabalhar e eu gosto de explicar a maneira como prefiro trabalhar. Entender as preferências de cada um ajuda a não criar conflitos quando o par precisa fazer algo diferente, Alguns gostam de desenhar diagramas, outros gostam de analisar código, etc. Torne as coisas implícitas em explícitas.
Encontrei esse vídeo, não sei como (acho que foi mencionado em uma das listas que participo), e achei ele interessantíssimo. Ele faz uma comparação entre dois times, um ágil (scrum) e outro Waterfall. Muito bem feito, imagens de primeira, gente bonita e a mensagem é o melhor de tudo. Confiram:
