Visualizar - Rally Software

Cartilha do CIO para Adoção doMétodo Scrum de Obtenção deAgilidade em SoftwaresWhite PaperBy Dean Leffingwell, Hubert Smits and Ken SchwaberA alta competitividade do mercado global levam as empresas aaprimorar cada vez mais suas habilidades na produção de softwaree os torna sua principal vantagem competitiva. Independente dotipo de software, sejam para gerenciar processos de manufatura oude entrega a clientes, ou softwares que melhorem a eficiência dasatividades diárias, eles atingem virtualmente qualquer faceta dosnegócios atuais. Este documento descreve como CIO e gerentesexecutivo podem implementar o Scrum em toda a organização,inclusive podendo escalá-lo para grandes projetos e multiplasequipes, além dos desafios a enfrentar, bem como as recompensas efornece uma cartilha para a adoção do Scrum em empresas onde ossoftwares e muitos deles, são primordiais para o sucesso competitivono mercado.www.rallydev.com©2013 Rally Software Development1

ConteúdoINTRODUÇÃOVISÃO GERAL DO SCRUM E DA AGILIDADE DOS SOFTWARESPRINCÍPIOS DO SCRUMO SCRUM E A AGILIDADE DOS SOFTWARESPREPARANDO-SE PARA O SCRUM“SCRUMMING” TANTO NO PROCESSO DE SOFTWARE QUANTO NA ORGANIZAÇÃOO PAPEL DO CIO COMO SCRUMMASTER ORGANIZACIONAL PARA O APRIMORAMENTO CONTÍNUOCUIDADO: MUDANÇA É UMA TAREFA DIFÍCILUMA CARTILHA PARA A ADOÇÃO DO SCRUMPLAY 0 - VISÃO GERAL, AVALIAÇÃO E PREPARAÇÃO DE PILOTOPLAY 1 - PROJETO(S) PILOTO(S)PLAY 2 – EXPANSÃO ORGANIZACIONALPLAY 3 – CAUSANDO IMPACTOPLAY 4 - MEÇA, AVALIE E AJUSTEPLAY 5 – EXPANDA E CONQUISTEIMPEDIMENTOS ORGANIZACIONAIS PARA A ADOÇÃO DO SCRUMEXPONDO OS IMPEDIMENTOS COM O SCRUMDIMENSIONANDO O SCRUMDIMENSIONANDO A ORGANIZAÇÃO: EQUIPES DE EQUIPES DE SCRUMA ORGANIZAÇÃO SEGUE A ARQUITETURACOORDENANDO EQUIPES DE EQUIPESCOMUNICAÇÃO DIÁRIA: SCRUM OF SCRUMSPLANEJAMENTO E MONITORAMENTO DO RELEASE NO NÍVEL DO SISTEMAINFRAESTRUTURA DE FERRAMENTAL PARA AGILIDADE CORPORATIVASUMÁRIO & BIBLIOGRAFIA34589910111213141516171819192122222323232426www.rallydev.com©2013 Rally Software Development2

IntroduçãoAs pressões de uma economia verdadeiramente global fazem com que a empresa dehoje passe a contar cada vez mais com sua habilidade para produzir softwares como suaprincipal vantagem competitiva. Sejam softwares para gerenciar processos de manufaturaou de entrega a clientes, ou softwares que melhorem a eficiência das atividades diárias, elesatingem virtualmente qualquer faceta dos negócios atuais.E ainda, para muitas organizações, as práticas de desenvolvimento de softwarepermanecem como eram nos anos oitenta. A dependência em métodos do tipo cascata(waterfall), prescritivos e baseados em planos é comum, apesar de inúmeras evidênciasde que estas práticas geralmente não conseguem realizar entregas de valor real em tempohábil e, portanto, dificultam a capacidade de resposta da nossa empresa às necessidadesde mudanças rápidas dos clientes e das condições do mercado. E isso não está setornando mais fácil.As organizações de TI de hoje tambémprecisam coordenar de forma eficaz asequipes de desenvolvimento de softwaredistribuídas pelo mundo inteiro refatorandoaplicações legadas em arquiteturas maisflexíveis e orientadas a serviços. É evidenteque precisamos de uma nova abordagempara gerenciar e desenvolver software parapermanecermos competitivos.Gerenciar organizaçõesdistribuídas e migrar de formaeficaz para arquiteturas orientadasa serviços exige uma novaabordagem de desenvolvimento desoftwarePara resolver estes desafios, estão sendo adotadas várias técnicas de desenvolvimentode software mais ágeis e adaptáveis que permitem às organizações fornecer software demaior qualidade mais rapidamente. O Scrum é um desses métodos consagrados que temtido sua adoção difundida em muitas organizações de software. Este documento técnicodescreve como um CIO ou outro gerente executivo podem implementar o Scrum em todaa organização, inclusive podendo escalá-lo para aplicações maiores e equipes de equipes- os desafios que ele ou ela irão enfrentar, bem como as recompensas - e fornece umacartilha para a adoção do Scrum em empresas onde os softwares e muitos deles, sãoprimordiais para o sucesso competitivo no mercado.Isto é uma cartilha de ideias sobre como implementar o Scrum dentro de uma empresa. Eleé denominado uma cartilha e não um manual porque cada organização tem característicasúnicas. A implementação do Scrum dentro de uma determinada empresa pode sersignificativamente diferente de sua implementação em outra. Os tipos de impedimentos, aswww.rallydev.com©2013 Rally Software Development3

coisas que precisam mudar, a dificuldade da mudança e as pessoas que farão as mudançassão diferentes, assim como os cronogramas, as prioridades e o esforço.Visão Geral do Scrum e da Agilidade dos SoftwaresÀ priori, o Scrum é um processo muito simples: uma técnica de administração de softwaresque tem um conjunto relativamente pequeno de práticas e regras inter-relacionadas, não édemasiadamente prescritivo, pode ser aprendida rapidamente e é capaz de produzir ganhosde produtividade quase imediatamente.O Scrum foca naturalmente uma organização inteira na criação de produtos de sucesso. Elefornece funcionalidades úteis a intervalos regulares à medida que os requisitos, a arquiteturae o design vão emergindo, mesmo quando se utilizam tecnologias instáveis. Você podeimplementar o Scrum no começo ou no meio de um projeto e o Scrum poupará muitosesforços de desenvolvimento que estavam em dificuldades.O Scrum funciona porque otimiza o ambiente de desenvolvimento, reduz o overheadorganizacional e sincroniza rigorosamente os requisitos do mercado com a rápida entregade funcionalidades. Fundamentado em uma moderna teoria de controle de processos, oScrum produz o melhor software possível de acordo com os recursos disponíveis, os níveisde qualidade aceitáveis e as datas de release exigidas.Em seu núcleo, o Scrum é um processo iterativo e incremental para desenvolvimento dequalquer produto ou gestão de qualquer trabalho que produza um conjunto potencialmentetransportável de funcionalidades ao término de cada de iteração. Seus atributos são:• Um processo ágil para gerenciar e controlar trabalho de desenvolvimento.• Um envoltório para práticas de engenharia já existentes.• Uma abordagem baseada em equipes para desenvolvimento de sistemas quando osrequisitos estão mudando rapidamente.• Controla o caos gerado por interesses e necessidades conflitantes.• Aprimora a comunicação e maximiza a cooperação.• Detecta e elimina qualquer coisa que se interponha no caminho do desenvolvimento eentrega de produtos.• Um modo de se maximizar a produtividade.• Pode ser escalado desde projetos únicos até organizações inteiras e tem sido aplicadopara gerenciar o desenvolvimento de diversos produtos e projetos inter-relacionadosenvolvendo mais de mil membros de equipe.www.rallydev.com©2013 Rally Software Development4

• Uma forma de fazer todo mundo se sentir bem com seu trabalho, suas contribuições esaber que fizeram o melhor que podiam ter feito.Embora a descrição das práticas do Scrum em detalhes esteja fora do escopo destedocumento técnico (veja Schwaber 2004 e Schwaber 2002), o método é caracterizado pelaprodução de um Backlog do Produto no qual as funcionalidades exigidas são organizadaspela sua prioridade (Figura 1). Um Product Owner é responsável por aprovar mudançasno backlog do produto. A implementação ocorre, grosso modo, em iterações de 30 dias,denominadas Sprint, que são focadas nas prioridades mais altas do Backlog do Produto. Ameta de cada Sprint é entregar um incremento de produto potencialmente chipável. Duranteo Sprint, os checkpoints são observados em uma reunião de “Scrum” diária que informao andamento e as atividades dentro da equipe e compartilha problemas que podem estar“bloqueando” o progresso de um indivíduo ou de uma equipe. Isto permite ao ScrumMasterdeterminar o andamento em relação aos compromissos do Sprint e assessorar comcorreções de percurso para assegurar a conclusão bem sucedida do Sprint.Princípios do ScrumEmbora esses sejam algumas das mecânicas do Scrum, o mais importante é o CIO entenderque o Scrum é guiado por alguns princípios primordiais:• A convicção de que o desenvolvimento eficiente de software é mais bem implementadoatravés de um processo empírico do que de um processo planejado;• A convicção de que, uma vez eliminados os impedimentos organizacionais, uma equipeauto-organizada e autogerida iránaturalmente produzir um softwaremelhor do que o faria em situaçãocontrária;• A premissa de que você podeproduzir o software mais valiosodentro de um determinadoprazo e orçamento, mas nãopode definitivamente prever afuncionalidade exata do que umaequipe irá entregar.Figura 1: Um Modelo de processo empiricoque caracteriza o ScrumA assertiva do Scrum é que o reconhecimento destes princípios chave livra uma organizaçãode muitas das restrições que impedem o desenvolvimento eficiente de softwares. Noentanto, os CIOs também precisam reconhecer que estes princípios fundamentais implicamem mudanças potencialmente significativas na organização que opta por adotá-los. Dadoque estes princípios formam a base subjacente do Scrum, cada um merece uma discussãoadicional.www.rallydev.com©2013 Rally Software Development5

