É ágil sobre desenvolvimento ou gerenciamento?

Em um debate sobre o que é o Scrum, descobri que talvez eu não entendesse totalmente a coisa ágil. Parece-me que o Scrum (que certamente é considerado um processo Agile) tem tudo a ver com gerenciamento de recursos, sprints, funções e outras coisas que não têm nada a ver com TDD, programação em pares, CI, refatoração e outras técnicas e práticas centradas no desenvolvedor que eu pensava ( até agora) são o coração do ágil. Agora estou enfrentando uma dificuldade!

1) O Scrum é independente de saber se os desenvolvedores praticam práticas ágeis?

2) Você pode implementar o Scrum em uma equipe que não utiliza testes automatizados? não realiza refatoração ou não adere às práticas de programação ágil?

É um erro comum pensar que Scrum é igual a Agile.

Ser Ágil está seguindo os quatro princípios do Manifesto Ágil . O Scrum é um processo de gerenciamento de projetos consistente com esses princípios, mas não é, por si só, ser ágil. XP (TDD, programação em pares) é um processo de desenvolvimento, também consistente com esses princípios e consistente com o Scrum, mas não está sendo ágil. Integração Contínua, Entrega Contínua, DevOps, todos consistentes com os princípios Agile.

Siga os princípios, em primeiro lugar. Todas essas frases de efeito são apenas metodologias que as pessoas descobriram com sucesso para ajudá-las a seguir os princípios. Mas a parte principal de "ser ágil" é poder ajustar seus processos à vontade, onde eles não seguem os princípios do ágil.

O Scrum é independente de saber se os desenvolvedores praticam práticas ágeis?

Scrum é um conjunto de diretrizes que incentivam uma equipe a ser ágil.

Você pode implementar o Scrum em uma equipe que não utiliza testes automatizados? não realiza refatoração ou não adere às práticas de programação ágil?

Muito difícil, porque no final de cada corrida você deve ter um produto em funcionamento. Se você precisar fazer um teste de regressão manual completo para provar que está funcionando, é provável que isso seja inatingível.

Alistair Cockburn (um dos criadores do movimento Agile) diz isso sobre o Crystal Clear (uma faceta de sua metodologia Agile):

O Crystal Clear pode ser descrito para um ouvinte de nível 3 nas seguintes palavras:

“Coloque 4-6 pessoas em uma sala com estações de trabalho e quadros brancos e acesso aos usuários. Faça com que eles entreguem software testado e em execução aos usuários a cada um ou dois meses e os deixem em paz. ”

Essa é uma definição de ágil, reconhecidamente para a equipe de desenvolvimento experiente que sabe o que está fazendo e que pode confiar em fazê-lo. Então, isso significa que você precisa usar CI e TDD e Pair Programming e todas as outras coisas da moda? Simplificando ... Não.

Agile não é seguir um conjunto de processos, é sobre ser eficaz. O que isso significa para você depende da sua equipe e de como ela funciona, do que você acha útil. Se o TDD não ajudar você a produzir código funcional, pare de ouvir as luzes menores que gritam sobre ele na web e não o use! Se a programação em pares realmente ajudar sua equipe a se concentrar e a fazer as coisas, ignore qualquer um que diga que é uma perda de tempo e organize sua equipe como uma corrida de três pernas no dia de esportes da escola.

Eu agilei há muitos anos, tantos que nem percebíamos que estávamos agilizando - entregávamos iterações do produto todos os meses e alternávamos bugs corrigindo bugs e adicionando novos recursos regularmente. Fizemos absolutamente zero testes unitários, pois essas coisas não haviam sido inventadas e o livro de refatoração não havia sido escrito. Então, sim, você pode absolutamente agir com agilidade sem nenhuma das chamadas práticas ágeis.

Alistair também diz isso de Kent Beck:

Questionado sobre o XP e os cinco níveis do “Modelo de Maturidade em Capacidade do Software Engineering Institute”, ele respondeu com os três níveis de maturidade do XP:

1. Faça tudo como está escrito.

2. Depois de fazer isso, experimente variações nas regras.

3. Eventualmente, não se importe se você estiver executando o XP ou não.

Eventualmente, não se importe se você estiver usando XP ou não ... palavras sábias que devem lembrá-lo de não cair nessa armadilha .

Scrum é um sabor ágil que segue um padrão específico para atender aos objetivos da metodologia de desenvolvimento ágil. Você não pode seguir o Scrum e não ser ágil, mas pode ser ágil e não seguir o Scrum.

O Scrum não tem influência no uso de testes automatizados, o ágil tende a favorecê-los, mas eles não são de forma alguma necessários. A refatoração deve ser uma meta no ágil e no Scrum, mas geralmente é ignorada. não ter a intenção de refatorar nunca é realmente ágil.

É ágil sobre desenvolvimento ou gerenciamento?

O Agile é um conjunto de práticas de desenvolvimento de software para atender à flexibilidade e à rápida mudança de fase dos requisitos do mercado - ou a chamada entrega acelerada . Portanto, em termos gerais, trata-se de uma abordagem flexível para atender aos requisitos complexos do cliente, dividindo o trabalho em pequenas peças e fornecendo funcionalidade em iterações rápidas de 2 a 4 semanas.

No entanto, para atender a essa flexibilidade, a equipe de desenvolvimento precisa praticar práticas de programação Agile .

Descrição do Wiki em relação ao desenvolvimento de software Agile :

O desenvolvimento ágil de software é um grupo de métodos de desenvolvimento de software baseados no desenvolvimento iterativo e incremental, em que requisitos e soluções evoluem através da colaboração entre equipes multifuncionais e auto-organizadas. Promove planejamento adaptativo, desenvolvimento evolutivo e entrega, uma abordagem iterativa com prazo determinado e incentiva respostas rápidas e flexíveis à mudança. É uma estrutura conceitual que promove interações previstas ao longo do ciclo de desenvolvimento.

De fato, você pode usar o scrum em projetos que nada têm a ver com o desenvolvimento de software. É um método de gerenciamento de projetos / gerenciamento de equipes.

1) NÃO !!!! Scrum é ágil, o que significa que práticas de desenvolvimento ágil (TDD, programação de pares, IC, refatoração etc.) são muito importantes para todos os aspectos de um projeto Scrum. Vai ser muito mais difícil descobrir a taxa de execução de suas equipes, estimar o trabalho, definir o tamanho apropriado do sprint etc. se você não estiver usando essas práticas.

2) Sim, você pode implementar o Scrum em uma equipe que não adere às práticas ágeis, mas acho que isso realmente limita o potencial da equipe. Uma grande parte do motivo pelo qual o Scrum / Agile é tão bem-sucedido são os ganhos de desempenho e qualidade que você obtém das práticas de desenvolvimento ágil, essenciais para fornecer recursos completos de frente para trás a cada sprint.

Se alguém do seu grupo está tentando convencê-lo de que as práticas de desenvolvimento ágil são uma perda de tempo, acho que você deveria dedicar algum tempo para enfatizar por que essas práticas são sempre estressadas com o Scrum e com o Agile como um todo. Eles realmente fazem a diferença.