Friday, July 27, 2007

Mais uma coisa legal do grupo de UML

"É muito comum o pessoal classificar como retrabalho alguns refinamentos comuns. É interessante ressaltar que a maneira como um software é produzido necessita de um processo empírico por ser de natureza criativa. Antes de prosseguir, precisa estar claro que o desenvolvimento de software é uma atividade criativa, se vcs não concordam podemos discutir aqui.

Determinados processos são prescritivos, isto é, possuem pontos observáveis que a cada passo podem ser verificáveis como válidos. A construção de uma ponte segue um processo prescritivo. Uma linha de montagem de um produto é um processo prescritivo. A forma que um cartório funciona é um processo prescritivo. Uma característica importante dos processos prescritivos é que se caso o produto final não atenda o nível de qualidade que você espera o custo é muito alto para reconstruir esse produto novamente ou para reparar a falha. Como exemplo, se um carro ao final da linha de produção foi montado de maneira errada é praticamente impossível recolocá-lo na linha para que seja produzido da maneira certa. É mais barato jogar o carro no lixo e corrigir a linha de produção.

O software não possui passos intermediários que possam ser verificáveis como válidos. Quando você captura requisitos você não tem certeza que eles solucionarão o negócio, quando você elege uma arquitetura não tem certeza se ela será suficiente, quando você codifica soma-se a essas incertezas aspectos técnicos e também com relação ao futuro. Nós só conseguimos reduzir essa incerteza quando o usuário olha a aplicação. Por conta disso, chegamos à declaração abaixo:

DESENVOLVIMENTO DE SOFTWARE = GERENCIAMENTO DE INCERTEZA

Com relação a retrabalhos, imagine que você capturou requisitos com relação a tela de pedidos e com a entidade de pedidos. Você modelou e implementou de acordo com o que você definiu como objetivos da sua iteração. Você mostra a tela para o usuário, ele gostou do que viu, mas ainda falta algumas coisas que podem fazer parte da próxima iteração. O fato de você ter que mexer na tela novamente ou na entidade não significa
necessariamente retrabalho e sim refinamentos. O que mostra o andamento do projeto é o cumprimento desses objetivos e não o número de telas implementadas. Se depois, na 20 iteração, algum conceito de negócio necessite de mais ajustes na entidade pedido também não será retrabalho, simplesmente é o software amadurecendo. Não considero ter que mexer em coisas já implementadas como retrabalho, principalmente se o processo é
ágil. Nós trabalhamos dessa maneira porque o PRODUTO SOFTWARE nos permite que o tratemos dessa forma. O custo para ajustar os conceitos no SOFTWARE não segue o padrão de um produto de processo prescritivo. A tecnologia nos permite construir o software dessa maneira. Isso nos leva a outro conceito:

SOFTWARE = IDÉIA

Idéias são coisas que amadurecem. É bem raro uma maçã cair na sua cabeça e de uma hora para outra você ter a idéia completa de como resolver com um software o caos aéreo no Brasil. O software assim como uma campanha publicitária, ou uma ação de marketing, ou um novo produto, é algo que floresce com a participação de muitas pessoas e chega a maturidade em constante inspeção e adaptação."

RODRIGO YOSHIMA