Fabio Braga de Oliveira

Relac o es entre o PMBOK e metodologias a geis de desenvolvimento de software

Campinas SP Dezembro / 2008

Fabio Braga de Oliveira

Relac o es entre o PMBOK e metodologias a geis de desenvolvimento de software

Trabalho apresentado ao curso MBA em Ge o lato renciamento de Projetos, P os-Graduac a o Get sensu, da Fundac a ulio Vargas como requi o do Grau de Especisito parcial para a obtenc a alista em Gerenciamento de Projetos.

Orientador:

Prof. Andr e Valle

G ET ULIO F UNDAC AO VARGAS

Campinas SP Dezembro / 2008

 o Get Fundac a ulio Vargas Programa FGV Management MBA em gerenciamento de projetos O trabalho de conclus ao de curso Relac o es entre o PMBOK e metodologias a geis de deo senvolvimento de software, elaborado por Fabio Braga de Oliveira e aprovado pela Coordenac a Acad emica do curso MBA em Gerenciamento de Projetos em 1 de dezembro de 2008, foi o do certicado do curso de p o, n aceito como requisito parcial para a obtenc a os-graduac a vel o do Programa FGV Management. de especializac a

Andr e Bittencourt do Valle Coordenador Acad emico Executivo

Termo de compromisso
O aluno Fabio Braga de Oliveira, abaixo assinado, do curso MBA em gerenciamento de projetos, turma PROJ15 do programa FGV Management, realizado nas depend encias da BI Campinas, no per odo de 01/01/2007 a 01/07/2008, declara que o conte udo do Trabalho de es entre o PMBOK e metodologias a geis de desenvolviConclus ao de Curso intitulado Relac o aut mento de software e entico, original e de sua autoria exclusiva. Campinas, 01 de dezembro de 2008.

Fabio Braga de Oliveira

Dedicat oria

Dedico este trabalho a minha esposa, Que com carinho e paci encia tem me ensinado os verdadeiros valores da vida.

Agradecimentos

Dedico meus sinceros agradecimentos para: o o professor Andr e Bittencourt do Valle, pela orientac a e incentivo; o amigo Guilherme OConnor, por sua revis ao, inu encia, sugest oes e amizade; ao projeto abnTex (ABNTEX, 2008) e sua comunidade, o gr praticamente respons avel pela bela formatac a aca deste trabalho; a todos os colegas da turma PROJ15 do curso MBA em o Get gerenciamento de projetos da Fundac a ulio Vargas.

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds castles in the air, from air, creating by exertion of the imagination. [...] Yet the program construct, unlike the poets words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. [...] The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard , and a display screen comes to life, showing things that never were nor could be. Brooks

Resumo
es entre metoNeste trabalho foi realizada uma pesquisa bibliogr aca buscando as relac o geis com o que e advogado como dologias modernas de desenvolvimento de software ditas a boas pr aticas pelo Project Management Institute (PMI) atrav es do seu trabalho A Guide to the Project Management Body of Knowledge(PMBOK) (PMI, 2004). geis, PMBOK, Project ManagePalavras-chave: engenharia de software, metodologias a ment Institute.

Abstract
In this work was realized a bibliography research looking for the relation between modern software methodologies said agiles with what is advocated as good practices by the Project Management Institute(PMI) in its work A Guide to the Project Management Body of Knowledge (PMI, 2004). Key Words: software engineering, agile methodologies, PMBOK, Project Management Institute.

Sum ario

Lista de Figuras Lista de Tabelas 1 o Introduc a 1.1 1.2 1.3 1.4 2 es iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Considerac o Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o do escopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Denic a Metodologia cient ca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 13 p. 13 p. 18 p. 18 p. 19 p. 20 p. 20 p. 21 p. 24 p. 25 p. 28 p. 29 p. 29 p. 30 p. 30 p. 32 p. 33 p. 34

Contexto hist orico 2.1 A hist oria do conhecimento em gerenciamento de projetos . . . . . . . . . . 2.1.1 2.1.2 2.1.3 2.1.4 2.2 Antes de 1940 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A segunda guerra mundial . . . . . . . . . . . . . . . . . . . . . . . Os anos 50, o desenvolvimento do gerenciamento de sistemas . . . . Os anos 60, Apollo e a d ecada do gerenciamento de sistemas . . . . .

A curta hist oria da engenharia de software . . . . . . . . . . . . . . . . . . . 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6 Pr e-hist oria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Os anos 50 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Os anos 60 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Os anos 70 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Os anos 80 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Os anos 90 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.7 3

Os anos 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 34 p. 38 p. 38 p. 38 p. 39 p. 40 p. 41 p. 43 p. 43 p. 45 p. 48 p. 50 p. 53 p. 56 p. 59

A teoria por tr as da metodologia 3.1 A anatomia de uma metodologia . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 3.1.2 3.1.3 3.1.4 Estrutura de uma metodologia . . . . . . . . . . . . . . . . . . . . . Tipos de metodologias . . . . . . . . . . . . . . . . . . . . . . . . . Escopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conceitos do desenho de metodologias . . . . . . . . . . . . . . . .

Um v oo r apido sobre as diversas metodologias 4.1 4.2 4.3 4.4 4.5 Extreme Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Crystal Clear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Feature Driven Development . . . . . . . . . . . . . . . . . . . . . . . . . . O PMBOK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Conclus oes

Refer encias Bibliogr acas

Lista de Figuras
2.1 2.2 2.3 2.4 2.5 Pir amides de Giza, no Egito (EGYPTIAN. . . , 2008) . . . . . . . . . . . . . . York Minster, catedral de York, Inglaterra (CASTLES. . . , 2008) . . . . . . . p. 21 p. 22

Trabalhadores de ferrovias no nordeste de Utah, 1869 (RAILROADS. . . , 2008) p. 23 Rotas de invas ao na Normandia (NORMANDY. . . , 2008) . . . . . . . . . . . Dispositivo nuclear Jumbo sendo posicionado para o teste Trinity em Alamogordo, Novo M exico (NEIGHBORHOOD. . . , 2008) . . . . . . . . . . p. 26 p. 25

2.6

Primeiro lanc amento do m ssil Atlas do Cabo Canaveral em 1957 (DECEMBER. . . , 2008) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27 p. 30 p. 32 p. 37 p. 40 p. 48 p. 51 p. 54

2.7 2.8 2.9 3.1 4.1 4.2 4.3

Processo formal de desenvolvimento do projeto SAGE . . . . . . . . . . . . Modelo cascata de desenvolvimento de software . . . . . . . . . . . . . . . . Tend encias de software (BOEHM, 2006) . . . . . . . . . . . . . . . . . . . . As tr es dimens oes do escopo de uma metodologia (COCKBURN, 2001) . . . Processo da metodologia Scrum (SCRUM, 2008) . . . . . . . . . . . . . . . Diagrama de processos da metodologia FDD (FEATURE. . . , 2008) . . . . . o entre os grupos de processos do PMBOK (PMI, 2004) . . . . . . . . Iterac a

Lista de Tabelas
1.1 1.2 1.3 4.1 The Standish Group Chaos Report: fatores de sucesso . . . . . . . . . . . . . The Standish Group Chaos Report: estudo de casos . . . . . . . . . . . . . . Taxas de sucesso relatadas pelo Standish Group . . . . . . . . . . . . . . . . Marcos na metodologia FDD . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15 p. 15 p. 16 p. 52

13

Introduc a o

1.1

es iniciais Considerac o

N ao s ao necess arios muitos anos de experi encia na ind ustria de software para j a se colecionar hist orias de projetos que terminaram muito longe de suas estimativas iniciais de custos e rea, ao que parece algo ainda foge aos olhos prazos. Apesar dos grandes esforc os j a feitos na a mais cuidadosos. vasta quando se trata do assunto engenharia de software e metodologias A bibliograa e es lanc de desenvolvimento de software. Ao longo do tempo, muitos autores e organizac o aram m ao de recursos para melhor compreender este fen omeno. Em 1975, o c elebre livro The Mythical Man-Month (BROOKS, 1995) j a retratava a reali es vindouras. Seu autor, Frederick P. Brooks, cunhou dade dura que iria ser vivida pelas gerac o a famosa frase:
Adding manpower to a late software project makes it later.1 (BROOKS, 1995)

Al em desta famosa frase, sua obra cont em outras tantas igualmente famosas, e apesar de considerada muito ser uma obra sobre engenharia de software com mais de 30 anos de idade, e atual (REVIEW. . . , 2005). A tend encia dos gerentes de projetos de software ainda repetirem chamado A os mesmos erros fez com que seu autor, jocosamente, declarasse que seu livro e B blia da Engenharia de Software porque todos l eem, mas ningu em faz nada de acordo com ela!. Vinte anos ap os estes trabalhos, em 1995 o The Standish Group fez uma grande pesquisa reas e compilou seu resultado no relat junto a 365 empresas de software das mais diversas a orio Chaos (THE STANDISH GROUP, 1995) que trazia os seguintes dados: Os Estados Unidos despendia mais do que 250 bilh oes de d olares por ano em desenvolvimento de software em aproximadamente 175000 projetos. O custo m edio de desenvol1 Traduc o: a

Adicionar pessoas a um projeto atrasado faz ele mais atrasado.

14

vimento para uma empresa grande era de US$2.322.000; para uma empresa m edia era de US$1.331.000; e para uma empresa pequena era de US$434.000. 31,1% dos projetos eram cancelados antes deles serem conclu dos. 52,7% custaram 189% a sua estimativa inicial. o de projetos: E ainda de acordo com a seguinte classicac a Tipo 1, projeto bem sucedido: o projeto foi terminado no prazo e no custo estimado, com es especicadas inicialmente. todas as caracter sticas e func o operacional, mas Tipo 2, projeto posto em risco: o projeto foi terminado e seu produto e es do que passou seu prazo ou seu custo, e oferece bem menos caracter sticas e func o originalmente especicado. Tipo 3, projeto cancelado: o projeto foi cancelado em algum ponto durante seu desenvolvimento. Tem-se que as falhas em projetos n ao eram igualmente distribu das de acordo com o tama o. Contrariando o que poderia ser o senso comum, somente 9% dos projetos nho da organizac a em grandes empresas eram bem sucedidos (tipo 1), enquanto as empresas pequenas e m edias tinham uma taxa de sucesso de 28% e 16,2% respectivamente. De acordo com o relat orio, um dos principais resultados da pesquisa seria descobrir as causas de tantas falhas. Para tanto, foram entrevistados executivos de TI sobre suas opini oes do que faria um projeto ser bem sucedido. As tr es maiores raz oes foram o envolvimento do usu ario, suporte do gerenciamento executivo e requisitos claros. H a outros fatores, como pode ser visto na tabela 1.1, mas com estes elementos a chance de sucesso aumentaria enormemente. Das empresas pesquisadas, foram escolhidos quatro casos para estudo, representativos entre empresas pequenas, m edias e grandes, e entre diversas ind ustrias, duas do tipo 3 e duas do tipo 1 conforme o crit erio apresentado anteriormente. Os projetos escolhidos foram o DMV, o CONFIRM, o HYATT e o ITAMARATI. O projeto DMV foi iniciado pelo departamento de tr ansito da Calif ornia, em 1987, para revitalizar os sistemas respons aveis pelo registro de licenc as. Em 1993, depois de terem sidos gastos 45 milh oes de d olares, o projeto foi cancelado.

15

Fatores de sucesso do projeto 1.Envolvimento do usu ario 2.Suporte do gerenciamento executivo 3.Requisitos claros 4.Planejamento apropriado 5.Expectativas realistas 6.Marcos menores 7.Equipe competente 8.Senso de propriedade 9.Vis ao e objetivos claros 10.Trabalho duro, equipe focada Outros

% de respostas 15,9% 13,9% 13,0% 13,0% 8,2% 7,7% 7,2% 5,3% 2,9% 2,4% 13,9%

