Agile é o novo microgerenciamento?

80

Essa pergunta está me incomodando há um tempo, então eu queria perguntar àqueles que estão seguindo as práticas ágeis / scrum em seus ambientes de desenvolvimento.

Minha empresa finalmente se aventurou a incorporar práticas ágeis e começou com uma equipe de 4 desenvolvedores em um grupo ágil, em caráter experimental. Foram 4 meses com 3 iterações e eles continuam a fazê-lo sem ficar totalmente ágil para o resto de nós. Isso se deve ao fato de a confiança da gerência atender aos requisitos de negócios com uma solicitação bastante ad-hoc do tipo acima.

Recentemente, conversei com os desenvolvedores que fazem parte dessa iniciativa; eles me dizem que não é divertido. Eles não têm permissão para conversar com outros desenvolvedores pelo seu Scrum master e não têm chamadas telefônicas na área de trabalho (o que pode ser bom até certo ponto). Por exemplo, se eu quiser conversar com meu amigo sobre chutes que faz parte do time ágil, não tenho permissão sem a aprovação do Scrum master; que está sentado ao lado da equipe ágil.

A idéia de tudo isso ou o ágil é fornecer um vácuo completo para os desenvolvedores ágeis de qualquer interrupção e tê-los em boas 6 ou mais horas produtivas. Bem, pessoal, eu não sou um guru ágil, mas o que eu li sobre o documento de distribuição ágil do Yahoo e similar para outras organizações, me dá a sensação de que o ágil não é barato. Requer recursos e orçamento para instilar as equipes de maneira ágil e corrigir os problemas à medida que chegam para colocá-los de volta aos trilhos.

Para iniciantes, requer treinamento para desenvolvedores e treinamento para gerentes e etc, etc ... O atual Scrum master era um gerente que fazia alguns dias de aulas de treinamento ágil, pagas pela gerência, que agora lideram essa equipe ágil. Eu também ouvi na reunião que o manifesto ágil não determina que o ágil não é imutável e é personalizado de maneira diferente para cada empresa. Bem, tudo soa bem e razão.

Em conclusão, sempre achei que o ágil deveria trazer harmonia às equipes de desenvolvimento, o que resulta em desenvolvedores felizes. No entanto, estou tendo uma sensação muito oposta ao conversar com os desenvolvedores da equipe ágil. Eles estão tristes por não poderem falar nada além de trabalhar, ficarem quietos o dia todo trabalhando, e sentem que é apenas outra maneira de a gerência fazê-los trabalhar mais.

Diga-me, por favor, se este é um dos exemplos de boas práticas usadas com o objetivo de obter uma vantagem egoísta por mais dólares? Ou talvez, somos apenas nós, os desenvolvedores como eu, e essa equipe ágil acha que não gosta de trabalhar em um ambiente em que apenas respira trabalho porque está trabalhando.


É uma empresa no domínio da saúde, com escritórios nos EUA. Definitivamente, parece um estilo ágil de caubói, o que me faz realmente não querer ser ágil, principalmente na minha empresa atual.

Tudo isso tem a ver com a gestão ser completamente barata. Cortar café caro para uma versão mais barata, ênfase na economia e ser produtivo, mantendo-se o mais enxuto possível.

Meu sentimento é que alguém da gerência atrás da porta jogou fora essa ideia, que o ágil faz você produzir mais para que possamos mostrar aos nossos chefes que estamos produzindo mais com o mesmo número de funcionários. Ou, talvez, nos permita reduzir o número de funcionários, se for esse o caso.

Eles estão tendo sua reunião diária de 5 minutos. Mas não é permitido conversar ou conversar com alguém fora da equipe. Todo o foco está no trabalho.

Smith James
fonte
71
Já vi mais abusos em nome do ágil do que gostaria de comentar. Muitas vezes "estamos agilizando" significa "estamos jogando fora toda aparência de processo e fazendo o que queremos, Yeehaw!" (para a referência óbvia ao cowboy). Um ambiente silencioso definitivamente ajuda, mas você precisa permitir que os desenvolvedores conversem entre si e planejem as coisas - sem a aprovação do ditador do scrum .
Berin Loritsch 15/03
28
Bem, você não está fazendo Agile ...
CaffGeek
13
Este é realmente um discurso. Não é uma pergunta.
JohnFx
8
Dois dias no curso certificado de scrum master não tornam o gerente um scrum master, assim como 24 horas com ensine a si mesmo c ++ em 24 horas não o torna um programador c ++ capaz. Eles estão fazendo errado.
Matt
9
leitura obrigatória: Half-arsed Agile Manifesto "Ouvimos sobre as novas formas de desenvolver software, pagando consultores e lendo relatórios Gartner ..."
mosquito

