Este artigo foi traduzido por máquina.

Orientações de ALM

Visual Studio Rangers de ALM — reflexões sobre equipes virtuais

Willy Peter Peter

Brian Blackman

 

O Visual Studio Rangers de ALM aprendeu valiosas lições sobre como organizar e gerenciar equipes com membros em todo o mundo — todos quem têm várias habilidades, motivações, compromissos, afiliações de projeto e restrições. Aqui, Compartilharemos nossa experiência e fornece diretrizes para trabalhar com equipes em ambientes de virtuais e distribuídos que perfeitos.

Recapitulando, os Rangers são um grupo de especialistas que promover a colaboração entre o grupo de produtos Visual Studio, serviços da Microsoft e da comunidade Microsoft Most Valuable Professional (MVP) pelo endereçamento funcionalidade ausente, removendo os bloqueadores de adoção e práticas recomendadas e orientações com base em experiências reais de publicação.

Neste artigo, vamos começar definindo o nosso processo de gerenciamento de projeto personalizado chamado Ruck; em seguida, vamos oferecer um resumo dos desafios de equipe virtual e compartilhar as observações feitas com projetos Rangers usando Ruck com Visual Studio Team Foundation Server (TFS) como a solução de gerenciamento de ciclo de vida do aplicativo (ALM). Concluiremos com nossas recomendações para os Rangers e outras equipes virtuais em ambientes semelhantes.

Ruck?

Os Rangers foram cachorro-fooding Visual Studio TFS como uma solução ALM, com o objetivo de melhorar a qualidade da produção de operações e soluções de nossa negócios. Uma área principal de investimento com um enorme impacto potencial tem sido o modelo de processo e o processo de gerenciamento de requisitos associados. Nossa intenção de núcleo é criar uma maneira sistemática e reproduzível de localização e os recursos killer das iniciativas Ranger de endereçamento. Definição e a evolução do processo provou para ser uma tarefa desafiadora — um pouco, como corrigir um motor de avião durante o vôo — mas com várias equipes de projeto com êxito usando variações do processo, podemos pode considerá-la como um pilar sólido. Para garantir que estamos não confunda a qualquer pessoa em termos de metodologias ou incomodar fanáticos por linguagens de processo, provisoriamente escolhemos chamar o nosso processo personalizado "Ruck", que, no mundo do futebol, significa "scrum solto".

Desafios do ambiente de equipe do Ranger Virtual

Um desafio freqüente com Rangers é que cada indivíduo tem seu trabalho, em casa e mundos Ranger e os compromissos de saldo. A maioria das atividades de Ranger tem a menor prioridade desses três e com freqüência ocorrem tarde da noite. O que torna o ecossistema Rangers exclusivo é que nossas soluções não podem ser liberadas quando estiver prontos, mas são implicitamente tempo-box com metas de tecnologia e por demanda para a solução. Como temos ainda encontrar uma forma mágica de estender o número de horas em um dia, contamos com entusiasmo enorme, uma Ranger individuais para a tecnologia e a comunidade para ajudar a localizar os ciclos de reposição para atividades de Ranger. Embora isso cria um profissional de TI heróica que poderá absorver numerosos alternâncias de contexto e produzir resultados de alta qualidade em suma, ad-hoc e partes aleatórios, ela também apresenta uma forma de processo anti-Scrum.

Olhando para vários locais de nossos membros da equipe no índice Rangers (bit.ly/9LKgZb), que atualmente inclui apenas uma pequena porcentagem dos Rangers, percebemos que Rangers e, portanto, nossas equipes, estão espalhados em todo o planeta. Precisamos ter em mente que estamos trabalhando com uma variedade de diferentes culturas e que nós não pode fazer suposições sobre normas culturais ou alfândega nem levar os ambientes concedido. Assim, implementamos liderança situacional e processo nos nossos projetos para acomodar diferenças culturais (consulte o livro, "Liderança e a um minuto Manager: aumentando a eficácia por meio de liderança situacional" [Morrow, 1985], por h. de Kenneth Blanchard, Patricia Zigarmi e Drea Zigarmi).

Conforme mostrado na a Figura 1, a ampla variedade de fuso horário necessita que alguns membros da equipe ocasionalmente ficar até mais tarde ou colocá-lo em horários estranhos para uma reunião de status ou design. Isso não é divertido nem produtiva.

