Alguns pensamentos sobre “documentação ágil”

Existe um mito de que não se documenta em projetos que usam metodologias de desenvolvimento ágil. Não é bem assim, aliás, não chega nem perto de ser verdade.

A grande diferença entre projetos “tradicionais” e de desenvolvimento ágil é que os processos tradicionais geralmente são bastante prescritivos e você tem que documentar tudo que estiver definido no processo (que geralmente é muita coisa). Você não pensa no que está fazendo, simplesmente segue o que foi definido e escreve documentos. Em métodos ágeis não há prescrição de documentação (e o manifesto ágil fala também sobre “software funcionando mais do que documentação”), mas isso não significa que você não pode documentar nada. Muita gente confunde isso e diz que nunca se deve documentar em projetos “ágeis”, o que é um grande engano. Em projetos ágeis você pode documentar sem problemas desde que seja necessário de fato. A idéia é que você não deve perder tempo com nada que não seja requerido de verdade para o projeto.

Já participei de projetos onde documentar foi extremamente necessário. Por exemplo, uma vez trabalhei num projeto com vários times onde nem sempre os desenvolvedores estavam no mesmo espaço físico, portanto era preciso documentar alguns pontos chave da arquitetura e ambiente para que todos pudessem trabalhar sem problemas. Também já participei de situações onde meu time desenvolvia componentes que precisavam ser usados por outros times, e esses componentes precisavam estar bem documentados para que os outros times pudessem trabalhar adequadamente. Note que isso é totalmente diferente de documentar o projeto inteiro ou escrever dezenas de casos de uso. Documentamos apenas o que fazia sentido ser documentado.

Enfim, há diversas situações onde você pode precisar documentar por diversos motivos. Para te ajudar a decidir quando documentar e como documentar, veja a seguir alguns princípios do que chamei de “documentação ágil”. Essas são apenas algumas práticas úteis e princípios importantes que observei ao longo do tempo em diversos projetos de que participei. Certamente existe muito mais do que isso, mas vamos lá:

Documentação não substitui comunicação

Em projetos tradicionais, muitos documentos são usados para comunicar idéias entre o Analista e o Programador, com QA e por ai vai. Em desenvolvimento ágil o objetivo da documentação é registrar as informações por outros motivos (como os motivos acima). Se você estiver se comunicando por documentos, você já deixou de ser ágil há muito tempo. Documentação não deve ser usada para substituir a comunicação intensa e constante entre os membros do time.

Documentação não pode ser perecível

Documentação tem que ser leve e não pode ser perecível, ela deve ser durável. Se você documenta algo que precisa ser modificado todo dia, existem grandes chances de você esquecer de atualizar a documentação e ela passa a ficar desatualizada. É melhor não ter documentação do que ter documentação errada. Além disso, se você precisa mudar a documentação toda hora significa que você está se aprofundando demais nos detalhes, e então a documentação vai “quebrar” a cada linha de código que você escrever. Quando estiver documentando, pergunte-se: “daqui a algum tempo essa documentação ainda será válida?”. Faça documentação durável. Não entre num nível de detalhe que te faça mudar a documentação o tempo todo (a não ser que você realmente precise disso – e mesmo assim pense se não dá pra fazer de outro jeito, por exemplo, automaticamente).

Documente o necessário, e não mais do que isso

Assim como você deve implementar apenas o necessário para entregar uma funcionalidade e não mais do que isso, você deve documentar apenas o que for necessário e nada mais do que isso. Não perca tempo escrevendo documentação que nunca será usada por ninguém. Se ninguém precisa usar a documentação, então ninguém deve documentar. Documento tem que ter um motivo, documentar sem uma necessidade real não faz sentido

Documentar tem que ser fácil

Documentar tem que ser rápido, não pode dar trabalho. Use ferramentas como wikis, geradores de documentação (como o Sphinx) e por aí vai. Se for fácil documentar, as chances de você fazê-lo serão maiores. No caso de não usar wiki (ou alguma coisa online/web), use ferramentas para publicar a documentação automaticamente. Se a documentação for fácil de ser acessada (e tiver busca) ela fica mais útil. Além disso, prefira usar uma tecnologia fácil e conhecida para que todos os membros do time possam documentar. Por exemplo, se você escolher usar LaTeX, você está reduzindo as chances de designers documentarem, pessoas de negócio e outros membros não-programadores de um time.

Documentação faz parte do “Definition of Done”

Se o seu projeto precisa de documentação por qualquer motivo, a documentação deve fazer parte da “Definition of Done”. É melhor documentar no momento que as histórias estao sendo desenvolvidas – quando o conhecimento está fresco na cabeça – do que acumular um monte de débito e ter que pagar de uma vez só – quando você vai precisar conferir um monte de coisas que já estão prontas para documentar com precisão, o que vai te dar mais trabalho e consumir mais tempo.

Documentação no código pode ser um “code smell”

“Code smell” é um sintoma no seu código que pode indicar um problema maior. Muitas vezes códigos precisam ser documentados porque eles são desnecessariamente complexos. Sempre que possível prefira refatorar o código para ele ficar mais fácil de entender ao invés de escrever comentários (até porque muitas vezes o código muda e o comentário fica lá desatualizado, e isso acaba mais atrapalhando do que ajudando). Tenha uma boa suite de testes (uma suite bem escrita e organizada é uma especificação executável), use Domain-Driven Design para expressar melhor o domínio do software, metáforas, tenha um design simples, use design patterns, enfim, é melhor fazer com que o software seja mais bem escrito e não mais bem documentado.

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

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/

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

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 Castro 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.

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

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].

| 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

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

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)

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

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