Gerenciamento Ágil de Projetos de Software

de Software De que se trata o artigo? Este artigo apresenta o histórico, a definição, os valores, os princípios e a estrutura de práticas do. Marisa Villas Boas Dias O Gerenciamento gil de Projetos ou Agile Project Management (APM) foi criado a partir dos valores e princípios dos Métodos Ágeis de Desenvolvimento de Software, retratados no Manifesto para o Desenvolvimento gil de Software (BECK et al, 2001). Conectado a iniciativas correlatas das indústrias de construção civil e aeroespacial (uma vez que o cenário de complexidades e incertezas era comum a todos), o movimento para o desenvolvimento ágil de software ampliou sua abrangência, sendo estendido ao gerenciamento de projetos (HIGHSMITH, 2004, p. xix). Chin (2004, p.1) afirma que [...] em projetos que envolvem tecnologia, balancear os requisitos do gerenciamento clássico de projetos e as necessidades de uma equipe altamente capacitada e criativa é mais uma arte que uma ciência. Explica Para que serve? Abordagens ágeis de gerenciamento de projetos de software surgiram com intuito de lidar com os principais pontos fracos das abordagens tradicionais. Conhecer estas alternativas ganha importância na medida em que novos projetos surgem com características diferenciadas que nos levam à necessidade de utilizar métodos mais ágeis para apoiar o planejamento e acompanhamento das atividades do projeto. Em que situação o tema é útil? Os projetos de desenvolvimento de software são normalmente caracterizados por um elevado grau de incertezas iniciais e, conseqüentemente, por uma grande dificuldade de detalhamento do escopo e de elaboração de um planejamento completo. Neste cenário de incertezas, abordagens ágeis para gerenciamento de projetos de software têm sido vistas como uma alternativa interessante. Conhecer tais abordagens é um passo fundamental neste cenário. 22 Engenharia de Software Magazine - de Software

METODOLOGIAS ÁGEIS que, se por um lado o excesso de formalidade e de processos tende a inibir a equipe e bloquear a inovação, por outro, a falta de estrutura pode fazer com que os objetivos do projeto nunca sejam atingidos. Por muitos anos, o gerenciamento de projetos se desenvolveu sobre uma sólida plataforma, capaz de dar suporte a diferentes tipos de projeto, nos mais variados ambientes. As organizações adotaram o Gerenciamento Clássico de Projetos, propuseram e implementaram melhorias e adaptações, criando seus próprios modelos e expandindo a plataforma clássica de gerenciamento de projetos (CHIN, 2004, p. 1-3). No entanto, Chin (Ibid.) explica que, como qualquer plataforma, o Gerenciamento Clássico de Projetos apresenta restrições e ao se aproximar do limiar de sua abrangência, estas restrições se tornam mais visíveis e o seu desempenho, menos efetivo. Continuar o desenvolvimento desta plataforma clássica, segundo o autor, em alguns momentos é mais difícil do que estruturar uma nova idéia. Neste contexto, Chin (2004, p. 1-3) propõe a criação de um novo modelo e não uma simples expansão do Gerenciamento Clássico de Projetos. O surge, então, como uma nova plataforma de gerenciamento de projetos (Figura 1), aplicável a ambientes voláteis e desafiadores, sujeitos a mudanças frequentes, em que o processo prescritivo e padronizado não mais se adéqua (CHIN, 2004, p. 1-3; HIGHSMITH, 2004, p. 5). Segundo Highsmith (2004) e Chin (2004), o Gerenciamento Ágil de Projetos se desfaz da postura antecipatória, fortemente calcada no planejamento prévio de ações e atividades, típica do gerenciamento clássico de projetos, e busca o desenvolvimento da visão do futuro e da capacidade de exploração. Enfocando este último ponto, Highsmith (2004, p. 6) afirma que são cinco os objetivos principais para um bom processo de exploração, que acabam por constituir a base para o Gerenciamento Ágil de Projetos: 1. Inovação contínua: entrega de produtos que atendam aos requisitos dos clientes e agreguem valor ao negócio. A ideia de inovação é associada a um ambiente organizacional cuja cultura estimule o autogerenciamento e a autodisciplina; 2. Adaptabilidade do produto: os produtos desenvolvidos devem não só oferecer valor ao cliente no presente, mas ser também adaptáveis às novas necessidades do futuro; 3. Tempos de entrega reduzidos: foco, direcionamento preciso e capacidade técnica da equipe são fundamentais para a redução dos prazos de desenvolvimento de produtos visando ao melhor aproveitamento das oportunidades de mercado e um melhor retorno sobre o investimento; 4. Capacidade de adaptação do processo e das pessoas: formação de equipes cujos integrantes estejam confortáveis com mudanças e que não as enxerguem como obstáculos e sim como desafios de um ambiente dinâmico; estabelecimento de processos que respondam rapidamente às alterações do negócio; 5. Resultados confiáveis: entrega de produtos de valor ao cliente, garantindo a operação, o crescimento e aumento da lucratividade da empresa. O pode ser visto como uma resposta de âmbito gerencial às crescentes pressões por constantes inovações, à concorrência acirrada, à necessidade de redução dos ciclos de desenvolvimento e implantação de novos produtos ou serviços e à necessidade de adaptação a um ambiente de negócio bastante dinâmico (HIGHSMITH, Ibid.). Definição, Valores e Princípios do Gerenciamento Ágil de Projetos Highsmith (2004, p.16) define o Gerenciamento Ágil de Projetos como [...] um conjunto de valores, princípios e práticas que auxiliam a equipe de projeto a entregar produtos ou serviços de valor em um ambiente desafiador. Os valores e os princípios descrevem o porquê do Gerenciamento Ágil de Projetos e as práticas descrevem como realizá-lo. Apesar de ratificar a necessidade de entregar produtos confiáveis aos clientes dentro de restrições de prazo e custos, comum ao Gerenciamento Clássico de Projetos, Highsmith (2004, p. 6) menciona que o pode ser considerado mais uma atitude que um processo, mais ambiente que metodologia. Extensões do Gerenciamento de Projetos Redução de eficácia e eficiência da plataforma clássica de gerenciamento de projetos Plataforma Clássica do Gerenciamento de Projetos Plataforma - Gerenciamento Ágil de Projetos Figura 1. Edição 20 - Engenharia de Software Magazine 23