Typical Rangers Meeting Across Time Zones
Figura 1 reunião de Rangers típico em fusos horários

A combinação de Rangers de ecossistemas diferentes, como grupos de produtos, serviços, parceiros, MVPs e comunidades apresenta uma variedade de motivações e os compromissos que todos precisam ser adotado pelo programa Rangers ecossistema e reconhecimento.

Enquanto o nosso objetivo é para o máximo de transparência e acesso a tudo por todo o mundo, temos casos extremos por causa dos contratos de confidencialidade, restrições de licenciamento e infra-estrutura.

A alternância de contexto freqüente — e iniciando e parando de uma área de projeto ou recurso — é o problema mais desafiador porque é uma experiência demoralizing da equipe. Isso pode tornar os gráficos burn-down sprint tiver uma aparência interessante, mas difícil de usar com eficiência para status e controle do progresso, como você pode ver na a Figura 2. O primeiro gráfico em a Figura 2 representa um aumento na tarefa de itens de trabalho como um indivíduo ou equipe aprende há mais a implementação do item de lista de pendências de produto que imaginava. O segundo gráfico ilustra o trabalho parar em um projeto por causa de compromissos do cliente. O gráfico velocity a Figura 3 demonstra nossa declaração sobre os efeitos da alternância de contexto e o Iniciando e parando das áreas de recurso.

Sprint Burn-Down Charts Reflect Challenges
Figura 2 Sprint Burn-Down gráficos refletem desafios (clique para ampliar)

Project Velocity
Figura 3 projeto Velocity

Finalmente, devido à natureza voluntário do programa Rangers, responsabilidade varia muito, oferecendo algumas opções para impor um compromisso de entrega. Felizmente, a maioria dos Rangers disporem propriamente ditos e, portanto, a maioria das equipes de Ranger entregar no prazo, sempre.

Analisando e aprendendo com projetos recentes

Conforme mencionado, temos vários desafios quando não as equipes estão localizadas em um único local, quando as equipes não estão em locais diferentes e quando não houver nenhum compromisso individual além da paixão de um para ser um colaborador Ranger. Tentamos adaptar a isso, organizando as equipes por localização geográfica, mas isso geralmente não trabalho porque ele vai contra acreditamos na permitindo que desenvolvedores escolher trabalho das áreas em que tenham interesse, mesmo quando ele não alinha com a região atual. Portanto, precisamos ser organizada automaticamente e contam com experiência para determinar quais as práticas recomendadas funcionará para um projeto específico.

A natureza do nosso ecossistema virtual força conosco para quebrar várias regras predefinidas de processos, como o Scrum. Como no Kanban (consulte o livro, "Kanban: bem-sucedida evolucionário alteração for Your tecnologia Business" [azul buraco Press, 2010], por David j Anderson), adaptadas nosso processo para atender às nossas necessidades. De muitas maneiras, aplicamos liderança situacional aos projetos, de acordo com os atributos exclusivos de cada projeto específico. Por exemplo, conduzir reuniões semanais porque todos têm trabalhos do dia. Reuniões diárias ("stand-ups") são muito freqüentes e muito limitada. Além disso, nossos encontros não clássicas reuniões stand-up do Scrum pois muito poucas pessoas podem atender ao mesmo tempo. Isso obriga regularmente nós ter duas reuniões em um único dia para acomodar vários fusos.

Projetos de Ranger são complexos, exigindo que temos transparência, freqüente de comunicação, pontos de verificação e reuniões. Porque todos têm outros compromissos, como as famílias e seus trabalhos do dia, as equipes precisam evitar sendo muito limitada. Como podemos saber e adaptar, estabelecemos nossos próprios padrões de projeto e adaptá-los para melhor influência. Alguns desses padrões incluem:

  • Tendo os membros da equipe para inscrever-se para a tarefa na qual eles têm interesse
  • Lembretes de email em tempo hábil dos principais pontos de verificação ou etapas com a visualização do progresso de trabalho
  • Reuniões semanais

