Dois direitos do desenvolvimento de software

Existem dois desafios no desenvolvimento de software: construir a coisa certa e construir certo a coisa (sim, eu amo aliteração).

Construir a coisa certa

A construção de software que os usuários querem é difícil, porque a maioria das pessoas não sabe o que quer.

Você pode se surpreender ao descobrir que as pessoas não sabem o que querem, mas é verdade. E, geralmente, não tem nada a ver com o quão espertas ou atentas elas são. Certa vez, escrevi um programa para meu uso pessoal. A primeira versão era pouco utilizável e eu tive que praticamente reescrevê-lo antes que ele atendesse às minhas necessidades. Em outras palavras, embora eu fosse o cliente, o BA (Analista de Negócios), o arquiteto, o engenheiro, o QA (Quality Assurance), e “todos os outros papéis concebíveis em um projeto”, ele fracassou.

Como isso é possível? Bem, pode ser que eu não seja um bom BA/Arquiteto/Dev/ etc. (este último é provavelmente verdade). Ou pode ser que eu só não soubesse do que eu precisava. A imagem na minha cabeça de “A coisa que eu queria” estava muito embaçada numa primeira instância. Foi necessário algo concreto para refiná-la.

Há duas maneiras de lidar com essa realidade. Uma é fazer com que as pessoas pensem muito, mas muito mesmo, sobre isso com antecedência, apenas para se certificarem de que elas pensaram muito bem sobre o assunto. Acima de tudo, crie um processo muito desagradável, pedindo alterações posteriores. Outra maneira é fazer um pouco, mostrar a eles, permitir que façam alterações, e fazer isso repetidas vezes, até que eles tenham o que querem.

Para recapitular, suas opções são: ou combater a realidade ou aceitá-la e trabalhar com ela. Curiosamente, para as primeiras décadas de desenvolvimento de software, nós insistíamos em usar a primeira opção. Muitos processos com títulos extravagantes e impressionantes conjuntos de templates de documentos surgiram para nos ajudar a administrar as exigências. Passamos semanas e meses escrevendo, em mínimos detalhes, todas as coisas que o sistema precisa fazer. Então criamos formas e processos para gerenciar as mudanças. Isso é conhecido como Cascata.

Por mais divertido que pareça, não funcionou. Projetos falharam regular e espetacularmente em todo lugar (eu estava em um projeto, uma vez, que foi cancelado após um investimento de 2 anos/8 dígitos). Finalmente, alguns caras inteligentes tiveram uma visão de que a luta contra a realidade é difícil, e por isso decidiram seguir com o Plano B. Eles propuseram construir o produto de forma incremental. Fazer um pouco, parar, verificar, ajustar, e assim por diante. Essa ideia maluca decolou de uma forma enorme e algumas pessoas agora desenvolvem o software assim. Chama-se agile.

Construir certo a coisa

Imagine se você pedir a alguém para o construir para você uma casa de 3 andares, 4 quartos, com uma garagem para 2 carros, uma casa de cachorro, e um alimentador de pássaro. Imagine então que eles fizeram exatamente isso, e que tudo está ótimo. Você está feliz? Claro que você está! Você só tem uma casa enorme, com animais de estimação felizes e animais selvagens. Mas e se os encanamento vazar? Ou o curto-circuito elétrico continuar? Ou se eles tiverem deixado um buraco no sótão? Ainda estaria feliz?

Construir software corretamente é fazê-lo para que seja sustentável. É preciso esforço e conhecimento para mantê-lo limpo, verificável, compreensível e facilmente mutável. É um problema difícil, mas existem muitas práticas de engenharia para ajudar: Integração Contínua, Test Driven Development, Testes Automatizados, Programação em Par, Design Patterns, e assim por diante. É necessário um compromisso real para acompanhá-lo, mas você acaba tendo um software que não requer um ato de Deus para poder modificá-lo.

São necessários dois…

OK, então neste momento você deve estar pensando em uma das duas: ou “Uau, esse tipo de pensamento inovador juntamente com escrita de alto nível são as razões de eu ler o que você escreve” ou “Obrigado, Capitão Óbvio, e parabéns por se tornar o milionésimo geek a escrever sobre isso. Mal posso esperar para o seu próximo artigo sobre o azul do céu. Idiota”. Ou, colocando de outra forma,”Eu já sei tudo isso, qual é o seu objetivo?”

Bem, meu ponto é este: Se a sua equipe parece ser incapaz de cumprir um prazo ou de entregar um bom produto para o cliente, entenda o porquê disso antes de tentar corrigi-lo. Isso pode parecer óbvio, mas não é. É muito tentador introduzir um processo ágil (“nós estamos fazendo agora Scrum”) e achar que tudo será ótimo. Pode ser, mas, novamente, pode não ser. Se você está construindo manualmente e não tem cobertura de código, o Scrum não vai consertar isso. E, se o desenvolvimento demorar 6 meses antes que os usuários vejam alguma coisa, nenhuma quantidade de Pairing ou TDD irá ajudar a oferecer o que os usuários realmente querem.

?

Texto original disponível em http://tatiyants.com/two-rights-of-software-development/