Respostas:

89

Você está descrevendo a ditadura gerencial, não a agilidade. Agile é sobre desenvolvimento incremental em um campo de requisitos em mudança, não sobre ditar as pessoas como elas individualmente realizam seu trabalho.

Sami Lehtinen
fonte
7
A única coisa que pude encontrar foi um post sobre "Joel on Software" nas 12 principais coisas que toda empresa deve fornecer aos seus programadores. Um dos 12 era um lugar tranquilo para trabalhar. Duvido que Joel Spolsky quis dizer isso, no entanto.
Berin Loritsch 15/03
5
Um local de trabalho silencioso seria aquele em que, se você não está tendo uma conversa, as coisas geralmente são silenciosas e onde você pode conversar sem incomodar os outros. Isso significa que não há cultura de chamar pessoas pelo interfone e usar geradores de ruído branco ou outros métodos para minimizar o nível aparente de som nas áreas em que muitas pessoas trabalham. Uma regra de não falar não cria um ambiente de trabalho silencioso.
precisa
5
@ Kevin Cathcart, estamos em um acordo violento sobre isso. Agora, eu estive em uma empresa onde o oposto era verdadeiro. Tínhamos ~ 40 pessoas em um cercado com mesas abertas e sem cubos. A única equipe que conseguiu fazer alguma coisa foi a que fez a maior parte do barulho. Esse é o tipo de ambiente que você deseja proteger.
Berin Loritsch 16/03/11
8
@Kevin - Meu departamento de desenvolvimento é uma fazenda de cubículos abertos, ao lado de uma série de três sinos denominados "Venda", "Grande Venda" e "Grande Venda". Algumas vezes por dia, os vendedores tocam e gritam "wooooo!". : - \
Dan Ray
2
@ Dan Eu tive uma série de entrevistas alguns anos atrás, onde três startups me disseram que tinham que afastar os vendedores dos desenvolvedores, porque eles eram muito!
amigos estão dizendo sobre erik
46

Eles não têm permissão para conversar com outros desenvolvedores pelo seu Scrum master e não podem receber chamadas telefônicas na área de trabalho

Isso realmente não faz parte das práticas ágeis - e uma questão separada.

Uma grande motivação das metodologias ágeis é o aumento da comunicação entre os desenvolvedores. Restringir a comunicação do desenvolvedor <-> desenvolvedor é um problema separado das práticas ágeis. Não estou dizendo que isso não está acontecendo - obviamente está, e está sendo rotulado como parte do lançamento "ágil" da sua organização, mas esse é realmente um problema separado do ágil (e um pouco contra o espírito do desenvolvimento ágil, OMI).

Reed Copsey
fonte
29
É absolutamente contrário ao primeiro princípio do Manifesto Ágil: "Indivíduos e interações sobre processos e ferramentas". Veja agilemanifesto.org para mais informações.
Berin Loritsch 15/03
"É absolutamente contra o primeiro princípio do <XXX> Manifesto"; substitua qualquer coisa por XXX e você terá seu culto de escolha. ;-) Sério, isso não faz você pensar?
CesarGon
5
@CesarGon, neste caso, estamos falando sobre os princípios do que torna o trabalho ágil. Se você não pode atribuir os princípios básicos do ágil, talvez não queira o ágil. Bem simples. Não estou dizendo "converter à fé", estou dizendo "faça o que você diz que acredita". A sério, não que fazem você se perguntar?
Berin Loritsch 16/03/11
1
@ CesarGon, o que o OP descrito é sobre o oposto polar da intenção dessa diretriz, como você pode obter. Em que ponto você considera seu tom médio perto o suficiente? A maneira como você está falando parece que uma diferença de 95% entre os tons está próxima o suficiente. Vamos lá. E me dê algum crédito. Estou trabalhando no mundo real e definindo processos nas empresas há muito tempo. Entendo muito bem o que está próximo o suficiente - e o que o OP descreveu não é isso.
Berin Loritsch 16/03
2
@Berin Loritsch: Eu dou crédito a você; não era minha intenção parecer diferente. Minha observação inicial sobre cultos tentou parecer parcialmente brincadeira, na verdade. O que estou tentando enfatizar é que não precisamos de algumas linhas em um manifesto para defender algo que é descaradamente contra o senso comum. O OP descreve uma situação que faz todos os alarmes tocarem. Espero que você aceite bem; desculpe se eu era muito duro. :-)
CesarGon
31