Os valores principais deste novo enfoque de gerenciamento de projetos endereçam tanto a necessidade de criação e entrega de produtos ágeis, adaptáveis e de valor, como a necessidade de desenvolvimento de equipes de projeto com as mesmas características (HIGHSMITH, 2004, p.10). Os quatro valores centrais do são: 1. As respostas às mudanças são mais importantes que o seguimento de um plano; 2. A entrega de produtos está acima da entrega de documentação; 3. Priorização da colaboração do cliente sobre a negociação de contratos; 4. Os indivíduos e suas interações são mais importantes que os processos e as ferramentas. Com relação ao primeiro valor, Highsmith (2004, p. 10-11) afirma que os projetos exploratórios, alvo do Gerenciamento Ágil de Projetos, são caracterizados por processos que enfatizam a visão do futuro e a exploração, ao invés do planejamento detalhado e a respectiva execução. Highsmith (Ibid.) e Chin (2004, p. 1-3) mencionam que não se trata apenas de absorver pequenas alterações de escopo, prazo ou custo, mas sim, de dar abertura à mudança completa de planos, requisitos, tecnologia e arquitetura no decorrer do projeto. Highsmith (op. cit.) embasa seu ponto de vista, ao apresentar o caso de uma companhia que, erroneamente, se recusou a mudar o plano traçado inicialmente para um projeto de desenvolvimento de software, orçado em aproximadamente US$125 milhões, o que a levou a um grande e custoso desastre. Para Highsmith (Ibid.), [ ] planejar o trabalho e executar o plano não é um lema adequado a uma grande variedade de projetos, em especial para os projetos de desenvolvimento de novos produtos (ou software) ou àqueles relacionados a qualquer tipo de inovação tecnológica. Esta posição está alinhada às proposições de Thomsett (2002) e Chin (2004). Abordando o segundo valor, ao estabelecer a prioridade da entrega de produtos sobre a preparação de uma documentação exaustiva, Highsmith (2004, p. 11-12) argumenta que não se trata de menosprezar a importância da documentação, mas sim de assumir que os resultados só podem ser avaliados pela equipe de projeto e pelo cliente quando algo concreto é apresentado, ou seja, quando se tem um produto (ou software) operante. Highsmith (Ibid.) defende a manutenção de um patamar mínimo e suficiente de documentação para auxiliar o processo de comunicação e colaboração, propiciar a transferência de conhecimento, preservar a informação histórica, servir de base para a melhoria de produtos e processos e, algumas vezes, atender aos requisitos legais. O terceiro valor, por sua vez, tem por pressuposto o estabelecimento de uma parceria entre o cliente e a equipe de projeto, na qual cada um tem papéis e responsabilidades específicos e bem definidos, sendo cobrados por isso. Esta parceria deve ser marcada por uma forte colaboração e não por disputas contratuais (HIGHSMITH, 2004, p. 13). Apesar de reconhecer a existência de diferentes partes interessadas no projeto, Highsmith (Ibid.) menciona que o cliente deve reinar soberano e apresenta a seguinte definição de cliente: [...] um indivíduo ou grupo de indivíduos que usa os produtos ou serviços para gerar valor ao negócio. Considerando o quarto valor, Highsmith (2004, p. 13-14) afirma que os processos servem como guias ou trilhas e as ferramentas são utilizadas para melhorar a eficiência, mas sem pessoas com qualificações técnicas e comportamentais adequadas, nenhum processo ou ferramenta produz resultado algum. O movimento ágil deposita elevado valor no indivíduo e reconhece sua capacidade de auto-organização, autodisciplina e sua competência. Enfocando o sucesso na ótica do Gerenciamento Ágil de Projetos, Highsmith (2004, p. 27) menciona que o sucesso é direcionado pelas pessoas e suas interações e não por processos e estruturas. As competências e habilidades individuais, as interações entre pessoas ou equipes tecnicamente qualificadas e a capacidade da equipe aprender e aplicar os conhecimentos adquiridos são determinantes para o sucesso ou o fracasso de um projeto, estando estritamente ligados ao atendimento das expectativas do cliente. Como as pessoas são normalmente guiadas por um conjunto interno de valores, desenvolver a agilidade depende do perfeito alinhamento entre o ambiente e este sistema de valor de cada indivíduo. Esta é a razão pela qual o é fortemente calcado em valores e também o motivo por que muitas vezes é impossível a aplicação do Gerenciamento Ágil de Projetos em determinadas organizações ou equipes (tal como ocorre com a adoção dos Métodos Ágeis de Desenvolvimento de Software). Além dos valores, o possui um conjunto de princípios mestres, que norteiam sua aplicação. De acordo com Larson e LaFasto (1989), a liderança baseada em princípios é uma das características mais importantes das equipes de alto desempenho. Highsmith (2004, p. 27-28) estabelece seis princípios, divididos em duas categorias (Tabela 1), que auxiliam as equipes de projeto a determinar como proceder, ou seja, ajudam-nas a definir quais práticas são mais apropriadas, a gerar outras práticas quando necessário, ou mesmo, a avaliar algumas que venham a surgir e implementá-las com agilidade. Embora cada princípio seja útil se aplicado isoladamente, o sistema formado por eles cria um ambiente que encoraja e produz resultados mais efetivos (HIGHSMITH, Ibid.). Categoria Princípio Entregar valor ao cliente Valor ao cliente Gerar entregas iterativas e baseadas em funcionalidades Buscar a excelência técnica Encorajar a exploração Estilo de gerenciamento baseado na Construir equipes adaptativas (auto-organizadas e liderança e colaboração autodisciplinadas) Simplificar Tabela 1. 24 Engenharia de Software Magazine - de Software

