Como provar aos meus stakeholders e gerentes que meu software funciona?[fechado]

Question

O que os engenheiros de software encontram após outro lançamento estressante?Bem, a primeira coisa que encontramos em nosso grupo são os bugs que divulgamos abertamente.O maior problema que nós, engenheiros de software, encontramos após um lançamento estressante é o código espaguete, também chamado de código espaguete. grande bola de lama.

O tempo e o dinheiro para perseguir a perfeição raramente estão disponíveis, nem deveriam estar.Para sobreviver, devemos fazer o que for necessário para que nosso software funcione e seja lançado no prazo.Na verdade, se uma equipa conclui um projecto com tempo de sobra, os gestores de hoje provavelmente interpretarão isso como um sinal de que irão disponibilizar menos tempo e dinheiro ou menos pessoas na próxima vez.

Você precisa entregar software de qualidade dentro do prazo e do orçamento

Custo:A arquitetura é um investimento de longo prazo.É fácil para as pessoas que pagam as contas rejeitá-lo, a menos que haja algum benefício imediato tangível, como uma redução de impostos, ou a menos que haja dinheiro e tempo excedentes disponíveis.Esse raramente é o caso.Mais frequentemente, o cliente precisa de algo funcionando amanhã.Muitas vezes, as pessoas que controlam e gerem o processo de desenvolvimento simplesmente não consideram a arquitectura uma preocupação premente. Se os programadores sabem que a mão de obra é invisível e os gerentes não querem pagar por ela de qualquer maneira, nasce um círculo vicioso.

Mas se esse fosse realmente o caso, cada projeto de software de longo prazo sempre levaria a uma grande bola de lama.

Sabemos que isso nem sempre acontece.Por quê?Porque a afirmação de que os gestores não consideram a arquitectura uma preocupação premente é falsa.Pelo menos hoje em dia.Os gerentes da área de TI sabem muito bem que a manutenção é fundamental para o negócio.

os negócios tornam-se dependentes dos dados que os impulsionam.As empresas tornaram-se criticamente dependentes do seu software e infraestruturas informáticas.Existem vários sistemas de missão crítica que devem estar no ar vinte e quatro horas por dia, sete dias por semana.Se estes sistemas falharem, os inventários não poderão ser verificados, os funcionários não poderão ser pagos, as aeronaves não poderão ser encaminhadas, e assim por diante.[..]

Portanto, está no cerne do negócio buscar maneiras de manter os sistemas longe da grande bola de lama.Que o sistema ainda pode ser mantido.Que o sistema realmente funciona e que você, como programador, pode provar que funciona.Sua gerente pergunta se você terminou sua codificação hoje, ela pergunta se o lançamento que tem as correções A, B e C pode ser feita hoje ou ela pergunta se o software que será lançado realmente funciona?E você provou que funciona?Com o que?

Agora a minha pergunta:

De que maneiras temos para provar aos nossos gerentes e/ou partes interessadas que nosso software funciona?Os sinais verdes dos nossos testes de unidade de software são bons o suficiente?Se sim, isso não provará apenas que a nossa grande bola de lama ainda está fazendo o que esperamos que faça?Que o software é sustentável?Como você pode provar que seu design está certo?

[Adicionado mais tarde]

Chris Pebble, sua resposta abaixo está colocando minha equipe no caminho certo.A Garantia de Qualidade é definitivamente o que procuramos.Obrigado Chris.Ter uma política de QA acordada com as partes interessadas é o resultado lógico do que minha equipe busca.

A questão seguinte é o que deveria estar nessa política de controle de qualidade?

• Ter aquele buildserver em execução visível para meus stakeholders
• Ter o buildserver não apenas 'apenas construir', mas adicionar testes que faziam parte da política de controle de qualidade
• Ter um acordo com minhas partes interessadas sobre nosso processo de desenvolvimento (onde os desenvolvedores revisam o código uns dos outros faz parte)
• mais..