Isso soa como uma implementação bastante perversa do ágil. O Agile, se houver, deve reduzir o microgerenciamento, não aumentá-lo. A equipe se compromete e parte do processo é que a gerência confia que a equipe o cumprirá. O scrum diário é uma maneira de os desenvolvedores se comunicarem entre si e uma maneira de informar o que eles fizeram, não como eles gastaram seu tempo (que é um erro que eu já vi em alguns lugares). Mesmo o processo de estimativa deve remover o tempo explícito, mantendo as estimativas, já que você deve estimar a complexidade relativa, não o tempo que uma história levará (outro erro comum). Controlar o tempo gasto pelos desenvolvedores é a marca do microgerenciamento, e remover o tempo do processo é um dos princípios básicos do ágil.

jjb
fonte
24

O ambiente que você descreve parece uma besteira pseudo-ágil de variedade de jardim .

Eu me envolvi com o Agile antes que fosse Agile. Por volta de 2000, eu estava esgotado com a codificação, ouvi falar sobre Extreme Programming, tentei e gostei. Ele me proporcionou como desenvolvedor um contexto em que a produção de software sólido era a coisa mais importante e me deu ferramentas para minimizar muitas besteiras que estavam me deixando louco. Eu amei.

O problema hoje, que explico em detalhes em outro lugar , é que a maioria das pessoas que "adota o Agile" hoje em dia não está interessada em melhorar nada, se isso as deixa desconfortáveis. Então, para eles, "Agile" é apenas um novo recurso para vencer os desenvolvedores da mesma maneira antiga. Em vez de, digamos, uma maneira de aumentar radicalmente a produtividade e remover todas as besteiras que estão atrasando o desenvolvimento.

Agora mesmo. Estou iniciando uma empresa e vou usar muito XP, além de vários outros truques que aprendi no mundo ágil. Mas, precisamente por causa de histórias como a sua, eu me encolho sempre que ouvi sobre uma adoção do Agile hoje em dia.

Então, para responder sua pergunta diretamente: Agile não deve ser o novo microgerenciamento. Deveria ser sobre capacitar as pessoas que estão fazendo o trabalho real para fazer merda. Mas no seu caso, o Agile parece a mentira mais recente que eles estão dizendo, enquanto desfrutam de seus próprios instintos ruins. Pelo qual realmente sinto muito.

William Pietri
fonte
4
+1. Agile / scrum / xp ou qualquer outra coisa são termos "mumbo jumbo" para lojas de TI que não são empresas de software reais. Como você disse, ninguém pode fazer mudanças radicais enquanto enterra a cabeça na areia com essas práticas. Tudo o que você precisa ler é esse ótimo Lean Software Development: An Agile Toolkit e deixar tudo para trás. Essas práticas não são para lojas de TI, é minha conclusão.
Smith James
23

Isso não é ágil.

Em primeiro lugar, Scrum não é ágil . Scrum, francamente, é besteira. Fui criado em uma casa de Extreme Programming (literalmente - tive Kent Beck sentado no sofá do meu pai e conversando comigo sobre os testes), e posso dizer diretamente que Scrum não é. Scrum é uma ferramenta de gerenciamento de projetos - um ritmo definido para um projeto de desenvolvimento. Mas não há nada a dizer sobre o desenvolvimento em si e muito pouco a dizer sobre requisitos, planejamento e relacionamento com o cliente. XP tem muito a dizer sobre tudo isso; qualquer outra metodologia que queira se chamar ágil precisa ter algo a acrescentar à conversa. Os proponentes do Scrum o descreveram não como um processo, mas como um invólucro para um processo. Um homem sábio uma vez apontou que um invólucro é a coisa que você remove e descarta para obter as coisas boas.

Ok, scrum falou alto!