Tabela 1.1: The Standish Group Chaos Report: fatores de sucesso O projeto CONFIRM foi um projeto iniciado em 1994 pelas empresas American Airlines, Budget Rent-A-Car, Marriot Corp. e Hilton Hotels, que depois de 165 milh oes de d olares cancelaram seu projeto de reserva de viagens, hot eis e aluguel de ve culos. Enquanto o projeto CONFIRM falhava, o projeto de reserva HYATT do Hyatt Hotels foi nibus muito bem sucedido. Hoje, pode-se reservar um quarto atrav es do celular, pedir que o o de cortesia passe no aeroporto e ter suas chaves esperando voc e no balc ao, tudo isso com um prazo e custos menores que o estimado, e com funcionalidades extras. O projeto ITAMARATI do Banco Itamarati tamb em foi um grande sucesso. O seu projeto para melhoria do atendimento ao cliente teve muitos dos ingredientes chaves que contribu ram para seu m no custo e no prazo estimados. Ao cruzar os dados de fatores de sucesso com os casos de estudo, dando-se um peso adequado aos itens ditos mais inuentes no sucesso de um projeto, obteve-se a tabela 1.2 como resultado.
Crit erio de Sucesso 1.Envolvimento do usu ario 2.Suporte do Gerenciamento Executivo 3.Requisitos claros 4.Planejamento apropriado 5.Expectativas realistas 6.Marcos menores 7.Equipe competente 8.Senso de propriedade 9.Vis ao e objetivos claros 10.Trabalho duro, equipe focada Total Pontos 19 16 15 11 10 9 8 6 3 3 100 DMV n ao(0) n ao(0) n ao(0) n ao(0) sim(10) n ao(0) n ao(0) n ao(0) n ao(0) n ao(0) 10 CONFIRM n ao(0) sim(16) n ao(0) n ao(0) sim(10) n ao(0) n ao(0) n ao(0) n ao(0) sim(3) 29 HYATT sim(19) sim (16) sim(15) sim(11) sim(10) sim(9) sim(8) sim(6) sim(3) sim(3) 100 ITAMARATI sim(19) sim(16) n ao(0) sim(11) sim(10) sim(9) sim(8) sim(6) sim (3) sim(3) 85

Tabela 1.2: The Standish Group Chaos Report: estudo de casos

16

Como pode ser visto, pelos dados levantados no pr oprio relat orio, os projetos DMV e CONFIRM tinham pequena chance de sucesso, enquanto o HYATT e ITAMARATI possu am os ingredientes certos. O resultado nal da pesquisa foi que os projetos de desenvolvimento de software estavam num estado ca otico. Uma lista de sugest oes e fatores de sucesso para projetos foi elaborada a partir desta pesquisa, e publicada. Poder amos questionar a validade desta pesquisa para os projetos atuais, argumentar que outra, com as mais novas t estes dados est ao velhos e defasados, e que a realidade hoje e ecnicas e metodologias, e com todo o aprendizado acumulado pela ind ustria. Infelizmente, como pode verdade. Se abusarmos e extrapolarmos estes dados, vemos que ser visto na tabela 1.3, isto n ao e a taxa de sucesso para projetos de software em grandes empresas tem crescido de maneira linear a uma raz ao de 1% ao ano, e que atingir a a marca de 50% no ano de 2014 (MARASCO, 2006). o nestes u ltimos anos, nada que justicasse um salto not N ao houve nenhuma revoluc a avel. Ao rea sim, mas a um passo extremamente lento. que parece, estamos evoluindo na a Relat orio Primeiro relat orio Chaos Extreme Chaos Relat orio Chaos recente Ano % Sucesso 1994 16% 2001 28% 2003 31%

Tabela 1.3: Taxas de sucesso relatadas pelo Standish Group comum na literatura que trata de engenharia e projetos de software. H Um tema e a um item rea de software que ainda n o intang vel na a ao foi domado, a exemplo da ind ustria da construc a civil, naval ou de defesa. Nos artigos No Silver Bullet e No Silver Bullet Rered (BROOKS, o ao c 1995), o primeiro com dez anos de intervalo com relac a elebre livro, e o segundo com o ao primeiro artigo, fazem menc es ao que o autor chama de complemais dez anos em relac a o xidade essencial e complexidade acidental. Segundo Brooks, o que zemos estes anos todos foi o de um sistema de software, que s atacar a diculdade acidental existente na produc a ao todas as o, ou ferramentas ruins ou diculdades criadas por n os mesmos, com excesso de documentac a excessivos pontos de controle. Mas ainda n ao atacamos a diculdade essencial de como facilitar o do modelo mental do problema a ser atacado pela equipe do projeto. Criar este moa criac a uma atividade intrinsecamente delo, como Cockburn tamb em coloca (COCKBURN, 2001), e reas da pol o. Ainda humana, e como tal passa pelas a tica, sociologia, psicologia e comunicac a uma atividade social, onde o ambiente deve ser segundo Cockburn, um projeto de software e favor avel para que exista a troca de conhecimento e experi encias, para que este modelo mental es de surgir. Os dois autores defendem a posic o que do que dever a ser o sistema tenha condic o a uma resposta melhor de onde se encontra a complexidade de todo projeto de software. esta e

17

mais comum o fracasso de um projeto de software do Vemos ent ao um cen ario onde e rea pode ter que seu sucesso. Pelas estat sticas at e o momento, um gerente de projetos na a como certo que o projeto que ele comec a hoje ter a uma chance de aproximadamente 70% de n ao ser conclu do ou ent ao de ultrapassar em muito suas estimativas de tempo e custos. Temos o do problema deve passar pela adequada compreens tamb em que qualquer soluc a ao e habilidosa o da sua natureza humana. manipulac a Mas desde 1969 o Project Management Institute(PMI) vem estabelecendo as bases para a pross ao de gerente de projetos, tendo como uma de suas principais obras de referencia o Project Management Body of Knowledge(PMBOK). Com ele, tenta-se estabelecer a soma do conhecimento na pross ao de gerenciamento de projetos e identicar que parte do conheci reconhecido como boa pr mento de gerenciamento de projetos e atica (PMI, 2004). The primary purpose of the PMBOK Guide is to identify that subset of the Project Management Body of Knowledge that is generally recognized as good practice. Identify means to provide a general overview as opposed to an exhaustive description. Generally recognized means that the knowledge and practices described are applicable to most projects most of the time, and that there is widespread consensus about their value and usefulness. Good practice means that there is general agreement that the correct application of these skills, tools, and techniques can enhance the chances of success over a wide range of different projects. Good practice does not mean that the knowledge described should always be applied uniformly on all projects; the project management team is responsible for determining what is appropriate for any given project.2 (PMI, 2004) Por em, se reetirmos por alguns instantes, vemos que ou estamos falhando em aplicar um conhecimento que hoje est a em sua fase de amadurecimento, com quase 40 anos de idade, ou rea de engeent ao ele tamb em n ao responde completamente aos problemas particulares da a que grupos de cientistas, pesquisadores e praticantes na a rea de nharia de software. Tanto e geis que parecem ser, em alguns engenharia de software v eem advogando metodologias ditas a ` vis aspectos, contr arias a ao do PMI em como se gerenciar um projeto nesta ind ustria. Como
identicar o subconjunto do conjunto de conhecimentos O principal objetivo do Guia PMBOK e amplamente reconhecido como boa pr em gerenciamento de projetos que e atica. Identicar signica fornecer o completa. Amplamente reconhecido signica que o conhecimento e as uma vis ao geral, e n ao uma descric a ` maioria dos projetos na maior parte do tempo, e que existe um consenso geral pr aticas descritas s ao aplic aveis a o ao seu valor e sua utilidade. Boa pr o em relac a atica signica que existe um consenso geral de que a aplicac a correta dessas habilidades, ferramentas e t ecnicas podem aumentar as chances de sucesso em uma ampla gama de projetos diferentes. Ser uma boa pr atica n ao implica que o conhecimento descrito dever a sempre ser aplicado respons uniformemente em todos os projetos; a equipe de gerenciamento de projetos e avel por determinar o que e adequado para um projeto espec co.
2 Traduc o: a

18

J. Davidson, PhD e PMP, argumenta, talvez seja o momento de rever os princ pios por tr as da maturidade, dos padr oes e processos controlados (FRAME, 2008) num mundo em constante mudanc a, cada vez maiores e mais r apidas. Num mundo onde as empresas desejam ser capazes de aprender e se adaptar ao meio. es da a rea, este tema e de suma import Para as organizac o ancia, trata-se de uma quest ao de es. sobreviv encia entender as vari aveis deste problema e poss veis soluc o

1.2

Objetivos

Este trabalho tem como objetivo fazer uma revis ao do conhecimento acumulado at e o mo rea de gerenciamento de projetos de software, sob a perspectiva de metodologias mento sobre a a geis de desenvolvimento e sob a perspectiva das recomendac es feitas pelo PMI atrav a o es da sua obra de refer encia, o PMBOK. Vericar as raz oes hist oricas por tr as de cada perspectiva de ge es entre as mesmas, se est renciamento, e estabelecer as relac o ao realmente em pontos opostos, se tratam de dimens oes diferentes do mesmo problema ou se apenas se complementam. Para tanto, esta obra est a dividida em quatro partes: a primeira estabelece o fundo hist orico onde se desenvolveu o conhecimento em gerenciamento de projetos; a segunda estabelece alguns conceitos te oricos sobre metodologias de gerenciamento de software, a m de estabelecer meios de compar a-las de forma clara e precisa; a terceira descreve de forma sucinta diversas metodologias de software e as principais boas pr aticas estabelecidas pelo PMBOK; e nalmente a quarta analisa e conclui sobre o tema proposto.

1.3

o do escopo Denic a

es do PMBOK serem mais extensas do que a Apesar da aplicabilidade das recomendac o rea de desenvolvimento de software, esta extens a ao e suas consequ encias n ao s ao analisadas neste trabalho. o precisa do que e uma metodologia de desenPor outro lado, por n ao existir uma denic a gil, este trabalho atem-se a denic o e aos trabalhos dos especialistas volvimento de software a a o, e que assinaram em conjunto o Manifesto pelo e pesquisadores que iniciaram a sua divulgac a Desenvolvimento Agil de Software (MANIFESTO. . . , 2001).

19

1.4

Metodologia cient ca

O trabalho apresentado utiliza a modalidade de pesquisa revis ao bibliogr aca. Foram utilizados como fontes de pesquisa bibliotecas e s tios na rede global de computadores. Os autores e es foram escolhidos de acordo com a relev o para a a rea pesquisada, instituic o ancia e contribuic a reas de gerenciamento de projetos, engenharia de principalmente cientistas e especialistas nas a geis. software e metodologias a

20

Contexto hist orico

George Santayana, escritor e l osofo, cunhou a famosa frase: Those who cannot remember the past are condemned to repeat it.1 Que de t ao conhecida se tornou clich e, e ganhou diversas variantes. No entanto, ao se interpretar esta frase na vis ao do contexto hist orico do gerenciamento de projetos, v e-se que somente parcialmente verdadeira. N povoado o passado, ela e ao s o de desastres e falhas e es foram feitas. Mas n verdade que ao n muitas grandes realizac o ao e ao conhec e-las, estamos condenados a repetir seu sucesso. Muito pelo contr ario, como veremos adiante, ainda hoje projetos falham por n ao seguir a receita de sucesso de projetos anteriores similares. Por outro lado, a hist oria est a sim repleta de casos de projetos falhos, que n ao atingiram seus objetivos, numa raz ao muito maior do que os bem sucedidos. Analis a-los pode trazer luz sobre o que n ao o caminho para a melhoria cont deve ser feito. E conhecer a hist oria e nua nesta viagem de o de conhecimento. acumulac a

2.1

A hist oria do conhecimento em gerenciamento de projetos

o de repoPara entendermos melhor as pr aticas recomendadas pelo PMBOK, na sua func a importante entendermos suas sit orio do conhecimento da pross ao de gerente de projetos, e es e pr ra zes, a origem das suas recomendac o aticas. Para tanto, uma breve revis ao hist orica se faz necess aria. Esta revis ao ser a fortemente baseada nos trabalhos de Peter W. G. Morris em The Management of Projects (MORRIS, 1997).
1 Aqueles

que n ao se lembram do passado est ao condenados a repet -lo.

21

2.1.1

Antes de 1940

