Sua equipe funciona bem sem seguir uma metodologia de trabalho (como scrum)?

Trabalhei em várias equipes pequenas nos últimos 9 anos. Cada um tinha boas práticas óbvias, como reuniões curtas, controle de revisão, software de integração contínua, rastreamento de problemas e assim por diante.

Nestes 9 anos, nunca ouvi muito sobre metodologias de desenvolvimento; por exemplo, nunca houve um "estamos fazendo scrum", ou "vamos fazer ágil", ou qualquer coisa além de uma referência passageira. Todas as equipes pareciam funcionar bem, sem seguir muito processo, estávamos apenas fluindo livremente e naturalmente funcionamos bem.

Alguém mais progrediu por longos períodos de tempo sem encontrar scrum / ágil / etc?

A única exposição que tive a estes é através de sites como este. Li perguntas como Sprint Meetings - Sobre o que falar ... e toda a conversa parece descrever quase robótica como pessoas que seguem uma máquina de estados finitos de metodologia. É realmente (embora exagerado) assim? Eu me pergunto se as pessoas que postam na internet apenas apoiam ruidosamente as "melhores práticas", com visões semelhantes de livros didáticos, não refletindo realmente como as pessoas trabalham ... Ou que eu encontrei algumas equipes inventando seus processos naturalmente.

Além disso (eu estou no Reino Unido, o que pode ser relevante) ... acho que se uma metodologia fosse introduzida em qualquer uma das equipes nas quais eu trabalharia, elas simplesmente a rejeitariam como boba e desnecessária ... em. Eu tenderia a concordar, seguir os processos parece um pouco natural. Isso é típico ou comum?

Mais de 20 anos de experiência em desenvolvimento aqui, e nunca usei uma metodologia formal. Nunca precisei deles, e não pretendo usar um no futuro. As metodologias podem ser boas para algumas pessoas, mas elas não substituem os programadores qualificados que escrevem códigos bons e testados.

Pessoalmente, acho que caberia a muitas pessoas se preocupar menos com a nova metodologia mais quente do dia e se concentrar mais na qualidade do código.

Honestamente, se sua pequena equipe tem trabalhado bem sem grandes incidentes por todos esses anos sem pensar em processo, você provavelmente estava fazendo alguma forma de agilidade. Tudo o que um processo ágil significa é que ele está em conformidade com o "Agile Manifesto" http://agilemanifesto.org/, que surpreende pouco a dizer sobre iterativos, storyboards etc. O primeiro inquilino do ágil é que você prefere "Indivíduos e interações sobre processos e ferramentas ". Qualquer equipe que trabalhe bem em conjunto não precisa pensar muito sobre o processo.

As diferentes marcas de ágil (como Scrum, etc.) são muito úteis se você tiver uma equipe nova que não está acostumada a trabalhar uma com a outra. Eles meio que definem a estrutura de como criar uma equipe coesa, que por sua vez criará um produto coeso.

Se o que você está fazendo está funcionando, continue fazendo. Se você está constantemente atrasado com as entregas, tendo que fazer rotineiramente horas extras ou ter que corrigir os principais erros após implantar algo - então algo está errado. É quando você faz uma série de pequenas alterações para corrigir os problemas.

Se está tudo bem e sempre está bem, então não há problema - introduzir uma nova (suas equipes seguirão algum tipo de metodologia - formal ou não) seria realmente uma perda de tempo.

Porém, onde as metodologias realmente ajudam é quando a equipe encontra problemas ou tem problemas de fontes externas - uma metodologia não apenas introduz boas práticas, mas também ajuda a protegê- las. É muito mais fácil manter as boas práticas sob estresse quando você as pratica conscientemente, caso contrário, elas podem ser rapidamente eliminadas.

Eu não acho que você precise necessariamente de uma metodologia formal - mas toda equipe precisa de algum tipo de padrão (não necessariamente repetitivo, pode ser motivado por eventos) para que seu trabalho seja eficaz no IMHO.

Se você não tiver nenhum problema para resolver, tenha sorte.

Eu já vi muitas equipes (especialmente em empresas muito pequenas) trabalhando bem sem nenhuma metodologia definida.

Implementar uma metodologia (ou técnica) porque é divertido ou porque você lê essa publicação na internet é muito perigoso.

Se você estiver bem, não mude nada. Apenas tente algumas otimizações quando puder.

Há uma vasta gama de metodologias, algumas bastante sensatas, outras à beira dos insanos. Todos eles parecem codificar o senso comum , dar-lhes um nome engraçado e depois vender muitos livros / seminários / etc.

Agora, se a sua gerência, ou mesmo a sua equipe, não tem senso comum e não possui organicamente suas próprias metodologias sensíveis (conscientemente ou não), então vale a pena estudar e incorporar as partes da metodologia. relevante para as experiências dessa equipe .

A imposição generalizada das mais recentes <insert-buzzword-here>práticas de trabalho pode causar mais confusão do que se pretende resolver. Mas normalmente pode fornecer muitas métricas de caixa de seleção que um gerente de linha que não codifica pode marcar com entusiasmo.

Talvez você não tenha chamado de ágil ou scrum, mas isso não significa que você não teve nenhum processo e não o estava usando.

Assim como o próprio desenvolvimento de software. Você provavelmente estará usando vários padrões de design, mesmo que não pense explicitamente sobre eles pelos nomes.