Case INtel

Esta é uma tradução do artigo encontrado no link: http://www.michaeljames.org/Intel-case-

study.pdf

Desenvolvimento Ágil de Projetos na Intel: Uma Odisseia Scrum por Pat Elwer, Intel
Corporation Os colaboradores incluíram Tim Gallagher, Intel Corporation; Katie Playfair,
Danube Technologies, Inc.; Dan Rawsthorne, Danube Technologies, Inc.; e Michael James,
Danube Technologies, Inc.

RESUMO
Na indústria de microprocessadores, o grupo de engenharia de desenvolvimento de produto
(PDE) existe para fornecer a garantia de teste para dar suporte à triagem e classificação de
dispositivos econômicos. Espremido entre as equipes de projeto reais e as equipes de
fabricação da fábrica, o PDE é frequentemente colocado sob uma pressão tremenda sem o
controle final do prazo, escopo, requisitos ou entregas no nível da equipe. Para coordenar
melhor os esforços das subequipes dentro do PDE, sete equipes compostas por
aproximadamente 50 pessoas se ofereceram para pilotar uma abordagem mais integrada
para o desenvolvimento de produtos. Para organizar essa integração, os autores decidiram
que o Scrum era a melhor estrutura de gerenciamento de projetos para empregar junto com
as melhores práticas de engenharia ágil. Este artigo descreve a jornada percorrida pela
organização, suas lições aprendidas e os resultados de seu investimento no Scrum.

INTRODUÇÃO
No mundo da engenharia de software de implementação ágil e Scrum, uma infinidade de
existem boas práticas. Muitos deles envolvem organizações de pequeno ou médio porte
usando equipes pequenas, desenvolvendo software em linguagens orientadas a objetos. O
Óregon e A equipe de PDE da Pacific (OAP) é uma grande organização que precisa
implementar Scrum e ágil em várias equipes, sites, culturas e ambientes. Nosso produto de
trabalho é um Programa de Teste executado em Equipamento de Teste Automatizado (ATE).
A ATE tem um sistema operacional proprietário e linguagens de interface que nos impedem
de usar soluções de validação de software padrão da indústria e prontas para uso. Em
essência, nós somos trabalhando em um ambiente de linguagem proprietária sem teste de
unidade pronto para uso estrutura e sem recursos de teste off-line. Além disso, temos uma
longa história de excesso de requisitos, comprometimento excessivo, cronogramas
perdidos, semanas de trabalho insanas, moral e altas taxas de rotatividade.
Uma longa história em fabricação resultou em uma forte cascata cultura da Intel,
amplamente adotada como o melhor caminho para o sucesso. As equipes são organizadas
em “silos” funcionais com entregas programadas regularmente de entregas para outros
equipes de silos funcionais. O resultado é que algumas equipes carregam uma carga
incomum no final fases do ciclo de vida e tinham uma rotatividade muito alta ao final de um
projeto. Por fim, cada A equipe é composta por especialistas de domínio cujas habilidades
raramente se sobrepõem às de seus membros do time. Portanto, é difícil ou impossível
emparelhar tarefas ou compartilhar responsabilidade dentro de uma equipe.
Apesar de todos esses desafios, queríamos seguir em frente com uma forma diferente de
gerenciar e organizar projetos para unir melhor as equipes de teste e suavizar o entrega do
nosso produto de trabalho. Escolhemos apresentar o Scrum para a organização no início de
um projeto, quando a maior parte do trabalho era o desenvolvimento do pré-silício trabalho
de infraestrutura e prontidão. Se conseguíssemos fazer o Scrum funcionar durante este
primeiro fase, sentimos as boas práticas aprendidas neste período relativamente calmo do
projeto encontrariam seu caminho para a fase de execução mais estressante - quando o
trabalho diário é dependente da integridade do silício real, condições dinâmicas de negócios
externos e os requisitos dos clientes de Fabricação, Projeto e Manufatura.

FASE 1: PREPARAÇÃO PARA O SILICONE