METODOLOGIAS ÁGEIS Ciclo de Vida e Fases do Apesar dos processos não serem tão importantes quanto as pessoas no, isto não significa que não se dê importância a eles. Highsmith (2004, p. 79) e Chin (2004, p. 14) defendem que não se deve atribuir aos processos uma conotação negativa, vinculada ao excesso de documentação e padronização, à característica estática e prescritiva, difícil de ser mudada, conforme alardeiam alguns seguidores do movimento ágil. Segundo os autores, os processos, como qualquer outro elemento de uma organização, devem estar estritamente alinhados aos objetivos de negócio. Em se tratando de operações contínuas e repetitivas, processos prescritivos são plenamente justificáveis. Por outro lado, se o ambiente for dinâmico e volátil, a estrutura de processos deve ser orgânica, flexível e facilmente adaptável (HIGHSMITH, op. cit..; CHIN, op. cit.). Sendo assim, a estrutura de processos para o Gerenciamento Ágil de Projetos deve ter por foco o conceito de agilidade e englobar os princípios apresentados no tópico anterior, assim como assegurar o alcance dos objetivos de negócio. Para tanto, deve: Favorecer a exploração e a cultura adaptativa; Permitir a auto-organização e a autodisciplina; Promover a confiabilidade e a consistência possíveis, dados o grau de incertezas e a complexidade inerentes ao projeto; Ser flexível e facilmente adaptável; Permitir visibilidade ao longo do processo; Incorporar o aprendizado; Englobar as práticas específicas de cada fase; Prover pontos de verificação. Segundo Udo e Koppensteiner (2003, p. 5) e Highsmith (2004, p. 81), um projeto típico do possui uma etapa inicial, seguida por vários ciclos ou iterações. A cada ciclo é feito um novo planejamento de escopo, prazo, custo e qualidade, visando à entrega de produtos ou resultados e possibilitando incrementos de funcionalidades conforme a necessidade do negócio. Ao final das várias iterações tem-se o término do projeto. Este padrão ou fluxo típico dos projetos ágeis, bem como o nível de atividade, são apresentados na Figura 2. Esta estruturação favorece a entrega de valor e a geração de um ambiente que propicie o aprendizado contínuo (UDO; KOPPENSTEINER, op. cit.). O está estruturado em cinco fases assim descritas (HIGHSMITH, 2004, p. 81): 1. Visão: compreende a determinação da visão do produto e do escopo do projeto, a identificação da comunidade do projeto (clientes, gerente de projeto, equipe de projeto e outras partes interessadas) e a definição de como a equipe de projeto trabalhará em conjunto; 2. Especulação: engloba a identificação dos requisitos iniciais para o produto, a definição das atividades, o desenvolvimento de um plano de projeto (contendo entregas, marcos, várias iterações, cronograma de trabalho e alocação de recursos), a incorporação de estratégias para mitigação de riscos, as estimativas de custos e outras informações financeiras relevantes. Nesta etapa é elaborado um planejamento preliminar, seguido por planejamentos específicos a cada iteração; 3. Exploração: corresponde à entrega dos produtos planejados, através do gerenciamento da carga de trabalho e do emprego de práticas e estratégias de mitigação de risco apropriadas. Estas entregas são feitas sob a forma de incrementos de funcionalidades do produto e são divididas entre os ciclos do projeto; 4. Adaptação: compreende a revisão dos resultados entregues, a análise da situação atual e a avaliação do desempenho da equipe e do projeto, para eventual adaptação. Esta revisão objetiva não apenas uma comparação do realizado versus planejado, mas principalmente do realizado versus informações e requisitos atualizados do projeto, para a identificação das mudanças necessárias; 5. Encerramento: referente à finalização das atividades do projeto, à transferência dos aprendizados-chave e à celebração. O relacionamento entre estas fases pode ser visualizado na Figura 3. Nível de Atividade Planejamento Preliminar Planejamento a cada iteração Incrementos de funcionalidades ; Mudanças de escopo; Aceites ao final de cada iteração; Controle Contínuo Início Iteração 1 Iteração 2 Iteração 3 Iteração 4 Encerramento Figura 2. Edição 20 - Engenharia de Software Magazine 25

