Programador reclama de tudo que é forma de controle.
Horario, dedicação (lê-se acesso a internet liberada), prazo. Reclama até de escopo (como se ele soubesse mais do que o usuário).
O problema é que uma baita fatia dos programadores disponíveis no mercado não são bons o suficiente pra se considerarem artistas. Eles não conseguem criar uma solução funcional, segura e performática. Eles não trabalham dedicados se houver internet liberada, eles não cumprem 5hrs por dia se deixar. E no final, ninguem entrega o software.
Ah... mas o que fazer, jogar fora 80% dos programadores?
Não. Dá o básico pra eles fazerem. O que não precisa de criatividade, inspiração. Só precisa de dedicação, 8hrs por dia digitando código a moda-bicho enquanto reclama das formas de controle que lhe são impostas.
Isso não vai mudar. Nem todo software é o Google Maps. Tem muito espaço pra software simples e básico por aí... e para isso você só precisa de um programador simples e básico.
Então, antes de reclamar ou aceitar a reclamação de um programador chateado com o horario, com o bloqueio do MSN, veja se você (ou esse cara) merecem ser tratador como artista.
sábado, 31 de maio de 2008
Testes durante o desenvolvimento
"quanto mais cedo testar, melhor"
Eu não sei quem disseminou essa idéia, mas não acredito nela.
Imagine um sistema integrado. Você tem 10 telinhas pra construir.
Ah... aí você vai retestar tudo e começa a encontrar defeitos básicos que não deveriam estar lá. Aí vem os motivos:
Você consegue automatizar 100% das telas e rotinas? Não, nem se recomenda.
Você consegue vender um projeto de software cobrando o preço de uma automatização? (pessoas, ferramentas, documentação, manutenção de dados, scripts e documentação...)? NÃO, não consegue.
Então, pra resolver a equação eu proponho o seguinte: teste o mais tarde possível. Já que você vai ficar retestando sempre e sempre. Deixa tudo pro final. Cada programador testa sua tela ou rotina, libera quando achar que está legal e a equipe de teste só é usada no final da história.
Eu não sei quem disseminou essa idéia, mas não acredito nela.
Imagine um sistema integrado. Você tem 10 telinhas pra construir.
- Faz a 1a, testa, corrige, re-testa, ok;
- Faz a 2a, testa, corrige, re-testa, ok;
- e assim por diante.
Ah... aí você vai retestar tudo e começa a encontrar defeitos básicos que não deveriam estar lá. Aí vem os motivos:
- Ao fazer a tela 2, você destruiu a tela 1...
- Ao corrigir a tela 3, você destruiu a tela 1 e a 2;
Você consegue automatizar 100% das telas e rotinas? Não, nem se recomenda.
Você consegue vender um projeto de software cobrando o preço de uma automatização? (pessoas, ferramentas, documentação, manutenção de dados, scripts e documentação...)? NÃO, não consegue.
Então, pra resolver a equação eu proponho o seguinte: teste o mais tarde possível. Já que você vai ficar retestando sempre e sempre. Deixa tudo pro final. Cada programador testa sua tela ou rotina, libera quando achar que está legal e a equipe de teste só é usada no final da história.
Porque é impossível acertar na estimativa?
Recentemente eu estava procurando artigos sobre estimativa de software para uma aula e encontrei isso aqui: http://en.wikipedia.org/wiki/Putnam_model
Pode ser falta de estudo eu ainda não conhecer o tal do Putnam e seu modelo de estimativa, mas é algo sobre uma equação maluca que tem a pretenção de dizer quantas pessoas ou qual o tamanho ou qual o tempo que um software levará para ser feito.
Eu não acredito em método caseiro, em pontos de função, em caso de uso. Muito menos acredito no Delphi e seus "especialistas".
Será que existe no mundo, alguem capáz de estimar o tempo, esforço, duração e custo de um software feito sob-medida, antes dele ser feito e acertar? Eu duvido disso também.
Aí vem as teorias de que quanto mais avançado o ciclo de vida, maior a acertabilidade. Não acredito também. Mesmo quando o programador sabe o que está fazendo, alguém já viu ele acertar ao ser questionado: quanto tempo vc precisa para terminar? Eu nunca vi. Sempre falta alguma coisinha e sempre a culpa é de outro (mesmo que esse outro não seja claramente identificado).
Meu próximo post vai ser sobre a real utilidade de testes durante a construção. Este é questionando a utilidade de se estimar. Acho que não serve pra nada. Só pra gastar dinheiro alocando um gerente estimando e se frustrando.
Pode ser falta de estudo eu ainda não conhecer o tal do Putnam e seu modelo de estimativa, mas é algo sobre uma equação maluca que tem a pretenção de dizer quantas pessoas ou qual o tamanho ou qual o tempo que um software levará para ser feito.
Eu não acredito em método caseiro, em pontos de função, em caso de uso. Muito menos acredito no Delphi e seus "especialistas".
Será que existe no mundo, alguem capáz de estimar o tempo, esforço, duração e custo de um software feito sob-medida, antes dele ser feito e acertar? Eu duvido disso também.
Aí vem as teorias de que quanto mais avançado o ciclo de vida, maior a acertabilidade. Não acredito também. Mesmo quando o programador sabe o que está fazendo, alguém já viu ele acertar ao ser questionado: quanto tempo vc precisa para terminar? Eu nunca vi. Sempre falta alguma coisinha e sempre a culpa é de outro (mesmo que esse outro não seja claramente identificado).
Meu próximo post vai ser sobre a real utilidade de testes durante a construção. Este é questionando a utilidade de se estimar. Acho que não serve pra nada. Só pra gastar dinheiro alocando um gerente estimando e se frustrando.
Assinar:
Postagens (Atom)