Nossos desafios mencionados anteriormente exacerbar como alteração de rhythms do projeto. Isso não é exclusivo para o nosso ecossistema de Ranger; Vamos enfrentar isso em muitos projetos na inicialização. Obter uma cadência adequada com uma nova equipe leva poucas etapas e missteps antes de todos é finalmente em sincronia, executando com o ritmo regular.

Nós, os autores, ainda não foram envolvidos diretamente na comunidade de código-fonte aberto grande fora da Microsoft, portanto, o que escrevemos aqui é baseado em suposições que são suportadas por outras publicações e blog postagens. Ao contrário dos projetos de código-fonte aberto, projetos de Ranger tem uma mentalidade de agendamento fixo-data de remessa. Como entendemos que ele, a maioria abre a entrega de projetos de origem quando terminar ou são bons o suficiente liberar, porém longo, isso leva. Para projetos Rangers, muitas pessoas dependem fortemente nossos artefatos. Se o nosso ciclo de desenvolvimento muito demorado, nosso trabalho pode se tornar obsoleto com uma nova versão do Visual Studio. Ter um fixo-data de remessa impulsionando o projeto poderia ser considerado anti-Scrum. No entanto, não vemos isso como diferente da hora-boxing sprints; Podemos hora inicial do projeto geral.

Para nossos projetos de Ranger, podemos usar o MSF para v 5.0 Agile Software Development ou o modelo de processo do Microsoft Visual Studio Scrum 1.0; Este último é de longe mais popular, pois é leve. Nossos projetos requerem algum planejamento antecipado e design; alguns métodos de processo se referir a isso como o pregame. Usamos Sprint 0 para esse trabalho pregame para definir um jogo na caixa-tempo terra e o planejamento e design. Isso garante que a data de início do desenvolvimento e os objetivos são conhecidos. Durante a Sprint 0, podemos Conduzir treinamento de equipe necessários, configurar o ambiente, o plano, a pesquisa, votar na prioridade extraordinária e analisar nosso processo de Ruck (discutiremos epopéias mais detalhadamente mais adiante). O programa de instalação dos ambientes é extremamente importante quando você considera um produto como o Microsoft Lab Management.

Como na metodologia Scrum, nosso processo de Ruck requer freqüentes pontos de verificação. Conforme discutido anteriormente, as reuniões diárias são muito grande para a equipe de Ruck. Nossa versão de um stand-up é uma reunião semanal, ou uma série de reuniões em diferentes fusos horários, conduzidas na Lync da Microsoft. Nessas reuniões são realizadas de modo clássico, onde os participantes serão mais perguntados sobre o que eles trabalharam, o que eles trabalhará em próximo e se há quaisquer impedimentos. Além disso, usamos a oportunidade para comunicar qualquer principais mensagens e reiterar a concepção de projeto/sprint. Temos aprendido que o uso de elementos visuais é mais eficaz. O mestre de Ruck ou o líder de desenvolvimento irá compartilhar sua área de trabalho para exibir gráficos sprint burn-down e mostrar a lista de itens de trabalho para o membro da equipe atual endereço. Visibilidade e visuais são chave!

Projetos de Ranger têm dificuldade em atingir velocity consistente, como você pode ver na a Figura 3. Isso é devido à natureza anti-Scrum das nossas equipes de onde a capacidade de equipe está sempre em fluxo. Membros da equipe podem desviar um projeto em um curtíssimo, deixando-na gerenciar de forma criativa para agilizar o trabalho ou solicitar novos colaboradores. Como esta é uma circunstância comum para nossos projetos de Ranger, nós já instituiu um Manifesto de Ranger para enfatizar a importância de tornar os compromissos necessários quando contribuindo para um projeto de Ranger.

Aprendemos que projetos menores e tamanhos menores de equipe permitem melhor execução adequada cadência e o mais profundo compromisso de membro de equipe. Além disso, parece que é mais difícil para alguém abandonar uma equipe pequena de uma equipe maior. Figura 4 demonstra um gráfico de burn-down sprint onde alcançamos boa cadência com conclusão do item de trabalho e a tendência real da gravação suspensa melhor coincide com a tendência ideal em comparação com a anteriores gráficos burn-down mostrado na a Figura 2.

Better Cadence Results in Better Burn-Down
Figura 4 obter melhores resultados de cadência melhor Burn-down