es antigas s Desde as civilizac o ao realizados grandes projetos, como as pir amides (ver gura 2.1) ou os aquedutos romanos. Estes primeiros projetos utilizavam uma quantidade enorme de o de poderes divinos pessoas, e envolviam toda a comunidade, como consequ encia da atribuic a a autoridade m axima do projeto e, ao mesmo tempo, seu patrocinador. Grandes obras militares gregas, romanas, persas ou chinesas se utilizavam largamente de trabalho escravo, que eram de poca a gura do respons propriedade do governo ou do empreiteiro. Percebe-se j a nesta e avel pela obra, como um arquiteto, que delegava o trabalho para empreiteiros, como no caso do Coliseum que foi constru do por quatro empreiteiras. Os contratos com as empreiteiras j a continham o do trabalho a ser realizado, o material a ser usado, as garantias e detalhes como a especicac a m etodo de pagamento. J a se tinha a consci encia da relev ancia dos prazos.

Figura 2.1: Pir amides de Giza, no Egito (EGYPTIAN. . . , 2008) As catedrais medievais, por sua vez, representam a domin ancia do sagrado sobre o mundano. Ao contr ario de super projetos anteriores, n ao se dava import ancia ao tempo necess ario o destas obras, levando at es para serem completadas (ver gura para a realizac a e mesmo gerac o 2.2). Entre os s eculos 15 e 17 o n umero de grandes projetos aumentou, com o surgimento da engenharia como ci encia. De novo era enfatizado a import ancia dos prazos nos projetos. O arquiteto trabalhava n ao s o como projetista, mas como estimador, comprador, organizador, ins es comerciais se sosticavam, as transac es petor e respons avel nanceiro. Conforme as relac o o contratuais se tornavam parte importante de todo projeto. o dos projetos de engenharia aumentaram ainda mais. Nos s eculos 17 e 18 a sosticac a

22

Figura 2.2: York Minster, catedral de York, Inglaterra (CASTLES. . . , 2008) Aqueles que constroem os projetos agora estavam organizacionalmente e contratualmente separados daqueles que projetavam e estimavam seu trabalho. importante notar que, de todas as a reas que se utilizam das t E ecnicas de gerenciamento aa rea de construc o e engenharia civil. Mas o de projetos modernas de hoje, a mais antiga e a reas desenvolvimento da ci encia do gerenciamento de projetos foi realizado principalmente nas a es para de defesa e aeroespacial como veremos adiante, e depois trazido de volta suas contribuic o rea de construc o. aa a Entre a metade do s eculo 19 e a metade do s eculo 20, viu-se o orescer de uma nova es como arranhaera industrial, com avanc os em tecnologias relacionadas. Grandes construc o gua e esgoto, c eus, ferrovias (ver gura 2.3), usinas hidrel etricas, sistemas de tratamento de a o em massa como a do ac entre outros, junto com novas ind ustrias de produc a o, do petr oleo, o, m petroqu mica, farmac eutica, energia, telefonia, de aviac a edica e outros setores. poca era baixo. Esta era a Era do empreendedor, do O envolvimento do governo nesta e capitalista. Tanto as minas quanto ferrovias e empresas de telefonia eram todas privadas. O ca es eram simples. As primeiras teorias de gerenciamento pital era abundante e as regulamentac o cient co, com autores como Weber, Taylor, Gilbreth e Gantt, enfatizavam regras simples de o e organizac o. administrac a a A escola cient ca deu origem a duas t ecnicas de gerenciamento de projetos. O gr aco de barras Gantt, produzido por Henry Laurence Gantt para o governo dos EUA para o gerencia-

23

Figura 2.3: Trabalhadores de ferrovias no nordeste de Utah, 1869 (RAILROADS. . . , 2008) o do Frankford Arsenal em 1917. E o n mento da produc a ao t ao famoso Harmonygraph criado ltimo e o precursor das t por Adamiecki por volta de 1896 na Pol onia. Este u ecnicas de gerenciamento de redes que caram famosas nos anos 60 atrav es do CPM (Crtitical Path Method) e do PERT (Program Evaluation and Review Technique). Outro precursor das redes foi a an alise es e do caminho, desenvolvido por Wright em 1918 como uma forma de decompor as relac o express a-las como formas causais estatisticamente. No nal dos anos 20, foi desenvolvido por Procter and Gamble o conceito de gerenciamento de produtos. O gerenciamento de produtos era a pr atica de fazer com que um gerente fosse respons avel pela propaganda, planejamento e controle de um produto. Como em gerenciamento o entre diversas a reas funcionais da de projetos, j a era enfatizado a import ancia da integrac a empresa. Durante os anos 30, a divis ao de materiais da US Air Corps comec ou progressivamente a mover-se para uma estrutura de escrit orio de projetos. Ao mesmo tempo, algumas empresas como a Exxon criaram a gura do engenheiro de projeto, um engenheiro que acompanhava o poca a estrutura organizacional processo atrav es dos diversos departamentos funcionais. Nesta e que prevalecia era a piramidal ou funcional, mas em 1937, Urwick, da escola de Fayol de o, edita um livro onde Gulick escreve um artigo que prop administrac a oe o papel de coordenador, reas funcionais. Esta e a primeira aparic o da que administraria as tarefas envolvendo diversas a a o horizontal no meio acad organizac a emico.

24

2.1.2

A segunda guerra mundial

es militares tem uma estrutura muito parecida com a de um projeto. Elas norOperac o malmente t em objetivos claros, precisam de planejamento cuidadoso, dependem de uma boa o e controle. lideranc a, comunicac a Na segunda guerra mundial, viu-se o surgimento da ci encia como grande aliada no geren es. Apesar disto, viu-se poucos dos mecanismos ciamento de um grande n umero de operac o formais e t ecnica que hoje encontramos no gerenciamento moderno. es importantes para o estudo do No entanto, a segunda guerra mundial deu tr es contribuic o gerenciamento de projetos moderno, a saber: a Pesquisa Operacional, o Dia D e o Manhattan Project. Pesquisa Operacional a coleta e analise de informac es do cotidiano usando princ A Pesquisa Operacional e o pios o de processos. Foi muito utilizada para a otimizac o do trabalho e cient cos para a otimizac a a log stica durante a segunda grande guerra. O Dia D o de invas O Dia D foi uma enorme ac a ao coordenada em v arias frentes (ver gura 2.4), que exigiram um enorme planejamento, tinha um objetivo bem denido e um Comandante Supremo. Mas apesar destas caracter sticas, utilizou-se de t ecnicas tradicionais, sem grandes es para o gerenciamento de projetos moderno. contribuic o O Manhattan Project O desenvolvimento da primeira bomba at omica foi um dos maiores projetos industriais de pesquisa j a realizados. Ele envolveu 600000 pessoas, custou 2 bilh oes de d olares, era de alto risco e grande complexidade. Quando o projeto em 1942 formalmente teve in cio, a teoria f sica de como controlar uma o nuclear em cadeia ainda n reac a ao era completamente compreendida. Somente quantidades microsc opicas de material radioativo estavam dispon veis. Em 1944, dois anos e meio depois, grandes usinas de beneciamento de material radioativo, e as duas bombas, j a estavam constru das. Tudo isso foi realizado sobre grande segredo e autoridade direta do presidente

25

Figura 2.4: Rotas de invas ao na Normandia (NORMANDY. . . , 2008) Roosevelt. o de todos o fato de a A ess encia do projeto foi a urg encia e a incerteza. Era preocupac a Alemanha nazista estar no caminho de criar sua pr opria bomba, e mesmo n ao compreendendo o nuclear, era consenso o fato de que os maiores desaos completamente os princ pios da reac a o da bomba eram organizacionais e de engenharia. para a construc a

2.1.3

Os anos 50, o desenvolvimento do gerenciamento de sistemas

Nos anos 50, tanto as t ecnicas CPM quanto PERT foram desenvolvidas, e o gerenciamento de sistemas se torna um jarg ao comum, principalmente pela necessidade de desenvolvimento de aeronaves e m sseis de longo alcance em curt ssimo espac o de tempo pela USAF (US Air Force). Em 1950, com a guerra da Cor eia, houve um aumento da necessidade de bombardeiros o entre engenharia e produc o. B47. Este aumento levou a necessidade de melhor coordenac a a Como resultado, projetos conjuntos foram criados, e em 1952 isto j a era comum. Com a ameac a de m sseis intercontinentais contendo ogivas nucleares em posse da antiga o de coordenar os esforc o Uni ao Sovi etica, foi criado um grupo especial com a func a os na criac a o coordenar os esforc de contra medidas. Este grupo teria como func a os de v arios grupos no projeto do m ssil Atlas (ver gura 2.6). Um comit e dirigido por John von Neumann emitiu um o mais cr relat orio que considerava esta coordenac a tica ao sucesso do projeto do que qualquer

26

Figura 2.5: Dispositivo nuclear Jumbo sendo posicionado para o teste Trinity em Alamogordo, Novo M exico (NEIGHBORHOOD. . . , 2008)

27

diculdade t ecnica.

Figura 2.6: Primeiro lanc amento do m ssil Atlas do Cabo Canaveral em 1957 (DECEMBER. . . , 2008) poca j Nesta e a se v e a necessidade da ger encia do projeto de um produto como uma enti nica, desde o projeto, passando pelo implementac o at poca, e dade u a e seu uso. Mas j a nessa e em projetos subseq uentes, v e-se o surgimento de pr aticas n ao t ao boas, como a excessiva burocracia e padr oes, enfatizando o processo de gerenciar outros e n ao o de se fazer a engenharia o por si mesmo. Pior ainda, como quem especicava o trabalho n e integrac a ao trabalhava em conjunto com quem produzia, o ambiente para requisitos irreais ou inferiores estava congurado. O projeto Atlas foi o precursor da t ecnica de compress ao de tempo do in cio de atividades dependentes de forma concorrente, e n ao seq uencial como era at e ent ao. O uso desta t ecnica nfase na melhora das t aumenta o risco do projeto, e foi dada e ecnica de controle de qualidade dos fornecedores contratados. o dos departamenMais do que o programa Atlas, o programa Polaris aumentou a orientac a tos por projetos. Tamb em fez surgir uma nova t ecnica de ger encia de projetos, o PERT.

28

Um time formado por gerentes de projeto da marinha americana e os consultores de gerenciamento Booz, Allen & Hamilton e a Lookhead Corporation levantaram os seguintes requisitos o de um novo sistema de controle de projetos: para a criac a deve conter uma estimativa para cada atividade o de como algumas atividades podem envolver incertezas, deve conter tamb em a func a o da probabilidade do tempo de conclus distribuic a ao. conhecimento preciso da ordem das atividades. Al em das t ecnicas de rede desenvolvidas atrav es do PERT, conceitos como o do caminho cr tico, como sendo o caminho da seq uencia de eventos que determina o prazo do projeto, foram poca. identicados nessa e rea com informac es gerenciais integradas T ecnicas como a de se ter a sala de guerra, uma a o poca, e tamb de todos os projetos em andamento, surgem nessa e em reuni oes semanais dos gerentes de cada projeto, onde informam dados sobre o andamento das atividades. Medir o desempenho planejado com o real se torna um dos principais objetivos. Interessante notar que caminhos diferentes levam a resultados diferentes. No mesmo per odo o que foi desenvolvido o PERT, o CPM foi desenvolvido por Du Pont na ind ustria de construc a muito similar ao PERT, ambos usam redes e setas para representarem atividades, civil. O CPM e o civil e uma ind mas a construc a ustria muito diferente da ind ustria de pesquisa militar, sendo a raz o suas tecnologias e processos muito bem conhecidos. Esta e ao da falta de preocupac a com a probabilidade de sucesso de uma atividade. Tamb em por esta raz ao viu-se nos primeiros o maior no CPM com o custo das atividades, j desenvolvimentos uma preocupac a a que o ramo o e um ramo comercial competitivo. da construc a

2.1.4

Os anos 60, Apollo e a d ecada do gerenciamento de sistemas

o de John F. Kennedy, Robert S. McNamara recebe o cargo de Secret Com a eleic a ario da Defesa, e com ele uma s erie de reformas no processo de gerenciamento interno da USAF s ao nfase no planejamento e denic o de contratos, controle de orc executadas. Grande e a amento e requisitos, controle integrado de log stica e qualidade, e o uso da Estrutura Anal tica do Projeto o com fornecedores. (Work Breakdown Structure) como padr ao na comunicac a Muitas destas t ecnicas foram aplicadas nos programas da NASA, e atingiram grande popularidade atrav es do programa Apollo.

