O Gestor de Projecto pede 100% de confiança sempre que se comete código

Como devo responder à sua pergunta neste caso, sem parecer incompetente? Honestamente, nunca tenho 100% de confiança em todo o site, mas tenho confiança nos meus métodos de teste. E, como programador, também sei que não é invulgar que bugs inesperados surjam mais tarde a partir destas alterações centrais.

O gestor de projecto não compreende o software suficientemente bem, e certamente não compreende os testes suficientemente bem. Talvez ele precise de ser educado.

Se tivesse um Departamento de GQ profissional, eu dizia-lhe para pedir o apoio do Gestor de GQ para explicar a este Gestor de Projecto a natureza do software, a natureza dos bugs, e a natureza dos testes. Eu pediria ao QA Manager para indicar porque é que simplesmente não é possível testar todas as condições, e como o lançamento/não lançamento é uma actividade comercial auxiliada pelos resultados dos testes, mas nunca pela informação perfeita.

Pode desejar obter uma cópia do excelente livro de Gerald Weinberg “* Perfect Software and other illusions about testing **”. No capítulo 3 (“Why Not Just Test Everything?”), Weinberg tem uma secção chamada “There are a infinite number of possible tests”

Ele fala de uma porta traseira colocada num programa altamente seguro onde a protecção da palavra-passe normal poderia ser contornada digitando W seguido de três espaços, depois M seguido de três espaços, depois J seguido de exactamente mais 168 teclas sem usar uma vez a letra L.

Depois ele escreve: “Já percebeu o ponto por esta altura? Se não adivinhou que o número de testes necessários para testar exaustivamente o software é infinito, ou pelo menos "um número maior do que eu poderia correr na minha vida”, não percebeu o objectivo deste capítulo. Agora sim"

Explique ao seu Gestor de Projecto que cada dia de testes adicionais irá melhorar um pouco a sua confiança no seu código, no entanto nunca poderá chegar aos 100%. Diga-lhe que terá todo o prazer em continuar a testar à custa do seu outro trabalho produtivo. Depois pergunte-lhe quantos dias mais gostaria que passasse a testar e qual dos seus outros trabalhos deve ser adiado.

Se o seu Gestor de Projecto ainda não o tiver, e se se sentir um pouco recuado, pergunte-lhe se está 100% confiante que cada estimativa que publica está exactamente correcta e que os prazos nunca serão perdidos. Pergunte-lhe se ele está 100% confiante que nenhum e-mail que ele escreva de agora até sempre terá uma gralha. Pergunte-lhe se está 100% confiante de que nunca irá cometer um erro - agora e no futuro.

Chefe: Está 100% confiante que esta correcção não irá quebrar nenhuma das funcionalidades existentes ou causar quaisquer efeitos adversos na experiência do utilizador?

** Eu:** Não. Uma vez que não temos um conjunto de testes de 100% de cobertura, não há forma de verificar que qualquer alteração de código evitará a quebra da aplicação ou efeitos adversos. No entanto, realizei as seguintes acções para assegurar que é pouco provável que o seu desempenho seja involuntário:

• Limitei o âmbito da alteração apenas ao módulo que afecta
• Li e actualizei a documentação em conformidade
• Executei os testes unitários deste módulo e dos módulos afectados
• Criei testes unitários para verificar novas funcionalidades adicionadas e testes obsoletos que já não são relevantes devido à alteração

Embora não possa dar-vos exactamente 100% de garantia, dei a maior garantia possível dentro do prazo que considero razoável para a implementação desta funcionalidade. Na verdade, já cheguei ao ponto de diminuir os retornos. Posso gastar mais 5 horas para vos dar mais uma garantia de 0,1%, mas já é uma probabilidade tão baixa que tal esforço não se justifica. No entanto, o senhor está encarregue do projecto e do prazo, portanto diga-me quanto mais tempo devo gastar nesta função.

Agora a bola está no seu campo. Se ele quer mesmo que eu passe a minha estimativa pessoal de, digamos, 95% de certeza para 95,1% de certeza para mais algumas horas de trabalho, então ei - eu posso fazer isso.

