Café com Agile - parte 2

Esta é a segunda de 3 partes do "Café com Agile", para quem não viu a primeira parte, link para a parte 1. Se você ficou com alguma dúvida, ou quiser dar alguma sugestão é só deixar um comentário ou entrar em contato comigo ou com o Sandro. Agora sem mais delongas, a segunda parte do Café com Agile.


Milton: Mudando um pouco o rumo da nossa última conversa, vamos falar um pouquinho de projetos agora. Acho que é melhor você falar um pouco sobre como você aprendeu que os projetos devem ser gerenciados
Sandro: O PMI entende que certas áreas de conhecimento são vitais para que um projeto termine com “sucesso” (a entrega do produto do projeto), no tempo programado, no escopo acordado, no custo estimado, e atingindo as expectativas do cliente (QUALIDADE)
Sandro: São 9 as áreas de conhecimento: escopo / tempo / custo / qualidade / aquisição / comunicação / RH / riscos / integração
Milton: No fim das contas temos a trinca: Custo, Prazo e Qualidade. A idéia é ter um equilíbrio para maximizar estes 3 pontos, certo?
Sandro: Sim, imagine um triangulo: de cada lado dele uma dessas áreas
Sandro: Se você aumentar o prazo, aumentará o custo ou o escopo, é bem interessante essa visão
Milton: E ainda tem o escopo, que influencia estas 3 variáveis, certo?
Sandro: Certo
Milton: Bom, aqui já posso observar uma figura muito forte, que é o Gerente de Projetos
Milton: Ele é o cara que pode, e que deve fazer, decidir, definir, mandar e desmandar tudo relacionado ao gerenciamento do projeto
Sandro: Sim, planejamento, planejamento, planejamento
Sandro: E cada área de conhecimento possui um Plano de Ação
Milton: É o Gerente de Projetos que define o escopo com o cliente, ele vende, ele negocia, ele define cronograma, ele define as tarefas, ele faz as estimativas
Milton: Pelo menos sempre tive essa é a impressão
Milton: E ele faz isso em cada uma das 9 áreas de conhecimento
Sandro: Sim, por isso ele não pode (não deve pelo menos) botar a mão na massa, pois tudo isso gasta MUITO, mas MUITO, tempo.
Sandro: Ele tem, durante o seu dia a dia, de passar por todas essas áreas e ver o que cada uma está dizendo para ele fazer naquele dia/momento.
Sandro: Além disso, cuidar da expectativa, problemas, atrasos, etc.
Sandro: E é claro que, o bom-senso tem que prevalecer. Se tenho um projetinho, vou precisar agir no plano de aquisição / comunicação da mesma forma que um projeto normal? Ele tem que analisar isso e deixar de fora o que não será necessário.
Milton: Entendi. Eu acho que vamos voltar nessa questão do bom-senso depois, por enquanto, eu acho legal a gente voltar a questão do escopo
Milton: Até onde sei, quando se fala em PMI, normalmente é definido todo o escopo do projeto logo na fase inicial, e tudo é desenvolvido com base neste escopo
Milton: Ai, qualquer coisa fora desse escopo irá impactar diretamente no custo e prazo do projeto
Sandro: Sim, mas quando o cliente solicita uma alteração nele, essa solicitação irá para uma Comissão, onde será analisado o impacto sobre o projeto. A partir dela é que definirá se será feito sem cobrar, ou então cobrando e alterando o cronograma, etc. Negociando com o cliente em seguida.
Sandro: E fica tudo registrado, para fins de documentação, nada é boca a boca, mesmo porque é esse registro que circulará dentro da equipe do projeto
Milton: É, acho que agora é hora de começar a comparar as coisas com scrum um pouco
Milton: Talvez a maior diferença entre um projeto "tradicional" e outro que siga a filosofia agile, é a questão do escopo
Milton: Em agile não existe um escopo fortemente detalhado no início do projeto, o escopo é associado a um objetivo do negócio do cliente
Milton: Digamos que o seu cliente é uma panificadora. O escopo desse projeto pode ser definido como "Quero aumentar a minha capacidade de atendimento dos meus clientes, controlando melhor os pedidos e a produção da minha panificadora"
Milton: O escopo morre ai, você não precisa saber detalhadamente que campos existirão no cadastro de clientes, como vai ser o controle de estoque, se precisa implementar TEF nas vendas logo no início do projeto
Milton: Você não precisa disso, porque o software será desenvolvido aos poucos, em ciclos ou iterações, e os requisitos serão levantados conforme forem sendo desenvolvidos
Sandro: Mas e o prazo e custo disso?
Milton: A cada iteração ou ciclo, você desenvolve pequenos incrementos do produto, cada um destes incrementos tem prazo de entrega e custos fixos
Sandro: Definidos no inicio do projeto?
Milton: Sim
Sandro: Não visualizei ainda. Se você acorda com o cliente: serão 300 incrementos. Cada incremento custa $ XX e leva YY dias.
Sandro: Levará então XXXX dias e custara YYY. Entrego em 31/12/2008. Mais ou menos isso?
Milton: Não. Em scrum, assumimos que não há como saber "quantos incrementos" serão necessários, temos apenas uma estimativa inicial que será ajustada continuamente durante o projeto.
Milton: No scrum, essa lista é chamada de Product Backlog. Ela é mantida e priorizada pelo Product Owner(um dos papéis do scrum), que é responsável pelo retorno financeiro do projeto
Sandro: Mas então o cliente não sabe quanto lhe custará e o tempo que levara o projeto, certo? Somente valores estimados, certo?
Milton: Para estimar quantos incrementos serão necessários, você precisa ter uma lista do que tanto o produto final deve ter. Com essa lista em mãos, é possível fazer uma estimativa inicial (junto com a equipe de desenvolvimento) de quantos incrementos serão desenvolvidos até o final do projeto. Normalmente há uma limitação de custo, nesse caso a quantidade de incrementos que serão entregues será limitada e o custo e prazo de entrega do projeto podem aumentar ou diminuir.
Milton: Agora, em valores exatos, não há como saber o custo e prazo do projeto. E se parar pra pensar, mesmo no esquema que você me disse também não há como saber. Você acaba estimando e assumindo um contrato de risco
Milton: Ai, se você terminar antes, você ganha ou o cliente te paga menos, se terminar depois alguém vai ter que assumir o prejuízo
Milton: Como você nunca via querer terminar muito antes do prazo, normalmente o cliente paga o pato, concorda?
Sandro: Claro, sem dúvida, se você estiver terminando o projeto muito antes do prazo e houver outras prioridades, o projeto do cliente será deixado um pouco de lado para maximizar os lucros Sandro: Entendi, o negocio é a negociação, estando tudo transparente no início (e no contrato também) vale o bom-senso e a aceitação da forma como será projetado o produto final
Milton: Exato, a coisa começa ai, toda a forma de se negociar comercialmente já muda

