Como manter o gerenciamento fora do nosso processo de desenvolvimento

Sou engenheiro de software em uma equipe de desenvolvimento de software. Nos últimos 3 anos, trabalhamos para um cliente interno em um novo produto. Agora que este produto terminou, vamos trabalhar nos principais novos recursos dos produtos existentes. Para um recurso específico, o gerenciamento de produtos calculou que leva 150 horas para ser desenvolvido. Juntamente com nosso gerente de projeto, criamos um plano muito detalhado e chegamos a um esforço de 300 horas. Ontem discutimos isso e eles acham que superestimamos as coisas.

Em nosso planejamento, estimamos horas para escrever testes de unidade, a idéia deles é descartá-los para economizar tempo. A decisão ainda não foi tomada e defenderei esse planejamento e os testes de unidade, se necessário. Mas o que realmente não gosto aqui é que o gerenciamento está interferindo no nosso processo de desenvolvimento. Como mantê-los fora do nosso processo de desenvolvimento? E que argumentos eu poderia usar para manter os testes de unidade no local (além da qualidade e economia de tempo a longo prazo)?

Como observação, nossa empresa possui três equipes de engenharia e a equipe em que eu integro entrega o software no prazo (com uma margem de 10%). Enquanto as outras equipes sempre entregam com atraso, principalmente devido à subestimação no planejamento. Eles planejam apenas a codificação e não o gerenciamento, os testes e o manuseio.

Primeiro, deixe-me dizer que simpatizo completamente com sua posição. Pode ser frustrante quando você tem uma falta de entendimento ou uma falha na comunicação entre diferentes partes do negócio. Dito isto, não acho que você deva tentar mantê-los fora. Em vez disso, você deve mostrar a eles os números sobre por que essa é uma boa idéia. Que fatos você tem que justificam o teste de unidade vale o esforço que você coloca nele? Se você não tiver nenhum, comece a reunir esses números ou mostre alguma pesquisa para fazer backup de suas reivindicações.

Eu mesmo tive que lidar com cenários semelhantes e respondi a essa pergunta sobre um tópico semelhante . Eu também escrevi sobre como eu lidei com isso aqui:

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

Caso você não se sinta à procura de links, repetirei meu resumo da pergunta relacionada:

Para resumir, comparei nossas horas estimadas com as horas reais do projeto e, em seguida, comparei nossa taxa de defeitos com a taxa de defeitos de outras equipes. No nosso caso, esses números se compararam favoravelmente e não houve mais preocupações.

Minha conclusão com base nessa experiência é:

... a melhor maneira de convencer alguém de que sua abordagem para fazer algo é prática e pragmática, é fazê-lo e compará-lo com outras abordagens. As pessoas não se importam com dogmas, ou por que você acha que algo deve ser o melhor caminho. Somente mostrando às pessoas os números e medindo a eficácia de sua abordagem, você pode realmente mostrar que suas práticas são eficazes.

Se sua equipe de gerenciamento não concordar em investir o que eles vêem como 150 horas adicionais em testes de unidade, talvez você possa convencê-los a investir em uma pequena área do produto (ou até mesmo concordar em dedicar as horas para fornecer alguns dados ) Faça testes de unidade nessa área do produto e colete dados sobre as taxas de defeitos nessa área do produto e o custo para encontrar e corrigir esses defeitos em comparação com as taxas de defeitos em outras áreas do produto. Espero que você colete alguns dados para fazer backup do seu caso e isso não será um problema para o seu próximo projeto.

A regra número um a seguir, independentemente do método usado, é que

1. Os desenvolvedores devem ter o direito de estimar seu próprio trabalho.
2. As partes interessadas devem ter o direito de priorizar esse trabalho.

Estimativa e priorização são duas forças que trabalham muito bem juntas, uma vez que ambas as partes aceitam suas próprias responsabilidades. Portanto, em vez de perder tempo discutindo, concorde com isso e respeite que ambas as partes farão seu trabalho da melhor maneira possível.

Você pode salientar que os testes de unidade economizam tempo; portanto, se você descartá-los, a estimativa será de 500 horas.

Diga-lhes sobre a dívida técnica e o valor dos testes de unidade

Veja este post de uma boa idéia sobre dívida técnica. Após esse post, você pode acessar o seguinte pdf

