4.2.3 [XP] Simplicidade

4.2.3 Simplicidade

O valor simplicidade é um dos mais sofisticados e importantes da XP. Ele procura sempre manter o projeto o mais simples possível, tornando-o ágil e maleável.

Estudos de 1994 do Standish Group revelam que nas grandes companhias americanas, mesmo entre os poucos (9%) projetos que são entregues dentro do prazo e do orçamento, somente 42% dos requisitos definidos inicialmente são encontrados [8:CHAOS]. Isto revela claramente que investir uma grande quantidade de recursos para definir detalhadamente, no início do projeto, os requisitos de todo o sistema, é um erro.

A simplicidade nos ensina a implementar apenas aquilo que é suficiente para atender as necessidades atuais do cliente. Ou seja, ao codificar uma funcionalidade o desenvolvedor deve se preocupar apenas com os problemas de hoje e deixar os problemas do futuro para o futuro. Não se deve tentar prever o futuro, pois raramente obter-se-á êxito nas previsões.

Fazer um sistema simples o bastante para resolver graciosamente somente os problemas do momento é algo muito difícil que depende muito da comunicação, pois sem ela é impossível obter corretamente os requisitos necessários para o momento atual.

A XP considera essencial obter feedback de todas as partes envolvidas no projeto o mais rapidamente possível e com isso sempre ter a certeza de que se está no rumo correto. A comunicação, embora seja essencial, não é suficiente para garantir feedback rápido. Também é essencial que a equipe compreenda e utilize o valor simplicidade, que antecipa a participação do usuário no sistema, o que torna viável o feedback do cliente para a equipe o quanto antes. É neste sentido que a simplicidade é essencial, pois só assim é possível obter feedback sobre uma ação logo após sua execução e conseqüentemente fazer pequenos ajustes caso estes se tornem necessários.

Simplicidade também evita um erro muito freqüente no desenvolvimento de software, chamado trabalho especulativo.

O trabalho especulativo é aquele que é executado utilizando premissas sobre as quais não se tem total certeza. Ele ocorre quando o desenvolvedor implementa por conta própria uma determinada funcionalidade diante de uma dúvida. Um exemplo ainda mais perigoso de trabalho especulativo é quando o desenvolvedor assume requisitos futuros, mesmo quando no momento atual, estes requisitos não são visíveis ao usuário. Neste caso, o desenvolvedor implementa a funcionalidade de forma “genérica” para que ela possa se adaptar a todas as futuras necessidades do cliente. Em inglês isto é chamado de overengineering e significa criar uma solução excessivamente sofisticada para um dado problema [TELES, 2004].

A simplicidade só faz sentido em um contexto, por isso, a solução simples de ontem pode tornar-se simplista ou complexa à medida que a aplicação evoluir. Neste caso, é essencial recuperar a simplicidade com base no contexto atual.

O principal objetivo da simplicidade é, portanto, evitar o trabalho extra que resulta do desconhecimento ou da precipitação. Implementar uma funcionalidade com mais detalhes que o necessário é especular sobre as necessidades do cliente. Neste caso, somente o feedback do cliente poderá dizer se a parcela especulativa do código é mesmo necessária. Tendo consciência disso, percebemos que é preferível evitar o trabalho especulativo implementando as funcionalidades sempre da forma mais simples possível [TELES, 2004].

 


[ASTELS, 2002]
[BECK, 2002]
[FOWLER, 2004]
[HUNT, 2004]
[IMPROVE IT]
[STANDISH GROUP, 2004]
[TELES, 2004]

\o ‘s,
ViniciusAC.

Anúncios

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