Visão Visão Escopo Comunidade do projeto Equipe do projeto Especulação Plano de entregas Exploração Lista de funcionalidades Ações de adaptação Adaptação Produto final Funcionalidades complementares Encerramento Figura 3. Após a fase Visão, as fases Especulação, Exploração e Adaptação se alternam a cada iteração, no intuito de refinar o produto do projeto. A etapa de Especulação é retomada com objetivo de planejar o novo ciclo, levando em consideração os resultados até então alcançados no projeto e os incrementos ou alterações de escopo solicitados até o momento. Algumas vezes, o retorno à fase Visão pode ser necessário, em especial quando se têm modificações muito significativas no escopo projeto. Uma vez obtido o produto final, segue-se o Encerramento do projeto (HIGHSMITH, 2004, p. 85). Práticas do Assim como o PMI (2004) sugere uma série de processos de gerenciamento de projetos, para cada fase do Gerenciamento Ágil de Projetos existe um conjunto de práticas, que em sua totalidade, formam um sistema de práticas. Este sistema não só alinha os valores e os princípios do Gerenciamento Ágil de Projetos, mas permite também a sua implementação (HIGHSMITH, 2004, p. 86). O autor, entretanto, é avesso à ideia da adoção de melhores práticas, ao afirmar que as práticas são apenas maneiras de se executar algo e que podem ser boas ou ruins, a depender do contexto em que estão inseridas. Highsmith (Ibid.) menciona que as práticas do Gerenciamento Ágil de Projetos se mostram úteis em uma grande diversidade de situações e que também podem ser aplicadas no Gerenciamento Clássico de Projetos. Por outro lado, admite que outras práticas, não mencionadas no modelo em questão, podem trazer benefícios aos projetos ágeis. Práticas da Fase Visão O propósito da fase Visão é identificar de maneira clara o que precisa ser feito e como o trabalho será realizado. Para tanto, suas práticas estão estruturadas em quatro categorias: visão do produto, escopo do projeto, comunidade do projeto e abordagem (HIGHSMITH, 2004, p. 88-92), que são apresentadas na Tabela 2. Categoria Prática Descrição Visão do produto Visão do produto e declaração de elevador Desenvolvimento de um conceito de alto nível do produto do projeto, de uma forma concisa e Arquitetura do produto visual, com a utilização de um texto simples, garantindo a uniformidade de entendimento e de discurso entre todos os envolvidos no projeto Desenvolvimento de uma arquitetura técnica do produto, que facilite a exploração e assegure um direcionamento à condução dos trabalhos e à organização da equipe de projeto, visando ao atendimento das expectativas dos clientes Escopo do projeto (objetivos e restrições) Folha de dados do projeto Elaboração de um documento que sumarize os pontos-chave do projeto em termos de escopo, prazo, custos, recursos, qualidade e riscos Comunidade do projeto Escolha das pessoas certas Montagem da equipe do projeto e definição de sua organização, buscando sempre atrair e Identificação dos participantes selecionar os melhores talentos Identificação de todas as partes interessadas no projeto, de forma a melhor entender e gerenciar suas expectativas Interface entre a equipe do cliente e a equipe do projeto Estabelecimento do processo de colaboração entre a equipe do projeto e a equipe do cliente Abordagem Adaptação de processos e práticas Definição de uma estrutura de processos e práticas com base em uma estratégia de autoorganização, que estabelece a forma de trabalho em conjunto da equipe do projeto Tabela 2. 26 Engenharia de Software Magazine - de Software

METODOLOGIAS ÁGEIS Práticas da Fase Especulação Segundo Highsmith (2004, p. 128-131), a fase Especulação tem por objetivo a elaboração de um plano de entregas que represente o melhor entendimento da equipe de projeto, em um dado momento do projeto. A utilização da palavra especulação no lugar de planejamento está estritamente relacionada ao reconhecimento do elevado grau de incertezas e de mudanças que caracteriza um projeto-alvo do. O plano resultante desta etapa é construído a partir de informações da especificação e da arquitetura do produto, dos riscos envolvidos, do padrão de qualidade ou do nível de defeito estabelecido, das restrições do negócio e dos marcos do projeto. As práticas de fase Especulação, repetidas a cada ciclo ou iteração, são divididas em duas categorias: estrutura analítica do produto e planejamento de entregas (HIGHSMITH, 2004, p. 132-164), sendo retratadas na Tabela 3. Práticas da Fase Exploração A fase Exploração visa a entrega dos produtos planejados, a cada ciclo do projeto, através do gerenciamento da carga de trabalho e do emprego de práticas e estratégias de mitigação de risco apropriadas (HIGHSMITH, 2004, p. 166-168). De acordo com Highsmith (Ibid.) e Chin (2004, p. 69-81), a essência do papel do gerente de projetos no não é a elaboração de um cronograma detalhado e a preparação dos relatórios de progresso (apesar de ambos fazerem parte de seu trabalho), mas sim a criação e o desenvolvimento de uma equipe de alto desempenho a partir de um grupo de pessoas e estabelecer um estilo de liderança e gerenciamento que encoraje a inovação e incentive a aceitação de situações de risco e de mudanças constantes. Neste contexto, Highsmith (2004, p. 169-209) propõe um conjunto de práticas divididas em três categorias: entrega segundo os objetivos, práticas técnicas e comunidade do projeto. Estas práticas podem ser visualizadas na Tabela 4. Prática da Fase Adaptação Se no cenário do os planos são especulações acerca do futuro, então é grande a necessidade de feedbacks frequentes e efetivos para a validação das hipóteses assumidas (HIGHSMITH, 2004, p. 213-215). As adaptações dependem do manuseio e entendimento de uma vasta gama de informações, que incluem o progresso do projeto, os riscos técnicos, a evolução dos requisitos do produto e a análise do mercado. A equipe de projeto deve avaliar e tomar decisões constantes sobre quatro pontos principais: Funcionalidades primárias, segundo a perspectiva da equipe do cliente; Qualidade do produto, de acordo com as perspectivas da equipe técnica; Desempenho da equipe do projeto; Progresso do projeto. A fase Adaptação possui apenas uma prática revisão do produto / projeto / equipe e ações de adaptação divida em várias subpráticas, como mostra a Tabela 5 (HIGHSMITH, 2004, p. 211-231). Prática da Fase Encerramento O Encerramento do projeto é tanto uma fase como uma prática. Como recursos humanos qualificados são normalmente escassos, há uma forte tendência por parte das organizações Categoria Prática Descrição Estrutura analítica do produto Lista de funcionalidades do produto Expansão da visão do produto, através da definição de seus requisitos, gerando uma lista de funcionalidades do produto Cartões de funcionalidades Criação de um documento padrão para o registro das funcionalidades e requisitos do produto e das estimativas de prazo para seu desenvolvimento Cartões de requisitos de desempenho Documentação dos requisitos de desempenho e operação do produto a ser entregue Planejamento das entregas Plano de entregas, marcos e iterações Desenvolvimento de um plano que apresente o caminho a ser seguido pela equipe de projeto para entregar o produto do projeto, de acordo com os objetivos de escopo, prazo e restrições delineadas na Folha de Dados do Projeto. São planejados vários ciclos ou iterações para refinamento do produto do produto final do projeto Tabela 3. Categoria Prática Descrição Entrega segundo os objetivos Gerenciamento da carga de trabalho Atribuição da responsabilidade pelo gerenciamento das atividades do dia-a-dia, necessárias para a entrega das funcionalidades a cada iteração, aos próprios integrantes da equipe de projeto Práticas técnicas Mudanças de baixo custo Redução dos custos das mudanças ao longo das diferentes fases do ciclo de vida do produto, alinhada à necessidade de entrega de valor ao cliente hoje, mas com vistas ao futuro Comunidade do projeto Aconselhamento e desenvolvimento da equipe Desenvolvimento contínuo das competências, habilidades e domínio técnico e de negócio dos integrantes Reuniões diárias de integração da equipe de projeto Decisões participativas Interações diárias com o cliente da equipe de projeto, enfatizando a autodisciplina e o espírito de equipe Realização de reuniões de integração com a equipe de projeto visando a coordenação diária das atividades do projeto Fornecimento à comunidade do projeto de práticas específicas para entender, analisar e/ou tomar decisões ao longo do projeto Realização de reuniões ou interações diárias com o cliente para garantir que os esforços do projeto sejam executados de forma a atender às suas expectativas Tabela 4. Edição 20 - Engenharia de Software Magazine 27