Mais algumas informações:A equipe que lidero está construindo webservices que são consumidos por outras equipes de software.É por isso que um webservice quebrado custa dinheiro imediatamente.Quando os desenvolvedores da equipe do Presentationlayer ou os próprios testadores não conseguem avançar, ficamos sob estresse imediato e temos que corrigir bugs o mais rápido possível, o que por sua vez leva a hacks rápidos.

[adicionado mais tarde]

Obrigado por todas as respostas.Na verdade, trata-se de “confiança”.Não podemos fazer um lançamento se o software não tiver a confiança das partes interessadas, que estão testando ativamente nosso software usando o site que está consumindo nosso serviço web.Quando surgem problemas, a primeira pergunta dos nossos testadores é:É um problema da camada de serviço ou da camada de apresentação?O que me orienta a ter uma política de controle de qualidade que garanta que nosso software esteja ok para os testes que estão fazendo.

Portanto, a única maneira que posso (agora) imaginar permitir a confiança dos testadores é:- Converse com a equipe de teste atual, analise os testes que eles são capazes de executar manualmente (a partir de seus scripts de teste e cenários) e certifique-se de que nossa equipe tenha esses testes como testes unitários já verificados em nosso webservice.Esse seria um bom ponto de partida para uma 'aprovação' antes de lançarmos um lançamento que a equipe de camada de apresentação terá que integrar.Será necessário algum esforço para esclarecer que a criação de testes automáticos para todos esses cenários levará algum tempo.Mas será definitivamente útil para garantir que o que construímos está realmente funcionando.

Answer 1

Você não pode provar isso além do escopo dos testes e, a menos que haja uma especificação à prova de balas (que nunca existe), os testes nunca provam nada além do óbvio.

O que você pode fazer como equipe é abordar seu design de software de maneira responsável e não ceder às tentações de escrever código ruim para agradar os gerentes, exigindo os recursos necessários e as restrições de tempo e tratar todo o processo, tanto quanto um ofício um trabalho. Os melhores escultores renascentistas sabiam que ninguém veria as estátuas de costas a serem colocadas nos cantos das catedrais, mas ainda se esforçaram para garantir que não estavam se vendendo aquém.

Como equipe, a única maneira de provar que seu software é confiável é criar um histórico: faça as coisas corretamente desde o início, corrija bugs antes de implementar novos recursos, nunca ceder à correção rápida e verifique se todos compartilham o mesmo entusiasmo e respeito pelo código.

Answer 2

Faço parte de uma equipe que trabalha em um grande projeto para um cliente governamental.O primeiro módulo da fase 1 foi um grande desastre, a equipe não era gerenciada, não havia equipe de QA e os desenvolvedores não estavam motivados para trabalhar melhor.Em vez disso, o gerente continuou gritando e deduzindo os salários das pessoas que não faziam horas extras!

O cliente, né, não pergunte isso, ficou muito chateado, mas ficou na nossa empresa porque sabe que ninguém entende de negócio como nós.

Então, qual era a solução:

• A primeira coisa separou a gerência dos programadores e colocou um líder de equipe amigável.
• Em segundo lugar, contrate uma equipe de controle de qualidade qualificada.Nas primeiras semanas, os bugs estavam na casa das centenas.
• Terceiro, coloque 2 a 3 desenvolvedores como equipe de suporte, a responsabilidade é não fazer nenhuma tarefa nova, apenas corrigir bugs, trabalhar diretamente com o controle de qualidade.
• Quarto, motive a galera, às vezes não se trata de dinheiro ou férias extras, às vezes uma boa palavra será perfeita.Pequeno exemplo, depois de trabalhar 3 dias seguidos durante quase 15 horas por dia, o líder da equipe fez uma nota ao gerente.Dois dias depois recebi uma carta do CEO me agradecendo pelos meus esforços e me dando 2 dias de férias.

Em breve entregaremos o 4º módulo do sistema, e como membro da equipe de suporte posso dizer que está pelo menos 95% livre de bugs.O que é um grande salto em relação aos nossos primeiros módulos.

Hoje temos uma equipe de desenvolvimento poderosa, controle de qualidade qualificado e solucionadores de bugs especializados.

