Como lidar com as mudanças nos requisitos de software após o início da implementação.

Alfredo Pinto Molina Blocked Desbloquear Seguir Seguindo 9 de janeiro

Há apenas uma constante no desenvolvimento de software, as coisas vão mudar. Esta é uma lei imutável. O primeiro passo para lidar adequadamente com a “mudança” é aceitar esse fato. É tão importante que, mesmo nos diretores do Agile Manifiesto, você possa ler: “Bem-vindos à mudança de requisitos, mesmo no desenvolvimento tardio”. Então, eles não estão indo embora, mas isso não significa que você não pode fazer nada sobre isso.

Vamos abordar o motivo pelo qual isso acontece primeiro, porque as pessoas que não aprendem com a história estão condenadas a repeti-la, então, como lidar com elas de uma maneira que não crie dores de cabeça.

Para a mente humana, é muito natural que, quando é apresentado a um problema, surja uma solução. Os gerentes inexperientes implementam o controle sobre seus departamentos por essa abordagem, assim que algo surge, eles vão dizer o que fazer, eles descobrem tudo imediatamente, isso é chamada de gerenciamento reativo ou como eu gosto de chamá-lo de gerenciamento Cowboy já que tudo é improvisado. Não é possível para nenhum ser humano prever quais situações seremos apresentadas, então esse estilo de gerenciamento vem naturalmente. As pessoas que trabalham em hotéis contarão histórias estranhas sobre como elas são sempre surpreendidas pelo tipo de coisas que acontecem nos hotéis, independentemente de quantos anos você tenha trabalhado nessa indústria.

Então, não é possível ver o futuro, mas a mente também é a maior máquina detectora de padrões do universo, ela pode encontrar padrões mesmo em lugares onde não há. Com o tempo você vai começar a perceber coisas que estão se repetindo, digamos que podemos ver um caixa sendo pago por um cliente com dinheiro ou cartão de crédito (parece óbvio e idiota, mas mantenha seus cavalos). Não podemos ver o futuro, mas podemos ver o padrão, então se um novo caixa é contratado, podemos deixá-lo descobrir como lidar com isso sozinho quando a situação ocorre (gerenciamento reativo) ou podemos criar um pequeno documento e um treinamento para deixe-o saber com antecedência o que fazer (gerenciamento proativo). É assim que nascem os processos.

Os processos são a pedra fundamental de todos os projetos de software corporativo. Os desenvolvedores de software criam ferramentas para permitir que os usuários façam seu trabalho de maneira mais fácil e rápida, baseando-se nesses processos, já que nenhum computador no mundo tem a capacidade de criar uma solução de situações imprevisíveis (pelo menos no momento em que isso for escrito). Mas o responsável por esses processos a serem executados adequadamente é a pessoa que paga pelo desenvolvimento do software, não os desenvolvedores, gerentes de projeto, líderes de equipe e até mesmo os proprietários de produtos que têm a responsabilidade de documentar e gerenciar os processos do cliente para o projeto.

Isto é assim porque, por exemplo, se estamos criando um software para contadores, ninguém na equipe de desenvolvimento será um especialista no assunto para saber como o software deve lidar com a contabilidade, então é um absurdo responsabilizar Qualquer equipe de desenvolvimento para os processos, eles são responsáveis apenas pela parte técnica e para implementar adequadamente os processos (também chamados de regras de negócios). Há alguns casos em que os desenvolvedores criaram software para uma indústria durante muitos anos e ganharam muita experiência nessa indústria, mas esse é o caso para o escopo disso.

Quando alguém escreve um novo processo, dizemos que é imaturo, porque abordamos apenas os cenários mais comuns. Em seguida, o caixa recebe novas situações: um cliente quer pagar uma parte da conta com dinheiro e a outra parte com o cartão de crédito, muito óbvio, mas o nosso software não pode lidar com isso adequadamente, por isso estamos com problemas e precisamos para mudar o processo, para que funcione corretamente. Então a loja quer aceitar cupons, então nós precisamos aceitar pagamentos mistos com cupons, dinheiro, cartão de crédito, então o cliente quer usar mais de um cartão de crédito e então uma nova lei é aprovada, e precisamos implementar o que a lei dita (o último acontece muito no México com as faturas).

Assim, as coisas podem complicar-se facilmente a partir de um processo aparentemente fácil, não podem ser previstas, previstas ou estarem preparadas. Quanto mais situações um processo puder lidar com o amadurecimento que ele se tornou e normalmente eu vi que isso leva pelo menos um ano, qualquer projeto de software é pelo menos um ano de projeto, mesmo que seja implementado em 3 meses. Ainda assim, mesmo com um alto nível de maturidade, algo imprevisível surgirá e o processo não será capaz de lidar, e seções do processo também podem se tornar obsoletas e tiveram que ser removidas.

Então, eu espero que agora esteja claro que não ter mudanças durante o desenvolvimento do software e depois é completamente fora da tabela. Mas isso não significa que não podemos fazer nada sobre isso, significa que precisamos integrar a forma de lidar com a mudança em nosso trabalho.

Rookie Projects Tenda de gerentes para fazer planos de projeto como nada vai estar errado durante o projeto e o plano será executado sem falhas. Sabe-se que os navios estão fora do curso a maior parte do tempo durante uma viagem, mas ainda assim conseguem chegar ao seu destino. Como eles fazem isso? Eles fazem correções durante a viagem. Esse é o primeiro e maior segredo para lidar com mudanças. Você deve ter um processo para lidar com eles adequadamente.