29

Desde muito cedo a NASA j a era consciente das deci encias do uso do PERT para controle de custos. Ap os estudos, passou a utilizar a EAP como forma de controle de custos, com nfase no controle de marcos principais e interfaces entre fornecedores. No entanto, depois e de problemas com a quantidade de formas diferentes com que era apresentado os relat orios de acompanhamento do custo do projeto, foi desenvolvido o sistema de Valor Agregado (Earned Value system), que se tornou um item importante no conjunto de ferramentas do gerente de projetos. considerado na academia, no mundo dos neg O projeto Apollo e ocios e pelo p ublico comum o paradigma do gerenciamento moderno de projetos. Pela sua complexidade, uma grande import ancia foi dada no controle de interfaces entre sistemas. Como sabemos, o projeto Apollo foi um grande sucesso. Mas isso n ao implica que n ao o a seus custos, foram experimentadas toda a sorte de problemas com seus prazos. J a em relac a es, e o por ser um projeto governamental na fase da corrida espacial, n ao teve grandes restric o poca o total de 25,5 bilh projeto custou na e oes de d olares.

2.2
2.2.1

A curta hist oria da engenharia de software

Pr e-hist oria

o n Os pioneiros na hist oria da computac a ao tinham um computador para si. Tinham que escrever seus programas e execut a-los na sala de processamento. O software tinha um custo o espec muito baixo se comparado com o custo do hardware, e todo hardware era de aplicac a ca e substitu do praticamente a cada dois anos, o que fazia necess ario se reescrever todo c odigo. A necessidade de se reescrever o c odigo a cada mudanc a de hardware fez surgir as primeiras linguagens de alto n vel, como FORTRAN, COBOL e ALGOL. Os fornecedores de hardware normalmente forneciam o software gratuitamente, j a que o hardware n ao funcionaria sem o software. O supervisor de Barry Boehm mostrou-lhe o computador ERA 1103 que ocupava uma grande sala, e disse-lhe, em seu primeiro dia no trabalho: Now listen. We are paying $600 an hour for this computer and $2 an hour for you, and I want you to act accordingly.2 (BOEHM, 2006)
Agora escute. N os estamos pagando US$600 a hora por este computador e US$2 a hora por voc e, e eu quero que haja de acordo.
2 Traduc o: a

30

poca. O que era bem de acordo com a economia da e o de reuso aos poucos surgia, com pequenos grupos de empresas e acad A noc a emicos o do que viria a ser mais tarde o movimento trocando software gratuito entre si, numa pr e-gestac a de software livre.

2.2.2

Os anos 50

poca foi o desenvolvimento do Semi-Automated O projeto de software mais ambicioso da e Ground Environment (SAGE) para o sistema de defesa canadense e norte-americano. Nesta poca, a metodologia de desenvolvimento de software era uma c e opia do que era a metodologia o, validac o e testes (ver de desenvolvimento de hardware, com m etodos formais de especicac a a gura 2.7).

Figura 2.7: Processo formal de desenvolvimento do projeto SAGE

2.2.3

Os anos 60

o do software e diferente da natuNos anos 60 foi-se percebendo que a natureza da produc a muito mais f o do hardware. E es de um software reza da produc a acil corrigir todas as instalac o defeituoso, basta corrig -lo e realizar c opias a um custo muito baixo, diferente de um hard-

31

es na linha de montagem e substituic o mec ware que necessitaria de alterac o a anica em cada o. Por este motivo, muitas empresas comec o instalac a aram a adotar o estilo de programac a codicar-e-corrigir (code-and-x), ao inv es de m etodos mais formais e caros. o e manutenc o de software n Percebeu-se tamb em que toda atividade de produc a a ao poderia o de hardware. O software e invis ser modelada atrav es dos modelos de manutenc a vel, n ao dif tem peso nem ocupa espac o, mas comec a a ter um alto custo. E cil dizer se um projeto de software est a dentro do prazo, e se voc e adiciona mais pessoas ao projeto, ele car a mais atrasado (como j a dizia Brooks). Um software tem muitos estados, modos, e caminhos para serem testados. Winstow Royce, num artigo cl assico em 1970, disse: In order to procure a $5 million hardware device, I would expect a 30 page specication would provide adequate detail to control the procurement. In order to procure $5 million worth of software, a 1500 page specication is about right in order to achieve comparable control.3 (ROYCE, 1987) o foi Um outro grande problema com os m etodos de engenharia aplicados a computac a que, no ritmo de crescimento da demanda por prossionais, comec ou a faltar m ao de obra especializada, e os grandes projetos comec aram a contratar pessoas menos especializadas e at e reas, mesmo graduados em ci de outras a encias humanas e biol ogicas. Para estes prossionais o o codicar-e-corrigir era bem adequado, j estilo de codicac a a que eles podiam utilizar de sua natural criatividade, mas com isso aumentou a quantidade de c odigo espaguete e surgiu a gura do cowboy do teclado, aquele que consegue com seu c odigo incompreens vel e muitas horas poca a subcultura hacker. extras salvar projetos atrasados. Tamb em surgia na mesma e o codicar-e-corrigir, como o Mas alguns projetos n ao sucumbiram ao modo de produc a projeto do sistema operacional IBM OS-360 e os projetos Gemini, Mercury e Apollo da NASA. Todos estes foram trabalhados de acordo com as mais modernas ferramentas de engenharia da poca, e obtiveram grande e xito, apesar de alguns atrasados ou a um grande custo. e o em que se encontrava a ind A situac a ustria de software levou a duas confer encias em 1968 poca, que e 1969 da NATO Science Committee com v arios pesquisadores e especialistas da e ocialmente deu origem a Engenharia de Software. Foram estabelecidas as pr aticas que deveriam orientar as ag encias governamentais e empresas, e que metodologias mais disciplinadas deveriam surgir para suprir a demanda de projetos de maior escala.
3 Para adquirir um dispositivo de hardware de US$5 milh o com 30 p oes, eu esperaria que uma especicac a aginas

o. Para adquirir um software no valor de US$5 milh provesse o detalhamento adequado para controlar a aquisic a oes, o de 1500 p necess uma especicac a aginas e aria para conseguir controle compar avel.

32

2.2.4

Os anos 70

o ao modo de programar codicar-e-corrigir, surgindo m Houve uma reac a etodos mais orga o, sintetizando o que havia de melhor do desenho e produc o de hardware, nizados de produc a a es exigidas para a produc o de software. Este cuidado pode ser exemplicom as modicac o a ` ACM Communications: Go To Statement Considered Harmful cado pela carta de Dijkstra a (DIJKSTRA, 1968), e um artigo de B ohm e Jacopini (B oHM; JACOPINI, 1966), que mostravam que programas seq uenciais sempre podiam ser escritos com apenas desvios condicionais e o Estruturada. lac os, iniciando o movimento da Programac a O resultado deste movimento por maior disciplina resultou em duas vertentes: uma de o, que focava na corretude do programa via prova matem m etodos formais de programac a atica o do programa usando m ou na construc a etodos do c alculo; e a outra menos formal, usando o estruturada e t programac a ecnicas gerenciais. o estruturada trouxe outras t O sucesso da programac a ecnicas e melhorias, como os princ pios o da superf da modularidade, coes ao, reduc a cie de contato, e tipos de dados abstratos. o do modelo cascata de desenvolvimento (ROYCE, Um grande marco hist orico foi a criac a o seq es iterativas 1987). Este modelo enfatizava a produc a uencial do software, com vericac o o de erros e o custo da correc o tardia (ver gura fechadas em cada fase para evitar a propagac a a 2.8).

Figura 2.8: Modelo cascata de desenvolvimento de software

33

Outro efeito positivo de processos mais r gidos foi o est mulo a processos quantitativos mais efetivos na engenharia de software. No entanto, no m dos anos 70 os problemas voltaram a crescer, com o excesso de formalidade e o uso de processos seq uencias. M etodos formais t em problemas com a escalabilidade e a usabilidade pela maioria dos desenvolvedores m edios. O modelo seq uencial em cascata se mostrou uma metodologia pesada, orientado a documentos, lenta e cara.

2.2.5

Os anos 80

A crise de software se mostra com forc a total. Projetos ultrapassam seus custos, h a danos nanceiros e at e perdas de vidas por falhas em softwares. Uma s erie de iniciativas, utilizandose dos resultados dos m etodos quantitativos empregados anteriormente, comec aram a atacar os principais pontos de falhas, como por exemplo o alto custo de testes tardios ou o custo pela falta de requisitos claros. A falha pelo n ao cumprimento de t ecnicas e metodologias j a consagradas fez com que o Departamento de Defesa norte-americano nanciasse o projeto do CMU Software Engineering Institute para o desenvolvimento de um modelo de maturidade de software, o Capability Maturity Model for Software (SW-CMM), e desenvolvesse m etodos para determinar a maturidade o. Este foi fortemente inuenciado pelas experi de uma organizac a encia da IBM no desenvol o de ser independente de vimento de seus projetos, e apesar de ter sido criado com a intenc a metodologias, tem uma forte tend encia seq uencial, como o modelo de desenvolvimento em cascata. es fez com que muitas empresas investissem no modelo de matuO medo de perder licitac o ridade, e muitas relataram benef cios devido ao menor retrabalho. Isto fez com que o modelo de maturidade ganhasse popularidade. Os anos 80 viram uma s erie de melhorias na produtividade utilizando-se de sistemas es o a objetos, estac es de trabalho poderosas e pecialistas, linguagens de alto n vel, orientac a o o visual. Todas elas foram colocadas em perspectiva no trabalho de Brooks No Silprogramac a ver Bullet (BROOKS, 1995), onde ele separa o que s ao tarefas acidentais do desenvolvimento o, do que s de software, tarefas estas repetitivas que podem ser evitadas atrav es da automac a ao as tarefas essenciais, aquelas que s ao necess aria e que precisam de trabalho intelectual, bom o. Brooks defende em seu trabalho como candidatos para enfrentar as disenso e colaborac a culdades essenciais o uso de projetistas de software experientes, prototipagem, desenvolvimento evolucion ario e evitar o trabalho via reuso.

34

O reuso de componentes de software foram um dos maiores agentes do aumento da produtividade nos anos 80. O uso de softwares na infraestrutura (sistemas operacionais, bancos de dados) e ferramentas (construtores de interfaces com o usu ario) evitaram muito desenvolvimento e retrabalho.

2.2.6

Os anos 90

o O desenvolvimento orientado a objetos ganhou mais forc a, principalmente com a criac a o de arquiteturas e o desenvolvimento de padr oes de desenvolvimento, linguagens de descric a da Unied Modeling Language (UML). o no A cont nua expans ao da rede global de computadores acirrou ainda mais a competic a mercado de software, e com isso a mudanc a das metodologias de modelos seq uenciais para o. modelos concorrentes da engenharia de requisitos, desenho, e codicac a o de produtos cada vez mais iterativos fez com que o usu A criac a ario se tornasse cada vez o de modelos seq mais exigente e imprevis vel, tornando mais dif cil a manutenc a uenciais de desenvolvimento. O modelo espiral de desenvolvimento (BOEHM, 1986) foi criado com o intento de controlar o de software. Foi adotado tamb o processo concorrente de construc a em pela Rational/IBM no seu Rational Unied Process, e como tal foi utilizado em um grande n umero de projetos. Outra forma de desenvolvimento concorrente que contribuiu muito nos anos 90 foi o desenvolvimento de software de c odigo aberto. Das ra zes da cultura hacker dos anos 60, estabeleceu o da Free Software Foundation e o GNU General Public sua presenc a institucional com a criac a es foram criadas as condic es License por Richard Matthew Stallman. Com estas contribuic o o o de in teis e gratuitos, como o compara o surgimento e evoluc a umeros pacotes de software u pilador C GCC e o editor Emacs. Outros grandes acontecimentos no mundo do software livre o do n o do World Wide Web foram a criac a ucleo do Linux por Linus Torvald (1991), a criac a Consortium e o livro The Cathedral and the Bazaar (RAYMOND, 1999) com uma an alise concisa no movimento de software livre e suas consequ encias.

2.2.7

Os anos 2000

o da veloOs anos 2000 viram um aumento das tend encias dos anos 90, com a acelerac a o, nas organizac es, no ambiente competitivo cidade das mudanc as na tecnologia da informac a o o com o excesso de planejamento, e global. Estas mudanc as r apidas aumentaram a insatisfac a

35

o, documentac o e outros impostos por modelos de maturidade e contratos. especicac a a gil de desenvolvimento de softO in cio dos anos 2000 viram o surgimento do movimento a ware e diversas metodologias seguindo seus princ pios, com representantes como o Adaptative Software Development, Crystal, Dynamic Systems Development, Extremme Programming(XP), Feature Driven Development e o Scrum. Os maiores representantes deste movimento se encontraram em 2001 e escreveram o Agile Manifesto (MANIFESTO. . . , 2001), colocando quatro valores como preferenciais: Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.4 geis foi a XP, que se mostrou efetiva A mais conhecida e aplicada metodologia dentre as a em diminuir a curva de custo de mudanc as no tempo. Mostrou-se efetiva ao tratar projetos pequenos, com uma equipe bem treinada e requisitos que se alteravam rapidamente. geis se encaixam na necessidade de desenvolvimento de incrementos de acordo Os m etodos a o do maior valor para o usu com a priorizac a ario, e as mudanc as em suas prioridades. A fazer com que a tecnologia se adapte a ` s pessoas, e n tend encia e ao o contr ario. Isto se re o de produtos, com e nfase cada vez maior no valor ete cada vez mais nos crit erios de selec a agregado e usabilidade, ao contr ario do que se tinha antes, que era o crit erio do n umero de caracter sticas e o custo. Estas tend encias norteiam as prioridades na escolha de produtos e processos, estrat egias de propaganda e meios de sobreviv encia competitiva. a que Uma caracter stica dos novos produtos de software que os torna um grande desao e os requisitos n ao s ao mais pr e-especicados, mas emergem durante o uso e aprendizado por parte do usu ario. Estes requisitos seguem uma pir amide como a pir amide de necessidades de Maslow, onde ap os as necessidades b asicas s ao satisfeitas, novas e mais sosticadas necessi o dos riscos s dades surgem. Neste ambiente, processos adaptativos e orientados a diminuic a ao mais recomendados, ao inv es de processos com excessivo planejamento, processos em cascata,
4 Traduc o: a

