BT

Processos de software destroem a paixão dos desenvolvedores?

por Eder Ignatowicz em 16 Jun 2011 |

Em um post recente, James Turner, editor da O'Reilly, criou polêmica afirmando que processos de software destroem a paixão dos desenvolvedores. O principal motivo apontado foi o foco demasiado em processos pela indústria de software sem a consideração dos seus reais benefícios, e a consequente perda de motivação pela equipe.

O autor afirma que a indústria tem se voltado à criação de processos e métricas como única forma de garantir a qualidade de código. E que, se forem seguidas à risca as atuais melhores práticas, provavelmente estará sendo feito o desenvolvimento orientado a testes, exigindo-se um percentual de cobertura de código, fazendo-se code reviews periódicos e utilizando-se ferramentas de inspeção contínua, entre outras práticas recomendadas. E se a empresa usa Scrum, ele acrescenta, os desenvolvedores provavelmente estarão gastando boa parte dos seus dias gerando histórias e tarefas e planejando e mensurando o tempo consumido, com o objetivo de gerar gráficos gerenciais de burn-down e cumprir outras atividades gerenciais.

Em resumo, desperdiça-se grande quantidade do tempo das equipes em processos, e se dedica cada vez menos tempo à codificação de aplicações.

Segundo Turner, estaríamos vivendo uma espécie de loop gerencial que gera pioras progressivas:

Programadores motivados, "apaixonados", escrevem código excelente, mas o processo destrói a paixão e a motivação. Desenvolvedores insatisfeitos criam código fraco e os gerentes, por sua vez, reagem adicionando mais processos ao ciclo de desenvolvimento, na tentativa de melhorar a qualidade. Isso reduz ainda mais a moral da equipe – e o ciclo se repete.

A aplicação cega de melhores práticas em todo o processo de desenvolvimento estaria, ele argumenta, transformando um trabalho que deveria ser criativo em uma espécie de prisão. E acrescenta:

As empresas precisam reconhecer que existe uma diferença qualitativa entre os desenvolvedores. Exigir que todos, independentemente do seu nível, utilizem os mesmos processos é prejudicial à moral e à eficiência da equipe. [...] Talvez desenvolvedores iniciantes devessem se ater à escrita de testes unitários, liberando assim os mais experientes para trabalhar na verdadeira implementação das aplicações.

O artigo gerou uma grande quantidade de comentários no próprio blog do autor e no SlashDot. Edgar Zambrano, consultor da Tata Consulting, realizou em seu blog algumas considerações importantes, entre elas:

Estarão mesmo os processos de software destruindo a paixão dos desenvolvedores? Devemos repensar a forma como produzimos software? E seria realmente possível confiar que os desenvolvedores seriam permanentemente criativos, ao mesmo tempo garantindo que as mudanças na forma de produção não teriam impacto negativo sobre receitas e prazos?

Zambrano afirma, ainda, que embora não haja uma solução simples para o problema, deve-se buscar um equilíbrio entre a quantidade de processos e o estímulo à criatividade.

Se os processos estão oprimindo os desenvolvedores, é possível que não estejam sendo aplicados corretamente, ou que ainda não tenham sido adaptados à natureza do projeto.

Embora a criatividade e a paixão sejam essenciais, argumenta, talvez não sejam suficientes para o sucesso dos projetos. 

Deve-se focar em processos que aumentem as chances de que os projetos sejam finalizados no tempo previsto e com alta qualidade – lembrando que a criatividade pode também ser usada para a elaboração de processos melhores e de novas formas de trabalho. É dessa maneira que a engenharia de software abraça a criatividade e a pesquisa.

Zambrano conclui que o equilíbrio entre a paixão e o uso de processos deve ser buscado para cada projeto, através do aprendizado baseado em experiências anteriores. Recomenda ainda que deve manter uma abertura a novas ideias, padrões emergentes e lições aprendidas durante crises.

E você, leitor, sente-se no seu dia-a-dia beneficiado ou prejudicado pelos processos? É capaz de imaginar – ou mesmo trabalha – em um projeto de grande porte sem processos estabelecidos?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

É impossível sobreviver sem processo! by Leandro Guimarães

Vivendo ao lado de uma pessoa da área de humanas, minha esposa, tenho percebido o quão comum é, na área de TI, deturparmos o sentido das palavra com base em nossas práticas.


