Escopo aberto

No início, tudo é novidade, todo mundo quer adotar novidades achando que são milagrosas, e tudo vai indo meio na mágica, dando a impressão de que houve um pulo do inferno ao paraíso, como se isso fosse possível sem passar pelos estágios intermediários. Até que a poeira baixe, os conceitos são mais bem entendidos, e se comece a perceber as falhas de entendimento e de concepção, e ai é o corre-corre para corrigir o que puder ser corrigido.

Foi assim com os métodos Ágeis, quando chegaram ao mercado por aqui. Há vários casos de adoção errada, um deles contado por um dos lançadores da eXtreme Programming (Kent Beck?): estava numa conferência, auditório cheio, sentou-se ao lado de um rapaz interessadissimo nas palestras sobre agilidade, e lá pelas tantas, o rapaz disse a ele que na empresa dele, tinham causado uma revolução total, tinham adotado métodos Ágeis completamente, e tinham melhorado demais a produtividade da equipe. Ele, curioso para conhecer mais um caso, perguntou o que de fato tinha feito tanta diferença assim, e o rapaz disse que não faziam mais documentação nenhuma, tinham eliminado  as enormes perdas de tempo com documentação, e agora o trabalho deles estava muito mais “ágil”! E por aqui também tivemos um caso semelhante em uma microempresa, adotaram o mesmo princípio e caíram no mesmo erro e ainda saíram criticando a Engenharia de Software “tradicional” e pesada, falando isso publicamente. Um belo dia, me encontrei com um colaborador recém-contratado dessa empresa, que me disse que ele tinha sido contratado para fazer toda a documentação do software que tinha sido produzido sem documentação, porque ninguém conseguia dar manutenção no mesmo, a equipe original já tinha se dispersado. O preço do erro foi muito alto, quase quebrou a empresa. Fácil de prever, não?  A lição que fica desses causos e de vários outros, é que antes de mais nada, tudo deve ser muito bem entendido para não entrar em roubada e ir pelo caminho errado.

Mas não é que recentemente, topei novamente com uma furada de conceito sem tamanho, relacionada com a ideia de Escopo Aberto? Uma furada grave, que estava literalmente jogando uma microempresa num buraco sem tamanho. No Manifesto Ágil, um dos preceitos é “Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.” Tomado ao pé da letra, e adotado sem entender direito o que significa, e quais seus impactos no desenvolvimento de software, esse preceito levou empresas a aceitarem mudanças de requisitos sempre, em qualquer circunstância, mesmo que essas mudanças levassem a mudanças no Escopo do projeto! E é ai onde mora o perigo! Aceitar mudanças, no contexto ágil, não significa sair mudando tudo a qualquer momento, sem uma análise prévia. E muito menos ficar aceitando mudança no escopo, o que pode significar um projeto sem fim! O correto é ter uma regra clara e informada ao cliente no início do projeto: mudanças de requisitos serão inicialmente acatadas, mas passarão por um processo de Solicitação de Mudança, serão conduzidas análises de viabilidade técnica e financeira, de impactos na estrutura do projeto, de impacto no Escopo original, e uma avaliação de custo e prazo da alteração será feita cuidadosamente. Dai em diante, deve acontecer uma fase de negociação com o cliente, e tudo depende do contexto em que cada empresa está inserida. Por exemplo, alterações simples e de pouco impacto no custo e no cronograma, podem ser aceitas e implementadas sem problemas. Já alterações maiores, com grande impacto em custo e cronograma, não podem ser aceitas imediatamente, pois envolvem custos para a empresa, impactos em outros requisitos que a análise da cadeia de dependências funcionais e de rastreabilidade entre requisitos vai indicar. Mais grave ainda, se envolverem mudanças no Escopo original do projeto. O risco enorme está nesses casos, que se não forem bem entendidos e bem negociados, podem levar a empresa para o buraco. Não é possivel sobreviver em um ambiente tão maluco assim, não há cronograma ou planejamento que resistam.

Empresas com algum nível de maturidade de mercado, que adotem pelo menos boas práticas para o desenvolvimento de software, certamente seguem algum processo organizado para desenvolvimento, um conjunto básico de artefatos a serem produzidos, talvez um processo ágil de gerência de desenvolvimento baseado em Scrum (por exemplo), e gerenciam requisitos adequadamente. Esse é o meu desafio atual: levar boas práticas customizadas especificamente para microempresas desenvolvedoras de software, cada caso exigindo uma customização única, sem padrões fixos.

Artigo postado originalmente em zeluisbraga.wordpress.com

[Crédito da Imagem: Escopo Aberto – ShutterStock]