Se ele continuar a ser desagradável com isso, terei uma conversa por e-mail com ele e com o “dono” do projecto sobre este requisito de “100% testado”, e que recursos acredito serem necessários para o cumprir.

Como desenvolvedor, você está UNIT testando as alterações ao seu código. Na minha opinião (como programador), ou seja, para verificar que não existem erros óbvios, tudo se compila, todos os erros estão encurralados. Você não tem como saber que cenários serão encontrados uma vez que o código entre no ar (dados ruins, entrada inesperada, alteração no software do cliente, a lista é interminável)

Para ter 100% de confiança de que uma alteração não afetará nada, você precisará de um ambiente de teste que espelhe EXATAMENTE o ambiente ao vivo (dados, hardware, permissões, conectividade) e um conjunto de scripts de teste que cubram todos os cenários. Este, como é sabido, é um ambiente virtualmente impossível de criar por várias razões

Se ele espera ter 100% de confiança, então precisa de fornecer o ambiente e a mão-de-obra para suportar as suas expectativas

É um pouco como quando os gestores de projecto e os clientes pedem que as coisas sejam à prova de futuro!

Parece que ele caiu num mau hábito. Ele está a fazer uma pergunta que sabe que, a algum nível, é uma tolice. Mas há um pouco de compulsividade. O meu palpite é que ele está a agir sobre uma ansiedade subjacente, e fazer uma pergunta pouco razoável fá-lo sentir-se mais controlado.

Neste tipo de situações tento difundir a dinâmica, sendo confiante e injectando um pouco de humor. Se compreende que a sua pergunta não vem do raciocínio, mas sim da ansiedade, então pode abordar isso melhor indirectamente do que directamente.

Em situações como esta, costumo acalmar os receios da gestão, apresentando todas as medidas que tomei para garantir a qualidade. Ele é, afinal, o cliente e precisa de saber que as suas prioridades estão de acordo com as dele. Vejam estes testes unitários. Olhe para este acompanhamento. Veja como o código é estruturado para manter as mudanças locais, modulares, etc. Se transmitir uma sensação de confiança e controlo, vai acalmar a sua ansiedade e provavelmente poderá ter uma conversa mais racional.

É aí que entra em jogo a arte deste negócio. Não só “funciona”, mas o cliente sente-se bem com isso.

Em última análise, no entanto, é uma relação de negócio. Se a contratação é confortável e rentável para si, então vale a pena aguentar esta peculiaridade. Não me parece que ele seja assim tão sério, apenas um pouco persistente. Como eu disse, ele desenvolveu um hábito irritante. Se ele começar a reagir negativamente e o tom se tornar mais hostil, então o equilíbrio do acordo comercial pode fazer com que não valha a pena para si. Mas, pela sua breve descrição, parece-me que ainda consegue gerir a relação de forma eficaz.

Muitas pessoas descreveram isto como um problema educativo, e não estou a dizer que estejam erradas.

É também possível que seja um problema político. O que a questão pode realmente significar, é que o gestor do projecto quer ser absolvido da responsabilidade por quaisquer erros. Ele recebe de si uma declaração juramentada em que sente que pode “razoavelmente” confiar, por isso, se alguma coisa correr mal, diz que fez tudo o que podia para o evitar, mas o senhor falhou.

Isto não é uma boa gestão e também não é 100% garantido que o ponha em claro se houver algum problema.

Admito que isto é especulação da minha parte, os exercícios de “butt-covering” não são de todo invulgares na vida profissional e o senhor tem de lidar com eles. Portanto, se isto soar verdade, então o que é preciso fazer para resolver o problema não é apenas educar o gestor de que é impossível ter 100% de confiança. Também precisa de o convencer que um bug não é um desastre - para ele pessoalmente ou para a empresa.