"pro.ces.so
sm (lat processu) 1 Ato de proceder ou de andar. 2 Sociol Sucessão sistemática de mudanças numa direção definida. 3 Concatenação ou sucessão de fenômenos. 4 Seguimento, decurso: O processo dos tempos. 5 Série de ações sistemáticas visando a certo resultado: O processo de fazer vinho. 6 Ação ou operação contínua ou série de ações ou alterações que ocorrem de uma maneira determinada: Em adiantado processo de decomposição. 7 Ação de ser feito progressivamente. 8 Filos Série de fenômenos que apresentam certa unidade. 9 Med Marcha ou progresso das lesões e sintomas. 10 Dir Ação, demanda. 11 Dir Forma ou maneira de tratar no foro uma demanda ou questão. 12 Dir Conjunto das peças que servem à instrução do juízo; autos. 13 Processamento. 14 Conjunto dos papéis relativos a um negócio."
(Michaelis)

Chama-me atenção a definição 5. E aí que reforço meu assunto: é impossível sobreviver sem processo. E por que isso?! Porque qualquer coisa, absolutamente qualquer coisa, que eu faça na minha vida eu faço segundo um processo. De comer um chocolate a programar uma estória de usuário. Geralmente eu faço as mesmas ações para comer um chocolate, assim como faço as mesmas ações para programar. Sendo assim, não adianta brigar ou espernear que você sempre estará seguindo um processo.

E vamos para a prática: o jeito que vocẽ resolve um problema é diferente do jeito que eu resolvo um problema que é diferente do jeito que um outro cara resolve um problema. Se cada um, trabalhando no mesmo projeto, for fazer do seu jeito, o caos se impera. E, ao meu ver, o estabelecimento de um processo de desenvolvimento de visa minimizar esse problema. E minimiza porque esse problema nunca some.

Mas por que o povo xinga tanto processo de desenvolvimento de software? Mil motivos. Mas os que eu mais destacaria são:

1. Muitos processos tendem a ir no detalhe do detalhe do detalhe. A tal ponto que um implementador vira, por exemplo, um mero tradutor de uma porrada de documento em código fonte. E isso é chato. É tipo Tempos Modernos do Chaplin.

2. Muitas pessoas julgam importante, só aquilo que elas julgam importante. E já é sabido que existe muito mais entre o céu e a terra do que imagina nossa vã filosofia. :)

3. O processo de eu comer chocolate não me enche tanto o saco porque se eu perceber que eu consigo comer chocolate de um jeito muito mais eficiente, eu vou lá, testo e aplico. Em empresas, geralmente não é assim: tem que passar pela área de processos que vai analisar a viabilidade daquilo, ver se está dentro do processo de alterar o processo e falar com os outros projetos e ver se aquilo não vai impactar os artefatos x y z. Enquanto isso, o pessoal dá um jeito de burlar o processo.

4. Processos tendem a extinguir a diversidade e substituir pessoas. E isso fala por si só, o tamanho do tiro no pé que é!

Não conseguimos viver sem processo! Mas quando temos um processo que mais nos atrapalha que nos ajuda, isso nos enche e, a partir disso, passamos a falar que processo não serve. Mas nós não vivemos sem eles.

Processos precisam ser vivos! Processos precisam ser eficientes! Processos precisam ser o mais transparente / natural possível. E, principalmente, o processo precisa aprender com a particularidade e não tentar eliminá-la.

Estou cansado de gerentes babacas by Pablo Leary

Sabe aquele cara que ja programou mais o que ele queria mesmo era mandar e nunca mais escrever uma linha de código. Então : um GERENTE BABACA.

Esta cheio desses no mercado. Que o que importa é social com o diretor. Entregar no prazo e as métricas fazem dele o bonito para empresa. Depreciando o real trabalho que quem realmente poe a mão na massa e fazem idéias tornarem-se REALIDADE.

Scrum = trabalho excessivo, é como você e fizesse o tudo que não e nada pro gerente B.
CMMI = quanto documentação, pra que ? pra vender produto.
Jira = ferramenta chata, sempre e preciso ficar postando , comentando e mais e mais ....

Quem gosta de programar , programa por paixão. Gosta de ver seu programa funcionando servindo os outros. Independente de prazo, custo e métricas.

A melhor empresa para programar é a minha, lá em casa, ouvindo música sem um gerente B. me enchendo o saco dizendo se já ta pronto.

Quando programadores se rebelarem, acabarão o gerentes babacas. TI realmente vai descobrir o real valor programadores.

Um abraço galera

Pessoas primeiro, metodologias e processos depois by Dirlei Dionísio