Prática Descrição Subprática Revisão do produto / projeto / equipe e ações de adaptação O objetivo desta prática é garantir que o feedback constante e o aprendizado de alto nível ocorram em todas as dimensões do projeto. - Grupo de foco com cliente - Revisões técnicas - Avaliação do desempenho da equipe do projeto - Relatório de progresso do projeto - Acompanhamento do escopo e do valor do trabalho realizado1 a cada iteração - Acompanhamento do cronograma de cada iteração - Acompanhamento dos custos e da utilização dos recursos (custo estimado ao término do projeto) - Acompanhamento da qualidade do produto do projeto - Informação à equipe do projeto - Ações de adaptação Tabela 5. Várias organizações interessadas; Várias organizações interessadas; Uma única organização interessada externas internas Projetos operacionais Gerenciamento Clássico de Projetos Gerenciamento Clássico de Projetos Gerenciamento Clássico de Projetos Projetos de desenvolvimento de novos produtos / Gerenciamento Clássico de Projetos / Gerenciamento Clássico de Projetos / processos Projetos de desenvolvimento de novas tecnologias / Gerenciamento Clássico de Projetos / plataformas Tabela 6. de transferi-los rapidamente para outra iniciativa, quando do término de um projeto, sem estes profissionais recebam, ao menos, os créditos pela realização. Entretanto, há várias atividades a serem realizadas na etapa final de um projeto. A primeira delas é a celebração, que tem dois propósitos fundamentais: reconhecer aqueles que trabalharam muito para que o projeto fosse entregue e marcar o encerramento do projeto. A segunda, menos glamorosa, diz respeito à limpeza de eventuais itens em aberto, à entrega da documentação final e à preparação dos relatórios financeiros e administrativos requeridos. Por fim, tem-se a condução de uma retrospectiva do projeto, visando à obtenção e à divulgação das lições aprendidas entre as equipes de projeto (HIGHSMITH, 2004, p. 231-232). O encerramento de um projeto, seja ele gerenciado segundo a abordagem ágil ou clássica, é fundamental e marca a transição do produto do projeto para a operação da organização (HIGHSMITH, Ibid.). Aplicações, Resultados e Limitações do Gerenciamento Ágil de Projetos Diferentemente dos Métodos Ágeis de Desenvolvimento de Software, não foram encontrados estudos analisando a eficácia, ou mesmo fornecendo indícios de resultados positivos (ou negativos) da aplicação do. Uma explicação para tal situação pode ser atribuída ao fato de o assunto ser bastante recente. O que se têm são indicações de alguns autores, como Thomsett (2002), Highsmith (2004) e Chin (2004), acerca dos potenciais de aplicação deste novo enfoque de gerenciamento de projetos. Highsmith (op. cit.) e Chin (op. cit.) sugerem a aplicação do em projetos de desenvolvimento de novos produtos, ou outros que requeiram alto grau de inovação, criatividade, que envolvam tecnologia de ponta, equipes de alto desempenho, que estejam sujeitos a incertezas ou inseridos em ambientes de negócio dinâmicos. Highsmith (2004, p. 4) indica formalmente o uso do Gerenciamento Ágil de Projetos para o desenvolvimento de software. Chin (2004, p. 13-21) propõe um modelo, apresentado na Tabela 6, para a verificação da aplicabilidade do Gerenciamento Ágil de Projetos, levando-se em consideração duas dimensõeschave, a saber: Tipo de projeto: projetos operacionais (projetos simples e que ocorrem regularmente na organização); projetos de desenvolvimento de novos produtos / processos; ou projetos de desenvolvimento de novas tecnologias / plataformas; Organizações envolvidas: apenas uma organização interessada no projeto; várias organizações internas interessadas no projeto; ou várias organizações externas interessadas no projeto. Nas áreas onde há a possibilidade de escolha, Chin (Ibid.) sugere que seja feita uma análise do contexto interno e externo, considerando aspectos culturais e a prontidão da organização e dos principais interessados no projeto para a adoção de um enfoque ágil, antes da definição da melhor abordagem. Esta colocação de Chin (Ibid.) é corroborada por Highsmith (2004) e considera as ponderações de Ambler (2002c), Cohen et al, 2003; Fowler (2003) e Nerur et al (2005). Isto porque tanto os Métodos Ágeis como o foram construídos sobre bases, valores e princípios similares e ambos pressupõem que as organizações estejam preparadas do ponto de vista cultural, organizacional e gerencial para a sua adoção. Apesar de não haver na literatura menção específica às limitações do, as ressalvas feitas por Turk et al (2005) e Nerur et al (2005) com relação aos 28 Engenharia de Software Magazine - de Software