Eu gosto deste post sobre o valor do teste de unidade (provavelmente há mais para encontrar)

A esperança não é tirá-los do processo de desenvolvimento, mas envolvê-los e comprometê-los da maneira certa.

IMHO, você precisa anotar seu planejamento original, adicionar os capítulos 1 e 2 (não em um apêndice) nos quais explica a dívida técnica e o valor dos testes unitários. Dê-lhes alternativas:

• menos horas (não as 150 inteiras, isso parece ridículo) em que todas as alterações (durante a fase de desenvolvimento e durante a manutenção), em média, levarão:
  • pequenas 4 horas
  • médio 16 horas
  • grandes 40 horas
• horas estimadas em que cada alteração (fase de desenvolvimento e durante a manutenção) leva, em média:
  • pequenas 2 horas
  • meio 8 horas
  • grandes 20 horas

(As horas são apenas indicativas. Você está muito melhor equipado para fornecer estimativas adequadas.)

Não se esqueça de incluir seu histórico de entregas dentro do prazo e do orçamento.

Escreva e discuta isso com eles. Eles podem ter alguns pontos valiosos em recursos que realmente não precisam no momento ou alguma dívida técnica que estão dispostos a assumir para entregar a tempo. Apenas verifique se essas são escolhas conscientes.

Espero que isso ajude e boa sorte.

Primeiro, não divida os "testes de unidade de gravação" como uma tarefa separada a ser estimada, agendada e potencialmente cortada. Suas estimativas devem estar no nível do recurso "Implementar o XYZ - 18 horas". Essas 18 horas devem incluir o que for necessário em seu processo para que esse recurso seja "CONCLUÍDO", incluindo "testes de unidade de gravação".

Essa é uma boa maneira de tirar o desenvolvimento não técnico "do seu processo de desenvolvimento". Não inclua seu processo de desenvolvimento na lista de tarefas ou no cronograma do projeto que você fornecer!

Em segundo lugar, parece que sua equipe já está entregando bons produtos para eles e no prazo, mas outras equipes não estão. Talvez esse grupo de gerenciamento esteja acostumado a ter que gerenciar minuciosamente essas equipes. Jogue com seus pontos fortes - ofereça-se para mostrar a eles atualizações semanais ou quinzenais com os recursos de trabalho, e eles ficarão surpresos com o "processo de desenvolvimento".

Uma vez, eu estava em uma situação em que estava trabalhando com uma base de código em um estado muito bom; era necessário um novo recurso desafiador em um período de tempo muito curto, e eu consegui fornecê-lo em um período muito curto. Nesse ponto, a base de código estava em um estado muito pior. Portanto, o recurso foi entregue, mas meu trabalho não foi concluído: tive que colocar tudo de volta em um estado igualmente bom.

Expliquei ao gerente dois níveis acima: É como fazer uma pintura em sua casa. Se todas as ferramentas estiverem lá onde pertencem e em bom estado, todas as escovas limpas e assim por diante, você poderá fazer uma pintura muito rapidamente. Mas você precisa gastar tempo para colocar todas as suas ferramentas em ordem novamente. Se você não fizer isso, sua próxima pintura demorará muito mais tempo. Na verdade, você não se lembra onde estão suas ferramentas, seus pincéis não podem mais ser recuperados e custa muito mais tempo e dinheiro extra, como se você tivesse feito o trabalho de limpeza imediatamente.

E o mesmo no meu trabalho de programação: ao limpar, coloco a base de código em um estado em que posso entregar algo muito rapidamente novamente na próxima vez que for necessário. Caso contrário, da próxima vez vai demorar muito mais.

Você não pode mantê-los fora do processo completamente, afinal eles pagam seu salário e usarão o produto (se não diretamente, presumivelmente alguém na sua empresa é o usuário final).

Os gerentes que acusam os desenvolvedores de superestimar o tempo são um cenário muito comum na minha experiência e, se não for tratado, pode levar a uma corrida armamentista bastante estúpida, na qual as próximas estimativas serão duplicadas porque você sabe que os chefes os reduzirão pela metade, eles sabem disso. eles os dividem, então você os quadruplica, etc. Você precisa evitar esse círculo vicioso, se possível.