O problema é que muitos querem aplicar processos criados para trabalhos mecânicos - como apertar parafusos - a trabalhos intelectuais, como compor músicas, pintar quadros ou fazer software.

Mas quando se trata de um trabalho intelectual, o resultado final não depende da forma como o trabalho foi estruturado, planejado ou conduzido, mas do talento de quem o executa.

Para fazer bom software, é preciso uma equipe talentosa e boas condições de trabalho. Metodologias e processos serão de ajuda, desde que sirvam como um plano geral, constantemente adaptado ao tipo e às circunstâncias de cada projeto.

Quase verdade! by Narciso Benigno

Tenho observado bastante disso que o Sr. Turner postou, trabalhei em equipes com processos extremamente rigidos, era claro que ao passar do tempo percebe-se que muitas coisas são totalmente desnecessárias, falta as pessoas uma devida avaliação sobre o que elas estão fazendo realmente entregam qualidade, ou adiciona alguma utilidade ao projeto e as espectativas do cliente. Em fim, falta senso critico as pessoas de se questionarem!
Hoje trabalho em uma equipe scrum, aonde o processo é bem seguido, mas as pessoas tem bastante maturidade, tudo o que fazemos é repensado constantemente para ver se agrega (aliás existe retrospectiva para que?).
Então não é necessáriamente o processo que nos deixa bravos como desenvolvedores, e sim, práticas sem noção, ou que não fazem sentido em um determinado contexto que nos deixa chateados.
Apenas como exemplo, o burn down chart, adotamos a prática de só alterar as tarefas no kanban durante o dayly, para que a atualização do gráfico seja simples, não é necessário recontar as tarefas todos os dias, e o gráfico nos ajuda acompanhar o andamento do sprint.

Abraços

Re: É impossível sobreviver sem processo! by Fernando Ultremare

Leandro, justamente. Seja chamado do que for, processo ou não, o que importa é ser adaptativo , baseado em feedback contínuo, mas até que ponto?

A diferença está justamente ai. Quando você acredita que já possui as melhores práticas, o feedback acabou, agora você tem o que processo significa pra mim.

And that really kills developers passion.

Os dois lados by Rafael Nunes

Bem, estou sentado nos dois lados:
E do lado de quem programa, eu acho bem chato e desmotivante processos que engessam e limitam a minha liberdade na hora de desenvolver. E todos eles fazem isso, porque todos tornam a atividade mecânica e repetitiva. E isso senti em todas as metodologias que já tive contato: Scrum, RUP, Waterfall, etc.

Porém na cadeira de quem assina o cheque pra pagar a conta no final do mês, é muito complicado não saber quanto vou gastar e quanto tempo vai levar a brincadeira toda.

Ainda estou tentando balancear os dois lados.

Re: Estou cansado de gerentes babacas by José Filipe Neis

Pablo, com todo o respeito, "Independente de prazo, custo e métricas. ", isso foi piada, é isso?

É simples sair falando que "arrombem-se os processos, deixem-me desenvolver meu código sem pressão, do meu jeito!", mas infelizmente as pessoas não tem um nível mínimo de maturidade padronizado pra serem deixadas a seu bel prazer. Fato.

O gerente deveria se preocupar com essa maturidade pra poder deixar a equipe mais solta possível, mas quando falamos de projetos grandes, empresas grandes, muitas pessoas, não tem bala de prata. Precisa de um processo (pelo menos de pano de fundo) pra garantir que não se use 2 pesos 2 medidas, que é algo que desmotiva também.

É mais ou menos na linha que o Rafael colocou, tem que ter um balanço. Ficar no mimimi eterno sem olhar pros problemas do mundo real, pensando no ideal de greenfield projects em equipes de 2 pessoas pra um cliente que não se importa com dinheiro não vai melhorar a vida de ninguém.

José Filipe

Processo x Paixão by Diego Santiviago

Acredito que o processo funciona se as pessoas funcionam.

Exemplo:

De nada adiantar ter um processo (Espec. Func., Espec. Téc., Desenv., Testes, Homol.) se pode acontecer o seguinte:

- Uma especificação funcional extensa, que não é discutida com a equipe técnica, é ambígua e sem nexo;
- Uma especificação técnica escrita nas coxas e que não acompanha as mudanças de negócio;
- Uma programação ruim, com código difícil de dar manutenção e de ser evoluído;
- Uma execução fraca de testes, que não testa os casos mais importante de regras de negócio, testando somente CRUDs e formatação de campos;
- Uma homologação com quem não conhece onde o sistema será implantado.