Em segundo lugar, um princípio fundador do XP, que acredito ser fundamental para qualquer processo ágil, é que ele esteja centrado no desenvolvedor . É uma maneira de dar aos desenvolvedores o poder de fazer o trabalho que eles sabem que precisam fazer, e são frequentemente impedidos de fazer. Uma equipe ágil pode ser estruturada como uma democracia ou uma autocracia, mas os líderes são desenvolvedores. Existem funções para gerentes de projeto e assim por diante - funções vitais - mas não são de liderança de equipe. Ter um gerente - desculpe, 'scrum master' - sentado lá mandando as pessoas ao redor é um sinal claro de que a equipe não está agilizando.

Eu sinto que deveria haver um terceiro. Não existe.

Tom Anderson
fonte
-1, eu não concordo. Desenvolvimento ágil também significa que você purifica e facilita processos e também a capacidade de se adaptar às mudanças. O que passa a ser exatamente o que é o Scrum. O Scrum também trata de requisitos e planejamento, de maneira diferente.
Falcon
6
Ah, vamos lá, é 2012. Cite a redação pública de Kent Beck ou deixe-a. Não importa se ele lisonjeava no seu sofá.
nes1983
6
@ nes1983: Escrevi isso em 2011. As coisas eram diferentes então.
Tom Anderson
3
Eu nunca ouvi o termo "dívida técnica" até o scrum aparecer no meu radar. Eu estive no treinamento. O Óleo de Cobra facilmente vendido, destinado a atrair a gerência em detrimento de considerações de qualidade de produtos a longo prazo. 100% besteira. Embora eu o engolisse totalmente se o Scrum Masters carregasse uma espada no estilo Conan para atacar pessoas que ameaçavam a integridade do processo.
amigos estão dizendo sobre erik
2
+1 para o discurso Scrum. Penso no Scrum como a metodologia "Agile" para pessoas que gostam tanto de cascata que desejam fazê-lo a cada duas semanas.
Kyralessa
16

Scrum é o filho bastardo de Agile. É o estilo mais cascata de todas as metodologias ágeis, e é por isso que é o mais popular entre os gerentes.

Todos os métodos ágeis são sobre a produção de código de trabalho sem porcarias. Leia isso de novo. E de novo.

Qualquer coisa que atrapalhe esse objetivo, independentemente das "regras ágeis", é ruim. Se as regras atrapalharem, mude as regras f * * ! Essa é a maneira ágil, é o que a torna relevante e eficaz.

O melhor exemplo disso é dado por Alistair Cockburn (um dos criadores do manifesto ágil):

“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. ”

Se isso funciona para a qualidade dos caras que você tem, então é tudo o que você precisa. Você não precisa de um scrum master ou de qualquer metodologia "ágil". Se sentar-se em um scrum diário funciona para você, então f * * * fazê-lo. Fazer você se levantar é apenas uma revogação patética de sua capacidade de pensar por si mesmos.

Há uma resposta para o tipo de agilidade que você está fazendo. É isso. Imprima e prenda em algum lugar quando não houver mais ninguém por perto e deixe que descubram por si mesmos.

gbjbaanb
fonte
Eles entregam software em execução e testado aos usuários, a cada 2/3 semanas, você quer dizer?
User272671
2
@ user272671 NO. Faça com que eles entreguem regularmente software testado e em execução ao usuário. Não com um cronograma estupidamente arbitrário, como 2 ou 3 semanas. Se a complexidade dos usuários ou do software for tal que um ciclo de 6 semanas funcione, faça 6 semanas. Se isso puder ser feito quando "concluído", faça isso. Não se limite com restrições artificiais. Tal não é ágil.
Gbjbaanb
11

O atual Scrum master era um gerente que fazia alguns dias de treinamento em ágil, pago pela gerência, agora lidera essa equipe ágil.

Esse é o seu problema. Os gerentes querem um pouco de Agile, não sabem realmente o que é e o impõem às equipes. Isso é basicamente o que fazer quando você deseja diminuir significativamente a produtividade de seus desenvolvedores;)

A nova proposta de processo deve vir dos desenvolvedores. Ou pelo menos ser revisto e aprovado por eles, se for uma idéia da gerência.

De qualquer forma, se os desenvolvedores recusarem, não implemente ! Ou será o desastre que você descreve.

user2567
fonte
9

O "Agile" e todas as outras "metodologias de gerenciamento" são frequentemente abusadas para forçar o microgerenciamento das pessoas. Às vezes, também é abusada a OTOH para defender o acabamento inadequado.

