28 maio 2008

Lean: Decida o mais tarde possível!

Decida o mais tarde possível
Tudo bem, pode soar completamente arriscada a afirmação do título, principalmente com a nossa má fama de deixar tudo para a última hora...

Desenvolvimento de software é uma atividade de problem-solving, e diferentemente dos demais produtos, espera-se que sistemas de computador tenham atualizações constantes. O principal fator para isso é que utilizamos softwares para resolver problemas complexos, principalmente quando o nível de incerteza é alto.

Complexidade pode ser tratada de duas formas: através de previsibilidade ou adaptabilidade... como dificilmente conseguiremos prever o comportamento de sistemas complexos, a adaptabilidade é a melhor opção.

No post anterior, discuti sobre uma forma de tratar problemas quando a incerteza é alta: buscando informação e feedback!

Para confirmar a afirmação:
O custo do ciclo de vida de um software atribuído à manutenção é de 40 a 90% do custo total de produção de um software, segundo Kajko-Mattsson.


Isto quer dizer que, logo após o primeiro release de um sistema, com certeza ele precisará de ajustes para se adequar às necessidades dos problemas que ele se propos a resolver...

Este fato que nos ajuda a desmistificar completamente a utilização de um modelo waterfall, uma vez que todo o trabalho em definição de um Big Design Up-front trará muitos problemas na hora de realizar alterações. A curva abaixo mostra o custo da mudança num modelo assim:
Cost of Change
Software Engineering Economics


E como resolvemos isso?



Bem, se para tomar melhores decisões é preciso conhecer melhor o problema e ter feedback real sobre a interação de sua aplicação com o ambiente de produção, podemos assumir que:

  • Quanto mais conhecimento melhor

  • Quanto mais opções para solucionar um mesmo problema, melhor podemos encontrar a ideal

  • Conhecendo várias possibilidades de atuação, será possível encontrar riscos ocultos

  • Quanto melhor a solução para um problema, maior será a satisfação de seu cliente



Os itens acima estão no cerne dos processos adaptativos de software, e é a forma que optamos em construir nossos sistemas em se tratando de Desenvolvimento Ágil.

Como requisitos podem ser apenas parcialmente compreendidos para serem produzidos numa equipe Ágil, é possível que, à medida que a solução emerge, se possa compreender melhor o domínio do problema através de incursões rápidas e sistemáticas ao ambiente real de trabalho.

Isto implica em possuir requisitos de negócio mutáveis, que possam ser adaptados à medida que o sistema, e a compreensão do problema evoluí. O cliente, neste ambiente, possuí papel importantíssimo para determinar em que momento a solução tornou-se suficiente.

Trabalhe as incertezas e dúvidas de seus clientes de forma a não enrijecer o seu sistema. Somente tome decisões cruciais quando houver fatos suficientes para apoiar sua escolha, caso contrário você tem grande risco de ampliar seus gastos com manutenção de sistemas...


Continua no próximo capítulo

Nenhum comentário:

Postar um comentário