Isto pode significar, por exemplo, dar exemplos de bugs a serem tratados a um custo razoável e sem qualquer culpa a voar de um lado para o outro. Pode significar olhar para a cultura da sua própria empresa, quer haja mais alguém na empresa a preparar-se para o culpar injustamente se alguma coisa correr mal. Pode também significar a introdução de procedimentos para lidar com futuros insectos o mais rapidamente possível e de forma pouco dispendiosa possível. Se a empresa estivesse realmente 100% confiante no código então tais procedimentos seriam inúteis porque estaria disposta a apostar arbitrariamente grandes quantias de dinheiro em não haver futuros bugs!

Como sanção final, se ele (o empregador) lhe pedir (o empreiteiro) que lhe venda uma garantia que não pode dar sobre o seu trabalho, e nada o fará mudar de opinião sobre este ponto, então tudo o que pode fazer é afirmar claramente que não é capaz de dar essa garantia, e que é bem-vindo a empregar outra pessoa se pensar que há alguém que pode. Claro que é um longo caminho a percorrer, mas mais vale que conheça o seu BATNA antes de começar.

Por rigor, nunca se pode estar 100% seguro de que um commit não quebra um programa.

Mesmo com todo o tipo de testes possíveis (testes unitários, integração, componente, sistema, manual, UI, fuzz, segurança, penetração… o que quiser). Isto é devido a um problema de paragem . Um extracto relevante da Wikipedia segue abaixo:

Na teoria da computabilidade, o problema de paragem pode ser dito como se segue: “Dada a descrição de um programa de computador arbitrário, decida se o programa termina de funcionar ou continua a funcionar para sempre”. Isto é equivalente ao problema de decidir, dado um programa e um input, se o programa vai eventualmente parar quando executado com esse input, ou se vai correr para sempre.

Alan Turing provou em 1936 que um algoritmo geral para resolver o problema de paragem para todos os pares de inputs possíveis do programa não pode existir. Uma parte chave da prova foi uma definição matemática de um computador e programa, que ficou conhecida como uma máquina Turing; o problema de paragem é indecidível sobre as máquinas Turing.

Se o seu PM se preocupa com o valor e a entrega estável e previsível, talvez o consiga convencer a dar uma vista de olhos ao SCRUM framework .

Outros deram muitos conselhos interessantes sobre como interagir com o seu PM. Pessoalmente, aconselharia a marcar uma reunião com o seu PM e com a equipa onde pode discutir os seus processos. Sou fortemente a favor do SCRUM, pelo que isto estaria em grande parte relacionado com o SCRUM.

Eu tentaria explicar, que um objectivo de 100% é elusivo. Não é possível alcançá-lo. Nunca. Em todo o universo. A história tem visto muitos exemplos, demonstração do lançamento do Windows 95 , por exemplo. Há muito tempo atrás? Bem, veja quantos vermelhos são construídos em um servidor público de CI para projetos open source; faça login como convidado se você não tiver uma conta lá. Então um resultado disto - software vai falhar.

Segundo, eu aconselharia a adoptar uma prática, onde você pode entregar valor, em vez da confiança de um compromisso. Algo, que os clientes se preocupem. Iterativamente, repetidamente e de forma fiável. Agora, você pode mudar a perspectiva do seu PM do seguro a 100%, para algo que realmente importa. Isto é: o software está em uso, o seu produto está a melhorar e a equipa está a fornecer valor ao cliente.

Em terceiro lugar, a definição de feito deve ser feita. Algo, que uma equipa de desenvolvimento venha a criar. Isto pode incluir: documentação, implementação, testes, portões de qualidade, etc. Isto é muito importante, pois agora pode mudar a subjectividade (ou seja “tem 100% de certeza?”) para objectividade (ou seja, todos os pontos da definição de feito são completados).

Existem outros passos muito importantes que a SCRUM promove. Mas todas elas permitiriam aos programadores atenuar essa frustração, e permitir-lhes-iam apresentar resultados objectivamente quantificáveis, em comparação com a garantia subjectiva.

A resposta habitual para este tipo de objectivo é a revisão por pares e testes de regressão.