Adoção de um Processo Empírico x Processo PlanejadoO Scrum acredita que a maioria dos sistemas de desenvolvimento de hoje tem uma basefilosófica incorreta, ou seja, através de mais e melhor planejamento podemos alcançarresultados mais previsíveis, de maior qualidade. O Scrum reconhece que o processode desenvolvimento de aplicações é imprevisível e extraordinariamente complicado(imagine centenas de milhares de linhas de código criadas manualmente) cujo valor sópode ser mensurado empiricamente. Afinal de contas, a aplicação em desenvolvimentoprovavelmente nunca foi desenvolvida por qualquer equipe em qualquer lugar, muito menospor sua equipe em seu contexto, portanto, as abordagens de planejamento do tipo livrode receitas, passo a passo, não conseguem resolver a imprevisibilidade inerente de formaeficaz.O Scrum define o processo de desenvolvimento de sistemas como um conjunto livre deatividades que combina ferramentas e técnicas conhecidas e executáveis com uma equipecapacitada que está firmemente atrelada ao Cliente/Product Owner. Dado que muitasdestas atividades estão soltas, são aplicados controles - como inspeção e demonstraçãoconstantes - para gerenciar o risco e fornecer evidência empírica do estado do projeto emtempo real, a todo o momento.A opção pelo Scrum é simples:Saiba onde você está todo dia com o Scrum- ou -Pense que você sabe onde está em seu plano bem formado e descubra que você estámuito errado, muito depoisElimine os Impedimentos de Forma que a Equipe PossaFazer Seu TrabalhoAo longo dos anos, os processos organizacionais de uma empresa e suas práticas dedesenvolvimento de software normalmente ganham peso, tornando muitas vezes a criaçãode software um grande esforço. Quando o Scrum é implementado, estes “impedimentosorganizacionais” para a distribuição eficiente de software tornam-se bastante óbvios, poisatrapalham a habilidade da equipe no que diz respeito ao cumprimento da rápida naturezaiterativa e incremental do Scrum. A eliminação ou mudança destes processos e práticaspode mostrar que um projeto de mudanças importantes deve ser iniciado, dirigido emonitorado pelo CIO ou campeão executivo (mais sobre este tópico adiante).Além disso, em Scrum, a equipe é a coisa. Afinal de contas, eles são os que de fatowww.rallydev.com©2013 Rally Software Development6

projetam, desenvolvem e fornecem a aplicação, portanto, ao otimizarmos seu desempenhoeliminando obstáculos, otimizamos o desempenho da empresa para fornecer valor a seususuários. A gerência cumpre seu papel quando elimina impedimentos. A Equipe cumpreseu papel quando honra seus compromissos de acordo com o descrito no Backlog de cadaSprint.Em outras palavras, em Scrum, a equipe é tanto capacitada quanto responsável porfornecer os bens. Ela faz seu trabalho quando auto-organiza, autogera e auto-atinge osobjetivos do Sprint. Para muitas organizações, isto significa virar as coisas de cabeça parabaixo. A abordagem hierárquico-técnico-gerencial-diretiva é essencialmente eliminada peloScrum. O Product Owner agora define os objetivos e prioridades, a equipe pensa comoatendê-los e ninguém precisa ensiná-los como fazer isso durante o processo.Resultados Melhores, Porém Menos Previsíveis x Falsa SegurançaO Scrum começa com a premissa de que a criação de software é um negócio complicadoque opera em um ambiente técnico e altamente fluido e que ninguém pode prever comsegurança ou planejar definitivamente o que exatamente uma equipe irá entregar, quandoirá fazê-lo e qual será a qualidade e o custo. Em vez disso, o Scrum entende que equipespodem estimar estes itens, informar as estimativas, negociar um plano de curto prazo deacordo com vários riscos e então se ajustar conforme vai progredindo. O acordo é que aequipe deverá fornecer o melhor software possível de acordo com as circunstâncias e quea adoção de qualquer abordagem do tipo livro de receitas não irá melhorar a definição de“o melhor” e apenas irá comprometer a rapidez de resposta da equipe à complexidade eimprevisibilidade real existente.Historicamente, a ignorância desta filosofia cria vários problemas organizacionais:• A gerência realmente acredita que pode prever o custo, a programação de entrega e afuncionalidade que será entregue e planeja de acordo com isso.• Os desenvolvedores e gerentes de projeto são forçados a viver uma mentira: eles fingemque podem planejar, prever e entregar. Eles criam de um modo, mas precisam fingir queo fazem de outro modo. No final, eles acabam essencialmente sem controles.• No momento em que o sistema é entregue, frequentemente se torna irrelevante ourequer mudanças significativas. Uma das causas fundamentais é que os custos elevadosda iteração limitam nossa visibilidade da utilidade do que a equipe está realmentedesenvolvendo, até quando já é tarde demais.O reconhecimento destas realidades não é nada fácil - por exemplo, que gerente desejafalar para o seu executivo que não sabe exatamente o que a equipe irá entregar em umadata determinada? Mas os benefícios dessa abordagem são que as organizações se tornamrealmente autônomas: a empresa finalmente se torna livre para produzir melhores resultadoswww.rallydev.com©2013 Rally Software Development7

para seus usuários finais e agora poderá fazê-lo mais rapidamente, criando uma claravantagem competitiva para os negócios.O Scrum e a Agilidade dos SoftwaresO Scrum tem sido usado desde meados dos anos noventa e atualmente está sendoaplicado mundialmente em milhares de projetos. Além do Scrum, várias novas metodologiasiterativas têm recebido também atenção durante este período. Como ocorre com o Scrum,cada uma delas resulta de uma combinação de ideias antigas com novas ideias, mas todaselas enfatizam:• A colaboração estreita entre a equipe de desenvolvimento e os especialistas emnegócios;• A comunicação face a face (como mais eficiente que a documentação por escrito);• A entrega frequente de novos softwares com valor de negócio aplicável;• Equipes coesas e auto-organizadas;• Maneiras de criar o código e a equipe para permitir a adaptação contínua aos requisitosvariáveis.Em 2001, vários idealizadores e praticantes destas metodologias, inclusive líderes doScrum, conseguiram entender o que eles tinham em comum. Eles escolheram a palavra“ágil” como o termo abrangente e elaboraram o “Manifesto para o Desenvolvimento Ágil deSoftwares” (Apêndice B), seu aspecto mais importante sendo uma especificação de valorescompartilhados:Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o e ajudando osoutros a fazê-lo. Através deste trabalho, aprendemos a valorizar:• Indivíduos e interações mais que processos e ferramentas• Softwares em funcionamento mais que documentação abrangente• Colaboração com o cliente mais que negociação de contratos• Responder a mudanças mais que seguir um planoOu seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.O Manifesto causou impacto e desencadeou milhares de novos projetos ágeis. Osresultados e as experiências destes projetos aprimoraram as técnicas aplicadas pelasdiferentes formas das práticas ágeis. Como ocorre com qualquer intento humano, algumastiveram sucesso, outras não. Mas o que mais teve impacto sobre os sucessos foi a ligaçãoque os homens de negócio e as pessoas técnicas tinham com o seu projeto. Esta erawww.rallydev.com©2013 Rally Software Development8

a maneira que eles desejavam que os softwares fossem desenvolvidos - e os clientes eusuários finais concordaram. Projetos bem sucedidos geraram mais entusiastas e tal comoum Sprint bem sucedido, o ciclo ágil virtuoso continua até hoje.Preparando-se para o ScrumApós os CIOs terem adquirido um entendimento básico dos benefícios comerciais eculturais do Scrum e da agilidade, eles geralmente desejam dar o próximo passo e ver comoeste método de desenvolvimento pode incrementar sua organização.Durante seus primeiros quinze anos de vida, a maioria das implementações de Scrumforam conduzidas no esquema bottom-up. Em outras palavras, uma equipe deprojetos experimentava o Scrum e os resultados eram impressionantes. Outra equipe oexperimentava e rapidamente os projetos de Scrum apareciam na organização inteira. Maisrecentemente, no entanto, muitas organizações desejam implementar o Scrum no esquematop-down como parte de uma diretiva para aumentar a rapidez de resposta da empresa eaumentar a produtividade.Visto que o Scrum representa autonomia para a equipe e “deixar a equipe decidir”, umaimplementação top-down exige consideração e preparação ponderadas, como iremosdescrever nesta seção.“Scrumming” tanto no Processo de Software quanto na OrganizaçãoMuitas organizações têm tolerado ineficiências e impedimentos por anos; o Scrum osidentifica rapidamente e exige sua resolução. Felizmente, o aumento de produtividade e devalor derivado de projetos de Scrum faz o esforço valer a pena, mas ainda é um esforço.Para implementar o Scrum, uma organização precisa assumir duas obras: a primeira envolveos projetos nos quais as equipes de desenvolvimento são orientadas a criar softwareusando o Scrum; e a segunda, eliminar os impedimentos à criação e entrega otimizada dosoftware que as equipes do Scrum encontrarem. O primeiro trabalho aprimora a distribuiçãode software e o segundo, resolve os impedimentos ao ROI e à produtividade identificadosno primeiro.Ambas as obras são desafiadoras e exigem trabalho duro acima e além do desenvolvimentoefetivo do software; uma implementação completa do Scrum pode demorar até dois anos.Não importa qual seja a intensidade ou o comprometimento da gerência, este cronogramanão pode ser reduzido porque o núcleo do projeto é mudança organizacional.Os ciclos diários e mensais de inspeção e adaptação do Scrum tornam tudo visível -o código, o processo e os impedimentos da empresa. Os projetos que usam Scrumwww.rallydev.com©2013 Rally Software Development9

