Como gerenciar desenvolvedores Agile que trabalham com pessoas de negócios tradicionais (seriais)? [fechadas]

Boa tarde,

Meu ambiente de trabalho tem alguns problemas. Nossa equipe de TI está tentando ser mais ágil, mas não estamos realmente conseguindo adesão dos negócios. Eles participam de nossas revisões diárias de stand-ups e sprint e ajudam no planejamento do sprint, mas depois se revezam e realizam 4 meses de coleta de requisitos para um projeto antes de avançar com um estilo de desenvolvimento serial (principalmente). Os objetivos do sprint são coisas como "chegar 20% mais perto do lançamento".

Para a equipe de TI, eles transformaram os Sprints em uma espécie de marcha da morte. Terminamos um Sprint um dia e começamos um novo Sprint no dia seguinte. Não há reflexão ou alterações feitas entre os sprints, apenas durante.

Como nunca fiz nenhuma das metodologias ágeis antes, não tive uma introdução muito agradável a elas. Então, minhas perguntas são:

1) Deve haver algum tempo (talvez uma semana ou mais) entre os sprints para fazer a reflexão / introspecção / alterações / etc.? Ou são as corridas consecutivas a norma?

2) Existe alguma chance de sobrevivência para uma equipe ágil sem contrapartes comerciais ágeis? Caso contrário, existem algumas metodologias de transição ou mesmo dicas para levar os negócios a uma mentalidade iterativa, se não necessariamente ágil?

3) Toda a sua equipe deve estar em cada corrida? Temos quase 20 programadores em um único sprint, mas trabalhando em projetos completamente diferentes (geralmente equipes de 3 a 5, às vezes maiores). É normal ter um único sprint ou devemos tentar gerenciar vários sprints independentes? Deveríamos estar tentando manter os vários sprints em sincronia simultânea ou os horários deles deveriam se sobrepor e ser flexíveis?

Quaisquer pensamentos ou conselhos são apreciados. Esta é a minha primeira vez que SO vem de uma pergunta, então, deixe-me saber se existem maneiras melhores de formular esses tipos de perguntas (o faq foi bastante útil, mas ainda não tenho certeza de que estou seguindo perfeitamente). Obrigado!

1) Geralmente, você pode apenas revisar o último sprint em uma reunião, planejar a próxima e iniciá-la. Revise particularmente a precisão das estimativas das tarefas e alimente isso nas estimativas para o próximo sprint. Você pode adiar o próximo sprint se precisar aguardar o feedback dos clientes dos resultados do anterior e achar que o feedback influenciará as tarefas do próximo sprint.

2) Não facilitará, mas é claro que a equipe pode ter sucesso. Seu comentário

Os objetivos do sprint são coisas como "chegar XX% mais perto do lançamento"

é um pouco preocupante, pois idealmente você deseja incluir recursos / funcionalidades demonstráveis ​​como os objetivos de um sprint.

3) Você diz que existem 3-5 projetos completamente diferentes. Se não estiverem relacionados, ou seja, para produtos diferentes, não há necessidade de sincronizá-los, mas cada um deles deve ser tratado como sprints independentes. Parece que suas equipes para cada sprint provavelmente são de bom tamanho.

1) Deve haver algum tempo (talvez uma semana ou mais) entre os sprints para fazer a reflexão / introspecção / alterações / etc.?

Não. Uma semana? Você deve estar louco. 2 horas é o limite.

Ou são as corridas consecutivas a norma?

Absolutamente. Caso contrário, você está girando suas rodas.

Existe alguma chance de sobrevivência para uma equipe ágil sem contrapartes comerciais ágeis?

Os negócios nunca são "ágeis". Agile é algo que você faz. Não eles. De fato, nunca eles. Eles apenas pedem coisas aleatórias. Você gerencia isso.

Caso contrário, existem algumas metodologias de transição ou mesmo dicas para levar os negócios a uma mentalidade iterativa, se não necessariamente ágil?

Nenhum. Você decompõe os requisitos em sprints. É a sua disciplina. Não deles.

Toda a sua equipe deve estar em cada corrida?

Sim.

Temos quase 20 programadores em um único sprint, mas trabalhando em projetos completamente diferentes (geralmente equipes de 3 a 5, às vezes maiores).

O que? Isso não é um time. Isso é um monte de equipes. 4 ou talvez 5 equipes separadas.

É normal ter um único sprint ou devemos tentar gerenciar vários sprints independentes?

Não faço ideia do que você está falando. Mas, como você parece ter 4 ou 5 equipes unidas, fica claro que você terá uma confusão enorme.