O grupo de transição inicial incluía seis equipes e várias subequipes. como primeiro etapa,
contratamos a Danube Technologies, Inc. como uma empresa de treinamento e
treinamento em Scrum fornecedor. Aproximadamente 20 líderes de grupo e técnicos
participaram de um evento de dois dias Curso de treinamento Certified ScrumMaster como
uma introdução intensa aos princípios do Scrum e práticas. Infelizmente, três gerentes
seniores faltaram ao treinamento e isso resultaram em impedimentos subsequentes ao
longo do processo de transição. Executivo patrocínio foi fundamental para o nosso sucesso.
Ter nossos três líderes mais antigos ausentes desde a formação inicial gerou lacunas no
conhecimento das mudanças que estávamos tentando fazer.
Após o treinamento, os participantes participaram de uma reunião retrospectiva e
discutiram, sem a presença dos representantes do Danúbio, seus pensamentos, reservas e
nível de comprometimento com uma abordagem Scrum para gerenciamento de projetos. Os
líderes de equipe concordou em se comprometer com três meses de implementação dos
princípios e práticas do Scrum “pelo livro” antes de questionar a eficácia do novo processo
ou tentar para adaptá-lo às necessidades da Intel. Uma Equipe de Ação de Processo (PAT)
foi formada para monitorar o desenvolvimento do Scrum dentro das equipes piloto e
fornecer suporte para o processo perguntas. Mesmo que houvesse acordo, eu já podia
sentir uma divisão noorganização em “porcos” e “galinhas” em termos de suporte ao Scrum.
Os líderes de grupo e equipe funcionaram como os proprietários do produto para todas as
sete equipes, enquanto eu trabalhou como ScrumMaster. Eu senti fortemente que o Scrum
era um framework importante para implementar dentro dessas equipes e eu estava
disposto a correr o risco de defendê-lo. Embora o resultado de correr esse risco tenha sido
positivo, quase não sobrevivi a um quarto de Scrum Mastering sete equipes!
Trabalhando com os consultores do Danúbio Michael James e Dan Rawsthorne, determinou
que ter ScrumMasters voluntários seria importante para o sucesso de cada equipe sucesso e
para sua própria sanidade. Primeiro, trabalhamos com a administração da Intel para fazer
certifique-se de que o papel do ScrumMaster foi valorizado no sistema de avaliação de
desempenho como “real trabalho de engenharia”, em vez de sobrecarga administrativa. Em
segundo lugar, aqueles que escalados para assumir funções de ScrumMaster o fizeram em
equipes nas quais não tinham aposta técnica. Isso ajudou a evitar quaisquer conflitos de
interesse entre seus próprios projetos técnicos e suas responsabilidades de facilitação. Não
havia orçamento para ScrumMasters desistam de seu próprio trabalho de engenharia em
favor do trabalho do ScrumMaster.
No entanto, apoiou-se uma mudança mais leve no papel do produto para aqueles que
passaram até conduzir o processo nas posições de ScrumMaster.