egularmente identificam impedimentos que devem ser registrados, avaliados, priorizados eresolvidos.A velocidade de implementação do Scrum está diretamente relacionada com:• O grau de mudança exigido dentro da organização;• A urgência dentro da organização de melhorar seu processo de desenvolvimento eentrega de softwares;• A eficácia da liderança dentro da organização.O Papel do CIO como ScrumMaster Organizacionalpara o Aprimoramento ContínuoEm Scrum, o ScrumMaster é responsável por cerificar-se de que uma equipe Scrum adoteplenamente os valores e as práticas de Scrum. O ScrumMaster protege a equipe garantindoque esta não irá se comprometer acima do limite do que é capaz de realizar durante umSprint e cabe a ele eliminar continuamente os obstáculos que possam impedir a equipe deentregar os resultados do Sprint com sucesso.No nível de impedimento organizacional, estatarefa cabe ao CIO ou a outro patrocinadorexecutivo cuja função seja trabalhar fora daequipe e eliminar as barreiras organizacionaisque possam impedir o sucesso de um modelo dedesenvolvimento ágil.O CIO é o ScrumMaster paraMudanças OrganizacionaisA função do ScrumMaster Organizacional é perceber, identificar e trabalhar dentro daorganização para causar as mudanças que eliminam os impedimentos, ou seja, o CIOcomo ScrumMaster Organizacional é principalmente um agente de mudanças e a lista deimpedimentos é seu Backlog de Produto. O patrocinador do Scrum do CIO - atuando como“Product Owner” em relação a estes impedimentos - define as prioridades destes itens. EsteBacklog de Produto de impedimentos é trabalhado pela organização através das equipesque utilizam o processo Scrum, tendo como deliverables a remoção do impedimento. Estebacklog de mudanças organizacional inicia durante os projetos pilotos e continua enquantoas mudanças necessárias sejam identificadas durante o ciclo de inspeção e adaptação doScrum.O ScrumMaster Organizacional se encontra periodicamente com todos do ScrumMasters,com o Product Owner e o patrocinador para desenvolver ainda mais o Backlog de Produtode Mudança Organizacional. São formadas equipes que conduzem as mudanças naorganização dentro de um Sprint. Na fase de Revisão do Sprint, a mudança é analisadabem como a métrica que pode ser usada para monitorar o andamento da implementaçãowww.rallydev.com©2013 Rally Software Development10

da mudança. Deste modo, o CIO toma conta de um processo contínuo de aprimoramentoorganizacional especificamente voltado para aumentar a produtividade e a qualidade dasequipes de desenvolvimento de software.Cuidado: Mudança é uma Tarefa DifícilMudança é uma tarefa difícil e não há como evitar o trabalho duro. As organizações queimplementam o Scrum às vezes identificam o trabalho duro de forma errada, como falha dealguém, algo que se pode fazer para eliminar se o grupo que falhou simplesmente “corrigirseu feito”. Este tipo de culpa organizacional pode matar uma implementação do Scrum, ecom isto, também a capacidade da organização para criar software melhor. Quando algoé penoso, quando algo dá errado, reconhecer isto é apenas parte da mudança que estáocorrendo; é uma oportunidade para todo mundo se reunir e imaginar como resolver oproblema, em conjunto.O Scrum não pode ser planejado e implementado com listas de verificação, procedimentose formulários. O Scrum é apenas uma estrutura simples que pode identificar tudo em umaorganização que atrapalhe a criação otimizada de software. O trabalho para gerenciar eeliminar estes impedimentos representa a parte difícil de implementar o Scrum e é diferentepara cada organização, dado que cada organização é diferente.Ninguém gosta de problemas e dificuldades; muitos dos impedimentos são tão inerentesao modo de pensar e operar de uma organização que se tornam muito difíceis de eliminar.Nenhum volume de planejamento antecipado irá reduzir esta dificuldade; ele só poderáajudar a alertar todo mundo para o trabalho duro que precisa ser feito para se tornar umconcorrente de categoria mundial. O Scrum exige que a alta administração esteja vitalmenteenvolvida na triagem e remoção dos impedimentos e, portanto, exige que o CIO que estejaadotando o Scrum se torne o principal agente da mudança.Deste modo, o CIO assume um processo de aprimoramento organizacional contínuo,totalmente focado no aumento da produtividade e da qualidade das equipes de software.Não é fácil e a liderança que o CIO oferece será um fator crucial para o sucesso, comoilustra a seguinte nota de Ken Schwaber para um CEO:De: Ken SchwaberPara: XXX XXXXX, CEO da XXXXXXX Corporation“Por um lado, o Scrum oferece algumas possibilidades muitoatraentes - aumento de produtividade, um ambiente de trabalhowww.rallydev.com©2013 Rally Software Development11

melhor, maior competitividade e um produto de maior qualidade.Por outro lado, é difícil de implementar. A quantidade de mudançasgeradas por uma implementação de Scrum é significativa edificultosa.Embora a mudança seja difícil para desenvolvedores e clientes(product owners), eles obtêm retorno imediato através da maiorsatisfação no trabalho. Isto os ajuda em tempos de tensão eansiedade. A administração intermediária, no entanto, sofreestresse sem recompensa imediata. Eles são solicitados a ajudarna transição de uma organização das abordagens tradicionaispara abordagens mais enxutas, sem a visão clara de um pontofinal pessoal… o que vou fazer e aonde vou me encaixar na novaorganização. Esta pergunta é particularmente difícil e carregadade perigo, pois a administração intermediária irá moldar a novaorganização. O potencial para conflitos e políticas é desencorajador.Minha experiência com implementações top-down corporativas doScrum me levaram a acreditar que o diferencial entre o sucesso eo fracasso é você. Sua habilidade para imaginar o futuro e ajudara transmitir isto à sua gerência, sua habilidade para orientá-lapacientemente durante a mudança e para convencer sua gerênciaintermediária do quanto ela é valorosa e transformá-la em umaequipe irá distinguir sua habilidade para absorver a mudança eperceber os benefícios, ou não”.Uma Cartilha para a Adoção do ScrumUma vez que você tenha decidido implementar o Scrum dentro de sua organização,tem início uma jornada com a convicção de que o esforço será recompensado com umprocesso de softwares mais eficaz e uma empresa mais responsiva e competitiva. Tambémse reconhece que uma quantidade significativa de mudanças organizacionais está agoraprevista.À medida que o CIO vai considerando esta incumbência, um entendimento decomportamento organizacional leva a um conjunto de etapas racionais para alcançarmudanças substantivas. Estas etapas incluem:www.rallydev.com©2013 Rally Software Development12

• Encontrar um evangelista e um patrocinador local;• Dar passos iniciais pequenos para sondar o terreno;• Refletir sobre os sucessos e as falhas e avançar passo a passo.A próxima seção descreve alguns exemplos típicos de como você poderia implementar oScrum em toda a sua organização; uma cartilha com exemplos de técnicas que você podeaplicar para realizar a mudança necessária.Play 0 - Visão Geral, Avaliação e Preparação de PilotoO objetivo do primeiro play é preparar o campo de atuação para as atividades futuras: a)avaliar a prontidão das organizações para a agilidade, b) fornecer treinamento inicial paraos primeiros participantes e c) elaborar o Backlog de Produto para os projetos iniciais. Osdetalhes deste play são os seguintes:Visão Geral e AvaliaçãoDescrição: Sessão funcional de dois dias que consiste de• Teste de Aptidão do Scrum - expõe a gerência aos tipos de mudança que acontecemcom o Scrum e a ajuda a determinar se deseja prosseguir.• Apresentações do Scrum - despertar conscientização geral e apresentar conceitos para aorganização inteira.• Avaliar a prontidão organizacional e definir os próximos passos.• Definir planos; identificar potenciais pilotos, programar treinamentos e providenciarrecursos para o projeto piloto.• Jantar com a alta gerência para examinar os próximos passos.Duração: 2 diasSuporte: ExternoPreparação do PilotoA organização está pronta para prosseguir com o treinamento e a estrutura necessária parasuportar o primeiro projeto piloto. As atividades nesta fase incluem:Treinamento do ScrumMasterDescrição: Treinar os ScrumMasters para rodar os pilotosDuração: 2 diasSuporte: ExternoTreinamento do Product OwnerDescrição: Treinar os Product Owners para maximizar o ROI usando o Scrum.www.rallydev.com©2013 Rally Software Development13