"somos ágeis" é a desculpa mais frequente que escuto por falta de planejamento, falta de pensamento sobre design, recursos, qualidade e ciclos de lançamento. Isso geralmente é de desenvolvedores e gerenciamento inferior. É loucamente também a desculpa mais usada que ouço de gerentes de nível médio, arquitetos, vendedores etc. para microgerenciamento, prazos e listas de características sempre em constante mudança, forçando horas extras do massiver nas pessoas (os prazos e características constantes em constante mudança garantem que, é claro) etc. etc. .

Os dois obviamente estão em contradição direta e podem acontecer no mesmo projeto.

jwenting
fonte
Na minha experiência .. eu só ouvi o ágil (sempre scrum) apresentado para explicar o microgerenciamento. Não vou negar, é um estilo diferente e único de microgerenciamento. Nunca ouvi um desenvolvedor dizer que é ágil e explicar uma breve vinda. Que tipo de scrum forçado de gerenciamento você já experimentou?
JM Becker
1
sempre que encontrei o scrum, ele era apresentado porque um gerente (geralmente superior ao gerente de projetos) ouvia falar dele como "a coisa".
jwenting
7

Para responder à sua pergunta original, o Agile é o novo microgerenciamento, eu diria que não.

Primeiro, leia este (manifesto Agile) e você notará que não está falando com seus co-desenvolvedores não está listado.

Na verdade, "Indivíduos e interações" é exatamente o oposto de não falar com seus co-desenvolvedores.

Ian
fonte
Bem, "Indivíduos e interações" são o que eles estão fazendo agora dentro de sua equipe. Como está indo contra o manifesto ágil, se você olhar do ponto de vista mestre do Scrum? O problema agora é que eles não devem ter nenhuma interação com outras equipes para manter sua produtividade, o que é a causa da reclamação do grupo ágil.
Smith James
Eles não estão interagindo. Esse é o problema. Claro que um desenvolvedor pode abusar de privilégios e falar sobre coisas sem sentido por horas. No entanto, a maioria dos bons desenvolvedores deseja entregar um projeto de qualidade. É uma questão de orgulho. Tudo o que o mestre de scrum está fazendo mina isso e, em vez disso, torna-o uma questão de repressão. Não é disso que trata o ágil. Um mestre de scrum deve permitir que a equipe seja produtiva, não estique um chicote e diga que seja produtiva. Eles já querem ser produtivos.
Berin Loritsch 16/03/11
2

Agile deve ser o novo autogerenciamento. Se o ágil for praticado corretamente, muitas das decisões serão tomadas por um cliente e desenvolvedor que trabalha com uma história de usuário com escopo razoavelmente adicionado ao backlog à medida que as tarefas são identificadas.

O scrum diário é sobre comunicação, não gerenciamento. Haverá algumas discussões sobre prioridade e balanceamento de carga, mas a pessoa gerenciada no scrum é esperançosamente o mestre do scrum. Como desenvolvedor, assisto, digo o que fiz, o que vou fazer e de que ajuda preciso. Então o scrum master deve entrar em ação, eliminando impedimentos ao meu progresso.

As equipes ágeis não devem sentir que o trabalho diário é gerenciado hierarquicamente. Se as decisões são tomadas de longe por alguém no topo de uma organização hierárquica, é hora de descentralizar a tomada de decisões! Para algumas pessoas e algumas organizações, isso pode ser uma ponte longe demais. Se o seguinte não se aplica à sua organização:

Viva o manifesto ágil

"Estamos descobrindo maneiras melhores de desenvolver software, fazendo isso e ajudando outras pessoas a fazê-lo".

Evite "Conheça o novo chefe, o mesmo que o antigo chefe". Crie o Agile de dentro da equipe o máximo possível. Às vezes, isso acontece escolhendo uma coalizão de dispostos a participar de um projeto de teste usando o Agile. Se você pode formar sua equipe Agile a partir de voluntários ou membros convidados que tenham um histórico de bom trabalho em equipe, eles podem resolver isso. Use uma equipe pequena em um projeto curto, talvez para um cliente interno ou altamente acessível.

Aceite a mudança. Talvez você possa fazer algum treinamento, mas talvez seu orçamento seja pequeno e o dinheiro simplesmente não esteja lá. Outras oportunidades também podem melhorar. Faça alguma leitura, peça aos membros da equipe que aprendam o que podem sobre o Agile e ensinem uns aos outros. Você pode encontrar uma equipe nova ou existente qualificada para modelar e liderar na adoção do Agile.