es sobre processos e ferramentas. Indiv duos e interac o o. Software funcionando sobre extensiva documentac a o do cliente sobre negociac o de contratos. Colaborac a a Resposta a mudanc as sobre seguir um plano.

36

o e a otimizac o. Estudos de engenharia de software orientados modelos enfatizando a repetic a a ao valor agregado (JAIN; BOEHM, 2005) tentam hoje atacar estes novos desaos.

37

Figura 2.9: Tend encias de software (BOEHM, 2006)

38

A teoria por tr as da metodologia

3.1

A anatomia de uma metodologia

gil, se Antes de estudar com mais detalhes algumas metodologias representativas da linha a uma metodologia, seus termos e estrutura. Uma metodologia e faz necess ario denir o que e uma forma de trabalho organizada de um grupo de forma a produzir um resultado. Ou melhor, A methodology is the conventions your group agrees to1 (COCKBURN, 2001). Desta forma, ca evidente a caracter stica social de uma metodologia, e de que mesmo uma empresa pequena possui uma metodologia, mesmo que ela n ao esteja descrita em algum livro ou tenha recebido o certicadora. Algumas grandes empresas descrevem as suas o aval de uma grande instituic a xito em sua miss metodologias que obtiveram e ao, e estas se tornam populares, de forma a serem recebidas pelo p ublico como a forma correta de se obter o mesmo resultado. Mas como o tem seus pr es culturais, na maioria dos casos sua cada organizac a oprios valores e variac o o como descrita pelo grupo de origem em um outro grupo pode trazer resultados implantac a adversos.

3.1.1

Estrutura de uma metodologia

rea de desenvolviAlgumas estruturas se repetem em todas as metodologias, seja ela na a o ou literatura. Elas s mento de software, construc a ao (COCKBURN, 2001): o, quais as habilidades necess Pap eis. Quem voc e emprega, com qual func a arias. Habilidades. As compet encias necess arias para cada papel. Normalmente a habilidade de uma o e um produto do seu treinamento pelo seu talento. pessoa em sua func a Equipes. Os pap eis que trabalham juntos para obterem um resultado. Em um pequeno projeto, pode haver apenas uma equipe, mas em grandes projetos podem existir diversas equipes coordenadas.
1 Uma

as convenc es acordadas pelo seu grupo metodologia e o

39

T ecnicas. Os procedimentos que as pessoas realizam para cumprir suas tarefas. Atividades. Como as pessoas utilizam seu tempo. Planejando, programando, testando ou em reuni oes s ao exemplos de atividades. es Processos. Como as atividades trabalham juntas no tempo, com poss veis pr e e p os condic o entre atividades. Algumas metodologias t em seu foco em processos, em como o trabalho ui entre os membros do projeto. Produtos. O que o projeto constr oi. Alguns produtos podem ter um tempo de vida curto, ou mais longo que o pr oprio projeto. Marcos. Eventos que marcam o progresso ou m das atividades. Um marco tem duas caracter sticas: ocorre num instante do tempo e ou ocorre completamente ou n ao ocorre, nunca pode ocorrer parcialmente. es que uma equipe adota em relac o a ferramentas, produtos e pol Padr oes. As convenc o a ticas de trabalho. Qualidade. As caracter sticas desejadas para atividades e produtos. Valores da equipe. Muitos itens da metodologia trabalham de acordo com os valores da equipe. Uma equipe agressiva que valoriza retorno r apido trabalha de forma diferente do que uma que valorize estar com a fam lia e sair do trabalho no hor ario.

3.1.2

Tipos de metodologias

(MAIER; RECHTIN, 2000) categoriza as metodologias como sendo normativas, racionais, participativas ou heur sticas: es ou seq ncias de passos conhecidos por funciNormativas s ao aquelas baseadas em soluc o ue onar grac as ao uso de disciplina. Racionais s ao baseadas em m etodos e t ecnicas. o da soluc o. Participativas buscam o envolvimento do cliente na elaborac a a es aprendidas. Heur sticas s ao baseadas em lic o rea cresce, suas metodologias tendem a ir de heur Conforme o conhecimento em uma a sticas a normativas.

40

3.1.3

Escopo

o conjunto de atividades e pap O escopo de uma metodologia e eis que ela pretende incorporar (COCKBURN, 2001). Neste sentido, muitas metodologias de desenvolvimento de software s o est ao preocupadas em determinar os pap eis e atividades necess arios para o desenvolvimento o com as atividades comerciais, nanceiras e algumas vezes de c odigo fonte, sem preocupac a at e de recursos humanos necess arias para o projeto. O escopo de uma metodologia pode ser caracterizado em tr es eixos: cobertura do ciclo de vida, cobertura de pap eis e cobertura de atividades (ver gura 3.1).

Figura 3.1: As tr es dimens oes do escopo de uma metodologia (COCKBURN, 2001) A cobertura do ciclo de vida indica quando a metodologia comec a seu trabalho no projeto, e quando termina. A cobertura de pap eis refere-se a quais pap eis est ao sob o seu dom nio. A cobertura de atividades dene quais atividades est ao sob discuss ao. Sob este prisma, v e-se que denir o escopo de metodologias faz com que metodologias que a primeira vista parecem ser contradit orias na verdade apenas t em escopos diferentes. Algumas metodologias do in cio da hist oria da engenharia de software tinham um escopo muito pequeno, geis est talvez at e mesmo insuciente para o seu trabalho. As metodologias a ao preocupadas com o desenvolvimento de c odigo fonte e o que pode inuenciar de forma direta, enquanto es do PMBOK t as recomendac o em um escopo muito mais abrangente, como veremos mais

41

adiante.

3.1.4

Conceitos do desenho de metodologias

De acordo com Cockburn (COCKBURN, 2001), a discuss ao do desenho de metodologias o dos seguintes termos: tamanho da metodologia, cerim passa pela denic a onia e peso; tamanho do problema; tamanho do projeto; criticidade do sistema; precis ao; acur acia; relev ancia; toler ancia; visibilidade; escala; e estabilidade. Tamanho da metodologia. O n umero de elementos de controle na metodologia. Cada padr ao, um elemento produto, atividade, medida de qualidade e t ecnica descrita na metodologia e de controle. Cerim onia da metodologia. A precis ao e o intervalo de toler ancia da metodologia. Uma cerim onia muito grande implica em controles r gidos. Uma equipe pode escrever casos de uso em quadros brancos e revis a-los durante o almoc o, e outra pode preencher um formul ario com tr es p aginas e revis a-los numa reuni ao que durar a uma semana. Ambas est ao escrevendo casos de uso e os revisando, uma com mais cerim onia que outra. Peso da metodologia. O produto do tamanho pela cerim onia. O n umero de elementos de controle multiplicado pela cerim onia necess aria em cada um deles. o. As metodoloTamanho do problema. O n umero de elementos do problema e sua correlac a gias em geral se limitam a atacar problemas de um certo tamanho, especicado pelo seu autor, ou ent ao especicam meios do usu ario da metodologia de como adapt a-la. Tamanho do projeto. O n umero de pessoas cujo esforc os precisam ser coordenados. Criticidade do sistema. O dano causado por defeitos no produto do projeto. Cockburn (COCKBURN, 2001) classica a criticidade do projeto em perda de conforto, perda de pouco dinheiro, perda de muito dinheiro e perda de vidas. Precis ao. Qual a precis ao que se deseja obter de um determinado t opico. Alguns autores de metodologias desejam obter mais precis ao o mais cedo poss vel. Acur acia. Qual a corretude se deseja obter de um determinado t opico. A maioria das metodologias trabalham no sentido de obter modelos mais precisos e mais corretos com o passar do tempo. Relev ancia. Falar ou n ao sobre um determinado t opico.

42

tolerante a falhas em alguns dos seus elementos de Toler ancia. O quanto a metodologia e pouco tolerante a falhas, talvez por ser controle. Algumas metodologias, como a XP, e uma metodologia minimalista. Metodologias maiores tendem a ser mais tolerantes, com o progressiva do resultado. degradac a Visibilidade. Qu ao f acil um observador pode dizer se uma metodologia est a sendo seguida. Alguns padr oes, como o ISO9001 foca em problemas de visibilidade. Como adicionar geis como um grupo t visibilidade em um projeto adiciona custos, as metodologias a em nfase em visibilidade. pouca e nica entidade. Algumas meEscala. Quantos tens s ao colocados juntos representando uma u o do todo, para combater o todologias criam entidades agrupadas para melhor visualizac a problema do limite do n umero de artefatos que a mente humano consegue lidar simultaneamente. o a mudanc Estabilidade. Qual a capacidade de adaptac a as ambientais e de escopo. es deste cap Com as informac o tulo, temos melhor embasamento para analisar as metodolo geis e as pr gias a aticas do PMBOK, de forma mais clara e objetiva.

43

Um v oo r apido sobre as diversas metodologias

4.1

Extreme Programming

uma das ou a mais conhecida das metodologias a geis, muito Extreme Programming e bem documentada (ver (BECK; ANDREAS, 2004), (WAKE, 2001) e (JEFFRIES; ANDERSON; HENDRICKSON, 2000)) e bastante controversa. Criada pelo engenheiro de software norte-americano Kent Beck enquanto era o l der do projeto C3 (acr onimo para Chrysler Comprehensive Compensation). Em seu livro Extreme Programming Explained (BECK; ANDREAS, 2004), Kent Beck prop oe o retorno de algumas pr aticas que foram abandonadas para o desenvolvimento de soft o oral ao ware, por serem consideradas ing enuas ou impratic aveis. Enfatiza o uso da comunicac a o constante do inv es do uso de documentos, simplicidade no desenho do software, realimentac a es aprendidas e problemas encontrados, tanto pelos participantes do projeto sistema com as lic o quanto pelo cliente. A metodologia XP envolve as seguintes pr aticas: O Jogo do Planejamento. O planejamento do projeto se parece com um jogo de mesa, onde o cliente determina as prioridades e os analistas t ecnicos determinam as estimativas. es. Deve ser colocado um sistema em produc o simples o mais r Pequenas iterac o a apido poss vel, e liberar novas vers oes em ciclos curtos. Met afora. O desenvolvimento deve ser guiado por uma hist oria simples compartilhada por todos de como o sistema funciona. Desenho simples. O sistema deve ser desenhado o mais simples poss vel. Qualquer complexidade extra deve ser removida no momento que for descoberta. Testes. Os programadores devem escrever testes unit arios continuamente, que precisam rodar

