O que torna o desenvolvimento de software Agile tão atraente?

Atualmente, o desenvolvimento de software ágil está se tornando um chavão bastante divertido.

Como desenvolvedor, entendo o valor pragmático do desenvolvimento iterativo, mas (na maioria das vezes) não é uma opção dos desenvolvedores adotar uma abordagem ágil para o desenvolvimento de software. É uma escolha de gerenciamento de cima para baixo! Seja cristal, métodos ágeis, dsdm, rup, xp, scrum, fdd, tdd, o nome dele. Não é uma escolha de desenvolvedor.

Para todos os gerentes por aí, quais são as maiores razões para optar pelo desenvolvimento Agile quando (na minha experiência) a maioria dos gerentes nem sequer tocou um pedaço de código em sua vida!

Requisitos de mudança, entrega mais rápida

O Agile é atraente porque oferece a possibilidade de se adaptar às necessidades em mudança mais rapidamente (ou de todo) e entregar essas alterações ao cliente mais rapidamente.

É por isso que muitas empresas falham ao usar o Agile / Scrum: os gerentes não entendem que com grande poder (de definir datas de lançamento mais rápidas e alterar requisitos com frequência) vem a responsabilidade de confiar nos desenvolvedores para obter estimativas . Para o trabalho ágil, o gerente precisa estar disposto a reduzir o escopo.

Eles querem o poder de ambos.

Seguindo tendências

Às vezes, as pessoas fazem coisas, não por causa do mérito daquilo em que estão embarcando (ágil), mas apenas porque é popular e outras pessoas estão tentando fazer o mesmo.

"O que? Macrojam está fazendo Agile? Por que não estamos? Não somos lentos, somos Agile, caramba!"

Algumas pessoas não dão a mínima para o que é realmente ágil. É apenas um meio de justificar sua existência. Sheeple, pressão dos colegas, etc.

A codificação em si não é o principal motivo pelo qual os gerentes podem ser convencidos a selecionar o método ágil. O fato de você poder reagir mais rapidamente às mudanças de requisitos e prioridades é atraente. O 'gerente' no final precisa fornecer uma solução para o usuário final / cliente / seu gerente.

Se a funcionalidade que parecia fundamental ao iniciar o projeto puder ser abolida no meio do projeto e substituída por novos requisitos mais relevantes, essa é uma grande vantagem.

Também é importante que, principalmente (por exemplo, no scrum), cada entrega intermediária esteja quase pronta para ser colocada em produção. Ao mesmo tempo, as funções mais urgentes foram desenvolvidas primeiro. Portanto, caso o projeto seja cancelado devido a alguma decisão corporativa, o gerenciamento tem certeza de que você terminará com algo que funcionará e poderá ser colocado em produção.

Espero que isto ajude.

Aumente a visibilidade do que está acontecendo e aumente a produtividade

1. Os gerentes geralmente se interessam pela visibilidade que o agile traz, principalmente com o scrum. É um dos pontos de venda mais usados ​​nos seminários direcionados aos gerentes.

2. Maior produtividade também é comumente usada para atraí-los, pois é fácil de demonstrar (graças à visibilidade). Alguns evangelistas ágeis prometem a eles excelente produtividade de seus funcionários existentes. "O quê? Eu já estou pressionando-os como limões e você me diz que eu posso ficar ainda mais " ?

Muitos gerentes usam o ágil para esmagar um pouco mais seus funcionários e eu os vi usando o gráfico de queima como uma máquina de caça mais preguiçosa em uma grande empresa.

Resultado? Muitos se juntam distress. Eles pensaram que o ágil resolveria todos os seus problemas, mas fez exatamente o oposto. O problema estava em outro lugar.

Eu estou lutando ativamente contra isso. É por isso que, às vezes, onde há uma alta probabilidade de que a metodologia ágil seja pervertedpela gerência, sugiro não mencioná-la na empresa.

A resposta para essa pergunta pode encher um livro.

Eu acho que uma das principais razões é que o desenvolvimento ágil se concentra na entrega. Ele sempre se concentra em fornecer exatamente o que é mais urgente aqui e agora.

Outro motivo é que as práticas de planejamento e estimativa baseadas em histórias que os processos ágeis seguem fornecem uma estimativa muito melhor do que pode ser entregue e quando.

Um bom exemplo de quão eficaz é o planejamento baseado em histórias é um projeto em que trabalhei. Por alguns meses (antes de adotarmos o desenvolvimento ágil), o líder do projeto acreditava que poderíamos entregar a tempo, e isso era cerca de 18 meses a partir do prazo final. Todos os desenvolvedores tinham a sensação de que isso provavelmente não era realista. Depois de iniciar o planejamento ágil, o líder do projeto ainda tinha uma avaliação otimista da situação. Mas somente após alguns sprints, o líder do projeto percebeu que a equipe simplesmente não tinha capacidade para entregar todos os requisitos no tempo esperado. E isso ainda faltava mais de 12 meses para o prazo final.

Portanto, práticas ágeis também tornam a realidade clara muito antes.

E, finalmente, as equipes ágeis tendem a adotar com mais frequência práticas que criam melhor qualidade de código, por exemplo, desenvolvimento orientado a testes, refatoração frequente, integração contínua, revisão de código por pares / programação de pares, etc. Não que os projetos tradicionais de software proíbam essas práticas, eles apenas tendem a não ser tanto em foco.

a maioria dos gerentes nem sequer tocou um pedaço de código em suas vidas!

