10th International Conference on Information Systems and Technology Management CONTECSI June, 12 to 14, São Paulo, Brazil

Transcrição

1 SCRUM IN PROJECTS USING FIXED TERM Jaqueline Aparecida Jorge Papini (Federal University of Uberlândia, Minas Gerais, Brazil) - jaque_comp@yahoo.com.br Allan Kardec Silva Soares (Federal University of Uberlândia, Minas Gerais, Brazil) - allankardec@gmail.com This research presents a proposed methodology to minimize the problems encountered in fixed term projects that use Scrum. Scrum is an iterative and incremental process used for managing any kind of project. This process is widely used in the area of Information Technology (IT), where most of the projects is closed with a fixed term, i.e., through a fixed price contract. In the IT area the changes in scope are constant, and can bring highimpact to the projects when they are not adequately addressed. Scrum, being iterative, provides a detailed scope of each cycle known as sprint. Thus, early in the project does not have all the detailed scope. Therefore, it is not possible to make a reliable estimate of the total project time, mainly due to not having the exact dimension of its size. However, because of this to be the main cause of the failure of many projects in the IT area, this research proposes a methodology that seeks to reconcile, on the one hand, Scrum, which is constantly growing in this area, and on the other hand, fixed term project, which is the most commonly be used in this area. The proposed methodology proves effective since, in addition to providing greater security in estimates, still predicts the impact of changes in the integration of the project. Keywords: Scrum, Agile Methodology, Fixed Term Project, IT Project, Fixed Price Contract. 2044

2 1 1. Problema de Pesquisa 1.1. Introdução Grande parte das empresas opta por fechar projetos de prazo fixo com os fornecedores. Isso remete principalmente a projeção de uma expectativa alinhada ao negócio do cliente. Em projetos de prazo fixo, tem-se um escopo e custo pré-acordados. Isso proporciona, dentre outras coisas, uma maior segurança para o cliente, em ter conhecimento prévio do preço e prazo total do projeto antes mesmo de seu início. Obviamente, nenhum cliente está disposto a investir no fornecedor sem pelo menos uma previsão do resultado do projeto. Quando um cliente contrata uma empresa para desenvolver um projeto nesse cenário, mudanças de escopo são consideradas críticas, pois o projeto possui prazo e custo fixos. Apesar da maior segurança que projetos de prazo fixo proporcionam aos clientes, um dos maiores problemas em projetos é o não cumprimento dos prazos estabelecidos (PMI, 2012). Por inúmeras razões os projetos estouram o prazo, e, por conseguinte, o custo previsto no planejamento. Quando o custo é afetado, medidas como redução de recursos geralmente são as primeiras a serem avaliadas. Essas medidas podem afetar outras áreas do projeto, como por exemplo, a qualidade. Isso retrata uma das inúmeras consequências de um planejamento equivocado de tempo do projeto. Dentre as causas do não cumprimento de prazos em projetos, as constantes mudanças de escopo são uma das grandes responsáveis por esse problema. Fatores como estimativas erradas, falta de maturidade do time do projeto, falta de integração e riscos não avaliados corretamente também impactam diretamente no aumento do tempo total do projeto. Na área de Tecnologia da Informação (TI) o índice de mudança de escopo é elevado (PMI, 2012). Uma das causas disso é que esta área muda rapidamente, e as organizações estão constantemente adquirindo inovações tecnológicas para se adequar às mudanças em seu negócio e reduzir custos. Outra causa desse índice elevado é que geralmente a área de negócio do cliente está em evolução e muitas vezes o mesmo não sabe definir corretamente o que precisa. O fato é que, seja por mudanças de tecnologia, por mudanças no negócio ou indecisão do cliente, as mudanças constantes de escopo implicam em inúmeros problemas para os projetos. Dentro deste cenário está inserido o Scrum. De acordo com Schwaber (2004), o Scrum é um processo muito simples para o gerenciamento de projetos complexos. Trata-se de um framework de desenvolvimento iterativo e incremental para gerenciamento de projetos, que vem ganhando força principalmente na área de TI. Por se caracterizar como uma metodologia ágil, as mudanças de escopo são tratadas com muito mais naturalidade quando comparadas às metodologias tradicionais. Com o Scrum, o foco é maior no negócio do cliente, ao invés do planejamento previamente acordado. Tanto é que um dos ideais que o Scrum valoriza, enquanto processo ágil de desenvolvimento, é "responder às mudanças mais do que seguir um plano" (Beck et al., 2001: 1). Além disso, a cada iteração do Scrum, o time do projeto estima o tempo necessário para atender as requisições mais prioritárias para o cliente, o que acarreta em uma maior flexibilidade nos processos de planejamento e mudanças. Com base nisso, projetos com prazo fixo que utilizam Scrum na sua forma pura tendem a ser muito problemáticos, principalmente em áreas em que as mudanças de escopo são frequentes. A área de TI é caracterizada pelo escopo instável e isso quase sempre implica em mudanças no prazo e custo do projeto. Sem uma metodologia adequada para tratar isso, os projetos com esse cenário tendem a fracassar. Neste contexto, apresenta-se essa pesquisa, que visa propor uma metodologia adequada para tratar projetos de prazo fixo que utilizam o Scrum. Para ser uma metodologia satisfatória, a mesma deve considerar, dentre outras coisas, uma adequação da forma de 2045