Deveríamos estar tentando manter os vários sprints em sincronia simultânea ou os horários deles deveriam se sobrepor e ser flexíveis?

Cada equipe - e os sprints da equipe - são o problema da equipe. De mais ninguem.

Algumas pessoas pensam que grandes projetos como esse devem ser um "Scrum of Scrums". As equipes estabelecem suas metas, constroem suas coisas. Os representantes de cada equipe se reúnem periodicamente para coordenar as equipes para obter liberações mutuamente benéficas.

Sinto muito por você estar em uma organização tão obviamente disfuncional.

Se você deseja ter alguma capacidade de medir o progresso, é absolutamente imperativo que você planeje em termos de marcos 100% completos. Se houver algum espaço para discordância honesta sobre o que é um marco em particular, a tendência natural é que a pessoa que faz o trabalho adote a interpretação mais otimista possível sobre o quanto eles fizeram e a pessoa que ouve o que eles dizem para ouvir isso. da maneira mais otimista possível. Isso significa que as notícias ficam cada vez melhores à medida que você sobe na cadeia, levando a uma desconexão completa entre a realidade e o que os principais ouvem. http://www.davar.net/HUMOR/JOKES/SHIT.HTM é uma abordagem bem-humorada e totalmente realista sobre esse fenômeno.

Quão ruim é essa desconexão? Considere isto. No projeto médio, o tempo real necessário para a conclusão (se você chegar lá) calcula o dobro das estimativas originais. Mas, independentemente do atraso do projeto, normalmente as pessoas no topo não recebem as primeiras dicas de que o projeto está atrasado até cerca de duas semanas antes da data de vencimento, pois esse é o ponto em que a desconexão entre expectativas e a realidade não pode mais ser escondida.

Portanto, as metas XX% mais próximas não são requisitos reais. Literalmente, sua equipe deve se recusar a aceitá-los como requisitos reais. É seu trabalho educá-los de que você precisa de tarefas concretas e acionáveis ​​e, no planejamento, elas precisarão ser divididas em tarefas específicas que podem ser estimadas em no máximo algumas horas.

Em segundo lugar, como outros já disseram, é absolutamente necessário dividir sua equipe em unidades menores, que provavelmente precisarão estar em horários diferentes. Pesquisas indicam que uma única equipe de software de 20 pessoas trabalhando em uma coisa pode realizar tanto quanto uma equipe de 5 a 8 pessoas. (Eu deparei com esse fato surpreendente no excelente livro de Steve McConnell, Software Estimation .)

Em terceiro lugar, é uma bandeira vermelha realmente grande que parece uma marcha da morte. Se parece uma marcha da morte, provavelmente é uma marcha da morte. Os desenvolvedores de software tendem a ter desempenho máximo quando trabalham de 35 a 40 horas por semana. (Consegui esse número no Rapid Development de Steve McConnell .) Trabalhar horas mais longas pode obter aumentos temporários no desempenho, com o custo de uma redução no desempenho a longo prazo. Um grande projeto é uma maratona, você precisa acompanhar o ritmo.

Quarto, realmente precisa haver um ritmo para um sprint. Quando trabalhei em uma equipe fazendo scrum, achamos muito útil dividir cada sprint em duas seções que chamamos de "foco longo" e "foco curto". Durante o "foco longo", desenvolvemos o desenvolvimento de software nas tarefas acordadas para esse sprint. Durante o "foco curto", fizemos todo o material necessário, envolvendo muitas interrupções e alternância de tarefas. Foi então que fizemos o controle de qualidade, a correção de bugs, várias reuniões, a estimativa de tarefas para o próximo sprint e finalmente concordamos com o que seria e o que não seria no próximo sprint. Isso funcionou muito bem para nós, porque muito desenvolvimento de software só pode ser feito quando você está na "zona", o que geralmente não acontece.

Se você seguir um ritmo como esse, obterá outra vitória com horários diferentes entre as equipes: seu pessoal de controle de qualidade sempre pode trabalhar em qualquer equipe que esteja atualmente no controle de qualidade, o que os mantém com um nível constante de trabalho.

Boa sorte e esteja ciente de que, sem o apoio da parte superior, você poderá não conseguir consertar a disfunção. Se for esse o caso, sua melhor opção realista pode ser encontrar uma organização mais saudável da qual fazer parte, em vez de tentar transformar sua organização em algo que ela não vai se tornar.

