Que documento / artefato deve me alertar quando um requisito antigo muda o escopo de um novo?

5

Eu desenvolvi um aplicativo de software há um ano, entreguei com uma documentação simples.

Por exemplo, ele tem um sistema de login especial e complicado como requisito.

Agora o cliente liga e pede para eu alterar o aplicativo para dar suporte a um novo tipo de usuário , então reviso (rapidamente) as tabelas, exibições e código que preciso alterar para entregar o novo requisitos suportam um novo tipo de usuários e fornecem um tempo estimado, mas esqueci completamente que preciso refatorar o sistema de login especial e complicado .

Este é um grande erro, porque o tempo que gastarei no refator do sistema de login especial e complicado não será pago.

Quais erros cometi? e como posso evitá-lo no futuro? Uma matriz de rastreabilidade me dá relações entre casos de teste e requisitos, mas eu preciso do controle de requisitos antigos em relação aos novos.

    
por Erick Asto Oblitas 25.08.2015 / 14:37
fonte

2 respostas

4

O contrato é importante

This is a big mistake because the time that I will spend [...] will not be paid

Na verdade, o grande erro é que o seu contrato possibilita que você gaste seu tempo trabalhando de graça. Não importa se você está resolvendo um bug ou aprendendo uma tecnologia necessária para um novo projeto: o cliente tem que pagar pelo tempo que você gasta.

Você não deve trabalhar de graça. Isso é tão simples quanto isso. Isso faz você se sentir mal, e incentiva seu cliente a pensar em você como um cara que trabalha de graça de qualquer maneira, e para quem não precisa ser particularmente respeitado, ou pago, afinal. Assim que seu cliente souber que você gasta uma hora trabalhando de graça, sua relação está estragada.

É também por isso que é essencial ter um contrato escrito por um advogado especializado em contratos de desenvolvimento de software.

Estimativas técnicas

What errors I did, and how can I avoid it in the future.

Tecnicamente falando, seu erro foi dar uma estimativa muito rapidamente. Você pode ter gasto mais algumas horas estudando o impacto e, provavelmente, encontrar a relação entre os dados e a autenticação.

Mas tais erros acontecem de qualquer maneira, por isso não é uma grande falha do ponto de vista técnico.

Isso não é muito diferente dos casos em que você fornece uma estimativa de duas semanas para uma tarefa e, uma semana depois de iniciar a tarefa, você acha que ela requer muito mais trabalho. Então, você simplesmente envia para as partes interessadas (seria seu gerente ou seu cliente) a estimativa reajustada que leva em conta as coisas que você descobriu enquanto isso.

Você pode ter cometido um erro ao fornecer uma estimativa muito precisa. Se você disser que uma mudança levará “oitenta horas”, isso não é a mesma coisa que “dez dias”, e nem a mesma coisa que “duas semanas”. Além disso, as estimativas são frequentemente representadas como um intervalo ou contêm uma sugestão sobre a precisão:

The task will take from 4 to 9 days.

ou:

The task will take 16 days ± 4 days.

Isso torna o reajuste progressivo da estimativa mais intuitivo.

Outro aspecto importante é que você deve ser capaz de dizer não. Isso se aplica especificamente a esses dois tipos de perguntas:

“Do you know how long this task will take?”

Se você não sabe quanto tempo a tarefa levará, não diga "Três semanas" apenas para se livrar da pessoa.

“Can you make an effort to deliver it faster?”

Se você responder "Sim", significa que sua última estimativa foi errada (nesse caso, por que você faria estimativas erradas em primeiro lugar?), ou que você sabe como ser mais produtivo, mas não Não faça isso a menos que seja solicitado especificamente, o que também não parece muito profissional.

Tem tudo a ver com alavancagem

Mas, novamente, o mais importante é como você interage com seu cliente, o que se resume a duas coisas: o que o contrato diz e qual é a sua alavancagem.

Por exemplo, compare esta mensagem:

On February 7th, I sent you an estimate of 8 days ± 3 days for the task of migrating the bottom menu to the new data source. It appears that the task also requires to make changes in the top menu, since both partially rely on the same code. Given those new elements, the updated estimate is 11 days ± 2 days.

com este:

On February 7th, I sent you an estimate of 8 days ± 3 days for the task of migrating the bottom menu to the new data source. It appears that the task is much more difficult than I thought, so I'm not sure I'll be able to release the changes on time. Can you, please, accord me three additional days for this task?

O segundo é uma droga. Isso mostra que o desenvolvedor não tem influência alguma. Não dá nenhuma estimativa, mas apenas implora por tempo extra. Parece que o desenvolvedor errou a estimativa original e se sente mal com isso. A primeira mensagem é puramente informal: aqui está uma estimativa, não ligo para o que você pensa e não preciso da sua aprovação, pois nosso contrato não exige sua aprovação neste caso. Minha estimativa inicial estava correta, e a última leva em conta informações adicionais. Nada mais.

    
por 25.08.2015 / 14:59
fonte
-1

This is a big mistake because the time that I will spend in the refactor of the special and complicated login system will not be paid.

Há uma grande bandeira vermelha mostrando o que deu errado. O problema foi incorporado neste projeto antes que qualquer alteração fosse solicitada pelo cliente, eles estavam lá antes mesmo que o código fosse escrito ...

Autenticação e permissões são problemas muito conhecidos (e resolvidos) até mesmo para conjuntos de requisitos excepcionalmente complexos (autenticação de dois fatores, bloqueio de tempo, restrições de localização, por exemplo).

O próximo passo é evitar recorrências ...

Você pode refletir sobre o processo de desenvolvimento original e examinar seus documentos / processos de projeto para entender os fatores que levaram a esses componentes serem bem acoplados e sinais de alerta a serem procurados. Geralmente, quando uma função comum é considerada "especial", é uma boa indicação de que a situação não foi totalmente entendida, por exemplo.

Em vez de considerar essa situação como um 'custo', aceite como um alerta que você ou quem trabalhou no projeto pode se beneficiar de algum desenvolvimento profissional para entender melhor o processo de desenvolvimento - é algo que os desenvolvedores fazem de todo tempo e usando esse conhecimento para se certificar de que os projetos futuros são mais passíveis de extensão e que o código é mais fácil de testar / corrigir. Isso lhe deu a chance de produzir um código melhor no futuro.

Como pontos de partida, o Princípio de Responsabilidade Única (SRP) e Separação de Preocupações (SoC) devem manter o código não relacionado separado e significar que você não deve precisar de matrizes complicadas de dependências no futuro.

Pegue alguns livros sobre qualidade de código e gaste algum tempo neles, não será desperdiçado, e alguns dias de tempo extra de desenvolvimento é barato comparado a alguns projetos que perdem meses devido a questões que poderiam ter sido evitadas.

    
por 25.08.2015 / 16:43
fonte