Duração: 1 diaSuporte: ExternoEstabelecer MétricasDescrição: Analisar e modificar métricas que monitoram o uso do Scrum dentro daorganização e definir o valor resultante dos pilotos. Estabelecer processos primordiais doScrum e as métricas do projeto.Duração: 1 semanaSuporte: ExternoEstabelecer Backlog de Produto para MudançasDescrição: Estabelecer backlog de produto para rastrear e avaliar impedimentos quesurgem durante os projetos pilotos. Isto será a base para a iniciativa de mudança dentro daorganização.Duração: 1 diaSuporte: ExternoPlay 1 - Projeto(s) Piloto(s)O objetivo deste play é experimentar o Scrum em um ou mais projetos reais parademonstrar os benefícios positivos da maior agilidade dos softwares dentro da organização.Um ou mais projetos pilotos são executados nesta fase. Os ScrumMasters e a gerênciaacompanham os pilotos com muita atenção para identificar obstáculos e impedimentosorganizacionais ao Scrum. Quando estes impedimentos são identificados, eles sãocorrigidos no local sempre que possível ou são simplesmente registrados no Backlog deMudanças Organizacionais e categorizados para tratamento posterior.Projetos PilotosDuração: 3-6 mesesSuporte: ScrumMaster Externo / InternoDescrição: Rode de 3 a 6 iterações dos projetos pilotos. Projetos pilotos entregamincrementos de funcionalidade e identificam impedimentos ao desenvolvimento otimizadode softwares. Avalie e ajuste o plano, avalie e priorize impedimentos.RetrospectivaDuração: 2 diasSuporte: ScrumMaster Externo / InternoDescrição: Análise os projetos pilotos, as métricas e os impedimentos. Avalie o que deucerto e o que poderia ser melhorado e identifique o ROI. Avalie o impacto nas operações denegócio, inclusive nos relacionamentos dentro dos departamentos organizacionais e com osclientes.www.rallydev.com©2013 Rally Software Development14

ReplanejamentoDuração: 1 diaSuporte: ScrumMaster Externo / InternoDescrição: Modifique o plano piloto para a implementação do Scrum; mantenha o alto nívele deixe os planos de projetos e o plano de mudanças organizacionais serem conduzidos porseus próprios backlogs de produto específicos.Play 2 – Expansão OrganizacionalBaseado em pilotos bem sucedidos, o objetivo deste play é ampliar a utilização do Scrume de seus benefícios a um subconjunto significativo da organização de desenvolvimento.Até agora, existe um entendimento de quais práticas benéficas estão integradas, queimpedimentos estavam no caminho de uma adoção mais ampla e onde havia maisnecessidade de treinamento. Por exemplo, os programas de treinamento mais amplosseguintes agora podem ser eficazes:• Treinamento do ScrumMaster: Antes de escalar a implementação a projetos adicionaise maiores, você precisa aumentar o número de Scrum Masters. Os candidatoscom habilidades apropriadas devem agora ser reconhecidos na organização. OsScrumMasters que irão chefiar o Scrum of Scrums (veja abaixo) agora podem sertreinados em habilidades avançadas, como Facilitação de Equipes e Coleta de Medições.• Treinamento no Desenvolvimento de Produtos: Nós otimizamos a transferênciaentre os analistas e equipes de desenvolvimento quando estas duas funções usaremuma abordagem comum. Uma abordagem muito comum é a adoção de métodos dedesenvolvimento de produto no estilo Lean ou Toyota. As referências listam vários livrosque fornecem informações sobre estes tópicos.• Treinamento para Desenvolvedores: As equipes de desenvolvimento envolvidas emprojetos ágeis terão aprendido quando irão precisar de habilidades para operar de umamaneira mais ágil. O treinamento nas habilidades Extreme Programming (XP), comoDesenvolvimento dirigido a Teste(TDD), etc. pode agora ser garantido. (Beck 2004)• Treinamento em Scrum/Agilidade: Uma implementação bem sucedida do Scrumdependerá em grande parte de um vocabulário comum a todas as pessoas envolvidas.Isto pode ser conseguido através de cursos de introdução de 2 a 4 horas para 30 a 50%da organização.Além disso, você pode aplicar outras atividades para aumentar a visibilidade e o nível deaceitação do Scrum na organização:• Radiadores de informação: Informe o estado dos projetos de Scrum através deradiadores de informação simples e de grande eficácia, como whiteboards exibindoas tarefas (Task Board), Backlogs de Produto e de Release e os gráficos BurnDown deprojetos e programas.www.rallydev.com©2013 Rally Software Development15

• Leituras: Uma sugestão de artigos e livros pode ser oferecida para todas as pessoas daorganização para incentivar a maior difusão do conhecimento.• Seminários/brownbags ministrados pelo CIO: O(s) líder(es) da mudanças deve(m)informar com frequência e de forma franca sobre o que está acontecendo naorganização. Reuniões informais, como brownbags e pizza hours tendem a ter umimpacto positivo sobre as mudanças.• Conversas/experiências difíceis/feedbacks sobre piloto(s): Os resultados dosprojetos pilotos devem ser disponibilizados a todos. Isto aumentará as discussões e oenvolvimento em todos os níveis da organização.Play 3 – Causando ImpactoComo os projetos pilotos provaram que o valor real será entregue através de umaabordagem ágil da gestão de projetos de software, o objetivo deste play é causar umimpacto mais significativo no resultado que só poderá ser demonstrado através de mais emaiores projetos. Através dos plays anteriores, a organização terá coletado conhecimentoexplícito e tácito suficiente para ser capaz de enfrentá-los com uma alta probabilidadede sucesso. Neste ponto, pelo menos 25% da organização deverá estar envolvida naimplementação do Scrum.Uma mudança efetiva já deverá estar ocorrendo dentro e fora da organização dedesenvolvimento. Dentro do desenvolvimento, o trabalho é feito melhor pela equipede desenvolvimento. Fora das equipes de desenvolvimento, o trabalho de eliminarimpedimentos é conduzido pelo ScrumMaster Organizacional e implementado pelosdepartamentos afetados.Projetos de DesenvolvimentoDuração: Para sempreSuporte: InternoDescrição: Projetos de desenvolvimento monitorados pelo ROI.Projetos de MudançaDuração: A maior parte do trabalho nos primeiros 1 a 2 anos; então, conforme necessárioSuporte: InternoDescrição: Projetos de mudança organizacional dentro de vários departamentos eliminamimpedimentos emergentes e variáveis.Avalie e AdapteDuração: A Cada SprintSuporte: ScrumMaster Externo / InternoDescrição: Análise as métricas qualitativas e quantitativas. Adicione outras métricas ewww.rallydev.com©2013 Rally Software Development16

analise os processos de captura sempre que tiver ocorrido uma surpresa.Play 4 - Meça, Avalie e AjusteO objetivo deste play é avaliar o andamento da organização e estabelecer um conjuntomais amplo de métricas para servir como base para uma maior expansão. O CIO deveráestar ciente de que a discussão iminente sobre as métricas poderá ser tanto controversaquanto distrativa, visto que muitas das métricas tradicionais que poderiam estar em vigorantes da adoção do Scrum (exemplo: medidas de “integridade de documento”) não sãomais relevantes. Felizmente, o Scrum e as práticas ágeis são realmente interpretáveis emensuráveis e os praticantes estão convergindo um conjunto de métricas que fornecemfeedback qualitativo e quantitativo tanto no nível de processos quanto de projetos.Mas, antes de entrar nesta discussão, é preciso fazer uma distinção importante entre osdiversos processos tradicionais de desenvolvimento de software e o Scrum e o ágil:A métrica primordial para o desenvolvimento de software ágil é saber se o software funcionalde fato existe e se é demonstravelmente apropriado para uso em seu propósito planejado.Em Scrum, este indicador chave é determinado empiricamente, através de demonstração,no final de cada Sprint individual.Esta medição primária da qualidade e produtividade do software é a essência dodesenvolvimento ágil. Portanto, com o Scrum, você não poderá se desviar muito do seuobjetivo sem perceber. Todos as outras métricas são subordinadas àquele objetivo e ao seueterno mantra de “fornecer software funcional com maior frequência”.Neste ponto do play de adoção do Scrum, uma parte significativa da organização já estáoperando de maneira ágil. Os resultados de Sprint dos projetos iniciais são a medidaprimária da eficácia dos novos comportamentos da equipe e de seus novos processos.Estes dados devem ser publicados e analisados.Além disso, agora é o momento apropriado para definir um conjunto de métricassecundárias usadas para guiar sua organização na forma como implementar o Scrum. Dessaforma, há dois tipos de métricas que podem ser aplicadas:Métricas de Processos – indicadores principalmente qualitativos da eficácia das equipes eda organização na adoção do Scrum. Eles incluem itens tais como a eficácia das equipes nagestão do Backlog do Produto, a eficácia dos processos do Scrum, como a reunião diáriado Scrum, reunião de Planejamento do Sprint, etc. Em cooperação com a ScrumAlliance,Hartman e Stallings desenvolveram um template de métricas de processos que pode serutilizado por qualquer organização que esteja implementando o Scrum. Estas métricas sãoapresentadas como a Tabela 1 do Apêndice 2.www.rallydev.com©2013 Rally Software Development17

