GERÊNCIA DE PROJETOS DE SOFTWARE
i
ditora
GERÊNCIA DE PROJETOS DE SOFTWARE
João Alberto Arantes do Amaral
João Alberto Arantes do Amaral
i ditora
Gerência de Projetos de Software
Todos os direitos desta edição reservados ao autor. Publicado por Editco Comercial Ltda. Rua Pedroso Alvarenga, 1046, 9º andar – sala 95 Itaim – 04531-004 – São Paulo-SP Tel: (11) 3706-1492 – Fax: (11) 3071-2567 e-mail:
[email protected]
João Alberto Arantes do Amaral
Gerência de Projetos de Software
São Paulo – 2002
©2002 AMARAL, João Alberto Arantes do GERÊNCIA DE PROJETOS DE SOFTWARE 1ª edição, São Paulo: 2002. Revisão: Elina Correa Miotto Editoração: Jean Carlos Barbaro Capa: Jean Carlos Barbaro
ISBN 85-87916-42-4
É PROIBIDA A REPRODUÇÃO Nenhuma parte desta obra poderá ser reproduzida, copiada, transcrita ou mesmo transmitida por meios eletrônicos ou gravações, assim como traduzida, sem a permissão, por escrito, do autor. Os infratores serão punidos pela Lei nº 9.610/98. Impresso no Brasil / Printed in Brazil
Dedicatória
○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
À memória de minha mãe, Neyde Curvo do Amaral
Agradecimentos
○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Como não podia deixar de ser, vou fazer um breve agradecimento às pessoas especiais que me ajudaram direta ou indiretamente na criação deste livro. Em especial gostaria de agradecer à minha amiga, a Prof. Dr. Joyce Warmkessel, do departamento de Aeronáutica e Astronáutica do MIT, pelo apoio e orientação que me deu no período em que estive nos EUA. À Helena e Renato Pakter, Patrícia e Elizabeth Sikar pelos passeios de bicicleta e de trem pela Nova Inglaterra, passeios que serviram de inspiração para as estórias que vocês irão ler em breve. Agradeço também a meu pai, José Roberto e aos meus amigos Nelson e Fabienne Monnerat, Erica, Frederico Sauer, Márcia Anjos, Maurício Kiwielewickz , Paulo e Luisinha Atkinson pelas sugestões e por terem me ajudado ao longo de todos esses anos, em especial no período em que estive no MIT. Gostaria de agradecer também ao Prof. Peña-Mora e aos 32 estudantes do Projeto IeCollab.
Índice
○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Introdução I Preparação para o Projeto Estudo de Caso 01 “O caminho que leva ao inferno é pavimentado de boas intenções” Tópicos para discussão ............................... Referências .................................................
CAPÍTULO
17 37 38
II Planejamento do Projeto Estudo de Caso 02 “Não há ventos favoráveis para aqueles que não sabem aonde ir” 43 Referências ................................................. 63 CAPÍTULO
III Execução do Projeto Estudo de Caso 03 “Os sete pecados capitais do projeto” ............................................ Tópicos para discussão ............................... Referências .................................................
CAPÍTULO
67 83 85
IV Adaptação do Projeto Estudo de Caso 04 “Perseverar é tornar o impossível possível” ............................... 89 Tópicos para discussão ............................... 105 Referências ................................................. 107 Conclusão .................................................. 109
CAPÍTULO
Introdução
○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Sobre o que é este livro Este livro é sobre gerência de um tipo especial de projeto, projeto de software. Eu procurei descrever as atividades principais envolvidas no gerenciamento de projetos de software de uma maneira bem informal. A idéia é dar uma visão geral das fases pelas quais um projeto de software passa, desde o seu nascimento até a sua finalização. De um modo geral, livros sobre gerência de projetos são muito maçantes, incrivelmente longos, caros, cheios de termos técnicos, definições cansativas e metodologias soníferas. Procurei evitar tudo isso; tentei escrever um livro divertido que retratasse de uma maneira bem informal as preocupações do diaa-dia de um gerente de projetos de software. Este livro é na verdade a compilação de quatro estórias, uma sobre preparação, outra sobre planejamento, a terceira sobre execução e a última sobre adaptação do projeto. Estas estórias são vividas por três personagens. Enquanto eles curtem o verão na região da Nova Inglaterra, EUA, eles discutem as aventuras e desventuras de Manopoulos, um gerente de projeto de software 11
Gerência de Projetos de Software
malsucedido. Espero que você se divirta acompanhando os nossos intrépidos heróis em seus passeios pela Nova Inglaterra e aprenda um pouco sobre as atividades principais envolvidas na gerência de projetos de software. Divirta-se!
A quem se destina este livro Este livro se destina a gerentes de projetos de software, analistas de sistemas, estudantes de MBA e a alunos de cursos de pós-graduação e graduação em áreas relacionadas à tecnologia da informação e gerência de sistemas de informação. Caso você tenha conhecimentos básicos de engenharia de software, ou já tenha trabalhado em desenvolvimento de sistemas você terá facilidade de entender os conceitos expostos. Caso você não tenha muita vivência na área, provavelmente terá um pouco mais de dificuldade, mas ainda assim conseguirá entender os principais conceitos envolvidos.
Porque eu escrevi este livro A estória da criação deste livro é de certa forma curiosa. Durante o período em que estive no MIT (Massachusetts Institute of Technology-EUA) tive a oportunidade de trabalhar como gerente de projeto de desenvolvimento de um ASP (application service provider), em um projeto acadêmico chamado IeCollab (Intelligent electronic Collaboration), conduzido pelo Prof. Feniosky Peña-Mora, do grupo de tecnologia da informação do Departamento de Engenharia Civil e Ambiental do MIT. Este projeto envolveu 32 estudantes e professores de 03 universidades, 12
João Alberto Arantes do Amaral
MIT nos Estados Unidos, CICESE (Centro de Investigación Científica y de Educación Superior de Ensenada) no México e PUC (Pontificia Universidad Católica) no Chile. Foi uma experiência única, muito interessante, o objetivo deste projeto era fazer com que os estudantes se familiarizassem com as responsabilidades dos diversos times de desenvolvimento, bem como tomassem conhecimento das peculiaridades envolvidas no desenvolvimento de um sistema por equipes situadas em países diferentes. Após a conclusão deste curso tive a oportunidade de trabalhar como Assistente de Pesquisa (Research Assistant) e posteriormente como Assistente do Professor (Teacher Assistant) no Programa de Gerenciamento e Projeto de Sistemas (Systems Design and Management Program) do MIT, com a professora Dr. Joyce Warmkessel. Na ocasião ela me pediu que escrevesse alguns estudos de casos que pudessem ser usados pelos estudantes de pós-graduação no curso de Gerência de Projetos que seria oferecido no próximo semestre. Escrevi os casos tendo por base dados do projeto IeCollab. Para não melindrar ninguém transformei o projeto IeCollab em PATOLAB e criei uma série de situações que permitissem narrar o que aconteceu ao longo do projeto. Estas estórias foram escritas no verão, normalmente à noite e de madrugada. Confesso que de dia às vezes conseguia escapulir de minhas obrigações, pegar a minha bicicleta e sair com os meus amigos pedalando pelas cidades próximas. Outras vezes eu saía para velejar pelo rio Charles ou mesmo caminhar pelas colinas de Blue Hills. Os estudos de caso refletem esse período divertido e atribulado. De noite eu escrevia sobre coisas que havia feito 13
Gerência de Projetos de Software
durante o dia, misturando ficção com realidade. Muitas das situações relatadas nos estudos de caso realmente aconteceram. Outras são pura fantasia. Enfim, foi divertido escrever os textos, mas confesso que escrever em inglês foi bem trabalhoso, agradeço à Prof. Joyce pela paciência infinita de ler os casos e tornar o texto mais digerível ao paladar americano. Enfim, os casos foram criados e usados no curso do MIT. Voltei ao Brasil e me esqueci dos estudos de caso por uns seis meses. Meio que por acaso recebi um convite e comecei a lecionar gerência de projetos de software à noite em cursos de pós-graduação. Resolvi então traduzir um a um os estudos de casos e modificá-los de modo a usá-los nas aulas. Para a minha surpresa, os estudos de caso tiveram uma aceitação muito boa, e vários alunos me cobraram que eu publicasse um livro sobre o assunto. Posterguei o quanto pude, dei infinitas desculpas mas no final não teve jeito: tive de escrever o livro! Pois bem, a culpa é deles. Aqui está o livro, espero que você se divirta tanto em lê-lo como eu me diverti em escrevê-lo.
14
João Alberto Arantes do Amaral
CAPÍTULO
I
PREPARAÇÃO PARA O PROJETO 15
Estudo de Caso
01
○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
“O caminho que leva ao inferno é pavimentado de boas intenções”
“O tempo gasto na reflexão é na verdade uma economia de tempo” Publius, 1 A.C.
É
verão em Boston. Meu nome é Nelson; eu estou conversando com Manopoulos, o gerente de um projeto malsucedido. Ele está cansado e estressado. Ele trabalhou duro durante muitos meses em PATOLAB, um projeto de software distribuído e colaborativo que envolveu times localizados em três países diferentes. Este projeto teve vários problemas, como a deterioração do esforço de desenvolvimento, atrasos e custos acima do orçamento. O projeto nunca atingiu seus objetivos. O time do projeto não foi capaz de integrar todos os componentes de software em um produto final. Eu estou tentando entender porque o projeto dele falhou apesar do grande esforço da equipe de desenvolvimento. Estou procurando trazer à tona os seus modelos mentais de modo a entender as causas do fracasso. Comecei perguntando a Manopoulos sobre o que era o seu projeto. 17
Gerência de Projetos de Software
“Meu projeto tinha por objetivo a criação de um aplicativo colaborativo para ambiente WEB. Em resumo, eu poderia dizer que visávamos criar um tipo especial de software cliente-servidor que permitisse compartilhamento de documentos e comunicação. Nós pretendíamos cobrar por prover este tipo de serviço.” – respondeu Manopoulos. “Parece que você iria construir um tipo de Application Service Provider (ASP), é isso mesmo?” – eu perguntei. “Exatamente. O projeto envolveu times localizados nos EUA, Chile e México. Era um projeto de curto prazo que começou em novembro de 1999 e terminou em abril de 2000. O time, composto por 32 desenvolvedores, estava geograficamente disperso: cinco no Chile, cinco do México e 22 nos EUA.” – Manopoulos respondeu. “Como você poderia descrever as fases de projeto?” – eu perguntei. “Nelson, está claro para mim que o projeto teve fases distintas: preparação, planejamento e execução. Claro que o projeto também sofria modificações baseadas nos resultados da execução. Talvez eu possa chamar isto adaptação do projeto. É mais fácil se eu fizer um desenho para explicar.” Este é o desenho que Manopoulos me mostrou (Amaral, 2000):
Figura 1
18
João Alberto Arantes do Amaral
“O.k., vamos falar um pouco sobre os pontos principais envolvidos na preparação do projeto” – eu disse. “Qual foi a estrutura de times que vocês adotaram para o projeto PATOLAB e quão motivados vocês estavam no início de projeto?” Manopoulos respondeu: “No começo do projeto nós estávamos muito entusiasmados e confiantes. Nossa estrutura de time era bastante boa, nós tínhamos 10 equipes trabalhando simultaneamente”. Ele me mostrou a seguinte figura que representa a estrutura dos times.
Figura 2
Ele continuou a explicação: “Todos os membros dos times tinham alguma formação em tecnologia da informação ou informática de um modo geral. A maioria de nós era generalista, tínhamos idéias básicas dos processos envolvidos no desenvolvimento de software e todos sabiam ao menos uma linguagem de programação, Java. Nós também contávamos com um par de especialistas na área de desenvolvimento de aplicações do tipo clienteservidor.” Enquanto Manopoulos falava eu pensava com os meu botões quão boa era a proporção entre o número de es19
Gerência de Projetos de Software
pecialistas e generalistas. Um grupo de trinta e duas pessoas trabalhando no desenvolvimento de uma aplicação do tipo cliente-servidor e só dois especialistas neste assunto soou um tanto estranho para mim. Eu lhe perguntei como os times foram formados. “Todos tiveram a liberdade para escolher entre os diversos times. Eu, como gerente de projeto, só defini o tamanho de cada time e deixei que as pessoas escolhessem livremente o time no qual elas queriam trabalhar.” “E o que você me diz sobre a escolha dos líderes dos times?” – eu perguntei. “A mesma coisa, eu também pedi por voluntários. Nós tivemos a liderança dos times dividida entre os países. Por exemplo, o líder do time de Análise era do México e o líder do time de Gerência de Negócios era do Chile, por exemplo.” Ele me mostrou a seguinte tabela (tabela 1) Tabela I Times
20
Número de participantes USA
México
Chile
Gerente do Projeto
01
—
—
Analistas
03
01
02
Projetistas
02
01
02
Programadores
03
—
—
Testadores
02
01
—
Gerentes de Qualidade Gerentes de Documentação
03 02
01 —
— —
Gerentes de Configuração
02
01
—
Gerentes de Marketing
02
—
—
Gerentes de Negócios
02
—
01
João Alberto Arantes do Amaral
“E como funcionou?” – eu perguntei. “Não funcionou muito bem, seria melhor se o grupo inteiro das pessoas de cada país pertencesse a um único time. Por exemplo, no México nós tínhamos uma pessoa que pertencia ao time de Analistas, outra que pertencia ao time de Projetistas, outra ao time de Gerência de Configurações, outra ao time de Testadores e uma moça que pertencia ao time de Garantia de Qualidade. Seria muito melhor se as cinco pessoas do México pertencessem a um único time, por exemplo o time de Gerência de Configurações. Essa medida daria maior poder de decisão aos times localizados fora dos EUA.
21
Gerência de Projetos de Software
O modo que nós dividimos os times nos trouxe vários problemas. Nós tínhamos 22 membros da equipe trabalhando juntos nos EUA e isto causou um desbalanceamento na estrutura do projeto. A tendência natural era decidir nos E.U.A o que fazer e comunicar as decisões aos times situados em outros países. Isso foi realmente ruim; as pessoas que trabalhavam em outros países não gostaram nada disso. Eu ainda me lembro do conselho do vice-presidente da empresa para mim: Manopoulos, você vai perder os desenvolvedores do México se você não mudar esta estrutura.” “Você os perdeu?” – perguntei curiosamente. “Sim, a maioria dos membros da equipe de desenvolvimento do México e do Chile deixou o projeto quando problemas apareceram. Eu estava tão envolvido com os problemas dos times dos EUA que não dei a atenção devida aos sentimentos e frustrações dos nossos colaboradores estrangeiros.” “Bom, pelo menos você tinha os líderes dos times para ajudá-lo a resolver este problema, não tinha?” “Deveria ter, mas não tive. Eu deveria ter tido mais cuidado na escolha dos líderes dos times. Mas no começo do projeto eu não conhecia muito bem a personalidade de cada um dos participantes. Se eu os conhecesse tanto quanto os conheço agora, certamente teria escolhido outras pessoas para serem os líderes de time. Em termos de liderança, ficou claro a mim desde o princípio do projeto que nós precisávamos confiar não apenas na minha capacidade de liderança, mas também na capacidade dos líderes de cada time. A maioria dos 22
João Alberto Arantes do Amaral
problemas enfrentados no projeto PATOLAB não foi devido à falha de medidas de gerenciamento do projeto, mas à falta de liderança efetiva de cada um dos líderes dos times (Smith, 1999). A falta de liderança causou a maioria dos problemas de comunicação que nós tivemos. Os líderes dos times não se comunicavam eficientemente com os integrantes do time. Os líderes dos times não tinham uma idéia clara do que os seus subordinados estavam fazendo; muitas vezes os e-mails enviados pelos líderes sequer foram respondidos pelos seus subordinados. O projeto PATOLAB também sofreu de falta de comunicação entre os diversos times, embora todos os membros tivessem acesso a uma variedade de ferramentas de comunicação (e-mail, repositório Web para o projeto, ICQ, etc.). As ferramentas estavam disponíveis e eram fáceis de se usar; no entanto elas não foram usadas adequadamente. Para melhorar a comunicação entre times, semanalmente fazíamos uma reunião, ocasião em que todos os integrantes do projeto falavam livremente sobre os problemas internos de cada time ou de problemas que os outros times estavam causando a eles. A pergunta que eu fazia mais freqüentemente era se os líderes dos times tinham conversado previamente sobre os problemas comuns, e a resposta na maior parte de vezes era “não”. Se os líderes dos times tivessem tido mais liderança, estes problemas de comunicação teriam sido superados facilmente.” Eu notei um certo tom de ressentimento na voz dele. Procurei mudar de assunto, eu não queria estressá-lo ainda mais. 23
Gerência de Projetos de Software
“Todos os integrantes dos times estavam trabalhando apenas neste projeto?” “Infelizmente não, a firma tinha vários outros projetos em andamento, quase todos estavam trabalhando em pelo menos outros dois projetos.” “O que mais você fez na fase de preparação?” “Nós gastamos algum tempo selecionando ferramentas de software que permitissem colaboração entre os times dispersos geograficamente. Gastamos algum tempo também revisando documentos de projetos de anos anteriores. Nós tentamos usar as mesmas normas (standards) que nós usamos no projeto de software do ano anterior, normas da IEEE. Nós procuramos identificar os usuários finais e as necessidades deles. Gastamos também um bom tempo providenciando os recursos necessários.” Rapidamente eu rascunhei as atividades principais da preparação para o projeto PATOLAB e mostrei a Manopoulos (figura 3).
Figura 3 24
João Alberto Arantes do Amaral
Baseado no desenho que fiz nós começamos a discutir cada componente da fase de preparação para o projeto. Eu comecei lhe perguntando como foi definido o escopo do projeto. Manopoulos tinha uma idéia clara do que deveria ser incluído no escopo do projeto: “O escopo delimita as fronteiras do projeto: quais serão as características do produto (funções e desempenho), quais são as restrições de contexto, quando o projeto será entregue, quando será terminado, quais serão as métricas que definirão o sucesso do projeto e quais os recursos envolvidos.” Ele me mostrou um documento (Amaral et. al., 1999) com a seguinte sentença sublinhada. Este documento fazia parte da definição do escopo do projeto PATOLAB: “O pacote de software fará uso da Internet, permitindo colaboração entre times localizados em diferentes localizações geográficas. Permitirá compartilhamento de documentos e reuniões on-line. Características principais: • Aplicação para Internet • Compartilhamento de documentos • Compartilhamento de aplicativos • Independência de plataforma específica • Gerenciamento de reuniões” Depois de ler esse trecho sobre o escopo do projeto ele ficou quieto, algo o estava perturbando. Então eu perguntei: “Você acha que faltou algo em sua definição de escopo do projeto?” 25
Gerência de Projetos de Software
“Sim, eu suponho que sim. Nós não cobrimos as restrições de contexto. Com o desdobramento do projeto ficou claro que teríamos de refinar nossa definição de escopo. Nosso escopo inicial do projeto se tornou impossível de ser alcançada em virtude do pouco tempo de que dispúnhamos.” Eu sabia que a firma de Manopoulos tinha desenvolvido um projeto de software similar um ano antes. Talvez a equipe de desenvolvimento do ano anterior tivesse enfrentado problemas semelhantes. Eu lhe perguntei quão útil foi revisar ou reutilizar documentos do projeto do ano anterior. “Nós não tivemos muito êxito reutilizando documentos e códigos do projeto anterior. As normas e documentos usados no último projeto serviram apenas como uma diretriz, um ponto de partida para o nosso planejamento. Sob este aspecto foi muito útil. Porém, a reutilização de documentos técnicos não foi bem sucedida. Como você sabe, em projetos de software você quer não apenas reutilizar o código, mas também os documentos de Análise, de Projeto, os Casos de Teste, etc. A Análise e Projeto não foram reutilizados em nada. Nós não reutilizamos quase nenhum código porque o software desenvolvido no ano anterior continha muitos erros. Nós tentamos consertar os erros inicialmente, mas sem muito sucesso. Nós percebemos que levaria mais tempo para consertar o código anterior do que construir um código totalmente novo.” “Que chato!” – eu disse, “mas pelo menos você usou as mesmas normas. Conte-me mais sobre as normas”. 26
João Alberto Arantes do Amaral
“Bem, não há muito o que dizer. A maioria das normas que nós escolhemos eram normas da IEEE. Foram providenciadas cópias das normas para todos os times e o time de Garantia de Qualidade teve por função assegurar que as normas seriam seguidas durante toda a vida do projeto.” “E quais foram os recursos do projeto?” “Os recursos do projeto PATOLAB eram o pessoal, o material e o equipamento usado no projeto. Os seguintes recursos foram usados:” (tabela 2) Tabela II Pessoal
32 desenvolvedores localizados em três países diferentes
Hardware
32 Computadores Pessoais.
Ferramentas de Desenvolvimento Java 2.0, Corba, Rational Rose de Software: Ferramentas de banco de dados
Oracle
Ferramentas de escritório
MS-Word, MS-Excel, MS-PowerPoint
Ferramentas de Projeto
MS-Project, Primavera,
Ferramentas de comunicação
Netmeeting, ICQ,
Web-repositórios
CVS, Apache
Depois desta conversa ficou claro para mim que Manopoulos seguiu uma metodologia de preparação para o projeto. Mas o projeto não foi bem sucedido apesar dessa metodologia. Eu estava curioso para saber o que poderia ter sido feito de um modo diferente. Eu lhe perguntei quais foram as deficiências principais na preparação para o projeto. 27
Gerência de Projetos de Software
“Nós não gastamos muito tempo revisando os documentos do projeto do ano anterior. Não houve nenhuma discussão formal sobre aqueles documentos, embora vários grupos tivessem consultado os documentos por sua própria iniciativa. Eu mesmo li o plano de gerência do projeto do ano anterior cuidadosamente. Isto foi muito útil, aprendi bastante com essa leitura. Se todos os times tivessem lido os planos e documentos do ano anterior, nós teríamos evitado incorrer nos mesmos erros.” “Que erros?” – perguntei prontamente. “Por exemplo, a definição da missão do projeto. Seria muito melhor se nós tivéssemos definido claramente nossas prioridades e as características desejadas do sistema antes de começar o projeto. Nós poderíamos ter criado uma matriz que representasse quais eram as características mais importantes e definir quais as nossas prioridades” (Figura 4). De modo a tornar mais clara a sua explicação, Manopoulos desenhou a seguinte matriz rapidamente (Highsmith 2000):
Figura 4 28
João Alberto Arantes do Amaral
“E qual é a importância disso?” – eu perguntei um pouco incrédulo. “Isto é muito importante, Nelson! Basicamente ajuda a visualizar o que deve ser alcançado, ajuda a definir quais são as características realmente importantes para a sua equipe de desenvolvimento. Em nosso caso nós queríamos ser os primeiros a lançar um aplicativo desse tipo no mercado, nós queríamos conquistar a maior parcela de mercado possível. Você sabe, a primeira versão poderia ter um número aceitável de erros de código, os tais “bugs”. Nós resolveríamos esses problemas nas versões seguintes.” Eu tinha lá minhas dúvidas quanto à sua afirmação sobre erros – “Então você pensa que entregar um software com um monte de erros não é problemático?” “Olha, Nelson, eu acho que é impossível entregar um software que foi desenvolvido rapidamente sem defeitos. Defeitos estarão lá, é um fato; não há nenhum modo de se evitar isto completamente. O truque é ter os defeitos sob controle. Há uma relação de compromisso como em qualquer outro produto de engenharia. Em nosso caso, nossos defeitos não causariam danos sérios. Nós não estávamos desenvolvendo um software que colocaria em risco a vida humana. Caramba, se os produtos da Microbob’s1, depois de muitas versões ainda têm vários “bugs”, por que o meu software não poderia ter nenhum?” Microbob’s é uma firma que desenvolve software, feroz competidora da firma em que Manopoulos trabalhava 1
29
Gerência de Projetos de Software
Nós rimos e concordamos. Sim, sempre há uma relação de compromisso em qualquer projeto. Mas eu ainda estava pensando por que a missão deveria ser definida do modo que ele propôs e pedi a ele mais detalhes. “A definição da missão é muito importante. Se você tiver uma definição clara do que é a sua missão, ficará mais simples de escolher o processo de desenvolvimento (ciclo de vida). Por exemplo, no nosso caso nós não tínhamos uma idéia clara de que ciclo de vida seguir. Agora eu sei que dependendo da natureza do software, um processo de desenvolvimento é mais adequado. Não faz sentido usar modelos de ciclo de vida em cascata para software que necessita ser desenvolvido rapidamente e que seja projetado para operar em ambientes que mudem rapidamente, como a Internet por exemplo. Definir a missão claramente ajuda a escolher o modelo de desenvolvimento mais adequado.” Eu já havia estudado os diversos modelos de ciclo de vida para desenvolvimento de software, mas nunca havia percebido que a escolha deles está ligada não apenas ao objetivo que se quer alcançar, mas também ao ambiente em que o sistema irá operar e à velocidade de desenvolvimento. Isso era uma novidade para mim. Manopoulos salientou que o modelo de ciclo de vida em cascata é bastante apropriado para o desenvolvimento de aplicações que irão operar em ambientes que mudam pouco. Ele me deu o exemplo do desenvolvimento de um sistema para monitoração de pacientes em UTI hospitalar. O software não deve ter erros, a velocidade de desenvolvimento não deve ser alta. O ambiente em que o sistema irá operar provavelmente será um computador dedicado apenas a essa fun30
João Alberto Arantes do Amaral
ção, ou seja, um ambiente que muda pouco. O modelo de ciclo de vida em cascata, neste caso, seria o adequado. “Mas no caso do projeto PATOLAB a estória era totalmente oposta: tínhamos que ser os primeiros a chegar no mercado, tínhamos que desenvolver rapidamente para um ambiente que muda muito, a Web” – ressaltou Manopoulos. Ele desenhou a seguinte figura de modo a tornar o conceito mais claro (Figura 5).
Figura 5 31
Gerência de Projetos de Software
Ele me explicou rapidamente as diferenças entre “Desenvolvimento de Software Monumental” e “Desenvolvimento de Software Acidental” (Highsmith, 2000). Ficou claro para mim que o desenvolvimento pode se situar entre dois extremos, pode variar desde um processo totalmente definido, o assim chamado “Desenvolvimento de Software Monumental” até um processo totalmente caótico, o “Desenvolvimento de Software Acidental”. Ele explicou que Modelos de Maturidade de Capacidade são mais satisfatórios para processos de desenvolvimento de software repetitivos. Para um projeto de características especiais como o PATOLAB ele usaria uma outra abordagem, chamada de Desenvolvimento Adaptativo de Software (Highsmith, 2000). Eu lhe perguntei se ele tinha esta visão clara no começo do projeto. “Infelizmente, não. Nós não definimos claramente as nossas prioridades no início do projeto. Nós escolhemos um ciclo de vida de prototipagem no começo do projeto e no meio do projeto nós resolvemos mudar e seguir o ciclo de vida em cascata. Realmente foi uma bagunça! E ao término do projeto nós estávamos discutindo em qual fase do Modelo de Maturidade de Capacidade nós nos encontrávamos!” Ele fez o seguinte desenho para mostrar como foi a evolução do projeto (Figura 6). Ele também me falou que não foi realizado um estudo de viabilidade adequado. Eu achei estranho e perguntei o porque disso. “Talvez porque nós estivéssemos bastante confiantes das nossas habilidades. Talvez exageradamente otimistas 32
João Alberto Arantes do Amaral
Figura 6
ou talvez porque naquele momento nós não tínhamos idéia de quão complexo seria o projeto que nós iríamos enfrentar. Se nós fôssemos fazer o mesmo projeto novamente eu conduziria a realização de um estudo de viabilidade imediatamente na fase de preparação. Deste modo nós poderíamos definir um escopo de projeto mais realís33
Gerência de Projetos de Software
tico. Nós dividiríamos o projeto em versões e definiríamos as características principais de cada versão.” “Manopoulos, fale me mais sobre essa idéia de versões.” – eu perguntei curioso. Ele pensou um pouco e disse: “Eu acredito ser importante definir as metas para cada versão do software. Nosso escopo inicial era muito abrangente, difícil de ser realizado em um ano. Seria melhor se nós tivéssemos definido metas específicas a serem alcançadas ao longo do tempo, da seguinte forma:” Ele fez este desenho (Figura 7):
Figura 7
“Manopoulos, você pensa que seu projeto teve algum sucesso?” “Bom, depende como você define sucesso. O que é sucesso de um projeto?” – ele retrucou. “Olha, para mim um projeto bem sucedido deve atender a um ou a todos dos seguintes critérios: cumprir os requisitos estabelecidos, ser entregue dentro do prazo estipulado, não ultrapassar o orçamento previsto. Bem, evidente34
João Alberto Arantes do Amaral
mente o projeto deve assegurar a qualidade do produto e proporcionar satisfação profissional e oportunidade de crescimento aos integrantes dos times (Highsmisht, 2000).” Manopoulos pensou um pouco e disse: “Talvez seja impossível atender a todos esses critérios, talvez você deva escolher alguns dentre eles e definilos como suas metas de sucesso. Mas eu posso lhe dizer que nós não atingimos nenhum desses critérios de sucesso plenamente. De fato, nós deveríamos ter definido como medir o sucesso do projeto ainda na fase de preparação para o projeto.” Manopoulos estava com uma expressão amarga, alguma coisa o estava perturbando. Eu tentei descobrir em que ele estava pensando. “Que mais você poderia me dizer sobre a preparação para o projeto?” “Eu penso que na fase de preparação todos os integrantes dos times deveriam ter estudado mais sobre os conceitos básicos de desenvolvimento de software para ambiente cliente-servidor. Todos os componentes dos times sabiam programar usando a linguagem Java, mas isso não era o suficiente. Tínhamos apenas um analista no time que era especialista em Corba e Oracle. Se todos os componentes dos times tivessem as noções básicas de arquitetura do tipo cliente-servidor isso teria evitado muitos problemas que tivemos durante o desenvolvimento do projeto. Talvez nós não tivéssemos as habilidades necessárias, sei lá. Talvez eu mesmo não tivesse maturidade e habilidade necessária para gerenciar um projeto daquele porte…” 35
Gerência de Projetos de Software
“Calma Manopoulos, não se culpe tanto! Minha mãe sempre diz que a cura para a tristeza é uma boa refeição!” Era hora do almoço, nós precisávamos comer algo. Decidimos que oportunamente conversaríamos sobre planejamento de projeto. Manopoulos me convidou a ir a um restaurante próximo, cujo nome era “Miracle of Science”. Ele iria me apresentar uma amiga dele, Beth. Eu estava ansioso por conhecê-la pessoalmente, já tinha ouvido falar bem sobre ela.
36
João Alberto Arantes do Amaral
Tópicos para discussão
○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
1) PATOLAB era um projeto colaborativo-distribuído; os desenvolvedores moravam no México, Chile e EUA. O que você faria para assegurar uma comunicação eficiente entre os times? Quais ferramentas você usaria? 2) Manopoulos esqueceu de falar sobre a nacionalidade dos integrantes do time que trabalhava nos EUA. Os desenvolvedores eram de várias nacionalidades diferentes tais como Índia, China, Líbano, Brasil e EUA. Você pensa que esta diversidade poderia causar alguns problemas? Você acha que diferenças culturais e barreiras de idioma poderiam dificultar o andamento do projeto? 3) Este é um exemplo de um projeto de software complexo e de curto prazo. Se você fosse selecionar os componentes dos times, que tipo de profissional você procuraria contratar? Como você dividiria os times? 5) Talvez o modelo de fases do projeto seguido por Manopoulos seja muito simples (Figura 1). Crie um novo modelo, mais elaborado. 37
Gerência de Projetos de Software
6) Eu não gosto das atividades listadas na preparação para o projeto (Figura 3). Talvez eu acrescentasse mais alguns componentes e retirasse outros. O que você faria? 7) Manopoulos não falou muito sobre o cliente para esse tipo de aplicação. Como envolver os clientes na fase de preparação para o projeto? 8) Quais foram os maiores erros de Manopoulos na fase de preparação para o projeto? 9) Você pensa que revisar projetos de anos anteriores é importante? Você alguma vez revisou algum projeto anterior antes de trabalhar em um novo? Sua companhia tem um catálogo de “lições aprendidas” de projetos anteriores? Que tipo de informação seria útil de se obter de projetos prévios? 10) Você pode explicar qual era o problema representado pela figura 6?
38
João Alberto Arantes do Amaral
Referências
○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
[Amaral, 2000] Amaral, J.A.A (2000) Project Management in Distributed Collaborative Environment: The ieCollabCase Study, MIT MscThesis, Ocean Engineering [Amaral et. al., 1999] Amaral, J.A.A., Limansky I. and Abbot E. (1999). The ieCollab Project Management Plan, obtido em 25 de maio de 2000, Web: http:// www.collaborate.mit.edu/FTP/P1 [Highsmith, 2000] Highsmith III, J. A. (2000). Adaptive Software Development: a collaborative approach to managing complex systems, New York, USA: Dorset House Publishing Company. [Smith, 1999] Smith G. (1999, August). Project leadership: Why project management alone doesn’t work, Hospital Materiel Management Quarterly, 21(1), 88-92.
39
CAPÍTULO
II
PLANEJAMENTO DO P ROJETO
Estudo de Caso
02
○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
“Não há ventos favoráveis para aqueles que não sabem aonde ir”
“Seres humanos são notáveis em sua habilidade de aprender com experiência de outros, mas também são igualmente notáveis em sua falta de vontade de fazer isso.” Douglas Adams
N
ós fomos para “Miracle of Science”, um bar bem rústico perto do MIT. Mesas toscas de madeira maciça, janelas amplas, sempre apinhado de gente. O bar é um ponto de referência em Cambridge, para lá convergem todas as tribos na hora do almoço. Ali nós nos encontramos com Beth, uma mulher notável. Alta, bonita e esbelta, olhos verdes atentos a tudo. Ela possui uma firma própria, especializada na fabricação de cromatógrafos. Beth e o seu pai fazem de tudo: contatam os clientes, projetam e constroem os dispositivos mecânicos e as interfaces eletrônicas, desenvolvem o software, testam as máquinas e cuidam do transporte aos clientes. Ela é realmente incrível! Beth está em Boston por um mês, em visita 43
Gerência de Projetos de Software
ao seu irmão que vai se casar em breve. Nós três nos sentamos a uma mesa perto da janela. Manopoulos e eu pedimos sanduíches; Beth pediu uma salada. Todos pedimos cervejas. Afinal é sexta-feira e ninguém é de ferro. Enquanto nós esperávamos, Beth perguntou a Manopoulos como foi o projeto de software que ele liderou. “Você conhece aquele ditado, Beth, que diz que a estrada para o inferno é pavimentada de boas intenções? Pois é, nós tínhamos um time de desenvolvedores muito bom e planejamos muito bem; porém, não conseguimos entregar o projeto no prazo. A gente planejou, programou, pelejou, pelejou, mas não teve jeito, a vaca caminhou firme e resolutamente para o brejo.” – Manopoulos chamou o garçom – “Uma cerveja a mais, por favor!” Isto era uma coisa que a Beth simplesmente não conseguia entender. Como 32 desenvolvedores não conseguiram criar um produto? “Mas por que vocês falharam?” – ela perguntou incrédula. “– O que deu errado?” Eu lhe falei que nós tínhamos discutido os assuntos relacionados à preparação para o projeto pela manhã. A preparação para o projeto me parecera um tanto problemática. Eu lhe falei brevemente sobre os problemas que Manopoulos teve escolhendo os líderes de time, a reutilização inadequada de documentos e códigos do projeto de software do ano anterior e a falta de experiência dos times em assuntos relacionados a ambientes cliente-servidor. Eu também falei para Beth que nenhuma área específica é a causa de todos problemas. Explo44
João Alberto Arantes do Amaral
rando o processo de planejamento talvez nós pudéssemos descobrir outras áreas que contribuíram para o fracasso. Beth normalmente não gasta muito tempo fazendo planejamento quando ela cria suas máquinas, por isso ela está interessada em aprender mais sobre planejamento. “Fale-me sobre planejamento, Manopoulos. Você pensa que isso é realmente importante?” – ela perguntou com um olhar maroto. Manopoulos pegou um guardanapo e escreveu as seguintes palavras.
Figura 1
Beth olhou curiosamente para o guardanapo e nos falou que ela tinha lido ontem uma frase assim: “não há nenhum vento favorável para aqueles que não sabem aonde ir”. Manopoulos pensou um pouco e disse: “Essa frase tem tudo a ver com planejamento de projetos. Planejar é 45
Gerência de Projetos de Software
definir as medidas que você vai tomar de modo a atingir o seu objetivo. Mas onde foi mesmo que você leu essa frase?” “Eu li em um panfleto de um curso de vela do MIT ontem à tarde”, respondeu Beth sorrindo. Ela velejava às quartas e sextas à tarde, no Charles River, um rio caudaloso que separa Cambridge de Boston. As cervejas chegaram e eu perguntei a Manopoulos como era a estrutura de times adotada. Ele sacou da sua pasta uma tabela que mostrava a constituição dos dez times (tabela 1) Tabela I Times
Número de Pessoas
Gerente de Projeto
1
Gerentes de Negócios
3
Gerentes de Marketing
2
Analistas
6
Projetistas
5
Gerentes de Configuração
3
Garantia da Qualidade
4
Gerentes de Conhecimento
2
Programadores
3
Testadores
3
Eu perguntei a Manopoulos se havia algo errado na composição dos times. Como um projeto de software poderia ter tão poucos programadores? “Em nosso projeto, todo o mundo tinha por segunda função ser programador. Os três programadores mostrados 46
João Alberto Arantes do Amaral
nesta tabela eram na verdade os líderes de sub-times de programação. Um liderava o desenvolvimento das GUI, o segundo conduzia o desenvolvimento das classes em JAVA e o terceiro liderava a criação do Banco de Dados”, ele explicou. Beth estava surpresa. Ela nunca havia trabalhado com tantos desenvolvedores em um único projeto. Ela também estava confusa sobre quais eram as responsabilidades de cada um destes times. “Quais eram as responsabilidades de cada time? Onde elas foram definidas?” – ela perguntou. Manopoulos sabia as responsabilidades de cor. Afinal, ele penou um bocado para explicar as responsabilidades de cada time aos membros do projeto. “Respondendo à sua segunda pergunta em primeiro lugar, as responsabilidades estavam definidas no plano de gerência de projeto” (Amaral et. al., 1999). “Bem, eu vou te dizer as responsabilidades de cada time rapidamente, pois sei de cabeça. O time de Gerência de Marketing é o responsável por identificar as características de mercado, tendências de tecnologia, necessidades dos clientes e estratégia de propaganda. O time de Gerência de Negócios analisa os competidores no mercado e desenvolve a estratégia competitiva. O time de Gerência de Negócios é responsável também por definir as características desejáveis para o produto baseado nas necessidades de mercado. Os Gerentes de Negócios trabalharam conjuntamente com os Gerentes de Marketing a maior parte do tempo.” 47
Gerência de Projetos de Software
Enquanto Manopoulos falava, eu pensava na diferença entre as responsabilidades do time de Gerência de Marketing e do time de Gerência de Negócios. Parecia-me que ambos os times tinham responsabilidades complementares. Bem, eu preferi não dizer nada e deixar que Manopoulos falasse.
Ele estava se tornando mais agitado, gesticulava nervosamente. Era fácil perceber que ele gostava de seu trabalho. Do que eu gosto? Sem dúvida dos olhos verdes de Beth, mas isso é outra história… As cervejas chegaram finalmente à nossa mesa. O fator cerveja fez Manopoulos falar mais rapidamente: “O gerente de projetos é o responsável pela organização, planejamento, monitoração e controle do projeto. O gerente de projetos é responsável pela criação do Plano de Gerência do Projeto e por tomar as medidas necessárias para assegurar que o plano seja seguido. Ele também é o responsável por alocar recursos para os times de acordo com a necessidade, dando o apoio necessário, coordenando as atividades e mantendo canais de 48
João Alberto Arantes do Amaral
comunicação eficientes. O Gerente do Projeto é o responsável pela entrega de um produto de qualidade, dentro do prazo e do orçamento. Os Analistas são os responsáveis por traduzir as metas dos Gerentes de Negócios em requerimentos de software. O time usa várias ferramentas (por exemplo os diagramas de Uso de Casos da UML) para especificar as funcionalidades desejadas para o sistema. Os analistas interagem bastante com os clientes, procurando entender as suas necessidades. A responsabilidade principal do Time de Projetistas é detalhar os requerimentos do software, definidos pelo time de Análise, de forma a dar condições ao time de Programadores de criar o código. Os projetistas usam ferramentas tais como o Rational Rose, Diagramas da UML etc. O papel do Time de Programadores é criar código de qualidade, bem documentado, conciso e que siga fielmente o que foi estabelecido pelos Projetistas. A responsabilidade principal dos testadores é descobrir erros e verificar se o programa opera da forma desejada. Casos de teste são ferramentas utilizadas para identificar erros.” Eu confesso que a essa altura do campeonato eu já estava quase dormindo. Eu já havia estudado desenvolvimento de software em alguns cursos; esta conversa estava me enfadando, mas Beth estava interessada. Ela nunca tinha feito qualquer curso relacionado à engenharia de software na sua graduação. A propósito, ela é Física. Finalmente, meu hambúrguer com queijo chegou e minha vida começou a fazer sentido novamente. Manopoulos continuou o seu discurso: 49
Gerência de Projetos de Software
“O time de Garantia de Qualidade é responsável por conduzir as inspeções, revisões de projeto e auditorias. O time é responsável por criar o plano de garantia de qualidade.” Neste ponto eu o interrompi e fiz um comentário: “Manopoulos, o time de Garantia de Qualidade é responsável pela qualidade do produto ou pela qualidade do processo de desenvolvimento?” “Ambos” – ele respondeu. “Na realidade durante o projeto eu trabalhei bastante em conjunto com o time de Garantia de Qualidade.” Beth perguntou quais eram as responsabilidades dos times de Gerência de Conhecimento e de Gerenciamento de Configurações. Manopoulos explicou: “O time de Gerência de Conhecimento é o responsável por manter o repositório WEB do projeto e por definir o formato padrão para os documentos de projeto. Os gerentes de conhecimento conferem diariamente o conteúdo do repositório WEB de forma a assegurar que os documentos estejam seguindo o padrão estabelecido e verificar se os mesmos foram publicados nas datas 50
João Alberto Arantes do Amaral
previstas. Se problemas surgissem, os gerentes de conhecimento contatariam os outros times e informariam o gerente de projeto. O time de Gerência de Configurações controla e armazena os produtos que são gerados pelo diferentes times e prontamente informa todos os integrantes dos times do estado atual do software (i.e. mudanças, versão, local de armazenamento). A responsabilidade principal deste time é ajudar os programadores a se organizarem, controlar e rastrear o trabalho deles. O time age como uma rede de segurança, evita que qualquer documento/código seja perdido ou apagado acidentalmente. Este time também é responsável por prevenir atualizações simultâneas de código e por notificar os programadores de erros que foram consertados (Humphrey,1990).” Beth gostou do modo que Manopoulos definiu as responsabilidades dos times. Tudo parecia tão claro a ela. “Mas por que você teve problemas em explicar as responsabilidades aos membros dos times?” – ela lhe perguntou. “Bem, sei lá, a definição de responsabilidades de times de projeto de software pode ser encontrada em qualquer bom livro de software. O problema é fazer o time entender e seguir suas responsabilidades, fazê-lo trabalhar harmoniosamente com os outros times. Quando você divide um grupo em times pequenos há uma tendência natural de cada time se especializar em seu próprio trabalho e se esquecer da otimização do produto final.” Beth concordou: “Muito interessante! Isso me faz lembrar de um livro que eu li há algum tempo, eu acho 51
Gerência de Projetos de Software
que o nome do livro é “Surely you’re joking, Mr. Feynman: Adventures of a Curious Character”. Preciso conferir o nome do livro; Richard Feynman é um físico, ganhador do prêmio Nobel. Ele foi chamado para descobrir o que deu errado com o projeto do Ônibus Espacial Challenger. Como você sabe, ele descobriu aquele problema com os anéis de vedação, os tais “O-rings”. Mas ele também percebeu (e não gostou) que os times que construíram a astronave não trabalharam de um modo muito integrado. Eles otimizaram o próprio trabalho em detrimento da otimização do produto final. Bem, em um projeto monstruoso assim, é bastante possível que os desenvolvedores não tivessem tempo para falar com os membros de outros times… Mas eu achei esta desvantagem do trabalho segmentado bem interessante. É engraçado como os mesmos tipos de problemas estão sempre presentes em qualquer projeto, independente de sua natureza.” É por isso que eu gosto de Beth, ela sempre tem algo interessante para dizer. Beth olhou novamente para aquele guardanapo (Figura 1) e perguntou a Manopoulos o que são requerimentos de performance. “Em geral, nós podemos dizer que requerimentos de performance são as características desejadas para o produto final. Em projetos de software, as características desejadas podem ser definidas em termos de portabilidade, velocidade, tipo de interface gráfica, características do banco de dados, arquitetura cliente-servidor, recursos multimídia, interfaces com outros sistemas e uso da Internet”, ele respondeu. 52
João Alberto Arantes do Amaral
“E o que são os produtos a serem entregues ?” – eu perguntei. “São os componentes principais do projeto. Em projetos de software os produtos a serem entregues são os códigos, os documentos técnicos e o guia do usuário.” “Eu nunca trabalhei com times situados em países diferentes” – observou Beth. “Qual foi a estrutura de comunicação que você usou?” “A comunicação diária entre times foi feita por meio de e-mails e pelo uso do software ICQ. Videoconferência e teleconferência foram usados raramente devido aos custos financeiros envolvidos. Nós definimos os seguintes mecanismos para reportar o progresso feito: • •
• •
•
Reuniões semanais de todos os componentes dos times com o gerente de projeto. Todos os relatórios escritos foram colocados no repositório de projetos na Web. Os documentos seguiram o formato especificado pelo time de Gerência do Conhecimento. Também foram colocados na Web todos os comentários e discussões sobre os documentos. Foi pedido aos líderes de cada time que lessem os comentários e que os discutissem com o gerente de projeto nas nossas reuniões semanais. Inspeções e revisões conduzidas pelo time de Garantia de Qualidade Recomendações do gerente de projeto. Estas recomendações eram fruto de nossas reuniões de quinta-feira e eram enviadas a todos via e-mail. Palestras de curta duração sobre as atividades desenvolvidas por cada time.” 53
Gerência de Projetos de Software
“A estrutura de comunicação me parece bastante boa” – eu disse, e Beth concordou. Beth tem muita experiência em identificar as atividades envolvidas na criação de um produto tangível como um cromatógrafo. Ela disse a Manopoulos que estava curiosa em saber quais eram as atividades principais envolvidas no desenvolvimento de software, um produto intangível. “Projetos de software envolvem atividades de desenvolvimento, apoio ao projeto e atividades empresariais (tabela 2).” Tabela II Atividades de desenvolvimento
• • • •
Atividades de Apoio de projeto
• • • •
Atividades empresariais
• •
Análise Projeto Codificação Teste Gerência de Projeto Garantia de Qualidade Gerência de Configuração Gerência do Conhecimento Gerência de Negócios Gerência de Marketing
“As atividades de desenvolvimento são a parte principal do processo de criação de software. São as tarefas técnicas: análise dos requerimentos, projeto, codificação e teste. As atividades de apoio ao projeto são atividades que ajudam a organizar o processo de desenvolvimento. Uma vez que nós definimos quais são as atividades, calculamos a duração delas e criamos a rede de atividades”. Neste momento, ele abriu sua maleta e nos mostrou o seguinte desenho (Figura 2). Beth perguntou como ele calculou a duração de cada atividade e como criou a rede. 54
Figura 2
João Alberto Arantes do Amaral
55
Gerência de Projetos de Software
“Há vários modos de se calcular a duração de cada atividade, depende do seu tipo. Por exemplo, para se determinar o tamanho do código a ser gerado, é bastante comum se fazer estimativas através de Análise de Pontos de Função. Nós não tivemos tempo para fazer estimativas precisas. Nossa estimativa estava baseada principalmente na duração das atividades do projeto do ano anterior e em nossa experiência profissional. A rede de atividades foi criada baseada no ciclo de vida que nós escolhemos. Se você olhar para a rede (Figura 2) poderá notar que há várias atividades planejadas para serem executadas em paralelo. Por exemplo, de modo a otimizar a utilização de nossos recursos, nós planejamos desenvolver atividades de Análise e de Projeto simultaneamente. As atividades de Codificação e o Teste também foram planejados de modo a serem realizados simultaneamente. Nós pretendíamos começar a testar o software sete dias após os programadores terem começado a desenvolver o código.” Mais cervejas chegaram, deliciosamente geladas. Cambridge no verão é muito quente e seco, o que fazia o nosso consumo de cerveja aumentar consideravelmente. Beth, já ligeiramente ébria, olhava atentamente aquele guardanapo (Figura 1) onde Manopoulos havia escrito as atividades básicas envolvidas no planejamento do projeto. Ela estava interessada em saber o que era mitigação de riscos. “Você ouviu falar da Lei de Murphy, Beth?” – eu perguntei, já meio zonzo de tanta cerveja. “Sim” – ela disse. “Se você percebe que há quatro possíveis modos nos quais algo pode dar errado, e evita estes, 56
João Alberto Arantes do Amaral
então um quinto modo para o qual você está desprevenido se desenvolverá prontamente!“ Manopoulos somou uma idéia: “Eu ouvi isto de um modo diferente, se você não atacar os riscos efetivamente, eles é que te atacarão efetivamente!” Nós estávamos rindo muito, talvez por causa do efeito da cerveja que torna tudo mais engraçado. Mas Manopoulos estava procurando algo na maleta dele. “Aha, aqui estão eles!” Ele retirou algumas folhas de
papel e as pôs sobre a mesa. A essa altura a nossa mesa já era uma bagunça total cheia de restos dos sanduíches, o capacete de bicicleta da Beth, guardanapos rabiscados e agora mais essas folhas. A garçonete começou a dar sinais de que queria nos ver pelas costas. Nós pedimos mais algumas cervejas de modo a melhorar nossa capacidade de raciocínio e tornar a garçonete mais feliz. Manopoulos nos mostrou em seqüência várias tabelas e explicou que ele seguira a abordagem de Pressman (Pressman,1997) para mitigação de riscos. 57
Gerência de Projetos de Software
“Primeiro nós definimos as categorias dos riscos e os identificamos.” Tabela III - Itens de Risco Lista de Riscos
Abreviação
Riscos associados ao Tamanho de Produto
TP
Riscos associados ao Impacto Empresarial
IE
Riscos relacionados ao Cliente
CL
Riscos associados ao Processo
PR
Riscos associados à Tecnologia
TC
Riscos associados ao Ambiente de Desenvolvimento
DE
Riscos associados ao número de pessoas e sua experiência
SS
Riscos associados ao Desempenho
DO
Riscos associados à estrutura de Apoio
AP
Riscos associados ao cronograma (schedule)
SH
“Então nós demos valores de impacto aos riscos” Tabela IV - Valores de Impacto para os Riscos Grau de impacto
Valores de Impacto
Catastrófico
1
Crítico
2
Marginal
3
Desprezível
4
“Depois disso nós listamos todos os riscos que fomos capazes de antecipar. Numeramos e classificamos por meio das categorias definidas anteriormente. Nós também definimos uma probabilidade de ocorrência para cada risco.” 58
TP TP TP IE PR PR PR PR PR DE DE SS TC TC SS SS DO TC SH
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Estimativas imprecisas quanto ao tamanho do software a ser criado Quantia pequena de software reutilizado Excessiva quantidade de documentação a ser gerada Grande número de sistemas com os quais o nosso software deve ser interoperável Pouca reutilização de documentos e códigos do projeto anterior Inconsistência entre sistemas diferentes Falta de treinamento em ferramentas de desenvolvimento Falta de ferramentas de software para apoiar processo de teste Falta de métricas de produtividade Poucas ferramentas disponíveis para gerenciamento de configurações Ferramentas de software não integráveis Pouca experiência prévia em desenvolvimento de software Uso de rotinas não testadas do projeto do ano anterior Problemas de integração com outros sistemas Desenvolvedores envolvidos em outros projetos Desenvolvedores abandonando o projeto Projeto não satisfaz todas as exigências Problemas na implementação de funções Qualidade afetada por escorregamento no cronograma Baixa Alta Média Alta Alta Alta Alta Baixa Alta Média Alta Média Média Média Alta
Alta Média Alta Média
Categoria Probabilidade
ID
Riscos
Tabela V - Riscos de Projeto
2 1 2 3 2 3 4 2 1 2 2 2 1 1 1
3 2 2 1
Impacto
João Alberto Arantes do Amaral
59
Gerência de Projetos de Software
“E finalmente nós agrupamos os riscos, em função do grau de impacto e da probabilidade de ocorrência.” Tabela VI - Riscos Agrupados Riscos ID
Probabilidade
Impacto
6,13,19
Alta
Catastrófico
3,9,15
Alta
Crítico
4,17,18
Média
Catastrófico
2,7,14
Média
Crítico
1,8,10
Alta
Marginal
5,12,16
Baixa
Crítico
11
Alta
Desprezível
“Baseado em cada categoria definida na tabela anterior nós desenvolvemos as estratégias de mitigação.” Ele nos mostrou um exemplo: Tabela VII - Exemplo de Estratégias Estratégia para mitigação de Riscos de Probabilidade Alta e de Impacto Catastrófico Risco 6 - Para assegurar consistência entre sistemas diferentes, nós implementamos as seguintes medidas: • Um Comitê foi formado com os líderes dos times. Este comitê se encontraria todas as semanas ou sempre que necessário para administrar as mudanças que poderiam afetar outras partes do projeto • Se uma reunião de um time tratasse de informação que também fosse pertinente a outro time, um membro do time externo deveria comparecer àquela reunião. Essa medida ajudaria a manter consistência e coerência entre os documentos e planos. • Os times de Análise e Projeto deveriam concordar nas ferramentas comuns a serem usadas desde o começo de desenvolvimento. Sugestão: usar UML. 60
João Alberto Arantes do Amaral
Risco 13 – Uso rotinas de projeto não testadas (do projeto do ano anterior) • Nós decidimos nomear dois testadores para executar testes nos programas do projeto anterior. Todo o código seria testado, mesmo que já tivesse sido testado no ano anterior. Risco 19 – Qualidade afetada por derrapagem no cronograma • Uma análise crítica na viabilidade dos requerimentos deve ser feita. Os requerimentos para as Versões 1 e 2 devem ser realísticos, levando em conta a curta duração do projeto e os vários compromissos assumidos. Um pacote de software pequeno e seguro é melhor que um grande e incerto. • Se ocorrer alguma derrapagem no cronograma nós cortaremos alguns requerimentos; nós não queremos sacrificar a qualidade.
Neste ponto nós todos estávamos cansados. Eu confesso que não estava prestando muita atenção ao conteúdo das tabelas, só na idéia principal. Eu penso que Beth estava fazendo o mesmo. Eu também não estava certo de quão sóbrios nós estávamos. Nós havíamos bebido muito! Pelo menos nós concordamos em um ponto: estava na hora de voltarmos para casa! No nosso caminho de volta Manopoulos estava cabisbaixo, pensando nos possíveis enganos que cometera em seu planejamento. Beth estava alegre, pensando no que ela havia aprendido do papo de boteco e como ela poderia usar essas dicas em seus próximos projetos de cromatógrafos. E eu pensava nos olhos verdes da Beth... Nós combinamos de andar de bicicleta de Manchester-by-the-sea até Gloucester no próximo fim de semana; talvez nós pudéssemos falar sobre assuntos relacionados à execução do projeto durante o percurso.
61
Referências
○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
[Amaral, 2000] Amaral, J.A.A (2000) Project Management in Distributed Collaborative Environment: The ieCollabCase Study , MIT, MSc Thesis, Ocean Engineering Dept/Civil Engineering Dept. [Amaral et. al., 1999] Amaral, J.A.A., Limansky I. and Abbot E.(1999).The ieCollab Project Management Plan, Obtido em 25 de maio de 2000, Web: http:// www.collaborate.mit.edu/FTP/P1 [Highsmith, 2000] Highsmith III, J. A. (2000). Adaptive Software Development: a collaborative approach to managing complex systems, New York, USA: Dorset House Publishing Company. [Limansky et al. 1999] Limansky I. et all, Master of Engineering Information Technology Class of 2000 (1999), The IeCollab project. Obtido em 25 de maio de 2000, Web: http://www.collaborate.mit.edu/FTP/P1 [Pressman, 1997] Pressman, R.S. (1997). Software Engineering: A practitioner’s approach. New York, USA: McGrawHill. [Humphrey,1990] Humphrey W.S. (1990). Managing the Software Process, Berkeley, USA: Addison-Wesley
63
CAPÍTULO
III
EXECUÇÃO DO PROJETO
Estudo de Caso
03
○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
“Os sete pecados capitais do projeto” “O pessimista reclama do vento; o otimista espera que ele mude de direção; o realista ajusta as velas.” William Arthur Ward
S
ão 08:35 de uma manhã de domingo deslumbrante. Beth, Manopoulos e eu estamos no trem, indo de Boston para Manchester. Nossas bicicletas se encontram amontoadas no final do vagão, amarradas no local apropriado. Nós pretendemos andar de bicicleta o dia todo e voltar no último trem antes do cair da noite. “Eis o plano” – disse Beth. “Ir até Manchester de trem, andar de bicicleta até Gloucester e fazer um piquenique no Stage Fort Park. Depois disso, contornar de bicicleta Cape Ann e pegar o caminho de volta para Manchester. Acho que levará aproximadamente cinco horas para fazer isso. No meio do caminho nós podemos fazer uma parada estratégica em Singing Beach e descansar por algum tempo na praia. Se nós ainda tivermos energia, podemos andar de bicicleta de Man67
Gerência de Projetos de Software
chester até Beverly. Que tal jantar em Lynch Park? Deixeme ver, nós podemos tomar o trem das 08:04 p.m. de Beverly para Boston. O que vocês acham?” Eu concordei com ela, que mais eu poderia fazer? Ela é uma ótima ciclista e sempre tem idéias bacanas. Manopoulos estava com muito sono para protestar, de forma que este ficou sendo o plano que nós iríamos seguir, aprovado agora por decisão unânime! Beth estava cheia de energia, ela abriu uma revista e começou a ler um artigo sobre o filme “Seven”. “Olha que interessante, aqui estão listados os sete pecados capitais (Hornby, 1995),” – ela passou então a lê-los um a um: “Avareza: ganância, um desejo extremo para riqueza ou ganho. Inveja: um desejo forte para ter as posses ou qualidades de outra pessoa. Glutonice: o hábito ou prática de comer ou beber muito. Preguiça: indolência, aversão ao trabalho. Luxúria: lascívia, desejo desenfreado. Vaidade: auto-estima exacerbada. Ira: raiva, fúria, rancor.” Ela sorriu maliciosamente para mim e perguntou – “Qual é o seu pecado favorito, Nelson?” “Glutonice”, eu respondi prontamente, “definitivamente este é meu pecado favorito. E o seu, Manopoulos?” “Preguiiiiiiiiiiiça…” – ele respondeu enquanto se espreguiçava. “Bom dia, Manopoulos!” – troçou Beth – “Você pode nos contar quais foram os seus pecados capitais durante a fase preparação para o projeto PATOLAB?” Manopoulos pensou por algum tempo e disse: 68
João Alberto Arantes do Amaral
“Em termos de preparação para o projeto, eu poderia dizer Glutonice. Nós tentamos morder mais do que nós podíamos mastigar. Nós fomos muito ambiciosos em termos de nossas metas: nós queríamos fazer tudo. Quase todos os participantes do projeto PATOLAB também estavam envolvidos em outros projetos. O tempo que nós dispúnhamos para trabalhar neste projeto era bastante limitado. Eu também poderia adicionar Vaidade. Nesta fase nós não fizemos nenhum estudo de viabilidade. Nós definimos o escopo do projeto, mas nós não analisamos se seria possível alcançar as metas estabelecidas. Talvez porque nós fôssemos muito vaidosos das nossas habilidades. Talvez porque nós estivéssemos muito otimistas. Sei lá, talvez porque nós não soubéssemos quão complexo o projeto viria a ser.” “E quanto à Preguiça?” – perguntou Beth, com uma expressão engraçada em seu rosto. “Sim, nós também fomos muito preguiçosos. Nós não gastamos o tempo necessário revisando os documentos do projeto do ano anterior.” “E quais foram os seus pecados no processo de planejamento?” – eu perguntei. “Eu poderia dizer Ganância; eu criei o plano de gerência do projeto sozinho. Eu deveria ter convidado a todos para participar na criação do plano, especialmente da definição das responsabilidades dos times.” “Cheelseeeaaaaaa, Chelsea. Lynn é a próxima parada” – o cobrador anunciou. “Seus tickets, por favor. Obrigado.” Beth entregou nossos tickets ao cobrador e voltouse a Manopoulos: “Manopoulos, a gente combinou semana passada de discutir como foi a execução do seu projeto. No seu ponto 69
Gerência de Projetos de Software
de vista, quais são as atividades mais importantes na execução de um projeto?” Manopoulos escreveu as seguintes palavras em um guardanapo e entregou para Beth.
Figura 1
“O que é monitoração e controle de um projeto?” – Beth perguntou. “Monitorar um projeto pode ser entendido como o conjunto de ações realizadas de modo a se acompanhar o desenvolvimento do projeto. Por meio delas checamos se o projeto está seguindo o planejamento. Controle de projeto são as medidas usadas para corrigir as divergências entre o projeto atual e o planejado. Está relacionado diretamente à monitoração, uma vez que a informação obtida pelo processo de monitoração é usada pelo controle, de modo a se tomar ações apropriadas. Há três áreas que são monitoradas e controladas durante a execução de um projeto: custo/cronograma, trabalho de engenharia realizado e desempenho técnico do produto. Todas as áreas são necessárias e complementares. Eu me dediquei bastante à medição do trabalho de engenharia, que é a área que sei mais. Bem, pelo menos eu pensava que sabia...” Eu percebi que Beth não entendeu bem as diferenças entre monitoração e controle de projeto. Assim eu 70
João Alberto Arantes do Amaral
criei um novo desenho em outro guardanapo (Figura 2). Eu queria contribuir para ampliar a coleção de guardanapos dela. Para falar a verdade eu queria mesmo era chamar a atenção da moça, você sabe como é…
Figura 2
“Obrigada, Nelson.” – ela agradeceu com um sorriso terno. “Mas o que isso significa?” Significa que eu quero chamar sua atenção, Beth – eu pensei. Mas não ousei dizer isso... “Este desenho (figura 2) mostra a relação entre monitoração e controle de projeto” – eu expliquei. “O nível desejado para o projeto é definido no plano de gerência do projeto. O nível atual do projeto é verificado por meio do monitoramento. Relatórios do projeto trazem os dados colhidos pelos diversos times.” “Mas como o gerente de projeto pode controlar o projeto? Quais são as ações de controle?” – Beth insistiu. “O gerente de projeto pode controlar o projeto somando mais recursos, re-alocando pessoal, mudando cronogramas, ou modificando o escopo” – eu respondi. “Os resultados das ações tomadas no projeto são também monitorados e este processo continua durante toda a dura71
Gerência de Projetos de Software
ção de projeto. Talvez Manopoulos tenha mais a dizer sobre isso. Como você monitorou e controlou o projeto PATOLAB?” – eu lhe perguntei. “No início do projeto PATOLAB,tornamos claro a todos os objetivos principais do projeto, tarefas e responsabilidades. Havia muitos objetivos, por conseguinte foi necessário salientar quais eram os objetivos chaves e desenvolver mecanismos para ajudar a rastrear o cumprimento destes objetivos. Para facilitar a verificação de que o projeto estava se desenvolvendo como planejado foram criados pontos de checagem. Monitoração está diretamente relacionada à medida do progresso nestes pontos de checagem. Como alguém já disse, se você não pode medir o progresso você não poderá controlar o projeto (Thamhain, 1992).” “Mas de que forma você mediu o progresso do projeto?” – insistiu Beth, com a sua curiosidade infinita. “Bem, nós criamos nossas próprias métricas. As métricas usadas em PATOLAB, apesar de serem simples, foram bastante eficientes. Para verificar o estado atual do projeto nós desenvolvemos planilhas que comparavam o estado planejado de cada tarefa com o seu estado atual.” “Swaaaaaaaaaampscott, Swampscott” – gritou o cobrador. “Salem é a próxima estação!” A região da Nova Inglaterra é muito bonita, ainda mais no verão. Casas antigas de madeira circundadas por muita vegetação ladeiam os trilhos. O trem (commuter rail) liga todas as cidades do Estado de Massachusetts. Além de ser um meio de transporte barato, é sempre pontual. Cortar o Estado de ponta a ponta de trem é uma experiência única, ainda mais se você tiver espírito aventureiro e levar consigo a sua bicicleta para passear pelas 72
0
15
Des. TM
Test
25
Des. MM
0
50
An. TM
Prog
50
An. MM
Feito
0
50
Des. TM
Test
50
Des. MM
0
50
An. TM
Prog
100
An. MM
Planejado
0
0
25
50
50
100
0
0
50
100
100
100
0
0
50
60
100
100
0
0
100
100
100
100
Chekpt 1 Chekpt 2 Chekpt 3
45
50
100
100
100
100
Chekpt 5
Figura 3
0
0
100
100
100
100
15
25
100
100
100
100
Chekpt 4
65
100
100
100
100
100
Chekpt 6
75
100
100
100
100
100
100
100
100
100
100
100
Chekpt 7 Chekpt 8
100
100
100
100
100
100
Chekpt 9
João Alberto Arantes do Amaral
cidades. Manopoulos começou a tirar da sua mochila algumas planilhas e alguns gráficos. “Aqui está um exemplo da planilha que nós usamos” – ele falou, enquanto mostrava a seguinte tabela (Figura 3).
73
Gerência de Projetos de Software
Manopoulos, percebendo que Beth estava confusa com tanta abreviação, explicou rapidamente as abreviações que ele usou na sua tabela (Figura 3). “Test significa atividades de teste, Prog, atividades de programação, Des.TM significa projeto dos módulos de gerência de transações, Des.MM projeto dos módulos de gerência de reuniões, An.TM significa análise do módulo gerência de transações, An.MM análise do módulo de gerência de reuniões. Ficou mais claro?” “Agora sim, consegui entender” – Beth respondeu sorrindo. “Mas bem que você podia ter usado uma notação menos chata! Mas como você sabia o estado atual do projeto?” “O estado atual do projeto foi calculado tomando-se por base os dados enviados pelos líderes dos times em seus relatórios semanais. Semanalmente eu reunia toda a equipe do projeto e mostrava alguns gráficos que indicavam onde o projeto estava. Estes gráficos, fruto da compilação dos dados enviados pelos times, davam uma idéia clara do andamento do projeto. Também mostravam os pontos de checagem. Dêem uma olhada no tipo de gráfico que eu me refiro (Figura 4).”
Figura 4 74
João Alberto Arantes do Amaral
Beth gostou do gráfico. Ela tem alma de artista, gosta de cores, desenhos, figuras e gráficos. Eu ainda estava curioso em saber detalhes de como ele coletou a informação usada para monitorar e controlar o projeto. “Mas como foi criado o relatório semanal dos times e que tipo de informação ele trazia?” – eu perguntei. “Isso é uma longa história, Nelson. Para monitorar o projeto, eu pedi aos líderes que enviassem um relatório semanal das atividades realizadas por seus times via e-mail. Nestes relatórios eles declaravam as tarefas a fazer e a porcentagem das tarefas efetivamente realizadas. Além disso, eles me escreviam sobre os problemas enfrentados, sugestões e críticas. Baseado nos relatórios dos times, eu criava o Relatório Semanal da Gerência do Projeto. Este relatório era apresentado aos times todas as terças-feiras pela manhã. Eu geralmente apresentava uma série de slides por meio de um equipamento de datashow. A apresentação era planejada para não durar mais que 15 minutos. A idéia desta apresentação era mostrar a todos os participantes do projeto o estado do projeto atual, os problemas que cada time estava enfrentando e as medidas tomadas pelo gerente de projeto de forma a reduzir estes problemas. Também era uma oportunidade para coletar mais informações sobre o projeto e para se discutir tópicos controversos. Nós seguimos a estrutura de tópicos (Tabela 1) proposta por Thamhain (Thamhain, 1992). Aqui estão os tópicos que nós cobrimos nas apresentações e as ferramentas que nós usamos.” 75
Gerência de Projetos de Software
Tabela I Relatório da Gerência de Projetos
Ferramentas usadas
Situação dos Trabalhos em andamento • Gráficos: Estado das Atividades, Estados do Projeto e Realizações dos Times Mudanças introduzidas
• Redes de atividades e gráficos de Gantt
Problemas e seu impacto
• Diagramas de causa-efeito • Matriz de solução
Progresso feito
• Resumo das atividades de time
Tópicos em abertos
• Lista de tópicos para discutir
“Beverly, Montserrat é próxima parada” – o cobrador anunciou. A cada parada do trem embarcavam pessoas interessantes. Chamou-me a atenção uma senhora já idosa, por volta dos seus sessenta anos, que trazia um patinete dobrável a tiracolo. Ela se sentou próximo ao nosso grupo e nos cumprimentou amigavelmente. Nós a cumprimentamos e Manopoulos continuou a sua explicação: “Como você pode imaginar, as apresentações não cobriam apenas o controle e monitoração do projeto, mas também a adaptação do projeto a riscos emergentes. Eu lhe explicarei sobre adaptação do projeto outro dia, por hoje é melhor que só falemos em execução de projeto. Todas as apresentações foram planejadas para conter alguns slides preparados e apresentados pelo time de Garantia de Qualidade. A idéia era que o projeto tinha de evoluir seguindo o plano, porém com qualidade. O gerente de 76
João Alberto Arantes do Amaral
projeto e time de garantia de qualidade trabalharam juntos para fazer esta apresentação útil para todos os times.” Beth olhou para o guardanapo (Figura 1) e notou que Manopoulos ainda não havia falado nada sobre a garantia da qualidade. “Manopoulos, como vocês lidaram com garantia de qualidade?”-perguntou Beth. “Para reduzir a quantidade de retrabalho, nós tentamos gerenciar o projeto com qualidade. O método mais usado para assegurar a qualidade do processo de desenvolvimento de produto é o modelo PDCA (Planeje(Plan), Faça(Do), Confira(Check), Atue(Act)). Eu descreverei as idéias básicas de PDCA brevemente (Clausing, 1994; et de Shiba al.1994). O modelo de PDCA é composto de quatro sucessões de ações definidas pelo verbos Planejar, Fazer, Conferir e Atuar. A parte de “PLANEJAR” do PDCA se refere à definição de metas e objetivos. No projeto PATOLAB o planejamento global foi descrito pelo plano de Gerência do Projeto. A parte “FAZER” está relacionada ao trabalho desenvolvido. Todas as semanas nós tínhamos vários times trabalhando em paralelo nas diversas atividades. A parte “CONFERIR” está relacionada à monitoração de atividades e a parte “ATUAR” está relacionada às atividades de controle de projeto. No projeto PATOLAB a atividade de “CONFERIR” era realizada conjuntamente pelo gerente de projeto e pelo time de garantia de qualidade. O relatório semanal dos times era a ferramenta usada para conferir se o projeto estava seguindo o planejamento. Baseado nestes relatórios, o gerente tomava duas ações diferentes (a parte “ATUAR” de PDCA) todas as semanas: ações de reativas e ações pró-ativas. Ações reativas estavam relacionadas com a melhoria do processo de 77
Gerência de Projetos de Software
desenvolvimento e com o melhoramento do plano de gerência de projeto para o próximo produto. Baseado no que os líderes dos times realçavam como sendo seus principais problemas, o gerente de projeto poderia alocar pessoal de modo a ajudar os times em dificuldades ou programar cursos sobre tópicos específicos. O relatório semanal também incluiu as sugestões de todos os integrantes do projeto. Estas sugestões ficaram registradas de modo a melhorar o plano de gerência de projetos do próximo ano. A ação próativa estava relacionada a modificações no planejamento. Durante o ciclo de vida do projeto PATOLAB foram feitas várias modificações no plano original.” Manopoulos deu para a Beth o seguinte desenho (Figura 5) que resume as suas explicações sobre PDCA.
Figura 5 78
João Alberto Arantes do Amaral
“Parece-me que a criação de um catálogo de lições aprendidas foi um subproduto da execução de projeto” – eu disse. “Exatamente! O modelo de PDCA era muito efetivo para assegurar qualidade no desenvolvimento do processo. Foram três os resultados básicos alcançados pelo uso do PDCA: a melhoria do processo de desenvolvimento, criação de um catálogo de lições aprendidas e aperfeiçoamento do plano de gerência do projeto. A melhoria do processo de desenvolvimento foi alcançada por meio de ações reativas, utilizadas para assegurar que o projeto seguisse o planejamento. Todas as semanas quando havia uma mudança no modo como o gerente de projeto estava monitorando e/ou controlando o projeto, estas mudanças eram incorporadas ao relatório semanal da gerência de projeto e o catálogo de lições aprendidas era atualizado. Eu, como gerente, também tive que fazer muitos ajustes no plano ao longo do projeto. Os ajustes do plano de gerência do projeto são exemplos de ações pró-ativas. Eu tenho um outro desenho que mostra isto de um modo mais claro. Deixe-me ver, aqui está (Figura 7). Beth, neste desenho a sigla FFA significa ações pró-ativas, e FBA significa ações reativas.”
79
Figura 7- Os ciclos de PDCA (Clausing, 1994) (Shiba et al., 1993)
Gerência de Projetos de Software
80
João Alberto Arantes do Amaral
Nós estávamos chegando ao nosso destino. Beth guardou rapidamente tudo em sua mochila: guardanapos, desenhos, refrigerante, biscoitos e a revista. “Mancheeeeeestaaaah, Manchester-by-the-sea!” – o cobrador anunciou.
81
Tópicos para discussão
○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
1) Alguém uma vez disse “diga-me como você vai medir meu esforço e eu lhe falarei como eu vou me comportar”. O que pensa você disto? 2) Quando nós estávamos andando de bicicleta, eu perguntei a Manopoulos sobre os aspectos negativos dos relatórios dos times. Ele disse: “Um ponto negativo para acentuar aqui é que o relatório semanal às vezes era criado sempre pela mesma pessoa de cada time. Às vezes as informações do relatório semanal refletiam apenas a sua opinião pessoal no lugar da opinião do time. Outro aspecto negativo do relatório semanal é que às vezes as sugestões e comentários não eram tão construtivos. Alguns times entenderam mal a natureza dos relatórios e criticavam o trabalho feito pelos outros times de um modo inesperado. Em suma, usavam o relatório como instrumento de vingança! Eu, como gerente do projeto, tive que filtrar estes comentários em nossa apresentação semanal para evitar piorar o nível de conflito entre times.” 83
Gerência de Projetos de Software
O que pensa você da idéia de relatório semanal dos times? Você alguma vez tentou monitorar e controlar um projeto? Como você tratou os dados do projeto? 3) Quais foram os pecados capitais realizados no projeto PATOLAB, no seu ponto de vista?
84
João Alberto Arantes do Amaral
Referências
○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
[Amaral , 2000] Amaral, J.A.A (2000) Project Management in Distributed Collaborative Environment: The ieCollabCase Study , MIT MSc. Thesis, Ocean Engineering Dept. [Thamhain, 1992] Thamhain, H.J. (1992). Engineering Management: Managing effectively in technology-based organizations. New York, USA: Wiley Series in Engineering and Technology Management. [Shiba et. al. 1993] Shiba S., Grahan A. and Walden D. (1993). A New American TQM: Four Practical Revolutions in Management. Portland, USA: Productivity Press. [Clausing, 1994] Clausing, D.(1994). Total Quality Development: a step-by-step guide to world-class concurrent engineering. New York, USA: ASME Press. [Hornby, 1995] Hornby A. S., Oxford Advanced Leaner’s Dictionary, Oxford University Press, New York, USA
85
CAPÍTULO
VI
ADAPTAÇÃO DO PROJETO
Estudo de Caso
04
○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
“Perseverar é tornar o impossível possível”
“Qualquer problema que enfrentamos não é tão importante quanto nossa atitude em relação a ele, isto é que irá determinar nosso sucesso ou fracasso”. Norman Vincent Peale
H
oje é dia 3 de julho. Os três mosqueteiros (Beth, Manopoulos e eu) estamos preparando nosso barco para nos unirmos amanhã à flotilha de embarcações que participará dos festejos de Celebração do Dia 4 de julho (Dia da Independência dos EUA) no rio Charles. Estamos terminando de limpar o convés, aduchar os cabos e remendar algumas velas. O nosso barco, o “Moleza”, tem 34 pés, um único mastro. Nós já demos uma volta ao redor do mundo com este barco valente, mas isso é outra história que eu posso lhe contar outro dia, quando você tiver tempo. Está muito quente e úmido, por isso nós decidimos dar um tempo nas atividades marinheiras e beber um pouco em um bar próximo que fica situado no meio do Es89
Gerência de Projetos de Software
planade Park, próximo ao Hatch Shell. Enquanto nós estávamos esperando pela comida e refrigerantes, Beth perguntou a Manopoulos sobre o seu projeto. “Manopoulos, eu estou curiosa sobre o que aconteceu com o projeto de PATOLAB. Na última vez que nós nos encontramos você me falou sobre os assuntos relacionados à Execução do Projeto. Você ficou de me explicar o modo que você lidou com as mudanças, com os imprevistos que ocorreram ao longo do projeto.” “Bem” – respondeu Manopoulos, “isso tem que ver com o que eu chamo de Adaptação de Projeto. Eu posso dizer que a Adaptação de Projeto englobaria as seguintes atividades:” Manopoulos escreveu as seguintes atividades em um guardanapo e entregou à Beth.
Figura 1
“O que você quer dizer por responder a problemas emergentes?” – eu perguntei. “Toda vez que alguma mudança significativa acontecia, todos os membros dos times eram avisados quanto ao impacto desta mudança. Por exemplo, olhe para este desenho (Figura 2). Ele mostra claramente a mudança na rede de atividades de projeto. 90
Figura 2
João Alberto Arantes do Amaral
91
Gerência de Projetos de Software
Esta figura foi usada por mim em uma reunião semanal para mostrar a todos os integrantes do projeto as mudanças realizadas. Neste caso específico eu usei este desenho para mostrar a todos que ao invés de realizarmos dois esforços de integração de código nos realizaríamos apenas um esforço, ao final do projeto. Essa mudança foi baseada nas sugestões dos times de desenvolvimento. Os desenhistas e programadores haviam sugerido em seus relatórios semanais que seria melhor codificar as funções de Gerência de Transações e Gerenciamento de Reuniões ao mesmo tempo, porque isso reduziria os problemas de integração entre os dois módulos. A sugestão foi aceita por mim e a modificação de cronograma foi implementada e apresentada a todos. Note que as sugestões dos desenhistas e programadores foram baseadas em um melhor entendimento dos problemas técnicos envolvidos na criação do software. À medida que o nível de entendimento aumentava gradualmente, o planejamento ficava mais preciso.” “O que você quer dizer com um melhor entendimento de problemas técnicos?” – Beth perguntou curiosamente. Fazia um calor infernal naquela tarde, estávamos famintos e sedentos. Ofereci a Beth batatas fritas e refrigerante, e ela aceitou prontamente. Manopoulos alheio ao calor e ao que acontecia à sua volta continuou o seu discurso. “A maioria dos projetos é complexa. No início do projeto é impossível prever em detalhes todas as atividades envolvidas. Eu, como gerente, criei um plano de desenvolvimento baseado no que sabíamos sobre o pro92
João Alberto Arantes do Amaral
duto desejado no começo do projeto. O problema é que, quando o plano do projeto foi concebido, nem eu e nem ninguém tinha uma visão clara de todas as tarefas envolvidas e de todas as dificuldades técnicas que aconteceriam. Com o desdobramento do projeto, os times foram descobrindo atividades novas que deveriam ser acrescentadas ao projeto. Nós sabíamos o que fazer, mas nós não tínhamos uma idéia clara de como fazer. Por exemplo, nós sabíamos que o software teria três partes principais, a parte de rotinas de entradas de dados, o que nós chamamos simplesmente de parte do “Cliente”, a parte de rotinas de negócios, que nós apelidamos de parte do “Servidor” e a parte do “Banco de Dados”. Esta última parte envolvia não só a criação de rotinas de acesso e atualização do Banco de Dados, mas também a criação de um banco de dados propriamente dito. Porém nós não estávamos seguros sobre as ferramentas que nós iríamos usar para construir cada parte. À medida que o projeto evoluía, o time de Análise de Reque93
Gerência de Projetos de Software
rimentos e o time de Projetistas definiam o sistema em detalhes, as interfaces a criar e as ferramentas a usar. A parte “Cliente” foi dividida em três componentes: ClienteGUI (Interface Gráfica do Usuário), Cliente-Classes em Java, e Interface Cliente-CORBA. A parte “Servidor” foi dividida em dois componentes: Interface Servidor CORBA e Classes do Servidor Java. Finalmente, a parte “Banco de dados” foi dividida em Interface JDBC/SQL e Banco de Dados Oracle.” Manopoulos nos mostrou o seguinte desenho (Figura 3):
Figura 3 94
João Alberto Arantes do Amaral
“Dividir os sistemas em componentes torna mais fácil a compreensão e mais simples o gerenciamento. Uma vez que o sistema foi dividido, nós dividimos os programadores em cinco times (Figura 4). Tentamos fazer a divisão em times de modo a casar as habilidades individuais de cada programador com a dificuldade do módulo.”
Figura 4
Eu voltei a olhar para a figura no guardanapo (Figura 1). Acredito que entendi as idéias de Manopoulos sobre “responder problemas emergentes”. O que não estava claro 95
Gerência de Projetos de Software
para mim era o conceito de mitigar riscos emergentes. Nós tínhamos discutido o seu plano de mitigação de riscos há algum tempo (Estudo de Caso 01), eu me recordo que era um plano bastante razoável: “O que você quer dizer por mitigar riscos emergentes? Havia riscos que não foram cobertos pelo seu plano de mitigação de riscos?” – eu perguntei atônito. “Se eu tivesse uma bola de cristal naquele momento, minha vida seria muito mais fácil. Sempre há algo de novo surgindo, algo inesperado, algo que você não estava preparado para enfrentar” – respondeu Manopoulos. “Você pode dar um exemplo?” – Beth perguntou. “Ok, Beth, eu darei um exemplo de como nós mitigamos os riscos emergentes. Todas as semanas os líderes de time enviavam um relatório com as atividades que deveriam ser feitas naquela semana, o que foi efetivamente realizado, problemas e sugestões. Baseado na avaliação deles, o gerente do projeto (eu, digase de passagem) listava os riscos emergentes e trabalhava para descobrir uma solução para eles. Por exemplo, olhe para os riscos emergentes listados pelos times na nona semana do projeto.” Ele nos mostrou a seguinte tabela (Tabela 1): Tabela I Problemas da semana 09 (1) Controle de projeto ineficiente
96
Assuntos discutidos & Riscos Emergentes • Os líderes dos times não passavam informações quanto ao andamento das atividades ao gerente do projeto • Ignorância sobre os problemas dos times
João Alberto Arantes do Amaral
• Falta de coordenação e controle de atividades com o time do México • Liderança pobre e falta de habilidade para ad ministrar conflitos • Pouco envolvimento dos líderes dos times em atividades de planejamento/controle • Falta de interesse dos desenvolvedores no cro nograma • Dificuldades em mitigar os riscos, até mesmo os que já haviam sido identificados (2) Comunicação • Todo o tipo de problemas de comunicação entre inadequada os times situados em outros países e o time local (times dos E.U.A. x time de México x time do Chile). Problemas de comunicação entre times (time de Analistas x time de Projetistas) e entre os membros de cada time (3) Dificuldades Técnicas
• Dificuldade para definir o trabalho em detalhes • Falta de conhecimento em banco de dados e middleware (Corba, JDBC, Client/Server) • Muitas mudanças de última hora nas especificações
(4) Falta de motivação
• Falta de reconhecimento pelo trabalho realizado • Pouco crescimento profissional • Vários membros dos times do México e E.U.A. abandonaram o projeto • Ausência de um sistema de recompensa /punição
• Indiferença e apatia (5) Falta de comprometimento (6) Conflito e confusão
• Pouca confiança mútua • Cooperação pequena entre times • Nenhum controle dos líderes dos times sobre seus subordinados • Compartilhamento ineficiente de conhecimento
97
Gerência de Projetos de Software
“Ok, mas o que fez você quanto a isso?”, eu perguntei. “Baseado nas informações disponíveis, eu e o time de Garantia de Qualidade desenvolvemos um diagrama de causa-efeito para entender as causas principais dos problemas.” – Manopoulos respondeu e sacou de um diagrama (Figura 5) na sua mochila.
Figura 5 98
João Alberto Arantes do Amaral
“Uau!” – Beth disse, “que desenho bonito! Mas para que isso serve?” “Uma vez determinadas as raízes dos problemas (retângulos hachurados), o próximo passo foi nomear pessoas para que atacassem esses problemas. Nós criamos uma matriz de solução (Tabela 2). A matriz resume as medidas levadas a cabo de modo a endereçar os riscos emergentes. Basicamente esta matriz mostra as raízes dos problemas, as pessoas que foram escolhidas para atacar os problemas, as datas estabelecidas para se alcançar resultados e a descrição do modo que o problema seria resolvido.” Tabela II Descrição Quem do Problema (Ação)
O que
Quando
• Curso • 24 de Insuficiente Gerente conhecimento de Projeto sobre CORBA/JDBC fevereiro • Palestras técnicas em • Março técnico assuntos relacionados ao desenvolvimento em ambiente de Cliente-Servidor
Falta de feedback dos líderes ao gerente
Gerente Obrigar os líderes a enviar de Projeto o relatório semanal
Como
• Curso
de curta duração para programadores • Palestra técnica com especialista
Toda e-mail Segundafeira até 12:00
Falta de coor- Subdenação com gerente A o México
Manter contato semanal com Toda Por o time do México Segunda- e-mail ou feira até telefone 12:00
Pouca liderança por parte dos líderes dos times
Líderes dos times
Enviar cópias de e-mails trocados entre os times para o gerente do projeto
Organização de projeto pobre
Gerente Planejar a inclusão de de Projeto elementos de ligação no planejamento
Diariamente
e-mail
Sugestão para o próximo projeto
Incluir no catálogo de lições aprendidas
99
Gerência de Projetos de Software
“Esta tabela e a figura anterior (Figura 5) que eu mostrei a vocês dão uma visão clara dos problemas que aconteceram na nona semana do projeto e das ações de corretivas implementadas de modo a solucionar estes problemas. Eu mostrava figuras e tabelas deste tipo na reunião semanal que fazia com todos. Isto era uma mensagem clara aos times de que os relatórios semanais que eles me enviavam eram lidos e as recomendações dos times, levadas em conta.” “O que você quer dizer por comunicar as mudanças?” – Beth perguntou enquanto olhava para o guardanapo rabiscado por Manopoulos (Figura 1). Eu estava sentando ao lado dela tentando organizar a sua coleção de guardanapos. “Bem, eu não tenho muito a dizer sobre isso. Todas as mudanças introduzidas no projeto de PATOLAB eram discutidas com os times em nossas reuniões semanais. Os times localizados em outros países participavam da maior parte de nossas reuniões, às vezes por meio de Web-conferência e outras vezes por Vídeo-Conferência ou Tele-conferência. A matriz de solução, o diagrama de causa-efeito e o cronograma do projeto foram colocados na parede da nossa sala de reunião. Nós também colocamos os documentos que detalhavam as mudanças introduzidas em nosso repositório-Web.” “E sobre a atualização do plano de gerência de projeto, o que você pode nos contar?” – eu perguntei. “Bem, eu tenho uma história interessante sobre isso. Eu, como gerente do projeto, tive que fazer muitos ajustes no plano durante a execução do projeto. Os ajustes do plano de gerência de projeto são exemplos de ações pró100
João Alberto Arantes do Amaral
ativas. Você se lembra da ferramenta de garantia da qualidade, o PDCA que nós discutimos semana passada? Eu lhe darei um exemplo de como isso funcionou. Durante as semanas 10, 11 e 12 o projeto paralisou.” Ele nos mostrou a seguinte figura (Figura 6).
Figura 6
“Por que o projeto paralisou?”, perguntou Beth incrédula. “As razões principais para uma paralisia de projeto são falta de foco, de direção e de prioridades claras (Lewis, 1998). Em nosso caso nós sofremos dos três problemas durante as semanas 10, 11 e 12 de projeto. Primeiro, tivemos os problemas de falta de direção e prioridades claras. O líder do time de programadores teve um pro101
Gerência de Projetos de Software
blema pessoal sério durante a semana 10 e viajou repentinamente para a Índia, não tendo tempo de definir tarefas aos líderes de programação. Só para relembrar, nós tínhamos três líderes de sub-times: um responsável pelo desenvolvimento do módulo “Servidor”, outro responsável pelo módulo “Cliente” e outro responsável para o módulo “Banco de dados” (Figura 4). Estes 03 líderes eram subordinados ao líder do time de programação. O líder do time de programação não pôde enviar qualquer relatório ao gerente do projeto. Como o time de programação não tinha ninguém designado para assumir as atividades do líder dos programadores em sua ausência, o caos se estabeleceu. Os programadores normalmente executavam as tarefas dadas pelos líderes dos sub-times, mas estes não tiveram a iniciativa para se reunir para dividir as tarefas entre si. Eles não definiram as prioridades claramente, o que causou o segundo problema, a perda do foco. Uma vez que todos os programadores também estavam envolvidos em outros projetos, quando eles perceberam este problema simplesmente passaram a se dedicar mais a outros projetos. Conseqüentemente quase nenhum progresso foi feito durante as semanas 11 e 12 em termos de programação. Em contrapartida, foi feito um bom progresso em termos de controle do projeto. Ficou claro para o gerente do projeto que o controle poderia ser melhorado se fosse criado um mecanismo para quantificar o esforço de cada time de programação. Dêem uma olhada nesta tabela, que torna claro o mecanismo que nós criamos para medir e informar o progresso de cada time de programação separadamente.” Ele nos mostrou a seguinte tabela (Tabela 3). 102
João Alberto Arantes do Amaral
Tabela III Item
Planejado
Feito
Líder
Projeto MM
2.1
100
100
A
Projeto TM
2.2
70
70
D
Cliente GUI
3.1.1
50
10
B
Cliente Classes Java
3.1.2
50
20
B
Interface CORBA Cliente Interface CORBA Servidor
3.1.3 3.2.1
40 30
30 30
B A
Classes Java Servidor
3.2.2
10
10
A
Interface SQL/JDBC
3.3.1
40
30
C
Projeto Banco de Dados
3.3.2
30
30
C
“O uso de um mecanismo de controle novo melhorou o processo de desenvolvimento e ajudou resolver o problema de paralisia. Os líderes dos sub-times de programação se tornaram mais ativos, as atividades individuais de programação foram definidas e o projeto avançou.” Eram quase duas horas da tarde. O Esplanade Park estava cheio de pessoas que vinham de toda parte dos EUA para celebrar o Dia da Independência. Nós decidimos voltar para nosso barco e terminar nossos arranjos. Manopoulos nos convidou para uma caminhada em Blue Hills na próxima semana.
103
Tópicos para discussão
○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
1) Eu estava pensando no que Manopoulos me disse sobre a paralisia do projeto. Ele disse que o líder do time de programação não pôde enviar qualquer relatório ao gerente do projeto. Eu estava pensando como isto poderia afetar a visibilidade do projeto. O que é visibilidade de um projeto? Como a situação descrita anteriormente pode afetar a monitoração e controle? 2) Beth me falou que para ela “responder a problemas emergentes” e “responder a riscos emergentes” é quase a mesma coisa. Eu discordo, o que pensa você disso? 3) O que pensa você sobre “Adaptação do Projeto”? Você alguma vez trabalhou em algo semelhante? Você pode me falar como fez adaptações a um projeto? 4) Em PATOLAB, Manopoulos usou a ferramenta de Garantia de Qualidade chamada “diagrama de causa e efeito”. Que outras ferramentas você poderia sugerir para ele usar?
105
Referências
○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
[Amaral, 2000] Amaral, J.A.A (2000) Project Management in Distributed Collaborative Environment: The ieCollabCase Study, MIT MSc. Thesis, Ocean Engineering Dept. [McConnell, 1996] McConnel,S.C.(1996). Rapid Development: taming wild software schedules. New York, USA: Microsoft Press. [Lewis, 1998] Lewis, J. (1998,September/October). Participative leadership or project paralysis. Women in Business, 50(5), 36-39.
107
Conclusão
○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○
Espero que você tenha se divertido lendo sobre o Projeto PATOLAB. Escrevi este livro sem pretensões acadêmicas, apenas relatei o que eu acho importante na gerência de projetos de software. Tenha em mente que há atividades que podem ser adicionadas ao conjunto das atividades citadas relacionadas à preparação, planejamento e adaptação. O modelo apresentado é apenas uma orientação, um guia inicial. Você pode adicionar ou suprimir atividades em função da complexidade de seu projeto. Cada projeto tem peculiaridades, mas de um modo geral, o modelo apresentado é abrangente o bastante para cobrir um grande número de projetos de software. Caso você tenha tido alguma dificuldade em tópicos relacionados à engenharia de software, não se preocupe, tenha um pouco de paciência que em breve lançarei um outro livro sobre o assunto. Mas há inúmeros sites interessantes sobre gerência de projetos, eu poderia recomendar os seguintes:
109
Gerência de Projetos de Software
Uma boa dica é o site do Project Management Institute http://www.pmi.org/publictn/pmboktoc.htm Vale a pena visitar este site, você pode inclusive fazer o download de manuais e estudos. • Outro site bem interessante é o da Carnegie Mellon Software Engineering Institute, http://www.sei.cmu. edu/cmm/cmm.html, uma vez que você leu algo a respeito de Modelos de Maturidade de Capacidade no estudo de caso 01. • Há livros de engenharia de software interessantes, entre eles eu ressalto o livro do Pressman (Software Engineering) e do Sommerville. • Recomendo também a leitura do livro Adaptive Software Development: A Collaborative Approach to Managing Complex Systems , de James A. Highsmith II •
Várias pessoas me perguntam o que aconteceu com Beth e Nelson. Isto é uma longa estória, talvez você fique sabendo no meu próximo livro! Caso você tenha comentários ou dúvidas sobre o livro, por favor me escreva
[email protected] Felicidades! João Arantes
110
APLICAÇÃO Livro-texto para as disciplinas "Gerência de Projetos de Software", "Gestão de Projetos", "Gestão de Tecnologia da Informação" de cursos de Graduação (Análise de Sistemas/Sistemas de Informação/Tecnologia da Informação), Pósgraduação, especialização e MBA. Leitura complementar para disciplinas que incluam atividades de planejamento, controle e execução de projetos. Leitura recomendada para profissionais que tenham sob sua responsabilidade a gerência de projetos de software.
João Alberto Arantes do Amaral
GERÊNCIA DE PROJETOS DE SOFTWARE
O livro traz uma abordagem inovadora e criativa ao ensino de Gerência de Projetos de Software. Ensina-se por meio de exemplos, a partir de discussões sobre práticas certas e erradas. É uma compilação de quatro estórias em que os personagens discutem entre si os principais aspectos envolvidos no gerenciamento de projetos de software. Eles comentam as ações tomadas pelo gerente de um projeto de desenvolvimento de um software complexo, um ASP (Application Service Provider). Os dados gerenciais apresentados no livro são na verdade dados reais coletados do projeto IeCollab (Intelligent Electronic Collaboration Project), projeto distribuído que envolveu 32 pesquisadores de três universidades, em três países diferentes (MIT – USA, CICESE – México e PUC – Chile). Cada estória versa sobre uma fase pela qual o projeto passa. Os personagens, de uma maneira divertida, discutem e refletem sobre as atividades envolvidas nas fases de preparação, planejamento, execução e adaptação de um projeto. Procurou-se abordar as atividades de uma forma bem descontraída, mantendo o foco apenas nos aspectos mais relevantes.
ditora
GERÊNCIA DE PROJETOS DE SOFTWARE
i
JOÃO ARANTES é graduado em Engenharia Mecatrônica pela Escola Politécnica da USP, Mestre em Computação e Sistemas pela COPPE-UFRJ, Master of Science pelo MIT (Massachusetts Institute of Technology), Doutor em Computação de Alto Desempenho pela COPPE-UFRJ.
