DADOS DE COPYRIG HT
Sobre a obra:
A presente obra é disponibilizada pela equipe Le Livros e seus diversos parceiros, com o obj etivo de oferecer conteúdo para uso parcial em pesquisas e estudos acadêm icos, bem com o o sim ples teste da qualidade da obra, com o fim exclusivo de com pra futura.
É expressam ente proibida e totalm ente repudiável a venda, aluguel, ou quaisquer uso com ercial do presente conteúdo
Sobre nós:
O Le Livros e seus parceiros disponibilizam conteúdo de dom inio publico e propriedade intelectual de form a totalm ente gratuita, por acreditar que o conhecim ento e a educação devem ser acessíveis e livres a toda e qualquer pessoa. Você pode encontrar m ais obras em nosso site: LeLivros.site ou em qualquer um dos sites parceiros apresentados neste link.
"Quando o mundo estiver unido na busca do conhecimento, e não mais lutando por dinheiro e poder, então nossa sociedade poderá enfim evoluir a um novo
Ficha Técnica
Copy right © 2014 by Jeff Sutherland and Scrum , Inc. Todos os direitos reservados.
Tradução para a língua portuguesa © 2014 Texto Editores Ltda. Título original: Scrum : The art of doing twice the work in half the tim e
Preparação de texto: Meggie Monauar Revisão: Paula Jacobini Diagram ação: Cristiane Viana
Capa: Ideias com Peso
Dados Internacionais de Catalogação na Publicação (CIP) Angélica Ilacqua CRB-8/
7057 Sutherland, Jeff
Scrum : a arte de fazer o dobro do trabalho na m etade do tem po / Jeff Sutherland; tradução de Natalie Gerhardt.
-São Paulo : LeYa, 2014. Bibliografia ISBN 9788544100882
Título original: Scrum : The art of doing twice the work in half the tim e
1. Scrum (Desenvolvim ento de software) 2. Negócios 3. Adm inistração I. Título II. Gerhardt, Natalie
14-0701 CDD 658 Índices para catálogo sistem ático:
1. Adm inistração - negócios 2014 TEXTO EDITORES LTDA. Um a editora do Grupo LeYa Rua Desem bargador Paulo Passaláqua, 86 01248-010 — Pacaem bu — São Paulo, SP
Jeff Sutherland
SCRUM A arte de fazer o dobro do trabalho na m etade do tem po
Prefácio
Por que Scrum ?
Eu criei o Scrum , j unto com Ken Schwaber, há vinte anos, para ser um a form a m ais rápida, eficaz e confiável de criar softwares para o setor de tecnologia. Até aquele ponto — e até 2005 —, a m aior parte do desenvolvim ento de software era feita usando o m étodo em cascata, no qual um proj eto era concluído em todos os estágios distintos e seguia, passo a passo, em direção ao lançam ento para os consum idores, ou usuários. O processo era lento, im previsível e, em geral, nunca resultava em um produto que as pessoas queriam ou estavam dispostas a pagar para obter. Atrasos de m eses ou até m esm o de anos eram endêm icos ao processo. Os planos iniciais de passo a passo, expostos em detalhes reconfortantes em diagram as de Gantt, asseguravam aos gestores que tínham os total controle do processo de desenvolvim ento — no entanto, quase sem pre, nós rapidam ente ficávam os atrasados em relação ao cronogram a, e desastrosam ente acim a do orçam ento.
Para superar essas falhas, em 1993, inventei um a nova form a de fazer as coisas: o Scrum . Trata-se de um a m udança radical das m etodologias prescritivas e de cim a para baixo usadas na gerência de proj etos no passado; j á o Scrum é sem elhante aos sistem as autocorretivos, evolucionários e adaptativos. Desde o com eço, a estrutura do Scrum se tornou a form a de o setor tecnológico criar novas aplicações de software e produtos. Contudo, em bora ele tenha se tornado m uito bem -sucedido no gerenciam ento de proj etos de software e hardware no Vale do Silício, ainda perm anece pouco conhecido em outros setores de negócios. E foi por isso que escrevi este livro: para revelar e explicar o sistem a de gerenciam ento do Scrum para setores de negócios fora do m undo da tecnologia. Aqui eu falo sobre a sua origem no Sistem a Toy ota de Produção e no ciclo OODA da aviação de com bate. Discuto com o organizam os proj etos em torno de equipes pequenas — e por que essa é a form a m ais eficaz de se trabalhar. Explico com o priorizam os as diversas tarefas nos proj etos; com o definim os Sprints de um a sem ana a um m ês para criarm os um a força e tornarm os todos na equipe responsáveis; com o fazem os reuniões breves diárias para m anter o controle de tudo o que
foi feito e dos desafios que inevitavelm ente aparecem ; e com o o Scrum incorporou os conceitos de aprim oram ento contínuo e produtos m inim am ente viáveis para obter feedback im ediato dos consum idores, em vez de esperar até que o proj eto tenha sido concluído. Com o você verá, usam os o Scrum para construir qualquer coisa, desde carros viáveis que fazem 42 quilôm etros por litro de com bustível até trazer os sistem as de banco de dados do FBI para o século 21.
Leia este livro. Acho que você verá com o o Scrum pode aj udar a transform ar o m odo com o a sua em presa trabalha, cria, planej a e pensa. Eu realm ente acredito que esse sistem a pode aj udá-lo a revolucionar a form a com o as em presas funcionam em praticam ente todos os setores, assim com o ele revolucionou a inovação e a velocidade para o m ercado em um a gam a estarrecedora de novas em presas e um a variedade enorm e de novos produtos surgindo fora do Vale do Silício e do m undo da tecnologia.
CAPÍTULO 1
A m aneira com o o m undo funciona está quebrada
Jeff Johnson tinha quase certeza de que aquele não seria um bom dia. Em 3 de m arço de 2010, o Federal Bureau of Investigation (FBI) cancelou o seu proj eto m ais am bicioso de m odernização — aquele que poderia ter evitado o 11 de setem bro, m as que se transform ou em um dos m aiores fiascos da indústria de software de todos os tem pos. Por m ais de um a década, o FBI tentou atualizar seu sistem a de com putação, e tudo indicava que iria falhar. De novo. E agora o proj eto era dele.
Ele havia chegado ao FBI sete m eses antes, atraído pelo novo Diretor-Executivo de Inform ação (Chief Information Officer, CIO), Chad Fulgham , com quem trabalhara na Lehm an Brothers. Jeff era o diretor-assistente da nova Divisão de Engenharia de Tecnologia da Inform ação (TI), e tinha um escritório no últim o andar do edifício J. Edgar Hoover, no centro de Washington, D.C. Era um a sala grande com vista para o Monum ento de Washington. Mal sabia Jeff que, pelos dois anos seguintes, acabaria em um escritório sem j anelas e do tam anho de um a caixa de fósforos no porão do prédio, tentando consertar algo que todos diziam ser im possível.
“Não foi um a decisão fácil”, conta Jeff. Seu chefe e ele decidiram declarar derrota e cancelar um program a no qual haviam trabalhado por quase dez anos e custara centenas de m ilhões de dólares. Àquela altura, fazia m ais sentido trazer o proj eto para “dentro de casa” e tentar fazê-lo por conta própria. “Mas aquilo precisava realm ente ser feito, e m uito bem feito”.
Tratava-se do aguardado proj eto para um novo sistem a de com putação que efetivam ente trouxesse o FBI para a era m oderna. Em 2010 — a era do Facebook, Twitter, Am azon e Google —, a agência ainda preenchia a m aioria de seus relatórios no papel, e utilizava um sistem a cham ado Autom ated Case Support. Ele rodava em com putadores gigantescos que, em algum período da década de 1980, eram o que existia de m ais m oderno. Mas, naquele m om ento, m uitos agentes especiais nem o usavam m ais; era ainda inconveniente e m uito lento para um a época de ataques terroristas e crim inosos espertos.
Quando um agente do FBI queria fazer algo — qualquer coisa, na verdade —, desde pagar a um inform ante para perseguir um terrorista até fazer um relatório sobre um ladrão de bancos, o processo não era m uito diferente do que era feito trinta anos antes. Johnson o descreve da seguinte m aneira:
Era necessário escrever o relatório usando um processador de texto e depois im prim i-lo em três vias. Um a seria enviada para aprovação, outra arquivada localm ente para o caso de a prim eira se perder; e, na terceira via, você teria de pegar um a caneta verm elha — não, eu não estou brincando, um a caneta verm elha m esm o — e circular as palavras-chave que deveriam ser inseridas no banco de dados. Você tinha de indexar o próprio relatório.
Quando um pedido era aprovado, a via em papel recebia determ inado núm ero — sim , um núm ero escrito em um pedaço de papel é o m odo com o o FBI m antém todos os seus arquivos de casos. Esse m étodo era tão antiquado e furado que recebeu parte da culpa quando a agência não conseguiu “unir os pontos” que m ostravam vários ativistas da Al-Qaeda entrando no país pouco tem po antes dos atentados terroristas de 11 de setem bro. Um escritório tinha um suspeito; outro se perguntava por que tantos estrangeiros suspeitos estavam assistindo a aulas de pilotagem de avião. E outro ainda tinha um suspeito em sua lista de vigilância, m as não repassou a inform ação. Assim , ninguém no FBI foi capaz de reunir todas aquelas peças.
Depois dos ataques, a Com issão do 11 de Setem bro investigou a fundo para tentar descobrir o principal m otivo de aquilo ter acontecido, e chegou à conclusão de que os analistas não conseguiram ter acesso às inform ações necessárias. Diz o relatório: “A ineficiência dos sistem as de inform ação do FBI significava que tal acesso dependia em grande parte das relações interpessoais do analista com pessoas em outras unidades ou equipes que detinham tais inform ações”.
Antes da tragédia, o FBI nunca havia concluído um a avaliação da am eaça global do terrorism o dentro dos Estados Unidos. Houve um a série de razões para isso, desde foco no avanço da carreira dos funcionários até um a total falta de com partilham ento de inform ações. No entanto, o relatório apontou a ausência de sofisticação tecnológica com o talvez o principal m otivo por que o FBI falhara de form a tão drástica nos dias que antecederam os ataques. “Os sistem as de inform ação do FBI eram com pletam ente inadequados”, concluiu o docum ento. “O FBI não tinha capacidade para
saber o que sabia: não havia qualquer m ecanism o adequado para acessar ou com partilhar o conhecim ento institucional”.
Quando os senadores com eçaram a fazer perguntas desconfortáveis para a agência, o FBI praticam ente disse “não se preocupem , tem os um plano de m odernização j á em andam ento”. O sistem a planej ado se cham ava Virtual Case File (VCF) e deveria m udar tudo. Sem deixar que a crise passasse em branco, os funcionários relataram que precisavam apenas de m ais US$ 70 m ilhões, além dos outros US$ 100 m ilhões j á orçados, para concluírem o trabalho. Se você ler os relatórios sobre o VCF da época, perceberá que as palavras revolucionário e transformação são usadas de form a generosa.
Três anos depois, o program a foi cancelado. Não funcionava. Nem um pouquinho. O FBI tinha gastado US$ 170 m ilhões dos contribuintes para com prar um sistem a de com putador que nunca seria usado — nem um a linha de código ou aplicação ou clique do m ouse. Tudo aquilo era o m ais absoluto desastre. E não era com parável a um erro da IBM ou da Microsoft. A vida das pessoas estava, literalm ente, em risco. O Senador Patrick Leahy, de Verm ont, dem ocrata e então Presidente do Com itê Judiciário do Senado, declarou, na época, ao Washington Post:
Nós tínham os inform ações que poderiam ter im pedido os ataques terroristas de 11 de setem bro. Estavam bem ali, diante de nós, e ninguém fez nada... Eu não estou vendo os problem as serem corrigidos... Talvez cheguem os ao século XXII antes que consigam os ter a tecnologia do século XXI.1
É bastante esclarecedor dizer que m uitas das pessoas que trabalhavam no FBI quando o desastre do Virtual Case File aconteceu não estão m ais trabalhando lá.
Em 2005, a agência anunciou um novo program a, o Sentinel. Daquela vez, ia funcionar. Daquela vez, tom ariam todas as precauções necessárias, fariam os procedim entos orçam entários corretos e usariam as ferram entas certas de controle. Já tinham aprendido a lição. O preço? Meros US$ 451 m ilhões. E estaria em pleno funcionam ento em 2009.
O que poderia dar errado? Em m arço de 2010, a resposta caiu na m esa de Jeff Johnson. A Lockheed Martin, em presa contratada para desenvolver o sistem a Sentinel, j á tinha gastado US$ 405 m ilhões do orçam ento. Tinham desenvolvido apenas m etade do proj eto e j á estavam um ano atrasados. Um a análise independente estim ou que levariam outros seis a oito anos para
concluir o proj eto, e que ainda teriam de investir m ais US$ 350 m ilhões do dinheiro dos contribuintes.
Encontrar um a solução para aquilo era problem a de Johnson. O que tinha dado errado e com o a situação foi resolvida são o m otivo por que estou escrevendo este livro. Não era um a questão de inteligência. Não era que a agência não tivesse as pessoas certas nos lugares certos e tam bém não era um a questão de tecnologia errada. Tam bém não tinha nada a ver com ética no trabalho ou com o estím ulo adequado de com petitividade. Era por causa da maneira com o as pessoas estavam trabalhando. A maneira com o a m aioria das pessoas trabalha. A m aneira com o nós acham os que o trabalho precisa ser feito, porque foi assim que aprendem os a fazê-lo.
Quando você ouvir o que aconteceu, vai achar que, em um prim eiro m om ento, parece fazer sentido: as pessoas na Lockheed se reuniram antes de entrar na concorrência para o contrato, analisaram os requisitos e com eçaram a planej ar com o desenvolver um sistem a que atenderia a todas as necessidades do cliente. Eles tinham m uitas pessoas inteligentes trabalhando por m eses a fio, planej ando tudo o que precisava ser feito. Então, dedicaram m ais alguns m eses planej ando como fazê-lo. Desenharam lindos diagram as com tudo isso, e o tem po que levaria para atingir os obj etivos. Então, com um a seleção cuidadosa de cores, apresentaram um fluxo que m ostrava cada um a das fases do proj eto com o um a cascata.
Esses fluxos se cham am “diagram as de Gantt”, em hom enagem a Henry Gantt, que os desenvolveu. Com o advento dos com putadores pessoais na década de 1980, tornou-se bem m ais fácil desenvolver diagram as com plicados — e torná-los realm ente complexos —, e eles se tornaram verdadeiras obras de arte. Cada etapa do proj eto está detalhadam ente definida; cada evento im portante, cada data de entrega. Esses diagram as são realm ente algo im pressionante de se ver. O único problem a com eles é que estão sem pre errados. Sem pre.
Henry Gantt inventou esses fam osos diagram as por volta de 1910. Eles com eçaram a ser usados na Prim eira Guerra Mundial pelo General William