METODOLOGIAS ÁGEIS Métodos Ágeis, em especial quanto à participação dos clientes, à questão da negociação de contratos, ao suporte a equipes de projeto distribuídas e à dependência da organização perante os integrantes da equipe de projeto, podem ser transpostas para o Gerenciamento de Projetos, dados os valores e princípios comuns. Cabe fazer uma ressalva, porém, quanto ao tamanho do projeto. Highsmith (2004, p. 85) afirma que os valores e os princípios do são aplicáveis a projetos de qualquer envergadura e, similarmente, as práticas podem ser empregadas em projetos de diversos tamanhos, havendo somente a necessidade de adaptação para equipes com mais de 50 integrantes. Comparação: Gerenciamento Clássico e Para finalizar a explanação sobre o Gerenciamento Ágil de Projetos é interessante o estabelecimento de uma comparação entre ele e o Gerenciamento Clássico de Projetos. Um possível alinhamento entre os enfoques clássico e ágil de gerenciamento de projetos pode ser feito através da comparação entre as principais características dos grupos de processos propostos pelo PMI (2004) Iniciação, Planejamento, Execução, Monitoramento e Controle e Encerramento e as fases do Gerenciamento Ágil de Projetos Visão, Especulação, Exploração, Adaptação e Encerramento (HIGHSMITH, 2004). Esta comparação tem por base o trabalho de Udo e Koppensteiner (2003, p. 3), sendo seu resultado apresentado na Tabela 7. A partir das informações da Tabela 7 acima e do exposto ao longo deste artigo, é possível verificar que as diferenças fundamentais entre o Gerenciamento Clássico de Projetos e o residem fundamentalmente em dois pontos: na relação Planejamento x Especulação e na dualidade Monitoramento e controle x Adaptação (UDO; KOPPENSTEINER, 2003; HIGHSMITH, 2004; CHIN, 2004). O Gerenciamento Clássico de Projetos, estruturado segundo uma visão de processos, conforme descrito pelo PMI (2004) e, anteriormente, defendido por autores como Verzuh (1999), Kerzner (2002), Maximiano (2002), Dinsmore e Neto (2004), entre outros, deposita uma grande importância no planejamento detalhado do projeto e nos processos formais de monitoramento e controle. Por outro lado, no Gerenciamento Ágil de Projetos, a ênfase é transferida do planejamento para a execução, visando à entrega rápida de valor ao cliente e à apresentação de resultados ao longo de todo o projeto; e do controle para adaptação, permitindo alterações substanciais de escopo a cada iteração, para atender às mudanças de requisitos do negócio (THOMSETT, 2002; UDO; KOPPENSTEINER, 2003; CHIN, 2004; HIGHSMITH, 2004). Com relação às áreas de conhecimento, também é possível traçar um paralelo entre Gerenciamento Clássico de Projetos e o, em uma adaptação do trabalho de Udo e Koppensteiner (2003, p. 6). A avaliação, apresentada na Tabela 8, aponta que praticamente todas as áreas de conhecimento são abordadas pelo Gerenciamento Ágil de Projetos, porém com um enfoque diferenciado, dada sua ênfase na entrega de valor ao cliente, na resposta rápida às necessidades de mudanças e na valorização do indivíduo. Considerações Finais Os projetos de desenvolvimento de software são normalmente caracterizados por um elevado grau de incertezas iniciais e, consequentemente, por uma grande dificuldade de detalhamento do escopo e de elaboração de um planejamento completo. Novos processos de negócio, linguagens de programação, ferramentas, arquiteturas e aplicações inovadoras são constantemente introduzidos. Muitos autores afirmam que neste cenário, ciclos rápidos de especificação, teste, validação e implantação podem produzir resultados mais vantajosos que o desenho e o planejamento integral de todo o projeto (AUER; MILLER, 2002; BECK, 2000; BECK; FOWLER, 2001; JEFFRIES et al, 2001; CHIN, 2004; COCKBURN, 2001; SCHAWABER, 2002; SCHWABER; BEEDLE 2001; HIGHSMITH, 2002; 2004; POPPENDIECK; POPPENDIECK, 2003; AMBLER, 2002a; COHEN et al, 2003; FOWLER, 2003; UDO; KOPPENSTEINER, 2003). Várias iterações em curtos períodos de tempo tendem a maximizar o aprendizado da organização e a potencializar o desenvolvimento da equipe de projeto. Cohen et al (2003, p. 46-47) escreve que [...] indubitavelmente os Métodos Ágeis vieram para ficar. Entretanto, estes autores, assim como outros (PAULK, 2001; GLASS, 2001; THOMSETT, 2002; UDO; KOPPENSTEINER, 2003; HIGHSMITH, 2004) acreditam que este novo enfoque não ocupará totalmente o espaço dos modelos clássicos de desenvolvimento de software, mas sim que as duas abordagens deverão trabalhar em sintonia (simbiose) no futuro. Embora alguns praticantes enxerguem uma grande distância entre os métodos ágeis e os clássicos, outros acreditam que se pode construir uma ponte entre eles, Grupo de Processos do Gerenciamento Clássico de Processos Iniciação: Autorização de um novo projeto ou fase e definição do escopo preliminar do projeto Planejamento: Planejamento integral e detalhado do projeto Execução: Execução do plano do projeto Fases do Visão: Determinação da visão do produto e do escopo inicial do projeto Especulação: Desenvolvimento de um plano inicial do projeto, seguido por planejamentos individuais a cada iteração Exploração: Entrega das funcionalidades / produtos previstos a cada ciclo Monitoramento e Controle: Ênfase no controle do progresso dos trabalhos e no controle e Adaptação: Revisão dos resultados entregues e abertura para adaptações do escopo, visando o atendimento gerenciamento de mudanças para minimizar os impactos no projeto aos novos requisitos do negócio Encerramento: Formalização do aceite final do projeto Encerramento: Aceites do cliente a cada ciclo ou iteração e formalização do encerramento do projeto ao final dos trabalhos Tabela 7. Edição 20 - Engenharia de Software Magazine 29

