Estou escrevendo um curso sobre o Agile para alguns dos novos integrantes que ingressamos recentemente, e quero adicionar um conto de advertência para que eles entendam que o Agile não se destina a todos os projetos.
Meu problema é que, devido à natureza dos projetos em que trabalho com o Agile, até agora, funcionei muito bem, não posso dizer honestamente o que pode dar errado e por que quando você o usa no tipo errado de projeto.
Quais são as coisas a serem observadas quando um projeto Agile dá errado?
Respostas:
O maior fracasso das equipes "Agile" é o resultado do chamado Cargo Culting . Essencialmente, as equipes desejam os efeitos de equipes ágeis bem-sucedidas para imitar as ações visíveis
Esses são os três que você verá consistentemente "aplicados" nesses ambientes, mas com muito pouco comprometimento em ser realmente ágil. De fato, você ouvirá a gerência dizer que estamos "agilizando". (Fuja dessas duas palavras, é um mau sinal.)
Você também ouvirá muito sobre dívida técnica, mas a definição de dívida técnica é "faça isso rápido e sujo e talvez possamos resolver isso mais tarde". (Tradução: faremos parecer que estamos preocupados com a manutenção, mas, na realidade, manteremos a mesma mentalidade da sala das caldeiras, porque foi isso que funcionou para nós no passado).
Outras frases-chave: "Eu sei que essas histórias não estão totalmente definidas, mas estamos agilizando para que possamos corrigi-las à medida que avançamos".
"Estamos fazendo desenvolvimento ágil, para que você possa acomodar o que eu preciso no sprint à medida que o identifico".
"Não podemos bloquear nossas histórias comprometidas no início do sprint, porque as necessidades continuam mudando no meio do sprint".
O principal indicador sobre se um projeto Agile será bem-sucedido é se o líder do projeto (scrum master ou qualquer outra função) teve experiência ou treinamento formal em liderar um projeto ágil. Muitas vezes eu já vi pessoas lerem sobre o Agile em um livro ou fazerem um curso de dois dias sobre ser um mestre de scrum e acharem que têm condições de implementá-lo com sucesso. Desculpe, não está acontecendo capitão.
fonte
Pessoas que não entenderam o que é ágil (era?) E o aplicaram a:
clientes que não estão disponíveis para comentar até o prazo
... e ameaçam ações legais posteriormente;
gerentes que mantêm os desenvolvedores afastados do cliente (provavelmente porque são um pouco mal pagos e podem saltar de navios, indo trabalhar para o cliente) e jogam o jogo do " telefone quebrado " em uma tentativa desesperada (muitas vezes bem-sucedida) em olhar ocupado e útil,
Veja também: gerenciamento de cogumelos , também conhecido como "mantido obscuro, alimentado com esterco" e chefes de cabelos pontudos . :)
equipes grandes demais para ir a qualquer lugar;
as empresas que mantêm sua folha de pagamento, outrora renomadas projetistas de arquitetura de sistemas, estão desesperadamente desviando a atenção do fato de terem perdido completamente de vista o ofício de codificação real, projetando demais as sagradas famílias UML magníficas, práticas e difíceis de realizar .
fonte
playing a game of "telephone"significa? Realmente não acho que editar era de forma alguma necessário ...O Agile não é adequado para contratos de prazo fixo ou preço fixo. Depois de se inscrever para uma fera, você precisa entregar. O Agile é muito bom no desenvolvimento contínuo para sempre, à medida que os clientes mudam de idéia e 'esclarecem' seus requisitos. Isso não ajuda você no dia em que o dinheiro acaba, mas ainda precisa terminar o trabalho.
O Agile é muito bom para a fase pós-projeto, quando você está fazendo atualizações incrementais e correções de erros.
O outro aspecto em que o Agile falha não é uma falha do Agile, é uma falha de pessoas que insistem em todas as coisas antigas, como documentação completa do projeto, projetos iniciais e linhas de comunicação ruins. (O manifesto ágil semi-arsed ).
fonte
Aqui estão algumas perguntas que podem ser úteis para procurar uma resposta em termos de encontrar um exemplo em que uma tentativa no Agile pode ser ruim:
Você já ouviu falar em "pseudo Agile"? Aqui estão algumas entradas de blog sobre isso:
Há algo a ser dito para empresas que podem ter sua própria visão do que é Agile e transformá-lo em outra coisa.
fonte
Trabalhei em uma equipe ágil de grande sucesso, bem como em algumas que tentaram o Agile, mas não consegui fazê-lo funcionar.
O bem sucedido teve os seguintes elementos:
A equipe de sucesso fez o Agile e fez muito bem. Eu acho que se você não tiver nenhum desses pontos acima, poderá falhar facilmente. A primeira e a segunda coisas andam de mãos dadas e, se você não tiver, o Agile não funcionará.
A equipe em que participei que não se saiu bem com o Agile também tinha alguns elementos:
fonte
Acrescentarei às ótimas respostas já postadas que, pela minha experiência, o Scrum ágil e especificamente só funcionará se a gerência e a equipe estiverem dispostas a dar muita visibilidade ao que está acontecendo.
Isso significa que em empresas públicas (governos, por exemplo), será muito difícil fazê-lo funcionar corretamente.
fonte
Ágil, na minha opinião, é tudo sobre a cultura da equipe que está praticando. Se a cultura é péssima, os membros da equipe não se dão bem e as pessoas não estão colaborando para cumprir os compromissos de sprint, então a cultura ou a equipe é deficiente.
No entanto, eu não diria necessariamente que o Waterfall funcionará necessariamente em um ambiente como esse, não é uma situação em preto e branco, muito pouco é realmente preto e branco.
Uma boa equipe Ágil é comunitária. Eles têm um espírito tribal de comunidade, onde todos os membros estão trabalhando para os mesmos objetivos. A equipe obtém sucesso ou falha juntos. Eles trabalham juntos na resolução de problemas. Um membro da equipe interrompe o que está fazendo com suas tarefas para ajudar um membro da equipe em dificuldades. Tudo é afundar ou nadar.
Quando não é esse o caso, torna-se rapidamente evidente o que está errado. Se os membros da equipe estiverem sentados, digitando em seus laptops ou enviando mensagens de texto ou zoneando durante o stand up diário, você não terá uma boa equipe Agile. Se seus gerentes de projeto estão aplicando todos os procedimentos, definições e terminologias do Scrum, mas todo mundo está apenas mantendo a cadência e prestando atenção, isso é apenas uma farsa bastante flagrante do que o Agile realmente é, e isso de várias maneiras leva à disfunção, ineficiência da equipe , prazos perdidos e projetos com falha.
Falha no Agile é, em muitos aspectos, pior do que uma equipe Waterfall moderadamente bem-sucedida e provavelmente tem taxas mais baixas de sucesso no projeto.
fonte
Não sei disso por experiência própria, mas hipoteticamente existem muitas circunstâncias em que o ágil não é a melhor opção.
Projetos cujo produto é essencial para a vida ou propriedade - Por exemplo, você não deseja usar o Agile para desenvolver o software que executa o seu marcapasso. Por quê? Porque você tem tolerância quase zero a erros. Considere um exemplo clássico de erro de programação na medicina em relação ao Therac 25 . É verdade que não foi construído com o ágil, mas o ponto é o seguinte: desenvolver uma vida ou propriedade crítica não é o lugar para dizer: "limparemos isso no próximo sprint" ou "não precisamos de ótimo, apenas bom". suficiente."
Projetos com muitos desenvolvedores juniores - o Agile espera uma certa autonomia dentro do grupo participante. Se não houver experiência suficiente na equipe, essa autonomia poderá funcionar contra você.
Projetos que exigem um maior grau de controle ou planejamento do que o tradicionalmente oferecido com o Agile.
Eu estou assumindo que alguém mais entrará em cena e ajudará com exemplos melhores, ou rejeitará este tripe que eu escrevi ;-).
Lembre-se de que quando a única ferramenta que você tem é um martelo, todo problema parece um prego. Nem todos os projetos são pregos.
fonte