44

sem falhas para o desenvolvimento continuar. Clientes devem escrever testes demonstrando que uma caracter stica foi terminada. Refatoramento. Os programadores devem reestruturar o sistema continuamente, removendo o, a simplicidade ou adicionando exibilic odigo duplicado, melhorando a comunicac a dade. o em pares. Todo c nico Programac a odigo deve ser escrito por dois programadores em um u garantido a troca de experi computador. Com isso e encias, a revis ao constante do c odigo e a transfer encia do modelo t acito do projeto. Propriedade comum. Todos podem mudar qualquer parte do c odigo a qualquer momento. Proporciona a melhoria cont nua. o cont Integrac a nua. O sistema deve ser integrado e testado muitas vezes num mesmo dia, a completada, utilizando-se os testes unit cada vez que uma tarefa e arios escritos. Semana de 40 horas. A equipe deve ter como meta trabalhar 40 horas por semana. Nunca deve realizar horas extras duas semanas consecutivas. Com isso garante-se a qualidade e o moral elevado da equipe. Cliente presente. Um representante do cliente deve fazer parte da equipe, em tempo integral, para responder as quest oes que surgirem. o. Os programadores devem escrever o c Padr oes de codicac a odigo de acordo com regras que o no projeto. enfatizem a comunicac a ` luz dos conceitos de metodologias de software elaboradas Ao se analisar as t ecnicas do XP a o pessoal por Cockburn, v e-se que a metodologia XP constr oi um ambiente onde a comunicac a enfatizada, e os tempos entre as quest e oral e oes e as respostas s ao curtos. O custo para o e muito baixo. O cliente tamb a descoberta de uma informac a em tem uma resposta r apida o de suas decis o nos prazos e custos do projeto. quanto a implicac a oes de implementac a o em pares XP usa a excelente capacidade humana em se comunicar, atrav es da programac a e retorno r apido do cliente, para compensar a tend encia humana em cometer erros. necess uma metodologia muito disciplinada. E Por mais controverso que parec a, XP e ario alta ader encia a padr oes de c odigo e de desenho, testes unit arios que devem ter sucesso 100% o, trabalho em pares, manter o c do tempo, testes de aceitac a odigo simples e refatoramento agressivo.

45

Dois pontos s ao considerados os mais controversos na metodologia XP: a falta de docu o, v mentos e o uso de apenas pequenas equipes. No caso da falta de documentac a e-se que XP enfatiza apenas o objetivo principal da equipe, a entrega do sistema funcionando, e n ao no es e novas vers o seria necess vos projetos futuros, como alterac o oes, onde a documentac a aria. Neste caso, o autor conta com o conhecimento t acito da equipe sendo mantido entre projetos, ou melhor dizendo, o capital humano da empresa. No caso de pequenas equipes, se levarmos em conta que uma equipe pequena com uma metodologia leve consegue produzir tanto quanto uma equipe grande com uma metodologia pesada, vemos que uma equipe pequena pode atacar problemas de tamanho razo avel e ser muito eciente para a maioria dos casos. Usando os crit erios estabelecidos no cap tulo 3, vemos toda a estrutura de uma metodologia presente, com pap eis, t ecnicas, atividades, processos, padr oes, valores e outras. Podemos classicar a metodologia XP como sendo do tipo heur stica e participativa, pois foca em pro o da equipe, e na participac o constante do cliente cessos para facilitar a capacidade de adaptac a a o de no projeto. O seu escopo compreende as principais atividades necess arias para a produc a o da equipe, deixando de lado preocupac es como t o software e coordenac a o ecnicas de selec a o de pessoal, gerencia nanceira e controle de contratos de terceiros. Como tal e capacitac a xito. A foi utilizada em ambientes com requisitos inst aveis e pequenas equipes, com grande e metodologia esforc a-se em ser pequena, com baixa cerim onia, por isso mesmo uma metodo o oral e o conhecimento t logia leve. Por trabalhar somente com a comunicac a acito da equipe, sempre aconselhada para uso com equipes entre tr e es a uma d uzia de pessoas (o suciente para manter todos numa mesma sala). Fazendo uma reex ao, podemos questionar sua capacidade em atacar problemas com alta criticidade, envolvendo a perda de altas somas em dinheiro ou de vidas, sem o uso de processos mais formais. Uma outra cr tica seria no sentido de ser o a algumas fraquezas humanas, j pouco tolerante com relac a a que a metodologia se baseia na o de testes automatizados e refatorac o agressiva, atividades que sofrem resist construc a a encia a o da metodologia em serem adotadas pelo programador m edio, um grande desao para a adoc a si.

4.2

Crystal Clear

o nome de uma fam Crystal Clear, mais do que uma metodologia, e lia de metodologias elaboradas por Cockburn e descritas nos livros Agile Software Development (COCKBURN, 2001) e Crystal Clear (COCKBURN, 2005). O autor valoriza o conceito de que toda metodoo logia de desenvolvimento de software deve estabelecer um ambiente favor avel para a produc a do seu produto. S ao estabelecidos sete princ pios a serem seguidos, sendo os tr es primeiros

46

obrigat orios, e os demais apenas auxiliares para manter o projeto neste ambiente seguro de desenvolvimento. Os sete princ pios s ao: Entregas frequentes. Segundo o autor, s ao tantas as vantagens de entregas freq uentes que e intrigante pensar que alguns projetos fac am diferente. O intervalo entre entregas n ao deveria ultrapassar quatro meses, com os seguintes benef cios: O patrocinador tem retorno real e tang vel sobre o progresso da equipe. o que ele realmente O usu ario tem a possibilidade de descobrir se o que ele pediu e quer e ter isto reetido no projeto. Os desenvolvedores mant em o foco, evitando momentos de congelamento por indecis ao. A equipe pode depurar seu processo de desenvolvimento e ter sua moral elevada pelo sucesso da entrega. o reexiva. A equipe deve se reunir periodicamente e rever seus processos e h Evoluc a abitos de trabalho. A periodicidade deve tamb em ser discutida pelo grupo, uma vez por semana, es no rumo do por m es ou duas vezes por entrega, o que for melhor para permitir correc o projeto. o osm o osm o de Comunicac a otica. O autor se refere a comunicac a otica como sendo a criac a o ocorra entre os membros da equipe de forma um ambiente tal que o uxo de informac a o imquase acidental, como ao ouvir a discuss ao de terceiros e perceber uma informac a portante para o projeto, ou uma d uvida da qual se sabe a resposta. Isto normalmente e conseguido ao se alocar a equipe num mesmo ambiente. Seguranc a pessoal. Todas as pessoas do projeto devem se sentir seguras em dizer a verdade, sem temer repres alias. Poderem dizer para o colega que o seu desenho do projeto e ruim, e para seu chefe que as estimativas que deu est ao erradas em 50%. Com este tipo de seguranc a, segundo o autor, o projeto tem maiores chances de descobrir o que est a causando danos e corrig -lo o mais cedo poss vel. necess a tarefa priorit Foco. E ario ter-se bem claro qual e aria e n ao ser interrompido. Leva-se horas para recuperar o uxo de pensamentos ao ser interrompido por colegas, telefonemas es ou reuni oes. Todas as pessoas do projeto devem ter um per odo por dia sem interrupc o e v arios dias na semana sem terem de trocar de tarefas, para poderem ser realmente produtivos.

47

Acesso f acil aos usu ario experientes. Acesso aos usu arios proporciona a equipe: Um lugar para fazer entregas e testes freq uentes. Resposta r apida quanto a qualidade do produto. Resposta r apida quanto a qualidade do desenho do produto. Requisitos sempre atualizados. o e integrac o frequente. Infraestrutura com testes automatizados, gerenciamento de congurac a a o destes tr A combinac a es elementos trazem qualidade de vida aos desenvolvedores. Eles podem adicionar funcionalidades sem ter o medo de quebrar algo que funcionava, pois t em os testes na retaguarda, garantindo a consist encia do sistema. Se algo der errado, o s podem voltar a vers ao anterior. E erros de integrac a ao detectados no momento em que mais f rea do c e acil encontrar a a odigo onde o erro pode existir. uma vis Esta e ao bem supercial dos m etodos e valores da metodologia Crystal, mas com es j o. Todas estas informac o a podemos fazer uma an alise a luz dos nossos crit erios de comparac a as estruturas de uma metodologia est ao presentes, mesmo que de forma bem informal. Pode nfase da metodologia na adaptac o e mos notar, da mesma forma que na metodologia XP, a e a o do cliente, ao inv participac a es de se basear em normas de trabalho, processos xos e repe o. Podemos com isso classic titivos e documentac a a-la como sendo participativa e heur stica. bem focado nas atividades principais do deO seu escopo tamb em, seguindo o modelo XP, e o a atividades secund senvolvimento de software, sem menc a arias. Quanto a crit erios de desenho da metodologia, v e-se que ela tenta ao m aximo ser uma metodologia pequena, com o baixa cerim onia, ou seja, uma metodologia leve. O autor descreve um arcabouc o de criac a geis, ao inv nica receita, a m de proporcionar com isso de metodologias a es de descrever uma u rea possa desenvolver a sua metodologia, com o peso ferramentas para que um praticante da a adequado para o tamanho do seu projeto, o tamanho do seu problema, e sua criticidade. Neste sentido, sua obra estabelece uma escala compreendendo o tamanho da equipe e a criticidade do sistema, onde conforme estes par ametros o praticante deve reetir sobre o uso de maior ou menor cerim onia, mas sempre procurando a quantia m nima e suciente. Ali as, o autor sempre coloca como fator decisivo para o sucesso de um projeto a reex ao constante sobre m etodos e processos de trabalho, sua melhoria cont nua, e a compreens ao e toler ancia com a natureza e fraquezas humanas.

48

4.3

Scrum

Em 1986, Hirotaka Takeuchi e Ikujiro Nonaka descreveram um novo m etodo para aumentar a velocidade e exibilidade do desenvolvimento de novos produtos. Eles compararam este novo m etodo hol stico com fases que se sobrep oem e com um time multifuncional ao rugby, onde o time como um todo tenta avanc ar, passando a bola para tr as e para frente. Em 1991, DeGrace e Stahl em Wicked Problems, Righteous Solutions referem-se a este m etodo como Scrum, um termo do rugby. Em 1990, Ken Schwaber usou estes m etodos em sua empresa, Advanced Development Methods, e ao mesmo tempo, Jeff Sutherland desenvolveu t ecnicas parecidas na empresa Easel Corporation. Em 1995 Sutherland e Schwaber apresentaram em conjunto um artigo na OOPSLA95 onde descreviam suas experi encias, e no ano seguinte trabalharam juntos o do livro Agile Software Development with Scrum (ver (SCHWABER, 2004)). na produc a um esqueleto que inclui uma s A metodologia Scrum e erie de pr aticas e pap eis. O pa o de ScrumMaster que e respons pel principal e avel por manter o processo e tem outras res quem representa o ponsabilidades semelhantes a um gerente de projetos. O Product Owner e patrocinador, e o Team inclui os desenvolvedores. produzido um incremento de um produto de Durante o sprint, um per odo de 15-30 dias, e software poss vel de ser entregue ao usu ario. O conjunto de funcionalidades que v ao constar uma lista de funcionalidades priorizadas do neste sprint s ao descritas no product backlog, que e decidido num sprint planning meeting. produto. Quais itens do backlog v ao constar no sprint e Durante esta reuni ao, o Product Owner informa a equipe que itens deseja que sejam inclusos ent no pr oximo sprint, a equipe ent ao negocia prazos e e ao congelado os requisitos durante o sprint (ver gura 4.1).

Figura 4.1: Processo da metodologia Scrum (SCRUM, 2008)

49

A metodologia Scrum procura criar equipes auto-adaptativas, encorajando equipe co-alocadas o verbal. Um princ o recoe comunicac a pio considerado fundamental na metodologia Scrum e nhecimento de que o cliente pode mudar de id eia sobre o que precisa a qualquer momento, e que estas mudanc as n ao s ao facilmente tratadas pelo m etodo tradicional de planejamento. Ent ao, tenta focar em promover a habilidade de responder rapidamente as mudanc as. As pr aticas gerais do Scrum s ao: O cliente deve fazer parte da equipe de desenvolvimento. geis, Scrum tamb Como muitas metodologias a em advoga entregas freq uentes do software produzido ao cliente. o devem ser desenvolvidos pela equipe. Planos de gerenciamento de riscos e mitigac a Deve ser feito em todos os est agios e ter seu comprometimento. res Transpar encia no planejamento e no desenvolvimento, todos devem saber quem e respons pons avel e quando e avel. Reuni oes freq uentes com o patrocinador do projeto, para monitorar o progresso. Nenhum problema deve ser varrido para debaixo do tapete. Ningu em deve ser penalizado por reconhecer um erro ou desvio do projeto. desmotivado o uso de horas extras. Trabalhar mais horas n E ao signica produzir mais. O Scrum estabelece as atividades, pap eis, processos e demais tens da estrutura de sua metodologia. Como as metodologias anteriores, podemos agora notar como um padr ao a tend encia geis em serem do tipo participativas e heur de todas as metodologias a sticas, o Scrum n ao sendo o. Tamb simplicado, mantendo-se no subconjunto das atividades uma excec a em seu escopo e principais necess arias ao desenvolvimento de software. A metodologia tem poucos elementos uma metodologia leve. N de controle e baixa cerim onia, e por consequ encia e ao estabelece o orientada a testes como obrigat t ecnicas como o refatoramento e programac a orias, mas v e nestas uma boa pr atica, e aconselha fortemente seu uso. Exige disciplina e descreve uma receita mais clara de como deve ser o dia a dia do projeto, colocando como item principal da o eciente. metodologia a comunicac a

50

4.4

Feature Driven Development

uma metodologia incremental e iterativa, desenvolFeature Driven Development ou FDD e vida por Jeff De Luca durante um projeto para um grande banco em Singapura, envolvendo 50 o. Une uma s pessoas e com 15 meses de durac a erie de boas pr aticas reconhecidas pela ind ustria para realizar o desenvolvimento de software de uma forma consistente, no prazo, e orientado ` s caracter o da metodologia a sticas que o cliente acredita mais importantes. A primeira menc a foi feita na obra Java Modeling in Color with UML (COAD; LEFEBVRE; LUCA, 1999) e posteriormente foi lanc ado um livro mais espec co, A Practical Guide to Feature-Driven De o tamb velopment (PALMER; FELSING, 2002). Muita informac a em pode ser coletada a partir do s tio do autor (LUCA, 2008). representada de forma Por causa das experi encias e o contexto do autor, a metodologia e iconogr aca usando a linguagem de modelagem UML como visto na gura 4.2. composta por cinco atividades b A metodologia FDD e asicas: Desenvolvimento do modelo geral. O projeto se inicia com o desenvolvimento de um modelo rea ou m detalhado, passa geral do sistema. Depois, cada a odulo do dom nio do projeto e integrado ao modelo geral. por uma revis ao e e o da lista de funcionalidades. O conhecimento adquirido durante o desenvolvimento Construc a usado para criar uma lista de funcionalidades. O modelo e decomdo modelo inicial e o dos passos posto em assuntos, cada um contendo uma atividade do neg ocio. A descric a de uma atividade do neg ocio forma uma lista de funcionalidades. Cada funcionalidade o - resultado - objeto, como Calcular o total de vendas ou Vadeve ser no formato ac a lidar a senha do usu ario. As funcionalidades n ao podem ter uma estimativa de tempo maior que duas semanas, neste caso deve ser decomposta em funcionalidades mais elementares. desenvolPlanejamento por funcionalidade. Depois da lista de funcionalidades completa, e o recebem a posse e responsabilivido o plano do projeto. L deres de implementac a dade sobre conjuntos de funcionalidades que se tornar ao classes dentro do paradigma o orientada a objetos. de programac a desenvolvido para cada funcionalidade. Projeto por funcionalidade. Um pacote do projeto e Um l der do desenvolvimento seleciona um pequeno grupo de funcionalidades para serem desenvolvidas em duas semanas. Diagramas de seq uencia do UML s ao desenvolvi-

