O Scrum transforma desenvolvedores ativos em desenvolvedores passivos?

O que você está descrevendo é NOT SCRUM

O dono do seu produto está superando seus limites se ele está lhe dizendo como fazer o seu trabalho tecnicamente, não é sobre o que é SCRUM.

O SCRUM é sobre liberar os desenvolvedores para se concentrarem em questões de desenvolvimento e capacitar eles se encarregam de determinar quanto tempo as coisas levam e como fazê-las.

SCRUM é sobre colaboração, é para isso que as reuniões de planejamento da Sprint são realizadas, para promover a colaboração entre todas as partes interessadas; proprietário do produto, desenvolvedores e testes.

Sim, o proprietário do produto deve priorizar os recursos, o que precisa ser entregue primeiro de acordo com as necessidades do cliente, mas os desenvolvedores devem fazer engenharia e design, e não o proprietário do produto.

Eu não concordo que os desenvolvedores devam projetar interfaces gráficas e fluxos de trabalho, a menos que sejam especificamente encarregados e treinados para trabalhar com os clientes e eliminar a funcionalidade diretamente com os clientes. As GUIs construídas pelo programador, feitas a vácuo, raramente atendem às necessidades dos clientes.

O SCRUM trata de colocar um processo leve que pode ser previsível e repetível ao longo do manifesto ágil.

Fico triste ao ouvir histórias de que coisas muito boas estão sendo pervertidas assim.

Eu acho que antes do Scrum, todo mundo fez o que queria: yippee ki-yay mf'er . Seus usuários são seus benfeitores e eles dirigem a história e pagam as contas. O product owner garante que a história seja feita. De alguma forma, seu grupo chegou à conclusão de que o Dono do Produto deveria estar lhe dizendo como programar.

Você quer escrever código ou criar aplicativos pequenos que você acha que são legais? "Eu quero fazer um primeiro recurso e não B, para que eu possa manter a minha liberdade de escolha." Encontre um benfeitor diferente e não uma nova metodologia de desenvolvimento.

Você está preso no título do proprietário do projeto ou algo assim. Se você tem uma razão válida para discordar da história, diga alguma coisa, faça sua argumentação. Você nem sempre pode ganhar. O trabalho deles é retornar aos usuários e informar que há um problema válido com a solicitação deles. Sejamos honestos, se a história pedir que você solte um banco de dados aleatoriamente ao longo do dia, sem backup, sem perda de dados ou tempo ocioso, você tem um problema e um dever de esclarecer a história.

Parece que suas aventuras no Ágil foram corrompidas pelo Scrum. Acho que, de todas as metodologias ágeis, o Scrum é o menos ágil. É mais como cascatas em miniatura e gerenciamento de projetos adicionais. Isso, é claro, faz com que seja mais apreciado pela gerência, que acha que está retomando o controle desses desenvolvedores irritantes, mas é claro que você vê a realidade da situação.

Agile não é sobre seguir um caminho prescrito, ele é projetado para torná-lo mais produtivo e motivado. As pessoas não processam diz o manifesto (parafraseado), e isso está perdido no sistema que você está usando.

Então mude isso. Chame a atenção da gerência e diga que é um passo retrógrado, que sua produtividade é menor do que costumava ser e todos estão insatisfeitos com a maneira como ela está funcionando. Mostre o Manifesto Ágil (e seu gêmeo maligno ) e demonstre que você não apenas aprendeu lições desta experiência, mas quer evoluir as partes boas dela para um sistema melhor (uma que é como você costumava ter, que parece funcionar bem para você).

Eu acho que simplesmente vocês estão acostumados a ter mais propriedade - e todos que eu acho que preferem isso, sua natureza humana.

Não faço ideia de como sugerir que você melhore ou divirta as coisas, mas é uma ótima pergunta e uma boa ideia.

Você está recebendo histórias de usuários na forma de "Como um --role--, eu quero --goal / desejo-- para que --benefit--"? Parece que o Product Owner deseja fazer o trabalho de design, e ele / ela pode não ser a melhor pessoa para fazer isso. Usar o padrão de história do usuário pode ajudar a garantir que o Product Owner esteja aderido aos interesses de negócios, e o desenvolvimento de software está sendo feito pelos desenvolvedores de software.

No Scrum há muito espaço para os desenvolvedores contribuírem e darem seus conselhos sobre novos recursos, interface do usuário, usabilidade ... Colaboração e conversação entre pessoas de negócios e desenvolvedores é necessária no Scrum e isso permite isso. No entanto no final, o dono do produto sempre terá a palavra final porque ele é o responsável por maximizar o valor comercial dos incrementos de software produzidos após o sprint (em outras palavras, o ROI).

Do Manifesto Ágil:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

O proprietário do produto informando como a interface do usuário e a funcionalidade devem ser implementadas não é aceitável. Nesse caso, você deve ter a palavra final, já que você é responsável pela qualidade interna do software que você produz.