Áreas de Conhecimento Gerenciamento Clássico de Projetos Gerenciamento da Integração do projeto Assegura a coordenação dos vários elementos do projeto A necessidade de coordenação formal é limitada devido à redução a nível Gerenciamento do escopo do projeto Gerenciamento de tempo do projeto Gerenciamento de custos do projeto Gerenciamento da qualidade do projeto Gerenciamento de recursos humanos do projeto Gerenciamento das comunicações do projeto Gerenciamento de riscos do projeto Gerenciamento das aquisições do projeto mínimo de estrutura e de processos Assegura que o projeto contenha apenas o trabalho necessário para O escopo é fixo apenas quando as iterações estão em andamento. Não há completá-lo de forma bem-sucedida. Foco na definição e controle do que está ou não está incluído no escopo do projeto e em um processo bem do cronograma detalhado do projeto e no controle, para assegurar a controle formal do escopo ao longo do projeto, havendo a possibilidade de inclusão / alteração das funcionalidades do produto em cada iteração estruturado de gerenciamento de mudanças Foco na definição das atividades e estimativas de tempo para a elaboração O prazo é estabelecido apenas por iteração ou ciclo. Foco na entregar valor (funcionalidades) o mais rapidamente possível. O cronograma geral é finalização do projeto no prazo baseado em funcionalidades e não em atividades Foco na elaboração do orçamento do projeto a partir da necessidade de Determinação do orçamento em função da funcionalidade do produto recursos humanos e materiais e no controle, para garantir que o projeto seja requisitada. Os recursos, as funcionalidades e os prazos são balanceados e encerrado dentro do orçamento aprovado há uma preocupação em medir o custo por atraso Assegura que o projeto atenda às necessidades para as quais foi concebido. O sucesso do projeto é definido pelo cliente, que também apresenta seu Foco na conformidade e na adequação às especificações e na satisfação das parecer ao final de cada iteração. Foco na execução da visão e do propósito expectativas das partes interessadas no projeto do produto e na adequação ao uso Processos para que se faça o uso mais efetivo de todas as partes interessadas Foco na equipe e não no indivíduo. Busca o desenvolvimento de equipes de no projeto alto desempenho. Os incentivos são baseados na produtividade do grupo Assegura a geração, a coleta, a disseminação e o armazenamento periódicos Foco na eliminação de gastos e de todas as padronizações, documentações das informações do projeto e relatórios desnecessários. Garantia de acesso às informações a todos os envolvidos no projeto Foco na identificação, na análise e na proposição de respostas aos riscos do Não há uma maneira padrão sugerida para o tratamento de riscos. Cada projeto projeto deve adotar a sua própria abordagem Foco na aquisição de produtos ou serviços externamente à organização Segue os melhores princípios para aquisição de bens ou serviços dando executora, para a realização do projeto maior ênfase à colaboração (estabelecimento de parcerias) do que à negociação de contratos Tabela 8. possibilitando a troca constante de informações e experiências e, consequentemente, um aprimoramento do processo de desenvolvimento de software. Glass (op. cit.) destaca que os defensores dos métodos clássicos têm muito a aprender com os adeptos dos métodos ágeis, argumentando que o processo clássico de desenvolvimento pode ser enriquecido com a utilização de algumas das práticas propostas pelos Métodos Ágeis. Em contrapartida, uma das razões para que os Métodos Ágeis não se sobreponham totalmente ao desenvolvimento clássico de software é que alguns processos antigos ainda se fazem necessários. Lindvall e Russ (2000) ilustram esta diferença ao mencionar que [...] desenvolver um software para controlar um ônibus espacial não é o mesmo que desenvolver um software para um torradeira. Cohen et al (2003, p. 45) complementam que aplicações que possam vir a colocar em risco a vida humana devem passar por um rígido controle de qualidade, sendo o enfoque clássico preferido para seu desenvolvimento. Com relação ao gerenciamento de projetos, as ponderações seguem a mesma linha. O fato dos Métodos Ágeis de Desenvolvimento de Software e do Gerenciamento Ágil de Projetos terem a mesma origem e serem construídos sobre os mesmos valores e princípios pode sugerir que, possivelmente, o seja mais indicado para o gerenciamento de software realizado com o uso de Métodos Ágeis. Contudo, cabe salientar que não foram encontradas evidências durante a revisão bibliográfica que comprovassem (ou negassem) tal afirmação. Thomsett (2002), Highsmith (2004) e Chin (2004) indicam a utilização do em projetos que requerem inovação e criatividade ou que estejam sujeitos a alterações constantes dos requisitos do negócio, como por exemplo, os projetos de desenvolvimento de novos produtos (o desenvolvimento de software se enquadra nesta categoria). Mas apesar de mencionarem que o Gerenciamento Clássico de Projetos traz uma rigidez indesejada a projetos desta natureza, estes autores reconhecem a importância do arcabouço de conhecimentos aportado por este enfoque de gerenciamento de projetos, chegando a afirmar que, em determinadas situações, uma combinação do enfoque clássico com as novas práticas propostas pelo é mais apropriada para que se alcance resultados cada vez efetivos. Expandindo esta visão, Thomsett (op. cit.) chega a mencionar que as práticas do podem ser utilizadas até mesmo no desenvolvimento de software conduzido segundo um método clássico. Num contraponto, Paulk (2001) cita que os Métodos Ágeis e o SW-CMM (que tem por base o Gerenciamento Clássico de Projetos) não são incompatíveis, sugerindo que o Gerenciamento Clássico de Projetos pode ser aplicado no desenvolvimento de software realizado com o uso de Métodos Ágeis. Enfim, não há uma opinião única sobre o assunto. 30 Engenharia de Software Magazine - de Software