Usamos epopéias para uma propaganda de modo de exibição ou elevador de alto nível para um recurso de estrutura de tópicos. Isso mapeia minuciosamente o uso da comunidade Agile da epopéias: para contar uma história abrangendo mais de um recurso porque o cliente não estiver no local para fornecer detalhes sem qualquer tempo de latência. Você pode examinar um epic como uma matéria informando por que alguém iria querer instalar nossa solução ou fazer o download de nossa orientação. O epic orienta a visão para um recurso e orienta a criação de histórias de usuários relacionados em que criamos nosso trabalho. Como os modelos de processo do TFS out-of-the-box não tem um epic tipo de item de trabalho, e temos restrições onde podemos evitar a personalização do modelo, podemos prefixar o campo de título da história de usuário com "Epic" (consulte a Figura 5) e podemos dar a este item de trabalho uma prioridade zero para facilitar a identificação em relatórios ou filtros de relatório.

Use of Epic Prefix in the Title of User Story Work Item Type
Figura 5 uso de Epic prefixo no título do usuário matéria Work Item Type (clique para ampliar)

Projetos de Ranger são representados por várias funções de vagamente definidas, como desenvolvedor, testador, mestre Ruck, chefe do desenvolvedor, proprietário do produto, lead extraordinária e revisor. Em muitos casos, um membro da equipe pode assumir mais de uma função. Uma pessoa poderia ser um desenvolvedor para um recurso, um testador para um recurso diferente e um revisor para um projeto diferente. Três Rangers de núcleo geralmente reproduzir funções sólidas em todos os projetos: Bijan Javidi como gerente de projeto, Brian Blackman como mestre de Ruck e coach e Willy-Peter Schaub como líder de desenvolvedor.

A necessidade de pontos de verificação freqüentes e transparência completa torna uma parte essencial de nosso processo e o ecossistema de comunicação. Uma boa comunicação cria webs de apoio, monitorial e de colaboração entre a equipe geograficamente dispersa. Para criar um senso de pertencer, sempre temos virtuais lançamento reuniões face a face, durante os quais definimos um conjunto comum de metas, objetivos, motivações, visões, benefícios, escopos e restrições. Mais importante, durante esta reunião de lançamento, a equipe concorda em diretrizes de comunicação e de infra-estrutura.

Ruck-Ruck de reuniões, discutidas posteriormente, minimizam a necessidade de todos estar presente nas reuniões semanais de stand-up e garantir que o status e impedimentos são transparentes, ad-hoc, usando a comunicação de espontâneo e predefinida. Usando o rastreamento de Item de trabalho do TFS (WIT) e o mapeamento de epopéias, conforme mostrado na a Figura 6, podemos capturar as informações e informações como o progresso, lista de pendências, recursos, critérios de aceitação, bugs e impedimentos de estado. Stand-up minutos são documentados em wikis e informações de design em documentos armazenados no portal comuns. Em alguns casos, os minutos são armazenados no controle de origem, que — como todos os outros componentes de infra-estrutura — é acessível a partir de qualquer lugar do mundo.

Mapping the Ranger Epic/PBI/Task Hierarchy to Team Foundation Server Artifacts
Figura 6 Mapeando a hierarquia de Epic/PBI/tarefa Ranger nos artefatos do Team Foundation Server

Primários veículos de comunicação e colaboração são o portal compartilhado e, mais importante, de email. Usando listas de distribuição e um vocabulário controlado, os e-mails são compartilhados com todos, inclusive Rangers fora do escopo do projeto atual. Isso garante que todos os participantes recebam todas as informações, que unidades de transparência e, usando regras de email, delega leitura seletiva para aqueles interessados nas informações.

Compreendendo e lidar com o impacto das condições culturais e funcionando

Estilos de comunicação e gerenciamento diferem em diversos países. Algumas culturas preferem comunicação formal e distante, com funções de gerenciamento claramente definidas e as expectativas. Outras pessoas estão envolvidas em informal, na face freqüentemente colaborativo gerenciamento e, em que até mesmo um adotando "Abraço pela" é um sinal de respeito. Para definir os problemas potenciais e garantir que não há nenhum mal-entendidos que poderiam levar a membros da equipe de bitter e freqüentemente desconectados, temos que reconhece essa diversidade. Assim como acontece com muitos outros ALM e Inquilinos da equipe virtual, a transparência é crucial para proativamente e continuamente lidando com os desafios de cultura.