3 2 trabalho de maneira a conciliar mudanças no planejamento com a restrição do tempo. É fundamental, ainda, que seja feita a integração do projeto a cada mudança aprovada e a avaliação dos riscos provenientes dessas mudanças. Espera-se que este artigo sirva de subsídio às empresas e gestores de projetos que estejam inseridos em cenários que se faça necessário a conciliação do Scrum com projetos de prazo fixo, de forma a disponibilizar condições de se efetuar um planejamento satisfatório que culmine no sucesso do projeto O Problema A problemática abordada nesta pesquisa pode ser expressa pela seguinte questão: Como conciliar de forma satisfatória, com ênfase na integração, a utilização do Scrum em projetos de prazo fixo, principalmente em cenários em que as mudanças de escopo são constantes e o fator tempo é considerado uma restrição? 1.3. Objetivos Objetivo Geral O objetivo principal deste artigo é apresentar uma análise do problema apresentado bem como propor uma metodologia que visa conciliar de forma satisfatória a utilização do Scrum com projetos cujo prazo está definido no momento do fechamento do contrato Objetivos Específicos Os objetivos específicos deste artigo são: Identificar no Scrum os papéis, artefatos e processos que constituem a essência desse framework; Verificar como a área de integração é abordada pelo Project Management Body of Knowledge (PMBOK) e relacioná-la às mudanças de escopo; Identificar as características dos projetos de prazo fixo e evidenciar os riscos e benefícios oriundos dessa abordagem; Identificar as características de projetos que tem prazo fixo e utilizam o Scrum; Levantar as características essenciais que deve ter uma metodologia que vise conciliar de forma satisfatória a utilização do Scrum em projetos de prazo fixo Justificativa da Pesquisa Atualmente grande parte dos projetos desenvolvidos pelas empresas é de prazo fixo. Neste contexto, a entrega do projeto na data acordada faz parte do contrato e, geralmente, é de suma importância para o cliente. Em paralelo a isso, a utilização do Scrum tem crescido bastante nos últimos anos. Várias empresas já utilizam esse framework para todo o seu leque de projetos, e outras estão iniciando pilotos para validar a eficácia do Scrum para as características de seus projetos. Por inúmeros motivos que serão apresentados no decorrer deste artigo, a utilização do Scrum em projetos de prazo fixo tende a ser problemática. Assim, a proposta de uma metodologia que visa adaptar projetos de prazo fixo com a utilização do Scrum é um tema de interesse de várias empresas com o intuito de obter sucesso em seus projetos. Além disso, com o crescente aumento da aderência ao Scrum, uma pesquisa com esse foco faz-se 2046

4 3 necessária para contribuir de forma significativa com as empresas e gestores que irão se deparar em seus projetos com os problemas que serão apresentados neste trabalho Hipóteses da Pesquisa Esta pesquisa iniciou-se com a hipótese de que a utilização do Scrum em projetos de prazo fixo tende a ser bastante problemática quando não conduzida de forma adequada. Dessa forma, a utilização de uma metodologia adequada para a condução desses projetos, principalmente em cenários em que as mudanças de escopo são constantes e o fator tempo é considerado uma restrição, é essencial para a obtenção do sucesso almejado. No decorrer deste artigo serão apresentados os problemas oriundos desse cenário, além de ser proposta uma metodologia para condução desses projetos. Ao final da apresentação desta proposta será possível verificar que tal metodologia permite conciliar de forma satisfatória a utilização do Scrum em projetos de prazo fixo Estrutura do Artigo Primeiramente, na seção 1, é feita uma introdução ao tema da pesquisa. Nessa seção temos uma explicação do problema, dos objetivos e das justificativas que levaram a esta pesquisa. Na seção 2 temos o referencial teórico utilizado para análise do problema. Dentro dessa seção o Scrum é apresentado, bem como os papéis, artefatos e processos que constituem a essência desse framework. Ainda nessa seção temos uma introdução à integração em projetos, como esta área é abordada pelo PMBOK e sua relação com as mudanças de escopo. Por fim, temos nessa seção a apresentação das características de projetos de prazo fixo, seguida de uma abordagem do processo de utilização do Scrum em projetos de prazo fixo. Na sequência, na seção 3, a metodologia da pesquisa é apresentada. Nessa seção será descrito o método científico utilizado na pesquisa. Como resultado desta pesquisa, a seção 4 apresenta a proposta de uma metodologia para solucionar esse problema, com os processos a serem seguidos e as definições de responsabilidades dos principais membros do projeto. Por fim, na seção 5 são feitas as considerações finais dessa análise. 2047

5 4 2. Referencial Teórico 2.1. Scrum Introdução Métodos ágeis podem ser definidos como aqueles que seguem os valores do chamado Manifesto Ágil. Esse manifesto foi formalizado no ano de 2001 por vários autores, dentre estes o Ken Schwaber, que é co-criador do Scrum. O Scrum é uma metodologia ágil para gerência de projetos. A origem da palavra Scrum foi dada pelos japoneses Hirotaka Takeuchi e Ikujiro Nonaka, no contexto de um tipo de processo de desenvolvimento de produto utilizado no Japão. O nome Scrum também foi escolhido pela similaridade entre o jogo de Rugby (Scrum denomina, no Rugby, uma equipe aglomerada em que todos agem em conjunto para transportar a bola pelo campo) e o tipo de desenvolvimento de produto comentado. Ambos são adaptativos, rápidos e promovem a autoorganização Papéis De acordo com o Scrum, o projeto é realizado por uma equipe composta por: Time, Product Owner e Scrum Master. Cada um desses personagens possui um papel bem definido. O Time constitui a base do Scrum. Este é auto-gerenciável e as decisões tomadas são compartilhadas por todos integrantes. O Time é acompanhado e suportado por dois papéis específicos: o Product Owner e o Scrum Master. De acordo com Schwaber (2004), é dever do Time definir como maximizar a sua própria produtividade. O Scrum Master e outros podem orientar a condução das atividades, mas é responsabilidade do Time a sua própria gestão. O Product Owner é responsável por fornecer a visão do projeto e por guiar o Time para atender as necessidades do negócio do cliente. É seu dever definir e priorizar o artefato chamado Product Backlog (vide seção Artefatos ). Esse papel pode tanto ser representado pelo cliente quanto por um integrante da empresa contratada. Também é de sua responsabilidade gerenciar o escopo do projeto, decidir sobre as datas de lançamento, garantir o retorno sobre o investimento (ROI), priorizar funcionalidades de acordo com o valor de mercado e aceitar ou rejeitar o resultado dos sprint s. Para Schwaber (2004), o Product Owner e o Time devem constantemente colaborar e planejar juntos sobre como obter o máximo valor para o negócio do cliente a partir da tecnologia selecionada. Já o Scrum Master pode ser visto como uma espécie de técnico do Time, e é responsável por representar parte da gerência para o projeto, garantir a aplicação dos valores e práticas do Scrum, remover obstáculos do Time, garantir a plena funcionalidade e produtividade da equipe, garantir a colaboração entre os diversos papéis e funções e ser uma barreira para interferências externas. Ainda de acordo com Schwaber (2004), o Scrum Master fornece liderança, orientação e treinamento ao Time. Além disso, é responsável por ensinar aos outros membros da equipe como usar o processo do Scrum para lidar com cada nova complexidade encontrada durante o projeto. 2048

6 Artefatos Os principais artefatos do Scrum são: Product Backlog, Sprint Backlog, Story e o Gráfico de Burndown. O Product Backlog é uma lista de funcionalidades que representa o escopo do projeto. Essa lista contém apenas os nomes das funcionalidades, e não seu detalhamento. É dever do Product Owner criar e manter o Product Backlog constantemente atualizado e priorizado, de acordo com as necessidades do cliente. Após o início dos sprint s, os itens mais prioritários do Product Backlog, que foram selecionados pelo Time, são divididos em partes menores e colocados no Sprint Backlog. Esses itens são de responsabilidade do Time, que tem autonomia para definir como as atividades serão executadas. É necessário o detalhamento de cada item priorizado do Product Backlog para que este possa entrar na sprint, e esse detalhamento é chamado de Story. Assim, geralmente, se tem Story (especificação) apenas para os itens mais prioritários do Product Backlog, e a construção para os outros itens é feita de forma incremental durante o desenvolvimento do projeto. O Gráfico de Burndown mostra, a cada dia, a quantidade de trabalho cumulativo restante de um sprint. Neste gráfico, o eixo y indica a quantidade de tarefas do Sprint Backlog, e o eixo x indica os dias decorridos. Com isso, pode-se visualizar facilmente se um trabalho está tendo ou não o progresso devido. É de responsabilidade do Scrum Master diariamente ajustar esse gráfico (que geralmente está em um local de livre acesso), de forma que a qualquer momento todos possam ter uma ideia do andamento do projeto em termos de tempo Processo O Scrum emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos (Schwaber & Sutherland, 2011: 4). De acordo com o Scrum, o progresso do projeto é baseado em ciclos de tamanho fixo, geralmente de duas a quatro semanas, chamados Sprint s, em que o Time do projeto trabalha para alcançar objetivos bem definidos. No início dos sprint s é realizada a Planning Meeting, em que o Product Owner apresenta ao Time as funcionalidades mais prioritárias para o cliente e o Time define quais destas funcionalidades são passíveis de serem desenvolvidas no sprint corrente. Durante os sprint s o Time e o Scrum Master fazem reuniões diárias para controle do que foi feito, do que será feito e reporte de problemas que possam ter surgido. Ao final do sprint, o Time apresenta os resultados para o Product Owner e demais stakeholders que darão os aceites para que possa ser iniciado um novo sprint. A reunião em que ocorre essa apresentação é conhecida como Review. Após isso, existe ainda uma reunião de Retrospective, onde o Time levanta quais foram as lições aprendidas no sprint. A figura 1 ilustra o processo iterativo do Scrum, mostrando os momentos de produção dos artefatos mencionados. 2049

7 6 Figura 1 Processo do Scrum (Magno, 2009: 20) Integração O Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK) é uma norma que fornece diretrizes para o gerenciamento de projetos individuais (PMI, 2008: 3), definindo um padrão composto por normas, métodos, processos e práticas para o desenvolvimento e gerenciamento de projetos. Entende-se por projeto um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo (PMI, 2008: 5). E o gerenciamento de projetos é uma aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos (PMI, 2008: 6). A integração do projeto é uma das áreas de conhecimento em gerenciamento de projetos presente no Guia PMBOK. O Gerenciamento da integração do projeto inclui os processos e as atividades necessárias para identificar, definir, combinar, unificar e coordenar os vários processos e as atividades dos grupos de processos de gerenciamento (PMI, 2008: 71). De acordo com o PMI (2008), os processos de gerenciamento da integração do projeto são: Desenvolver o termo de abertura do projeto, que faz parte do grupo de processos da iniciação do projeto; Desenvolver o plano de gerenciamento do projeto, que faz parte do grupo de processos do planejamento do projeto; Orientar e gerenciar a execução do projeto, que faz parte do grupo de processos da execução do projeto; Monitorar e controlar o trabalho do projeto, que faz parte do grupo de processos de monitoramento e controle do projeto; Realizar o controle integrado de mudanças, que também faz parte do grupo de processos de monitoramento e controle do projeto; Encerrar o projeto ou fase, que faz parte do grupo de processos de encerramento do projeto. Dentro da área de integração, a cada novo risco identificado no projeto, por exemplo, o gerente de projetos deverá realizar a integração e reflexo deste nas demais áreas afetadas no projeto (geralmente as áreas de tempo, custo e riscos). Da mesma forma, a cada mudança de 2050

8 7 escopo realizada durante o projeto, deverá ser feita a integração da mesma com as áreas que serão impactadas no projeto, de maneira a efetuar o processo de integração chamado Realizar o controle integrado de mudanças. As mudanças de escopo solicitadas geralmente precisam ser aprovadas por um comitê de controle de mudanças para serem executadas. Se uma solicitação de mudança for considerada exequível, mas fora do escopo do projeto, a sua aprovação requer uma mudança de linha de base (PMI, 2008: 98). Geralmente, cada mudança aprovada representa um aumento no custo e tempo do projeto, e deverá ser avaliado o impacto disso de acordo com o tipo de contrato fechado para o projeto. Esse é um ponto que necessita de bastante atenção, e representa um dos problemas mais frequentes em projetos quando a integração da mudança não ocorre de forma adequada Projetos de Prazo Fixo É sabido que o não cumprimento dos prazos estabelecidos é um dos principais fatores responsáveis pelo fracasso dos projetos. No Benchmarking de 2012 em Gerenciamento de Projetos no Brasil, realizado pelo Project Management Institute (PMI), o não cumprimento dos prazos estabelecidos está referenciado como o segundo problema mais frequente em projetos, citado por 66,2% das empresas que participaram do estudo. A figura 2 ilustra o gráfico referente a essa questão no benchmarking realizado. Figura 2 Problemas mais frequentes em projetos. Fonte: PMSURVEY.ORG 2012 Edition. Project Management Institute Chapters. De acordo com este mesmo benchmarking, no setor de TI o resultado é semelhante ao geral, e o problema de não cumprimento dos prazos estabelecidos (54%) também aparece entre os primeiros do ranking de problemas mais frequentes nas organizações. Note que as mudanças de escopo constantes (62%) lidera o ranking de problemas na área de TI. A figura 3 ilustra o gráfico específico para o setor de TI referente a essa questão no benchmarking realizado. 2051

9 8 Figura 3 Problemas mais frequentes em projetos no setor de TI. Fonte: PMSURVEY.ORG 2012 Edition. Project Management Institute Chapters. A grande maioria dos projetos na área de TI possui prazo fixo estabelecido no momento de fechamento do contrato, ou seja, o prazo é fornecido antes mesmo do período de planejamento detalhado do projeto. Isso ocorre, dentre outros fatores, para que seja possível que o cliente tenha informações a ponto de calcular o Retorno sobre Investimento (ROI) total do projeto, e para que possa alinhar isso a sua expectativa de lançamento do produto. Outro motivo desse tipo de abordagem é, muitas vezes, a não confiança plena, por assim dizer, do cliente no fornecedor contratado, uma vez que, em projetos com escopo e prazo flexíveis, seu custo pode ser bastante oneroso. Projetos de prazo fixo representam uma maior garantia para o cliente, visto que o mesmo não será impactado por riscos não previstos, fatores estes que no geral tendem a ser absorvidos pela empresa fornecedora, principalmente os referentes a custos não previstos nas estimativas. Entretanto, em áreas onde mudanças de escopo são constantes, esses prazos fixos na sua maioria não são cumpridos. Assim, de nada adianta o cliente fechar um projeto de prazo fixo se no final do prazo este precisar ser reavaliado. Dessa forma, uma das grandes desvantagens desse tipo de projeto é no tratamento das mudanças de escopo, pois o gerente de projetos tende a estar com foco maior em cumprir o planejamento do projeto, ao invés de atender a real necessidade do cliente. Com isso, as mudanças de escopo geralmente são vistas como inimigas do projeto, pois as mesmas poderão trazer impactos negativos em todo o planejamento. Além disso, nessa abordagem, o cliente tende a não querer pagar por essas mudanças, alegando que as alterações propostas faziam parte do escopo. Assim, nesses cenários, se o projeto não tiver um escopo muito bem definido, o mesmo irá facilmente estourar o custo e prazo, devido a absorver as mudanças solicitadas sem que seja feito um replanejamento adequado (mudança de linha de base, dentre outros). Nesses casos, o replanejamento é necessário, pois um item a mais ou alterado no escopo pode impactar no custo, tempo, risco e qualidade geral do projeto. Outra desvantagem que pode ser citada nesse tipo de projeto é que, geralmente, os prestadores de serviço incluem uma margem de segurança no orçamento do projeto, 2052

10 9 justamente prevendo uma eventual falha no planejamento e estimativa de horas. Essa é uma desvantagem para o cliente, entretanto, o mesmo muitas vezes opta por esse tipo de contrato, ao invés de não ter uma previsão segura (prevista em contrato) de término e custo do projeto. Projetos de prazo fixo funcionam bem quando o escopo é fechado e completamente detalhado no início do projeto, antes do fornecimento do prazo ao cliente. Isso porque, se saberá com clareza quando uma requisição é ou não mudança de escopo. Assim, quando de fato ocorrer uma solicitação de mudança de escopo, será consenso entre as partes (cliente e fornecedor) que o planejamento do projeto terá de ser alterado, uma vez que áreas como tempo e custo provavelmente serão impactadas. Com o escopo do projeto detalhado e aprovado é possível se ter uma maior segurança na estimativa de tempo e custo total do projeto, tanto para o cliente quanto para o fornecedor Scrum com Projetos de Prazo Fixo Em grande parte dos projetos da área de TI que utilizam Scrum é necessário planejar antecipadamente todo o projeto, ou seja, mais de um sprint de uma só vez. Isso ocorre porque esses projetos são fechados com prazo, escopo e custo fixos. Para tanto, em muitos desses projetos existe uma fase comumente chamada de préprojeto. Essa fase ocorre antes do fechamento do contrato, e é responsável por definir as estimativas que irão direcionar todo o projeto. Nessa fase, primeiramente, o Product Owner define o Product Backlog completo do projeto em conjunto com o cliente. Esses são os itens que farão parte do escopo do projeto. Para cada um desses itens é feita uma breve descrição do mesmo, de forma a dar uma ideia do que o sistema deverá fazer. É importante ressaltar que o escopo não será totalmente detalhado nessa fase, mas sim ter-se-á apenas uma descrição bastante superficial de cada funcionalidade. Após isso, geralmente é reunido um time para realizar a estimativa de tempo de cada um dos itens do Product Backlog. Nessa reunião, o Product Owner faz uma explicação dos itens do escopo e o time pontua a complexidade de cada item, de forma a estimar seu tempo. Feito isso, o Product Owner tem as informações necessárias para montar um plano de releases ou plano de entregas. Nesse plano, o Product Owner divide o projeto em sprint s e define quais itens farão parte de cada entrega, de acordo com a priorização do cliente. Com o plano de releases concluído é possível definir a data de término do projeto, bem como seu custo total. De posse dessas informações, o contrato de prazo e custo fixo geralmente já é assinado pelas partes (cliente e fornecedor). Com o contrato assinado, o projeto tem início, e o processo do Scrum começa a ser executado. Em cada sprint, o Product Owner irá detalhar os itens mais prioritários do Product Backlog, e o time do projeto irá realizar a estimativa de tempo desses itens, de forma a definir quais itens serão desenvolvidos no sprint. É nesse ponto que reside o maior risco em projetos Scrum com prazo fixo. Isso porque, antes da assinatura do contrato, o que se tinha era uma breve descrição de cada funcionalidade do escopo. Já nesse momento, antes de iniciar cada sprint, é necessário que se tenha um detalhamento completo, a ser levantado junto com o cliente, das funcionalidades mais prioritárias do Product Backlog. Com isso, o cliente pode aumentar tanto quanto queira cada uma das funcionalidades, visto que esse detalhamento está aberto até o momento (existe apenas uma breve descrição). No contrato assinado está previsto o desenvolvimento dos itens do Product Backlog, mas não consta seu detalhamento completo, pois segundo o Scrum isso é definido em tempo de execução do projeto. Com isso, corre-se o risco de facilmente um item ficar com o dobro do tamanho estimado, o que poderá impactar várias áreas do projeto, principalmente tempo e custo. Existem ainda projetos que, de forma a diminuir o impacto sobre as demais áreas, optam por comprometer a qualidade. 2053

11 10 Além disso, existem ainda as frequentes mudanças de escopo. Vários itens que o cliente não visualizou na fase de pré-projeto surgem na fase de execução do projeto. Existem itens que, se não forem implementados, podem inviabilizar parte do projeto, sendo portanto críticos e estritamente necessários. O mais comum de ocorrer nesses casos é o fornecedor tentar absorver esses detalhes dentro do tempo e custo previamente acordados. Entretanto, com isso, o tempo disponível da release diminui, e sem uma renegociação com o cliente, geralmente a área mais afetada por esse tipo de decisão é novamente a qualidade. Outro aspecto que se evidencia é o impacto que essa problemática traz na área de recursos humanos do projeto. Isso porque, de acordo com o que o Scrum prega, a estimativa de tempo deve ser feita a cada sprint pelo Time do projeto. As comuns pressões por prazo que ocorrem em metodologias tradicionais não são aprovadas pelo Scrum, entretanto, ocorrem nesse tipo de situação, devido ao projeto já ter suas datas definidas. Esse tipo de cenário é prejudicial tanto para o cliente, que irá perder em qualidade do produto, quando para a equipe do projeto, que passa o projeto todo com a falsa sensação de trabalhar com o Scrum. Logo, como já mencionado anteriormente, projetos de prazo fixo funcionam bem quando o escopo está completamente detalhado antes do fechamento do contrato. Entretanto, no Scrum, o processo de detalhamento é incremental, realizado ao longo do projeto. E não há como realizar uma estimativa realista de um projeto, principalmente de software, sem o escopo estar bem detalhado. Com isso, surge essa problemática quando se tenta conciliar Scrum com projetos de prazo fixo. É preciso definir um elo entre esses pontos, para que esse tipo de projeto não esteja fadado ao fracasso, ou pelo menos, a passar por várias turbulências. 2054

12 11 3. Metodologia da Pesquisa Nesta pesquisa foi utilizado como método científico o método dedutivo. Primeiramente foi realizado um estudo do referencial teórico, que contempla os temas chave utilizados no problema da pesquisa, e com base nisso foi elaborada uma metodologia que visa conciliar de forma satisfatória a utilização do Scrum com projetos de prazo fixo. Dentro deste método, as premissas que foram utilizadas como base para criação da metodologia são: 1. No Scrum, o levantamento de requisitos é iterativo e incremental, e é realizado durante todo o projeto. Com isso, não se tem todo o escopo do projeto detalhado antes do fechamento do contrato, mas sim apenas uma lista de itens que constituem o Product Backlog, que também está passível de repriorização e possível alteração ao longo do projeto. 2. Em projetos de prazo fixo, o prazo total do projeto deve ser conhecido no momento de assinatura do contrato, pois essa informação fará parte do contrato. 3. Não é possível efetuar uma estimativa totalmente segura de tempo de desenvolvimento de um escopo sem se ter tal escopo completamente detalhado. Isso porque apenas com as especificações completas é que será possível uma análise real de riscos, um levantamento adequado dos atributos de qualidade, além de uma estimativa realista de tempo e custo do projeto. Com base nessas premissas é possível chegar a uma conclusão lógica. Inicialmente é possível perceber que a utilização de Scrum em projetos de prazo fixo tende a ser problemática. Isso porque, com o Scrum em sua forma pura não se terá todo o escopo detalhado no início do projeto, pela sua característica de ser iterativo e incremental (premissa 1). Entretanto, será necessário fornecer uma data de entrega do projeto, visto que isso é uma exigência de projetos de prazo fixo (premissa 2). Como não se tem todo o escopo detalhado, a estimativa de tempo do projeto não será totalmente segura, pois o projeto não possui informações suficientes para que seja realizada uma adequada análise dos riscos e estimativa de tempo e custo (premissa 3). Logo, nesse cenário, apenas metodologias que preguem o detalhamento do escopo em sua totalidade antes da determinação do prazo total do projeto podem fornecer uma maior segurança ao cliente. A metodologia apresentada na próxima seção, que visa conciliar os princípios do Scrum com projetos de prazo fixo, foi elaborada com base na conclusão mencionada anteriormente, levando em consideração o raciocínio apresentado, referente principalmente à área de escopo. 2055

