Baixe o app para aproveitar ainda mais
Prévia do material em texto
Gestão de Projetos em Tecnologia da Informação Aula 05 Software Extension to the PMBOK® Guide Objetivos Específicos • Correlacionar os elementos propostos pelo Software Extension com os do Guia PMBOK®. Temas Introdução 1 Características e aspectos gerais de projetos de desenvolvimento de software 2 Software extension to the PMBOK® Guide Considerações finais Referências André Luis Fonseca Ricardi Professor Senac São Paulo - Todos os Direitos Reservados Gestão de Projetos em Tecnologia da Informação 2 Introdução Nesta aula será apresentado o conteúdo do Software Extension, que complementa o Guia PMBOK® – Um Guia de Conhecimento em Gerenciamento de Projetos (PMI, PMBOK, 2013). O Guia PMBOK® tem extensões (extensions) que contêm aquilo que seria aplicável a projetos de áreas específicas, identificando como estes elementos se associam àqueles que seriam aplicáveis a qualquer tipo de projeto, conteúdo primário do Guia PMBOK®. São manuais complementares com a finalidade de atender aos projetos de áreas específicas. O Software Extension não tinha tradução oficial para o português quando este material foi desenvolvido. Será apresentado a você aquilo que consideramos mais importante conhecer sobre esta publicação, mas certamente não conseguiríamos tratar aqui da totalidade de uma referência com quase 300 páginas. O fato é que você não deveria desprezar a possibilidade de aplicar algo que milhares de profissionais ao redor de todo o mundo entendem ser aplicável à maioria dos projetos de desenvolvimento de software. Na área de desenvolvimento de software é comum ouvirmos que algo é impossível de se aplicar em projetos, quando na verdade as pessoas estão acomodadas e não querem se esforçar para aumentar as chances de sucesso de seus projetos. Você entende que está bom assim, ou acredita que pode melhorar o desempenho de seus projetos? Responda esta pergunta com a certeza de que é preciso mudar, pois a concorrência melhora diariamente, tanto no aspecto empresarial quanto no pessoal. Se você e sua empresa ficarem acomodados, provavelmente terão dificuldades no futuro. Como profissional de TI não tenho receio em afirmar que muito pode ser melhorado, e de fato isso tem ocorrido. Aumenta de forma exponencial o percentual de empresas e profissionais que se preocupam em melhorar o desempenho dos projetos, pois como já foi dito, não se trata de opção, mas sim de sobrevivência. 1 Características e aspectos gerais de projetos de desenvolvimento de software O gerenciamento de projetos pode ser extremamente útil quando se fala sobre desenvolvimento de software, em especial por conta de características intangíveis que podem estar associadas ao produto. A concepção de um software pode terminar com uma visão muito diferente do que era no seu início, o que dificulta sobremaneira gerenciar o seu desenvolvimento (PMI, Software Extension, 2013). Senac São Paulo - Todos os Direitos Reservados Gestão de Projetos em Tecnologia da Informação 3 É comum o cliente não ter certeza sobre os requisitos que o software precisará atender, e sem requisitos e critérios de aceitação consistentes fica quase impossível medir o sucesso de um projeto. Assim sendo, coletar os requisitos é um processo vital para desenvolver software e, além disso, mantê-los consistentes talvez seja tão difícil quanto coletá-los. Muitas vezes ocorre displicência em manter os requisitos atualizados, o que pode ter consequências catastróficas, por exemplo, quando se consulta os envolvidos somente no início e no final do processo de desenvolvimento. Os cenários podem se alterar neste intervalo, e os requisitos são modificados sem que os solicitantes sejam consultados; então, a validação ocorre somente durante a homologação, e o índice de retrabalho pode se tornar alto. Ainda, algumas equipes técnicas impõem limites aos seus clientes/usuários com base em seu conhecimento (domínio da tecnologia) ou na deficiência de recursos tecnológicos restritos ou obsoletos. Na verdade, buscar novas tecnologias e conhecimento adicional pode ajudá-lo a obter sucesso e atender melhor ao seu cliente/usuário. Não restrinja o atendimento de requisitos considerando apenas aspectos técnicos. Saia da zona de conforto. Busque novas alternativas, analisando primeiro as necessidades do cliente/usuário, para depois analisar a aderência e capacidade da tecnologia. Desde que dentro de limites aceitáveis de risco, inovação, na maioria das vezes, é eficiente e traz excelentes resultados. Houve um tempo em que os profissionais de TI se consideravam os “donos” do software, e o cliente/ usuário precisava se adaptar. Não há mais espaço para isso. É preciso atender às necessidades de expectativas das partes interessadas da melhor forma possível; isso não significa restringir o atendimento dos requisitos por conta da tecnologia disponível, ou da falta de conhecimento da equipe técnica. Cronogramas irreais e impossíveis de atender são quase uma regra em projetos de desenvolvimento de software. Confesso que é algo que me intriga, pois se todos sabem que o cronograma não reflete a realidade, para que usá-lo? É insano e insalubre criar documentos apenas por criar. O documento mais importante a ser atualizado e que deve estar condizente com a realidade é o cronograma, pois ele é a principal referência para a execução das atividades do projeto. Assim sendo, por que acreditar que “forçar a barra” em um cronograma pode de alguma forma ser benéfico à gestão? Relatórios de acompanhamento e de status de projetos não podem apresentar algo diferente do que a verdadeira situação do que está ocorrendo. Planejar e construir um cronograma realista aumenta significativamente as chances de sucesso de um projeto. Para desenvolvimento de software isso não é diferente, muito pelo contrário (RICARDI, 2014). Poderíamos ter aqui uma lista quase interminável de problemas que ocorrem em projetos de desenvolvimento de software. O fato é que ter uma referência pensada, testada e comprovada por milhares de profissionais, como o Software Extension, pode lhe guiar por um caminho mais curto e menos traumático para o sucesso, evitando erros e indicando caminhos mais adequados. Senac São Paulo - Todos os Direitos Reservados Gestão de Projetos em Tecnologia da Informação 4 2 Software extension to the PMBOK® Guide Esta extensão pode auxiliar tanto empresas que têm como atividade principal o desenvolvimento de software como aquelas onde existe uma área interna de Tecnologia da Informação (TI), que supre as demais áreas da empresa com o desenvolvimento interno de software. Ele pode ser utilizado como referência tanto pelos profissionais que desenvolvem diretamente o software como por aqueles que trabalham em áreas de suporte ao desenvolvimento. Dependendo do tipo de usuário final (cliente), eles também podem se beneficiar do uso desta extensão. Você pode identificar diretamente no Software Extension o que é complementar e diferente do Guia PMBOK®. Elementos novos são mostrados em itálico e negrito. Elementos modificados são mostrados em itálico. Os demais que estão iguais ao Guia PMBOK® estão em texto normal. Na Figura 1 a seguir você pode verificar como isso é representado. Figura 1 – Identificação de Entradas, Ferramentas e Técnicas, e Saídas revisadas Fonte: PMI, Software Extension (2013, p. 18). Cada um dos capítulos do Software Extension, assim como no Guia PMBOK®, e a partir do capítulo 4, corresponde às áreas de conhecimento do gerenciamento de projetos. No início de cada um destes capítulos você encontra uma figura com todos os processos desta área de conhecimento, com seus respectivos elementos: entradas, ferramentas e técnicas, e saídas. Nestas figuras estão identificadas alterações e o que foi incluído especificamente para gerenciamento de projetos de software, conforme a figura anterior. A seguir estão identificadas as diferenças a destacar (alterações e inclusões) em cada processo específico, e agrupados poráreas de conhecimento (PMI, Software Extension, 2013). Os processos e elementos que porventura não estiverem citados são iguais ao Guia PMBOK®, ou não foram considerados como passíveis de destaque. Senac São Paulo - Todos os Direitos Reservados Gestão de Projetos em Tecnologia da Informação 5 2.1 Processos de integração Para o processo Desenvolver o Termo de Abertura do Projeto: • Entradas: o Business Case pode incluir custos operacionais e de manutenção, pois isso é comum para se analisar o custo/benefício do desenvolvimento de software. • Ferramentas e técnicas: a Opinião Especializada é fator a destacar para projetos de desenvolvimento de software. Dada a dificuldade de definição do escopo, já citada, conhecer aspectos relevantes de projetos similares desenvolvidos no passado pode ser fator crítico para o sucesso. Para o processo Desenvolver o Plano de Gerenciamento do Projeto: • Entradas: modelos e lições aprendidas de projetos similares são de extrema importância para projetos de desenvolvimento de software. • Ferramentas e técnicas: ferramentas para estimativas são importantes para aumentar a precisão no planejamento, dada a dificuldade em entender e definir o escopo. • Saídas: destaque para planos de testes. Envolva o cliente/ usuário e as áreas de suporte no planejamento de testes e homologação. Para o processo Orientar e Gerenciar o Trabalho do Projeto: • Ferramentas e técnicas: a disseminação da informação é importante para o sucesso do projeto, pela característica intangível do produto. A informação inadequada e/ou no tempo inadequado pode prejudicar substancialmente o sucesso do projeto. • Saídas: demonstrações de trabalho são o indicador mais importante do progresso tangível para projetos de software, pois se não ficar comprovado que de fato está funcionando de acordo com os requisitos, podemos considerar que foi apenas codificado, e nada mais. Para o processo Monitorar e Controlar o Trabalho do Projeto: • Saídas: os relatórios de desempenho do trabalho devem ser detalhados e específicos da área, considerando métricas de produto e de desempenho, bem como informações do que ficou para backlog e relatórios de gerenciamento de configuração (versionamento das entregas). Para o processo Realizar o Controle Integrado de Mudanças: • Saídas: os relatórios de desempenho do trabalho devem ser detalhados e específicos da área, considerando métricas de produto e de desempenho, bem como informações do que ficou para backlog e relatórios de gerenciamento de configuração (versionamento das entregas). Senac São Paulo - Todos os Direitos Reservados Gestão de Projetos em Tecnologia da Informação 6 Para o processo Encerrar o Projeto ou a Fase: • Saídas: o código fonte, dados sobre desempenho e a documentação do projeto e das lições aprendidas são importantes para projetos de software. 2.2 Processos de escopo Para o processo Planejar o Gerenciamento do Escopo: • Entradas: como o desenvolvimento de software permite entregas parciais, é importante analisar como entrada para este processo se é aplicável para cada projeto específico, ou se será tudo entregue em um mesmo momento. Para o processo Coletar os Requisitos: • Ferramentas e Técnicas: as entrevistas são essenciais para um bom desenvolvimento de software, pois a equipe não tem como adivinhar detalhes que são de conhecimento de outras partes interessadas. O uso de protótipos e casos de uso também se aplica para validar requisitos durante o processo de coleta destes requisitos. O Guia PMBOK® cita o Business Analysis Body of Knowledge (BABOK) (IIBA, 2011) como uma referência importante para quem precisa coletar requisitos de negócios junto a usuários finais. Se você precisa coletar requisitos recomendo que você consulte o BABOK. Procure mais informações em International Institute of Business Analysis (IIBA). • Saídas: a documentação dos requisitos e a matriz de rastreabilidade dos requisitos são especialmente importantes, principalmente se você considerar que podem ocorrer entregas parciais ou futuras, e que você precisa ter controle absoluto sobre o que está sendo entregue em cada momento, inclusive o que eventualmente possa ficar como backlog para projetos futuros. Para o processo Criar a EAP: • Ferramentas e Técnicas: analise com atenção a proposta do uso de EAPs (Estrutura Analítica do Projeto) orientadas às atividades, elaboração de EAP em ondas sucessivas e planejamento em ondas sucessivas para projetos com ciclo de vida adaptativo. Sua EAP deve ser atualizada de acordo com a evolução do entendimento do que será entregue, e neste caso pode utilizar atividades em sua estrutura, se for cabível. Senac São Paulo - Todos os Direitos Reservados Gestão de Projetos em Tecnologia da Informação 7 Para o processo Validar o Escopo: • Entradas: considerando mais uma vez que as entregas podem ser parciais, assim como o atendimento dos requisitos, controlar o que será validado em cada momento é importante, principalmente se você estiver utilizando ciclo de vida adaptativo (também conhecido como interativo ou incremental), que é utilizado frequentemente quando se aplicam métodos ágeis. 2.3 Processos de tempo Para o processo Definir as Atividades: • Entradas: atenção com ativos de processos organizacionais relacionados a documentos de governança corporativa e também do próprio projeto. Você não pode executar seus projetos sem entender e seguir as diretrizes, bem como sem analisar o que está acontecendo a sua volta. • Ferramentas e Técnicas: diagramas de casos de uso são utilizados em larga escala no desenvolvimento de software, e têm sucesso comprovado. Se você não os conhece nem utiliza, procure se aprofundar no assunto, pois eles podem resolver vários problemas que você eventualmente tem encontrado. • Saídas: não se esqueça de incluir em sua lista de atividades aquelas que não são executadas pela sua equipe, mas que podem ter impacto no desempenho do projeto. Para o processo Sequenciar as Atividades: • Ferramentas e Técnicas: não se esqueça de considerar acordos de nível de serviço (ANS) quando estiver sequenciando suas atividades. Para o processo Controlar o Cronograma: • Ferramentas e Técnicas: tenha evidências de que as atividades foram concluídas. Não basta atualizar o cronograma para indicar avanço nos relatórios de desempenho. Relatórios de Burndown são uma excelente ferramenta para controlar o avanço do projeto. 2.4 Processos de custos Para o processo Planejar o Gerenciamento dos Custos: • Entradas: atenção com ativos de processos organizacionais relacionados às diretrizes de custos, infraestrutura disponível, políticas de governança e gerenciamento de portfólios. • Saídas: destaque para a precisão das estimativas e a confiabilidade dos dados que serão utilizados como parâmetro para estas estimativas. Senac São Paulo - Todos os Direitos Reservados Gestão de Projetos em Tecnologia da Informação 8 Para o processo Estimar os Custos: • Entradas: medir o tamanho de um software é uma tarefa árdua, notadamente no início do planejamento, quando possivelmente ainda não se tem detalhes suficientes para uma estimativa precisa. Métodos como Análise por Pontos de Função (APF) auxiliam, mas não se aplicam se não houver um histórico confiável para utilizar como referência. Para o processo Controlar os Custos: • o Ferramentas e Técnicas: Gerenciamento de Valor Agregado (GVA) ou Earned Value Management (EVM) (PMI, 2011) é uma técnica que tem conquistado muitas empresas e muitos gerentes de projetos pelo mundo. Ela está baseada no controle do desempenho do projeto com base na comparação entre o custo relativo do que foi agregado (efetivamente entregue) e o que foi planejado. Este valor agregado serve de base para se avaliar o desempenho com relação a custos e a prazo. Para se aprofundar em GVA, consulte o manual específico publicado pelo PMI®: Practice Standard for Earned Value Management. (PMI, 2011). Se você já se associou ao PMI® poderealizar o download de sua cópia deste manual. 2.5 Processos de qualidade Para o processo Controlar a Qualidade: • Entradas: para controlar a qualidade em projetos de desenvolvimento de software é importante ter planejado o uso de métricas adequadas, dependendo do ciclo de vida adotado e do tipo de plataforma que está sendo utilizada. São utilizados com frequência critérios de desempenho, quantidade de linhas de código, tempo de desenvolvimento, checklists de qualidade e avaliação dos usuários finais durante os testes. 2.6 Processos de recursos humanos Para o processo Planejar o Gerenciamento dos Recursos Humanos: • Saídas: considere no planejamento do gerenciamento dos recursos humanos fatores específicos que motivam equipes de desenvolvimento de software, como a oportunidade de aprender novas tecnologias, perspectiva de participação na construção de um software inovador e desenvolvimento de habilidades técnicas individuais. Normalmente as equipes apresentam melhor desempenho se o controle não for excessivo, e quando a colaboração mútua é incentivada e recompensada. Senac São Paulo - Todos os Direitos Reservados Gestão de Projetos em Tecnologia da Informação 9 Para o processo Desenvolver a Equipe do Projeto: • Ferramentas e Técnicas: algumas técnicas apresentam resultados expressivos, como programação em pares, desenvolvimento orientado a testes, coalocação e construção de ambiente colaborativo e sinérgico. 2.7 Processos de comunicações Para o processo Gerenciar as Comunicações: • Entradas: quando se utilizam métodos ágeis podem ser criados planos para cada versão. • Ferramentas e Técnicas: profissionais de TI normalmente têm facilidade no uso de ferramentas colaborativas. Considere o uso de redes sociais e outros recursos, principalmente se você estiver trabalhando com uma equipe virtual, localizada geograficamente em locais diferentes. 2.8 Processos de riscos Para o processo Planejar as Respostas aos Riscos: • Entradas: o plano de gerenciamento dos riscos define como os riscos serão gerenciados. Não confunda isso com o planejamento das respostas aos riscos, que é o objetivo deste processo. As respostas aos riscos normalmente são individuais e específicas para cada risco identificado. • Saídas: após a identificação, análise e planejamento das respostas aos riscos, é possível que o projeto seja abortado, pois o risco ao qual ele está exposto pode estar acima dos limites aceitáveis para este projeto e para a organização. É essencial dosar o otimismo para não executar um projeto que pode perder o controle no futuro. 2.9 Processos de aquisições Para o processo Planejar o Gerenciamento das Aquisições: • Entradas: é importante analisar a capacidade de desenvolvimento interno, se a sua organização tem uma área interna de desenvolvimento, em relação aos fornecedores disponíveis. Pode ser mais interessante contratar o projeto todo externamente, se você não tem capacidade interna para atender, ou mesmo se tiver disponibilidade de fornecedores qualificados e comprovadamente eficientes. Senac São Paulo - Todos os Direitos Reservados Gestão de Projetos em Tecnologia da Informação 10 2.10 Processos de partes interessadas Para o processo Planejar o Gerenciamento das Partes Interessadas: • Entradas: não há dúvida de que uma das maiores dificuldades em projetos de TI é conciliar a disponibilidade das partes interessadas com as necessidades do projeto. O agendamento de atividades, cotidianas ou relacionadas a projetos mudam constantemente, em especial por conta de atividades urgentes que surgem constantemente. O impacto da não participação de uma parte interessada chave em determinado momento do projeto pode ser catastrófico para o cronograma. Desta forma, é essencial planejar com extremo cuidado e zelo como estas situações serão gerenciadas. Consulte cada parte interessada e valide a sua disponibilidade, tanto durante o planejamento quanto durante a execução do projeto. Para o processo Gerenciar o Engajamento das Partes Interessadas: • Ferramentas e Técnicas: a adoção do termo “engajamento” foi muito feliz, pois é exatamente este tipo de atitude que falta em boa parte dos projetos. As pessoas acreditam que o desempenho do projeto não é problema delas, pois têm alguém a quem culpar por um eventual atraso: o gerente do projeto. Culpar alguém não resolve o problema ou atende às necessidade relacionadas ao projeto. Se você está alocado em atividades de projetos, com certeza o seu engajamento efetivo será visto com bons olhos, independentemente de qual é a sua função neste projeto (RICARDI, 2014). Reforço a recomendação para que você se associe ao PMI®, pois assim terá acesso ao Software Extension to The PMBOK® Guide (PMI, 2013), e poderá consultar em detalhes o que se aplica a cada processo. Consulte também: o Capability Maturity Model Integration (SEI); o ISO/IEC/IEEE 12207: Systems and software engineering-Software project life cycle processes (IEEE, 2008). Senac São Paulo - Todos os Direitos Reservados Gestão de Projetos em Tecnologia da Informação 11 Considerações finais Certamente você notou que não há como abordarmos todo o conteúdo do Software Extension durante este curso, assim como não é possível com relação ao Guia PMBOK®. Se de fato você está interessado em melhorar o seu desempenho nos seus projetos de desenvolvimento de software, independentemente da função que desempenha, considero essencial que você conheça estes dois Guias em detalhes, os entenda, e saiba utilizá-los na prática. É um esforço que tem recompensa certa, pois quem participa de projetos de TI sabe que eles podem se tornar traumáticos, com consequências incontroláveis. Se você trabalha em projetos para grandes corporações, seja como funcionário ou como prestador de serviços contratado, não deixe que o “dinheiro fácil” sirva de maquiagem para resultados inconsistentes. É comum empresas que têm grande capacidade financeira “camuflarem” sua ineficiência com aportes financeiros para “socorrer” projetos ineficientes, e até mesmo fadados a serem cancelados. A concorrência está se especializando, tanto na esfera corporativa quanto na esfera individual, e se você continuar conduzindo seus projetos como tem feito pode não ser suficiente para mantê-lo onde está. Pense a respeito. Referências IEEE. Computer Society. ISO/IEC/IEEE 12207: systems and software engineering-software project life cycle processes. 2. ed. Geneva: ISO, 2008. IIBA. Um guia para o corpo de conhecimento de análise de negócios (TM) (Guia BABOK(R)). versão 2.0. Toronto: IIBA, 2011. IIBA. International Institute of Business Analysis. Disponível em: http://www.iiba.org.br/. Acesso em: 30 abr. 2014. PMI. PROJECT MANAGEMENT INSTITUTE. Practice standard for earned value management. Pensilvânia: Project Management Institute, 2011. PMI. PROJECT MANAGEMENT INSTITUTE. Software extension to the PMBOK guide fifth edition. Pensilvânia: Project Management Institute, 2013. PMI. PROJECT MANAGEMENT INSTITUTE. Um guia do conhecimento em gerenciamento de projetos: guia PMBOK. Pensilvânia: Project Management Institute, 2013. RICARDI, André L. F. EasyBOK: um guia de sobrevivência para o gerente de projetos. BRASIL: Campus Elsevier, 2014. SEI. Software Engeneering Institute. Capability maturity model integration (CMMI). Disponível em: http://www.sei.cmu.edu/cmmi/. Acesso em: 30 abr. 2014. http://www.iiba.org.br/ http://www.sei.cmu.edu/cmmi/ Introdução 1 Características e aspectos gerais de projetos de desenvolvimento de software 2 Software extension to the PMBOK® Guide Considerações finais Referências
Compartilhar