IMPLANTAÇÃO DE METODOLOGIA PARA SUPORTE TÉCNICO COM BASE EM METODOLOGIAS ÁGEIS

Transcrição

1 IMPLANTAÇÃO DE METODOLOGIA PARA SUPORTE TÉCNICO COM BASE EM METODOLOGIAS ÁGEIS Gabriel Antonello Pastoriza Guilherme Silva Lacerda Centro Universitário Ritter dos Reis Faculdade de Informática Rua Orfanatrófio, Bairro Alto Teresópolis - Porto Alegre RS Abstract. Currently, many companies are improving their infrastructure of IT. This improvement is necessary because the Information Technology is increasingly in all sectors of the companies. In order to succeed with these changes, it s important that there is a well structured team that follows the patterns of work adopted by the company. This task requires behavioral and structural changes, but if it s well applied, it can bring positive results for the company and for the team. This article describes a methodology of Technical support using Agile Methodologies. Based on the principles of ITIL and SCRUM, the main objective of this work is to create an own model of work. Keywords: Technical Support, ITIL, SCRUM, Agile Methodologies. Resumo. Atualmente, muitas empresas, estão aprimorando sua infra-estrutura de TI. Este melhoramento se faz necessário uma vez que a Tecnologia da Informação está cada vez mais presente em todos os setores das empresas. Para que se tenha sucesso com tais mudanças, é importante que haja uma equipe bem-estruturada e que siga os padrões de trabalho adotados pela empresa. Esta tarefa requer mudanças comportamentais e estruturais, mas se bem aplicada, pode trazer resultados positivos tanto para a empresa quanto para a equipe. Este artigo descreve uma metodologia de Suporte Técnico usando Metodologias Ágeis. Baseado em princípios da ITIL e do SCRUM, o principal objetivo deste trabalho é criar um modelo próprio de trabalho. Palavras chave: Suporte Técnico, ITIL, SCRUM, Metodologias Ágeis. 1. Introdução A Tecnologia da informação tornou-se parte integrante do negócio das organizações de todos os setores da economia. Neste contexto, os profissionais da área de TI são encarregados por executarem uma série de papéis. Além disso, muitos profissionais começam a focar-se no desafio de aprimorar suas áreas de TI. As organizações procuram serviços de TI que aumentem à eficiência operacional dos processos de negócio e ao mesmo tempo reduzam custos de suas transações comerciais. A importância do gerenciamento de TI está se tornando mais aparente para as organizações, à medida que as mesmas reconhecem cada vez mais a sua dependência dos serviços de TI para conseguirem satisfazer os objetivos estratégicos do negócio e irem de encontro às necessidades das suas unidades de negócio. Desta maneira, a

2 constante otimização no nível dos serviços de TI e o seu gerenciamento efetivo são necessários para assegurar o sucesso de qualquer negócio. Na área de Suporte técnico, a adoção de um método padrão de trabalho ainda é algo que é bastante discutido. Muitas vezes o uso de equipes pequenas e multidisciplinares faz com que haja um maior rendimento do trabalho e da produtividade e, conseqüentemente, maior satisfação do cliente com o produto final. A principal motivação na elaboração deste trabalho é mostrar a possibilidade de adotar práticas ágeis para estruturar uma metodologia de trabalho para Suporte Técnico. O uso de Metodologias Ágeis, em especial SCRUM, pode ser aplicado sempre que houver um grupo de pessoas em prol de um objetivo comum. A adoção do SCRUM, juntamente com ITIL, em uma equipe de Suporte Técnico, tornará a equipe mais integrada, a fim de garantir entregas dentro dos prazos estipulados, além de se ter um maior controle e conhecimento sobre as atividades que estão sendo realizadas por toda a equipe em questão. O principal objetivo deste trabalho é aplicar as melhores práticas de Gerenciamento de TI, juntamente com SCRUM, de maneira que seja possível a adaptação em empresas de diversos ramos e tamanhos, organizando-se e padronizandose os serviços prestados pela equipe de Suporte Técnico. Devido ao fato de todas as publicações da ITIL serem bastante extensas, optou-se por focar o trabalho na área de Operação de Serviço (Livro 4), pois ela apresenta orientações sobre como uma organização pode gerenciar com sucesso um serviço através do seu ciclo de vida de produção. O texto contido neste artigo está organizado da seguinte forma: a seção 2 contém o Referencial Teórico, a seção 3 contém o Estado da Arte, na seção 4 está contida a Solução Elaborada. Na seção 5 estão contidos os Resultados Alcançados. Por fim, a Seção 6 apresenta as Considerações Finais. 2. Referencial Teórico Esta seção do artigo contém informações de pesquisa sobre questões importante que são abordadas posteriormente no trabalho. Serão apresentadas informações referentes a Governança de TI, Metodologias Ágeis, Scrum e ITIL. Para o IT Governance Institute (2005), a governança de TI é de responsabilidade da alta administração (incluindo diretores e executivos), na liderança, nas estruturas organizacionais e nos processos que garantem que a TI da empresa sustente e estenda as estratégias e objetivos da organização. Analisando esta definição, pode-se concluir que a Governança de TI busca o compartilhamento de decisões de TI com os demais dirigentes da organização, assim como estabelece as regras, a organização e os processos que nortearão o uso da TI pelos usuários, departamentos, divisões, negócios da organização, fornecedores e clientes, determinando como a TI deve prover os serviços da empresa. De acordo com Fernandes e Abreu (2008), o ciclo de governança de TI pode ser dividido em 4 grandes etapas: Alinhamento estratégico, Decisão, Estruturas e medição do desempenho de TI. A Figura 1 ilustra o ciclo da Governança de TI.