51

Figura 4.2: Diagrama de processos da metodologia FDD (FEATURE. . . , 2008)

52

renado o modelo. A assinatura e documentac o dos dos para cada funcionalidade e e a escrita e uma revis feita. m etodos e ao dos artefatos e o por funcionalidade. Depois do sucesso durante a inspec o dos artefatos da fase Construc a a o com durac o de anterior, s ao constru das as funcionalidades especicadas, numa iterac a a o do c duas semanas. Depois dos testes unit arios e inspec a odigo, as funcionalidades s ao promovidas para o sistema em uso. produzida numa iterac o Como pode ser visto, cada funcionalidade dentro do projeto e a curta, sendo ent ao f acil de gerenciar e estimar o tempo de conclus ao. Cada funcionalidade passa por estas cinco atividades de forma seq uencial, e marcos s ao denidos por atividade para seu acompanhamento. Na tabela 4.1 s ao representadas as atividades e o porcentual que representa, por padr ao, dentro do total das atividades:
Modelo Geral 1% Lista 40% Plano 3% Projeto 45% o Construc a 10% o Promoc a 1%

Tabela 4.1: Marcos na metodologia FDD em muitos aspectos mais cerimoniosa e mais pesada que suas irm A metodologia FDD e as geis, mas ao revermos o contexto onde foi criada, uma equipe de 50 pessoas num projeto de a a gil sim, mas adaptada as condic es de uma equipe um grande banco, percebemos que ela e o rea mais cr maior e numa a tica, onde a perda de dinheiro seria muito relevante. O autor coloca como as principais caracter sticas incorporadas na metodologia as seguintes: Modelagem dos objetos do dom nio. A modelagem dos objetos do dom nio consiste em explorar e explicar o modelo do problema a ser resolvido, de forma a se construir um o do sistema. arcabouc o para a construc a decomposta at Desenvolvimento por funcionalidade. Cada funcionalidade e e que seu tempo o seja menor que duas semanas, desta forma e mais f de construc a acil construir e controlar cada funcionalidade. nico respons Propriedade individual do c odigo. Cada parte do c odigo tem um u avel pela sua consist encia, desenho e desempenho. respons Equipes funcionais. Uma equipe funcional e avel por uma atividade, de forma que cada decis ao de projeto passe pelo aval de muitas pessoas, e v arias alternativas sejam consideradas.

53

es. S es ap o de cada artefato, para se assegurar a quaInspec o ao realizadas inspec o os a produc a lidade do produto. o. Mant Gerenciamento de congurac a em o hist orico de mudanc as, o c odigo alterado e per o em caso de falhas. mite a recuperac a es regulares. Integrac es regulares permitem assegurar que o sistema est Integrac o o a funcional, o o mais cedo poss e permite capturar erros de integrac a vel. Visibilidade do progresso e resultados. Com marcos bem denidos por todo o projeto, o gerente e o patrocinador podem saber a todo momento o progresso e quando intervir para colocar o projeto novamente no rumo. geis vistas at Sem d uvida, o FDD destoa das metodologias a e o momento. Mais cerimo consideravelmente mais pesada, com foco niosa e com muito mais elementos de controle, e o de documentos que orientem a construc o do sistema de software. Mas maior na produc a a mant em o padr ao de ser heur stica e participativa. Apesar de destoar, est a na classe das me geis pela preocupac o constante no envolvimento do usu es curtas e a todologias a a ario, iterac o o, que promove a criac o do modelo comum do sistema. Suas diferenc o comunicac a a as em relac a ` s demais v a eem mostrar que mesmo metodologias num ambiente de alta criticidade e com gran geis, de acordo com a denic o dos seus autores, quebrando o mito de des equipes podem ser a a geis est que metodologias a ao fadadas a projetos pequenos e triviais. Isto vai ao encontro do trabalho de Cockburn em seu conjunto de metodologias, de tal forma ex veis que podem ser adaptadas a criticidade e tamanho do projeto do praticante. Luca, no entanto, prefere fornecer ao usu ario de sua metodologia n ao um arcabouc o, mas um pacote fechado de pr aticas com ec acia comprovada.

4.5

O PMBOK

geis de desenvolvimento de software, e inAp os a vis ao geral de diversas metodologias a teressante confrontarmos estas metodologias com as pr aticas advogadas pelo PMBOK. Apesar uma metodologia, mas um conjunto de do argumento sempre presente de que o PMBOK n ao e boas pr aticas que podem ou n ao serem seguidas, e que o ciclo de vida, t ecnicas e ferramentas devem ser adequados pela equipe do projeto ao seu projeto em quest ao, o pr oprio aconselha rea de fortemente o uso de todos os processos descritos, o que pode confundir o iniciante na a ` quelas que sejam coerentes gerenciamento de projetos, reduzindo o n umero de metodologias a es. O PMBOK n uma metodologia, mas acaba ditando, principalmente com as recomendac o ao e

54

ao ser uma norma do PMI, quais elementos devem estar contidos em uma metodologia v alida. o ser Deste modo, a comparac a a feita atrav es do ciclo de vida e processos recomendados, em o com o ciclo de vida e processos de uma metodologia a gil t comparac a pica. O PMBOK descreve 44 processos do gerenciamento de projetos, divididos em cinco grupos reas do conhecimento. Os cinco grupos s ncia em todos e nove a ao executados na mesma seq ue rea ou ind o (ver gura 4.3): os projetos, independente da a ustria de aplicac a

o entre os grupos de processos do PMBOK (PMI, 2004) Figura 4.3: Iterac a

o. Dene e autoriza o projeto ou fases do projeto. Grupo de processos de iniciac a o para atender Grupo de processos de planejamento. Dene e rena objetivos e curso de ac a os requisitos do projeto. o. Integra pessoas e recursos para efetivar o plano do projeto. Grupo de processos de execuc a Grupo de processos de monitoramento e controle. Processos que regularmente medem e mo es em relac o ao plano, de forma que ac es nitoram o progresso e identicam variac o a o corretivas podem ser tomadas. o do produto, servic Grupo de processos de encerramento. Formaliza a aceitac a o ou resultado e faz com que o projeto chegue ao seu m.

55

seu foco em J a neste momento ca evidente uma caracter stica forte do PMBOK, que e processos. O que nos remete novamente aos trabalhos de (MAIER; RECHTIN, 2000), mostrando que o PMBOK tende a ditar metodologias do tipo racionais, ou at e mesmo normativas o a grande maturidade de suas j a que faz parte das normas do PMI. O que revela uma intenc a es. recomendac o Todas os processos descritos no PMBOK t em entradas e sa das bem denidas, normalmente muito descrevendo documentos a serem criados para uso nos processos seguintes. Seu escopo e geis descritas anteriormente, passando por procesmais abrangente que todas as metodologias a o, riscos, contratos sos de controle do tempo, custos, qualidade, recursos humanos, comunicac a e outros. que o trabalho de um projeto de acordo com o PMBOK Outra tend encia que pode-se notar e deve seguir a risca o plano estabelecido. Muitos autores separam o mundo das metodologias de desenvolvimento entre as adaptativas e as orientadas a planos, sendo que uma metodologia seguindo o PMBOK estaria no segundo grupo. Mecanismos para adaptar o plano de acordo com o existem, mas estes est o mudanc as encontradas durante a execuc a ao mais para tratar a excec a do que reetem a regra. O gerente do projeto deve concentrar suas energias em elaborar um bom plano, que contenha todos os poss veis eventos e planos de conting encia, e guiar o projeto o. de acordo com ele uma vez que posto em execuc a O PMBOK sugere uma metodologia de trabalho com muitos pontos de controle e cerimoniosa, muito provavelmente uma metodologia bem pesada. Com estas caracter sticas, est a muito melhor colocado para gerir projetos com grandes equipes e de grande criticidade. Provavelmente, uma metodologia atuando de acordo com os princ pios descritos no PMBOK seria es nos requisitos, j tamb em pouco tolerante a falta de disciplina e a variac o a que isto provocaria uma mudanc a em cascata numa s eria de documentos do projeto.