Após aproximadamente cinco meses, escalar o trabalho entre as equipes Scrum tornou-se
um dos maiores desafios. Antes de adicionar as cinco equipes adicionais que foram
formadas durante o restante do ano, a organização precisou de mais conhecimento sobre
como gerenciar as dependências entre várias equipes e facilitar uma melhor comunicação
entre equipes. A Danube foi novamente contratada para desenvolver um Scrum
customizado scaling para alguns dos participantes originais do Certified ScrumMaster curso
junto com os gerentes seniores que faltaram à primeira aula. este dia inteiro
O treinamento revisou os principais princípios de planejamento de lançamento,
planejamento de sprint e, em em particular, dimensionamento em várias equipes.
Novamente, adotamos o “aprender, experimentar, inspecionar e adaptar” a essa escala.
Depois de aprender algumas “práticas recomendadas” para dimensionamento, levamos o
problema de volta às equipes para experimentar um dos modelos de escala da classe e, em
seguida, adaptou a abordagem para o ambientes do mundo real das equipes. Depois de
adicionar algumas funções para lidar com questões técnicas dependências e mais camadas
de organização, o grupo conseguiu escalar para 12 Equipes Scrum, cada uma contendo
aproximadamente cinco a nove desenvolvedores, dentro de um ano.
Dois dos principais aspectos das transições organizacionais bem-sucedidas que discutimos
com os consultores do Danúbio foram o voluntariado e a auto-organização. Embora as
equipes que se comprometeram com um período de teste de três meses de "Scrum
conforme o livro" foram solicitados a aderir aos princípios e práticas centrais, a adoção foi
claramente mais importante do que adesão. Uma atitude de “por favor, apenas tente” da
gerência resultou em melhor buy-in das equipes. Após o teste de três meses, as equipes
tiveram a liberdade para se organizar e inspecionar e adaptar sua abordagem a cada sprint.
Embora as equipes precisavam trabalhar juntas, eles tiveram o máximo de liberdade
possível para determinar o que funcionaria para eles. Desvios foram discutidos, mas não
julgados em a reunião do PAT com todos os POs e ScrumMasters toda semana. Nosso
objetivo nesta fase era unidade, não uniformidade.
A visibilidade também foi crucial para esse processo. Um wiki interno permitiu que as
equipes documentassem o que funcionou para eles, o que não funcionou bem e sugestões
de melhores práticas para Adoção do Scrum.
A implementação do Scrum “by the book” foi parte integrante do lançamento do Scrum em
toda a as equipes. Porém, em uma organização do porte da OAP, é necessário estar em
conformidade com certas estruturas ou requisitos organizacionais. Após o período piloto de
três meses, algumas modificações foram feitas para encaixar o Scrum em nossa cultura e
ambiente. Primeiro, a equipe teve que definir quais funções eram mais úteis para seus
objetivos. Nós desenvolvemos o seguintes descrições de funções:
Proprietários de negócios: gerentes seniores ou engenheiros principais encarregados de
supervisão de várias equipes ou questões técnicas abrangentes para todas as equipes. Os
BOs definem os marcos do roteiro (Plano de Liberação) e definem o 'desejado'
características em cada marco. As equipes Scrum ainda possuíam dimensionamento e
comprometimento para atender aos marcos do recurso com base em sua velocidade.
Product Owners: gerentes de grupos tipicamente funcionais.
Proprietários Técnicos: Líderes técnicos de cada uma das áreas funcionais que poderia
colaborar na integração, dependência e questões arquitetônicas para garantir a congruência
entre equipes com saídas dependentes. anúncios retidos por TOs reuniões hoc para dividir
os épicos em histórias capazes de correr.
ScrumMasters: Um engenheiro de equipe cruzada sem participação específica no projeto
equipe ele ou ela era ScrumMastering. Isso ajudou a conter o desejo de ScrumMaster para
se intrometer na solução técnica.
Equipes: equipe encarregada de uma determinada saída do conjunto de testes, raramente
com membros da equipe multifuncional. Quase sempre uma equipe de silo funcional.

Transitório: membros do grupo com conjuntos de habilidades altamente especializados