3 Figura 1. O ciclo de governança de TI. (Fonte: Adaptado de FERNANDES, 2008) A etapa de alinhamento estratégico refere-se ao planejamento estratégico da tecnologia da informação, levando em consideração os objetivos da empresa para seus vários produtos e segmentos de atuação. A etapa de decisão, compromisso, priorização e alocação de recursos refere-se às responsabilidades pelas decisões relativas à TI em termos de: Infra-estrutura, arquitetura de TI, investimentos, necessidades de aplicações, etc. A etapa de estruturação de processos, operação e gestão refere-se à estrutura organizacional e funcional de TI aos processos de gestão e operação dos produtos e serviços de TI. Também são alinhadas as necessidades estratégicas e operacionais da empresa. Nesta fase são definidas ou redefinidas as operações de Sistemas, infra estrutura, suporte técnico, segurança da informação, etc. Por fim, a etapa de medição do desempenho refere-se à determinação, coleta e geração de indicadores de resultados dos processos, produtos e serviços de TI e a sua contribuição para as estratégias e objetivos do negócio (FERNANDES E ABREU, 2008). Para Fernandes e Abreu, o principal objetivo da Governança de TI é alinhar TI aos requisitos do negócio. Este alinhamento tem como base a continuidade do negócio, o atendimento às estratégias do negócio e o atendimento aos marcos de regulação externos. Desdobrando este objetivo principal, é possível identificar outros objetivos da Governança de TI: permitir à TI ter um posicionamento mais claro e consistente em relação às demais áreas de negócio da empresa: A TI deve entender as estratégias do negócio e traduzi-las em planos para sistemas, aplicações, soluções, estrutura e organização, processos e infra-estrutura; alinhar e priorizar as iniciativas de TI com a estratégia do negócio: o que foi planejado para acontecer deve ser priorizado, tendo em vista as prioridades do negócio e as restrições do capital de investimento; alinhar a arquitetura de TI, sua infraestrutura e aplicações às necessidades do negócio, em termos de presente e futuro: implantar os projetos e serviços priorizados e planejados;

4 prover à TI dos processos operacionais e de gestão necessários para atender os serviços de TI, conforme padrões que atendam as necessidades do negócio: a execução dos projetos e serviços de TI deve ser realizada de acordo com processos operacionais e de gestão, que devem estar inseridos em uma estrutura organizacional; prover a TI da estrutura de processos que possibilite a gestão do seu risco para a continuidade operacional da empresa onde os processos definidos, tanto operacionais como gerenciais, devem considerar a mitigiação de riscos para o negócio; prover regras claras para as responsabilidades sobre decisões e ações relativas a TI no âmbito da empresa. Isso significa identificar as responsabilidades sobre decisões no que se diz respeito aos princípios de TI, arquiterura de TI, infraestrutura de TI, necessidade de aplicações, investimentos, segurança da informação, estratégia de fornecedores e parcerias. (FERNANDES, 2008). Metodologias ágeis conjuntos de metodologias de desenvolvimento de software. Em 2001, um grupo de 17 pessoas deu início ao Manifesto Ágil, documento que reúne os princípios das Metodologias ágeis. Este documento definiu uma série de princípios, tais como: indivíduos e interações são mais importantes que processos e ferramentas; software em funcionamento é mais importante do que a documentação detalhada; colaboração com o cliente é mais importante do que negociação de contratos; adaptação a mudanças é mais importante do que seguir o plano inicial. Pode-se encarar o manifesto ágil como uma inquietação motivada por: Reação às metodologias pesadas, menos orientação ao documento e mais orientação ao código, métodos claros e adaptáveis, processos ágeis minimamente carregados com atividades que consomem e não produzem nenhum ganho visível (AGILE MANIFESTO, 2009). O SCRUM é um framework, iterativo incremental para o desenvolvimento de qualquer produto ou gestão de qualquer trabalho (KNIBERG, 2007). Inicialmente, o SCRUM foi concebido como uma maneira de gerenciamento de projetos em empresas de fabricação de automóveis e produtos de consumo, por Takeuchi e Nunaka. Eles perceberam que o uso de equipes pequenas e multidisciplinares produziam resultados melhores. A idéia principal do SCRUM é ser utilizada em projetos de desenvolvimento de software, embora possa ser utilizado em qualquer contexto no qual um grupo de pessoas trabalhem em prol de um objetivo comum, inclusive em equipes de manutenção, infraestrutura, etc. (SCHWABER, 2004). Para Schwaber (2004), O SCRUM estende todas as práticas em um esqueleto incremental de processos, onde a saída de cada interação é um incremento do produto. A Figura 2 ilustra o esqueleto do SCRUM. O círculo inferior representa uma interação de atividades de desenvolvimento as quais ocorrem uma após a outra. O círculo superior

5 representa a inspeção diária que ocorre durante a iteração, no qual os membros da equipe se encontram para inspecionar-se entre si. Figura 2. O Esqueleto do SCRUM. (Fonte: Adaptado de SCHWABER, 2004) Dentre as principais características do SCRUM, pode-se citar: mantém o foco na entrega do maior valor de negócio e no menor tempo possível; inspeção no software é rápida e contínua; as propriedades do desenvolvimento de um sistema são determinadas de acordo com as necessidades do negócio; equipes auto-organizadas para definir a melhor maneira de entregar as funcionalidades de maior prioridade. Com relação a terminologia do SCRUM, alguns termos são fundamentais para seu entendimento: sprint é uma interação que segue o ciclo PDCA e entrega incremento de software (ou serviço) pronto; product Owner é quem define as funcionalidades do produto, define datas e prioriza as funcionalidades de acordo com o seu valor de negócio. O valor de negócio é de uma determinada funcionalidade é estipulado em uma escala de zero a cem; backlog é um conjunto de atividades priorizadas. backlog de produto é mantido pelo Product Owner. É uma lista de requisitos que tipicamente vem do cliente; backlog de sprint é uma interpretação do Backlog de produto, e contém as tarefas que serão realizadas no próximo Sprint para implementar alguns dos itens do Backlog de Produto; scrum master tem a determinação de remover os obstáculos que impeçam ao time atingir seus objetivos, garantindo assim a plena funcionalidade e produtividade da sua equipe, assim como a colaboração entre os diversos papéis e funções. O SCRUM Master também é responsável por organizar os encontros do ciclo de um Sprint, além de ser um escudo para o time contra interferências externas;

6 time (team) é geralmente composto entre 5 a 9 indivíduos. Os times devem ser multifuncionais, ou seja, devem conter profissionais de diversas especialidades. Para Schwaber (2004), as vantagens no uso de SCRUM em projetos são inúmeras, das quais pode-se citar as seguintes: Clientes se tornam parte do time (maior proximidade da equipe com o cliente); Entregas freqüentes e intermediárias de funcionalidades plenamente desenvolvidas; Planos de riscos freqüentemente desenvolvidos pela equipe; Discussões diárias da equipe a respeito do status do projeto; Transparência no planejamento e desenvolvimento; Reuniões freqüentes com os stakeholders (envolvidos no projeto) monitoram o projeto mais freqüentemente. O SCRUM possui, por sua vez, um ciclo de vida composto por 4 fases. São elas: Planejamento, Preparação, Desenvolvimento e Entrega. Na fase de Planejamento, são estabelecidas as visões do projeto, bem como as expectativas dos envolvidos para sua execução. Além disso, também são criadas as versões iniciais do Product Backlog, o plano de Releases, a arquitetura de negócio e a arquitetura técnica em alto nível. Na fase de Preparação são avaliadas as várias dimensões do projeto. É nesta etapa que são adicionados itens ao Product Backlog relacionados com o tipo de sistema, equipe, ambiente de desenvolvimento e tipo de aplicação. As equipes são formadas e são construídas os mecanismos de comunicação e coordenação entre eles. Na fase de Desenvolvimento ocorre o desenvolvimento iterativo e incremental das funcionalidades do produto através de múltiplas Sprints. Nesta fase ocorre a maior alocação de pessoas e recursos. Por fim na fase de entrega realiza-se a entrega final do produto ao cliente, e suas atividades relacionadas, inclusive o treinamento do usuário final. Esta é a fase de menor duração do projeto (LARMAN, 2004). A ITIL (Information Technology Infrastructure Library) foi desenvolvida pelo CCTA (Central Computer and Telecomunications Agency) no final dos anos 80, a partir de uma encomenda do governo britânico. Neste cenário, foi solicitado o desenvolvimento de uma abordagem de melhores práticas para gerenciar a utilização dos recursos de TI. A versão 3 da ITIL foi lançada em Maio de 2007, e representa uma grande evolução em relação a anterior, pois organiza os processos de gerenciamento de serviços em uma estrutura de ciclo de vida de serviço. Como um framework, o propósito principal da ITIL é prover um conjunto de práticas de gerenciamento de TI testadas e comprovadas no mercado. A adoção das práticas da ITIL pretende levar um grau de maturidade e qualidade que permita o uso

