zeluisbraga

Escopo aberto

Posted on: domingo, 10 agosto, 2014

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.

downloadFoi 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.

(este artigo foi escrito por zeluisbraga, e postado no meu blog zeluisbraga . wordpress . com) (this post is authored by zeluisbraga, published on zeluisbraga . wordpress . com) (from Viçosa, MG)

About these ads

5 Respostas to "Escopo aberto"

Boa tarde Prof. Zé Luiz. Parabéns pelo blog (novamente) e pelas recentes publicações (tenho acompanhado de longe). Esta questão de escopo é complicada até fora da área de projetos de sofwtare. Tenho acompanhado alguns de meus alunos em trabalhos de TCC e percebo o impacto que uma mudança tem quando não programada.

Tenho pensado em montar um grupo de estudos sobre processos de desenvolvimento de software para que os alunos passem a ter um mínimo de perspectiva de montar equipes de desenvolvimento (caso contrário irão quebrar a cara logo no começo). Diante disso fiquei imaginando como isso acontece nas empresas. Como tais empresas (sejam de software ou não) gerenciam a inovação (ou pelo menos a novidade ao criar novos produtos) e a obtenção de novos conhecimentos para manterem-se atualizadas. Talvez seja um bom tema para o proximo post. Grande abraço!!

olá, flávio. sua sugestão de postagem já está na fila há algum tempo, vão aparecendo aos poucos. abraço,

É cilada Bino!

Republicou isso em Blog da Rosinhae comentado:
Vale muito a pena a leitura, principalmente pelos meus alunos.
Quando apresento na disciplina de Engenharia de Software os conceitos de Metodologia Pesada e, logo em seguida, apresento os conceitos de Metodologias Ágeis, meus alunos acham que encontraram a fórmula do sucesso: programar, programar e programar sem ter que documentar.
Leiam o post!!!! POR FAVOR, LEIAM! :)

[…] Artigo postado originalmente em zeluisbraga.wordpress.com […]

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

Enter your email address to follow this blog and receive notifications of new posts by email.

Junte-se a 1.215 outros seguidores

Tweets recentes

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 1.215 outros seguidores

%d blogueiros gostam disto: