Gerenciamento de Tempo no Projeto de Desenvolvimento de Software André Giovanni Castaldin, Edson Pacheco, João Maurício Hypólito, Polyanna Pacheco Gomes Fabris, Rodolfo Miranda Barros Departamento de Computação Universidade Estadual de Londrina E-mails: agcastaldin@hotmail.com, esdonpachec@gmail.com, joao.hypolito@gmail.com, poly.pgomes@gmail.com, rodolfombarros@gmail.com Abstract: The management of software projects involves tracking several guidelines. Time, human resources, communication, project risks, quality and testing are some of these guidelines. This paper studies the time management in software development. The Time Management involves knowledge of activities to be done and the network structure of execution (which can be networked allowing parallel execution of activities). To run control is necessary to know the necessary resources, cost, manpower, runtime and how all these factors can be measured in the monitoring of project development. Several models have been studied and proposed for project management. It is, in this text, a summary of these studies and presents a proposal for time management. It also presents a survey to assess whether companies use time management in software development. Palavras chaves: management, software projects, time management.
1 INTRODUÇÃO Ao longo da década de 1990 percebe-se o aumento da complexidade das organizações em todos os níveis sociais, este aumento de complexidade forçou a necessidade do uso de Sistemas de Informação constituídos por equipamentos e programas. Esta combinação fornecia as condições de armazenamento e processamento de dados e a melhoria da tomada de decisão nas organizações. Os programas passaram a ser desenvolvidos por empresas e por equipes de trabalho que viram a complexidade do software crescer rapidamente. Tornou-se necessário o aprimoramento da gestão de projetos no que tange as tecnologias da informação e comunicação (TIC). Projeto pode ser entendido como um conjunto de tarefas que, se executadas de modo coordenado, permitem alcançar um determinado objetivo [1]. Uma vez que a execução das tarefas consome algum tipo de recurso, percebe-se o desenvolvimento do conceito de Gestão de Projeto. Os projetos de TIC têm aspectos interessantes (ou agravantes) no que trata a gestão de projetos: As soluções de TIC mudam constantemente. As necessidades das organizações podem ser mutáveis ao longo do tempo de desenvolvimento de um projeto de TIC. Os recursos podem ser escassos e os requisitos elevados. Os problemas que ocorrem na execução das tarefas para conclusão do projeto podem ser agrupados em categorias, dentre elas as referentes à Gestão de Tempo. Neste artigo abordam-se os aspectos relevantes para a realização plena da Gestão de Tempo, com o objetivo de apresentar e discutir uma proposta de Gestão de Tempo de Projeto de Software. Tal proposta toma como referencia os tópicos de outras abordagens desenvolvidas e completa com o estabelecimento de níveis de avaliação do grau de maturidade das empresas desenvolvedoras de software. Citam-se no texto os aspectos de Gestão de Tempo nas seguintes metodologias: SCRUM, COBIT, PMBOK e PERT/CPM. A seguir é apresentada a estrutura de uma proposta com base nas práticas do MPS.BR, em alinhamento com as demais práticas citadas para Gestão de Tempos em Projetos de Software. Por fim, apresenta-se um questionário de pesquisa que possibilita a avaliação do nível de maturidade das empresas na gestão de tempo no desenvolvimento de projetos de software. Para tal desenvolvimento, este texto se divide assim: Capítulo 1, Introdução; Capítulo 2 - Conceitos de Gestão de Projetos e Gestão de Tempo em Projetos; Capítulo 3 - Apresentação das Abordagens de Gestão de Projetos, juntamente com a proposta deste artigo;
Capítulo 4 - Apresentação dos níveis de maturidade e aplicação de uma proposta de avaliação destes níveis nas empresas e Capítulo 5 - Conclusão.
2 GESTÃO DE PROJETOS e GESTÃO DE TEMPO EM PROJETOS De modo geral, gerir um projeto constitui-se num conjunto de ações para responder algumas perguntas importantes: o que deve ser feito? É possível ser feito? Como pode ser feito? Quanto custará e em quanto tempo estará concluído a construção do que deve ser feito? Como administrar o desenvolvimento do que deve ser feito? No estudo das técnicas de Gestão de Projetos um importante instrumento foi desenvolvido pelo Dr. Kaoru Ishikawa, o Diagrama de Causa e Efeito. Este diagrama é desenvolvido para cada projeto que desenvolve e resume as principais etapas de um projeto e quais são os principais problemas que podem ser percebidos no projeto. Este diagrama também é conhecido como Espinha de Peixe devido ao seu formato [7]. O diagrama apresentado a seguir é fruto da contribuição dos alunos da disciplina de Gerenciamento de Projetos de Software e contém uma lista de problemas a serem enfrentados nas áreas de: qualidade, custo, tempo, escopo, lições aprendidas, portfólio, comunicação e recursos humanos que podem ocorrer na Gerência de Projetos de Software. Este diagrama pode ser visualizado com mais detalhe no endereço: http://www.gpswtempo.appspot.com. Figura 1 Problemas no Gerenciamento de Projetos de Software.
Ainda sobre o paradigma dos modelos de gerenciamento de projetos, SABBAG[3], explica que o Gerenciamento da Execução de Projetos, prevê 5 grupos de processos distintos: Iniciação, Planejamento, Execução, Controle e Encerramento. A Iniciação relaciona as atividades de formalização e legitimação de um projeto. Contemplam-se as atividades de estudos de viabilidades (tecnológicas, econômicas e de tempo), determinando os pré-requisitos necessários para a organização para qual se desenvolve o projeto. O Planejamento de um projeto pode ser classificado ou dividido em: Planejamento físico (recursos necessários e quando eles devem ser usados); Planejamento financeiro (previsão de montantes monetários para o projeto) envolvendo fatores como custos e tempos de utilização; Planejamento de qualidade, onde se estabelece os patamares de qualidade e os níveis de medidas para esta qualidade ser alcançada; Planejamento de escopo, onde se escolhem como modelar a organização para qual se desenvolve uma solução; Planejamento de comunicações, Planejamento de suprimento, Planejamento de riscos e Planejamento de recursos humanos (ou de alocação de pessoal). A Execução é a etapa do projeto onde se tem como foco principal o desenvolvimento da solução de TIC propriamente dita. São objetos desta etapa: a determinação das ações diretas que implementem a solução (tarefas), determinação de métricas de acompanhamento e estabelecimento de rotinas de medidas de desenvolvimento. O Controle é a etapa onde a preocupação é estabelecer pontos indicativos de problemas e determinar ações corretivas para que o projeto seja concluído dentro de margens de aceitabilidade satisfatória. O Encerramento é a etapa onde se coleta todo o conhecimento adquirido no projeto e se alimenta a memória dos desenvolvedores do projeto, gerando a baseline (memória de referência) da empreendedora do projeto. Ainda, segundo SABBAG[3], podemos nos deparar com alguns problemas usuais na execução de projetos:
Objetivos nebulosos: para quem não sabe onde chegar, qualquer caminho serve, este bordão reflete a primeira fonte de problemas, que são: falta de objetivos claros, metas quantificadas de custos, prazo, qualidade, desempenho e resultados; Escopos mutantes: o conjunto de prerrogativas operacionais e/ou funcionais da organização pode apresentar uma certa volatilidade, implicando num projeto que tem sua execução iniciada antes que tenha sido concluído, neste caso, cada nova alteração deve ser passada aos interessados, com a pena de favorecer um grupo isolado, e mudando o escopo do projeto; Planejamento inócuo: o planejamento é realizado, no entanto, suas ações durante a execução do projeto se tornaram obsoletas ou mesmo não preveem atitudes que devem ser tomadas para corrigir pequenas falhas; Acompanhamento intuitivo do desempenho: o acompanhamento de um projeto deve ser feito de modo sistêmico. Apenas o feeling do administrador pode transformar o acompanhamento do projeto em apostas mal fundamentadas, baseadas em métricas falhas e falha no levantamento do trabalho realizado; Orçamentos imprecisos: como controlar o que foi fracamente determinado, ou o projeto que já teve início, mesmo incompleto? Vários métodos de cálculo de custo devem ser utilizados nas etapas de desenvolvimento de um projeto; Predominância de crises e perda de controle: crises ocorrem em ambientes onde há desafios singulares, no entanto, fornecem oportunidades que podem ser positivas ou causar a perda de controle sobre o projeto; Descompasso na execução: quanto mais executores o projeto tem, maior é a necessidade de coordenação. Para tanto existe a necessidade do Plano de Gerenciamento do Projeto, que irá fornecer estimativa de performance e também permitirá a métrica do desempenho dos executores; Incapacidade de atribuir responsabilidades: falta de uma Matriz de Alocação de Responsabilidades para informar, tanto o pessoal interno, quanto o pessoal externo à organização, claramente as tarefas definidas e para quem, causando aperfeiçoamento parcial do processo, no entanto, sem considerar a unidade do projeto;
Nível exagerado de conflito: sempre que existe uma interação entre equipes de desenvolvimento é possível que ocorram conflitos: interesses, prioridades, soluções adotadas, procedimentos, sistemas escolhidos, alocação de recursos; Competição com a rotina: tarefas diárias versus tarefas de um projeto. Tanto o gerenciador como a equipe, envolvidos em um determinado projeto, têm de separar o dia a dia, das funções exigidas no projeto; Gestão insuficiente ou amadora: conciliar esforços pessoais com esforços coletivos e manter diálogo e crítica pode mostrar ao gerenciador o caminho da sabedoria, pois o amadurecimento vem apenas com o tempo, trabalhar de forma isolada mostra amadorismo e vai custar muito mais esforço ao gerenciador; Segundo PMI[1], o gerenciamento de projeto contempla: Gerenciamento de Integração: trata do projeto como um todo desde sua abertura até seu encerramento; Gerenciamento do Escopo do Projeto: descreve os processos relacionados, com a garantia de que o projeto contenha todo o trabalho necessário e apenas este, para que seja concluído com sucesso; Gerenciamento de Tempo do Projeto: desempenha ações que estabelecem os parâmetros de custo (financeiro, de pessoal e recursos) e sua relação com o tempo de desenvolvimento do projeto; Gerenciamento de Custos: estima e controla os dispêndios do projeto; Gerenciamento de Qualidade: fixa patamares de qualidade e indica formas de medida e controle; Gerenciamento de Recursos Humanos: determina o perfil dos executores do projeto; Gerenciamento de Comunicações: identifica processos relativos à coleta, disseminação, armazenamento e destinação de dados relevantes no projeto; Gerenciamento de Riscos: contempla situações que podem comprometer o projeto e ações corretivas que mitigam os efeitos destas situações; Gerenciamento de Aquisições: estuda processos envolvidos na compra e aquisições de produtos ou serviços que afetam o desenvolvimento do projeto.
Vargas [4] ensina que a causa de fracasso de grande parte dos projetos é decorrente das falhas gerenciais, que podem ser evitadas, são exemplos: As metas e os objetivos são mal estabelecidos, ou não são compreendidos pelos escalões inferiores; Há pouca compreensão da complexidade do projeto; O projeto inclui muitas atividades e muito pouco tempo para realizá-las; As estimativas financeiras são pobres e incompletas; O projeto é baseado em dados insuficientes, ou inadequados; O sistema de controle é inadequado; O projeto não teve um gerente, ou teve muitos, criando círculos de poder paralelos aos previamente estabelecidos; Criou-se muita dependência no uso de software de gestão de projetos; O projeto foi estimado com base na experiência empírica, ou feeling dos envolvidos, deixando em segundo plano os dados históricos de projetos similares, ou até mesmo análises estatísticas efetuadas; O treinamento e a capacitação foram inadequados; Faltou liderança do gerente de projeto; Não foi destinado tempo para as estimativas e o planejamento; Não se conheciam as necessidades de pessoal, equipamento e materiais; Fracassou a integração dos elementos-chave do escopo do projeto; Cliente/Projeto tinham expectativas distintas e, muitas vezes, opostas; Não se conheciam os pontos-chaves do projeto; Não foi verificado se havia conhecimento necessário nos envolvidos para executar as atividades do projeto; Falta de padrões de trabalho. O desenvolvimento do presente capítulo prestou-se até aqui em citar problemas e exemplificar, de acordo com diversos autores, problemas enfrentados na Gestão de Projetos e modelos utilizados para este fim. A partir deste momento, o estudo será focado no controle, ou gerenciamento do tempo em projetos de desenvolvimento de software, para tanto, são indicados problemas identificados nesta área da gestão, bem como sugestões para resolvê-los: Má definição de escopo: conjunto de prerrogativas operacionais e/ou funcionais da organização pode apresentando certa volatilidade,
implicando num projeto que tem sua execução iniciada antes que tenha sido concluída uma definição completa de seus modelos. Metas e objetivos mal estabelecidos ou não compreendidos pela equipe de desenvolvimento: cada etapa do projeto deve ter estabelecidos, objetivos e conjunto de metas a serem cumpridas para alcançá-los. Devem ser comunicados para todos os integrantes da equipe de desenvolvimento, gestores e planejadores. Se a Organização para a qual se desenvolve o projeto apresentar escopo inconstante ao longo de seu ciclo de vida, todos os envolvidos no desenvolvimento devem estar a par das alterações e saber quais metas e objetivos podem ser afetados. Falta de comprometimento por parte da equipe de desenvolvimento: os membros da equipe de desenvolvimento devem estar, comprometidos com o sucesso do projeto, atentos a evitar a competição com a rotina e a rivalidade entre componentes ou setores da equipe. Falta de liderança do gerente de projeto: o líder de projeto deve ser hábil em perceber as capacidades de cada membro de sua equipe e articular este perfil estimulando o esforço individual e estabelecendo o trabalho em equipe produtivo, mantendo a sinergia. Má comunicação entre o gerente de projeto e a equipe de desenvolvimento: o líder deve saber estabelecer um nível de comunicação eficiente com todos os membros de sua equipe de modo que o ritmo das mensagens seja constante e seu conteúdo seja claro e simples. Falta de conhecimento das necessidades de pessoal, equipamento e materiais: a avaliação da exeqüibilidade de um projeto exige que se conheçam tarefas, prazos, complexidade, custos, capacidade de execução, equipamentos necessários, e requisitos da equipe de desenvolvimento (perfil profissional). Falta de conhecimento técnico por parte da equipe de desenvolvimento: no desenvolvimento de um projeto, as pessoas devem ter as habilidades percebidas no estabelecimento do perfil das tarefas do projeto. Pode ser realizado treinamento de pessoal.
Indeterminação de métricas para aferição no desenvolvimento das tarefas: é necessário definir o conjunto de métricas de aferição de desempenho na execução das tarefas. Esta definição envolve conhecimento histórico no desenvolvimento de tarefas similares ou iguais. Falta de monitoramento e controle do cronograma: estabelecida a rede de tarefas, é possível determinar o caminho crítico de execução (com base no tempo de execução de tarefas, por exemplo), indicar a unidade de medida de desenvolvimento das tarefas (métrica) e a periodicidade da medição. A falta de métricas para avaliar o andamento do projeto implica em gerenciamento intuitivo que resulta na ocorrência de prazo de execução excedente, elevação de custo, afetando qualidade do produto ou comprometendo todo o projeto. Falta de estimativa de tempo para as atividades do projeto: a estimativa de tempo deve basear-se em projeções técnicas ou padrões históricos e não em desejos e intenções. A estimativa de tempo pode ser feita com base nos dados de uma BASELINE já desenvolvida na empresa para projetos semelhantes. É errado estabelecer o tempo de execução das atividades de um projeto fixando-se o prazo final e impondo-se este limite como máximo. Falta de alinhamento das expectativas do cliente: a pressa em iniciar o projeto faz com que os modelos a serem desenvolvidos não sejam totalmente concluídos antes que o projeto seja acordado e iniciado sem estar claro o suficiente, isto é, as necessidades e especificações fiquem mal definidas. Ocorrências de riscos não planejados: situações que podem acarretar algum prejuízo no desenvolvimento de um projeto, mas que nem sempre ocorre. Um projeto deve conter uma estimativa de riscos e seu grau de impacto sobre o produto final, além de um Plano de Contingência. Inexistência de planos de correção para tarefas que demonstrem problemas de desenvolvimento: pode fazer com que as tarefas em situação de risco fiquem paradas e comprometam o caminho crítico do projeto.
Inexistência de valores de referencia na BASELINE para parametrizar um novo projeto: o armazenamento de dados históricos permite uma fundamentação para novos planejamentos, no entanto, quando houver pouca experiência adquirida, métodos estatísticos podem ser utilizados. Falta de cultura de gestão de tempo para gerar os valores de BASELINE para um projeto em andamento: a execução de projetos gera dados de interesse para o controle de projetos futuros. É necessário saber identificar, catalogar e coletar dados relevantes. Imprecisão na determinação das tarefas e em seu seqüenciamento: a gestão de projetos deve prever fatores durante a execução de uma tarefa, custo, prazo e recursos necessários, dentre eles pré-requisitos para o início de sua execução, portanto, deve haver uma rede de execução de tarefas responsável pelo seu o seqüenciamento.
3 ABORDAGENS DE GESTÃO DE TEMPO EM PROJETOS A Gestão de Tempo em Projetos de Software é um estudo particular da Gestão de Projetos. O presente texto formula uma proposta de Gestão de Tempo composta das seguintes diretrizes: Determinar o que fazer. Determinar como medir o que se vai fazer. Determinar um plano de execução (e revisá-lo durante o projeto). Determinar um plano de emergência. Realizar tarefas, medir o que é feito e registrar em uma Base de Referência. Tomar ações corretivas e Comunicar todas as ações (normais ou corretivas). A proposta foi formulada com base no comparativo dos seguintes modelos de gestão: MPS.BR, SCRUM, COBIT, PMBOK e Pert/CPM, mantendo-se apenas o essencial para o controle do tempo de um projeto. A abordagem de gestão de projetos segundo o MPS.BR traz em sua raiz a visão do projeto com diferentes graus de maturidade por parte da empresa desenvolvedora e estabelece níveis de maturidade indicando mecanismos (acumulativos) que devem ser implantados para se atingir os graus de maturidade no desenvolvimento de projetos. Na planilha 1 em anexo apresentamos os processos do MPS-BR que indicam os níveis de maturidade e colocamos os mesmos processos alinhados com os tópicos propostos neste texto para gestão de tempo em projetos de software. O Scrum é uma metodologia de desenvolvimento de software iterativa e incremental, que tem como princípio o manifesto ágil. Originalmente, foi formalizado para projetos de desenvolvimento de software, mas funciona bem quando aplicado para qualquer escopo de trabalho complexo e inovador [5]. Quanto ao ciclo de vida da metodologia, o Scrum pode ser resumido da seguinte forma: um product owner cria uma lista priorizada de requisitos chamada de product backlog. O product backlog é montado com o estabelecimento aproximadamente organizado ao longo do tempo das atividades necessárias para a conclusão do projeto. A complexidade das atividades é estabelecida com base na formação de uma equipe que composta de um analista-programador e de no máximo 2 usuários, sendo que esta equipe é determinada pela sensibilidade do product owner. Durante planejamento do sprint, a equipe (sempre constituída de analista e algumas vezes com usuários), seleciona um pequeno pedaço da parte superior da
lista de requisitos e o chama de sprint backlog, e decide como desenvolvê-lo. A equipe tem certa quantidade de tempo para desenvolver o que se estabeleceu no planejamento, um quantum de tempo determina o sprint, para completar esse trabalho, geralmente duas a quatro semanas. Durante o sprint ocorrem reuniões diárias (daily scrum), na quais se fazem avaliações do progresso das atividades, estas reuniões são breves e focadas em soluções de problemas com a ajuda de todos. Ao longo do projeto e em cada daily scrum, o Scrum Master mantém a equipe focada em seu objetivo, sendo também sua função disparar ou executar atividades complementares de modo que a atividade de cada equipe não seja comprometida no sprint. No final do sprint, o trabalho deve ser potencialmente preparado para entrega, para utilizá-lo ou mostrar a uma das partes interessadas. O sprint termina com um sprint review e uma retrospectiva. Como o próximo sprint começa, a equipe escolhe um outro pedaço do product backlog e começa a trabalhar novamente. O ciclo se repete até que todos os itens do product backlog tenham sido concluídos. De acordo com VIEIRA[6], o COBIT (Control Objectives for Information and related Techonology) é baseado em quatro dimensões, trina e quatro processos, fatores de críticos de sucesso, indicadores de performance e resultado, além de trezentos e dezoito objetivos de controles para equacionar o ambiente de TI em atendimento dos requerimentos de negócio relativos às informações. Constitui estrutura de relações e processos para que dirigem e controla o ambiente de TI com o objetivo de alcançar as metas da organização, agregando valor ao mesmo tempo em que equilibra risco versus retorno de investimento em TI. As quatro dimensões do COBIT são detalhadas a seguir: Planejamento e organização: cobrem estratégia e táticas e buscam a identificação da forma que pode contribuir para a melhor realização dos objetivos organizacionais. Prevê planejamento, comunicação e administração para a realização da visão estratégica. Aquisição e implementação: identifica, desenvolve ou adquire soluções de TI através de percepção estratégica integrada ao processo empresarial. Inclui mudanças e manutenções de sistemas existentes. Entrega e suporte: trata da entrega dos serviços requeridos pelo negócio, garantindo segurança, continuidade e treinamento. Monitoramento: avalia o processo regularmente assegurando qualidade e conformidade com os controles requeridos.
Ainda, de acordo com VIEIRA[6], as dimensões são detalhadas em 34 processos de controle de alto nível e 318 objetivos de controle com visão ampla sobre os requerimento à área de TI em suas atividades. O COBIT procura alinhar os recursos de TI, pessoas, sistemas, tecnologia, instalações e dados à estratégia da organização e aos requerimentos do ambiente. Para o presente trabalho, foram utilizados os objetivos de controle da dimensão de Planejamento e Organização, pois, para atingir os objetivos do gerenciamento de tempo em projetos software, a empresa de TI deve planejar e prover a organização adequada de seus recursos. O COBIT também nos fornece um modelo para atestar a maturidade de cada processo em uma escala de cinco estágios possíveis: não existente, inicial ou ad-hoc, repetível, processo definido, processo otimizado. Além de fornecer o detalhamento do que deve ser auditado em cada processo com base em seus controles. Constitui importante ferramenta na estruturação e controle dos processos da empresa a atendendo à demanda de suas diversas áreas: acionistas, organismos regulatórios e entidades externas, por alinhamento, transparência e equalização dos riscos de TI. O PMBOK (Project Management Body of Knowledge) é desenvolvido pelo PMI (Project Management Institute), que estuda os aspectos gerenciais de projetos de diferentes tipos. Considera como projeto qualquer empreendimento que tenha como objetivo o desenvolvimento de um produto ou prestação de serviço. Para o desenvolvimento de um projeto é considerado o uso de recursos: materiais ou humanos (pessoas colaborando com experiência e conhecimento acumulado). As pessoas desempenham atividades que devem ser executadas sob uma coordenação sendo que as atividades realizadas consomem tempo para sua conclusão. Deste modo o PMBOK prevê a gestão de tempo como fundamental para a coordenação na execução das atividades, sendo necessário: Definir as atividades do projeto: identificação das ações específicas a serem realizadas para produzir as entregas do projeto. Determinar a seqüência mais adequada de execução: identificação e documentação dos relacionamentos entre as atividades do projeto Estimar os recursos das tarefas: estimativa do número de períodos de trabalho necessários para cada atividade.
Desenvolver um cronograma: análise de seqüência das atividades, suas durações, recursos necessários e restrições do cronograma visando criar o cronograma do projeto. Controlar a execução das atividades do cronograma: monitoramento do progresso do projeto para atualização e gerenciamento de mudanças feitas na Linha Base do Projeto Uma questão quase que constante em todas as prerrogativas da proposta de gestão de tempo do PMBOK é relaciona desenvolvimento e manutenção de dados da BASELINE dos projetos desenvolvidos e a se desenvolver. A BASELINE é um depósito referencial de dados dos projetos que são feitos ao longo do tempo por uma organização. A BASELINE deve conter dados relativos ao desenvolvimento das várias gestões de um projeto, como: gestão de tempo, recursos humanos, comunicação, riscos, entre outras. A BASELINE é dinâmica e particular de cada organização desenvolvedora. O PERT/CPM, uma consagrada abordagem para gestão de projetos é o método desenvolvido com a contribuição de vários engenheiros da NASA durante a década de 1960. HIRSCHDELD[2] apresenta o PERT/CPM como um método manual ou computacional para determinação do Planejamento e Controle de Execução de Projetos. O conceito fundamental do método é a TAREFA que é uma seqüência de ações que consomem insumos e se desenvolvem ao longo de um intervalo de tempo. A tarefa tem como premissa um estado de elementos que fundamentam a sua execução. Os estados ou eventos são pontos chaves ao longo do projeto onde se reúnem produtos (resultantes de outras tarefas) ou insumos (pessoal ou material) de modo que outras tarefas possam ser desenvolvidas. A consecução de tarefas pode ser indicada em uma rede que representa a mudança de estados (ou realização de tarefas que conectam eventos). O método PERT/CPM determina (em função quase sempre do tempo de execução das tarefas) qual deve ser a sequência de tarefas que devem ser executadas em ordem e sem atraso para que o projeto termine no menor tempo possível. Este é o caminho crítico do projeto. Resolver uma rede, então é determinar seu caminho crítico. O método é desenvolvido ou aplicado em projetos seguindo-se uma ordem de etapas, estas etapas são apresentadas na Planilha 1, em anexo, e comparam igualmente o método PERT/CPM com a abordagem de Gestão de Tempo em Projeto proposta. Depois de determinado o caminho crítico pode-se montar o diagrama de Gantt. Neste diagrama se apresenta todas as tarefas alinhadas ao longo tempo, as atividades paralelas podem contar com um tempo de folga. O início de execução de atividades que tem
folga pode ser deslocado e isso pode implicar em um consumo mais balanceado de insumos para a conclusão de atividades. Pode-se assim realizar o balanceamento de redes para equilíbrio de consumo de mão de obra ou materiais usando como referência o caminho crítico por tempo. Um resumo das principais características de cada abordagem, em comparação com a abordagem proposta neste texto, foi montado em uma tabela comparativa. Esta tabela pode ser acessada no seguinte endereço: http://www.gpsw-tempo.appspot.com. Nesta tabela indicam-se os componentes da abordagem proposta neste texto em comparação com os itens considerados nas outras abordagens já comentadas. Estabelece-se, assim, uma correlação e uma comparação da abordagem proposta.
4 OS NÍVEIS DE MATURIDADE E ASPECTOS DA PROPOSTA Será que uma empresa pode desenvolver software com qualidade sem que aplique nenhuma ferramenta ou conceito de Gestão de Tempo em Projetos de Software? E se usa alguma ferramenta ou noção de gestão, como separar a empresa A da empresa B? Como avaliar ou estimar a diferença entre as empresas desenvolvedoras? Para mensurar a aplicação da gerência de tempo nas empresas, foi criado um questionário com abordagens das sete diretrizes da proposta de gestão de tempo em projetos de software. 4.1 Questionário Cada questão é dividida em práticas, as práticas são entendidas como um conjunto de ações ou artefatos produzidos durante o desenvolvimento do projeto de software e que dão suporte ou tornam efetivos a realização da diretriz que contempla a prática. No questionário é possível marca a prática desenvolvida no atendimento da diretriz. As diretrizes indicadas no questionário são as seguintes: 1) A empresa determina o que será feito no projeto (escopo/objetivos). 2) A empresa determina como será realizada a medição do progresso do projeto (métricas). 3) A empresa determina, e revê plano de execução e/ou aquisição para o projeto (execução/aquisição). 4) A empresa possui um plano de emergência para o projeto (emergência). 5) Ao realizar tarefas, a empresa mede o que é feito e registra (registro). 6) A empresa toma ações corretivas no decorrer do projeto (correção). 7) A empresa comunica todas as ações realizadas durante o projeto (Comunicação). As perguntas foram criadas com base no comparativo entre os modelos de gestão constantes da proposta de Gestão de Tempo (MPS.BR, SCRUM, PMBOK, COBIT e PERT/CPM) e podem ser vistas na integra no endereço: https://docs.google.com/spreadsheet/viewform?formkey=de4xvlp2qvf1se 1DdUh0aUh5clEtQWc6MQ#gid=0
4.2 Os Níveis de Maturidade O questionário tenta estimar o quanto uma diretriz é alcançada na gestão de tempo em desenvolvimento de software. Para isso o modelo de perguntas foi o seguinte: Para cada diretriz estudada desenvolveu-se uma lista de práticas que podem ser desenvolvidas ou ações que podem ser executadas. Depois de identificadas todas as práticas de uma diretriz estas são classificadas segundo a sua importância para a efetiva conclusão da diretriz considerada. Este grau de importância é uma estimativa do quanto é afetada uma diretriz se a prática não for cumprida; se o impacto for grande, então a prática tem 'muita' importância. Para cada prática (considerando seu grau de importância), determina-se um peso. Adota-se uma escala de 0 a 8 com os pesos sendo números inteiros. A definição da ordem e da escala de pesos foi feita levandose em conta a descrição dos itens nas diversas abordagens de gestão de projetos e avaliando-se o que causaria o seu não cumprimento para a conclusão do aspecto analisado. Quando uma empresa responde ao questionário é possível estabelecer seu nível de maturidade no aspecto respondido. A empresa que responde ao questionário marca a prática de uma diretriz que utiliza no desenvolvimento do software. Como se tem associado a cada prática um peso, então é possível determinar a soma dos pesos que a empresa desenvolve (SE). Para cada diretriz temos a somatória dos pesos das práticas (SP). Ponderando-se a somatória dos pesos assinalados por uma empresa em uma diretriz, com relação à soma dos pesos das práticas da mesma diretriz é possível ter uma nota relativa da empresa (de 0 a 1). Podemos multiplicar este valor por 10 e obtemos uma nota da empresa (NE). O fator NE pode ser calculado com a seguinte fórmula: Lembrando que NE é um valor entre 0 e 10, pode-se dividir o intervalo em grupos de 2 pontos, têm-se os 5 níveis de maturidade e determina-se o nível de maturidade das empresas para cada aspecto considerado na Gestão de Tempo no Desenvolvimento de Projetos de software.
Desse modo para cada diretriz pode-se ter os diferentes níveis de maturidade das empresas. Colocando-se os níveis de maturidade obtidos para cada diretriz considerada no questionário é possível ter o quadro de níveis de maturidade como o apresentado na tabela 1. Nesta tabela têm-se todos os níveis determinados para as práticas marcadas como desenvolvidas pelas empresas. A partir desta tabela podem-se construir os diagramas de comparação das empresas para os aspectos de gestão de tempo no desenvolvimento de software como os apresentados nas figuras 1 e 2. EMPRESAS A B C D E F G Escopo/Objetivos 1 1 2 5 4 3 3 Métricas 1 1 2 4 3 3 2 Execução/Aquisição 1 1 5 4 4 3 2 Emergência 1 1 3 5 1 2 4 Registro 1 1 3 5 3 4 3 Correção 4 1 4 4 4 4 4 Comunicação 2 1 5 5 2 4 3 Tabela 1. Resumo dos níveis de maturidade das empresas para os aspectos. Observa-se na tabela 1 que a empresa que apresenta os níveis de maturidade mais baixos é a empresa B. Isso pode refletir uma empresa sem experiência suficiente no desenvolvimento de software. A partir dos dados da tabela 1 projeta-se o gráfico da figura 1, que pode ser analisado com mais facilidade e no qual se percebe que a empresa D apresenta os mais altos níveis de maturidade anotados na pesquisa realizada. Nota-se também um comportamento heterogêneo quanto à estratégia de se buscar um amadurecimento no desenvolvimento de software. Existem empresas que buscam maturidade nas fases iniciais do projeto e gradativamente vão melhorando as fases subsequentes. É o caso da empresa E que aparentemente busca melhoria de processos de desenvolvimento nas fases de determinação das tarefas do projeto, no estabelecimento de métricas de controle e no estudo sobre a aquisição ou desenvolvimento de itens complementares ao projeto. De outro lado percebemos quais empresas adotam a estratégia de melhorar seus processos a partir da percepção da qualidade do software desenvolvido e da geração de registros que estas experiências propiciaram. É o caso da empresa F.
NÍVEIS GRAU DE MATURIDADE 5 4 3 2 1 A B C D E F G EMPRESAS 0 ESCOPO/OBJETIVOS MÉTRICAS EXECUÇÃO/AQUISIÇÃO EMERGÊNCIA REGISTRO CORREÇÃO COMUNICAÇÃO Figura 1. Graus de maturidade para as empresas analisadas De outra forma podemos representar os dados da tabela 1 no gráfico da figura 2. As mesmas análises são possíveis a partir desta figura. GRAU DE MATURIDADE NÍVEIS 5 4 3 2 A B C D E F G 1 0 ESCOPO/OBJETIVOS MÉTRICAS EXECUÇÃO/AQUISIÇÃO EMERGÊNCIA REGISTRO CORREÇÃO COMUNICAÇÃO A B C D E F G EMPRESAS Figura 2. Gráfico em 3D dos dados dos níveis de maturidade das empresas. Esta análise foi aplicada a um pequeno grupo de empresas convidadas. Seus nomes permanecem em sigilo. O perfil das empresas não é o mesmo. Pode-se indicar que uma pesquisa mais ampla e estatisticamente mais representativa seja aplicada com a mesma