DesenvolvedorDon
fonte
1

Equipes ágeis são como times de futebol trabalhando em direção a um objetivo comumente entendido. Faço parte de equipes ágeis há alguns anos e a chave é a comunicação eficaz e eficiente entre todos os interessados. Os gerentes / mestres de Scrum são meros facilitadores da equipe e a gestão / microgestão tradicional matará o espírito da equipe.

Nas equipes em que trabalhei, somos incentivados a jogar jogos em equipe após o horário de trabalho para melhorar a camaradagem entre os membros. Eu coletei esses pensamentos aqui .

Vinod R
fonte
1
Desenvolver relações de trabalho após o trabalho. Devemos desenvolver nossos amigos e familiares, muitas vezes negligenciados, depois do trabalho. Considerar que os colegas de trabalho raramente são amigos e aproveitam a maioria das oportunidades para se ajudarem às custas dos outros. A empresa sim-homens, amigos e ferramentas simplesmente não percebem isso, porque as oportunidades são raras. XP pode ter algum valor, não tenho experiência para dizer o contrário. O Scrum se tornou uma versão diferente do microgerenciamento, pelo menos nas três empresas que eu conheço. .... Sabe, eu odeio demais a América corporativa para ser um pouco objetiva.
JM Becker
0

Para responder à sua pergunta: Não. O Agile não é uma forma de microgerenciamento. Mas, como qualquer ferramenta, as pessoas podem usá-la incorretamente. O Agile é maravilhoso quando implementado corretamente e quando as pessoas são consistentes com ele.

Meus pensamentos sobre o tópico "Os desenvolvedores não estão falando com ninguém além do scrum master":

Eu trabalhei em um lugar onde isso era uma regra antes. No entanto, a regra estava mais relacionada a pedir às pessoas para concluir tarefas. Por exemplo, não posso ir aleatoriamente a um testador de desenvolvimento e pedir que ele faça alguns testes para mim nas próximas horas. Preciso conversar com o scrum master para que eles possam discutir com o membro da equipe como esse trabalho se encaixará no sprint se for uma emergência (ou se precisar ser enviado ao backlog para um sprint futuro).

Nesse caso, entendi o conceito de "desenvolvedores que não falam um com o outro" porque ele realmente se traduzia em canalizar tarefas por meio de um ponto de verificação, para que um desenvolvedor em particular não estivesse sobrecarregado ou estivesse tão ocupado executando tarefas de emergência que não conseguiria planejar Trabalho feito.

Caso contrário, os desenvolvedores DEVEM estar conversando entre si. Sempre. Ele ajuda você a resolver os problemas mais rapidamente, se aproximar como uma equipe e entregar mais rapidamente.

Só para oferecer outra perspectiva: eu também já estive em um ambiente em que as pessoas pensavam que os desenvolvedores "conversavam demais". Após uma sessão, descobrimos que, na verdade, traduzidos para "desenvolvedores não são independentes o suficiente para realizar seu próprio trabalho. Como tudo é tão fragmentado, os desenvolvedores precisam procurar outras três pessoas para realizar tarefas pequenas".

Portanto, quando os gerentes decidiram mudar para o ágil, eles esperavam que isso ajudasse a levar as informações aos lugares certos e interromper muita fragmentação dentro da organização. Algumas pessoas ficaram meio decepcionadas que, depois que o Agile foi implementado, os desenvolvedores ainda estavam correndo um para o outro. Mas o que eles não perceberam é que isso acontecia cada vez menos. Demorou um pouco. Então, talvez se isso é o que está acontecendo na sua organização, pode ser que as pessoas esperem que sejam ágeis para consertar as coisas da noite para o dia. Não é assim que funciona.

JustBlossom
fonte
-1