13 12 4. Resultados: Proposta da Metodologia Nesta seção será proposta uma metodologia que visa conciliar o Scrum com projetos de prazo fixo, prevendo os pontos de integração do projeto decorrentes dos itens não planejados. A metodologia proposta prevê uma fase que denominaremos de pré-projeto. Essa fase será composta de duas etapas, uma denominada Etapa Inicial (EI) e outra denominada Etapa Final (EF). A EI visa efetuar um levantamento geral sobre o escopo do projeto. Nessa etapa, a empresa fornecedora irá enviar um analista de negócios (de preferência o futuro Product Owner do projeto) para ficar in loco na empresa cliente. Esse analista irá primeiramente entender a necessidade do cliente e as expectativas em relação ao produto. Feito isso, o analista irá levantar todos os itens do escopo do projeto em conjunto com o cliente. Cada um desses itens fará parte do Product Backlog do projeto. O analista então deverá entender de forma geral cada uma das funcionalidades levantadas, e criar uma breve especificação das mesmas. Com base nisso, o analista fará um estudo sobre cada uma das funcionalidades requisitadas e irá registrar as dúvidas em relação a cada item. Com as dúvidas registradas, será feita outra reunião com o cliente com a finalidade de saná-las, e, assim, fechar com clareza uma breve descrição de cada funcionalidade. Com essas informações levantadas, o analista irá retornar para a empresa fornecedora, e, juntamente com um time (de preferência o futuro Time que fará parte do projeto), irá realizar uma estimativa de tempo para cada uma das funcionalidades presentes no Product Backlog. É importante adiantar que essa estimativa não estará presente no contrato, será apenas para ser utilizada como base de decisão do cliente em prosseguir com a EF ou não, conforme será explicado na sequência. A estimativa de tempo deverá ser realizada de duas maneiras distintas, de forma a se ter uma maior segurança nos dados a serem definidos. Uma das maneiras poderá ser por pontos por caso de uso e a outra por pontos por story, mas esta metodologia propicia uma abertura para a empresa fornecedora utilizar suas próprias formas de estimativa de tempo, sendo as estimativas citadas apenas uma sugestão. Com base no tempo levantado para cada funcionalidade, a empresa fornecedora irá definir um tempo total para o projeto, levando em conta as peculiaridades de um projeto que utilize Scrum. A partir desse tempo, pode-se definir o custo do projeto com base no esforço total levantado. Com tempo e custo do projeto estimados, será calculado um percentual para mais e para menos a ser definido pela empresa fornecedora, com base na segurança da estimativa realizada. Assim, esse percentual não necessariamente deverá ser fixo para todos os projetos da empresa. Após isso, a empresa fornecedora irá apresentar para a empresa cliente a estimativa inicial de tempo e custo do projeto levantada na etapa de EI, com o intervalo oriundo do percentual para mais e para menos definido de acordo com a segurança da estimativa. A empresa fornecedora não terá o compromisso de desenvolver o projeto nesse tempo e custo, pois a definição final dessas informações só será possível com a execução da EF. Essa estimativa inicial é apenas para o que o cliente tenha uma noção de como será o projeto e decida em continuar ou não com a segunda etapa (EF). A EI é necessária porque geralmente o cliente está avaliando diversos fornecedores, assim, é preciso se ter pelo menos uma estimativa superficial para avaliar o quanto é viável prosseguir com a segunda etapa do préprojeto, que geralmente costuma levar um tempo maior para conclusão. A EF consiste na empresa fornecedora enviar, de preferência, o mesmo analista de negócios que participou da EI, para ficar novamente in loco na empresa cliente. Nessa etapa, o analista irá investigar minuciosamente cada um dos itens do escopo com o cliente. Assim, será feito um detalhamento completo do escopo total do projeto nessa etapa. O analista irá 2056