Desculpem a longa história, mas foi assim que nossa equipe (durante 4 meses) provou ao gestor e ao cliente que somos confiáveis ​​e só precisamos do ambiente certo.

Answer 3

Em todos os casos, exceto triviais, você não pode 'provar' que seu software está correto.

Esse é o papel de vocêSer UMAcceppany TEsting: Mostrar que um nível aceitável de utilidade foi alcançado.

Answer 4

Eu acho que isso está colocando o carrinho diante do cavalo. É equivalente a um soldado de pé tentando explicar ao general o que são manobras de batalha e por que proteger seus flancos é importante. Se a gerência não puder dizer a diferença entre o código da qualidade e uma grande bola de lama, você sempre acabará entregando uma grande bola de lama.

Infelizmente, é completamente impossível "provar" que seu software está funcionando sem bugs (os comerciais do Windows XP sempre me incomodavam ao anunciar "a versão mais segura do Windows de todos os tempos", isso é impossível de provar no lançamento). Cabe ao gerenciamento configurar e aplicar um processo de controle de qualidade e estabelecer métricas sobre como é realmente um produto entregável e qual nível de bugs ou comportamentos inesperados é aceitável na versão final.

Dito isto, se você é uma equipe pequena e define suas próprias políticas de controle de qualidade com pouca contribuição da gerência, acho que seria vantajoso escrever um processo básico de controle de qualidade e fazer com que a gerência seja assinada. Para nossos aplicativos da Web, atualmente suportamos 4 navegadores - e a gerência sabe disso - então, quando o aplicativo quebra em algum navegador de mão obscuro, todos entendem claramente que isso não é algo que projetamos o aplicativo para apoiar. Ele também fornece uma boa alavancagem para contratar recursos adicionais de desenvolvimento ou teste quando a gerência decidir que deseja começar a testar x.

Answer 5

Como Billy Joel diz uma vez: "Sempre foi uma questão de confiança".

Você precisa entender que o desenvolvimento de software é "magia negra" para todos, exceto aqueles que escrevem software. Não é óbvio (na verdade, bastante contra -intuitivo) para o resto da sua empresa que muitas de suas iniciativas levam a uma qualidade crescente e a redução do risco de correr ao longo do tempo e/ou orçamento.

A chave é construir uma relação de confiança e respeitosa entre desenvolvimento e outras partes do negócio. Como você constrói essa confiança? Bem, esse é um daqueles problemas delicados de pessoas ... você precisará experimentar um pouco. Eu uso as seguintes ferramentas com frequência:

1. Visibilidade do processo - Certifique -se de que todos saibam o que você está fazendo e como as coisas estão progredindo. Além disso, verifique se todos podem ver o impacto e as mudanças que ocorrem durante o desenvolvimento.
2. Apontar as pequenas vitórias - Para criar confiança, aponte quando as coisas foram exatamente como você planejou. Tente encontrar situações em que você tenha que julgar e usar o termo "mitigou o risco" com sua gerência.
3. Não diga: "Eu te disse". - Digamos que você disse à gerência que precisava de 2 meses para realizar alguma tarefa e eles dizem: "Bem, você só tem três semanas". O resultado provavelmente não será bom (assumindo que sua estimativa seja precisa). Torne a gerência ciente do problema e documente todas as coisas que você precisava fazer para tentar cumprir o prazo. Quando a qualidade se mostra ruim, você pode trabalhar com os problemas que enfrentou (e gravou) de maneira profissional, em vez de apontar o dedo e dizer: "Eu lhe disse isso".

Se você tem um bom relacionamento com seu gerente, pode sugerir que eles leiam alguns livros específicos para o desenvolvimento de software para que possam entender as melhores práticas do setor.

Além disso, eu apontaria para o seu chefe que não permitir que você atue como desenvolvedores de software profissional está prejudicando sua carreira. Você realmente quer trabalhar em algum lugar que permita crescer profissionalmente, e não em algum lugar que o transforma em um hacker.