7 eficaz e eficiente dos ativos de TI, sempre com foco no alinhamento e na integração com as necessidades dos clientes e usuários (FERNANDES, 2008). O núcleo da ITIL é composto por cinco publicações, cada uma delas relacionadas e um estágio do ciclo de vida do serviço, contendo orientações para uma abordagem integrada de gerenciamento de serviços, conforme ilustra a Figura 3: Figura 3. O Núcleo da ITIL. (Fonte: Adaptado de OFFICE OF GOVERNMENT COMMERCE, 2007). A Estratégia de Serviço orienta sobre como as políticas e processos de gerenciamento de serviço podem ser projetadas, desenvolvidas e implementadas como ativos estratégicos durante o ciclo de vida de Serviço. O Desenho de Serviço fornece orientação para o desenho e desenvolvimento dos serviços e dos processos de gerenciamento de serviços. A Transição de Serviço orienta sobre como efetivar a transição de serviços novos e modificados para operações implementadas. A Operação de Serviço descreve a fase do ciclo de vida do gerenciamento de serviços que é responsável pelas atividades do dia-a-dia, orientando sobre como garantir a entrega e o suporte a serviços de forma eficiente e eficaz. A Melhoria de Serviço Continuada orienta sobre como fazer sistematicamente melhorias incrementais e de larga escala na quantidade dos serviços, nas metas de eficiência operacional, na continuidade dos serviços, etc., com base no modelo PDCA, preconizado pela ISO/IEC (FERNANDES, 2008). A publicação Operação de Serviço, que será adotada parcialmente neste trabalho, com ênfase nos processos de Gerenciamento de Evento, Gerenciamento de Incidente e Gerenciamento de Problema, incorpora as práticas de Gestão de Serviços de Operações. Esta publicação abrange processos de Serviços de TI que são utilizados no dia-a-dia a fim de garantir a qualidade dos serviços. Descreve os componentes relacionados para que se tenha estabilidade e flexibilidade nos serviços de TI, além de incluir orientações sobre eficácia e eficiência na entrega e suporte de serviços, de modo a garantir um valor para o cliente e ao prestador de serviços.

8 Pode-se definir incidente como qualquer evento que não é parte padrão da operação de um serviço que causa (ou pode causar) uma interrupção ou redução da qualidade do serviço. A principal meta do Gerenciamento de Incidentes é restaurar a operação normal do serviço o mais rápido possível e minimizar o impacto negativo sobre as operações do negócio, garantindo que os melhores níveis de qualidade de serviço e disponibilidade sejam mantidos. Um problema pode ser definido como a causa desconhecida de um ou mais incidentes. O Gerenciamento de Problemas é o processo responsável por gerenciar o ciclo de vida de todos os problemas. O principal objetivo do Gerenciamento de Problemas é prevenir que problemas decorrentes de Incidentes possam vir a ocorrer, além de eliminar incidentes que podem ser evitados e minimizar o impacto dos que não podem ser evitados. Um evento pode ser definido como uma ocorrência detectável que possui importância para a Gestão de TI. Geralmente, são notificações criadas por algum serviço de TI, item de configuração ou ferramenta de monitoramento. O Gerenciamento de Eventos também fornece o ponto de entrada para a execução de vários processos de Operação de Serviço. A Requisição de cumprimento envolve a gestão de clientes ou solicitações de usuários que não são considerados como incidente. Finalmente, o processo de Gerenciamento de Acesso é aquele que concede a usuários autorizados o direito de utilizar um serviço, enquanto restringe a usuários não autorizados. (OFFICE OF GOVERNMENT COMMERCE, 2007). As práticas da ITIL são compatíveis com as várias modalidades de prestação de serviços de TI, tanto para locais quanto remotas. O modelo tem sido bastante utilizado em projetos e operações contínuas envolvendo itens de infra-estrutura, tais como manutenção de equipamentos, gerenciamento de redes, suporte à utilização de aplicações e outsourcing de processos de impressão, etc., podendo ser adaptado em empresas de diversos portes (FERNANDES, 2008). 3. Estado da Arte Esta seção do artigo é destinada para apresentar alguns trabalhos relacionados que motivaram na elaboração deste artigo. Serão citados trabalhos dos autores: Carfax, Shimada, Nóbrega e Beleze. No trabalho de Carfax (2006), concluiu-se que é possível juntar técnicas de XP com ITIL, desde que os processos que estão em torno da ITIL se tornem mais ágeis, diminuindo o planejamento de desenvolvimento de tarefas e de testes, de modo que se encaixe com as técnicas de trabalho do XP. Além disso, também é necessário que o XP forneça documentações quando necessário, pois algumas implementações em XP são centralizadas evitando documentações, porém alguma documentação é necessária para grupos ou serviços fora da equipe XP. No artigo de Shimada (2007), publicado na Revista de Pós Graduação da UNIFIEO, foi feito um trabalho de aplicação de ITIL e ISO/IEC na gestão de serviços de Suporte em Microinformática em uma empresa de grande porte na área financeira do país. A proposta deste trabalho foi elaborada tendo como base os livros da