Aguardem, em breve teremos a parte 3.

Link para a Parte 1
Link para a Parte 3

Café com Agile - parte 1

Há algum tempo quero escrever sobre desenvolvimento ágil, que é uma área de desenvolvimento que gosto muito. O único problema é que desenvolvimento ágil é um assunto com muito material na internet. O grande desafio é falar sobre o assunto sem cair no "mais do mesmo", apesar de não ser um especialista no assunto, eu queria criar um material diferente dos diversos artigos, apresentações e palestras que é possível encontrar na internet.

A forma que encontrei para abordar o assunto de forma mais criativa, foi através de uma conversa entre amigos, algo parecido com a série Café com Flex, que o pessoal da d-click fez sobre o Adobe Flex. É ai que surge o meu amigo Sandro, que trabalha comigo na Datasul Saúde e é especialista em Gerência de Projetos. Ele topou a idéia de fazer uma conversa envolvendo Gerência de Projetos nos moldes do PMI e Desenvolvimento Ágil com uma certa ênfase em Scrum. Eu gostei muito do resultado, acho que conseguimos criar um bom material, que vale tanto para quem quer ver alguma coisa sobre gerênca de projetos, como para quem quer conhecer mais sobre desenvolvimento ágil.

Decidimos dividir esse bate papo em 3 partes, para não ficar tão cansativa a leitura, acompanhem os próximos posts, espero que gostem.


