Construção é projeto

abril 29, 2008

Escrevi uma tradução de um fragmento do livro “Software Project Secrets: Why Software Projects Fail”. Este trecho retrata bem a má interpretação que é feita do processo de desenvolvimento de software.

Construção é projeto

A construção de estradas consiste em uma sequência de fases bem definidas. O primeiro passo é planejar e projetar, o que resulta em um conjunto de planos e projetos (blueprints) que podem ser assinados. Uma vez que essas tarefas sejam concluídas a construção pode começar. A fase de construção consiste principalmente de tarefas bem definidas e repetitivas que podem ser executadas por empregados menos qualificados.
Ao contrário, o desenvolvimento de software é um processo de pesquisa, portanto em nenhum momento pode-se ter planos definitivos. Quanto mais definitivo tenta-se fazer os planos, mais falhos eles serão, e mais trabalho se terá ao revisá-los para que cumpram as mudanças de circunstâncias. Como a forma do sistema fica incrementalmente mais clara durante o curso do projeto, seu projeto (design) deve ser revisado constantemente. Reprojetar (redesign) a solução completamente de tempos em tempos pode ser custoso e desnecessário, portanto devemos pensar o projeto como um processo de design constante.
Sabemos que o trabalho repetitivo no desenvolvimento de software é rapidamente automatizado. Não existe nenhuma tarefa repetitiva a definir. Mas se as tarefas não são repetitivas, definí-las exaustivamente se torna um processo muito custoso em tempo. Ganha-se muito pouco definindo as tarefas dessa maneira. Software é abstrato, portanto definir as tarefas da construção completamente é equivalente a realizar o trabalho, pois existem ferrametas automatizadas que conseguem transformar estas definições em código.
Se as tarefas não podem ser bem definidas, então não podemos separar claramente as fases de design (projeto) e construção. Aliás, não existe fase de construção; o que existe é design (projeto) em escalas cada vez menores (níveis cada vez mais baixos). Isso significa que não podemos facilmente categorizar as pessoas nos papéis de arquitetos, projetistas (designers), programadores ou analistas. Estes papéis se sobrepoem. Todos os desenvolvedores têm o mesmo tipo de tarefas a fazer, apesar de uns terem mais responsabilidades que outros.
Quando um desenvolvedor cria uma nova funcionalidade num pedaço de software, a sua tarefa é simplesmente responder a seguinte pergunta “Essa funcionalidade irá funcionar exatamente como?”. Ele adiciona um conjunto de instruções ao código fonte que definem cada detalhe de como a funcionalidade funcionará. Porém, cada detalhe é uma decisão de projeto. Por exemplo, um fragmento de texto pode ser armazenado em um objeto imutável para uma maior eficiência, ou em um objeto mutável para maior flexibilidade. A escolha de uma dessas opções depende de como o texto será utilizado. É uma decisão bem significante.
Programar é mais do que apenas escrever código. Cada passo requer que o desenvolvedor analise uma parte do problema e projete uma parte da solução.

NOTA: Diferentemente de outros produtos, software não é construído, é projetado até a sua existência.

Acho que esse é um dos pontos em que as metodologias ágeis acertam e o RUP e os processos tradicionais falham. É um erro absurdo tratar a construção como uma tarefa repetitiva (tradução de diagramas para código fonte) que pode ser executada por empregados mais baratos (codificadores, programadores).
Como escutei lá no FISL, o movimento ágil é legal e funciona porque foi feito por programador para programador. É coisa de nerd mesmo!

Anúncios

Processos e confiança

abril 11, 2008

O processo de desenvolvimento de sw reflete totalmente a maneira como a empresa é administrada e como esta se relaciona com as pessoas.
Achei um artigo que compara alguns aspectos dos processos baseados no CMMI com os processos ágeis. Achei muito interessante a discussão sobre confiança.

The heart of the conversation was on the perception that if a model forces us to write something down then we are not trusted (the more we write stuff down, the less we trust one another).

Me parece ser bem adequada a colocação do autor, uma vez que um dos objetivos de toda a documentação que o CMMI impõe é a independência da empresa em relação às pessoas. Esse objetivo reflete de maneira muito clara a falta de confiança nas pessoas.