1) Não cometer nada no fluxo de código de produção até que não só o autor, mas também um ou mais programadores, o tenham verificado para garantir que muda apenas o que é necessário, que cumpre todos os critérios acordados para uma boa prática de codificação, que vem com um teste que lhe dá probabilidades decentes de detectar se uma mudança posterior quebra novamente a lógica, e assim por diante.

2) Não cometer nada no fluxo de código de produção até que TODOS os testes de regressão tenham sido repetidos e tenha sido provado que não quebrou nada para o qual o teste foi feito. Se ocorrer qualquer falha durante esse teste, a alteração tem de ser reposta até se poder estabelecer claramente que não causou o problema.

3) Testes alfa e beta precoces e muitas vezes com cenários de clientes do mundo real. Os clientes farão coisas com o seu código que você nunca esperou.

Nenhum deles é 100%, nem a sua combinação. Mas eles aproximam-no consideravelmente. Eles exigem um investimento não trivial de recursos adicionais. Eles retardam o desenvolvimento em comparação com os skunkworks “basta fazê-lo e nós vamos corrigi-lo quando ele quebra” a prática de codificação. Mas se você realmente quer código sem bugs, reconhecer que os humanos são falíveis e colocar práticas para ajudar a apanhar falhas antes que elas cheguem aos clientes pode valer mais do que esses custos.

Disseram-me que houve nunca um bug reportado no código que a IBM escreveu para a NASA - porque foi revisto por pares e testado até à morte durante o design, durante o desenvolvimento e antes de ser lançado.

Se você está a fazer algo crítico para a vida, é óbvio que vale a pena esse investimento. Se estás a fazer algo que é infra-estrutura para grandes empresas, vale a pena esse investimento; não queres ser aquele cujo bug derruba os processos de negócio de uma empresa de mil milhões de dólares.

Sim, enlouquece os bons codificadores. Até à primeira vez, poupa-lhes os seus olhares.

A verdade é que se trata de testes deficientes. A realidade é que uma empresa que não está disposta a investir numa equipa de GQ vai ter testes deficientes. Os bons testes são dispendiosos e levam tempo. A empresa aceitou o risco ao não autorizar o tempo e o dinheiro.

Mesmo uma equipa de GQ não pode garantir que todas as possibilidades sejam testadas porque os caminhos possíveis através de um programa complexo são basicamente infinitos. No entanto, eles irão aproximá-lo muito mais do que você está neste momento. Uma das razões é que é impossível para um dispositivo testar adequadamente o seu próprio código. Eles sabem o que ele faz, por isso tendem a conceber testes em torno daquilo que pensam que é suposto fazer. Falham casos extremos, falham coisas estúpidas que os utilizadores fazem que um dev nunca faria porque sabem como funciona, por vezes interpretam o requisito incorrectamente, mas todos os seus testes irão reflectir a sua interpretação original incorrecta. Muitas vezes, não conseguem detectar erros no requisito e fazem o que lhes é pedido para não fazerem o que deveriam ter feito (esta é a causa de um grande número de erros que só são encontrados depois dos utilizadores reais [que muitas vezes não são consultados para definir o requisito] tentarem utilizar o software). Falham efeitos em partes da aplicação em que nunca tiveram motivos para trabalhar, especialmente em partes que são feitas por especialistas (como uma mudança de tabela que faz sentido para a aplicação mas quebra um processo de importação automatizado ou um relatório)

Se ele quiser uma qualidade superior terá de pagar por isso, tanto em tempo como em dinheiro. Mesmo com uma GQ completa não pode chegar aos 100%, embora certamente a NASA e os seus contratantes se aproximem. Eles também gastam um grande negócio mais dinheiro* do que a sua empresa está a gastar. Mesmo assim, eles conseguiram perder completamente o MARS uma vez.