Métricas do Projeto – No nível do projeto, um conjunto de métricas adicional podeser aplicado para medir os resultados de uma equipe de Scrum particular e o serviço,componente ou sistema sobre os quais é responsável. Elas podem incluir algumas métricastradicionais, como contagem de defeitos, porcentual do código com cobertura de testeunitário, porcentual de código coberto por testes de regressão automatizados, etc., bemcomo métricas específicas do Scrum, como número de histórias de usuário concluídase demonstráveis no final de cada Sprint. Um exemplo de um conjunto destas métricasaparece como Tabela 2 no Apêndice 2.Uma Nota sobre Qualidade e ScrumOs clientes costumam pressionar as organizações de desenvolvimento para que entreguemfuncionalidades mais rapidamente do que é possível. Algumas organizações dão um jeitonisso reduzindo a qualidade do produto, abandonando a refatoração, reduzindo esforçosem testes e outras práticas sólidas de engenharia. Isto não é suportável dentro das práticasdo Scrum, posto que o sistema ou produto é um bem corporativo, continuamente refinadoe medido objetivamente, não um ativo de projeto único. As organizações de engenharia quesucumbem a esta pressão acabam criando sistemas com “design morto”, que não podemser mantidos ou incrementados de forma eficaz. A organização sofre o enorme custo deuma significativa reescrita e re-release do código fonte. Para evitar isto, somente os níveissêniores de uma organização podem tomar uma decisão de ativos para reduzir a qualidade.Play 5 – Expanda e ConquisteCom estas atividades por trás da organização e com um conjunto definido de métricas paraguiar e avaliar o andamento futuro visando a organização inteira, agora é a hora de ampliar ouso do Scrum no ambiente inteiro. As atividades desta fase da implementação são focadasno maior dimensionamento do Scrum dentro da organização.Em incrementos de talvez 25 a 30% do número de funcionários, o Scrum é apresentadoàs demais equipes da organização. As práticas já existentes são refinadas ainda maise compartilhadas entre as equipes para que se obtenha a absorção organizacional daspráticas ágeis. Só agora as regras rígidas com que o Scrum opera podem ser ajustadaspara melhor corresponder às necessidades da organização. Os clientes podem serconvidados a participar da implementação através de treinamentos como product ownersou ScrumMasters. Esta fase continua até todas as equipes estarem envolvidas com o Scrume os mecanismos de inspeção e adaptação do Scrum tomarem conta dos aprimoramentosadicionais de seus processos e práticas.Neste ponto, a organização estará recebendo a produtividade substancial e os benefícioscomerciais e culturais do Scrum.www.rallydev.com©2013 Rally Software Development18

Antes de prosseguirmos para o Dimensionamento do Scrum para ambientes de projetosmaiores, no entanto, precisamos analisar os tipos de impedimentos organizacionais quepodem atrapalhar as práticas eficazes do Scrum.Impedimentos Organizacionais para a Adoção do ScrumAs aplicações desenvolvidas em qualquer organização são planejadas para otimizar acapacidade da empresa de cumprir sua missão nos negócios. Entretanto, com o passardo tempo, as organizações evoluem de formas nem sempre conducentes à produtividadeda equipe de software que desenvolve e mantém essas aplicações. De fato, algumasorganizações evoluíram ao ponto no qual as práticas de software são em grande partedisfuncionais e, apesar dos repetidos esforços para melhorá-las, a estrutura organizacional,as políticas e as restrições impedem uma mudança eficaz. Esta seção descreve a origem e anatureza destes impedimentos para preparar melhor o CIO para o trabalho que virá.Expondo os Impedimentos com o ScrumA própria natureza do Scrum; suas demandas incessantes por software de qualidade quedeve ser entregue mais rápido; sua demanda contínua de trabalhar com usuários finaispara assegurar uma implementação eficaz, seus mecanismos de inspeção e de adaptaçãocontínua expõem as práticas disfuncionais e “problemas impeditivos” muito rapidamente.Este efeito se torna ainda mais pronunciado quando o Scrum também é usado como umprocesso para implementar e dimensionar o Scrum na organização.É impossível identificar todosos esforços organizacionais deantemãoVocê não consegue identificar todos osimpedimentos de antemão por eles estaremintegrados na organização e, portanto, seremmuito familiares para serem identificadosfacilmente. Só quando você começa a usar oScrum é que eles se tornam óbvios. O plano para a implementação emerge quando surge aevidência do que precisa ser mudado e a disposição da organização para fazer a mudança.Caracterizando os ImpedimentosOs impedimentos são geralmente encontrados em quatro áreas:No Próprio Processo Scrum – quais impedimentos estão ocorrendo e atrapalhando oprocesso do Scrum?Práticas Pessoais – que práticas pessoais estão atrapalhando o desenvolvimento, adistribuição, o suporte e a utilização dos produtos para maximizar a satisfação de todos osenvolvidos?Práticas da Engenharia de Produtos – que práticas estão impedindo a otimização deretorno de investimento, ou a maximização da missão da organização sob a perspectiva dowww.rallydev.com©2013 Rally Software Development19

produto e que impedimentos existem contra o desenvolvimento otimizado do produto e suaentrega?Questões Organizacionais – que problemas organizacionais sistêmicos - claramentefora do controle da equipe – estão impedindo as equipes de entregarem software maisrapidamente a seus usuários?Queremos categorias separadas no Backlog de Produto de Impedimento Organizacionalporque elas exigem habilidades exclusivas para sua solução. Além disso, elas devem serpriorizadas para impactar e deve-se pensar um pouco em quem, na organização, tem maiscapacidade para solucionar o impedimento da melhor forma.A Tabela 1 abaixo exibe exemplos de impedimentos encontrados em organizações queadotaram o Scrum. Esta lista poderia funcionar como um ponto de partida e um sistema deaviso antecipado sobre alguns dos impedimentos que sua organização poderia encontrar.Mas, novamente, cada empresa é diferente e toda implementação é única, portanto,felizmente ou infelizmente, o processo Scrum irá seguramente descobrir alguns novosimpedimentos para o CIO tratar!Processo ScrumAs pessoas chegam tarde ao Scrum diário e não suportam disciplina básicaAs reuniões do Scrum são muito demoradas - a equipe fica entediada econsidera o tempo improdutivoScrumMaster dita as decisões de design ou administra meticulosamenteAs equipes são muito grandes para Scrum diário eficaz e planejamento doSprintAs equipes não relatam tempo restante das tarefas para análise de BurnDownImpacto Custo OwnerPráticas PessoaisIndivíduos interrompidos e encarregados de trabalhar fora do SprintEquipes isoladas em cubículo e não em área do Scrum abertaMembros da equipe não responsáveis por compromissos pessoais do SprintIndivíduos divididos entre muitos projetos e equipesPráticas da Engenharia de ProdutosOs recursos interfuncionais para definição, design, implementação e testesnão estão presentes na equipeOs Sprints não implementam nem testam completamente incrementospotencialmente aplicáveis de funcionalidades valiosas para o clienteO Product Owner não está sempre disponível/não está íntegro na equipeA integração de sistemas não é forçada a cada SprintO Product Owner não divide itens volumosos do backlog de produto paraajustá-los dentro de um Sprint.www.rallydev.com©2013 Rally Software Development20

As equipes têm recursos ineficazes para automatizar criações e integraçõesAs funcionalidades são carregadas no Sprint depois que o Sprint começaImpacto Custo OwnerQuestões OrganizacionaisPolíticas de processos de software ineficazes para regular processosA gerência pressupõe preço fixo, tempo fixo, postura fixa de entrega defuncionalidadesTestes de Softwares ou CQ de Sistemas é uma organização separada e nãointegrada com a equipeA organização recompensa indivíduos em vez do comportamento da equipeAs regras já existentes ou a capitalização de softwares demandam aderênciaa abordagens tipo cascata, orientadas por documentosAs equipes não são colocadas no mesmo espaço quanto possívelAs equipes não conseguem tomar pequenas decisões organizacionais deespaço e de despesas necessárias para executarem seu trabalhoLegenda:Impacto deste impedimento para o projeto (de 0 a 9 sendo 0 = baixo, 9 = alto),Custo para resolver este impedimento (de 0 a 9 sendo 0 = baixo, 9 = alto)Owner: Ponto em uma organização para resolução:C – CEO/CTO/COO/CFO,V – VP,D – Diretor,P – Gerência de Produto,E – Gerência de Engenharia,T – EquipeDimensionando o ScrumOs benefícios empresariais do Scrum e da agilidade são mais prontamente obtidoscom equipes pequenas, situadas no mesmo local e integradas, consistindo idealmenteem oito pessoas ou menos (inclusive Product Owner, ScrumMaster, Desenvolvedores eTestadores) sendo que cada equipe do Scrum é owner de um produto específico ou de umadeterminada aplicação que ela possa definir, desenvolver, testar e entregar sem muita ajudaexterna.É inevitável, porém, que o sucesso do Scrum resulte na sua aplicação em programasmaiores, sistemas de sistemas e aplicações que demandam muitas (provavelmentedistribuídas), equipes para desenvolvê-las e entregá-las. Felizmente, o Scrum tem mostradosua eficácia em projetos envolvendo centenas de desenvolvedores, portanto, podendo serproporcionalmente dimensionado para atender as maiores empresas de software. Estescasos, porém, envolvem um conjunto exclusivo de obstáculos que precisam ser resolvidos,especificamente:1. Dimensionamento da organização: Equipes de Equipes de Scrumwww.rallydev.com©2013 Rally Software Development21