Milton: Sandro, antes de começar o nosso bate-papo, gostaria de dizer para os nossos leitores que você é meu amigo de trabalho aqui na Datasul Saúde, atualmente atua como Analista de Suporte, e é especialista em Gerência de Projetos pela FGV, com uma forte ênfase nas práticas de gerenciamento de projetos definidas pelo PMI e mais algumas práticas complementares, estou certo ao afirmar isso?
Sandro: Sim, o curso ministrado pela FGV é diferenciado dos demais cursos voltados somente para a certificação PMP.
Sandro: Nesse MBA vimos outros temas que ajudam as boas praticas do PMI. Temas, inclusive, que a própria FGV aposta que serão incorporados ao PMBOK em futuras publicações, tais como: Marketing, Negociação, Gestão de Mudança Organizacional e Comunicação fora do âmbito do projeto
Sandro: É importante deixar claro que, a parte do MBA, existe a certificação que o PMI oferece, o PMP. Com esta certificação, eu seria um especialista do PMI.
Milton: O PMI é o Project Management Instutite, que é uma organização que tem por objetivo estudar, identificar e disseminar as melhores práticas relacionadas à gerência de projetos, certo?
Sandro: Sim, e também fomenta
Sandro: As suas boas praticas são publicadas, de tempos em tempos, um livro chamado de PMBOK (Project Managemente Body of knowlege)
Milton: Interessante, a idéia desta conversa é justamente poder falar um pouco sobre Gerência de Projetos de forma geral e também um pouco sobre Agile, então só para esclarecer, essa tal "Gerência de Projetos" trata sobre o que exatamente?
Sandro: Boas praticas que podem ser utilizadas em qualquer tipo de projeto
Milton: E estes mesmos conceitos podem ser aplicados na rotina de pessoas que executam o trabalho operacional, no dia-a-dia da empresa?
Sandro: Sim, é possível, por exemplo, a gestão da comunicação sugere a identificação de stakeholders (que são as partes interessadas em um projeto) e quando cada stakeholder tem que receber a informação, em qual mídia, etc.
Parte do que a Gestão de Comunicação aborda e recomenda, eu aplico em meu dia-a-dia, mesmo não estando em uma posição de gerencia.
Milton: Sem se prender a metodologias, podemos dizer que qualquer pessoa, independente de posição em hierarquia poderia utilizar conceitos de gerência de projetos para ajudar no desenvolvimento de suas atividades no dia-a-dia, certo?
Sandro: Sim, pelo menos eu acredito que sim.
Sandro: Um bom exemplo seria o seguinte:
Se uma empresa que está contratando um Gerente de Projetos, descobrir que a sua vida pessoal é desorganizada, sem planejamento, a contratação desse profissional pesara nesse item (em casa de ferreiro o espeto tem que ser de aço), principalmente se os projetos que ele assumir forem de milhões de reais.
Sandro: Forcei um pouco a barra, mas a idéia é de que essas práticas estejam sempre em mente.
Milton: Agora vamos falar um pouco de agile, o q você já viu ou leu sobre agile?
Sandro: Já ouvi alguns podcasts sobre Agile e também de scrum
Sandro: Posso perceber que o mercado está começando a abraçar o SCRUM, ou seja, está começando a aceitá-lo sem torcer o nariz para uma coisa nova que não vem do RUP e outras mais conhecidas
Milton: Só complementando, Agile é algo como uma "filosofia" para gestão de projetos, scrum é uma metodologia que segue os princípios de agile
Sandro: Mas é especificamente voltada para desenvolvimento de software, certo?
Milton: Agile vem do manifesto ágil, que foram alguns princípios definidos por algumas pessoas que desenvolviam software de uma forma pouco convencional para a época
Milton: Estes princípios foram os pontos de convergência que eles encontraram entre cada uma de suas metodologias
Milton: E você está certo sim, de modo geral, todas as metodologias ágeis foram concebidas para tratar projetos de software
Milton: A única exceção, talvez seja o scrum, que é visto como um "framework de gerenciamento", que pode ser aplicado a qualquer tipo de projeto
Sandro: Ou seja, esse pessoal conseguiu formar uma “opinião”, gerando princípios
Sandro: Achei esse lance do Manifesto Ágil um pouco fora do comum, pois não vemos esse tipo de manifesto em outros processos/tendências
Milton: Realmente, normalmente o que acontece é uma coisa mais TOP-DOWN né?
Milton: Exemplo: A IBM contrata um grupo de profissionais muito bons e produz um processo (RUP), e depois vende uma ferramenta baseada neste processo (Rational)
Sandro: Sim
Sandro: Mas existe um instituto que regule essas práticas?
Milton: Bom, preciso deixar uma coisa muito clara, se você entrar no site do manifesto ágil, você vai ver que lá só tem 4 frases, que representam o manifesto. Esses são os princípios seguidos por qualquer metodologia ágil
Milton: As metodologias em si, é outra história. Eu particularmente tenho um conhecimento mais aprofundado em scrum, que é mantido pela agile aliance
Milton: Até onde eu sei, é a única metodologia ágil que possui uma organização por trás, outras bastante difundidas como a extreme programming foram desenvolvidas na prática por um pequeno grupo de pessoas, e depois divulgadas
Milton: Inclusive, a extreme programming foi desenvolvida pelo Kent Beck a partir de um projeto na Chrysler
Sandro: Entendi
Sandro: Clareou agora
Sandro: Existem certificações para estas metedologias ágeis?
Milton: Não são todas as metodologias ágeis que possuem certificações. Até hoje, só vi um processo de certificação em scrum
Milton: Existe uma resistência muito grande na comunidade ágil para certificações. Principalmente pelo fato de que uma certificação simplesmente certifica o conhecimento teórico sobre o assunto
Milton: Há pouquíssimas certificações atualmente que avaliam experiência, capacidade e qualidades humanas, como postura e comportamento
Sandro: Sim, difícil mesmo
Milton: E mesmo a primeira "certificação" do scrum que é a Certified Scrum Master é muito contestada, pois para conseguir esta certificação basta assistir a um curso de 16 horas em dois dias. Claro que o curso é ótimo, mas não certifica nada além de que a pessoa assistiu ao curso
Milton: E mesmo para PMP, a única avaliação é a prova baseada no PMBok, assim como as provas da sun para certificação java, Microsoft, ITIL e tantas outras certificações que existem por ai
Sandro: Concordo, inclusive para o PMP é uma prova de 4 horas incrivelmente decoreba (o processo xyz tem uma entrada/processamento/saída, quais são as entradas e as saídas?)
Milton: Nesse ponto eu até concordo com a comunidade ágil, uma certificação até pode ser um diferencial no mercado, mas na prática é apenas uma prova de que você decorou muita coisa sobre um assunto, só disso