Fui desenvolvedor por 12 anos e agora gerente por 5 anos. Durante os 5 anos, mudei gradualmente de um gerente que ainda codificava para ser basicamente um gerente puro (eu ocasionalmente corrigo bugs ou faço exercícios de prototipagem).

Quais são as principais razões para optar por fazer o desenvolvimento Agile

• Visibilidade ou sucesso rápido / falha rápida - Somos uma loja de desenvolvimento de produtos com ciclos de 6 a 24 meses. O desenvolvimento iterativo com os recursos testados e funcionais fez um trabalho melhor ao refletir o status do projeto.
• Mudança - em nosso ambiente, requisitos e tempo tendem a ser fixos. Porém, os negócios regularmente passam por mudanças rápidas e dissonantes de direção. O desenvolvimento iterativo e visível facilitou a mudança de direção dos projetos.
• Os requisitos baseados em histórias com desenvolvimento iterativo tornaram mais fácil trabalhar com os negócios que nem sempre entendiam os aspectos técnicos dos requisitos ou entendiam completamente os fatores de negócios de alguns dos detalhes. Em nossos esforços anteriores, especificações de alto nível ou documentos de requisitos de marketing nem sempre eram suficientes. Agora, à medida que os projetos evoluem, pode haver alguma pesquisa paralela de mercado e de clientes.
• A mudança de processo veio com muitos outros atributos de desenvolvimento, como TDD, teste automatizado versus manual, ciclos de teste mais rigorosos (não temos mais um grupo de controle de qualidade, apenas um grupo de controle de qualidade) e uma valorização e esforço mais altos relacionados à qualidade (usamos um muito mais ferramentas e métricas).

Poderíamos ter conseguido isso de outras maneiras, mas alavancar metodologias e idéias ágeis nos ajudou imensamente.

Também continuamos refinando nosso processo. Por exemplo, o equilíbrio entre o trabalho inicial do projeto e o projeto logo antes da implementação. Revisamos todas as nossas decisões regularmente para determinar se poderíamos ter adiado decisões de projeto anteriores. E, quando as coisas dão errado, quanto mais trabalho inicial teria sido necessário até que o erro fosse identificado. Freqüentemente, falhas são casos extremos que requerem análise profunda. O esforço para obter esse detalhamento geralmente é o mesmo que o custo de descobrir isso ao longo do caminho e refatorar. As equipes não são penalizadas por esses tipos de erros e incentivadas a serem mais agressivas.

Já vi várias empresas "agindo". Infelizmente, muito poucos deles adotam agilidade. O que quero dizer é apenas fazer desenvolvimento iterativo e standups diários (onde a maioria da equipe se senta) não torna a equipe Agile. TDD, refatoração, integração contínua, presença do cliente, práticas do SOLID tornam a equipe ágil. Sem eles, você está andando em círculos.

Há muito apelo que a mensagem do Agile traz. A adaptabilidade à mudança é a maior. Infelizmente, seu código não se torna mais adaptável apenas porque você altera a maneira como gerencia o projeto. Até que mais empresas percebam isso, ouviremos mais e mais sobre projetos ágeis com falha.

Eu não sei sobre a parte da palavra da moda. Eu realmente tenho feito isso o tempo todo em um processo não tão formalizado ou identificado. Eu tive clientes literalmente olhando por cima do ombro enquanto criava o site deles. Economizou cerca de 50 e-mails e o cliente aprendeu algo sobre esse processo - não é fácil.

Toda a noção de que levaremos um longo período de tempo para anotar tudo o que o usuário deseja que o software faça, em seguida, levar um longo período de tempo para criar o que achamos que eles querem descobrir apenas dentro de 2 segundos depois de experimentar o aplicativo. não é o que eles esperavam é nauseante. Quão difícil é dividir qualquer projeto ou aplicativo em partes razoáveis ​​para criar e obter algum feedback antes de criar outra peça?

Sei que isso é uma simplificação excessiva e não aborda as práticas reais do desenvolvedor, mas não é difícil vender até mesmo para o gerente ou cliente não técnico. Que outra abordagem é mais atraente? Os clientes realmente amam o fato de que os programadores ficam sem cabelo por 6 a 12 meses enquanto desenvolvem durante algum projeto em cascata? Você contrataria alguém para construir uma casa dessa maneira?

A gerência não impõe essas coisas aos desenvolvedores. Desenvolvedores e equipes devem tomar iniciativa e se esforçar para que eles façam seu trabalho melhor. O trabalho da gerência é fornecer suporte para essas iniciativas.

Como gerente que escreveu uma boa quantidade de código em minha carreira, talvez eu não seja quem você está procurando para responder a isso. De qualquer forma, acho que a atração para o Agile hoje em dia tem mais a ver com responder às necessidades do cliente mais rapidamente, além de diminuir o ciclo de feedback entre especificação, codificação, teste e cliente. Estamos caminhando para um desenvolvimento mais ágil por essas mesmas razões.

Eu acho que você não deve mexer no processo Agile e nas práticas de codificação / desenvolvimento. Por exemplo, o Scrum não diz como você deve desenvolver seu código - é tudo sobre o processo que aceita mudanças.

No final do dia, trata-se de capacitar o desenvolvedor; trata-se de reconhecer o fato de que aqueles que estão na parte inferior da hierarquia são os únicos que realmente entendem a extensão do que precisa ser feito e como fazê-lo, por isso, se você já os contratou por sua experiência - por que não deixe que eles assumam o controle total ou melhor, por que distancia-los da tomada de decisão real?