2. Infraestrutura de ferramental para promover agilidade corporativa3. Coordenação de equipes de equipesCada um destes desafios é abordado nas seções abaixo.Dimensionando a Organização: Equipes de Equipes de ScrumConsistente com sua filosofia de que “menos é mais”, o Scrum tem um número muitopequeno de normas. Entretanto, a maioria das normas que existem são fixas e relativamenteinvioláveis. Uma norma básica é a equipe consistir em oito ou menos membros quetrabalham em uma mesma área física. Este é o modelo mais eficaz e produtivo, visto quea) suporta o requisito da comunicação informal e constante entre os membros da equipe,b) promove um alto grau de corporativismo e c) permite um compromisso comum com asmetas do Sprint entre os membros da equipe que de fato conhecem um ao outro e têm detrabalhar juntos diariamente. Além disso, certos mecanismos do Scrum, como planejamentode Sprint e a reunião Diária do Scrum podem deteriorar muito rapidamente se o tamanho daequipe aumentar além de 8 a 10 indivíduos.O dimensionamento do Scrum para aplicações maiores mantém este princípio chave emvigor. Portanto, o dimensionamento para uma aplicação envolvendo 300 pessoas requera organização de cerca de 30 equipes de Scrum. Conforme discutido anteriormente, aformação da equipe deve ser totalmente equilibrada e capaz de desenvolver segmentospotencialmente aplicáveis de funcionalidade a cada Sprint. Para a maioria das organizações,isto exige reorganizar equipes em torno de funcionalidades de produtos, serviços,componentes ou subsistemas, em vez de fazê-lo por função individual (por exemplo, pool dedesenvolvedores, recursos de testes, etc.). Embora já tenhamos discutido este impedimentoorganizacional anteriormente, vemos que ele se torna mais complexo à medida que nossoprojeto aumenta de tamanho.A Organização Segue aArquiteturaAlém disso, não podemos formar equipesde Scrum prontamente sem entendercomo cada equipe individual pode, deforma relativamente holística, entregarfuncionalidades para usuários finais. Poroutro lado, isto nos obriga a decompor aarquitetura das aplicações em componentesou subsistemas que possuam integridadeconceitual e possam fornecer valor denegócio por sua própria conta. O ScrumFigura 2: Um Sistema Sendo Criado por três Equipesde Scrum em três Sprintswww.rallydev.com©2013 Rally Software Development22

permite esta atividade de fatoração arquitetônica na fase de organização do Sprint e nosSprints iniciais, pelas equipes avançadas de Scrum. Este método funciona particularmentebem num período de expansão do Scrum e sua implementação em um projeto grande.Aqui, as equipes de frente criam pontos de provas de valor para o cliente enquantofatoram a arquitetura das aplicações simultaneamente para aceitar equipes adicionais cujotreinamento em Scrum irá provavelmente ocorrer ao mesmo tempo. À medida que cadanova equipe é formada, sua função no sistema maior fica mais clara e surge uma situaçãocomo a descrita na Figura 2.Coordenando Equipes de EquipesClaro que, a presença de um número grande de equipes traz desafios significativosem termos de coordenação e comunicação entre equipes e também implica em que,provavelmente, surgirão vários problemas no nível do sistema que exigirão as mesmaspráticas de inspeção diárias e mensais aplicadas no nível de equipe local. Experiênciasde dimensionamento do Scrum para equipes maiores geraram um pequeno conjunto depráticas úteis para coordenar equipes discrepantes e solucionar os desafios maiores deplanejamento de Sprints, planejamento de releases e monitoramento da integração no níveldo sistema e das atividades de teste.Comunicação Diária: Scrum of ScrumsDa mesma forma que o Scrum obriga uma comunicação diária no Scrum diário, as equipesmaiores e distribuídas normalmente coordenam suas atividades em um Scrum of Scrumsdiário. Nesta reunião, os líderes de equipe de cada equipe componente usam o mesmoformato de reunião diária de uma única equipe:• O que minha equipe fez ontem para adiantar os objetivos do Sprint?• O que minha equipe fará hoje?• Que impedimentos estão presentes e que poderiam impedir minha equipe de cumprir seucompromisso com o Sprint?Idealmente, esta reunião deve ocorrer imediatamente após o Scrum diário da equipeindividual. Quando as equipes estão espalhadas, ela geralmente é feita por telefone, numhorário oportuno para maximizar a participação dos membros da equipe do Scrum ofScrums.Planejamento e Monitoramento do Release no Nível do SistemaA Figura 2 poderia dar a entender que é uma questão bastante simples dividir a organizaçãoem equipes de funcionalidades, serviços ou subsistemas, capacitar estas equipes a fazerseus trabalhos e que um sistema maravilhosamente integrado irá naturalmente acontecer.A experiência tem demonstrado que isto é improvável. Pois mesmo quando as equipeswww.rallydev.com©2013 Rally Software Development23

individuais estão capacitadas tanto parasatisfazer as necessidades do Sprintquanto para coordenar a integração entreequipes/subsistemas, um conjunto maiorde dificuldades aparece. É o desafio decriar um sistema de forma holística, noqual implementamos e testamos nossasintegrações em todos os subsistemas, ossubsistemas trabalham em conjunto parasatisfazer requisitos mais abrangentes docliente e o sistema global cumpre seusrequisitos de qualidade, desempenho econfiabilidade.Para resolver estes desafios, muitas equipestêm acrescentado uma função de liderançatécnica exercida no nível do sistema.Arquitetos, chefes de equipe, gerentes deFigura 3: Sistema de Três Subsistemas comSprints no Nível do Sistemaproduto e profissionais de garantia de qualidade geralmente se juntam em uma equipe deScrum adicional para pensar e agir no nível do sistema. Além disso, eles também podemaplicar o processo de Scrum no nível do sistema para estabelecer objetivos do Sprint e criaritens de backlog de integrações de sistema forçadas, demonstrações no nível do sistema,checkpoints de qualidade, distribuições experimentais e outros milestones para assegurarque o sistema permaneça nos trilhos. Dessa forma, a situação da Figura 3 começa aemergir.Infraestrutura de Ferramental para Agilidade CorporativaMesmo com este nível de estrutura e coordenação, os projetos maiores e as equipesdistribuídas ainda podem carecer de coordenação interna e interequipes, e da visibilidadedos projetos necessária para entregar, com segurança. softwares em iterações rápidase totalmente testadas. Embora o Scrum forneça uma estrutura já consagrada para osaspectos de gestão de projetos de desenvolvimento de software, ele não prescreve práticasespecíficas de engenharia de software nem recomenda ferramental específico para suportaro processo de Scrum. A filosofia do Scrum, nesse sentido, é de “manter a coisa simples edeixar as equipes decidirem”.De fato, no caso de uma equipe ideal de menos de dez pessoas trabalhando no mesmolocal, os artefatos básicos de gestão de projetos utilizados para planejar o Sprint e informaro status de funcionalidades individuais, tarefas e progresso da equipe podem normalmenteser gerenciados usando-se uma planilha desenvolvida e mantida pelo ScrumMaster. Osartefatos de engenharia para requisitos, casos de teste e defeitos podem ser igualmentewww.rallydev.com©2013 Rally Software Development24

simples e escritos em fichas, whiteboards, ou mantidos em um wiki da equipe.Pessoas e ComunicaçãoTodavia, dimensionar práticas de Scrum para equipes distribuídas e equipes de equipesimpõe certos desafios especiais de comunicação. A coordenação interequipes de comoimplementar requisitos compartilhados, monitorar o status de funcionalidades e identificarproblemas impeditivos se torna uma preocupação prioritária. Nestes casos “deve ser criadoe implementado um mecanismo para sincronizar frequentemente seu trabalho. Ademais, épreciso criar um produto mais detalhado e uma arquitetura técnica para que o trabalho possaser perfeitamente dividido entre as equipes”. (Schwaber 2004)O dimensionamento do Scrumtraz desafios especiais deferramentalEmbora as ferramentas de gestão de projetostradicionais possam ter funcionado paramostrar datas idealizadas de iniciar/finalizartarefas e efetuar - talvez inutilmente - análisescríticas de trajetórias de longos projetos dotipo cascata, estas atividades baseadas em planos perdem sua relevância quando setrabalha com iterações nas quais a equipe inteira se concentra em fazer com que as poucasfuncionalidades de prioridade mais alta sejam aceitas. Em vez de ter uma pessoa mantendoum banco de dados de tarefas separado e disassociado dos artefatos diários que a equipeestá efetivamente planejando e implementando (por exemplo, histórias de usuários e testes),os programas maiores precisam de um ambiente de colaboração em tempo real que suportea sinalização natural que ocorre entre os membros da equipe à medida que fazem umafuncionalidade avançar do Backlog do Produto para os processos de desenvolvimento,testes e integração. Para emular uma equipe trabalhando no mesmo local, este ambiente degestão de projetos ágeis precisa deixar todos rapidamente verem e se atualizarem quandouma funcionalidade está em seu ciclo de vida, quanto esforço ainda será necessário antesde sua conclusão e que problemas específicos estão bloqueando seu andamento.Além de precisar de novos modos para planejar e monitorar nossas iterações, os recursosdas ferramentas aplicados para definir, organizar e compartilhar nossos artefatos de sistematambém têm novas exigências. A gestão dos requisitos, de seus testes de aceitação e deseus defeitos exige suporte que seja horizontal para todas as atividades do ciclo de vidadentro de um Sprint, não vertical, com silos profundos de informações sobre artefatosdeficientemente relacionadas com os compromissos que as equipes assumiram. Naverdade, nas iterações rápidas, os relacionamentos entre estes artefatos é que realmentedão mais preocupação às equipes. Afinal de contas, cada Sprint está produzindo muitossegmentos de código testado funcional, portanto, as equipes precisam entender exatamentecomo estes artefatos de engenharia se relacionam uns com os outros e conseguir enxergarseus status a todo o momento.www.rallydev.com©2013 Rally Software Development25