Diferenças de fuso horário e diferenças culturais mão-de-mão vai com freqüência. Enquanto algumas culturas ou indivíduos não se incomoda funcionando 24 horas por dia — ou, mais importante, chegar insane horas da noite para participar de uma reunião de equipe — outros levará ofensa excelente quando solicitado a investir tempo família pessoal em um projeto. Para criar um ambiente no qual equipe membros se sentir confortável e capaz de colaborar, é importante localizar mecanismos e horários em que contribuem para todas as pessoas na equipe para participar de discussões on-line ou de chamadas de conferência. A maioria da colaboração e comunicação de Ranger ocorre através de email e, mais importante, os TFS de equipe do projeto e associada ao portal. Podemos tomar muito cuidado para agendar reuniões de equipe regular stand-up onde compartilhamos pode promover a colaboração, status e promover continuamente a identidade da equipe. Quando estamos agenda várias reuniões de stand-up em fusos horários, os membros da equipe não são restritos aos seus próprios fusos. Eles estão permitidos para ingressar em uma ou mais reuniões que se ajustem ao seu fuso horário e os compromissos de seus negócios. Ruck-de-Ruck stand-up reuniões agregam o status para cima, conforme mostrado na a Figura 7, usando a colaboração e especialmente a infra-estrutura WIT. Depois de concluído, um status de equipe consolidado podem ser compartilhados transparente, com a equipe inteira e acionistas, usando os mecanismos de comunicação escolhidos pela equipe.

Ruck-of-Ruck Stand-Up Meetings
Figura 7 reuniões de Stand-Up de Ruck-de-Ruck

Figura 8 mostra a equipe virtual ideal, operando em um fuso horário, dividida em áreas de recurso no qual um cliente potencial de recurso apaixonados funciona com um número de dedicado e concentrado dos membros da equipe.

Ideal Virtual Team
Figura 8 Ideal equipe Virtual

Na realidade, a equipe de Ranger típica se assemelha ao a Figura 9, onde a equipe está espalhada em vários fusos horários em todo o mundo. A equipe lidera o trabalho com recursos de meio expediente em vários fusos horários, freqüentemente concentrados em diversas áreas de recurso dentro do projeto.

Typical Rangers Virtual Team
Figura 9 Rangers típicas equipe Virtual

Dando todos tenham acesso a tudo, levando a transparência completa, promovendo um ambiente de equipe simplificada, não-política e tomada de usam a tecnologia ALM de estado-de-arte, pudemos criar equipes de projeto apaixonados e eficaz. Conforme mostrado na a Figura 10, Rangers todos têm acesso a todos os projetos por meio de um portal Rangers, que inclui itens de trabalho, controle de origem, portais de projeto e o portal Rangers geral. Os Rangers usam o vocab controlado para categorizar os e-mails, permitindo a fácil filtragem e uso de regras.

Typical Rangers Infrastructure
Figura 10 infra-estrutura Rangers típica

A diversidade de condições de trabalho é provavelmente a parte mais desafiadora das nossas equipes virtuais. Não só são os membros da equipe de meio expediente Rangers e portanto regularmente desconectado durante o horário comercial normal, elas geralmente funcionam em ambientes seguros, limitando o acesso ao domínio público e a infra-estrutura de ALM Rangers. Além disso, alguns Rangers trabalham em ambientes menos favoráveis onde as linhas de comunicação de 9.600 bps ou modems de 56 KB são infra-estrutura padrão ainda. Isso limita sua capacidade de usar os serviços que dependem de redes de alta velocidade e grande largura de banda e ambientes.

Trabalhando com o TFS — especificamente os componentes de acesso da Web — e confiar em email para colaboração, pudemos criar uma infra-estrutura ALM eficaz e confiável que atenda a maior parte do Rangers.

Compreendendo e lidando com os compromissos e as motivações

Quais são as forças motrizes que tornam os profissionais de TI sacrifica tempo pessoal para colaborar com outros Rangers e a experiência agregada, o conhecimento e a informações em soluções Rangers e orientações, trabalhando com freqüência em isolamento? Cada um tem um conjunto diferente de compromissos resultantes, que precisa ser identificado e entendido, de forma que cada recurso pode ser utilizado com eficiência dentro da equipe e as motivações.