9 ITIL 2.0 sobre Service Support e Service Delivery, e das recomendações da norma ISO/IEC Concluiu-se neste artigo que modelos de estrutura das áreas de TI mostram-se cada vez mais eficazes quando suportados pelo ITIL. Os processos de gerenciamento apresentados no ITIL, e reforçados pelas recomendações da norma ISO são aplicadas com objetivo de manter a melhoria contínua dos processos de trabalho. Na monografia de Nóbrega (2007), trabalho mostrado no curso de Pós Graduação Latu Sensu em Administração Estratégica de Sistemas de Informação na Fundação Getúlio Vargas, a autora implementa uma prática de Gerenciamento de Serviços no Tribunal de Justiça, analisando o impacto em processos do modelo ITIL. O trabalho trata-se de uma pesquisa na forma de Estudo de Caso de caráter exploratório que correlaciona a evolução dos conhecimentos com os resultados do Estudo de Caso realizado. Após abordar os principais conceitos de Governança de TI, permitiu-se verificar que a TI do STJ está na busca da melhoria dos serviços de TI com visão no negócio. Contudo, para se obter um elevado grau de satisfação nesta implementação, é necessário que a instituição esteja bem estruturada, aculturada, disposta e preparada para mudar. Ocorreram melhoras significativas nas funções de Central de Serviços e Gerenciamento de Incidentes, porém notou-se a necessidade de implementação do Processo de Gerenciamento de Configuração, para integrar os processos e a internalização dos processos da ITIL. Além disso, também sugeriu-se a elaboração de um catálogo de Serviços, para possibilitar melhor orientação aos usuários da TI no que tange ao seu atendimento. Ainda foi recomendada a implementação do Processo de Gerenciamento de Mudanças a fim de detectar as alterações dos itens de configuração de forma consistente e repetitiva. Conclui-se neste trabalho que o domínio da ITIL referente ao Suporte de Serviços é essencial e prioritário de se implementar para a operacionalização plena em uma gestão de TI. Também chegou-se à conclusão de que o Tribunal de Justiça tem investido nesse alinhamento da TI do seu negócio, entretanto trata-se de um modelo de alta complexidade que requer elevada integração de seus processos e demanda tempo para apresentação de resultados. O trabalho de (BELEZE, 2009) é um artigo da área de Engenharia de Produção e apresenta o uso do Kanban 1 em uma fábrica de software juntamente com SCRUM. Foi realizado um estudo de caso em uma Fábrica de Software da cidade de Maringá que utilizava antes apenas UML e PMBOK em suas aplicações. Em Dezembro de 2008 começou a utilizar SCRUM no desenvolvimento de seus projetos e posteriormente começaram a utilizar os conceitos do Kanban. De acordo com os resultados obtidos, pode-se concluir que o tempo médio para realização das tarefas diminuiu consideravelmente logo após a nova metodologia ser implantada. Outros pontos da fábrica de software também melhoraram, tais como: Aumento da qualidade dos produtos, diminuição de erros e gargalos e eliminação de desperdício de tempo de trabalho. Abaixo, no quadro 1, relacionados e o presente, é apresentada a comparação entre os trabalhos 1 Técnica de programação de produção, de origem japonesa, onde os próprios operadores controlam as necessidades de produção e prioridades através de um quadro com cartões ou fichas. (KNIBERG, 2007)

10 Quadro 1 Comparação entre trabalhos relacionados no Estado da Arte com o presente CARFAX SHIMADA NÓBREGA BELEZE PASTORIZA ITIL X X X X SCRUM X X KANBAN X X ISO X XP X 4. Solução Elaborada A adoção de Metodologias Ágeis da área de Desenvolvimento de Software é algo que vêm acontecendo freqüentemente e com sucesso. A principal vantagem no uso destas metodologias é que a preocupação maior da equipe está na entrega rápida do produto, não havendo gasto de tempo com documentações pesadas e complexas, além de haver maior contato do cliente com a equipe e flexibilidade com as mudanças do projeto ao invés de seguir um plano fechado. O uso do SCRUM em especial se deve ao fato de esta metodologia ágil possuir grande poder de comunicação entre toda a equipe. As chances de sucesso em um projeto são muito maiores em uma equipe onde há comunicação efetiva, entendimento e cooperação mútua. Muitas vezes a comunicação se torna mais importante que ferramentas e processos. No SCRUM o cliente também se torna parte da equipe, trabalhando juntamente com o SCRUM Master e a equipe de desenvolvedores. Além disso, no SCRUM há a opção de dividir tarefas complexas em Sprints menores, separando-se o planejamento da execução da tarefa e tornando assim os procedimentos mais simples. Hoje em dia, muitas empresas não dão a devida importância para suas áreas de Suporte Técnico. Boa parte de procedimentos são esquecidos, acarretando problemas que podem ser desde atrasos até mesmo perda de qualidade da prestação dos serviços de TI. A adoção de um padrão de comportamento e de rotinas se torna necessário para evitar tais problemas. A padronização do trabalho da equipe, tendo como base a adoção de um conjunto de melhores práticas, torna a execução de tarefas mais fáceis e organizadas, gerando desta forma um significativo aumento na produtividade de toda a equipe de Suporte Técnico. Neste novo modelo de trabalho, o uso de práticas da ITIL juntamente com SCRUM se faz necessário para que se tenha a formalidade das melhores práticas juntamente com a agilidade da Metodologia de Desenvolvimento de Projetos. Na publicação de Operação de Serviços da ITIL, estão contidas muitas orientações necessárias para que se tenha um padrão de trabalho a ser aplicado na Equipe de suporte Técnico. No uso do SCRUM, a participação do cliente juntamente no projeto se torna algo muito interessante, uma vez que tira da equipe a responsabilidade pela tomada de decisões. Além disso, a divisão de tarefas complexas em partes menores facilita o trabalho tanto na divisão de atribuições dos membros da equipe quanto na resolução dos problemas. A comunicação entre todos os membros da equipe também é fundamental