Link para a Parte 2

Link para a Parte 3

Visite Curitiba

Eu estou a um bom tempo sem blogar, mas é por um bom motivo. No último fim de semana, fugi um pouco do trabalho e viajei para Curitiba com a minha esposa. Foi a minha primeira visita a cidade, e gostei muito da experiência. De fato é uma cidade modelo, muito fácil de se localizar, cheia de parques, com muito verde, bem iluminada a noite, com muitas placas indicativas e um trânsito muito fluido, tanto que nem parece o trânsito de uma capital(comparando com São Paulo, lá é o céu). Claro que posso estar exagerando um pouco, mas pelo menos essa foi a minha experiência nos três dias que passei por lá.

Foi uma viagem turistica mesmo, sem maiores pretenções. Conhecemos o Jardim Botânico, com os seus enormes jardins, sua estufa inspirada no castelo de cristal e seu bosque com um pedacinho da mata nativa da região. Também fizemos o passeio de trem até morretes, atravessando a serra do mar. A ferrovia é cheia de história, foi construida há mais de 100 anos e é utilizada até hoje por trens de carga para escoar a produção paranaense até o porto de paranaguá. As paisagens da serra do mar são incríveis e é admirável imaginar que a ferrovia foi construida no tempo do império, pois ela passa por regiões onde o acesso é muito díficil.

