Como programador, você se importa com o método que o processo de desenvolvimento usa?

Estou no mercado de trabalho e tenho um conjunto de prioridades para o meu próximo emprego, incluindo salário, linha de negócios, etc. Uma coisa que não aparece em nenhum lugar da minha lista de requisitos é a metodologia do processo de desenvolvimento. Sinto que meu trabalho é criar software e vejo a estrutura do processo como algo em que posso me adaptar, seja scrum ou cascata ou qualquer outra coisa.

A metodologia do processo de desenvolvimento é uma prioridade para você?

É importante para mim apenas na medida em que não atrapalhe o senso comum que esperamos que a maioria dos profissionais tenha.

Quando falamos sobre controle de versão, há o argumento de que any version control beats not having anything at allesse não é o caso dos métodos de desenvolvimento. Métodos significam regras, e as regras às vezes são quebradas. Eu trabalhei para empresas que fazem coisas realmente bobas desde que alguém se lembra, qualquer que seja o problema que o procedimento bobão resolveu desapareceu há muito tempo.

Quero o seguinte de uma empresa:

• Procedimentos claramente documentados que cabem em algumas páginas. Se eu tiver que ler uma dissertação ou (pior) um romance para acelerar, ficarei perdido por um longo tempo.

• Evidência de que a empresa está aberta a mudanças de procedimentos para melhor. Eu preciso ser capaz de ir até alguém e dizer: "Eu sei por que você está fazendo [xyz], mas há uma ferramenta que faz a maior parte disso para você agora. Podemos usá-la?"

• Um pouco de competição pode ser bom e muitas vezes é inevitável. Mas evitarei qualquer loja em que a concorrência seja usada como principal meio de motivar as pessoas. Se você codificou algo que envia o número de linhas confirmadas por dia pelo desenvolvedor à impressora a laser às 17h, não quero trabalhar para você.

• Se você não impediu que as compilações nos repositórios abençoados recebessem alterações que quebram a referida compilação, eu corro como o inferno. A última coisa que quero fazer às 5:00 é puxar alterações do repositório principal para testar minha compilação local, apenas para me encontrar corrigindo o ponto e vírgula de outra pessoa.

• Prefiro pular para métodos que se assemelham a um método estabelecido que caiu da árvore ágil. Não é obrigatório, mas um senso de familiaridade ajuda a superar o obstáculo inicial de tentar ser produtivo sem cometer erros de procedimento.

Se perceber que passarei mais tempo ressentindo-me dos procedimentos do que agradecendo por eles existirem, provavelmente passarei o trabalho.

O outro retumbante "oh não, nunca mais!" é "Esperamos que você também configure as melhores práticas para nós. Temos seis milhões de linhas de código e 21 telecomutadores, deveríamos usar um SVN ou algo assim?" .

Alguém poderia se divertir resolvendo isso. Eu não sou aquele cara :)

Como desenvolvedor, me importo que o processo de desenvolvimento seja sadio. Várias metodologias de desenvolvimento diferentes podem fornecer um processo de desenvolvimento são. Por outro lado, uma empresa falida pode fornecer um processo insano, não importa como eles o chamam.

Portanto, não me importo particularmente com a "metodologia de desenvolvimento" oficial deles. No entanto, ainda vou perguntar sobre isso, simplesmente porque isso fornece um contexto para que eu faça perguntas de acompanhamento para descobrir o que elas realmente estão fazendo.

Sim, vi algumas metodologias ruins que acho que não gostaria de repetir novamente. Como alguns exemplos, considere o seguinte: você ficaria bem com um estilo de cowboy para uma equipe de uma dúzia de desenvolvedores onde todos podem usar seu próprio controle de fonte, convenções de codificação, etc.? Eu sei que não. Que tal onde alterar uma linha de código, há uma dúzia de formulários a serem preenchidos e cerca de 20 assinaturas para confirmar a mudança na produção que pode levar semanas para ser concluída, já que a aprovação da gerência sênior pode demorar um pouco? O "tanto faz" deixa as coisas um pouco abertas demais para minha mente, mas talvez eu seja um pouco ciencial aqui.

Como desenvolvedor, não me importo com a metodologia usada, desde que seja adequada.

Por exemplo, eu não gostaria de trabalhar para uma empresa que faz "codificação de cowboy" , especialmente se eles são ignorantes o suficiente para pensar que estão realmente fazendo Agile .

Prefiro lugares que tenham um método de desenvolvimento que todos possam realmente seguir.

Eu trabalhei em trabalhos que eram muito frustrantes por causa das opções de processo usadas para desenvolvimento e negócios em geral. Hoje em dia tenho alguns requisitos mínimos para o processo. Qualquer empresa que não se dedique a isso considero mal administrada e não funcionará. Eu não tenho paciência para a idiotice que costumava ter, então eu salvo a mim e a eles um monte de agravamento ao pular esses trabalhos.

Contanto que tenhamos alguma aparência de requisitos sensatos, algum representante comercial comprometido e receptivo e um entendimento de que a equipe de desenvolvimento tem uma grande participação nos prazos, então estou feliz e posso me encaixar em qualquer coisa.