14 13 especificar as stories que irão direcionar toda a execução do projeto. O analista deverá fazer também, em conjunto com o cliente, uma priorização na lista de funcionalidades que compõem o Product Backlog. Após a especificação de todo o escopo estiver sido concluída, a mesma deverá ser aprovada formalmente com o cliente. Com isso, o cliente irá demonstrar seu de acordo com todos os itens do escopo. Após essa aprovação, o analista irá retornar para a empresa fornecedora e, juntamente com, de preferência, o mesmo time que participou da etapa EI, irá novamente estimar o tempo para cada uma das atividades do escopo, de duas maneiras distintas (de preferência as duas maneiras utilizadas na etapa EI). Nessa fase, o analista irá, com base nessas informações, montar o plano de releases do projeto. Com isso, será possível definir o tempo e custo total do projeto, com uma segurança alta pelo fato do escopo estar totalmente detalhado e aprovado pelo cliente. Esses dados de escopo, tempo e custo serão apresentados para o cliente, e caso o mesmo aceite, será assinado o contrato do projeto pelas partes (cliente e fornecedor). Deve-se, como regra essencial, anexar o escopo completo do projeto no contrato, uma vez que o mesmo será de prazo fixo, ou também conhecido como contrato de preço fixo. Com o contrato assinado, o projeto tem início e deve-se elencar um Product Owner, Scrum Master e Time para compor a equipe do mesmo. Como o escopo já está totalmente detalhado, a parte de tempo que o Product Owner iria gastar com o detalhamento das stories, este poderá dedicar ao gerenciamento das demais áreas do projeto, como risco e qualidade. É importante ressaltar que após a EI e EF concluídas e o contrato assinado, todos os demais processos e artefatos relativos ao Scrum serão seguidos normalmente (exceto o detalhamento das stories que já estará concluído). Para cada solicitação do cliente que seja alteração de escopo (o que, com essa metodologia, pode ser visto claramente no contrato), deverá ser feita uma negociação comercial a parte, em que será decidido se será o Time do projeto que irá desenvolver (caso seja deverá ser renegociado o prazo do projeto) ou uma equipe ou pessoas a parte que irão se integrar ao projeto. A cada mudança de escopo aprovada, deverá ser feita uma análise do impacto da alteração nas áreas do projeto, e realizada uma integração atualizando o status atual do projeto. Primeiramente, deverá ser levantado o escopo da nova funcionalidade, e, na sequência, avaliado os riscos inerentes a mesma. Depois, com base nisso, deverão ser realizadas iterações de integração visando atualizar os documentos do projeto, o andamento de solicitação de mudança e o plano de gerenciamento do projeto (linhas de base, planos auxiliares), principalmente no que se refere a risco, qualidade, tempo, custo e escopo. Essa integração é essencial para a saúde do projeto, visto que dependendo da forma que um item novo é tratado, pode-se ter um impacto bastante negativo no projeto. De acordo com a descrição realizada nessa seção, pode-se concluir que, nesse contexto, com a metodologia apresentada, é possível conciliar de forma satisfatória a utilização do Scrum com projetos de prazo fixo. 2057

15 14 5. Considerações Finais O Scrum na sua forma pura é melhor aplicável em projetos de escopo aberto, principalmente na área de TI, onde as mudanças de escopo são constantes. Isso porque, cada mudança de escopo solicitada requer uma análise de impacto e posterior replanejamento do projeto. Em projetos de prazo fixo cujo escopo não está completamente detalhado no momento de fechamento do contrato, abre-se brecha para o cliente aumentar cada item tanto quanto queira, uma vez que os itens estão previstos em contrato, mas não detalhados. Assim, não há como provar que determinada solicitação se trata de uma mudança de escopo. A metodologia proposta na seção 4 visa tornar viável para a empresa fornecedora a utilização do Scrum em projetos cujo tempo está fixado no contrato. Isso porque, nessa metodologia, o escopo é completamente detalhado e aprovado pelo cliente antes do início do projeto. Essas especificações são anexadas em contrato e assinadas pelo cliente. Com isso, é possível saber claramente quando que uma requisição é ou não mudança de escopo. Isso elimina grande parte da probabilidade de fracasso do projeto, pois o escopo será exatamente do tamanho que se pensava que fosse na fase de planejamento. Além disso, essa metodologia fornece uma maior segurança em relação às estimativas. Isso porque o projeto foi estimado, tanto em tempo quanto em custo, em cima do escopo completamente detalhado. Com isso, é possível analisar com clareza os riscos inerentes ao escopo e, assim, realizar as devidas integrações disso com as demais áreas do projeto. Cada mudança de escopo deve ser tratada de maneira adequada, de forma que seja realizado o controle integrado de mudanças, e isso é previsto por esta metodologia. Deve-se fazer, primeiramente, um alinhamento comercial para avaliar se a mudança de escopo irá ser desenvolvida em paralelo ao projeto, ou pelo próprio Time do projeto. Caso seja pelo mesmo Time do projeto, deverá ser realizado um estudo do impacto disso no projeto e um posterior replanejamento do mesmo. Apenas dessa forma é possível que o projeto possa ser avaliado de acordo com sua linha de base. Além disso, com essa abordagem o projeto não incorre no risco de perder em qualidade devido à diminuição do tempo por inserção de itens não previstos. Com a aplicação dessa metodologia, certamente projetos de prazo fixo que utilizem Scrum terão maiores chances de sucesso. Isso porque a metodologia elimina o problema do escopo mal definido (este estará inclusive aprovado formalmente pelo cliente), mitiga riscos com relação a estimativas de tempo e custo, e prevê a integração do projeto para cada alteração de escopo aprovada. Como trabalho futuro, pretende-se utilizar esta metodologia em um estudo de caso, com a finalidade de comprovar o sucesso desta proposta. 2058

16 15 6. Referências Beck, K. et al. Manifesto for Agile Software Development. USA: Disponível em: < Acesso em: 1 jul Magno, A. The Zen of Scrum: Certified ScrumMaster Training. São Paulo: Scrum Alliance, Project Management Institute, PMI. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK). 4. ed. Newtown Square, Pennsylvania, USA: Project Management Institute, Project Management Institute Chapters. PMSURVEY.ORG 2012 Edition. Brasil, Relatório. Disponível em: < Acesso em: 23 mar Schwaber, K. Agile Project Management with Scrum. USA: Microsoft Press, Schwaber, K., Sutherland, J. Scrum Guide. USA: Disponível em: < Acesso em: 24 mar