necessários para várias equipes para apenas um sprint ou dois de cada vez. Eles vieram e
foram em limites de sprint.
Conduit: Membro da equipe que representa mais de uma pessoa, incluindo supervisores
contratados ou membros locais de uma equipe remota. Os conduítes podem inscreva-se
para muito mais pontos de história de trabalho do que um membro normal da equipe.
Proprietários da história: Um especialista técnico com conhecimento específico sobre como
completar uma história que pode desenvolver tarefas e solicitar a participação de
certos membros da equipe na conclusão dessas tarefas. A única pessoa que você pode
vá e pergunte: "Qual é o status desta história?" e obter a resposta certa de, todas as vezes.
Finalmente, durante esta fase de desenvolvimento do produto, o grupo geral de times
Scrum era essencialmente seu próprio cliente. Estávamos apenas construindo infraestrutura
para dar suporte depuração e fabricação de silício. Não havia nenhuma força externa
solicitando certas recursos durante o primeiro ano ou mais do projeto. Isso tornou o valor
do negócio uma tarefa difícil métrica para priorização. Assim, os POs e BOs procuraram
priorizar funcionalidades com uma combinação de valor comercial estimado e prioridade
geral, principalmente como um estratégia de gerenciamento de dependência.
No final do primeiro ano, o Scrum havia se enraizado na organização e tornar-se a estrutura
padrão para planejar nosso trabalho e gerenciar nosso requisitos. O PAT tinha uma riqueza
de dados sobre quais “alfaiatarias” eram e não eram trabalhando. O silício surgiu no
horizonte. O processo se sustentaria sob condições reais? pressão dos negócios ou seria
jogado pela janela em favor de fazê-lo "à moda antiga?
FASE 2: SILÍCIO SOBREVIVENTE
O primeiro silício é um momento difícil para ser um engenheiro de desenvolvimento de
produto. Se você mapeou no Diagrama de Stacey, seria o pixel superior direito no espaço do
caos!
Quando o silício chega, todos os requisitos são ambíguos e leva algumas semanas para
coletar os dados necessários nos dispositivos de silício para determinar o caminho que o
projeto seguirá leva.
Decidi dar um passo atrás e “inspecionar e adaptar” a abordagem da minha organização ao
Scrum com base no que vi acontecer no primeiro silício. O que eu vi realmente me
surpreendeu. eu tive um Equipe Scrum que voltou aos velhos hábitos. Alguns outros Scrums
decidiram que eram feito no punho de silício e se desfez graciosamente. O resto se agarrou
ao Scrum como um afogamento homem a um colete salva-vidas.
Nossos sprints de duas semanas eram impossíveis de manter neste ambiente e a maioria Em
vez disso, as equipes Scrum foram para sprints de um dia. Eles se encontrariam por uma
hora a cada dia para planejar as próximas 24 horas e rever e refletir sobre o anterior. os
quatro do Scrum as reuniões desmoronaram sob a gravidade do primeiro silício em uma
única reunião. No entanto, quando participei dessas reuniões, vi que os principais
comportamentos do Scrum – como priorização com base no valor comercial,
dimensionamento da equipe, não trabalhar fora do backlog, atualizações e swarming,
implementando melhorias de processo e revisando o trabalho produto - estavam
acontecendo, apenas em uma escala muito menor e mais rápida, pois o conhecimento o
dispositivo estava crescendo.
Na reunião diária de depuração, onde todos os líderes e gerentes da organização foram
presente, eu ouvia qualquer pedido ad hoc sendo feito seguido por um PO dizendo, “Existe
uma história pendente para isso?” Também vi muitos exemplos em que os desenvolvedores
pegavam uma parte interessada ou PO e os arrastavam para o equipamento de teste para
testemunhar que o conteúdo adicionado ao programa atendeu aos critérios de aceitação.
Esse período de intensa depuração e desenvolvimento durou algumas semanas. No final
daquela época, os Scrums sobreviventes emergiram intactos e expandiram seus sprints de
volta para duas semanas, como um acordeão. A mudança foi anunciada no Friday Debug
reunião, ocorreu no fim de semana, e os sprints de duas semanas permanecem em vigor até
hoje.
FASE 3: PREPARAÇÃO PARA FABRICAÇÃO
À medida que o silício ficou mais saudável e nos preparamos para a rampa de fabricação, eu
percebeu que os Scrums do silo funcional estavam sendo sobrecarregados por
transferências no ambiente pós-silício. Uma transferência ocorre sempre que
responsabilidade, conhecimento, ação, e feedback são separados (Ward):
• Uma pessoa decide o que fazer (responsabilidade);
• Outra pessoa define como será feito (conhecimento);
• Uma terceira pessoa implementa (ação); e
• Uma quarta pessoa valida o trabalho (feedback).
Além disso, a Lei de Conway afirma que as organizações que projetam sistemas são
obrigados a produzir designs que são cópias das estruturas de comunicação de essas
organizações (Conway). Eu sabia que as equipes multifuncionais faziam parte do Scrum “de
acordo com o manual” e senti que elas resolveriam esse impedimento específico, mas não
não encontrou uma solução viável para formá-los dentro da organização.
Durante esse tempo, observei várias Forças-Tarefa sendo formadas para lidar com questões
de conteúdo de silício. Na Intel, uma Força-Tarefa é uma equipe multifuncional formada em
resposta a uma crise. Se você for convocado para participar de uma força-tarefa, é porque
você é um especialista. Você é imediatamente responsável pelo sucesso da Força-Tarefa,
você abandona que quer que você esteja fazendo, e você não pode dizer não. Eu não
conseguia ver como obter o benefício multifuncional da Força-Tarefa sem mudar a estrutura
da organização.
Por coincidência, agendei um treinamento de desenvolvimento de produtos Lean com Mary
e Tom Poppendieck para a equipe neste período e o treinamento Lean revelado uma pista
importante sobre como usar o Scrum de forma eficaz nesta fase:
Manter Equipes Funcionais: Estas são estruturas organizacionais úteis como conhecimento
e profundo conhecimento técnico moram aqui. Eles também fornecem Scrum membros da
equipe um lugar para “voltar para casa” entre os projetos.
Crie Scrums de “recursos” multifuncionais: empréstimo de equipes funcionais especialistas
responsáveis para equipes Scrum multifuncionais. Os membros da equipe Scrum
multifuncional são 100% dedicados e não são influenciados por seus gerentes funcionais
durante o sprint.
Quando ouvi isso, realmente ressoou comigo. Um Scrum multifuncional é uma tarefa Força
sem crise!
Executamos um piloto rápido em um tipo de conteúdo e os membros da equipe adoraram.
O transferências foram bastante reduzidas. Os membros da equipe foram capazes de lidar
com os problemas. A comunicação e o conhecimento fluíram sem problemas. E se um
determinado membro da equipe função não era necessária em um sprint, eles se juntaram a
outro membro da equipe para cross-training e ajudar onde eles poderiam.
Mais uma vez, o timing era tudo. Esses dados piloto multifuncionais foram lançados apenas
em tempo para nossa reunião anual de liderança externa. Esta foi uma grande oportunidade
para
influenciar a liderança da organização e fazer uma correção de curso que permita Scrum
para funcionar ainda melhor do que antes. Apresentei minhas observações e os primeiros os
dados do piloto multifuncional único e a organização foram vendidos. Na verdade, todos
dos opositores, bem como a parcela indecisa da organização, aderiu a o conceito Scrum
multifuncional. Isso adicionou cinco novos Scrums ao nosso processo, elevando nosso
impacto total para 18 Scrums em dois anos!
RETROSPECTIVA:
Usei um esquema simples (+) e (-) para indicar o que deu certo e o que não deu certo.
Definição Forte de Feito (+)
Como não temos uma linguagem de programação 'real', não temos um teste de unidade
framework ou uma regressão offline. No desenvolvimento de produtos microprocessados, a
unidade testar significa testar unidades de silício! Isso nos levou a focar em escrever boas
histórias e, mais importante, escrever bons critérios de aceitação. Os critérios de aceitação
(AC) fornecem uma forte definição de feito, detalhando os requisitos para a satisfação do
cliente.
Também implementamos um processo de verificação leve que chamamos de “Pair Análise."
Para completar uma história, o desenvolvedor e PO ou parte interessada devem sentar-se
juntos e concorda que as AC foram atendidas. Coletamos métricas simples sobre essa
atividade em a forma de Adds, Saves e Escapes.
Acréscimos são CA adicionais que o SH/PO adiciona à história durante a Revisão do Par
processo que são aceitos pelo desenvolvedor para o sprint atual e são uma indicação da
história ambígua AC. Salvamentos são bugs criados neste sprint e capturados neste sprint.
Escapes são bugs criados em um sprint anterior e encontrados no sprint atual. Economizar
indicam que o processo de verificação está funcionando, enquanto Escapes indicam que ele
precisa melhorar.
Além disso, tivemos que definir um processo de validação robusto. A validação não pôde ser
generalizada nos Scrums como verificação, então cada Scrum documentou seu regras de
validação, essencialmente definindo o que significa ser feito com validação para seu produto
de trabalho. A validação deve garantir que a história funcionará corretamente no
lançamento produto de trabalho e geralmente envolve a execução de dispositivos no
equipamento de teste.
Uma história só é concluída se todas as tarefas forem concluídas e tiverem sido verificadas e
validadas.
Nenhum crédito parcial (+)
Ao determinar a velocidade para o próximo sprint, nenhum crédito é dado para histórias
que são não "feito" com base em nossa definição acima. Isso pode parecer draconiano, mas
foi necessário para forçar a equipe a prestar atenção à verificação e validação requisitos e
certifique-se de que suas estimativas incluam essas etapas. Também força o equipe esteja
atenta aos seus compromissos. Se você se comprometeu a 100 por cento feito e você
entregou 90 por cento, você falhou.
Sprints de nove dias (+)
Corremos por nove dias e realizamos reuniões de revisão, retrospectiva e planejamento a
cada outra sexta-feira. Dessa forma, a equipe está sempre fora de um sprint a cada dois fins
de semana. Isso ajudou muito a melhorar a qualidade de vida e o moral das equipes Scrum.
Por outro lado, todos os fins de semana eram no meio do Sprint e os membros da equipe
poderiam decidir entre si se precisavam trabalhar no fim de semana para atender suas
metas. Isso aconteceu raramente após os primeiros seis meses e conseguimos um cadência
repetível e um ritmo sustentável.