Sendo assim, no 1o dia de implantação sentirão as falhas:
- Na especificação funcional os requisitos não foram escritos/levantados corretamente;
- Pelo problema acima, a especificação técnica que já era ruim, não faz mais sentido;
- A programação dificulta e muito, a modificação para atender realmente o negócio;
- etc, etc.

Quanto a isso, não imagino uma empresa com mais de 300 pessoas trabalhando em projetos enormes sem o mínimo de processo. Qual o controle que terá um projeto assim? Como o Chefão (Object) vai saber que o dinheiro que ele está injetando está sendo bem gasto? Ele não vai acompanhar de perto, projeto a projeto.

Re: Estou cansado de gerentes babacas by Pablo Leary

José,

parece piada né. Entendo.

Eu sempre trabalhei como programador, passei por algumas equipes, em empresas de pequeno e grande porte.

O que eu carrego é alguma desilusão de alguns ambientes onde eu trabalhei.Como o post fala sobre a desilusão, resolvi postar minhas mágoas.

O que os alguns gestores não compreendem(como já foi comentado aqui) é que eles estão lidando com egos, pessoas.

Deve ser ter processo ? Sim, concerteza. Isso é bom para o programador.

Agora...o que eu reparei é que: quanto melhor o processo, mais a "chibata dói". Todos os projetos que eu participei com Scrum, mais eu tive que trabalhar.

Programadores e Gestores costumam ser egocêntricos, usam a tecnologia ou o processo como uma arma para depreciar o próximo. Aquela velha frase : "Aqui é cobra comendo cobra".

Empresas o que mais tem é a politicagem, e o processo serve pra isso , no final da contas . E não para aumentar a qualidade do software como diz a teoria.

Programadores trabalham 12, 14 horas . E no final das contas são cuspidos como chiclete sem sabor. A única profissão que você sai da faculdade e abre uma empresa pra trabalhar. Essa é a realidade na cidade São Paulo.

N consultorias faturando o que você ganha por nada. Por negócio.

Então não estamos falando somente em desenvolver software, estamos falando em entrar no jogo podre. Essa é a realidade. O mundo Google eu nunca vi.

Se o programadores não pensarem em ser cada vez mais anarquistas. Logo, logo a sacanagem vai ser maior. Gerentes "Babacas". Sim são Babacas sim.

Psicopatas , pessoas sem poesia na vida.

O que dá me prazer em TI é refatoração, código limpo e liberdade by ROLIM FOR COMPUTERS

Todo bom desenvolvedor gosta de entregar um código de melhor qualidade possível, resolvendo todos os problemas importantes que ele conseguiu detectar. E isso rapidamente.
.
O problema é que há muitos que simplesmente não trabalham! Gastam longas horas em redes sociais na Internet e isso obriga os gerentes a pressioná-los.
.
Há sim gerentes estressados. Mas há muito mais desenvolvedores irresponsáveis.

Re: O que dá me prazer em TI é refatoração, código limpo e liberdade by Julio Faerman

Na minha opnião precisa haver o equilbrio, nem formalizacao demais, nem de menos, apenas a medida certa que funciona pra sua equipe.

Acho que estão esquecendo de... by André Luiz Cardoso

"Indivíduos e interações mais que processos e ferramentas"

Re: É impossível sobreviver sem processo! by Fabio Santos

Então Fernando, o que você sugere é um processo de feedback contínuo, certo?

Re: Estou cansado de gerentes babacas by Fabio Santos

Então Pablo, eu tenho participado de projetos Scrum há mais de 2 anos e o que percebi de lá prá cá é que o número de horas que eu trabalho por dia diminuiu significativamente, enquanto minha produtividade aumentou muito. É claro que não é do dia para a noite, mas o papel do gerente ficou bem reduzido com o empoderamento de outras pessoas, como o PO e o Scrum Master.

Concordo com o Leandro. Falar em inexistência de processo é paradoxal. Sem processo não existe atividade. O que importa é um processo dinâmico, com feedback contínuo e com o poder devidamente balanceado na equipe. Isso não é fácil de alcançar, muito menos fácil de manter.

Re: Acho que estão esquecendo de... by Frederico Augusto de Camargo

Exato!

É necessário viver o Manifesto Ágil! Scrum como processo é mero... processo! Processo pode até deixar a vida melhor. Mas é necessário incentivar a criatividade e tratar os membros do time de forma não genérica, tornando especiais suas atribuições!

E isso é o que de fato mantém a paixão.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

15 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2013 C4Media Inc.
Política de privacidade
BT