Se o que ele quer é a garantia de que quaisquer problemas não o prejudicarão com os clientes, então fale sobre o seu processo de testes (Mostre-lhe a lista de testes que realizou.), o que pensa que seria afectado e como verificou isso, o seu processo de como reverteria um mau empurrão e o seu processo de registo de erros para que os veja antes que a maioria dos clientes os note. Dê-lhe confiança de que, mesmo que haja um problema, ele pode ser corrigido. Fale sobre o valor de obter o código (novo recurso ou correção) rapidamente vice o tempo adicional que levaria para testar mais profundamente. Fale sobre os riscos de não o obter rapidamente.

Pode também pedir-lhe que forneça o teste de regressão completo do sistema sempre que fizer uma alteração porque não é possível a um dev testar completamente o seu próprio trabalho (sabe quais foram os seus pressupostos, se não estiverem correctos, nunca o testaria). Certifique-se de que ele sabe que terá de testar cada página da aplicação e cada coisa que pode ser feita numa página, em todas as ordens possíveis. Ah sim, teste também qualquer importação/exportação, relatórios, trabalhos automatizados. E todas as aplicações relacionadas que possam ser afectadas. Uma vez que ele tenha tentado exercer completamente o sistema uma vez, ele vai perceber porque é que você não pode fazer essa garantia.

Outra coisa a tentar é dizer-lhe antecipadamente que não pode fazer essa garantia, mas se ele autorizar X horas de teste, você pode chegar mais perto de fazer essa garantia. Dê-lhe uma lista detalhada dos testes adicionais e as horas que seriam necessárias para desenhar e executar cada um deles. Diga-lhe que percentagem de confiança você teria depois de executar todos esses testes e que percentagem de confiança você tem neste momento.

Por isso diga-lhe quanto tempo levaria apenas a executar todos os testes unitários actuais que você tem, independentemente de estarem ou não relacionados com esta questão. Assim, se tem actualmente 1000 testes unitários e cada um deles demora cinco minutos a configurar e executar e avaliar os resultados que seriam 83 horas. Peça-lhe a autorização para prosseguir e gastar esse tempo.

Se ele está de facto a microgerir-te e a olhar por cima do teu ombro durante todo o processo de construção do projecto, há uma maneira fácil de te certificares de que podes ‘garantir’ 100% de confiança sem que ele te fale mal do projecto mais tarde.

Pede-lhe que ele próprio o aprove

Para ser claro, não deves fazer isto como uma exigência, mas sim como uma sugestão, que se ele quer realmente um código 100% perfeito, então ele deve olhar para o que estás a fazer e aprovar cada mudança que estás a fazer pelo caminho. Isto não é para dizer que ele deve literalmente ler o código, mas sim para o ver em acção e confirmar “sim, é assim que ele deve agir”.

Se você é o único testador do seu próprio código, isto não é irrazoável - você já está totalmente focado no projecto, e se ele quer perfeição, ele próprio deve assumir a responsabilidade de garantir essa perfeição.

Também, tome notas sobre tudo o que ele aprova, para que mais tarde, quando ele inevitavelmente se quebrar, você possa apontar para a sua documentação mostrando que ele o aprovou.

Se, por qualquer razão, achar que isto não vai correr bem (por exemplo, se pedir-lhe para fazer mais trabalho é algo que já sabe que seria desastroso), tudo o que pode realmente fazer é testar o máximo de erros que conseguir, escrever nos seus relatórios tudo o que sabe que funciona correctamente e dar-lhe 100% de garantia de que, “dentro dos limites dos meus testes, estou 100% confiante nestas alterações”.

Infelizmente, pode estar na posição de ter um ‘chefe’ cuja compreensão do seu trabalho é limitada, o que é sempre uma dor ao tentar explicar como a correcção de erros é impossível de manter com 100% de confiança. Portanto, para resumir, a sua melhor aposta pode ser apenas fazer o melhor que puder, registar tudo e fazer compreender que está a fazer o que pode dentro dos seus próprios limites.

Bastantes respostas simpáticas aqui, o PM precisa definitivamente de ser educado e aprender um pouco sobre o que significa escrever software.

