Acabei de ver pela santa web a palestra do @viniciusteles no #railssummit 2009.

Excelentes lições de tec #empreendedorismo

Link: http://blip.tv/file/2726351

É legal ver o sucesso do produto(be on the net) dele. É legal ver ele se dando bem mantendo-se fiel ao que sempre acreditou. É legal ver, no flashback que ele faz na palestra, um cara ficando adulto e paralelamente não se tornado um desistente (adultos, por muito muito comumente abrirem mão das visões de futuro que tinham quando jovens, deveriam ser chamados de desistentes, acho que foi em [Senge, A quinta disciplina] que li isto).

E o mais legal de tudo é que uma parte substancial do flashback apresentado na palestra, eu acompanhei relativamente de perto. Espero ser o próximo. Se o único motivo para a improve it não ter fechado foi ele ser muitíssimo teimoso, eu tô muito bem encaminhado. Me faltam reservas, mas eu chego lá.

Att.,
Vinicius AC
Voltando a ativa

A SWX será a próxima : – )

1 – A globo.com foi exemplo de sucesso na época que eu estava estudando pra mono, mas não citei na apresentação pq tava muito no início ainda, a experiência deles.

No link abaixo, Guilherme Chapiewski comenta como estão as coisas na Globo.com. Ele já comentou algumas vezes aqui no blog \o/. Legal ver estas coisas. Chega deu um frio na barriga.  : – )
http://gc.blog.br/2008/05/27/como-estamos-indo-com-a-adocao-de-scrum-na-globocom/

———————————–

(atualizado em: 09/01/2007)

Desenvolvimento Ágil
com
Programação Extrema

Finalmente estou publicando o conteúdo completo da minha monografia aqui no Blog. Considerando que o blog surgiu em função do estudo para este trabalho, e que a apresentação foi a uns 2 meses, realmente demorei tempo demais. Mas foi por um bom motivo. Acrescentei conteúdo novo e corrigi algumas coisas também.

O título é:
DESENVOLVIMENTO ÁGIL COM PROGRAMAÇÃO EXTREMA
EFICÁCIA E DISCIPLINA EXTREMA NO DESENVOLVIMENTO ORIENTADO A OBJETOS DE SOFTWARE

AVISO

O autor é o titular dos direitos autorais do trabalho que você está preste a baixar em seu computador. Este trabalho destina-se para uso pessoal ou científico.
Está proibida comercialização de qualquer espécie sem autorização prévia do autor.

DOWNLOAD

BETA

Apesar do beta estampado no topo das páginas, esta versão está finalizada. Não há versão mais nova do que esta.

]]> http://devagil.wordpress.com/2008/01/06/desenvolvimento-agil-com-extreme-programming/feed/ 0 viniciusac http://devagil.wordpress.com/2008/01/02/qualidade02012007/ http://devagil.wordpress.com/2008/01/02/qualidade02012007/#comments Wed, 02 Jan 2008 23:35:35 +0000 Vinicius AC http://devagil.wordpress.com/2008/01/02/qualidade02012007/ ]]>

3.3.12 Qualidadade (Princípio da XP)

Maior qualidade significa menos defeitos e retrabalho, menos aborrecimentos e maior segurança para clientes e desenvolvedores, maior confiança, menos ansiedade, maior motivação, maior efetividade, maior produtividade e maiores lucros, entre outras coisas. Ou seja, maior qualidade significa gerar maior valor de forma mais simples e eficientes, e com menos custos [IMPROVE IT, XP].

Qualidade motiva a equipe, entre outras coisas, porque as pessoas geralmente não gostam de fazer trabalhos medíocres, pelo contrário, elas sentem-se muito mais motivadas quando têm a oportunidade de trabalhar com qualidade e se orgulham disto [BECK, 2005].

Existe uma crença de que alta qualidade signifique gastos mais elevados. Não há dúvidas de que a qualidade tem um preço, mas a falta dela tem um preço ainda maior [IMPROVE IT, XP]. Sacrificar a qualidade nunca é uma boa forma de controlar o tempo ou os custos. Projetos não se tornam mais rápidos ou mais baratos, de acordo com a diminuição da qualidade, assim como não se tornam mais lentos ou mais caros de acordo com o aumento. Geralmente ocorre o contrário, ou seja, o aumento da qualidade gera entregas mais rápidas e com menores custos, enquanto que a diminuição resulta freqüentemente em atrasos e maiores custos [BECK, 2005].

A XP acredita que qualidade não é uma boa variável de controle para projetos. Para a XP, uma forma eficiente de gerenciar o andamento de um projeto com alguma flexibilidade é através do controle do escopo, já que este nunca é conhecido precisamente e em detalhes com uma boa antecedência. Além disso, o tempo e o custo são comumente fixados logo no início do projeto. Os ciclos semanais e trimestrais provêem pontos explícitos para acompanhamento e escolha do escopo [BECK, 2005].

Qualidade não é um argumento para falta de ação. Caso não se conheça uma solução clara para uma tarefa urgente, o indicado é resolver da melhor maneira possível. Se existe uma solução clara, mas que vai levar muito tempo, deve-se fazer com a melhor qualidade possível de acordo com o tempo disponível [BECK, 2005]. O mais importante é sempre ter em mente o significado e a importância de princípios como qualidade e melhoria, e assim agir da forma mais efetiva de acordo com cada contexto.

Talvez a única característica que realmente justifica o nome programação extrema para a metodologia, seja a extrema importância dada à geração do máximo de valor da forma mais simples e eficiente possível, e é por este motivo que a qualidade é tão importante para a XP.

Abraços,
Vinicius AC.

(atualizado em: 08/01/2007)

Resultados do Desenvolvimento Tradicional

Desde 1994, o Standish Group International publica a cada dois anos um estudo intitulado de Chaos Research [STANDISH, 2001] que consolida as informações de uma grande pesquisa sobre sucessos e fracassos dos projetos de software (figura 2.4). Neste estudo, os resultados dos projetos são enquadrados em uma das seguintes categorias:

• Bem sucedidos – O projeto é finalizado no prazo, dentro do orçamento e contendo todas as funcionalidades especificadas.
• Comprometidos – O projeto é finalizado e um software operacional é entregue, porém o orçamento e o prazo ultrapassam os limites estipulados, e, além disso, o software entregue possui menos funcionalidades do que o especificado.
• Fracassados – O projeto é cancelado em algum momento durante o desenvolvimento.

Figura 2.4 – Resultados dos estudos Chaos Research

Este estudo é bastante abrangente, pois engloba uma grande quantidade de projetos com as mais diversas metodologias de desenvolvimento. Porém, apesar da diversidade de metodologias, a grande maioria delas é baseada no desenvolvimento tradicional. A figura 2.4 mostra que apesar de ter ocorrido um aumento substancial da porcentagem de projetos bem sucedidos e diminuição de fracassados, os últimos resultados ainda são muito ruins, pois os projetos fracassados e comprometidos equivalem a 66% do total.