Há duas maneiras de lidar com mudanças em seus próprios processos de trabalho, também conhecidas como metodologias e arquitetura de software, a parte técnica. Para a parte técnica, eu já escrevo aqui: Como você escreve código que é extensível e sustentável quando você não sabe quais novos recursos e mudanças serão exigidos no futuro?

Em metodologias formais, a primeira fase do desenvolvimento de software é a Análise e, depois de feita, produzirá todos os documentos necessários para o projeto. Se alguma coisa muda após a fase de análise, houve processo de chamada "solicitação de mudança" para lidar com essas situações. Muita literatura tem escrito sobre isso, mas o problema com essa abordagem é que é muito burocrático e demorado. Além disso, muitas pessoas não são devidamente treinadas e mal executam essa metodologia, o que as leva a acreditar que isso não funciona, mas acontece. Para grandes projetos é o caminho para o trabalho, mas para projetos pequenos ou médios é um exagero, não vou recomendá-lo nesses projetos.

Em metodologias ágeis simplifica-se muito tudo. O proprietário de um produto criará histórias a partir dos requisitos imutáveis. Se você estiver codificando um módulo e durante o Teste de Aceitação do Usuário for encontrado que a história está incompleta ou errada, desde que o desenvolvedor faça tudo o que foi especificado na história, a história é encerrada e marcada como concluída. criado para lidar com as alterações. Para projetos pequenos e médios isso funciona como um encanto, mas em grandes projetos eu vi que não é a melhor abordagem já que a quantidade de mudanças aumenta exponencialmente com o tamanho do projeto, o que leva a um refatorador de software para cada nova história . Quanto maior o projeto fica, mais difícil é fazer os refatoradores.

A única coisa que eu não gosto sobre as metodologias ágeis é que eles não dão muita ênfase na análise de processos e no design técnico (também conhecido como arquitetura de software), e isso é bom se o cliente tiver processos maduros documentados e os projetos forem pequeno a médio, mas para clientes que seus negócios são baseados em gerenciamento reativo o projeto será um fracasso certo e grandes projetos sofrerão muito com os refatoradores de código.

Há coisas que levam a muitas mudanças fora do escopo das metodologias. Um é o cliente tentando implementar melhorias em seus processos de trabalho, porque agora estamos criando um software para eles. Geralmente esses projetos falham. Criar um novo processo não é uma tarefa fácil, como discutimos. O processo tende a ficar complicado muito fácil. A implementação de processos de trabalho no software é difícil e cara, tentar fazer melhorias rapidamente fará com que você amadureça esses processos ao tentar implementar o software na produção. Não ter essa visão levará o cliente a ter a falsa impressão de que os desenvolvedores estão fazendo um trabalho ruim. Eu geralmente não deixo um cliente tentar melhorar os processos, eu sempre digo: Vamos primeiro fazer o software funcionar com os processos atuais que você tem, depois de implementá-lo, então melhoramos tudo o que você quer.

Os clientes que usam o gerenciamento reativo ao longo do tempo começam a ter muitos problemas para controlar seus departamentos. É muito comum pensar erroneamente que a compra de um software magicamente resolverá o problema em vez de implementar processos. Você acaba não como um desenvolvedor, mas como um consultor de processos que não é seu trabalho e sofrerá muito tentando acertar as coisas. É como atirar no cego para um alvo. Para esses casos, eu recomendo esta técnica Quando iniciar um projeto pelo front end. – Alfredo Pinto Molina – Medium

Além disso, como você pode ver, você pode ter centenas ou milhares de cenários diferentes para um determinado processo. Você e seu cliente precisam ser muito espertos nisso, nem todos os cenários precisam necessariamente ser implementados ou valer a pena. Depois de comprar um item na Amazon, quando preencho o endereço, cometo um erro e coloco um número de rua errado. Eu me comunico com o fornecedor para corrigir o erro antes que o item seja enviado para que ele não seja entregue no lugar errado. Nesse caso, o fornecedor me instrui que o pedido será cancelado, a cobrança do cartão de crédito será reembolsada e eu precisarei recomeçar. Para mim foi como: É apenas uma simples correção, por que cancelar toda a ordem ao invés de apenas corrigir o endereço já que o item não foi enviado. Bem, para que não analise por um momento. Lembre-se de que todo cenário deve ser codificado, e a codificação custa muito dinheiro. Se esse cenário só acontecer muito raramente, pode não valer o dinheiro e o tempo investido na codificação para lidar com essa situação, será mais barato cancelar o pedido e esperar que o cliente compre novamente o item (o que fiz e o que não fiz) Isso nos mostra que o cliente e a equipe de desenvolvedores precisam ser muito inteligentes em quais cenários vale a pena implementar para ter um retorno de investimento (escolha suas batalhas). É melhor e mais barato simplificar o processo do que tentar torná-lo robusto.

Assim, mesmo que ambas as metodologias tenham seus prós e contras, é preciso ver que ter muitas mudanças não é sobre metodologias, mas sim sobre três coisas: requisitos de baixa qualidade, planejamento de projeto ruim e execução de planos inadequada. As mudanças vão acontecer, não importa o quê, mas você pode impactar a quantidade delas durante o projeto, reunindo requisitos de qualidade. Portanto, é muito melhor evitar mudanças durante a análise do projeto do que ser muito bom na solução de mudanças durante o desenvolvimento do software.

Eu sempre recomendo esses dois livros que abordam os requisitos de forma mais ampla: Requisitos de Software (Boas Práticas de Desenvolvedor) 3, Karl Wiegers, Joy Beatty, eBook – Amazon.com e o livro Requisitos de Exploração: Qualidade Antes do Design: Donald C. Gause, Gerald M Weinberg: 9780932633132: Amazon.com: Livros

Foto por rawpixel no Unsplash