56

Conclus oes

poss Na curta revis ao hist orica realizada neste trabalho, e vel ver que, apesar de possu rem es, a hist mbito mais geral e cl intersecc o oria do gerenciamento de projetos no seu a assico e a hist oria do gerenciamento de software possuem naturezas distintas. O gerenciamento de projetos cl assico sempre teve como produto um item tang vel, como estradas, m sseis, usinas hidrel etricas, edif cios, entre outros. Estes projetos em sua maioria permitem a conjectura de terem em comum a linearidade do crescimento de sua complexidade dado o seu tamanho. Mesmo antes das t ecnicas modernas de gerenciamento de projetos, v arios empreendimentos de tamanho consider avel foram realizados com grande sucesso. o e valor O software parece ser o primeiro produto intang vel com tamanha disseminac a econ omico da hist oria da humanidade. Quase todas as atividades humanas hoje t em o aux lio de software para serem executadas, e uma grande empresa ou um programador solit ario parecem ter a mesma chance de sucesso com seus produtos. Mas pela caracter stica de ser produto da criatividade e g enio humanos, sofre problemas de escalabilidade e sua complexidade tende a crescer de forma exponencial dado o tamanho do problema atacado e o respectivo tamanho da equipe do projeto. o de hip O conhecimento acumulado da coletividade parece seguir um ciclo de formulac a oteses o ou refutac o. Assim se deu com o conhecimento em gerenciaseguida de sua comprovac a a mento de projetos, que seguiu este ciclo e atingiu sua maturidade quase no mesmo instante hist orico em que surgiu o software, uma vari avel nova at e ent ao desconhecida. Esta nova o traz consigo vari avel parece contradizer um modelo j a tido como maduro, e esta contradic a al em da defesa quase passional pelos seus adeptos, problemas econ omicos para aqueles que investiram neste modelo. A maturidade de todo processo tem dois lados. Por um lado, a maturidade traz consist encia, o e processos bem denidos. Por outro lado e o m da busca por a capacidade de otimizac a a supremacia da obedi o. Cada entidade certimelhorias, e encia aos processos sobre a inovac a o. Ela enfrenta cadora torna-se ent ao guardi a dos processos denidos, retardando sua evoluc a

57

`s o dilema de que as pr aticas de hoje reetem o passado, mas os padr oes devem se adaptar a mudanc as, ou se tornam barreiras ao progresso. No entanto, enormes somas de recursos s ao es para se adequar aos padr despendidas por pessoas e organizac o oes vigentes, e sua mudanc a constante seria vista como um erro de julgamento da entidade certicadora, o que prejudicaria sua credibilidade, o seu maior produto. Neste cen ario tem-se o conito entre o que est a defendido no PMBOK pelo PMI como boas geis. Pelo que foi visto neste trabalho, o software e um novo elepr aticas e as metodologias a nicas, e por isso n mento que possui muitas caracter sticas u ao deveria ser colocado no mesmo conjunto de produtos cl assicos tratados pelo gerenciamento de projetos tradicional. No entanto, verdade que nada do conhecimento acumulado da ger n ao e encia de projetos cl assica n ao se necess o de novos conceiaplica ao gerenciamento de projetos de software, mas e ario a adic a o dos antigos no conjunto de conhecimentos de forma mais r tos e t ecnicas e adaptac a apida e o da a rea e do mercado como um todo. din amica, de forma a acompanhar o passo de evoluc a importante reetir o valor de entidades que promovem a repetic o, procesNeste contexto, e a sos e padr oes num mundo de mudanc as cada vez mais r apidas, onde a escola de gerenciamento atual promove Learning Organizations1 (CHAWLA; RENESCH, 1995), pois o aprendizado e nica vantagem competitiva sustent au avel que qualquer empresa pode ter em qualquer tempo. geis est nfase Neste sentido, as metodologias a ao mais em acordo com esta nova vis ao, com sua e o. no aprendizado e adaptac a geis deu seus primeiros passos, Mas vale notar que o processo evolutivo das metodologias a mas ainda precisa responder muitas quest oes, a saber: geis? Como lidar com o aumento de escala em projetos a geis geogracamente dispersas num mundo cada vez mais glo Como gerenciar equipes a balizado? gil, como estabelecer estimativas Como planejar os recursos necess arios para um projeto a de custos e orc amentos? gil? Como fazer com que participantes de n vel m edio sejam produtivos num ambiente a o para a ger Finalizando, vemos que a contribuic a encia de projetos de software dada hoje es s pelo PMBOK parece ser mais danosa que ben eca, que suas recomendac o o seriam adequadas para projetos de software envolvendo uma grande equipe, para atacar um grande problema
1 Traduc o: a

es que aprendem Organizac o

58

rea de alta criticidade. Como a maioria dos projetos de software n numa a ao possui estas caracter sticas acabam sofrendo com a sua inu encia por ser aplicado na sua totalidade sem a devida o. As metodologias a geis, por outro lado, comec reex ao pelos membros da organizac a am menos ambiciosas quanto ao seu escopo e seu alcance, at e mesmo por serem uma resposta contra o o modelo anterior, e t em ainda o que evoluir, mas por serem livres de v cios, por terem a adaptac a como bandeira e por serem espec cas, s ao mais promissoras num espac o de tempo mais curto como resposta ao problema de como desenvolver software que devolva mais valor ao usu ario, de forma mais r apida e mais eciente.

59

Refer encias Bibliogr acas

ABNTEX. 2008. Dispon vel em: <http://abntex.codigolivre.org.br>. Acesso em: 23 out. 2008. BECK, K.; ANDREAS, C. Extreme Programming Explained: Embrace change. 2. ed. [S.l.]: Addison-Wesley Professional, 2004. BOEHM, B. A spiral model of software development and enhancement. SIGSOFT Softw. Eng. Notes, ACM, New York, NY, USA, v. 11, n. 4, p. 1424, 1986. ISSN 0163-5948. BOEHM, B. A view of 20th and 21st century software engineering. In: ICSE 06: Proceedings of the 28th international conference on Software engineering. New York, NY, USA: ACM, 2006. p. 1229. ISBN 1-59593-375-1. B oHM, C.; JACOPINI, G. Flow diagrams, turing machines and languages with only two formation rules. Commun. ACM, ACM, New York, NY, USA, v. 9, n. 5, p. 366371, 1966. ISSN 0001-0782. BROOKS, J. F. P. The Mythical Man-Month: Essays on software engineering. Anniversary. [S.l.]: Addilson-Wesley Longman, Inc., 1995. ISBN 0-201-83595-9. CASTLES & Cathedrals. 2008. Dispon vel em: <http://lincolnmotorhomehire.co.uk/castles.htm>. Acesso em: 20 nov. 2008. CHAWLA, S.; RENESCH, J. Learning Organizations. [S.l.]: Productivity Press, 1995. COAD, P.; LEFEBVRE, E.; LUCA, J. D. Java Modeling In Color With UML: Enterprise components and process. 1. ed. [S.l.]: Prentice Hall PTR, 1999. COCKBURN, A. Agile Software Development. 1. ed. New York: Addison-Wesley Publishing Company, 2001. COCKBURN, A. Crystal Clear: A human-powered methodology for small teams. 1. ed. New York: Addison-Wesley Publishing Company, 2005. DECEMBER 17, 1957 - rst launch of the Atlas rocket by U.S. 2008. Dispon vel em: <http://todayinspacehistory.wordpress.com/2007/12/17/december-17-1957-rst-launch-ofthe-atlas-rocket-by-us/>. Acesso em: 20 nov. 2008. DIJKSTRA, E. W. Letters to the editor: go to statement considered harmful. Commun. ACM, ACM, New York, NY, USA, v. 11, n. 3, p. 147148, 1968. ISSN 0001-0782. EGYPTIAN pyramids. 2008. Dispon vel em: <http://en.wikipedia.org/wiki/Egyptian pyramids>. Acesso em: 20 nov. 2008.

60

FEATURE Driven Development. 2008. Dispon vel em: <http://en.wikipedia.org/wiki/Feature Driven Development>. Acesso em: 21 nov. 2008. FRAME, J. D. Iterative and agile project management: Rethinking pmbok, cmm and iso 9000. 2008. Dispon vel em: <http://www.nysforum.org/events/agileprojectmanagement-1-16-08>. Acesso em: 03 nov. 2008. JAIN, A.; BOEHM, B. Developing a theory of value-based software engineering. In: EDSER 05: Proceedings of the seventh international workshop on Economics-driven software engineering research. New York, NY, USA: ACM, 2005. p. 15. ISBN 1-59593-118-X. JEFFRIES, R.; ANDERSON, A.; HENDRICKSON, C. Extreme Programming Installed. 1. ed. [S.l.]: Addison-Wesley Professional, 2000. LUCA, J. D. I.T. Solutions That Make A Difference. 2008. Dispon vel em: <http://www.nebulon.com/articles/index.html>. Acesso em: 21 nov. 2008. MAIER, M.; RECHTIN, E. The Art of Systems Architecting. 2nd. ed. Boca Raton: CRC Press, 2000. MANIFESTO for Agile Software Development. 2001. Dispon vel em: <http://agilemanifesto.org>. Acesso em: 05 nov. 2008. MARASCO, J. Software development productivity and project success rates: Are we attacking the right problem? 2006. Dispon vel em: <http://www.ibm.com/developerworks/rational/library/feb06/marasco/index.html>. Acesso em: 02 nov. 2008. MORRIS, P. W. G. The Management of Projects. 1. ed. [S.l.]: Amer Society of Civil Engineers, 1997. 18-77 p. ISBN 978-0727725936. NEIGHBORHOOD Recovery Act. 2008. Dispon vel em: <http://virtualology.com/MANHATTENPROJECT.COM/>. Acesso em: 20 nov. 2008. NORMANDY Landings. 2008. Dispon vel em: <http://en.wikipedia.org/wiki/D-Day>. Acesso em: 20 nov. 2008. PALMER, S. R.; FELSING, J. M. A Pratical Guide to Feature-Driven Development. 1. ed. [S.l.]: Prentice Hall PTR, 2002. PROJECT MANAGEMENT INSTITUTE (USA). A guide to the project management body of knowledge: Pmbok guide. 3. ed. Pennsylvania: Project Management Institute, Inc., 2004. ISBN 1-930699-45-X. RAILROADS in Utah. 2008. Dispon vel em: <http://www.media.utah.edu/UHE/r/RAILROAD.html>. Acesso em: 20 nov. 2008. RAYMOND, E. S. The Cathedral and the Bazaar. 1999. Dispon vel em: <http://www.catb.org/ esr/writings/cathedral-bazaar/>. Acesso em: 14 dez. 2008. REVIEW: The Mythical Man Month: Essays on Software Engineering - Anniversary Edition. 2005. Dispon vel em: <http://slashdot.org/books/980805/1148235.shtml>. Acesso em: 08 dez. 2008.

61

ROYCE, W. W. Managing the development of large software systems: concepts and techniques. In: ICSE 87: Proceedings of the 9th international conference on Software Engineering. Los Alamitos, CA, USA: IEEE Computer Society Press, 1987. p. 328338. ISBN 0-89791-216-0. SCHWABER, K. Agile Project Management with Scrum. 1. ed. [S.l.]: Microsoft Press, 2004. SCRUM. 2008. Dispon vel em: <http://en.wikipedia.org/wiki/Scrum (development)>. Acesso em: 22 nov. 2008. THE STANDISH GROUP. Chaos. 1995. Dispon vel em: <http://net.educause.edu/ir/library/pdf/NCP08083B.pdf>. Acesso em: 01 nov. 2008. WAKE, W. C. Extreme Programming Explored. 1. ed. [S.l.]: Addison-Wesley Professional, 2001.