11 em um time de Suporte Técnico. Para estabelecer esta comunicação de forma efetiva, o SCRUM Meeting, reunião diária entre todos os membros da equipe, é uma ação bastante eficaz. Diariamente devem ser discutidas questões sobre o que a equipe realizou e o que está sendo realizado, em prol da realização das tarefas ainda pendentes. Para organizar o planejamento da execução das tarefas da equipe de Suporte, será utilizado o painel de Kanban. As tarefas a serem executadas são passadas do Product Owner para o responsável pela equipe de Suporte Técnico, que neste caso assume o papel de SCRUM Master. Este último deve gerenciar as atividades planejadas juntamente com o restante do time, colocando as atividades da iteração no quadro. A Figura 4 ilustra o modelo de Quadro de Kanban: Figura 4. Modelo de Quadro de Kanban para Suporte Técnico O espaço Atividades é destinado a colocar todas as atividades que devem ser realizadas pela equipe a cada iteração. Tais atividades podem estar dentro de 4 estados: Planejadas, Em Execução, Em Teste ou Prontas ; todas de acordo com o status em que se encontram. Também há um espaço destinado às tarefas que não puderam ser executadas por algum motivo ( Impedimentos ). No modelo de Quadro de Kanban também é possível observar o espaço destinado às retrospectivas. Este espaço possui a finalidade de manter a melhoria contínua do time, e nele são colocadas as atividades concluídas que a equipe considerou ou positivas ou negativas, além do Kaizen, que são as sugestões de melhorias para as próximas iterações. A priorização das tarefas realizadas pela equipe se dará em escala gradual definido de acordo com a ITIL. A Figura 5 e o Quadro 2 ilustram a priorização das atividades de Suporte Técnico e o tempo de resposta para um incidente, respectivamente:

12 Figura 5. Priorização de atividades Quadro 2 Descrição das prioridades e tempo de atendimento. PRIORIDADE DESCRIÇÃO TEMPO DE ATENDIMENTO 1 Crítica 1 hora 2 Alta 4 horas 3 Média 24 horas 4 Baixa 48 horas 5 Planejada - Ao final de cada Iteração, serão apontados os Indicadores Principais de Desempenho (IPDs) da Equipe de Suporte. Estes indicadores pertencem a ITIL e são importantes para que seja possível analisar o desempenho de toda a Equipe, além de apontar possíveis melhorias na solução de problemas. Os indicadores são os seguintes:. número total de incidentes por área de negócio; número de incidentes resolvidos por operador; redução do tempo médio de solução; distribuição de solução entre os níveis de Suporte; percentual de incidentes resolvidos com a base de conhecimento. A implementação desta proposta de metodologia de trabalho foi aplicada nos meses de Fevereiro, Março e Abril de 2010 em uma fábrica de softwares, localizada na cidade de Porto Alegre, no Parque Científico e Tecnológico da PUCRS (TECNOPUC), que existe desde A equipe, formada por três pessoas, já possuia uma metodologia de trabalho implantada. Era utilizada uma ferramenta proprietária para registro e acompanhamento de chamados de ocorrências de Suporte Técnico. Também era utilizada uma base de conhecimento, que nada mais era do que um repositório de arquivos onde ficavam os arquivos que explicavam alguns procedimentos mais complexos. A primeira etapa do trabalho, que foi realizada no primeiro mês de estudos (Fevereiro de 2010), foi constituída da análise da metodologia que até então era utilizada, a fim de manter os aspectos positivos desta organização e implantar novas

13 atribuições nos pontos a melhorar. Foram levantados alguns IPD s, os quais se pode ter algumas impressões a respeito da organização da equipe: não se sabia exatamente as atribuições de cada componente da equipe; Não era possível observar uma divisão da equipe por níveis de suporte. Esta falta de estruturação na equipe fazia com que os setores não soubessem a melhor maneira de recorrer caso ocorresse algum incidente. pouca documentação a respeito de atividades já realizadas; Os problemas mais complexos eram solucionados, porém havia documentação de poucos procedimentos realizados, dificultando a resolução de problemas recorrentes. atrasos com atividades planejadas ; As tarefas eram organizadas informalmente. Não se tinha priorização de tarefas, e estas eram entregues de uma só vez, gerando, muitas vezes, atrasos na entrega. Além disso, dificilmente o solicitante tinha algum feedback da equipe sobre o andamento das atividades. Ainda no mesmo mês, foi determinado com consentimento da equipe e da diretoria da empresa o tempo de cada iteração, que seria de 15 dias. Este período serviu para levantar informações referentes aos atendimentos de incidentes e problemas, realizar a retrospectiva e também coletar os primeiros IPD s ainda utilizando a metodologia antiga da empresa. As Figuras 6, 7 e 8 ilustram os Indicadores Principais de Desempenho do mês de Fevereiro: Figura 6. Número de Incidentes por Área do Negócio. (Fevereiro/2010) Como é possível analisar na Figura 6, a maior quantidade de incidentes ocorreu na área de desenvolvimento da empresa. A razão deste número desproporcional deve-se ao fato de o Desenvolvimento ser o setor que possui maior número de pessoas e, conseqüentemente, a maior quantidade de demandas a serem realizadas.