Talvez você trabalhe em uma empresa criada por desenvolvedores onde os programadores tivessem liberdade para implementar os recursos desejados. No entanto, a maioria das metodologias Ágeis faz uma separação clara entre as pessoas do domínio de negócios e a equipe responsável pela produção de software (desenvolvedores, testadores ...), que é a divisão de trabalho mais comum na maioria dos lugares. Se minhas suposições estiverem corretas, eu posso entender o sentimento que você tem de que você não é capaz de "ter uma influência no quadro geral", mas com a empresa crescendo, acho que teria sido o caso de qualquer maneira, Scrum ou não. / p>

Com relação à análise, design e outras atividades de meta-desenvolvimento que você menciona (que não devem ser feitas novamente pelo Product Owner), as equipes Agile devem ser multifuncionais e livres de silo. Ninguém deve possuir todo o conhecimento em torno de uma atividade de desenvolvimento específica, então talvez haja uma oportunidade para você diversificar o local apenas contra o "monkeying de código".

Pelo contrário, descobri que ter um proprietário de produto tomando decisões sobre a funcionalidade me permite dedicar mais tempo à produção de código de qualidade. Além disso, se houver preocupações válidas, sempre posso questionar as decisões dos proprietários do produto, o que geralmente leva a discussões proveitosas.

Nós praticamos o Scrum aqui. Temos uma reunião de planejamento quinzenal onde nos alimentamos das prioridades de negócios atuais, e sucessos e fracassos do sprint anterior, e decidimos, como uma equipe , o que queremos resolver para o próximo sprint.

Uma das maneiras de fazer isso é classificar o backlog em uma placa por complexidade verticalmente e prioridade de negócios horizontalmente. Depois disso, o Dono do Produto teve sua contribuição, então cabe à equipe escolher o que queremos fazer. Obviamente, escolher uma tarefa de baixa prioridade de alta complexidade é desaprovado, mas estamos decidindo isso como uma equipe. Isso faz com que as sessões de planejamento sejam mais longas, mas vale a pena, e uma parte essencial do processo ágil.

E nós temos microgerencias às vezes, mas isso é um problema diferente.

O problema real que você está descrevendo é uma patologia comum quando as equipes adotam uma Metodologia: elas desligam seus cérebros. Isso é tão verdadeiro com um sistema ágil da nova escola quanto com os sistemas pesados da velha escola.

Q: A Metodologia prescreve x, mas x não está funcionando bem. O que deveríamos fazer?

A: Refine sua implementação de x. Talvez pare de fazer isso completamente. A Metodologia não é o seu chefe!

Neste caso específico, parece que o product owner pode estar fazendo muito. Você está confortável falando com ele sobre isso? Você ficaria confortável em ter essa conversa se não estivesse "fazendo scrum?" Se o proprietário do produto não é sensível ao feedback construtivo, não é um problema de metodologia, é um problema com o proprietário do produto.

Eu não estou realmente em sintonia com a coisa toda scrum como tem sido mais cachoeira por um tempo.

Mas, para ser honesto, isso soa mais como uma questão de pessoal de gerenciamento do que um problema de técnica de gerenciamento de projetos. Como é mais baseado em pessoas do que em técnica.

O papel dos líderes em uma equipe auto-organizada seria uma postagem no blog sobre algo que parece estar faltando no seu post. Onde a equipe está decidindo qual trabalho é realizado em um sprint? Onde a equipe é proprietária do processo e do trabalho? Você tem alguém que conhece o Scrum o suficiente para fazer Scrum e não uma versão pervertida dele?

Eu tive a mesma experiência com o Scrum e gosto de chamar isso de "tirania da história".

Da minha experiência, os desenvolvedores mais do lado criativo / design / frontend parecem sofrer mais com isso do que as pessoas envolvidas no trabalho de back-end.

A única saída que encontrei até agora foi afastar o Scrum - muitas vezes não é possível e / ou apropriado porque afinal tem suas vantagens - ou introduzir algo como o tempo de 20% do Google para dar aos desenvolvedores uma saída criativa além do "você está livre para escolher como implementar a Página de login ", porque na realidade você não é a sua implementação é restrito pelo código existente e pela arquitetura do sistema - isto é, a menos que se considere a liberdade de escolher entre 'um loop for e while' uma liberdade.

There is a big difference between you deciding what to do, or being told what to do.

Na minha experiência, há apenas um longo caminho de sendo dito o que fazer para decidir o que fazer.

Ao final deste processo, normalmente não somos instruídos porque eles gostam de poder e não porque eles não têm nada melhor para fazer. Muito pelo contrário, no final deste caminho - quando eles ganham confiança suficiente em nossa equipe - eles parecem aliviados e alegremente passam a nós tanto controle quanto podemos lidar (e se a confiança deles é realmente firme, eles ainda tentam passar mais do que isso)

Ah, e na minha experiência, isso basicamente não tem nada a ver com o Scrum / Agile. Aconteceu com scrum, iterativo, cachoeira, o que seja. Parece que a questão de confiança é agnóstica ao processo

Em nossa equipe, o proprietário do produto nos diz o que faz e decidimos como o fazemos. É realmente importante ter essa separação ou você acabará na situação que descreveu.

De acordo com minha experiência, o Scrum é para observar profundamente o que você faz. Está apenas sentado em seu ombro e observando o que você faz. Mesmo que tenha sua própria vantagem, eu odeio a metodologia scrum. Espera a contagem, não a qualidade. A qualidade está ficando comprometida com a metodologia scrum.