Fábricas de Software

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.

 

Quem é o operário da programação
Conheça o perfil dos programadores que trabalham nas fábricas de software
Idade média
A maioria dos profissionais são jovens entre 20 e 30 anos, mas alguns tipos de tecnologia exigem a presença de programadores seniores
Formação
Há desde pessoas formadas em faculdades de engenharia ou ciências da computação até profissionais que fizeram apenas um curso técnico de programação
Salário inicial
Varia de acordo com a região. Em São Paulo, onde a remuneração é mais alta, um programador júnior ganha cerca de 1 000 reais por mês
Teto salarial
Varia de acordo com a região e a especialização do profissional, mas raramente ultrapassa 6 000 reais.Acima disso só para quem assume funções gerenciais ou comerciais

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

Auto-semelhança (Princípio – 4)

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

Benefício Mútuo (Princípio – 3)

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)

Economia (Princípio – 2)

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

Humanidade (Princípio – 1)

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

Continuidade da Equipe (Prática Corolário – 3)

 

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

Implantação Incremental (prática corolário – 2)

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