14 Figura 7. Número de Incidentes resolvidos por Operador. (Fevereiro/2010) A Figura 7 ilustra a quantidade de incidentes resolvidos por operador durante o mês de Fevereiro. É possível observar que a quantidade de trabalho não está dividida de forma proporcional. Como conseqüência deste fato, o Operador 2 acaba por trabalhar mais do que os demais. Figura 8. Percentual de incidentes resolvidos entre os níveis de Suporte. (Fevereiro/2010) A Figura 8 mostra a distribuição da quantidade de incidentes que foram resolvidos por nível de suporte. O Suporte nível 1 (menos avançado) corresponde aos operadores 2 e 3, enquanto o Nível 2 (suporte avançado) é representado pelo operador 1. Na Figura 8 também é possível observar que a distribuição dos incidentes entre os níveis de suporte estão bem distribuídos (77% no nível 1 e 23% no nível 2), visto que o Suporte de nível 2 é acionado somente se o nível de complexidade do incidente for grande e o nível 1 não consiga solucionar. Outro Indicador de Desempenho que foi analisado no mês foi o percentual de incidentes resolvidos com a Base de Conhecimento. Além disto, apenas 35% deles foram solucionados utilizando a Base de Conhecimentos. Por fim, também foi calculado o indicador de Tempo Médio de Solução de problemas. O valor nada mais é do que a média de todos os incidentes que ocorreram no mês em questão. O valor obtido foi de 2,37 horas por problema. Este número poderia ser menor, caso tivesse uma Base de Conhecimento mais completa para agilizar muitos procedimentos. No mês de Março de 2010, segundo mês de estudo, alguns procedimentos foram aprimorados para melhorar os índices apresentados no mês anterior. Primeiramente, foi

15 implantado o Quadro de Kanban, com a finalidade de mostrar as atividades da equipe de forma explicita e de fácil visualização. Posteriormente, foi adotada uma reunião diária, após o horário de almoço, baseada no Scrum Meeting. Esta reunião tinha a finalidade de discutir as tarefas de Suporte Técnico: O que foi feito, o que será feito. Ainda no mês de Março de 2010, o Sistema de chamados começou a ser utilizado freqüentemente para registrar os chamados priorizar as atividades tendo como base a criticidade dos problemas, com base na ITIL. O tempo médio para solução de problemas aumentou neste período, e isto se deve ao fato de haver mais uso de tempo do atendimento dos incidentes para alimentar a base de conhecimento com a documentação necessária. As Figuras 9, 10 e 11 ilustram o número de Incidentes por Área de Negócio, número de incidentes resolvidos por Operador e o percentual de incidentes resolvidos com a base de conhecimento no mês de Março, respectivamente: Figura 9. Número de Incidentes por Área de Negócio. (Março/2010) A Figura 9 mostrou que a mudança no comportamento da equipe não diminuiu o número de incidentes. Os incidentes resolvidos por operador ficaram distribuídos conforme ilustra a Figura 10: Figura 10. Número de Incidentes resolvidos por operador. (Março/2010) Os números acima foram obtidos graças ao uso do quadro de Kanban e da reunião diária, pois estes dois recursos ajudaram muito na comunicação entre os membros da equipe, tornando mais fácil a divisão do trabalho. O percentual de incidentes resolvidos por nível de suporte se manteve praticamente o mesmo do mês anterior, visto que a divisão das tarefas por nível de suporte já era bem estruturada.

16 Figura 11. Percentual de incidentes resolvidos entre os níveis de Suporte. (Março/2010) Outro Indicador importante é o tempo médio de solução de incidentes e problemas. No mês de Março, este valor aumentou consideravelmente, passando para 3,57 horas por problema. O aumento no valor do tempo foi causado pela necessidade de alimentar a Base de Conhecimento pela equipe, com objetivo de reduzir este tempo posteriormente. A utilização da Base de Conhecimento neste mês aumentou em uma ótima proporção, sendo possível resolver 59% dos incidentes utilizando este recurso. Este valor já foi alcançado mesmo com a base estando completa de forma parcial, mostrando a importância de uma documentação para o sucesso na solução de problemas No mês de Abril de 2010 a equipe trabalhou de forma integral utilizando a metodologia proposta. Os resultados foram positivos; o sistema de chamados, juntamente com o Kanban proporcionaram um controle mais efetivo sobre as atividades. O Sistema de chamados formalizou as tarefas que eram executadas, e este ponto foi bastante útil na emissão de relatórios que auxiliavam a diretoria da empresa nas questões de gerenciamento da infra - estrutura. O tempo médio de resolução dos incidentes também diminuiu consideravelmente, além de ter permanecido a divisão uniforme das tarefas entre os operadores. As Figuras 12, 13 e 14 ilustram alguns IPD s do mês de abril: Figura 12. Número de Incidentes por Área de Negócio. (Abril/2010) Como já tivera acontecido nos meses anteriores, os valores dos Incidentes por Área do negócio permaneceram praticamente iguais, não sendo alterados pelo uso efetivo da Metodologia de Trabalho. Caso a Figura 12 fosse analisada tendo como base