METODOLOGIAS ÁGEIS Todavia, é consenso entre os autores pesquisados que se deve fazer uma análise do ambiente interno (aspectos organizacionais e culturais) e do contexto externo no qual o projeto está inserido, para que se selecione o modelo de gerenciamento de projetos (clássico ou ágil) e se defina o método de desenvolvimento (clássico ou ágil) e o respectivo conjunto de processos, técnicas, ferramentas ou práticas a serem seguidos (AMBLER, 2002c; THOMSETT, 2002; COHEN et al, 2003; COHN; FORD, 2003; FOWLER, 2003; UDO; KOPPENSTEINER, 2003; HIGHS- MITH 2004; CHIN, 2005; NERUR et al, 2005). Por serem assuntos relativamente novos (os primeiros Métodos Ágeis, ainda incipientes, surgiram no final dos anos 90 e o embrião do surgiu em 2001), pouquíssimas são as pesquisas empíricas que versam sobre os benefícios de sua utilização, investigando diretamente a questão relativa ao enfoque de gerenciamento de projetos mais apropriado para o desenvolvimento de software com o uso de Métodos Ágeis, o que aumenta a motivação para o desenvolvimento deste estudo. Dê seu feedback sobre esta edição! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, leitor, acha da revista! Dê seu voto sobre este artigo, através do link: www.devmedia.com.br/esmag/feedback Dê seu Feedback sobre esta edição Referências ABRAHAMSSON, P et al. New directions on agile methods: a comparative analysis. In: Proceedings of the 25th International Conference on Software Engineering. [S.l.]. IEEE Software Society, 2003, p. 244-254. AGILE ALLIANCE. Manifesto for agile software development. Disponível em <http://www. agilemanifesto.org/>. Acesso em janeiro, 2005. AUER, K.; MILLER, R. Extreme programming applied. Boston: Addison-Wesley, 2002. AMBLER, S. W. Agile modeling: effective practices for extreme programming and the unified process. John Wiley & Sons, Inc., 2002a. AMBLER, S.W. Lessons in agility from internet-based development. IEEE Software, [S.l.], v. 19, n. 2, 2002b, p. 66 73. AMBLER, S.W. When does(n t) agile modeling make sense. Apr, 2002c. Disponível em <http:// www.agilemodeling.com/essays/whendoesamwork.htm>. Acesso em julho de 2005. AMBLER, S. W. Quality in an agile world. Software Quality Professional, [S.L.], v. 7, n. 4, sep. 2005. BECK, K. Embrance Change with Extreme Programming. IEEE Computer Magazine, [S.l.], Oct 1999, p. 70-77.. Extreme programming explained. Boston: Addison-Wesley, 2000. BECK, Kent. et al. Chrysler goes to extremes. Oct, 1998. Disponível em <http://www.xprogramming. com/publications/dc9810cs.pdf>. Acesso em julho, 2005. BECK, Kent et al. Manifesto for agile software development. Feb. 2001. Disponível em <http:// www.agilemanifesto.org/>. Acesso em janeiro, 2005. BECK, Kent; FOWLER, M. Extreme programming applied. Boston: Addison-Wesley, 2001. BECK, Kent; MEE, R. Enhancing brazilian software s global competitiveness. Jan, 2003. Disponível em: <http://www.xispe.com.br/wiki/wiki.jsp?topic=enhancingbrazilssoftwareglobalcompetiti veness>. Acesso em novembro, 2004. BOGER, M. et al. Extreme modeling. In: SUCCI, G.; Marchesi, M. (eds). Extreme programming examined. Boston: Addison-Wesley, 2001. BOHEM, Barry.; TURNER, Richard. Balancing discipline and agility: evaluating and integrationg plandriven methods. In: Proceedings of the 26th Conference on Agile Development. IEEE COMPUTER SOCIETY, [S.l.], May 2004, p. 718-719. BONATO, A. S. F. Uma experiência de aplicação do processo Extreme Programming em pequenos projetos. São Paulo, 2004. Dissertação (Mestrado em Engenharia) Programa de Pós-Graduação em Engenharia, Escola Politécnica da Universidade de São Paulo. BOOCH, G. Developing the future. Communications of the ACM. ACM Press, [S.l.], v. 44, n. 3, p. 118 121, 2001. CHIN, Gary. Agile project management: how to succeed in the face of changing project requirements. NY: Amacon, 2004. COCKBURN, A. Crystal clear: a human-powered methodology for small teams. Boston: Addison- Wesley, 2004.. Agile software development. Boston: Addison-Wesley, 2001.. Learning from agile software development part one. Crosstalk, The Journal of Defense Software Engineering, [S.l.], October 2002. COCKBURN, A.; HIGHSMITH, J. Agile software development: the business of inovation. IEEE Computer Magazine, [S.l.], p. 131-133, sep 2001a.. Agile software development: the people factor. IEEE Computer Magazine, [S.l.], p. 131-133, nov 2001b. COHEN, David et al. Agile software development: a DACS state of art report. NY: Data Analysis Center for Software - Fraunhoufer Center for Experimental Software Engineering Maryland and The University of Maryland, 2003. Disponível em <http://www.thedacs.com/techs/agile/>. Acesso em abril, 2005. COHEN, Dennis. J.; GRAHAM, Robert. J. Gestão de projetos: MBA executivo. Trad. Afonso Celso da Cunha Serra. Rio de Janeiro: Campos, 2002. COHN, Martin. The scrum development process. Disponível em <www.mountaingoatsoftware. com/scrum> Acesso em julho, 2005. COHN, Martin; FORD, Doris. Introducing an agile process to an organization. IEEE Computer Magazine, June 2003, [S.l.], p. 74-78. DINSMORE, P. C. The AMA handbook of project management. New York: AMACON, 1993. DINSMORE, P. C.; NETO, F. H. S. Gerenciamento de projetos: como gerenciar seu projeto com qualidade, dentro do prazo e custos previstos. Rio de Janeiro: Qualitymark, 2004. FOWLER, Martin. The new methodology. April, 2003. Disponível em <http://www.martinfowler. com/articles/newmethodology.html>. Acesso em julho, 2005. GAWLAS, J. Mission critical development with XP & agile process: common code ownership and lots of testing. Dr. Dobb s Journal, [S.l.], p. 21-24, Jan. 2004. Edição 20 - Engenharia de Software Magazine 31