Oportunidades da Infraestrutura de FerramentalAfinal, sendo desenvolvedoras de software, as equipes naturalmente vão querer organizarmelhor seus artefatos e automatizar os aspectos do processo Scrum que se prestam aosuporte de software. Especificamente, as equipes provavelmente vão querer adicionarsuporte de infraestrutura para as atividades e os tipos de artefato do ciclo de vida dossoftwares descritos adiante:• Gestão de Backlogs: Com o aumento da complexidade do sistema, a equipe desejarásuporte melhor para a captura e manutenção das listas de funcionalidades, de requisitosfuncionais e não funcionais, casos de uso e histórias de usuários, bem como dasprioridades, estimativas, status e owners destes itens. Como o Scrum pode ser aplicadoa projetos maiores, estes artefatos podem atingir a casa dos milhares e poder contarcom um meio para organizá-los, suportá-los e enxergá-los através de sistemas ousubsistemas torna-se crucial.• Relatórios de Projetos: O Scrum evita planos de projetos tradicionais, do tipo cascata,mas a natureza tática da gestão diária de projetos do Scrum é intensa e constante.A equipe precisará de um modo simples de permitir a cada membro informar suasestimativas de tarefas, seu status e o esforço restante de forma que os Gráficos deBurnDown sejam automatizados e permaneçam continuamente disponíveis. Além disso,a infraestrutura deverá suportar a sinalização natural que as equipes utilizam à medidaque os itens de backlog vão passando pelo seu ciclo de vida. Os funcionários graduadosvão ter de observar as equipes e entender suas iterações e planos de release individuaispara poderem avaliar o status de seus programas como um todo.• Elaboração de Requisitos Just-in-Time: Muitos projetos menores de Scrum obtêmsucesso com mecanismos informais de requisitos, como discussão direta entre oProduct Owner e a Equipe, mas, à medida que aumenta a complexidade dos projetos eo grau de criticidade cresce, pode haver necessidade de maior profundidade e riquezade expressão de requisitos e do controle de suas versões. Por exemplo, a documentaçãodas interfaces que afetam diversas equipes torna-se crucial. Mudanças nas interfacesou novas funcionalidades que extrapolam os limites da equipe podem ter um impactosignificativo no projeto. Estes requisitos devem ser elaborados no esquema just-in-time,ou seja, durante ou pouco antes do Sprint que implementará a nova funcionalidade. Pararesolver este problema, as equipes poderão desejar um suporte centralizado para formasmais elaboradas de expressão de requisitos, sua compilação para análise e notificaçãoautomatizada de mudanças.• Teste Preliminar: Dado que todo Sprint entrega potencialmente código utilizável nabaseline do produto, o desenvolvimento de casos de testes e a automação de testespreliminares permitem às equipes suportar os requisitos de iterações rápidas do Scrum.O ferramental que gera casos de teste diretamente a partir de requisitos ou story cardsvai acelerar o processo de desenvolvimento e proporcionar a rastreabilidade inerentewww.rallydev.com©2013 Rally Software Development26

necessária para demonstrar a aceitação da funcionalidade. Saiba que a gestão contínuadas centenas e milhares de testes de regressão resultantes irá, provavelmente, se tornaro fator crucial para determinar a velocidade e o sucesso de seus Sprints.• Planejamento do Release: A filosofia do Scrum foca na “arte do possível no prazo maiscurto”, em oposição à magia negra de supostamente prever exatamente o que seráentregue nas 6 a 12 Sprints mais adiante. Esta filosofia representa um grande progressoem termos de colaboração, pois permite às equipes do Scrum se concentraremprofundamente por 30 dias em cada ciclo e, deste modo, produzir software funcionalcom mais segurança. Porém, conforme as equipes vão crescendo e se expandindo, aaplicação de mais análise e rigor aos Sprints além do horizonte imediato ajuda a evitar asarquiteturas que exigem refatorações significativas mais adiante. Embora a refatoraçãoseja altamente incentivada na metodologia ágil, ela se torna menos prática à medidaque o escopo da aplicação e o número de implementações já existentes aumentam.Um melhor planejamento do release que nos proporcione uma pista de decolagemarquitetônica geralmente é apropriado. Portanto, a arte de planejar o Sprint pode incluirfunções de planejamento do tipo “retirar alguns Sprints “ e “e se” que ajudem as equipesa fazer intercâmbios de backlogs e transmitir uma visão e um roadmap de produtorazoáveis aos patrocinadores.Além disso, estas equipes normalmente vão querer organizar todos estes ativos em umrepositório central onde qualquer membro da equipe poderá acessá-los, no esquema 24x7,em âmbito mundial e que permita visualizar instantaneamente o status dos projetos eprogramas, com notificação de mudanças automatizada no caso de alterações cruciais nosprojetos.Evoluindo a Infraestrutura em SprintsEm Scrum, a implementação deste nível de infraestrutura não é um evento raro ou único,feito “de antemão” por uma equipe de ferramental. Ao contrário, as equipes de Scrumassumem a tarefa de identificar o que elas irão comprar e construir para resolver seusproblemas com base nas lições que aprenderam nos Sprints anteriores. Ademais, estesinvestimentos são feitos no contexto dos Sprints em andamento. Portanto, a equipe tratada criação da infraestrutura acrescentando itens ao Backlog de Produto para resolver ositens da infraestrutura, como mostra a Figura4 abaixo. É claro que o cliente que está diantede uma funcionalidade ainda tem prioridade,mas a equipe experiente reconhece queprecisa ser capaz de programar continuamenteo trabalho da infraestrutura de forma a mantersua velocidade e produtividade conforme oescopo da aplicação e o número de equipesvão crescendo.Figura 4: Análise da Infraestrutura deEscalabilidade em um Sprintwww.rallydev.com©2013 Rally Software Development27

SumárioO Scrum é uma prática de desenvolvimento de software consagrada e eficaz, que poderapidamente aumentar a produtividade, a velocidade da entrega e a qualidade das equipesde software.Que departamento de TI não iria se beneficiar destes atributos comumente vivenciadosatravés de implementações bem sucedidas do Scrum?• Redução do tempo do ciclo de desenvolvimento• Maior valor de processamento para usuários finais• Maior qualidade• Menor risco de desenvolvimento• Maior satisfação do usuário• Aumento da motivação na empresaEmbora pareça simples à primeira vista, a implementação do Scrum geralmente exige umamudança organizacional significativa para eliminar os impedimentos que atrapalham odesenvolvimento e a entrega eficaz. Como principal agente de mudanças, o CIO ou outropatrocinador executivo tem a responsabilidade primordial de eliminar estes impedimentos. Éo compromisso duradouro do CIO que pode definir a diferença entre o sucesso e o fracassoda implementação. Embora nada disso seja fácil, o CIO que se comprometer a melhoraros resultados em termos de software utilizando o Scrum terá dado o primeiro passo paraassegurar que a empresa está no caminho certo para alcançar os benefícios comerciais daentrega de software mais rápida e de melhor qualidade.Além disso, o Scrum é altamente eficaz no desenvolvimento de aplicações corporativasde grande porte e capaz de suportar as necessidades de centenas de desenvolvedorestrabalhando em aplicações compartilhadas. O dimensionamento do Scrum impõe uma sériede desafios à infraestrutura e ao ferramental que as próprias equipes terão de resolver - masa superação destes desafios irá provavelmente proporcionar uma vantagem significativapara as organizações maiores em relação a seus rivais no mercado.www.rallydev.com©2013 Rally Software Development28

BibliografiaAgile Manifesto: www.agilealliance.orgBeck, Kent. Extreme Programming Explained: Embrace Change (2ª Edição). Boston:Addison-Wesley, 2004.Schwaber. Ken. Agile Project Management with Scrum. Redmond, WA: Microsoft Press,2004.Schwaber, Ken, and Mike Beedle. Agile Software Development with Scrum. Upper SaddleRiver, N.J.: Prentice Hall, 2002.www.rallydev.com©2013 Rally Software Development29