Conhecemos a ópera de arame, que é uma sala para apresentações, e a impressão que se tem ao olhar pela primeira vez, é que toda a estrutura foi feita em arame e está sobre um lago, mas é só impressão. Aproveitamos para conhecer o Madalosso (valeu a dica Andrew), que é o maior restaurante do Brasil e o segundo maior do mundo. Segundo o tiozinho do estacionamento(que disse que o site deles está desatualizado), eles já atenderam mais de 6.000 pessoas em um único dia. A comida é muito boa e o preço também, um ótimo custo x benefício, recomendo. Durante nossas andanças, ainda demos uma passeada pelo batel, que é um bairro nobre de Curitiba e fica pertinho do centro, é um bairro muito bonito e tranquilo, tem shoppings, barzinhos, restaurantes e baladas.

Mesmo com todos estes atrativos, quero chamar atenção para uma "atração" que nem é tão conhecida assim, e foi o que mais me surpreendeu durante a viagem, que é o Museu Oscar Niemeyer. Começa que o prédio foi projetado pelo próprio Niemeyer, o que já é algo que não se vê todo dia. O prédio tem uma arquitetura muito bonita, com muito espaço, muito verde e um design único. Se todo o prédio estivesse vazio já valeria a visita pelas rampas de acesso, pela estrutura das salas, pelas possibilidades de iluminação, e pelo túnel que liga o prédio principal ao "olho" e pelo próprio "olho", que é uma enorme estrutura semelhante a um olho que fica sobre uma grande coluna no meio de um pequeno lago bem em frente ao prédio principal do museu. Como se isso não bastasse, o museu tem um acervo invejável, com muitas obras e objetos pessoais de Tarsila do Amaral, muitas exposições de obras e fotografias. O lugar é enorme, tanto que nós visitamos somente metade das salas de exposição e olhe lá. Também há salas que passam vídeos o tempo todo, um espaço para educação cultural para crianças, uma lojinha de souvenirs e ainda uma grande exposição com fotos, textos e maquetes sobre Oscar Niemeyer. E o melhor de tudo, você pode ver tudo isso por apenas R$ 4,00 hehe.

As 10 maneiras mais comuns de arruinar projetos com XP e Scrum

Povo, antes de mais nada quero me desculpar pela demora do novo post, nesta última semana o bicho pegou e não sobrou tempo para muita coisa. Agora, falando sobre o assunto do dia, na semana passada o Guilherme Chapiewski, da globo.com, postou em seu blog um resumo sobre a apresentação do Henrik Kniberg, que ocorreu na Agile 2008 Conference em Toronto/Canadá.

Na apresentação, Henrik Kniberg falou sobre "as 10 maneiras mais comuns de arruinar projetos com XP e Scrum". Lendo o resumo do Guilherme, cheguei a conclusão que, com as devidas adaptações de contexto, as tais 10 maneiras se aplicam a praticamente qualquer projeto de desenvolvimento de software, mesmo que não seja utilizada uma metodologia ágil para o desenvolvimento. Vou colocar as minhas considerações logo abaixo de cada item do resumo do Guilherme(em itálico).