O autor original Smith Janes pode ter dado experiência. Mas esses são os problemas típicos que encontrei no projeto Agile.

  1. Na maioria das organizações, os desenvolvedores devem trabalhar em vários projetos, no Agile / Scrum. Sprints nunca são considerados esse fato. seu Scrum Master assume que você deve terminar suas histórias no final do sprint. Seu Scrum Master pode ser dedicado a apenas um projeto, mas não aos desenvolvedores. ESTA É A DISTRACÇÃO-- não precisa ser apenas uma ligação telefônica ou permitindo uma ligação.
  2. Eu vi projetos Agile nos quais o Sprint é planejado, as histórias incluídas no Sprint, sem ser encolhidas ... no meio ou no meio dos sprints .. desenvolvedores descobrindo dependências não resolvidas, requisitos ou história não concluída, narrada ... é um dos abusos na maioria dos projetos ágeis.
  3. Teste: TTD .. sim, é muito bom .. mas eu vi a maioria dos projetos Agile confiando totalmente no TTD ... nenhum escopo ou tempo permitido para testes funcionais ou humanos .. Outro abuso ... Muitos Scrum Masters também não conhece nem entende a importância dos testes funcionais. Seu pedaço de código pode estar funcionando perfeitamente, se não atender às necessidades da empresa .. é inútil .. Isso acontece quando a empresa não participa bem à frente .. ou a participação existe ... mas não reflete a tomada de decisão da empresa .. No final, os desenvolvedores são culpados, você não entregou a funcionalidade .. ou ela terminará com alterações de última hora ... horas extras porque o mestre do Scrum não quer se responsabilizar pela história não concluída.

Abuso aqui ... baixa participação de negócios ou participante não totalmente conhecedor ou pessoa de negócios que está desistindo no meio do sprint.

  1. Nem todos os projetos são adequados para o Agile ... A maioria dos gerentes ou scrum master não sabe disso. Projetos de manutenção. Um defeito pode ser inicialmente assumido, que pode ser feito em 8 horas, aceito no sprint. Depois de quatro horas, descobri que este é o Java / outro produto ... (recentemente, enfrentei um defeito relacionado ao Quartz Scheduler .. dentro do nosso projeto) e esse defeito pode levar à atualização do produto / pacote .. lidar com burocracia, aprovação, financiamento, nova versão ou atualização deve ser aprovada pela Engenharia Interna etc., 5.Retrospecção: somente alguns projetos Agile executam esta etapa.
  2. Emparelhamento .. Muitos desenvolvedores tratam o emparelhamento como um local para abusar dos colegas de trabalho .. criticam outro design, práticas de codificação .. avaliam o tratamento como trabalho em equipe. Aprendem uns com os outros ... Outra maneira de abusar do Agile / Scrum.

Agile é definitivamente uma boa metodologia. A menos que sua organização não siga completamente ou não seja treinada ... É abusada .... efeitos colaterais 60+ horas / semana de trabalho, jogo de culpa, baixa moral.

mukunda
fonte
veja este link .. porquê projetos ágeis falhar .. brighthubpm.com/agile/55778-why-do-agile-projects-fail
mukunda
Por acaso, eu também concordo com as informações apresentadas nesse artigo. Entendo que há quem pense que o Agile é infalível, mas a realidade é que o Agile deixa pouco ou nenhum espaço para a introdução de idéias novas e mais eficazes. is..brighthubpm.com / agile / 55778-por-que-agile-projetos-falha
user272671
-3

Agile é microgerenciamento disfarçado. Não há lugar para iniciativa ou criatividade no Agile, ele removeu a diversão da programação para permitir que gerentes incompetentes mantivessem o controle, mesmo sem ter uma pista do ponto de vista técnico.

geo
fonte
2
Você não poderia estar mais errado. No ágil, as equipes devem ter uma quantidade muito grande de controle criativo. O Agile requer uma quantidade extrema de iniciativa, pois é a equipe que decide como implementar cada história. Na verdade, o gerenciamento tem muito pouco controle sobre o processo ágil. Pessoalmente, as três equipes ágeis diferentes das quais faço parte são extremamente divertidas. Parece que você experimentou uma incompetência severa que se identificou como ágil sem estar nem perto disso.
Bryan Oakley
adicionar um pouco de raciocínio para apoiar a sua afirmação (que faz certo sentido para mim, mas isso não importa), e eu vou remover o downvote
mosquito
1
Eu concordo com @Geo. Até o momento, essa é a impressão que tenho do que é "Agile", no mundo real. Quando você tem essa configuração no chão de fábrica, é simplesmente uma forma de microgerenciamento. Agora o Manifesto tenta nos dizer que não é. Mas projeto após projeto, sou levado a acreditar ainda mais que é simplesmente outro nome para "Microgerenciamento". E isso mata a criatividade.
user272671