Supondo que não exista uma razão para "desistir" do prazo, sugiro duas coisas.

1. Forneça um plano detalhado do que você pensa que pode fazer em 150 horas, mantendo a sua abordagem atual de trabalho de alta qualidade. Enumere exatamente o que pode ser entregue nesse período. A resposta do KeesDijk tem alguns links muito bons para o planejamento em um nível detalhado.
2. Continue com o mesmo estilo de planejamento detalhado para abranger todos os recursos e mostrar como levará 300 horas (ou seja qual for o resultado).

Em seguida, comece a trabalhar e relate regularmente os progressos e, se possível, faça entregas em intervalos regulares. Isso deve dar à gerência confiança em suas habilidades e capacidade de estimativa.

Peça-lhes a base de suas estimativas. É justo discutir as discrepâncias. Despejar testes de unidade é uma economia falsa; o que você não gasta escrevendo testes de unidade, passará em um depurador mais tarde (e mais). Essencialmente, você documentou o fato de planejar testar o trabalho concluído. Eles estão dizendo que você não prova nada . Se você testar usando testes de unidade ou testes ad hoc ao desenvolver o projeto, ainda precisará contabilizar esse tempo. A remoção do tempo alocado para o teste de unidade também remove o tempo alocado para o teste ad hoc.

Conclusão: mantenha suas armas com sua estimativa. Seu histórico mostra que você sabe do que está falando e pode dar uma resposta razoável quanto à base de sua estimativa (suposições, expectativas, desempenho passado, etc.). Parece que sua alta gerência não tem a visibilidade necessária para criar uma estimativa razoável. Eles estão assumindo dias de 8 horas sem interrupções para as reuniões? Eles estão orçando para o teste do sistema em suas estimativas? Como eles criaram o número que é metade do seu, considerando seu histórico?

Eu estimaria que demoraria 300 horas e, se o orçamento for de 150, forneça a opção, será um trabalho urgente de buggy ou atrasado para ser entregue. Quando o projeto estiver concluído e como você prevê, basta dizer a eles que foi o que você pediu.

O que Wally faria?

Existem várias maneiras de interpretar o que a gerência pede, uma é que elas não querem que você entregue dentro do prazo.

Parece absurdo? Sim, mas de que outra forma eles podem saber que você não está superestimando? Não cumpra seus prazos (folga, se necessário), se você escorregar e entregar algo acidentalmente dentro do prazo, certifique-se de parecer realmente cansado, para não dar a impressão de que foi um passeio no parque.

Você está em apuros. Se você seguir as suas armas e quiser continuar com os testes de unidade, e quiser reivindicar as 300 horas, você fará inimigos.

Se você reduzir para 150 horas e realizar testes de unidade de mandril, poderá entregar um produto com defeito mais rapidamente, mas isso causará sofrimento no futuro, com um custo de manutenção mais alto.

De qualquer maneira, você perde.

Ou assim parece.

Veja bem, você não está administrando um laboratório de ciências em uma universidade. Você está fornecendo um serviço de negócios a uma unidade de negócios de uma empresa que presta serviços a clientes em um ecossistema de empresas. Sua empresa pode precisar que seu produto comece a fornecer serviços melhores e mais rápidos e melhores para seus clientes, aumentando assim as receitas necessárias.

Veja bem, o que você precisa é de uma análise de ROI e não possui todos os dados para fazer essa análise. Você tem apenas parte da parte do custo (não conhece os números da folha de pagamento de todos) e certamente não possui as partes da receita, especialmente as projeções de receita.

Sua administração, acredite ou não, é especialista em fazer as projeções de ROI (é o que elas ensinam na escola de negócios) e pode ter executado várias projeções de ROI e sugerir "se agirmos agora, ganharemos muito mais dinheiro ainda com o pagamento triplo pela manutenção do software que os bozos em TI reclamam. "

Então, se você deseja administrar a joint, comece sua própria empresa. Você verá, não é tão fácil.

Em outras palavras: faça o que você mandou. Se a gerência souber o que está fazendo, você estará à frente. Caso contrário, você está sem emprego, com testes de unidade ou não.

Qual é o ROI que você pergunta? Retorno do investimento. É um nome ruim, no entanto. Ele precisa ser um ROTI (Return On Timely Investment), porque o timing é tudo em investimento.