Cadência (+)
A cadência de sprint de nove dias permitiu que POs, BOs e equipes mudassem de direção
conforme necessário, em intervalos frequentes. Essa cadência realmente ajudou a reduzir
os requisitos thrash que tínhamos visto em projetos anteriores e gerentes de alto nível
começaram a ver que a equipe era capaz de produzir um produto de trabalho real todas as
sextas-feiras. dados nós coletados mostraram que 10 a 20% da velocidade foi perdida
quando um sprint foi significativamente interrompido. Chamamos isso de “taxa de
interrupção do sprint”. Dez por cento de a velocidade era perdida se a interrupção
ocorresse na primeira semana do sprint e 20 por cento se veio na segunda semana. Os
gerentes foram informados dessa estatística. Eles começaram respeitar a cadência dos ciclos
de planejamento. Também adicionamos uma regra de que qualquer alteração um sprint
ativo força uma renegociação de escopo. Mais uma vez, a administração respondeu e
quando eram necessárias interrupções, eles geralmente vinham preparados para trocar
itens de o backlog do sprint.
PO na Equipe (-)
Como forma de facilitar uma melhor comunicação entre os Product Owners e o equipe,
permitimos que os Product Owners atuassem como membros participantes de cada equipe.
Dentro alguns casos, funcionou muito bem, mas em outros, os POs microgerenciaram as
equipes, ditando as tarefas do dia-a-dia e impedindo a comunicação honesta entre a equipe
membros. Isso levou as equipes a realizarem reuniões secretas para discutir problemas
organizacionais reais. impedimentos fora da visão de seu PO/gerente funcional. Embora
estes situações parecem estar se resolvendo com o tempo, elas prejudicaram a capacidade
da equipe de auto-organizar. Quando construímos os Scrums multifuncionais, não
permitimos essa prática.
Ferramenta Central Scrum (+)
O Scrum requer contabilidade para gerar métricas úteis, como o gráfico de burndown, todo
dia. Isso é especialmente verdadeiro ao executar vários Scrums ou Scrum-of-Scrums em sua
organização. Ter uma ferramenta central de acesso aberto contribuiu muito para o sucesso
da transição. Quando começamos nossa jornada, não consegui encontrar ferramentas para
apoiamos o Scrum-of-Scrums, então criamos o nosso próprio. Começamos com o XPlanner e
personalizamos significativamente com Java e SOAP em algo que chamamos “XPlanner2.”
Com base nesses aprendizados, criamos um aplicativo personalizado do Windows.
Essa ferramenta central tem sido um facilitador essencial para o gerenciamento de várias
equipes. enquanto eu acredito que você deve ter ferramentas para habilitar e facilitar o
Scrum em larga escala, as ofertas disponíveis no mercado amadureceram a ponto de eu
provavelmente não aceitar isso abordagem caseira novamente.
Enormes Atrasos (-)
Gerenciar um “backlog de acesso total” também é um desafio. Se alguém, a qualquer
momento, puder adicionar qualquer coisa no backlog de uma equipe, pode parecer que a
equipe está sendo bombardeada com solicitações de. Alguns POs queriam bloquear suas
pendências que não permitem entrada de outros membros da equipe ou partes
interessadas. Nossa ferramenta para Scrum coloca “novas” histórias em uma pilha diferente
das Histórias “aceitas”. O PO pode então revisar cada nova história, discutir com as partes
interessadas e decompor a história de forma adequada. Nós também implementamos um
“congelador” para histórias que sabíamos que não conseguiríamos por alguns corrida. As
partes interessadas puderam ver que seus pedidos estavam no congelador e o principal
backlog tinha apenas três a cinco sprints de profundidade.
Pontos de história (+)
Como a maioria das equipes não tinha um quadro de referência comum, a maioria dos
Scrums usava dias. O tamanho relativo é melhor, mas mais difícil de obter na maioria dos
meus Scrums. tivemos que assistir nosso uso da palavra “dias” ao falar com gerentes de
nível superior não familiarizados com Scrum. Rapidamente passamos a falar sobre “pontos”
ao revisar dados com forasteiros.
Tarefas levam menos de um dia (+)
Jogar estimativas de horas pela janela foi libertador para as equipes e gerentes. As histórias
recebem um grau de “dificuldade” em pontos de história e as tarefas são simplesmente
itens que são binários - concluídos ou não concluídos. Uma tarefa é sempre menor que uma
dia, portanto, se uma pessoa está trabalhando em uma tarefa por mais de um dia, sabemos
que ela está provavelmente impedido.
Observações de Burndown no Daily Scrum (+)
Métricas e representações visuais de status também foram de vital importância para o
sucesso de encontro. Um gráfico de burndown de sprint visível provou ser eficaz em alertar
as equipes se elas estiverem ficando para trás e iniciou conversas com POs sobre o status,
antes do final de uma corrida. O ScrumMaster trouxe o gráfico de burndown todos os dias.
Como um Como resultado, ninguém entra em uma reunião de revisão chocado por algo ter
acontecido ou não. Realizado.
Revisão Incremental (+)
Não gostamos de esperar até a reunião de revisão para buscar a aprovação do PO. Nosso O
processo de verificação de revisão em pares encorajou o PO e o desenvolvedor a se
sentarem juntos como logo uma história foi considerada pronta para verificação. Isso
eliminou a maioria das surpresas na reunião de revisão onde o produto final do trabalho foi
revisado. Também fez para um reunião muito mais curta.
Velocidade (+)
A visibilidade do backlog, relatórios de progresso e métricas gerais ajudam a ajustar o
gerente expectativas com frequência para que possam tomar decisões de negócios com
base no real conquistas das equipes. As métricas de velocidade forçam os POs a agendar o
trabalho para capacidade. Afinal, você não pode obter 80 pontos de história de uma equipe
de 50 pontos.
Patrocínio Executivo (+)
O suporte foi uma vitória crucial para as equipes e os gerentes. Sem alto nível apoio do
gerente da organização, a transição não teria sido bem sucedido. A alta administração
forneceu suporte estrutural, incentivos para aqueles que assumiu um papel de liderança nas
equipes e deu-lhes crédito de carreira por suas contribuições.
A liderança também forneceu desincentivos para aqueles que optaram por subverter o
processo. Os impedimentos humanos foram “reaproveitados” para garantir o sucesso, mas
não perdemos nenhum pessoas na transição.
Mudança de Comportamentos (+)
Finalmente, o comportamento não é aprendido a menos que seja praticado. Minha equipe
aprendeu que o a prática do Scrum gera um melhor comportamento e resultados do Scrum.
Por consistentemente escopo de negociação, praticando priorização, criando requisitos
claros, aderindo a time boxes, de olho nas métricas e visando a auto-organização da equipe,
O Scrum sobrevive e prospera dois anos depois de dar os primeiros passos.
RESULTADOS
O Scrum causou impacto de quatro maneiras principais: Tempo de Ciclo, Desempenho para
Programar, Moral e Transparência.
Tempo de ciclo reduzido
• O Scrum foi um dos principais contribuintes para uma redução de 66% no tempo de ciclo.
Desempenho para Programar
• Estabelecemos e mantemos um planejamento baseado em capacidade e uma cadência de
duas semanas por mais de um ano.
• Nós praticamente eliminamos atrasos no cronograma e compromissos perdidos.
• Os clientes e a alta administração estão mudando seus comportamentos para proteger a
cadência de duas semanas.
Moral melhorada
• Melhor comunicação e satisfação no trabalho.
• O que era a equipe com moral mais baixa agora é a equipe de melhor desempenho.
Maior Transparência
• Levou à adoção de padrões formais, estilo CMMI, VER e VAL.
• O Scrum descobriu bugs, impedimentos, ferramentas fracas e engenharia deficiente
hábitos.
O Scrum tem sido um dos principais contribuintes para um tempo de ciclo consistente e
repetível de 66% redução na criação de nosso produto de trabalho. Embora também
tenhamos passado por alguns grandes melhorias de ferramentas, acredito que o Scrum
contribuiu com cerca de 50 por cento esses ganhos.
A cadência de sprint de nove dias fornece previsibilidade de cronograma robusta. Este a
previsibilidade na verdade levou a menos desgaste nos requisitos da equipe como
gerenciamento busca evitar o pagamento da taxa de interrupção. Simplesmente não
perdemos mais prazos por meio de uma gestão agressiva de prioridade e escopo.
A satisfação no trabalho vem de atingir consistentemente as metas estabelecidas com base
na velocidade planejamento. A equipe sente um orgulho incrível em sua capacidade de fazer
e atender compromissos. A moral está muito mais alta e o ritmo sustentável é muito
valorizado no organização.
Muitas, muitas práticas e sistemas tradicionais de engenharia estão sendo questionados
como O Scrum torna as inadequações mais visíveis. Isso nos levou a investir em mais
infraestrutura para nos permitir adotar práticas ainda mais ágeis.
RESUMO
O Scrum nos serviu muito bem na Engenharia de Desenvolvimento de Produto. palavra do
nosso sucesso está se espalhando por toda a empresa e tenho divulgado a palavra no
benefícios do Scrum.
Tivemos muitos falsos começos ao longo do caminho e tivemos que aprender muitas lições
difíceis.
No entanto, tivemos um forte comprometimento de nossa administração e um quadro
restrito de Crentes do Scrum que nos mantiveram voltando para torná-lo melhor. No final,
acho que fizemos grandes progressos para mudar nossa organização de uma organização
baseada em planos e comando e controle em uma organização baseada em planejamento
empírico, de inspeção e adaptação, auto-organizada.
Eu estava dando uma aula interna de “Introdução ao Scrum” e alguns membros da minha
organização estiveram presentes. No meio da aula, um deles surgiu durante um intervalo e
disse: “É engraçado, mas eu não sabia que havia regras. Isso é apenas meu jeito de
trabalhar.” Mudar comportamentos é uma jornada longa e difícil, mas vale o esforço.
RECONHECIMENTOS
O autor gostaria de agradecer ao pessoal da Danube Technologies, Inc. treinamento,
orientação do paciente e resolução de problemas quando necessário. Também gostaria de
agradecer a Mary e Tom Poppendieck por nos darem uma visão sobre o uso adequado de
equipes multifuncionais.
BIBLIOGRAFIA
Desenvolvimento Ágil de Software com Scrum por Ken Schwaber
Implementando o Desenvolvimento de Software Lean por Mary e Tom Poppendieck
Desenvolvimento Lean de Produtos e Processos por Allen Ward
Datamation Proceedings, 1968 por Melvin Conway