Como já foi dito neste trabalho, todas as metodologias tentam, entre outras coisas, reduzir o alto risco associado ao desenvolvimento de software. Porém, de acordo com os resultados alarmantes conseguidos nos últimos anos (figura 2.4), está claro que o desenvolvimento tradicional não tem conseguido atingir este objetivo. Estes resultados respaldam a afirmação de Brooks (seção 2.2.5) de que o desenvolvimento tradicional é equivocado.

Resultados do Desenvolvimento Ágil

Nos anos de 2006 e 2007, Scott Ambler organizou pesquisas para medir a adesão dos profissionais e das empresas aos valores, princípios e práticas comumente usadas no paradigma ágil. Os pesquisados tiveram que responder um questionário com perguntas relacionadas ao objetivo da pesquisa. Os resultados das duas pesquisa foram publicados na revista Dr. Dobb’s [DOBBS, WEB].

Os resultados mostram, entre outras coisas, que a grande maioria das empresas pesquisadas já adota técnicas ágeis, e que um adicional de aproximadamente 7% pretende adotar em no máximo 1 ano (figura 2.7).

Figura 2.7 – Taxa de adoção de técnicas ágeis pelas organizações

Outra constatação muito importante é que a adoção de técnicas ágeis não está restrita a projetos pilotos, isto fica claro na figura 2.8 que mostra a quantidade de projetos ágeis em andamento por organização.

Figura 2.8 – Número de projetos ágeis em andamento

Os dados da pesquisa de 2007 também mostram claramente que as técnicas ágeis foram implantadas com sucesso na maioria das empresas pesquisadas. A figura 2.9 mostra a porcentagem global de sucesso nos projetos. Neste caso não houve na pergunta uma definição formal de sucesso, já que esta definição em projetos de TI costuma variar por organização e freqüentemente até mesmo por projeto.
As fatias do gráfico indicam as porcentagens de pessoas que acreditam que seus projetos ágeis estão dentro da faixa de sucesso representada pela cor. A faixa de sucesso que cada cor representa está descrita na legenda.
Ex.: 77%(verde claro + verde escuro) das pessoas pesquisadas indicaram que seus projetos ágeis tiveram mais que 75% de sucesso. (nada mal)

Figura 2.9

Apesar da diferença de tamanho da amostra, em relação ao Chaos Research [STANDISH, 1994], os resultados mostrados na figura 2.9 são muito significativos e esclarecedores, pois dão uma boa idéia da grande diferença que existe em termos de resultados, entre os processos ágeis e os tradicionais. A pesquisa, feita através da Internet, recebeu respostas de 781 pessoas da área de TI, sendo 52% desenvolvedores e 22% gerentes, em março de 2007 [DOBBS, WEB; AMBLER, WEB].

Com base nos dados mostrados, fica claro que as metodologias ágeis, seis anos após seu surgimento, estão deixando de ser algo incerto, adotado somente por empresas jovens e com cultura fortemente voltada para inovação. O grande crescimento dos projetos que usam técnicas ágeis, em número e tamanho, nas mais variadas organizações, incluindo as grandes e tradicionais, mostra que o desenvolvimento ágil está tornando-se rapidamente a opção comum da maioria das empresas para projetos de software.

Essa pesquisa não é “A PESQUISA!”. Mas, independente de outras coisas, ela já merece algum crédito por ter sido publicada numa das maiores revistas, focada em desenvolvimento de aplicações e sistemas embarcados, do mundo. Somado a isto, existe o crédito da pesquisa ter sido organizada por um cara extremamente competente e bastante conhecido (Scott Ambler). Minha opinião pessoal é que, por estes dois motivos, ela merece mais que “algum crédito”, ela merece muito respeito e quase tanto crédito quanto o Chaos Research [STANDISH, 2001].

Abraços,
Vinicius AC

No desenvolvimento ágil, os projetos adotam o processo iterativo e em espiral (figura 2.5). No modelo espiral a dimensão radial representa o custo acumulado atualizado e a dimensão angular representa o progresso através da espiral.

Figura 2.5 – Desenvolvimento iterativo em espiral

No desenvolvimento ágil cada setor da espiral corresponde a um ciclo de desenvolvimento, sendo que estes ciclos devem ser curtos e ter tamanho(tempo) fixo.

Cada ciclo é precedido por uma retrospectiva que objetiva manter um processo de evolução contínua com base no aprendizado adquirido até o momento através dos ciclos anteriores.

Os ciclos são chamados de iterações e sempre acrescentam valor ao projeto na forma de novas funcionalidades implementadas, testadas e aprovadas. Isto permite que o cliente acompanhe na prática e gradativamente a evolução do projeto, obtenha muito mais cedo os benefícios do sistema, avalie a evolução do projeto e dê feedback constante para os desenvolvedores sobre as funcionalidades implementadas [TELES, 2004].

Matéria péssima da revista EXAME sobre fábricas de software ( horrível principalmente nos pontos que fala mais diretamente do desenvolvimento de software).
Destaquei as piores partes, na minha opinião.

| 28.06.2007
Por Ricardo Cesar

Mauri Morina não se queixa de seguir uma rotina quase sem variações. Pudera. Apesar da pouca idade — seus 22 anos estão patentes na cara de garoto com brinco na orelha e sorriso despreocupado –, ele não só tem um emprego fixo como ganha mais do que a média da população brasileira. Morina é funcionário de uma fábrica muito especial, que não usa parafusos nem solda: uma fábrica de software. Ele é programador no centro de desenvolvimento que a Stefanini IT Solutions montou em Alphaville, na Grande São Paulo, para atender o Bradesco, um de seus principais clientes. *Todos os dias, Morina liga seu computador às 8 horas da manhã e começa a digitar uma infinidade de linhas de código — uma seqüência de números e caracteres que para um leigo faz tanto sentido quanto grego. Como fios que costuram uma roupa, essas linhas indecifráveis, juntas, darão origem a um sistema coeso, como um internet banking, por exemplo.* Dessa mesma maneira são feitos os programas que controlam as chamadas telefônicas das operadoras, administram a frota de uma companhia aérea ou organizam o fluxo de pedidos de uma siderúrgica. Sistemas são essenciais para companhias de todos esses setores, mas desenvolver linhas de código não é a atividade principal de nenhuma delas. À medida que as empresas terceirizam essa função, fornecedores especializados, como a Stefanini, contratam mais e mais gente.

>>Vou considerar que o autor da matéria quis romantizar um pouco nesta parte, afinal é o início. Se foi isso, ainda não está muito ruim.

