Matheus Tardivo

Thinking and talking about software development

Posts Tagged ‘programming’

Fábricas de… software?

Posted by Matheus Tardivo em janeiro 16, 2008

É impressionante ver que em pleno ano de 2008 existem pessoas que ainda acreditam em fábricas de software. Geralmente, estas pessoas tendem a permanecer alheias as novas metodologias – sei que o termo “novas” foi um pouco forte, afinal, pra ter uma idéia, o artigo “The New Methodology” de Martin Fowler foi escrito no ano de 2000.

Fábricas de software sugerem que os desenvolvedores são apenas recursos que executam tarefas manuais, determinísticas e altamente especializadas. Isso funciona bem para carros, sapatos, mas não para software. A explicação para isso pode se tornar extensa e gera várias discussões, mas, no meu ponto de vista, é algo simples de entender: desenvolver software é essencialmente um trabalho de criação, que se assemelha mais a pintar um quadro ou escrever um livro.

Tentar tornar o trabalho de desenvolvimento de software altamente especializado e determinístico NÃO FUNCIONA!

A especialização é uma teoria que surgiu na revolução industrial e funciona muito bem para o trabalho manual. Nela cada recurso executa uma pequena parte de um trabalho, muito especifico – como apertar parafusos. Neste caso, o recurso pode ser facilmente substituído. No desenvolvimento de software o trabalho é essencialmente um processo de criação, uma arte. Por isso, essa teoria não encaixa.

A forma de especialização mais conhecida na área de desenvolvimento é a separação entre analista e programador. O analista é responsável por estudar os requisitos do sistema e gerar artefatos que transmitam a idéia para o programador – estes artefatos geralmente são diagramas UML (diagramas de classes, diagramas de seqüência, diagramas de iteração) e casos de uso. Em posse desses artefatos, o programador apenas “transforma” tudo isso em código. Simples não? Parece ser. Mas então por que isso não funciona? Aliás, acabei de ler mais um ótimo post do Phillip Calçado sobre este assunto: Quando eu crescer quero ser Analista de Sistemas.

O processo de criação de um software exige que a análise e o desenvolvimento andem o tempo todo juntos e sejam feitos de maneira incremental. A análise é feita a medida que o desenvolvimento evoluí. Algo que foi analisado hoje, pode não ser mais válido daqui uma semana – ou até mesmo num tempo menor.

Para entender como funciona o processo de desenvolvimento incremental, ou melhor, iterativo, precisamos antes nos lembras dos velhos tempos: o estilo cascata.

“O estilo em cascata subdivide um projeto com base na atividades. Para construir software, você precisa realizar certas atividades: análise dos requisitos, projeto, codificação e teste. Assim, nosso projeto de um ano poderia ter uma fase de análise de dois meses, seguida de uma fase de projeto de quatro meses, após a qual viria uma fase de codificação de três meses, seguida de uma fase de teste de mais três meses.
No desenvolvimento em cascata, normalmente existe alguma espécie de transferência formal entre cada fase, mas freqüentemente existem refluxos. Durante a codificação, pode surgir algo que o faça rever a análise e o projeto. Você certamente não deve supor que todo o projeto esteja concluído, quando a codificação começa. É inevitável que as decisões de análise e projeto tenham de ser revistas nas fases posteriores. Entretanto, esses refluxos são exceções e devem ser minimizados o máximo possível.”

Essa definição sobre o estilo em cascata foi tirada do livro UML Distilled: A Brief Guide to the Standard Object Modeling Language de Martin Fowler. Então, nada mais justo que expor a definição sobre o estilo iterativo deste mesmo livro:

“O estilo iterativo subdivide um projeto em subconjuntos de funcionalidades. Você poderia pegar um ano e dividi-lo em iterações de três meses. Na primeira iteração, você pegaria um quarto dos requisitos e faria o ciclo de vida do software completo para esse quarto: análise, projeto, código e teste. No final da primeira iteração você teria um sistema que faria um quarto da funcionalidade necessária. Então, você faria uma segunda iteração tal que, no final de seis meses, tivesse um sistema que fizesse metade da funcionalidade. É claro que o exposto é uma descrição simplificada, mas é a essência da diferença. Na prática, evidentemente, vazam algumas impurezas no processo.
No estilo iterativo, você normalmente vê alguma forma de atividade exploratória, antes que as iterações reais comecem. No mínimo, isso fornecerá uma visão de alto nível dos requisitos: pelo menos o suficiente para subdividi-los nas iterações que se seguirão. Algumas decisões de projeto de alto nível também podem ocorrer durante a exploração. Por outro lado, embora cada iteração deva gerar software integrado pronto para produção, freqüentemente ela não chega a esse ponto e precisa de um período de estabilização para eliminar os últimos erros. Além disso, algumas atividades, como o treinamento dos usuários, são deixadas para o final.
Você pode não colocar o sistema em produção ao final de cada iteração, mas eles devem ter qualidade de produção. Freqüentemente, entretanto, você pode colocar o sistema em produção em intervalos regulares; isso é bom, porque você avalia o sistema antecipadamente e obtém um retorno de melhor qualidade. Nessa situação, muitas vezes você ouve falar de um projeto com múltiplas versões, cada uma das quais subdivididas em várias iterações.”