Não quero repetir nada disso, mas lançar outra ideia bastante invulgar. Este método é bastante arriscado e depende muito de quão elevada é a sua reputação, quão boas são as suas capacidades (ou mais como são percebidas), e tanto a sua personalidade como a do seu PM. Presumo que não o entendeu mal, e ele significa realmente 100% (vejo frequentemente pessoas a dizerem 100%, mas que significam realmente “faça o melhor que puder”)

Funcionou para mim uma vez, e essa é a única razão pela qual o estou a mencionar aqui. O senhor foi avisado. Esta é sobretudo uma forma possível de educar um PM se todos os outros meios falharem.

Por vezes, um PM (ou qualquer outro gestor) simplesmente não quer ouvir, por isso tem de se fazer com que ele (ou a equipa) bata numa parede para parar por um momento e pensar. Neste cenário isso significa: Trabalha o melhor que puderes, tenta testar o melhor que puderes. Dá o teu melhor, e depois diz “Sim, tenho 100% de certeza que isto vai funcionar”.

Se tiveres muita sorte, nunca vai acontecer nenhum bug e todos ficam felizes; mas na realidade o que vai acontecer é: existe um bug. O que é que vai fazer agora? Admite que cometeu um erro. Faça uma ligação com os bugs e o erro de ter 100% de certeza. Os humanos são imperfeitos e podem criar bugs no software. Os seres humanos são imperfeitos e podem criar bugs em testes. Consequentemente, os humanos são imperfeitos e podem “criar bugs” na sua percepção de estarem 100% seguros de que não existe nenhum bug.

Apresentar este poço, e 100% à prova de água (haha, j/k, os 100% novamente). Certifique-se que depois de tudo isto, a mensagem que passou é “Não posso estar 100% confiante nos meus testes”. Se o PM não conseguir dar o passo lógico de “Isto será o mesmo para todos os programadores”, então toda a esperança está provavelmente perdida…

Mas, por favor, tente outras coisas primeiro!

O indicador-chave é que se trata de uma alteração recente. Alguma coisa (ou alguém) provavelmente deu ao seu PM uma má experiência, e agora ele está no limite cada vez que algo muda. Ou talvez ele tenha lido algo num livro ou revista.

Se conseguir que o PM lhe conte a sua história (talvez sobre a sua bebida de eleição) então pode simpatizar, e ele pode tornar-se receptivo à “inovação”, também conhecida como uma prática sólida de engenharia de software.

Esta é a sua oportunidade de falar sobre o erro humano e as formas que esta indústria encontrou para aumentar os níveis de confiança nos nossos designs e códigos. Falar sobre as soluções de compromisso em termos de confiança, qualidade, recursos e prazos que provêm de diferentes abordagens aos testes, revisão do código pelos pares, métodos formais (também conhecidos como correctos por construção).

Fale a sua linguagem: Use metáforas para ilustrar a dimensão do problema. São 40.000 linhas de código? Diga-lhe que é como um mistério de 600 páginas de homicídio numa língua estrangeira. Se quiser mudar alguma coisa no meio do capítulo 12, como se certifica que não causa uma quebra na continuidade com o resto da história?

Procure formas de aumentar a confiança em relação a um alvo aceitável dentro de limites económicos razoáveis. Não vai conseguir implementar o SEI Capability Maturity Model nível 5 da noite para o dia. Mas talvez consiga passar da questão actual para “será que o conjunto de testes de regressão automatizado passa?” e “como é que expressamos este novo requisito no sistema de testes de regressão?”.

Eu responderia da forma mais matemática, considerando que ele pede uma probabilidade com 100% de confiança, e ignorando completamente o efeito que as distribuições estatísticas teriam sobre esse número: deveria dar-lhe 2 ou 3 números, com a confiança associada: 1 semana a 90%, 2 semanas a 95%, 6 meses a 100%. O último número foi um exagero, mas tenho a certeza que já percebeu.

Veja artigo da Wikipedia sobre Intervalos de Confiança para mais leitura.