Resumidamente, as 10 maneiras mais comuns de arruinar projetos com XP e Scrum são:

• Futilidades: debates homéricos sobre coisas como “vamos usar cartões ou post-its” quando o time sequer tem um Product Owner! Os problemas devem ser atacados em ordem de importância. Além disso, a aplicação do processo não precisa ser perfeita desde o início. Good enough is good enough.
  

Em outras palavras, a prioridade sempre deve ser para o que é mais importante. Quem nunca ouviu "faz o cadastro 123AABB e depois o cálculo" ou "começa a adiantar o código, e depois você vê direitinho com o cliente como vai funcionar". Nesses dois casos o mais importante está sendo deixado de lado ou postergado, este tipo de atitude invariavelmente leva a retrabalho e dor de cabeça.

• Definition of Done: muitos times não têm uma definição de pronto ou não respeitam essa definição. Isso não só é essencial como também é preciso que o cumprimento desta definição esteja dentro do controle do time.

Em scrum e xp existe um conceito muito interessante, que é a "definição de pronto". Esta definição é a referência para que os desenvolvedores possam dizer que algo está pronto. Isso evita que alguns desenvolvedores mais preguiçosos façam a programação correndo, com o famoso teste "compilou? beleza" e liberem para a equipe de qualidade.

• Velocidade: não é conhecida, usada ou é muito variável ao longo das iterações.

Métricas em desenvolvimento software ainda é algo muito complicado e as vezes polêmico, mas necessário. Para medir velocidade em scrum e xp, a métrica mais conhecida e utilizada é a de "story points", mas pode-se utilizar outras métricas, como a APF por exemplo. O ponto que quero chegar é, para poder melhorar é preciso ter uma medida de desempenho, fazendo uma rápida analogia, trabalhar sem uma métrica de velocidade é como estar em uma corrida de fórmula 1 sem cronômetro e velocímetro.

• Retrospectivas: não há retrospectivas e o time não evolui suas práticas ao longo do tempo aproveitando-se dos aprendizados obtidos nas iterações.

Aqui entra o lance do feedback, apesar de algumas pessoas acreditarem que essas reuniões são puro desperdicio de tempo, as reuniões de retrospectiva são muito importantes pra se buscar e obter feedback individual e coletivo. A equipe precisar ter um momento para analisar o ciclo, absorver novos conhecimentos e evoluir.

• Comprometimento do time: time é cobrado e sempre culpado por erros em estimativas. Isso faz com que eles sempre se comprometam com menos do que podem fazer, com medo de serem culpados novamente.

Temos que pensar que em 99,9% dos casos, ninguém gosta de errar, ninguém erra de propósito e que desenvolvedor não tem bola de cristal. Estimativa é só isso, estimativa, óbvio que estourar um prazo não é legal, mas acontece e com o passar do tempo há um refinamento nas estimativas. Exigir que os desenvolvedores sempre acertem as estimativas provoca comportamentos indesejados, como exagerar nas estimativas, trapacear na apuração dos tempos de tarefas, enrolar até dar o tempo previsto para a tarefa, etc.

• Débito técnico: é totalmente ignorado e só cresce ao longo das iterações.

Débito técnico são aquelas coisas "bizonhas" que aparecem na arquitetura de um software, que precisam ser re-estruturadas para ser possível trabalhar o código. Normalmente é o resultado do uso recorrente de marretadas. O problema é quando o software nunca é re-estruturado, nesse caso a empresa só perde dinheiro porque qualquer implementação ou manutenção fica díficil de fazer, até que se chega em um ponto onde o software precisa ser jogado fora e feito novamente a partir do zero.

• Trabalho em equipe: não há trabalho em equipe e existem tarefas fixas para determinadas pessoas, o que faz com que várias histórias sejam implementadas em paralelo.