Parando e refletindo sobre o assunto é interessante observar que muita coisa exposta neste texto e nos links abaixo não são exatamente grandes novidades. Essa é a realidade do desenvolvimento de software. Quem não entende isso ou não quer entender está completamente fora dessa realidade e deveria rever seus conceitos.

Alguns links sobre o assunto:

Anúncios

Posted in agile | Etiquetado: , , | 3 Comments »

Improve It fecha as portas para consultorias em metodologias ágeis

Posted by Matheus Tardivo em dezembro 21, 2007

Uma notícia preocupante – pelo menos pra mim, que estava realmente acreditando no sucesso dessa empresa por causa dos trabalhos com desenvolvimento ágil. Mas que também serve para mostrar as inúmeras dificuldades que esse tipo de metodologia (ou filosofia de trabalho) enfrenta no nosso país. Ou não será só aqui?

Alguns pontos que eu gostaria de salientar: recentemente passei a estudar e defender as práticas de metodologias ágeis, principalmente o XP.
Na equipe que trabalho, como todos também tem interesse em metodologias ágeis, decidimos aplicar práticas do XP no nosso dia-a-dia. Tentamos aplicar o que está ao nosso alcance: programação em par, refactoring, desenvolvimento guiados pelos testes, código coletivo, padrões de codificação, iterações e releases curtos, entre outras. Como a metodologia oficial adotada pela empresa não é XP (dizem que é RUP, mas na verdade é puro Waterfall) temos que procurar oportunidades para utilizar as práticas do XP, e posso dizer que estamos conseguindo. Ficamos satisfeitos (pelo menos eu estou) com os resultados que estamos obtendo com isso.

Mas, quando falamos de metodologias ágeis, existem alguns pontos críticos. Segue abaixo um trecho do texto publicado pelo Vinícius (desenvolvedor de software e fundador da Improve It) falando sobre isso:

“À medida que este ano termina, algumas coisas ficam claras para mim. Primeiro, é preciso admitir que comercialmente XP é muito ruim. Há uma resistência enorme ao seu uso, baseada nas mais diversas interpretações equivocadas. A maioria das pessoas não sabe o que é, mas pelo nome, é melhor nem saber mesmo. Com certeza não é coisa boa. Segundo, não tem certificação, o que é um pecado capital neste país. Terceiro, demanda das pessoas, das equipes, das empresas, um nível de atitude social e comportamental que parece ser avançado demais para o pensamento pequenino que reina nas empresas brasileiras, com raras exceções.”

Pra mim, tudo se resume neste texto: uma boa parte das pessoas que eu converso, mesmo sem realmente entender as propostas do XP, prontamente concluem que é algo ruim. Que não funciona. Quanto a isso, o que fica claro pra mim é que essas pessoas ou pensam que conhecem XP, ou apenas ouviram falar.

Recomendo que todos leiam a notícia na íntegra e tirem as suas conclusões. Fica claro que a atitude que a Improve It tomou não é baseada em problemas ou insucessos causados pelas metodologias ágeis, muito pelo contrário, pois isso deu condições à eles de tomarem esse novo rumo. Apenas mudaram o foco comercial de serviços para produtos – que, com certeza, continuaram a serem desenvolvidos utilizando metodologias ágeis.

Na notícia o Vinícius cita o caso de sucesso da 37signals: “Sem dúvidas esta empresa é, atualmente, nossa principal inspiração.” Pra que não conhece, David Heinemeier Hansson da 37signals é o criador do Ruby on Rails – e diversos outros produtos como o Basecamp.

Mas uma notícia como essa, principalmente com o conteúdo colocado, me deixa um pouco preocupado. Acredito não ser o único a ter essa preocupação pois vi mais pessoas acreditando no modelo de serviços que a Improve It vinha apostando. Segue um trecho de um post do Phillip Calçado num “Momento Mãe Diná 2008“:

“Vai ser o ano das consultorias pequenas. As ImproveIt, TriadWorks e Caelum da vida vão mostrar ao mercado brasileiro o que o internacional já sabe: times pequenos com foco em qualidade são melhores que enormes fábricas de software que simplesmente não conseguem entregar projetos”

Já conhecia a Improve It através dos artigos sobre XP, mas passei a ter admiração através do livro de XP do Vinícius – que virou uma fonte de referência para todos da equipe que trabalho, e pelo movimento para disseminar as técnicas ágeis no Brasil.

Boa sorte e sucesso para o pessoal da Improve It.

Aliás, vale a pena ler o artigo do Danilo Sato sobre essa notícia: Os Valores Ágeis não se Expressam em Palavras, mas em Ações.

Posted in agile, XP | Etiquetado: , , | Leave a Comment »