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]
Leave a Comment