Além do desenvolvimento em paralelo, que já faz com que a entrega de funcionalidades demore mais, a falta de trabalho em equipe cria "donos" de códigos, e isso gera muitos efeitos maléficos na organização como: códigos indecifráveis que apenas uma pessoa consegue trabalhar, a empresa fica réfem do "cara" que sabe tudo de uma coisinha só, surgem gargalos no desenvolvimento porque apenas uma pessoa consegue trabalhar com determinado assunto, não existe troca de conhecimento, etc.

• Product Backlog: não existe ou não está priorizado corretamente.

Uma vez um professor me disse a seguinte frase: "_Ahhh, muitas vezes é aquele negócio né? O último cliente que entra na sala com o pé na porta e gritando é o primeiro a ser atendido". Acho que isso ilustra perfeitamente a falta de um backlog(lista de pendências do produto) devidamente priorizado de acordo com as prioridades de negócio da empresa.

• Integrações da base de código: não existe um branch onde o código pode ser lançado em produção a qualquer momento e a gerência da base de código não é agil.

O impressionante mesmo, é ver que há empresas de desenvolvimento que já transformaram essa deficiência em política da empresa. Ilustrando com um exemplo: O cliente encontra um bug crítico no sistema e precisa de uma correção urgente, a resposta padrão é: "_Ahhh, infelizmente só poderemos estar liberando a versão que estará corrigindo o seu problema no final do mês, que é quando estaremos fechando versões".

• Sprint Backlog/quadro de tarefas: não existe, está longe do time, é muito complicado ou não é usado durante o Daily Scrum e atualizado diariamente.

Essa é exclusiva de quem trabalha com scrum e xp, mas, seria mais ou menos o mesmo que ter um project que nunca é atualizado. Nesse caso, não ter nada já é melhor.

Achei muito legal essa lista, principalmente porque ilustra a maioria dos problemas que já observei em desenvolvimento de software, seja com metodologias tradicionais, metodologias ágeis ou mesmo sem nenhuma metodologia.

O poder da MARRETA

Hoje eu quero descontrair um pouco, portanto, vamos falar do poder da MARRETA. Talvez a marreta seja o instrumento de trabalho mais poderoso que está ao alcance de qualquer desenvolvedor de software.

Aposto que qualquer um que já programou alguma coisa nessa vida pode contar um "causo" como esse: "_Eu estava fazendo um programa xyz que tinha que gravar um blabla no banco, mas tinha um cálculo antes que provocava um erro de conversão de tipo por causa da Repimboca da Parafuseta que retornava float e devia ser double. Ai eu tive que fazer uma conversão para string e depois pra number, e assim funcionou. Claro que pode dar problema em outra coisa e qualquer um que pegar o código vai me xingar até faltar folego, mas foi o que funcionou, fazer o que?"

Essas situações acontecem por "n" motivos, e não vale a pena ficar tentando descobrir a causa desses problemas na linguagem de programação, ou na ferramenta(exceto se você desenvolve a tal ferramenta). O importante mesmo, é avaliar se a marretada era indispensável, se não existe nenhuma outra alternativa, mesmo que mais cara, para o problema. Geralmente há boas razões para não implementar a solução "decente", pode ser porque o projeto está com prazo apertado, porque a gambiarra não é tão grande, porque fazer a solução decente vai ficar muito caro e também há as razões não tão boas, como o desenvolvedor estar com preguiça(por exemplo), o chefe gostar de marretadas(exemplo também).

Apesar da inegável tentação que é resolver aquele abacaxi em 5 minutos usando o poder de uma bela marretada, eu costumo pensar bem antes de me decidir por uma solução dessas. Marretadas podem gerar muitos outros problemas para os clientes, geralmente gera muitos mal cheiros no código (Refactoring -> Beck e Fowler), isso sem falar no aumento do débito técnico do projeto. Provocar todos estes fatores repetidamente impossibilita a manutenção de qualquer software em um curto período de tempo.

E ai, vai uma marretada hoje?