PRODUZIR SOFTWARE sob encomenda é uma atividade menos glamourosa do que muita gente imagina. O grosso da mão-de-obra, os programadores, são jovens na faixa dos 20 anos. *O trabalho é repetitivo e nem sempre requer criatividade. Sentados em baias e munidos de computadores simples, eles passam o dia inteiro digitando os códigos que construirão ou atualizarão os sistemas dos clientes. A produção é organizada como numa linha de montagem: ao cumprir uma etapa, o programador passa o serviço adiante e pega a próxima tarefa. É comum que esses profissionais nem saibam exatamente para que serve o software que estão criando, porque o desenvolvimento é quebrado em vários pedaços e distribuído entre equipes diferentes, que não têm uma visão abrangente do projeto. É como se cada uma delas recebesse instruções para desenhar uma peça de um quebra-cabeça sem saber como é a imagem completa.* A remuneração não é muito diferente do que se paga numa unidade fabril tradicional. A média de salários das montadoras automobilísticas da região do ABC paulista é 3 666 reais, segundo informações do sindicato dos metalúrgicos local. O salário inicial fica em torno de 1 000 reais e, após vários anos de carreira, pode chegar a pouco mais de 5 000 reais. Numa fábrica de software nos arredores de São Paulo, um programador júnior ganha entre 1 000 e 2 000 reais; um pleno, até 3 000 reais; e um sênior, por volta de 4 000 reais. Um funil estreito separa essa grande base dos poucos que chegarão a posições de comando, como coordenadores e gerentes.

>> Engraçado é que a capa da edição anterior a esta foi sobre a Toyota e seu grande sucesso baseado no seu modelo just in time, que entre outras coisas, costuma pregar a redução dos desperdícios (que a EXAME costuma dar ênfase em 100% das matérias), custos, etc, mas que tem como fundamento a manutenção de um processo de melhoria contínua baseado essencialmente nas contribuições dos operários envolvidos diretamente com a produção que estão no chão de fábrica. Este processo de melhoria contínua se dá essencialmente através das sugestões destes operários, ou seja, não há um setor de experts isolado e que tem a função de propor inovações que serão implementadas pelos operários. São operários valorizados e motivados que, com base no feedback do próprio trabalho, na confiança que recebem da empresa, na liberdade para propor e na própria qualificação, que sugerem estas melhorias. É através destas sugestões que a toyota IMPLEMENTA mais de 1 milhão de idéias por ano, e assim mantém a muitos anos uma vantagem(lucro, valor de mercado) esmagadora sobre seus concorrentes.
>>Porque escrevi isto acima? Porque a produção de automóveis é um trabalho muito mais intuitivamente (e teoricamente) ligado ao modelo taylorista do que o desenvolvimento de software, mas que mesmo assim foi completamente revolucionado pelo abandono deste modelo e pela adoção do Just in Time e do Thinking Lean (acho que no fundo um engloba o outro, não tô lembrado). A Toyota esmagou a GM e a Ford por isso, e hoje todas as montadoras tentam imitá-la.

>>Aí vejo uma matéria atual de uma revista de negócios respeitada no Brasil falando de linha de montagem para software. É demais! Isso que foi destacado representa cascata na veia. Um modelo baseado nas premissas tayloristas que, mesmo tendo sido o mais adotado por décadas, nunca funcionou. Veja o Chaos Report (Standish Group).

>>”Desenvolvimento de software é repetitivo e não requer criatividade“. isto é ridículo. Sem comentários!

>>Será que o autor da matéria conhece as vantagens de se valorizar a comunicação dentro das equipes ou entre as equipes, e dos imensos ganhos provenientes do enriquecimento da comunicação entre os desenvolvedores e seus clientes? Tenho certeza que não, senão ele teria falado sobre feedbacks curtos, comunicação, respeito, etc, e não sobre baias.

O ritmo é puxado. Na unidade onde Mauri Morina atua, as especificações de códigos a ser desenvolvidos chegam por meio de um link dedicado entre a Stefanini e o Bradesco.

>> As especificações de software costumam ser complexas, e o papel (ou a tela) é um meio pobre de comunicação em relação a outros meios, como a comunicação face a face por exemplo. Transmitir idéias complexas através de um meio de comunicação pobre fatalmente vai acabar gerando erros de representação e/ou de interpretação. O ideal é que o desenvolvedor também tenha acesso ao cliente e não somente às especificações.

Um sistema interno chamado e-Fábrica controla o recebimento e o andamento dos serviços. A cada tarefa executada, o programador precisa notificar no e-Fábrica o que foi feito. No final do mês, a empresa tem um levantamento detalhado de quanto cada profissional produziu. Há metas de produtividade para as fábricas. Quando são superadas, um sino é tocado. Silêncio por ali não é um bom sinal. Duas vezes por ano, a Stefanini premia os profissionais que se destacam. Dentro da fábrica há o aplauso do mês — os funcionários brindam com uma salva de palmas os colegas mais votados por eles mesmos. São maneiras de quebrar o clima árido de trabalho nessa verdadeira linha de montagem de bits e bytes.

>>Não faz sentido. Parte disto deve ter sido copiado e colado de alguma página no google sobre o trabalho dos digitadores, e não dos programadores. As tarefas variam muito em característica e complexidade de um sistema para outro e também dentro de um mesmo sistema, como eles podem medir os profissionais por quantidade de tarefas concluídas? E a corretude do código (bugs)? E a corretude de cada funcionalidade (tem que atingir ao objetivo, não basta não ter bugs)? Ou seja, mesmo numa visão bem geral, fica obvio que o modelo de fábrica de software, e mais ainda, este descrito nesta reportagem, não faz sentido.