Apêndice A - RecursosLeituras SelecionadasBeck, Kent. Extreme Programming Explained: Embrace Change 2nd Edition. Boston:Addison-Wesley, 2004. Cockburn, Alistair. Agile Software Development. Boston: Addison-Wesley, 2002.Cohn, Mike. User Stories Applied. Boston, MA: Pearson Education, 2004.Highsmith, Jim. Agile Project Management: Creating Innovative Products. Boston: PearsonEducation, 2004. Nonaka, Ikujiro and Hirotaka Takeuchi. The Knowledge-Creating Company.Oxford University Press, 1995. Poppendieck, Mary and Tom Poppendieck. Lean SoftwareDevelopment. Addison-Wesley, 2003.Schwaber. Ken. Agile Project Management with Scrum. Redmond, WA: Microsoft Press,2004.Schwaber, Ken, and Mike Beedle. Agile Software Development with Scrum. Upper SaddleRiver, N.J.: Prentice Hall, 2002. Larman, Craig. Agile and Iterative Development: A Manager’sGuide, Boston: Addison Wesley 2004Treinamento ÁgilSCRUM Master Class - www.controlchaos.com/certifiedscrum/EXtreme Programming - www.xprogramming.com/xpmag/services.htmFerramental e Treinamento ÁgilRally Software Development: www.rallydev.comOutrosAgile Alliance: www.agilealliance.orgScrumAlliance: http://www.scrumalliance.org/Possíveis newsgroups para interessados em Scrum / Agile:Desenvolvimento em Scrum : http://groups.yahoo.com/group/scrumdevelopment/Gestão Ágil: http://groups.yahoo.com/group/agilemanagement/Testes Ágeis: http://groups.yahoo.com/group/agile-testingDesenvolvimento em Lean: http://groups.yahoo.com/group/leandevelopment/www.rallydev.com©2013 Rally Software Development30

Apêndice B – O Manifesto ÁgilEm 2001, foi realizado em Snowbird, Utah, EUA, um workshop no qual vários criadorese praticantes das metodologias ágeis se reuniram para entender o que eles tinham emcomum. Eles escolheram a palavra “ágil” como um termo abrangente e elaboraram oManifesto para Desenvolvimento Ágil de Software, cujo sustentáculo é uma declaração dosvalores que compartilhavam:“Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o e ajudando osoutros a fazê-lo. Através deste trabalho, aprendemos a valorizar:• Indivíduos e interações acima de processos e ferramentas• Softwares que funcionam acima de documentação abrangente• Colaborações de clientes acima de negociação de contrato• Reagir a mudanças em vez de seguir um planoOu seja, embora exista valor nos itens à direita, valorizamos os itens mais à esquerda”.O Manifesto causou impacto e desencadeou a criação de diversos novos projetos ágeis.Como ocorre com qualquer intento humano, alguns tiveram sucesso, outros não. Mas o quemais teve impacto sobre os sucessos foi a ligação que os homens de negócio e as pessoastécnicas tinham com o seu projeto. Esta era a maneira que eles desejavam que os softwaresfossem desenvolvidos. Projetos bem sucedidos geraram mais entusiastas.Princípios por trás do Manifesto ÁgilOs signatários do Manifesto Ágil concordaram com 12 princípios que subscrevem ereforçam o manifesto. Estes princípios se concentram em resultados e mudanças, empessoas e comunicação e feedback:Deliverables e MudançasEm vez de prescrever ou aconselhar um grande número de artefatos que devem serentregues como resultados de uma conclusão de projeto bem sucedida, os métodos ágeisvão de volta para o deliverable do princípio: software funcional.• Software funcional é a principal medida de progresso.• Nossa maior prioridade é satisfazer o cliente através da entrega rápida e contínua desoftware de grande valor.• Entregar software funcional com bastante frequência, de duas semanas a dois meses,com uma preferência para o prazo mais curto.• Acolher os requisitos variáveis, mesmo quando no final do desenvolvimento. Oswww.rallydev.com©2013 Rally Software Development31

processos ágeis exploram as mudanças para dar vantagem competitiva ao cliente.• Os melhores projetos, arquiteturas e requisitos emergem de equipes que se autoorganizam.• Simplicidade - a arte de maximizar a quantidade de trabalho não feita - é essencial.• A atenção contínua com a excelência técnica e o bom design aumenta a agilidade.Pessoas e ComunicaçãoCriar sistemas de software funcionais é, antes de tudo, lidar com pessoas.• Crie projetos ao redor de indivíduos motivados. Dê a eles o ambiente e o suporte de queprecisam e confie neles para fazer o serviço.• O pessoal de negócios e os desenvolvedores têm de trabalhar em conjunto diariamenteao longo de todo o projeto.• O método mais eficiente e eficaz de transmitir informações para e dentro de uma equipede desenvolvimento é a interação face a face.• Processos ágeis promovem desenvolvimento sustentável. Os patrocinadores,desenvolvedores e usuários devem ser capazes de manter um ritmo constanteindefinidamente.FeedbackNenhum processo ou método pode ser estático, portanto, feedback e auto-ajuste precisamser integrados.• A intervalos regulares, a equipe reflete sobre como se tornar mais eficiente e, então,sintoniza e ajusta seu comportamento de acordo com essa reflexão.Crédito aos líderes dos métodos ágeisUm grande número de líderes intelectuais tem participado no desenvolvimento de váriosmétodos ágeis, sendo impossível reconhecê-los todos. Entre eles citamos: Kent Beck (XP),Mike Beedle, Ken Schwaber & Jeff Sutherland (Scrum), Alistair Cockburn (Crystal), WardCunningham (FIT), Martin Fowler (XP), Jim Highsmith (Agile Project Management), Marie &Tom Poppendieck (Lean Software Development) e Ron Jeffries (XP).www.rallydev.com©2013 Rally Software Development32

Apêndice C – Métricas do ScrumTabela 1 – Métricas do Processo Scrum(Hartmann, Stallings)Projeto Pontuação (0-5) Sprint 1 Sprint 21. Product OwnerBacklog do Produto desenvolvido possuído e gerenciado peloProduct OwnerProcesso do Product Owner é flexível; colaboração com equipeé contínuaParticipação do Product Owner e do stakeholder na Análise doSprintProduct Owner gerencia projeto por valorPontuação Total do “Product Owner”2. PlanejamentoBacklog do Produto é descritivo, priorizado e tem estimativaseficazesEquipe desenvolve e gerencia o Backlog do SprintEquipe envolve stakeholders e dependências de forma eficazAndamento do projeto pode ser rastreado por backlogBurnDown e burnup de valoresRitmo sustentávelPontuação Total do “Planejamento”3. ProgramaçãoPlanejamento de Sprint regular, na hora certa, totalmenteassistidoAnálise de Sprint regular, na hora certa, totalmente assistidaScrum Diário ocorre na hora certa, é totalmente assistidoEquipe cumpre seus compromissos com o SprintPontuação Total da “Programação”4. ProcessoEquipe se autopolicia e reforça uso de processo e regrasOrganização é capaz de cumprir regras de ScrumScrumMaster é eficaz em fazer seguir processoEquipe está se autogerindoSurpresas não ocorremEquipe é interfuncionalEquipe e Product Owner colaboram e trabalham unidosEquipe trabalha para aprimorar a si e aos seus processosEquipe gerencia dependências adequadamentePontuação Total de “Processo”www.rallydev.com©2013 Rally Software Development33

Projeto Pontuação (0-5) Sprint 1 Sprint 25. EquipeMembros da equipe são dedicados e honram compromissosEquipe efetivamente atua sobre indicadores em Sprint BurnDownComunicações entre membros da equipe são eficazesEquipe gerencia conflito de forma eficaz dentro da equipeEquipe aprimora processos de desenvolvimento internosPontuação Total da “Equipe”6. RelatóriosBacklog do Produto é mantido e transmitido de forma eficazBacklog do Sprint é mantido e transmitido de forma eficazRelatórios do Projeto e do Sprint são eficazes e compreendidosValor é utilizado para gerenciar o Backlog do ProdutoPontuação Total de “Relatórios”7. Práticas de Engenharia / InfraestruturaPelo menos criação diáriaBiblioteca comum de código fonteMétrica para qualidade de incrementoMétrica de incremento cumpridaPráticas de desenvolvimento dirigidas a testesPráticas de refatoraçãoPráticas de análise de designPráticas de análise de codificaçãoPadrões de codificaçãoEquipamento de teste unitário automatizadoEquipamento de teste de aceitação automatizadoPontuação Total da “Engenharia”www.rallydev.com©2013 Rally Software Development34

Tabela 2 – Métricas do Projeto Scrum(Rally Software Development Corp.)Projeto Sprint 1 Sprint 2FuncionalidadeNovas Funcionalidades PlanejadasNovas Funcionalidades ConcluídasStory cardsEm iteraçãoAceitos% de AceitosNº não aceitosNº empurrados para a próximaNº empurrados posteriormenteNº adicionados/apagadosQualidade e Automação de Testes% de SC com teste disponível / testes automatizadosOpen Defect Count (P1 + P2)Total Open Defect CountNº de casos de testeNº de casos de teste manuais exigidos para retrocederCode coverage %ArquiteturaRefactors concluídosRefactors em andamentoRefactor backlogCustomer debt featuresDébito de funcionalidades do cliente aceitoPlano de ReleaseSegurança de que o plano do release foi compreendidoSegurança no cumprimento do planoData de Release PlanejadaData de Release Realwww.rallydev.com©2013 Rally Software Development35