1. Minha experiência é que os sprints geralmente retornam com alguma perda de tempo para fazer retrospectivas, demonstrar funcionalidade e planejar o próximo sprint. Por exemplo, o último dia de um sprint costumava ser considerado um cancelamento, pois haveria três reuniões que se estendiam naquele dia, tipicamente, de modo que um sprint de 2 semanas equivalia a 9 dias úteis. A retrospectiva no final de um sprint pode trazer alterações a serem tentadas no próximo sprint, que começa quase imediatamente em certo sentido.

2. Uma chance sim, mas bastante pequena, como se você usasse o Scrum, deveria haver um proprietário do produto aprovado pela gerência para direcionar a priorização de quão urgentemente algumas histórias são comparadas a outras. Tem que haver alguma compreensão da responsabilidade que eles têm, embora outra parte seja que o "XX% mais próximo do lançamento" é uma métrica bastante ruim para mim, pois isso tende a não incluir bugs e outros problemas de última hora que são quase impossíveis de corrigir adequadamente. estimar em minha experiência limitada. Também há algo a ser dito para entender quando as mudanças nas prioridades podem ser conhecidas pela equipe e usadas no planejamento de um sprint. O comprometimento da gerência é crucial, pois, se eles não entendem o que você está fazendo, pode ser como tentar fazer entregas enquanto caminha em uma esteira estacionária. Enquanto suas pernas estão se movendo, você não está

3. Não necessariamente, mas às vezes esse pode ser o caso. A chave é saber quanto cada desenvolvedor é alocado para o projeto e mantê-lo consistente, para que, quando houver uma velocidade nos primeiros sprints iniciais, isso seja útil na previsão de velocidades futuras, em vez de ser inútil, conforme o número de horas trabalhadas. os projetos saltam demais para facilitar a estimativa de quantos pontos podem ser feitos em um sprint. Cada projeto deve ter seu próprio conjunto de sprints se o projeto for grande o suficiente para durar semanas de trabalho.

Boa sorte em educar a gerência em termos do que eles precisam fazer e como isso funciona, pois esse pode ser seu grande obstáculo a ser superado aqui.

Se o seu projeto está utilizando o Scrum, você deve ter um Scrummaster cujo trabalho é educar todas as partes sobre como exatamente o processo deve funcionar. Se você estiver executando o Scrum, parece que o scrummaster não está realizando seu trabalho, já que não ter buy-off do lado comercial do projeto é um obstáculo enorme (e não incomum).

Diga às pessoas do programa para estragar tudo, se elas disserem que XX% está mais perto de concluir. Diga-lhes que você terminará X, Y e Z exigíveis em tal e qual data. Se eles querem contratar o cronograma, pergunte o que eles querem remover; se eles recusam, dizem que removem peças ou acrescentam tempo. Dizer fazê-lo, ou então não fará nenhum bem. Se eles pressionarem, atribua o código do gerente de projeto para concluir esse sprint. Tenha em mente que o Agile é um esforço de equipe. Se o pessoal de gerenciamento de projetos não estiver trabalhando 12 horas por dia, é melhor buscar pizzas e refrigerantes para as pessoas e qualquer bônus por fazer as coisas dentro do prazo ou antes do previsto, vá também para as pessoas que fizeram o trabalho. Informe a gerência superior, se você também tiver, eles provavelmente empurraram o Agile para você enquanto não treinava o pessoal de gerenciamento de projetos.

Acompanhe seu progresso, faça ajustes e escolha os próximos requisitos a serem atendidos. Se o projeto não for entregue até que tudo esteja pronto, não se preocupe com a prioridade dos recursos, preocupe-se com quais recursos são importantes para você e que sejam feitos para peças futuras. Você tem que se apropriar disso. Também não deveria ser uma marcha da morte. Os projetos Scrum devem medir a quantidade de trabalho que você pode concluir na duração de um sprint NORMAL. Esses 10 (ou 9, conforme observado acima), normais 8 horas por dia útil.

Uma coisa que ouvi na conferência Agile há alguns anos foi que sua equipe é como uma fábrica e pode produzir X quantidade de carros (ou no seu caso) por sprint.

Além disso, suas equipes de sprint devem ter entre 3 e 5 pessoas e não 20. Isso pode ser parte do problema. Cada equipe deve escolher suas histórias (itens de linha de requisitos, se desejar) e trabalhar com elas. Eles devem se reunir separadamente, mas reunir-se com um grande grupo para compartilhar idéias.

Ao gerenciar esses tipos de equipes, pode ser melhor que os gerentes consultem separadamente para determinar quais tarefas entre equipes são necessárias e colocar as pessoas certas em contato. Um stand up de 20 pessoas é monótono e chato para os envolvidos.