17 apenas dois grandes grupos, o Desenvolvimento, que é o foco do negócio e as demais áreas agrupadas em um só bloco, o número de incidentes dessas outras áreas muito maior do que no desenvolvimento. Acredita-se que esta diferença ocorra devido ao fato de os demais setores não possuírem usuários de recursos de TI tão qualificados quanto no setor de Desenvolvimento. A seguir, a Figura 13 demonstra a quantidade de incidentes resolvida por operador: Figura 13. Número de Incidentes resolvidos por operador. (Abril/2010) Acima é possível observar que o número de incidentes resolvidos pelos operadores 2 e 3 é praticamente o mesmo, mostrando que foi mantida a uniformidade da execução das tarefas entre os operadores que compõem o Suporte de nível 1, deixando apenas os problemas mais avançados para o nível 2; e esta estabilidade nos números foi obtida graças ao uso do painel de Kanban e das reuniões diárias. A Figra 14 ilustra a distribuição das soluções entre os níveis de Suporte: Figura 14. Percentual de incidentes resolvidos entre os níveis de Suporte. (Abril/2010) No mês de Abril também foram medidos o Tempo Médio de Solução de Problemas, bem como o percentual de incidentes resolvidos com a Base de Conhecimento. Estes indicadores tiveram os valores de 1,96 horas e 74%, respectivamente. Estes valores foram muito positivos, pois mostrou que o período que a Base de conhecimento foi mais utilizada na solução de incidentes foi o mesmo período que se obteve o menor tempo médio de solução.

18 O mês de Abril também foi importante, pois além do fato de a equipe estar adaptada com nova rotina de trabalho, também houve a plena adaptação dos usuários que solicitavam serviços do Suporte Técnico. Com a formalização de todos os incidentes através do Sistema de Chamados e com a boa comunicação da equipe através das reuniões diárias e do Kanban, foi possível obter um pleno gerenciamento sobre as demandas de cada usuário, estes que acabavam por saber melhor do andamento de suas solicitações. 5. Considerações Finais Na adoção deste novo modelo de trabalho, muitos desafios foram enfrentados, pois a implantação de melhores práticas é algo que requer muita força de vontade. Muitas organizações ainda possuem a filosofia de que não são necessários investimentos em infraestrutura de TI, mas não percebem que esta divisão da empresa possui importância vital para os demais setores. A tarefa de mudar a cultura de uma equipe não é nada trivial. Muitas equipes de Suporte Técnico possuem suas próprias rotinas de trabalho, e a implantação de uma nova metodologia baseada nas melhores práticas pode ser encarada como uma crítica ao seu modelo de trabalho atual. O que é desejado é apenas a melhoria do time como um todo, e conseqüentemente, maior satisfação de todos os usuários dos serviços de TI. Mudar o pensamento de um time inteiro não é uma tarefa fácil; é necessário convencer os membros de que a adoção do novo modelo de trabalho é melhor que a atual. Além de mudar a filosofia da equipe, é importante mudar a filosofia dos superiores da empresa, a fim de que a implantação seja levada a sério e com o consentimento de todos. Utilizando apenas conceitos básicos de SCRUM, ITIL e Kanban, foi possível adotar uma metodologia de trabalho capaz de agradar a grande maioria dos colaboradores da Fábrica de Software do presente estudo. Com os conceitos da ITIL foi possível observar que a medição de Índices de Desempenho, utilização do Sistema de Chamados e documentação eficiente tornam o trabalho muito mais organizado e formalizado. Utilizando princípios do SCRUM, como as reuniões diárias após o almoço, bem como a participação do cliente (neste caso o usuário) foi possível perceber que a comunicação é um fator fundamental em uma equipe em que todos trabalham com os mesmos objetivos. E por fim, utilizando o quadro de Kanban, foi possível organizar a execução de tarefas de forma visual e rápida, mostrando o andamento das atividades do ciclo de trabalho para todos. Este trabalho mostrou que é possível adotar o uso de melhores práticas juntamente com Metodologias Ágeis em uma equipe de Suporte Técnico sem que haja grandes mudanças estruturais na empresa. É necessário que existam pessoas na equipe que estejam interessadas no conceito de melhoria contínua, bem como apoio das partes estratégicas e táticas do negócio. 6. Referências Agile Manifesto. Disponível em < Acesso em: 05.nov BELEZE, Casimiro. Kanban na Fábrica de Software. Trabalho publicado na XVI SIMPEP (Simpósio de Engenharia de Produção), 2009.

19 CARFAX, Charles Hoover. ITIL vs. Agile Programming: Is the Agile Programming Discipline Compatible with the ITIL Framework?. Artigo publicado na revista GMC CONFERENCE, FERNANDES, Aguinaldo Aragon; ABREU Vladimir Ferraz de. Implantando a Governança de TI: Da Estratégia à Gestão de Processos e Serviços. 2. Ed. Rio de Janeiro: Brasport. 444 p, IT Governance Institute. Disponível em < Acesso em: 11.nov KNIBERG, Hendrik. SCRUM e XP Direto das Trincheiras: Como nós fazemos o SCRUM. C4Media: Disponível em: < Acesso em: 15.set LARMAN. Larman C. Agile & Iterative Development, A Manager s Guide. Addison-Wesley, NÓBREGA, Rose Mary Dourado Reis. Implementação De Prática de Gerenciamento de Serviços de TI no Superior Tribunal de Justiça: Uma análise do Impacto em Processos do Modelo ITIL. Brasília/DF, OFFICE OF GOVERNMENT COMMERCE. ITIL Service Operation v.3.0. The Stationery Office Ltd. Norwich, Inglaterra, SCHWABER, Ken. Agile Project Management With SCRUM. 1. Ed. Washington: Microsoft Press. 163 p, SHIMADA, Lucio Mitio. Aplicação do ITIL e ISO/IEC na Gestão de Serviços de Suporte em Microinformática. Revista da Pós Graduação da UNIFIEO, 2007.