equipes Scrum vs. equipes tradicionalmente organizados [fechado]

Question

Para aqueles de vocês que começaram a usar scrum em suas equipes de desenvolvimento: Será que quis manter as equipes tradicionais ou formar novos? Na nossa organização, são divididos em banco de dados, desenvolvimento de produtos e desenvolvedores de frontend (simplificado!).

Estou interessado em saber se outros realmente reorganizou sua estrutura de equipe inteira devido a scrum ou se formaram projeto dedicado (?) Equipes, combinando por exemplo uma pessoa de cada equipe "velho".

Answer 1

Na verdade, eu não posso nem imaginar como scrum poderia funcionar se você manter seus silos papel. No scrum nós construímos fatias verticais através do produto de modo que todos os recursos entregues durante um sprint requer todas as habilidades que você mencionou (mais QA que você não fez). Como você criar uma colaboração contínua e ter pessoas comprometer com o sprint, se eles não estavam todos no mesmo time? Parece ser o caminho mais provável para terminar em "Scrumfall" para mim. Eu não sou um especialista, por qualquer meio, mas parece-me que a maneira de falhar no scrum é pensar nisso como uma solução em vez de toda uma mudança organizacional de gerenciamento de projeto. Sua cultural no núcleo.

Para responder pergunta sobre "generalistas". A resposta fácil é que por ter certas pessoas só é capaz de trabalhar em certas coisas que você criar gargalos graxos grandes em chegar ao Pronto. Com especialidades você está sempre constrangido a cada passo por ter recursos limitados para trabalhar em algo. Na corrida 1 você pode ter um monte de trabalho db para fazer onde há mais do que apenas que um dba pode fazer. Mas, em seguida, Sprint 5, onde não há alteração no datamodel em tudo, seu dba vai estar sentado em torno de manter entediado. Torna-se quase impossível no planejamento do sprint a cometer em um tempo razoável, se você tem que divy-se e atribuir ao nível de tarefa por papel, em vez de apenas pegar o próximo conjunto de características prioritárias que se adapta a velocidade da sua equipe. O modelo generalista trará, inevitavelmente, o valor do negócio no longo prazo. Você não pode apenas vê-lo imediatamente até alcançar a polinização cruzada.

Gostaria de advertir que, se você já está em grupos ed-silo por papel, então você tem que ter muito cuidado na am ágil reorganização. Muitas pessoas não estão prontas e não quero estar pronto para perder seus títulos especiais e membros da equipe acaba de se tornar. Eu acho que você deve quase sempre esperar uma certa quantidade de volume de negócios.

Answer 2

É preferível que no scrum / desenvolvimento ágil que a maioria dos indivíduos na equipe são 'generalista' o que significa que qualquer um pode razoavelmente passo em qualquer papel para que qualquer pessoa pode retirar itens do backlog como a entrar e ninguém está esperando em torno de outros.

Agora, isso pode não ser o caso em sua situação hoje, mas fazer as coisas como programação de pares e reuniões standup para ver onde as pessoas estão tendo impedements e para melhorar a polinização cruzada de conhecimento vai ajudar na obtenção deste objetivo.

Answer 3

Na minha empresa, criamos uma equipe de funções cruz temporária para cada projeto. Nossas equipes existentes ainda estão lá, mas é realmente importante que nós temos equipes funcionais cruzadas para scrum.

Answer 4

Em geral, tentar misturar-se um pouco para obter algum conhecimento cross-equipe, mas para a maioria dos trabalhos parte, as nossas especialidades. Mas, como os avanços do projeto podemos mais facilmente ajudar em diferentes equipes

Answer 5

Quando eu trabalhava para o meu empregador anterior, a empresa reorg'ed toda a organização dev e gestão de produtos. Eles colocaram engenheiros, qa, e analistas em cada equipe. A divisão foi principalmente verticais / funcional com algumas exceções. Essas exceções foram um erro - a arquitetura vertical não se encaixava, porque era realmente horizontal. Pensei que equipes multifuncionais funcionou bem. No seu caso, os departamentos db e front-end precisa para se fundir com o resto, se possível, e novos mercados verticais específicos para o seu produto pode ser criado

Answer 6

Nós dividimos nossa equipe em Desenvolvimento de Novos Produtos e existente Maintenance Produto, com a capacidade para qualquer desenvolvedor de saltar de um para o outro entre os sprints.

Answer 7

Eu acho que temos mantido a equipe tradicional, pelo menos por agora. Há um par de outras equipes dentro do ramo de aplicações do departamento de Sistemas de Informação onde eu trabalho que estes foram colocados em apenas antes que chegamos em Scrum.

Não é um projeto grande maioria de nós estão em que está usando Scrum e a equipe parece estar a evoluir ao longo bem. Temos algumas novas ferramentas e processos que parecem ter nos ajudou muito e deu-nos uma sensação de "grandiosidade" que esperamos vamos passar para as outras equipes.

Para alterações em um banco de dados, qualquer um de nós desenvolvedores podem fazer a mudança no ambiente de desenvolvimento e, em seguida, passar ao longo do script para um DBA deve ser feito quando ele está pronto para a produção. Para alterações na rede, há pessoas de infraestrutura que alça que e inicialmente configurar um servidor em termos de O / S, rede, memória, discos rígidos, etc.