>>Na minha opinião, as fábricas de software estão fadadas ao desaparecimento. E parece que isto já está acontecendo. Não faz sentido que algo extremamente complexo e que, dependendo do caso, pode ter milhares de possibilidades, centenas de partes que precisam trabalhar integradas, e ainda que depende fundamentalmente da criatividade, possa ser construído num modelo que tenta imitar uma fábrica taylorista. Pena que onde eu estudo, ninguém nem comenta isto, pois um banco montou um fabrica de software lá pra explorar mão de obra barata dos estudantes (desabafozinho .

TALVEZ NÃO HAJA GLAMOUR algum nessas coisas, mas não faltam motivos pelos quais essa atividade deveria ser vista como estratégica para o Brasil. A área tem se mostrado pródiga em atrair investimentos e é uma das razões que levaram fornecedores como IBM e Accenture a aumentar a aposta no mercado nacional. Há também projetos brasileiros, como a CPM Braxis, que, com apenas um ano de vida, reúne 5 000 funcionários, deve faturar algo próximo a 1 bilhão de reais no atual exercício e é séria candidata a abrir capital na Bovespa em médio prazo. Além disso, trata-se de um segmento com enorme capacidade de gerar empregos — e gerá-los rapidamente. Juntas, as dez maiores companhias do setor empregam mais de 40 000 pessoas no país. “É preciso pelo menos dois anos para estabelecer uma montadora, enquanto uma fábrica de software está de pé em seis meses”, diz Chu Tung, presidente da subsidiária brasileira da EDS, uma das gigantes americanas de serviços tecnológicos. Por mais que o trabalho de programação seja repetitivo, ainda é extremamente atraente para muita gente. A carreira é abraçada sobretudo por jovens das classes C, D e E, que enxergam uma oportunidade de alcançar uma renda razoável em poucos anos. Trata-se de um trabalho mais sofisticado e mais bem remunerado que o de um atendente de call center, por exemplo. “Num país como o Brasil, essa é uma atividade que puxa a média para cima, não para baixo”, diz Jair Ribeiro, presidente da CPM Braxis.

>> Parece piada. Sem comentários!

O momento é promissor, mas há algumas nuvens carregadas no horizonte. A falta de mão-de-obra qualificada é uma delas.

>> Porque será que “falta” mão de obra qualificada? Eu prefiro plantar feijão lá em Antas-BA na roça de meu pai, do que trabalhar neste modelo que foi descrito. Ainda bem que o mundo é plano [Thomas Friedman], então se no Brasil as empresas grandes “pensam” a respeito dos desenvolvedores de forma tão ridícula quanto a reportagem diz, eu ainda tenho algumas alternativa(antes do feijão), tipo ser autônomo ou micro-empresário com a ajuda da WEB. Só espero não ter que fazer como muitos colegas formados, que desiludidos abandonaram a área para tentar concursos públicos, ou para fazer faculdade em áreas “melhores”.

Nesse mercado, o fechamento de um grande contrato pode significar a abertura de centenas de vagas da noite para o dia. O melhor exemplo disso é a subsidiária nacional da indiana Tata Consultancy Services (TCS), que triplicou de tamanho quando a matriz ganhou um contrato milionário do banco holandês ABN Amro. Hoje, dos 1 600 funcionários brasileiros da TCS, 900 são dedicados ao banco. “Precisamos de tantos profissionais qualificados quantos pudermos encontrar”, diz Sérgio Rodrigues, presidente da TCS no país. A brasileira BRQ tem 500 vagas em aberto, situação que se repete na CPM Braxis. Na subsidiária brasileira da Accenture, há cerca de 800 postos não preenchidos no momento. “Está todo mundo desesperado atrás de mão-de-obra”, afirma Paulo César Bonucci, presidente da subsidiária da Unisys, que emprega mais de 700 pessoas — cerca de um terço de seu contingente — em fábricas de software. Essa situação gera alguns efeitos colaterais. Estima-se que os salários de programadores subam em média 8% ao ano no mercado nacional. Há sempre propostas de concorrentes rondando, o que leva a rotatividade nessas empresas a cerca de 10% anuais. São números que tiram o sono dos empresários do ramo, mas ainda parecem uma calmaria em relação ao que ocorre na Índia: lá, os salários sobem 18% e a taxa de demissão voluntária beira os 25% ao ano.

>>Ainda bem que a mão de obra qualificada não é idiota (pelo menos, uma parte não).

No Brasil, o maior gargalo é a escassez de programadores com inglês fluente, um pré-requisito para quem quer exportar serviços. Algumas empresas chegam a procurar funcionários em escolas de idiomas. “Aprender a programar é mais fácil do que falar outra língua fluentemente”, diz Humberto Luiz Ribeiro, vice-presidente da Politec, empresa de serviços de tecnologia com sede em Brasília.
A preocupação faz sentido. A CPM Braxis, por exemplo, tem forte presença nos Estados Unidos. A Politec atende a Mitshubishi no Japão e também tem contratos no mercado americano. Quase 20% do faturamento da Stefanini já vem de fora do Brasil. Um terço de tudo o que a Accenture desenvolve em Alphaville destina-se ao mercado externo. O centro que a IBM mantém em Hortolândia, no interior de São Paulo, uma das instalações mais modernas do país, atende dezenas de clientes sediados em nações que falam inglês, espanhol e francês.

>> Aprender um novo idioma fluentemente, realmente não é nada fácil, mas vejo uma pequena contradição aqui. Tudo bem que os clientes são internacionais, as referências são quase sempre em inglês, etc… Mas, pra quem vai atuar de forma semelhante a uma máquina que traduz especificação em em software, pra que saber inglês fluentemente? Neste caso não bastaria saber ler de forma razoável?
Concluindo esta parte: Saber ler razoavelmente em outro idioma(inglês) é relativamente fácil em relação ao conhecimento exigido de bom programar.

Mas a principal queixa dos empresários é o custo de contratação de profissionais no mercado brasileiro, que fica em média 30% acima do verificado na Índia. A mão-de-obra responde por 2 de cada 3 reais gastos para manter uma fábrica de software. Os representantes do setor pedem medidas de incentivo ao governo, argumentando que agora é o momento de criar condições para o país posicionar-se como uma alternativa à Índia. Se o Brasil não fizer isso, outras nações ocuparão o vácuo rapidamente. É claro que Mauri Morina não pensa nessas coisas quando chega à fábrica de software da Stefanini, em Alphaville, com um dia de trabalho pela frente. Sua cabeça está nas oportunidades que a carreira lhe reserva ou em como gastar seu próximo salário. Pensamentos que podem ser compartilhados por centenas de milhares de outros jovens brasileiros dentro de alguns anos — se mais essa oportunidade histórica não for perdida.

>> Gasto não. Investido! Mão de obra em empresas que sabem desenvolver software é algo que trás bons lucros dependendo da qualificação. Quanto mais qualificada, melhor o salário, claro. Quanto melhor o salário, mais lucros. Simples!
Pena que muitos e muitos gerentes de TI, acostumados a trabalhar com premissas erradas, não conseguem(não querem) ver isso.
>> Quanto ao custo da mão de obra na índia, suponho que a EXAME saiba muito bem que a realidade no Brasil é outra completamente diferente.
>> “Medidas de incentivo de governo”? Quem sou eu pra falar pra EXAME se isto é bom ou não.

Chego até a suspeitar que a grande revista EXAME,
não se preocupa muito em selecionar pessoas competentes para escrever as matérias.

Tomara que tenha sido “só” um problema nesta matéria específica (se bem que não vi nenhuma correção numa edição seguinte).
Ainda bem que recebo de graça, afinal eles insistiram tanto em me dar 3 meses grátis, que acabei aceitando.

Quando li a uns dois meses, fiquei doido pra escrever algo sobre o assunto, mas nunca deu tempo. Tá aqui no meu quadro branco até hj, o lembrete. Hj, mesmo sem tempo, acabei escrevendo algo.

Com relação a parte empresarial da reportagem, eu até concordo que muitas empresas adotam o que está descrito, mas também acredito que não são todas e que nos países desenvolvidos atualmente nem representam a maioria. Além disso, acredito(rezo que seja logo) que o futuro das empresas que continuem seguindo esta linha, mesmo nos países subdesenvolvidos, não será dos melhores. Graças a Deus!

Flws,
Vinicius AC.
UFS / Graduando.

Minha argumentação está longe de ser detalhada e sólida, mesmo porque nem precisa argumentar tanto, pois a reportagem tá fraquinha.
Tentaria escrever melhor, mas deveria estar estudando nos últimos 60 minutos, ao invés de escrevendo isto.

===================

Mais infos sobre este assunto:
http://www.urubatan.com.br/movimento-contra-a-asneira-da-info-exame/

http://eduardomiranda.net/blogs/dotnet/archive/2007/07/10/remando-contra-a-mare.aspx

Deve-se tentar aplicar a estrutura de uma solução para outros contextos, mesmo em escalas diferentes. É algo semelhante a proposta de padrões de projetos (Design Patterns) descrita por Gamma [GAMMA, 1995], onde estruturas de soluções eficientes para problemas freqüentes foram catalogadas para facilitar o reuso.

Por exemplo, uma prática básica na XP é escrever os testes antes da implementação das funcionalidades (seção 3.5.12). Esta prática dita um ritmo de desenvolvimento que opera em diferentes escalas.

No início de cada trimestre listam-se os temas (metas) que são importantes para o período e direcionarão as histórias do trimestre. Depois disto, os testes guiam diretamente o desenvolvimento em duas escalas:

1. Em cada semana, os usuários reunidos com os desenvolvedores priorizam e selecionam, entre as histórias, algumas para implementação. Então os testes que expressam estas histórias são escritos para depois serem colocados em funcionamento. Estes são os testes de aceitação (seção 5.2.2);

2. Em poucas horas é possível fazer uma lista com os testes necessários para uma funcionalidade. Então se escreve o código do primeiro teste e o coloca em funcionamento, depois o segundo é escrito e colocado pra funcionar junto com o primeiro, depois o terceiro e assim sucessivamente até que todos os testes da lista estejam funcionando. Estes são os testes de unidade (seção 5.2.1).

Auto-semelhança não é o único princípio que influencia o desenvolvimento de um software, pelo contrário, existem muitos outros. O fato de se copiar a estrutura de uma solução que funcionou bem em um ou mais contextos, não significa que ela irá funcionar sempre. De qualquer forma, é um bom lugar por onde começar. Em contrapartida, o fato de uma solução não ser reutilizável, não significa que esta seja ruim, pois existem casos onde esta é a melhor escolha [BECK, 2005].

Abraços,
Vinicius AC
Graduando – Univ. Federal de Sergipe

Cada atividade deve ser benéfica para todos os envolvidos em um projeto de software. Este é o mais importante princípio da XP, e o mais difícil de cumprir.

Há sempre soluções mais fáceis em que alguns ganham e outros perdem para qualquer problema. Apesar de tentadoras, principalmente quando as pressões externas são intensas, estas soluções sempre causam mais perdas que benefícios, já que, além das perdas diretas, existe a perda causada pela deterioração das relações de trabalho.

Desenvolver software é um negócio focado nas pessoas e que depende muito das relações entre os envolvidos, por isso, deve-se adotar práticas que beneficiem ambos, criadores e clientes do software, agora e no futuro. Programação em par, por exemplo, beneficia os programadores de inúmeras formas. Mas, também beneficia os clientes, porque costuma ser raro encontrar bugs em funcionalidades implementadas em par, e gerentes, já que a disseminação do conhecimento fruto da programação em par, torna o projeto menos suscetível a perdas em função da saída definitiva ou temporária de um dos desenvolvedores [IMPROVE IT, XP; BECK, 2005].

Documentação abrangente no código é um exemplo de uma prática que viola o princípio do benefício mútuo. Esta prática costuma diminuir a velocidade de desenvolvimento consideravelmente, objetivando que no futuro seja mais fácil fazer alterações. Realmente existe um possível benefício futuro, desde que a documentação ainda esteja válida, mas nenhum benefício para o presente.

A XP recomenda para resolver o problema anterior de maneira mutuamente benéfica, agir da seguinte forma [BECK, 2005]:

· Escrever testes automatizados que ajudam a melhorar o design e implementação no presente. Deixar estes testes para os futuros programadores, para que estes possam ter uma documentação sincronizada com o código e um mecanismo de verificação automatizado que dá segurança para qualquer possível alteração futura.

· Refatorar cuidadosamente para eliminar qualquer complexidade acidental, isto gera satisfação e menos defeitos no presente, além de tornar o código mais fácil de compreender e modificar no futuro.

· Escolher nomes de um conjunto coerente e explícito de metáforas relacionadas ao domínio da aplicação. Isto aumenta a velocidade de desenvolvimento no presente e torna o código mais claro para o futuro.

Abraços,
Vinicius AC
Universidade Federal de Sergipe (Graduando)

Para desenvolver software é preciso investir tempo e recursos. Este investimento é considerado satisfatório quando é compensado através do valor gerado, ou seja, quando o software satisfaz as expectativas de quem investiu nele. É um erro esquecer-se do lado econômico do desenvolvimento e preocupar-se somente com o “Sucesso Técnico” [BECK, 2005].

O cliente investe em software com a expectativa de que este gere valor comercial. A XP reconhece esta premissa e suas práticas são organizadas para antecipar receitas e adiar despesas [IMPROVE IT, XP].

Abraços,
Vinicius AC

Softwares são desenvolvidos por pessoas e para pessoas, logo uma melhor compreensão das pessoas – como elas trabalham individualmente e em equipe, por exemplo – e das questões humanas em geral, é fundamental para a criação e evolução deste produto. Um bom software é resultado da ação de pessoas. Assim como é o caso de softwares ruins [CONSTANTINE, 2001].

Freqüentemente, o desenvolvimento de software não reconhece as fragilidades humanas, nem satisfaz suas necessidades. Isto é o mesmo que ignorar a importância das pessoas para a qualidade de um software [TELES, 2005; BECK, 2005].

Existem alguns fatores que afetam diretamente a qualidade do trabalho de um desenvolvedor:

· Segurança básica – não se sentir ameaçado, inclusive em relação a manutenção do emprego;

· Realização – sentir-se útil, valorizado e orgulhoso com o trabalho realizado;

· Participação – identificar-se com um grupo e dentro deste, assumir responsabilidades e ajudar a alcançar objetivos;

· Crescimento – desenvolver as próprias habilidades e pontos de vista;

· Intimidade – compreender e ser compreendido pelos outros.

Na XP, as pessoas são fundamentais no processo de desenvolvimento, por isso suas práticas são voltadas para potencializar o melhor que as pessoas têm para oferecer, bem como suprimir suas falhas [IMPROVE IT, XP ].

As práticas da XP também procuram balancear as demandas dos negócios com as necessidades pessoais dos desenvolvedores. Por exemplo, limitar a carga horária dá tempo para que necessidades pessoais sejam satisfeitas – já que muitas delas, como descansar, exercitar-se e socializar-se, ocorrem fora do ambiente de trabalho – e também aumenta o rendimento e as perspectivas das pessoas durante o trabalho [BECK, 2005].

Abraços,
Vinicius AC

Mantenha equipes eficientes juntas. Há uma tendência em grandes organizações de abstrair pessoas para coisas, como se pessoas fossem unidades de programação plug-and-play. Valor em software é criado não apenas pelo o que as pessoas conhecem e fazem, mas também por seus relacionamentos e o que elas realizam juntas [IMPROVE IT, XP].

Organizações pequenas não têm esse problema. Há somente uma equipe e, uma vez que seus membros estejam integrados e confiando uns nos outros, somente uma verdadeira calamidade pode separá-los. Grandes organizações freqüentemente ignoram o valor das equipes, adotando ao invés disso, uma metáfora em que os desenvolvedores são meros “recursos de programação”. Uma vez que o projeto está pronto, os desenvolvedores voltam para “para a fila” e aguardam até que sejam alocados para uma nova tarefa. O objetivo desse tipo de gerenciamento de “recursos” é fazer com que todos os desenvolvedores sejam integralmente utilizados. Essa estratégia maximiza micro-eficiências, mas mina a eficiência da organização como um todo. O principal erro é buscar uma eficiência ilusória em que indivíduos ficam alocados no trabalho o maior tempo possível, e em contrapartida, minimizar ou ignorar o valor do trabalho em equipe, principalmente quando os membros se conhecem bem e confiam uns nos outros [IMPROVE IT, XP].

Estimular que equipes bem integradas permaneçam juntas não significa que as equipes tenham que ficar inteiramente estáticas. É notável como novos membros começam a contribuir rápido em equipes XP já estabelecidas. Eles insistem em implementar tarefas de desenvolvimento já na primeira semana, e já estão contribuindo de forma independente após um mês. Preservando equipes e ainda encorajando uma quantidade razoável de rotação espontânea entre os membros, a organização ganha os benefícios tanto das equipes estáveis, quanto da dispersão consistente de conhecimento e da experiência [BECK, 2005; IMPROVE IT, XP].

Abraços,
Vinicius AC

Quando estiver substituindo um sistema legado, gradualmente e desde o início do projeto, implante as partes do novo sistema que forem ficando prontas, substituindo as partes equivalentes no sistema legado. De vez em quando grandes implantações funcionam, mas são muito arriscadas e têm custos humanos e econômicos muito elevados [IMPROVE IT, XP].

A alternativa às grandes implantações é encontrar algumas funcionalidades ou um conjunto limitado de dados que possam ser controlados em separado e imediatamente, e então implantá-los. Enquanto a implantação não for concluída, terá que ser encontrada uma forma de rodar os dois sistemas em paralelo, dividindo ou fundindo arquivos ou treinando alguns usuários para usar ambos os sistemas por um tempo. Esta necessidade, técnica ou social, é o preço que se paga pela segurança [BECK, 2005; IMPROVE IT, XP].

Abraços,
Vinicius AC

1. Introdução

Desenvolver software é uma atividade difícil e arriscada. Segundo as estatísticas, entre os maiores riscos estão: gastos que superam o orçamento, consumo de tempo que supera o cronograma, funcionalidades que não resolvem os problemas dos usuários, baixa qualidade dos sistemas desenvolvidos e cancelamento do projeto por inviabilidade.

No conceito tradicional, metodologia de desenvolvimento de software é um conjunto de atividades e resultados associados, que auxiliam na produção de software. Todas as metodologias de desenvolvimento tentam, entre outras coisas, reduzir o alto risco associado ao desenvolvimento de software.

Neste trabalho, as diversas metodologias de desenvolvimentos existentes na literatura serão agrupadas de acordo com o modelo básico de desenvolvimento adotado.

1.1. Desenvolvimento Tradicional

O termo desenvolvimento tradicional, neste trabalho, é utilizado para identificar as metodologias que de alguma forma adotam o desenvolvimento em cascata. No desenvolvimento em cascata, o software é construído seguindo uma seqüência de fases, sendo que cada fase, com exceção da primeira, depende da conclusão da fase anterior para ser iniciada (figura 1.1).

Figura 1.1 – Desenvolvimento em cascata.

O desenvolvimento em cascata, á várias décadas é amplamente empregado nos processos de desenvolvimento de software, e ainda hoje é o mais empregado. Por esse motivo, neste trabalho ele é chamado de desenvolvimento tradicional.

Mesmo alguns processos de desenvolvimento de software que, em essência, não são em cascata, como o RUP (Rational Unified Process), são adotados em grande parte dos projetos, de uma forma que se assemelha muito ao modelo em cascata. Nesses projetos, o processo é empregado de forma iterativa e incremental, mas ainda existe uma forte linearidade no desenvolvimento, caracterizada por “cascatas menores” dentro de cada iteração (figura 1.2). Neste trabalho, o termo “desenvolvimento tradicional” também engloba estes casos [TELES, 2004].

Figura 1.2 – Desenvolvimento iterativo em cascata.

1.2. Premissas do Desenvolvimento Tradicional

Existem algumas premissas básicas, derivadas do modelo de desenvolvimento industrial, que são muito comuns no desenvolvimento tradicional e o influenciam profundamente. Segue abaixo estas premissas e seus significados dentro do contexto do desenvolvimento tradicional de software.

1.2.1 Linearidade

A linearidade fica evidente pela própria adoção de um modelo em cascata que, como já foi explicado, é linear por definição.

1.2.2 Determinismo

Um processo de desenvolvimento previamente conhecido por gerar determinados resultados com base nas especificações, gerará resultados semelhantes sempre que suas regras forem rigidamente seguidas. O desenvolvimento tradicional, assim como a indústria, persegue o determinismo por acreditar que esta é uma forma de reduzir erros e perdas de tempo [TELES, 2004].

1.2.3 Especialização

O processo de desenvolvimento pode ser desmembrado em atividades especializadas que serão executadas de forma independente e depois terão seus resultados integrados para formar o produto final. A especialização torna as tarefas mais simples e conseqüentemente facilita o determinismo. No desenvolvimento de software tradicional, a especialização aparece claramente na rígida divisão de papeis entre membros de uma equipe, como analistas, projetistas, programadores, testadores e implantadores. Cada um deles realiza tarefas bem diferentes e especializadas e terão seus resultados integrados para compor o software finalizado [TELES, 2004].

1.2.4 Foco na execução

Quando existe especialização suficiente para que as tarefas sejam simples e determinísticas, não existe a necessidade, por parte de quem executa o trabalho, de pensar sobre o que se está fazendo, basta fazer. Ou seja, basta que cada pessoa envolvida no processo de desenvolvimento execute corretamente a tarefa que lhe cabe, conforme rigidamente estipulado numa metodologia que presumivelmente torna o processo determinístico, para que a especificação seja transformada corretamente em software [DEMARCO, 1987, pg. 114; TELES, 2004]. Isto gera uma grande valorização dos processos e uma conseqüente desvalorização das pessoas, no desenvolvimento de um software [TELES, 2004].

1.2.5 Crescimento exponencial do custo de alteração

No modelo de desenvolvimento tradicional, em cascata, o custo de uma alteração cresce exponencialmente, à medida que o processo de desenvolvimento avança (figura 1.3). Esta premissa básica da engenharia de software tradicional foi formulada por Boehm em Software Engineering Economics [BOEHM, 1981]. A aceitação desta premissa tem como conseqüência natural uma busca por processos determinísticos, já que estes prometem menos alterações e maior previsibilidade.

Este princípio também reflete e justifica de certa forma, a busca pela aproximação conceitual entre os processos de desenvolvimento de software e os processos industriais típicos, ou seja, justifica a busca por metodologia lineares, determinísticas, especializadas e focadas na execução.

Figura 1.3 – Crescimento dos custos de alteração

Segundo Brooks [BROOKS, 1995, p. 264; TELES, 2004], isto não seria nenhum problema se o processo de desenvolvimento tradicional, em cascata, não estivesse errado nas seguintes afirmações:

• O modelo em cascata assume que o projeto irá passar por cada etapa apenas uma vez. Ou seja, assume que a arquitetura é excelente, que o design é correto e que a implementação pode ser corrigida durante os testes. Nenhuma destas afirmações funciona bem na prática, seja no modelo em cascata tradicional, seja nas metodologias iterativas e incrementais que empregam “cascatas menores” dentro de cada iteração (figura 1.2) [TELES, 2004].
• O modelo em cascata puro, assume que o sistema todo é construído de uma única vez. Isso implica que para poder testar todo o sistema é preciso que todas as fases anteriores, desde o levantamento dos requisitos até a implementação estejam concluídas e integradas num sistema único. Na prática, entre outros problemas relacionados, os erros ocorrem em todas as etapas do desenvolvimento e deixar os testes para depois da implementação é algo altamente ineficiente [TELES, 2004].

1.3. Problema do desenvolvimento tradicional

O grande problema do desenvolvimento tradicional é que ele baseia-se em premissas que não se aplicam ao trabalho de desenvolvimento de software.

Segundo Drucker [DRUCKER, 1999, p.111], existem duas categorias de trabalhadores: o trabalhador manual e o trabalhador do conhecimento. Um trabalhador manual executa atividades que dependem basicamente de habilidades manuais e que não se baseiam no uso intensivo do conhecimento. São atividades relativamente fáceis de automatizar por serem altamente determinísticas e repetitivas. O trabalhador do conhecimento, em contrapartida, é aquele que produz com base no uso intensivo da criatividade e do conhecimento [TELES, 2004].

Apesar de ser um trabalho executado basicamente por trabalhadores do conhecimento, o desenvolvimento tradicional utiliza premissas que só são válidas para o trabalhador manual.

Segundo Vinicius Teles [TELES, 2004, p. 38]: “Inúmeros estudiosos, entre eles Drucker, DeMarco, Lister, Toffler e DeMarsi têm demonstrado que a produtividade do trabalho do conhecimento deriva de fatores completamente diferentes daqueles usados para o desenvolvimento tradicional. De fato, eles mostram que as premissas da produtividade do trabalho do conhecimento são praticamente opostas às do trabalho manual e o grande erro cometido na maioria dos projetos de software é desconsiderar este fato e adotar as mesmas práticas do ambiente industrial.”.

Um exemplo da grande diferença em relação ao trabalhador manual e do conhecimento está na escolha da melhor política para tratar a ocorrência de erros. Para atividades que envolvem trabalhadores manuais, erros podem e devem sempre ser evitados, e os processos rígidos e determinísticos ajudam a alcançar este objetivo. Já para atividades que envolvem trabalhadores do conhecimento, erros devem ser encarados como coisas naturais, saudáveis e até inevitáveis. Neste caso, tentar sistematizar ou impor metodologias rígidas ao processo de desenvolvimento, visando o determinismo, no máximo torna as pessoas envolvidas defensivas e pouco criativas [TELES, 2004].

1.4. Resultados do Desenvolvimento Tradicional

Desde 1994, o Standish Group International publica a cada dois anos um estudo intitulado de Chaos Research [STANDISH, 1994] que consolida as informações de uma grande pesquisa sobre sucessos e fracassos dos projetos de software (figura 1.4). Neste estudo, os resultados dos projetos são enquadrados em uma das seguintes categorias:

• Bem sucedidos – O projeto é finalizado no prazo, dentro do orçamento e contendo todas as funcionalidades especificadas.
• Comprometidos – O projeto é finalizado e um software operacional é entregue, porém o orçamento e o prazo ultrapassam os limites estipulados, e, além disso, o software entregue possui menos funcionalidades do que o especificado.
• Fracassados – O projeto é cancelado em algum momento durante o desenvolvimento.

Figura 1.4 – Resultados dos estudos Chaos Research

Este estudo é bastante abrangente, pois engloba uma grande quantidade de projetos com as mais diversas metodologias de desenvolvimento. Porém, apesar da diversidade de metodologias, a grande maioria delas é baseada no desenvolvimento tradicional. A figura 1.4 mostra que apesar de ter ocorrido um aumento substancial da porcentagem de projetos bem sucedidos e diminuição de fracassados, os últimos resultados ainda são muito ruins, pois os projetos fracassados e comprometidos equivalem a 66% do total.

Como já foi dito neste trabalho, todas as metodologias tentam, entre outras coisas, reduzir o alto risco associado ao desenvolvimento de software. Porém, de acordo com os resultados alarmantes conseguidos nos últimos anos (figura 1.4), está claro que o desenvolvimento tradicional não tem conseguido atingir este objetivo. Estes resultados respaldam a afirmação de Brooks (seção 1.2.5) de que o desenvolvimento tradicional é equivocado.

1.5. Desenvolvimento Ágil

O desenvolvimento ágil é um fruto da constatação feita, de forma independente, por diversos profissionais renomados na área de engenharia de software, de que, apesar de terem aprendido segundo a cartilha tradicional, só conseguiam minimizar os riscos associados ao desenvolvimento de software, pensando e agindo de forma muito diferente do que tradicionalmente está nos livros. Estes profissionais, a maioria veteranos consultores para projetos de softwares, decidiram reunir-se no início de 2001 durante um workshop realizado em Snowbird, Utah, EUA.

Embora cada envolvido tivesse suas próprias práticas e teorias preferidas, todos concordavam que, em suas experiências prévias, os projetos de sucesso tinham em comum um pequeno conjunto de princípios. Com base nisso eles criaram o Manifesto para o Desenvolvimento Ágil de Software, freqüentemente chamado apenas de Manifesto Ágil. O termo Desenvolvimento Ágil identifica metodologias de desenvolvimento que adotam os princípios do manifesto ágil. Estes princípios são os seguintes:

· Indivíduos e interação entre eles mais que processos e ferramentas

· Software em funcionamento mais que documentação abrangente

· Colaboração com o cliente mais que negociação de contratos

· Responder a mudanças mais que seguir um plano

O manifesto reconhece o valor dos itens à direita, mas diz que devemos valorizar bem mais os itens à esquerda.

No desenvolvimento ágil, os projetos adotam o modelo iterativo e em espiral (figura 1.5). Neste processo, todas as fases descritas no modelo em cascata são executadas diversas vezes ao longo do projeto, produzindo ciclos curtos que se repetem ao longo de todo o desenvolvimento, sendo que, ao final de cada ciclo, sempre se tem um software funcional, testado e aprovado. Os ciclos são chamados de iterações e crescem em número de funcionalidades a cada repetição, sendo que, no último ciclo, todas as funcionalidades desejadas estarão implementadas, testadas e aprovadas [TELES, 2004].

Figura 1.5 – Desenvolvimento iterativo em espiral

1.6. Premissas do Desenvolvimento Ágil

O cliente aprende ao longo do desenvolvimento, à medida que é capaz de manipular o sistema.

Um dos problemas mais complexos que afetam o desenvolvimento de software é a enorme quantidade de detalhes que precisam ser considerados. Normalmente, ao especificar um sistema, o cliente tem o conhecimento de alguns aspectos do software que deseja. Entretanto, muitos outros só ficam claros quando ele tem a oportunidade de utilizar o sistema. Portanto, o cliente não especifica estes detalhes no início do projeto por uma razão muito simples: ele não os conhece [BECK, 2000]. Além do mais, mesmo que tais detalhes fossem conhecidos previamente, seria muito difícil especificá-los através de documentos, devido à grande quantidade de elementos que precisariam ser descritos.

Perceber que o cliente aprende ao longo do desenvolvimento é a chave para se compreender o grande desafio existente no desenvolvimento de software. O cliente aprende à medida que tem acesso ao sistema e se envolve em discussões sobre ele. Este aprendizado pode ser utilizado para realimentar o processo de desenvolvimento ou pode ser ignorado. Esta última alternativa é o caminho adotado normalmente no desenvolvimento tradicional, pois ele parte da premissa que o cliente já sabe o que quer no início do projeto e a ele cabe apenas descrever os requisitos. Depois, ao final, ele receberá o sistema e não haverá ciclos de realimentação entre a especificação e a entrega do sistema [TELES, 2004].

O custo de uma alteração mantém-se estável a partir de um certo ponto no projeto.

Ao contrário do desenvolvimento tradicional que acredita que o custo de uma mudança cresce exponencialmente a medida que o tempo de desenvolvimento avança, no desenvolvimento ágil acredita-se que o custo de mudança do software ao longo do tempo tende a se tornar constante (figura 1.6). Tal idéia se fundamenta, entre outros, nos seguintes fatores: avanços ocorridos na microinformática, adoção da orientação a objetos, uso da refatoração para aprimorar e simplificar o design, adoção de testes automatizados, melhores linguagens e ambientes de desenvolvimento [TELES, 2005].

Figura 1.6 – Custo de alterações no desenvolvimento ágil e no desenvolvimento tradicional.

As duas premissas anteriores ajudam a explicar algumas das posições totalmente opostas adotas pelos dois modos de desenvolvimentos. Por exemplo, no desenvolvimento ágil, modificações no projeto são naturais, pois não existe nenhum custo exponencial associado às alterações. Ou seja, não existe nenhuma necessidade de tentar especificar detalhadamente tudo que ocorrerá durante a implementação do sistema, para tentar minimizar possíveis alterações, até porque, isto dificilmente traz os resultados esperados.

1.7. Conclusões

No desenvolvimento ágil os envolvidos no desenvolvimento são tratados como trabalhadores do conhecimento e conseqüentemente são estimulados a aprender durante o desenrolar do próprio trabalho e tomar decisões melhores com base neste aprendizado. Não existe um processo rígido que impõe o que pode ou não ser feito e desestimula a criatividade.

No desenvolvimento tradicional, os especialistas do negócio conversam com os analistas, que digerem, abstraem e passam as informações mastigadas aos programadores, que não pensam nada além do necessário para escrever o código do software. Esta especialização (seção 1.2.3) de atividades é péssima porque é completamente desprovida de feedback. O analista tem toda a responsabilidade de criar o modelo de domínio, baseado somente nas informações fornecidas pelos especialistas do negócio. Eles não têm a oportunidade de aprender com o desenvolvimento ou ganhar experiência com as versões iniciais do software [EVANS, 2004].

O desenvolvimento ágil sabe que trabalhadores do conhecimento rendem mais e melhor em ambientes que estimulam o uso intensivo da criatividade e do conhecimento. Escrever softwares é um trabalho tão ou mais criativo que escrever um livro, um artigo ou uma monografia. É uma atividade tipicamente intelectual, onde é muito comum ocorrerem idas e vindas, já que o aprendizado adquirido com o seu desenrolar torna possível aos envolvidos perceberem maneiras cada vez melhores de fazerem as coisas. Este tipo de trabalho – não linear – funciona muito melhor de forma iterativa e incremental (em espiral).

1.8. Considerações finais

Este trabalho tem como objetivo principal mostrar em detalhes como funciona e quais as vantagens da Programação Extrema ou XP (Extreme Programming), que é a metodologia de desenvolvimento ágil mais conhecida na atualidade. Esta introdução é muito importante, pois aborda características comuns a todos os processos ágeis, incluindo, é claro, a XP, que apesar de ter sua identidade garantida por um conjunto rico de características próprias, em essência, é mais uma metodologia ágil.

Outros exemplos de metodologias ágeis são: SCRUM, Adaptive Software Process, Feature Driven Development (FDD), Crystal, Agile Modeling e Win-Win Spiral.

Abraços,
Vinicius AC.