Ao trabalhar com equipes virtuais, descobrimos que ele é importante identificar todos os membros da equipe que são apaixonados por tecnologia, tem uma mentalidade "de seja feito" e são motivados, open-minded e altamente self-disciplined. Nenhuma identidade de equipe, tecnologia ou processo permitirá que as pessoas que precisam de uma grande quantidade de supervisão para trabalhar efetivamente em equipes virtuais, especialmente quando eles também deverá atender a uma função de líder de equipe.

Utilizando o processo de Ruck e a solução de ALM do TFS para definir epopéias, pendências de produto e tarefas foram de extrema importância, especialmente quando os membros da equipe forem solicitados a voluntário para tarefas, em vez de serem atribuídos a tarefas. Além disso, a capacidade para que possamos rastrear o progresso continuamente — ou a falta delas — nos permitiu identificar e lidar com desafios e impedimentos desde o início. Infelizmente, um desafio que ainda podemos ainda não conquistados está ficando em torno do fator humano de obter todos os usuários atualizar regularmente seus itens de trabalho em tempo hábil sem lembretes constantes.

Conforme mostrado na a Figura 11, podemos usar uma combinação das reuniões da equipe regular, uma estratégia de colaboração contínua e tecnologia para definir e comunicar-se a equipe de finalidade, visão, produto status do projeto e a lista de pendências com a equipe e partes interessadas. Isso garante que obtemos contínua e compromisso com o de todos, mesmo quando estiver trabalhando em um ecossistema desconectado, virtual, isolado e fáceis.

Using Technology for Collaboration and ALM
Figura 11 usando a tecnologia para colaboração e ALM

É impressionante como se um problema isolado torna um desafio de equipe quando sua existência e o impacto potencial sobre o objetivo da equipe é transparente. Usando o TFS e nosso processo de Ruck nos permitiu manter o status e desafios "diante de todos." O resultado é que a equipe freqüentemente identifica e soluciona os desafios antes de precisar relatá-los na próxima reunião semanal stand-up.

Nossas recomendações superior

Existem muitas recomendações, técnicas e práticas recomendadas que ajudarão você a melhoram o ambiente de equipe virtual, a colaboração e a eficácia de cada membro da equipe e a qualidade dos resultados. Para nós, sete recomendações principais incluem:

  1. Definir e promover uma identidade de equipe e a visão.
  2. Defina claramente o processo, como o processo Ruck.
  3. Defina claramente as diretrizes de comunicação e protocolos.
  4. Definir metas claramente, compartilhe o status e comemorar os resultados práticos.
  5. Implemente uma infra-estrutura ALM que permite que a equipe a colaborar de maneira efetiva, como o TFS e tecnologia associada.
  6. Promova a visibilidade e transparência completa em um ritmo regular.
  7. Escolha com sabedoria, suas equipes perguntando membros ser voluntário e promover apaixonados e get-it-done indivíduos.

Em um futuro artigo, estamos investigarei como as Rangers estão usando a fábrica de VM e o Visual Studio ferramentas de teste no ambiente de equipe virtual e distribuídas para promover a consistência e aumentar a qualidade geral de nossas soluções de out-of-band.

Brian Blackman é consultor principal da equipe Microsoft Services parceiro ISV, concentrando-se em afetar o sucesso de parceiros ISV em engenharia e no mercado. Ele tem um MBA e é CSM, MCSD (C++), MCTS e Visual Studio ALM Core Ranger. Ele ocupa seu tempo escrevendo código, criando e fornecendo workshops e consultoria em diversas concentrações e todas as coisas ALM.

Willy-Peter Schaub é gerente de programas sênior da equipe Visual Studio ALM Rangers do Microsoft Canada Development Center. Desde que o médio-se dos anos 80, ele tem sido esforçando forsimplicity e a sustentabilidade em engenharia de software. Seu blog está em blogs.msdn.com/b/willy-peter_schaub e você poderá segui-lo Twitter no twitter.com/wpschaub.

Graças aos seguintes especialistas técnicos para revisão deste artigo: Ben Amodio, Fourie de Mike, Heys de Bill, Bijan Javidi e Patricia Wagner