Escolar Documentos
Profissional Documentos
Cultura Documentos
Porto Alegre
2012
BRUNO SOUZA DE OLIVEIRA
Ao meus pais pelo apoio, dedicação e incentivo para o meu crescimento pessoal e
profissional. A minha esposa pela compreensão e o apoio prestado durante a elaboração deste
trabalho. Ao meu orientador Marcelo Hideki Yamaguti pela sabedoria e o apoio dispensado
para realização deste trabalho e a toda equipe da célula de serviços do Projeto AGHU que
serviram de inspiração para elaboração desta monografia, além de terem prestado todo o
apoio necessário para o sucesso deste.
“Quanto aos métodos, pode haver mais de
um milhão deles, mas são poucos os
princípios. O homem que souber os
princípios pode selecionar com sucesso os
próprios métodos. O homem que testar os
métodos, ignorando os princípios,
certamente terá problemas”,
Keywords: ITIL, service management, agile, Scrum, XP, Kanban, quality service.
LISTA DE ILUSTRAÇÕES
INTRODUÇÃO........................................................................................................................13
1.1 Motivação ..................................................................................................................14
1.2 Solução Proposta........................................................................................................14
1.3 Objetivos ....................................................................................................................16
1.4 Estrutura do Trabalho ................................................................................................16
2 MÉTODO DE PESQUISA...............................................................................................18
2.1 Fundamentação Teórica .............................................................................................18
2.2 Avaliação Inicial ........................................................................................................19
2.3 Definição....................................................................................................................20
2.4 Execução ....................................................................................................................20
2.5 Análise dos Resultados ..............................................................................................20
3 FUNDAMENTAÇÃO TEÓRICA ...................................................................................22
3.1 Gerenciamento de Projetos ........................................................................................22
3.2 Gerenciamento de Serviços em TI.............................................................................25
3.2.1 Estratégia de Serviços (Service Strategy)...........................................................27
3.2.2 Desenho de Serviços (Service Design)...............................................................27
3.2.3 Transição de Serviço (Service Transition) .........................................................28
3.2.4 Operação de Serviço (Service Operation) ..........................................................29
3.2.4.1 Gerenciamento de Eventos..........................................................................31
3.2.4.2 Gerenciamento de Incidentes ......................................................................33
3.2.4.3 Gerenciamento de Problemas......................................................................36
3.2.4.4 Cumprimento de Requisições .....................................................................38
3.2.4.5 Gerenciamento de Acesso ...........................................................................38
3.2.4.6 Central de Serviços......................................................................................39
3.2.4.7 Gerenciamento Técnico...............................................................................40
3.2.4.8 Gerenciamento da Aplicação ......................................................................40
3.2.4.9 Gerenciamento das Operações de TI...........................................................41
3.2.5 Melhoria Contínua de Processo (Continual Process Improvement) ..................42
3.3 Gestão Ágil de Projetos .............................................................................................44
3.3.1 Scrum ..................................................................................................................47
3.3.2 XP (Extreme Programming)...............................................................................50
3.3.3 Kanban ...............................................................................................................52
3.4 Síntese da Fundamentação Teórica............................................................................53
4 AVALIAÇÃO INICIAL ..................................................................................................56
4.1 Projeto AGHU ...........................................................................................................56
4.2 Descrição do Ambiente..............................................................................................57
4.2.1 Estrutura do Projeto AGHU ...............................................................................58
4.2.2 Estrutura da Célula de Serviços de TI ................................................................60
4.3 Instrumento de Avaliação ..........................................................................................62
4.4 Aplicação do Instrumento de Avaliação ....................................................................67
5 DEFINIÇÃO.....................................................................................................................71
5.1 Avaliação das metodologias estudadas......................................................................71
5.2 Definição de Estrutura do Projeto..............................................................................72
5.3 Definição de Processos ..............................................................................................78
5.3.1 Central de Serviços.............................................................................................84
5.3.2 Catálogo de Serviços ..........................................................................................89
5.3.3 Workflows por Tipos de Requisição ...................................................................90
5.3.4 Método de Trabalho das Equipes da Célula de Serviços de TI ..........................97
5.3.5 Ferramenta de apoio .........................................................................................103
6 EXECUÇÃO ..................................................................................................................104
6.1 Planejamento da Implantação ..................................................................................104
6.2 Execução da Implantação ........................................................................................105
6.3 Reaplicação do Instrumento de Avaliação...............................................................112
7 ANÁLISE DOS RESULTADOS ...................................................................................116
7.1 Análise de Pontos Positivos e Negativos .................................................................118
7.2 Análise de Pontos a Melhorar ..................................................................................119
8 CONCLUSÃO................................................................................................................121
8.1 Limitações do Trabalho ...........................................................................................122
8.2 Trabalhos Futuros ....................................................................................................122
REFERÊNCIAS BIBLIOGRÁFICAS ...................................................................................124
APÊNDICE A – Dados coletados no instrumento de avaliação ............................................126
APÊNDICE B – Fluxo completo de uma requisição de serviço ............................................129
APÊNDICE C - Fluxo completo de um incidente ou problema.............................................130
APÊNDICE D – Catálogo de serviços ...................................................................................131
APÊNDICE E – Métricas .......................................................................................................141
APÊNDICE F – Exemplos de Ambiente Informativo ...........................................................147
APÊNDICE G – Dados coletados na reavaliação do instrumento de pesquisa......................148
INTRODUÇÃO
Segundo van Bon (2002), ao longo das duas últimas décadas o mundo de Tecnologia da
Informação (TI) mudou drasticamente, com isso, surgiram diversas outras preocupações que
inexistiam anteriormente e, a partir dessas, nasceram várias boas práticas como sugestão para
encarar essa nova realidade.
Em um mundo de crescente complexidade, escolha e globalização, a TI precisou mudar
seus processos, perceberam que a maioria de seus projetos estava fracassando e que algo
precisava mudar. Entendeu-se que não se podia mais apenas se preocupar com o
desenvolvimento do software, mas também em como manter este em seu correto
funcionamento após a sua entrega e, principalmente, zelar pelo relacionamento com o cliente.
Sendo necessário garantir a qualidade dos serviços prestados para o cliente também após a
conclusão do projeto, pois é nesse momento que será observado o valor do serviço prestado
(BON, 2002).
Gerenciar esses serviços é a alternativa para garantir o melhor atendimento possível
aos clientes, com isso e seguindo no contexto a evolução do mundo, surgem diversas novas
ideias para serem aplicadas nas mais diversas realidades, como é o caso da Information
Technology Infrastructure Library (OGC, 2007a) focada em gerenciamento de serviços e as
práticas ágeis inicialmente com o foco em desenvolvimento de software.
Ambas as práticas sempre vão estar em constante evolução, pois é necessário
acompanhar o crescimento do mundo, sua velocidade e mudanças constantes o que o torna
cada vez mais complexo e é com esse entendimento que as organizações vêm evoluindo de
forma a garantir um diferencial competitivo.
13
1.1 Motivação
15
1.3 Objetivos
O objetivo principal deste trabalho é a construção e implantação de um processo de
gerenciamento de serviços constituído com base na ITIL v3 focado na fase e operação de
serviços e práticas ágeis aplicados à realidade do Projeto AGHU, para assim, melhor atender
as necessidades dos HUF’s.
Alinhado a este objetivo, pretende-se atingir os seguintes objetivos secundários:
17
2 MÉTODO DE PESQUISA
O desenho da pesquisa apresentado neste capítulo está alinhado com o objetivo deste
trabalho, sendo assim, é importante ressaltar que o mesmo não visa aplicar todas as boas
práticas possíveis e sim entender o contexto atual e aplicar apenas o que realmente deve
agregar valor a célula de serviços de TI do Projeto AGHU.
Nesse sentido abaixo segue um diagrama que ilustra a ordem que será construída este
trabalho:
18
O sucesso desta metodologia será avaliado através de sua aplicação durante algum tempo
e a coleta de dados oriunda de métricas e questionários, sendo estes, medidos antes do inicio
da implantação da metodologia e após sua implantação, assim nos fornecendo dados
comparativos. Então para sua melhor execução, esta fase está dividida em três grandes
atividades:
1. Estudo e identificação de literatura necessária para construção do trabalho:
nesta atividade deve ser pesquisado um conjunto de literaturas que devem ajudar
na concepção deste trabalho;
2. Estudo e identificação de boas práticas ITIL: esta fase deve iniciar o estudo de
boas práticas da ITIL com base na literatura selecionada na primeira atividade
realizada do método de pesquisa;
3. Estudo e identificação de boas práticas ágeis: esta fase deve iniciar o estudo de
boas práticas ágeis com base na literatura selecionada na primeira atividade
realizada do método de pesquisa.
19
devem ser coletados e armazenados para comparação após a implantação do
método.
2.3 Definição
Na fase de definição é onde deve ser montada a proposta de processo para a célula de
serviços de TI do Projeto AGHU, esta definição será guiada por todo o estudo realizado nas
fases anteriores, por esse motivo é imprescindível que as fases anteriores já estejam
concluídas antes de se iniciar esta. Com esse intuito esta fase apresenta uma grande atividade
nomeada de “Definição e desenvolvimento de metodologia para o processo de operação”
onde será finalizada a proposta do processo.
2.4 Execução
Com a metodologia definida é necessário aplicá-la, para isso essa fase foi dividida em
duas grandes atividades:
Este capítulo teve o objetivo de explicar como este trabalho será conduzido, no próximo
capítulo será apresentada a fundamentação teórica, primeira fase do método de pesquisa,
conforme ilustrado na figura 1.
21
3 FUNDAMENTAÇÃO TEÓRICA
Durante muitos anos, as organizações puderam continuar seus negócios, ainda que
tivessem pouco apoio da TI (Tecnologia da Informação). Hoje a realidade é diferente, a TI é
um fator crítico de sucesso para organização, por esse motivo, cada vez mais vem se tornando
um dos pilares estratégicos dessas instituições, sendo muitas vezes seu grande diferencial
competitivo.
22
1. Grupo de processos de iniciação: onde deve ser realizada uma definição inicial
de um novo projeto ou nova fase de um projeto existente, sendo que este será
analisado e aprovado de acordo com a estratégia da organização;
2. Grupo de processos de planejamento: neste grupo deve ser definido o escopo
total do projeto bem como os objetivos desejados, assim elaborando um
planejamento para que seja possível alcançar estes objetivos dentro dos prazos
acordados;
3. Grupo de processos de execução: tem a responsabilidade principal de elaborar o
plano de gerenciamento do projeto além de integrar pessoas e recursos;
4. Grupo de processos de monitoramento e controle: compostos de processos
com a finalidade de monitorar e controlar métricas frequentemente para assim,
melhor avaliar o andamento do projeto e tomar alguma ação caso necessário;
5. Grupo de processos de encerramento: neste grupo é onde deve ser
encaminhado o encerramento formal do projeto de forma ordenada.
23
Figura 2 - Resumo em Alto Nível das Interações entre os Grupos de Processos (PMI, 2008).
24
3.2 Gerenciamento de Serviços em TI
Serviço de TI é um meio para entregar valor para os clientes, com o objetivo de que esses
alcancem os resultados desejados, sem que tais clientes precisem assumir custos e riscos
específicos inerentes a TI. Gerenciamento de Serviços de TI é o conjunto de capacidades
organizacionais (processos e métodos de trabalho, funções, papéis e atividades) realizadas
para prover valor sob a forma de serviços (OGC, 2007a).
Implementada no fim da década de 1980 pelo governo britânico, inicialmente pela CCTA
(Central Computing and Telecommunications Agency) e atualmente pelo OGC (Office of
Government Commerce), sendo que, o OGC é um órgão que tem como objetivo desenvolver
metodologias e criar padrões dentro dos departamentos do governo britânico (OGC, 2007a),
A ITIL (Information Technology Infrastructure Library) nasceu como um catálogo de
melhores práticas para os departamentos de TI de seus órgãos governamentais, pois
perceberam que estavam gastando muito dinheiro para manter seus serviços em
funcionamento e decidiram criar uma biblioteca de boas práticas para melhorar sua gestão de
serviços.
Após o seu nascimento as empresas começaram a entender que as boas práticas descritas
poderiam ser utilizadas em seus departamentos de TI e em 1990 a ITIL acabou se tornando
um padrão de fato em todo o mundo (OGC, 2007a).
A TI se tornou uma grande dependência para os negócios, fazendo com que os gestores
busquem cada vez mais a adoção de melhores práticas com o objetivo de trazer resultados
positivos, reduzindo custos e aumentando a produtividade de seus processos. Com este fato, a
ITIL acabou despertando um grande interesse no mercado, pois as empresas começaram a se
preocupar com o Gerenciamento de Serviços de TI.
A ITIL oferece uma biblioteca de melhores práticas comum para todas as tarefas de uma
célula de serviços de TI, como a parte da operação dos serviços, baseada na infraestrutura de
TI. Estas tarefas são divididas em processos, que fornecem um framework eficaz para um
Gerenciamento de Serviços aprimorado. As melhores práticas descritas na ITIL têm como
objetivo (OGC, 2007a):
25
• Sugerir por que adotar os processos e práticas.
Uma observação importante é que a ITIL não pode ser considerada uma metodologia,
pois as melhores práticas são flexíveis a ponto de o usuário adaptar aos seus processos, já uma
metodologia possui uma implementação mais definida, com regras bem definidas, que é
exatamente a proposta desse trabalho.
Com o passar dos anos a ITIL teve melhorias e o acréscimo de mais práticas bem
sucedidas, desta forma este trabalho utiliza a terceira versão desta biblioteca que tem o foco
no ciclo de vida do serviço representando uma grande mudança estrutural entre as demais
versões.
26
Conforme a figura 3 apresentada acima, o ciclo de vida de serviços da ITIL v3 é dividido
em cinco grandes processos, um para cada fase. O processo trabalhado neste trabalho será o
de Operação de Serviço, entretanto, a seguir segue uma explicação de cada um dos processos
a fim de contextualizar o trabalho.
Pode se entender que este processo faz parte de uma análise de requisitos e definição
inicial, orientando o uso do Gerenciamento de Serviços como uma ferramenta estratégica para
satisfazer as necessidades do negócio, sendo que seu principal objetivo é identificar requisitos
e necessidades do negócio, que são acordados e documentados em um pacote de níveis de
serviço (OGC, 2007b).
A Estratégia de Serviço é a primeira fase do ciclo de vida de um serviço, e se caracteriza,
principalmente, por ser o eixo central que move todas as outras fases; tudo gira ao redor da
estratégia. Talvez um dos grandes diferenciais da ITIL e mais especificamente desta fase é a
proposta de integração entre as áreas de negócio e a TI de forma que cada um ressalte o que
há de melhor no outro focando mais no sucesso do cliente do que a eficiência e eficácia das
operações, qualidades estas, que apresentam uma relação com os valores das práticas ágeis.
Um dos propósitos desta fase é fazer com que os provedores de TI pensem de maneira
estratégica para que eles possam operar aumentando cada vez mais sua lucratividade, e
desenhar estratégias e modelos organizacionais baseados em serviços e com a visão da
organização.
Esta fase apresenta os seguintes objetivos:
• Identificar as necessidades do negócio;
• Desenvolver estratégias para satisfazer as necessidades do negócio;
• Ajudar a selecionar as melhores opções para o aperfeiçoamento do serviço;
• Analisar o uso dos serviços para criar valor para o negócio.
27
Nesta fase, como o próprio nome sugere, é onde os serviços devem ser desenhados
baseados nas estratégias definidas na fase anterior, a fim de atender as necessidades do
negócio. Seus principais objetivos são (OGC, 2007c):
Seu principal propósito é implantar os desenhos, elaborados na fase anterior, com sucesso
para que a área de operação possa gerenciar os serviços e a infraestrutura de maneira
controlada. Seus principais objetivos são (OGC, 2007d):
28
• Gerenciar o processo de mudança de serviços, a fim de assegurar o menor
impacto possível ao cliente, aumentando assim sua satisfação.
• Assegurar recursos necessários para elaborar, planejar e implantar um novo
serviço.
• Gerenciamento de Mudança;
• Gerenciamento de Configuração e de Ativo de Serviço;
• Gerenciamento do Conhecimento;
• Planejamento e Suporte da Transição;
• Gerenciamento de Liberação e Implantação;
• Validação e Teste de Serviço;
• Avaliação.
Pode ser considerada uma das principais fases do ciclo de vida da ITIL v3, pois é nessa
fase onde é executado todo o planejamento estratégico e tático realizado nas fases anteriores,
sendo focada nas demandas do dia a dia e tem o dever de mostrar para o cliente o valor da TI.
Por essa característica, a fase de Operação de Serviço será o foco deste trabalho, sendo assim,
esta seção é descrita de forma mais detalhada. Segue uma descrição de relações importantes
que se tornam objetivos conflitantes:
29
uma mudança de comportamento de seus clientes, pois as solicitações de mudança se
tornam cada vez mais frequentes. Logo se torna claro que as organizações que
responderem mais rapidamente a essas mudanças de escopo terão um grande
diferencial competitivo. Visando essa tendência a ITIL v3 sugere um balanceamento
entre estabilidade e agilidade, nem tão estável para não ser tão lento para adaptar-se e
nem tão ágil para não ser muito instável.
• Qualidade do serviço versus Custo do serviço: Existe ainda a relação de
qualidade do serviço e o custo do serviço, o cliente se torna cada vez mais exigente,
por outro lado não é simples ter qualidade a um baixo custo, logo é necessário
encontrar o equilíbrio ideal dessa relação com o objetivo de atender a requisição do
cliente dentro do prazo acordado ao menor custo possível e com alta qualidade.
• Reativo versus Proativa: Conforme descrito acima, o mundo pede cada vez
mais respostas rápidas a suas mudanças, para que isso se torne realidade é preciso ser
proativo em suas atitudes com o objetivo de minimizar ao máximo o impacto para o
cliente, não se pode mais se reativo, no sentido de somente atuar quando o problema já
existe.
Para o sucesso desses objetivos, além das fases anteriores, a operação do serviço é
dividida em cinco grandes processos e quatro importantes funções:
Processos:
30
1. Gerenciamento de Eventos;
2. Gerenciamento de Incidentes;
3. Gerenciamento de Problema;
4. Cumprimento de Requisições;
5. Gerenciamento de Acesso.
Funções:
1. Central de Serviços;
2. Gerenciamento Técnico;
3. Gerenciamento da Aplicação;
4. Gerenciamento das Operações de TI.
31
• Informativo: apenas mensagens com informações que não impactam no serviço
podem ser qualificadas como mensagens informativas ou de operação regular;
• Alerta: mensagens avisando que algum serviço está executando de forma anormal,
mas ainda está em funcionamento, operação usual;
• Exceção: alerta sobre uma anormalidade mais grave no serviço que pode ter
prejudicado o seu correto funcionamento.
32
3.2.4.2 Gerenciamento de Incidentes
33
Figura 5 - Fluxo do Gerenciamento de Incidentes (OGC, 2007e).
34
De acordo com a imagem (Figura 5) apresentada segue uma breve explicação das
atividades executadas:
35
3.2.4.3 Gerenciamento de Problemas
36
Figura 6 - Fluxo do Gerenciamento de Problemas (OGC, 2007e).
37
Como alguns processos desse fluxo foram apresentados na seção anterior, serão descritos
apenas processos não vistos anteriormente.
• Solução de contorno (Workaround): este processo tem a finalidade de resolver o
incidente com uma solução de contorno enquanto ainda não se tem a solução final
do problema;
• Erro conhecido (Known error): como o próprio nome diz, o erro conhecido é
todo o problema na qual já possui sua causa raiz ou solução de contorno
documentado.
Uma requisição de serviço pode ser traduzida como uma solicitação de um usuário para
alguma informação, dúvida, sugestão, para uma mudança de rotina ou acesso a um serviço de
TI. Normalmente é o nome dado as demandas de um departamento de TI. Geralmente é
tratada pela central de serviço (OGC, 2007e).
Seus objetivos são (OGC, 2007e):
• Oferecer aos usuários um canal no qual eles possam requisitar e receber serviços;
• Fornecer aos usuários e clientes informações sobre a disponibilidade dos serviços
e procedimentos para obter estes serviços;
• Fornecer componentes de serviços-padrão (licença de software);
• Auxiliar em informações gerais, questionamentos e reclamações.
Analisando seus objetivos fica evidente a importância deste conceito, pois o usuário
somente pode requisitar uma demanda se existir um canal de comunicação entre o usuário e a
central de serviço. Logo, é necessário que se tenha um procedimento padrão para requisitar
serviços. As atividades desse processo são simples, porém fundamentais.
38
de acessar ou modificar os ativos (OGC, 2007e). Seu principal objetivo é fornecer aos
usuários o direito de utilizar um serviço, mas de recusar o acesso a usuários não autorizados.
Nesse processo é fundamental se ter em mãos a política de segurança da instituição,
somente com essa política bem definida é possível executar esse processo, logo esse método
deve ser planejado e criado durante a fase de desenho de serviço e testado durante a fase de
transição de serviço.
Para a execução dessas atividades a central de serviços pode ser de quatro tipos:
• Local: esse tipo de central de serviço fica alocada na própria unidade onde o
atendimento deve ser fornecido.
39
• Centralizada: esse modelo a equipe deve ficar centralizada em um única
unidade, podendo atender vários outros locais, entretanto as informação ficam
centralizadas em um único local;
• Virtual: pode-se ter uma ferramenta onde todas as requisições são cadastradas ter
equipes de atendimento em qualquer parte do mundo atendendo essas requisições;
• Siga o sol: é realizado um acordo entre as centrais de serviço através dos fusos
horários de cada uma. Sendo que cada central trabalha de acordo com o horário
comercial de seu país, dessa forma sempre que houver a luz do dia uma equipe vai
trabalhar e dessa forma garantindo um atendimento 24 horas.
Função responsável por manter e capacitar recursos necessários para prestar o melhor
suporte possível aos serviços de TI disponibilizados, sendo que, as decisões técnicas passam
por sua avaliação e decisão, como por exemplo, as ferramentas que devem ser utilizadas e as
equipes que devem ser montadas. Alguns de seus objetivos são (OGC, 2007e):
40
Figura 7 - Responsabilidades Gerenciamento de Aplicações (OGC, 2007e).
Essa função tem a responsabilidade de controlar o dia a dia das atividades necessárias
para o gerenciamento dos serviços e da infraestrutura relacionada. Acumula também as
funções controlar as operações e gerenciar as instalações (OGC, 2007e).
O grande desafio desse papel é de encontrar um processo que chegue a um equilíbrio que
garanta o melhor serviço a um baixo custo, pois é nesse momento que o cliente vai visualizar
o valor do serviço, logo a qualidade do serviço fornecido é fundamental, porém ter qualidade
a baixo custo não é um simples. No próximo capítulo será explicado a ultima fase do ciclo de
vida da ITIL v3.
41
3.2.5 Melhoria Contínua de Processo (Continual Process Improvement)
A melhoria contínua de processo está relacionada em todas as fases de seu ciclo de vida.
A grande finalidade disto é de se identificar melhorias em qualquer uma das fases do
processo, sendo que sua responsabilidade é de gerenciar essas melhorias.
Para isso é necessário ter indicadores que forneçam a real situação do provedor de
serviços, com essas métricas deve ser possível entender o que está funcionando corretamente
e o que não está funcionando da forma esperada e com base nessa análise planejar novos
processos para melhorar o serviço. Seus principais objetivos são (OGC, 2007f):
• Encontrar e desenvolver melhorias;
• Monitorar continuamente os indicadores para assim descobrir maneiras de
melhorar a eficiência e eficácia do serviço entregue;
• Estar sempre alinhado com as estratégias da organização para não fugir do foco
da área de negócio.
42
Figura 8- Modelo de Melhoria Contínua de Processo (OGC, 2007f).
43
Figura 9 - Quatro Razões para Monitorar e Medir (OGC, 2007f).
• Para validar (To Validate): a única forma que se tem para verificar se o
processo está funcionando de acordo com o que é esperado se passa pela
validação de métricas e baseado nessa validação pode se entender se está sendo
realizado o que foi definido ou não, assim validando decisões prévias;
• Para direcionar (To Direct): somente assim se pode dar direção ao trabalho que
se deseja realizar, verificando o que é necessário mudar para se atingir as metas;
• Para justificar (To Justify): somente com dados ou evidências se pode justificar
a necessidade de uma mudança ou o motivo de um acerto;
• Para intervir (To Intervene): tomar uma atitude no momento certo.
44
apresentam cada vez mais instáveis e o cliente muitas vezes não sabe o que realmente deseja,
ou não tem tempo e nem capacidade para definir de forma clara o seu pedido.
Tendo em vista essa nova realidade, no dia 13 de novembro de 2001, um grupo de
profissionais da área de TI (Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn,
Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron
Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff
Sutherland e Dave Thomas) se reuniu para discutir como se poderia melhorar o desempenho
dos projetos de desenvolvimento de software (BECK, 2001). A partir desse encontro nasceu o
Manifesto Ágil, onde, os seguintes valores deveriam ser valorizados:
Percebe-se claramente a nova visão que esse grupo teve e que vem agregando muito em
diversas organizações de TI e seus clientes, demonstra-se uma evidente preocupação tanto
com o cliente, em lhe entregar um produto útil que vá agregar valor ao seu negócio e quanto
com a organização de TI em se entregar projetos no prazo, principalmente, respondendo a
mudanças da melhor forma possível, desta forma, é necessário que as empresas tenham
capacidade de se adaptar rapidamente as mudanças e isso é ser “ágil”. Por trás destes quatro
itens do manifesto ágil existem os seguintes princípios (BECK, 2001):
45
• Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e
suporte necessário, e confiar que farão seu trabalho;
• O método mais eficiente e eficaz de transmitir informações para, e por dentro de
um time de desenvolvimento, é através de uma conversa cara a cara;
• Software funcional é a medida primária de progresso;
• Processos ágeis promovem um ambiente sustentável. Os patrocinadores,
desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos
constantes;
• Contínua atenção a excelência técnica e bom design aumenta a agilidade;
• Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser
feito;
• As melhores arquiteturas, requisitos e designs emergem de times auto-
organizáveis;
• Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se
ajustam e aperfeiçoam seu comportamento de acordo.
1. XP (Extreme Programming);
2. Scrum;
3. Lean;
4. Kanban;
5. DSDM (Dynamic Software Development Method);
6. FDD (Feature Driven Development);
7. OpenUP;
8. Crystal.
Como pode se verificar foram criados diversos frameworks para auxiliar na construção de
uma equipe ágil, entretanto, este trabalho vai abordar, nos próximos capítulos, apenas alguns
desses itens que serão utilizados no desenvolvimento deste.
46
3.3.1 Scrum
Um dos frameworks mais utilizados para métodos ágeis, Scrum, concebido por Ken
Schwaber e Jeff Sutherland, foi criado com o objetivo de desenvolver e manter produtos
complexos, sua definição consiste em papéis, eventos, artefatos e regras, sendo que, não deve
ser considerado um processo ou uma técnica e sim uma ferramenta onde você pode empregar
vários processos e técnicas (SCHWABER, 2011).
Talvez um dos pontos mais intrigantes desse método é que ele é muito leve e simples de
entender, entretanto é extremamente difícil de dominar, pois depende de pessoas, padrões
culturais da empresa, quebra de alguns paradigmas entre outros.
Toda a teoria do Scrum é fundamentada, baseada em teorias empíricas, em três pilares de
sustentação:
47
• Equipe de Desenvolvimento: time responsável por desenvolver o produto de
maneira incremental agregando valor para o cliente, sendo que essas equipes
devem ter a capacidade de se auto-organizarem além de serem multifuncionais.
48
• Revisão da Sprint: executada sempre ao final de uma sprint com objetivo de se
apresentar para as partes interessadas o trabalho realizado;
• Retrospectiva da Sprint: é uma das cerimônias mais importantes em relação ao
pilar de adaptação, relatado anteriormente, pois é nesse momento que a equipe faz
uma análise de seus pontos negativos e como fazer para melhora-los, criando um
plano de ação para sua adaptação.
• Backlog do Produto: deve ser uma lista de itens de tudo que for necessário para
construção do produto, sendo que o responsável por controlar e, principalmente,
priorizar essa relação é o product owner;
• Backlog da Sprint: é a relação de itens selecionados do backlog do produto para
entrarem na sprint, sendo que a responsabilidade desses é da equipe de
desenvolvimento.
49
Ambos os artefatos podem ser acompanhados por gráficos de burndown ou burnup, são
práticas muito utilizadas que facilitam o acompanhamento e aumentam ainda mais a
transparência por facilitar a visualização.
O XP foi criado baseado nos valores do manifesto ágil, relatado no capítulo anterior,
sendo que, foi utilizada pela primeira vez em um projeto que se iniciou no dia 6 de março de
1996 chamado de C3 (Chrysler Comprehensive Compensation) da Chrysler. O resultado não
poderia ter sido melhor incentivou a criatividade e consequentemente a inovação. Kent Beck,
Wrad Cunningham e Ron Jeffries são os idealizadores desta metodologia, vira a necessidade
de se mudar para se atingir os objetivos, exploraram ao máximo as práticas de
desenvolvimento de software, chegando assim no XP (BECK, 2009). Essa prática apresenta
cinco principais valores:
50
• Integração Contínua: garantir que o código fonte da aplicação está consistente
após alterações, normalmente executado diariamente, afim de, encontrar erros o
mais rápido possível, nesse momento, além de atualizar os ambientes, deve ser
executado a bateria de testes automatizados e testes unitários;
• Ambiente Informativo: o local de trabalho da equipe deve expressar claramente
a situação do projeto, de forma, que uma pessoa de outra equipe consiga entender
rapidamente aprimorando assim a comunicação, como no exemplo apresentado na
figura abaixo:
É importante ressaltar que neste trabalho não será abordado todas as práticas do XP, por
esse motivo, acima foi descrito apenas o que fará parte de seu desenvolvimento. No próximo
capítulo será relatada a metodologia Kanban que apresenta uma relação com a prática de
Ambiente Informativo, visto recentemente.
51
3.3.3 Kanban
O Kanban teve origem na década de 50 logo após a segunda guerra mundial, fazendo
parte do STP (Sistema Toyota de Produção) ou Lean (Lean Production System) que foi criado
visando principalmente à eliminação de desperdícios e redução de estoque. Foi utilizado pela
primeira vez por David Anderson com a colaboração de Don Reinertsen que se esforçaram
muito para ampliar o conhecimento do Lean (BOEG, 2011). O termo Kanban significa
“quadro visual” ou “cartão visual” apresentando apenas duas restrições, como o próprio
nome diz, deve-se visualizar o fluxo de trabalho e as atividades em andamento devem ter
limites definidos.
O mais interessante deste método é que em um primeiro momento pergunta-se “O que
realmente um quadro de tarefas pode mudar no desempenho, cultura, capacidade e maturidade
de uma equipe?”. Mesmo parecendo uma mudança pequena o Kanban causa uma grande
mudança na organização.
Normalmente as equipes ágeis tem utilizado um quadro branco com as suas fases e
atividades lançadas neste, isso alavanca a transparência do trabalho realizado iniciando um
processo de mudança cultural.
Na figura acima pode se ver um exemplo de Kanban, dividido em fases e com seus
limites definidos dando transparência ao processo e seu fluxo, assim expondo gargalos, filas,
variabilidade e desperdícios. Com essa exposição todos tem a oportunidade de visualizar o
52
trabalho realizado e tomar alguma ação caso o resultado não esteja de acordo com os
objetivos, ou seja, o método incentiva a colaboração de todos os envolvidos, podendo surgir
melhorias no processo iniciando assim uma proposta de melhoria contínua.
53
o Gerenciamento de Eventos: monitora tudo que possa influenciar na
entrega de um serviço para, no caso de algum evento, executar a ação
correta;
o Gerenciamento de Incidentes: deve corrigir falhas o mais rápido possível
minimizando o impacto ao cliente;
o Gerenciamento de Problemas: problema é a causa raiz de vários
incidentes, sua correção é fundamental para minimizar o número de
incidentes;
o Cumprimento de Requisições: seu principal objetivo é oferecer aos
usuários um canal de comunicação com a central de serviço;
o Central de Serviços: ponto único de contato entre o provedor de serviços
e o usuário;
o Gerenciamento Técnico: manter e capacitar recursos necessários para
prestar o melhor suporte possível aos serviços de TI disponibilizados;
o Gerenciamento da Aplicação: suportar e manter os aplicativos em seu
correto funcionamento durante todo o seu ciclo de vida;
o Gerenciamento das Operações de TI: controlar o dia a dia das atividades
necessárias para o gerenciamento dos serviços e da infraestrutura
relacionada além de controlar as operações e gerenciar as instalações.
• Práticas Ágeis: foram analisadas varias práticas ágeis, movimento esse que teve
início em novembro de 2001, onde dezessete profissionais da área de TI se
encontraram e criaram o Manifesto Ágil (BECKER, 2001) onde constava um
conjunto de valores essenciais para o sucesso de seus projetos (Indivíduos e
interação entre eles mais que processos e ferramentas, Software em
funcionamento mais que documentação abrangente, Colaboração com o cliente
mais que negociação de contratos, Responder a mudanças mais que seguir um
plano). Baseado nesses valores nasceu uma série de metodologias, entretanto este
trabalho vai focar apenas em três delas:
o Scrum: framework criado por Ken Schwaber e Jeff Sutherland, composto
de papéis (Product Owner, Scrum Marter, Equipe de Desenvolvimento),
eventos (Sprint, Planejamento da Sprint, Reunião Diária, Revisão da
Sprint e Retrospectiva da Sprint), artefatos (Backlog do Produto e Backlog
54
da Sprint) e regras sendo baseado em três grandes pilares: transparência;
inspeção; adaptação.
o XP (Extreme Programming): Kent Beck, Wrad Cunningham e Ron
Jeffries são os idealizadores desta metodologia sendo baseada em cinco
grandes valores: Feedback; Comunicação; Simplicidade, Coragem e
Respeito. Possui diversas práticas, porém foram citadas apenas as que
serão utilizadas no desenvolvimento deste trabalho, como por exemplo:
Integração Contínua: garante que o código fonte da aplicação
está consistente após alterações;
Ambiente Informativo: garante que o local de trabalho da equipe
expressa claramente a situação do projeto;
Folga: nunca planejar pensando em 100% do tempo da equipe,
sempre deve ser reservado um espaço para riscos.
o Kanban: criado na década de 50 visa principalmente eliminar desperdícios
e reduzir estoque. Fornece transparência ao processo e seu fluxo expondo
gargalos, filas, variabilidade e desperdícios.
55
4 AVALIAÇÃO INICIAL
Para melhor avaliar o resultado da proposta da metodologia que será desenvolvida é
necessário entender o contexto e a realidade do cenário atual, pois somente assim é possível
fazer um comparativo da situação anterior e posterior à implantação do processo. Além disso,
não seria possível elaborar um processo que realmente agregue valor sem antes entender o
cenário atual, o ambiente, o projeto e outros fatores que são fundamentais para a melhor
utilização das boas práticas.
• Definição de um modelo de gestão que possa ser adotado por todos os HUF;
• Criação de um software capaz de apoiar esse modelo de gestão.
O AGHU deve ser implantado nos 46 hospitais universitários do Brasil, hoje o aplicativo
está instalado em oito HUF’s.
57
4.2.1 Estrutura do Projeto AGHU
O Projeto AGHU teve seu objetivo geral definido em reunião realizada em Brasília, no
dia 21 de maio de 2009 onde estavam presentes representantes do HCPA, da Diretoria de
Tecnologia da Informação do Ministério da Educação, da Coordenação dos HUF’s do
Secretário Executivo do MEC:
58
Órgãos Proponentes MEC – Ministério da Educação
HCPA – Hospital de Clínicas de Porto Alegre
Patrocinadores Secretário Executivo - MEC
Diretor de Tecnologia da Informação - MEC
Presidente - HCPA
Facilitadores Chefe do Serviço e Suporte a Projetos - HCPA
Chefe do Serviço de Suporte à Rede – HCPA
Coordenadores do Projeto Assessor da Presidência – HCPA
Gerente de Executivo AGHU – MEC
Tabela 1 - Responsáveis no Projeto AGHU.
O projeto é organizado de acordo com o organograma que pode ser visualizado a seguir.
59
Baseado nas prioridades que o Comitê Gestor define, as equipes realizam seu trabalho
sendo que suas responsabilidades estão divididas da seguinte forma:
1. Um Líder de Equipe;
2. Dois Analistas de Infraestrutura.
A equipe de integração é composta por cinco membros divididos nos seguintes papéis:
1. Líder de Equipe;
2. Analista de Integração;
60
3. DBA (Database Administrator);
4. Dois Desenvolvedores.
Apesar de se ter pontos fracos muito graves, existem também alguns pontos positivos que
seguem:
1. Equipes comprometidas com o projeto;
2. Equipes dispostas a melhorar;
3. Boa comunicação entre os membros;
4. Alta maturidade das equipes;
5. Excelente nível de conhecimento técnico;
6. Possibilidade de novas contratações.
Devido à falta de gerenciamento deste trabalho, as equipes acabam tendo que fazer
constantemente horas extras, pois normalmente todo problema que ainda não possua sua
causa raiz identificada é atribuído a estas equipes. Com a causa raiz identificada a equipe
acaba atuando frequentemente na solução do problema mesmo que não seja de sua
responsabilidade.
61
4.3 Instrumento de Avaliação
O instrumento de avaliação é necessário para que se tenha convicção do sucesso ou
insucesso da aplicação do novo processo, sendo que o mesmo instrumento deve ser aplicado
antes e depois da implantação do processo desenvolvido neste trabalho. Após sua aplicação
serão avaliados seus resultados.
A elaboração deste instrumento foi baseada em dois modelos de maturidade, tais como:
Instrumento de Avaliação
1 - Nós sabemos quais são os nossos serviços?
2 - Nós temos funções e processos bem definidos através do ciclo de vida?
3 - Nós temos a possibilidade de mensurar os processos de maneira relevante?
4 - O motivo de existir um processo é entregar um resultado específico?
5 - As metas da Gerência de Serviços estão definidas?
6 - Os objetivos da Gerência de Serviços estão definidos?
7 - O propósito da Gerência de Serviços está definido?
8 - Nós temos um plano de Gerência de Serviços?
9 - Melhorias de serviço e seus benefícios estão claramente definidos?
10 - Nós temos justificativas de Gerência de Serviços para os dirigentes de negócio e
dirigentes de tecnologia?
62
11 - Os benefícios da Gerência de Serviços para a área de negócio e clientes estão
claramente definidos?
12 - Os benefícios da Gerência de Serviços internos à organização de TI estão claramente
definidos?
13 - Nós envolvemos a área de negócio e determinamos seus requerimentos em nível de
serviço?
14 - Nós definimos um portfólio interno de serviços: serviços que estão planejados; em
desenvolvimento e em produção?
15 - Nós definimos um Catálogo de Serviços orientados a clientes que detalha cada serviço
e pacote de serviço oferecido?
16 - Nós identificamos as relações internas do departamento de TI codificando-as em
Acordos em Nível de Operação?
17 - Nós usamos o Catálogo de Serviços como linha de base para negociar os Acordes em
Nível de Serviço com a área de negócio?
18 - Nós criamos um Plano de Melhoria de Serviço para monitorar continuamente e
aprimorar os níveis de serviço?
19 - Papeis e responsabilidades estão claramente definidos?
20 - Gatilhos, entradas e saídas de interface entre os processos estão definidos?
21 - O propósito, meta e objetivo do processo de Implantação estão definidos?
22 - O escopo do processo de implantação está definido?
23 - As políticas, princípios e conceitos básicos para a Implantação estão definidos?
24 - Modelos de implantação estão definidos?
25 - O planejamento de Implantação está gerenciado?
26 - A preparação para a construção, teste e implantação está gerenciada?
27 - A construção e teste estão gerenciados?
28 - Planejamento e preparação para implantação estão gerenciados?
29 - Verificação de implantação está gerenciada?
30 - Revisão e fechamento de implantação estão gerenciados?
31 - O processo de Operação está bem documentado?
32 - Nós temos definidos os princípios, políticas e conceitos básicos do processo de
Operação?
33 - Nós temos definidos os gatilhos, entradas, saídas e interfaces do processo de
63
Operação?
34 - Nós temos definidos os relatórios de gerência de informação do processo de
Operação?
35 - Nós temos definidos os desafios, fatores críticos de sucesso e riscos do processo de
Operação?
36 - Nós monitoramos eventos que possam prejudicar a entrega de nossos serviços?
37 - Existe alguma ação automática, no caso de acontecimento de algum evento, que venha
a prevenir um incidente?
38 - Existe um ponto único onde os usuários possam requisitar serviços?
39 - Existem níveis de serviço bem definidos?
40 - Os incidentes são priorizados baseados em impacto e urgência?
41 - Os incidentes são categorizados?
42 - Existe um processo para gerenciamento de problemas?
43 - Existe um controle de qualidade dos serviços realizados?
44 - É realizada a reunião de planejamento da sprint?
45 - A reunião de planejamento da sprint é realizada em no máximo 25 minutos?
46 - A equipe estima o esforço necessário para o desenvolvimento de uma tarefa?
47 - A equipe seleciona as tarefas que podem ser concluídas dentro da sprint?
48 - São realizadas reuniões diárias?
49 - As reuniões diárias realizadas duram no máximo 10 minutos?
50 - As reuniões diárias são realizadas em pé?
51 - São realizadas reuniões de revisão da sprint?
52 - As reuniões de revisão da sprint duram no máximo 20 minutos?
53 - As reuniões de lições aprendidas são realizadas?
54 - A equipe comenta na reunião de lições aprendidas o que correu bem durante a última
iteração?
55 - A equipe comenta na reunião de lições aprendidas o que não correu tão bem?
56 - A equipe identifica os itens mais importantes ou problemas na reunião de lições
aprendidas para focar na próxima iteração?
57 - O ambiente de trabalho expressa claramente a situação da célula no momento? (o
ambiente é informativo?)
58 - Existe uma visão de risco no planejamento, armazenando uma folga no tempo
64
planejado, não sendo planejado 100% do tempo da equipe?
59 - Existe o processo de integração contínua?
60 - Na integração contínua são executados testes automatizados?
61 - Na integração contínua são executados testes unitários?
62 - Existe integração contínua em ambiente de produção?
63 - Os processos estão devidamente documentados?
64 - As equipes praticam gestão do conhecimento? Não centralizam o conhecimento em
seus membros?
65 - As equipes são autogerenciáveis?
66 - Existe algum processo definido para mudanças?
67 - Existem indicadores ou métricas que permitam avaliação do trabalho realizado?
68 - Existe uma ferramenta para o gerenciamento de serviços?
69 - Nós utilizamos kanban?
70 - Existe transparência entre a equipe do trabalho realizado?
71 - O kanban é dividido em fases e possui limites?
72 - É possível identificar gargalos no kanban utilizado?
Tabela 2 - Instrumento de Avaliação.
Grau Descrição
1 - Inicial Processos e atividades são caóticos ou não definidos.
2 - Repetível Processos e atividades básicas são estabelecidos e existe um nível de
disciplina e aderência.
3 - Definido Todos os processos e atividades são definidos, documentados, padronizados
e integrados.
4 - Gerenciado Processos são mensurados através de coleta detalhada de dados e sua
qualidade é melhorada apropriadamente.
5 - Otimizado Melhoria contínua de processos é adotada e atividades e processos são
maduros.
Tabela 3 - Possíveis Respostas para o Instrumento de Avaliação.
65
Na tabela 4 é possível visualizar a relação dos questionamentos do instrumento de
avaliação com as áreas de conhecimento que foram estudadas e devem fazer parte do processo
que será implantado. As informações são relacionadas de acordo com os números das
questões.
Questões Relação
19, 20, 66 PMBOK
1, 5, 6, 7, 14, 21, 22, 23, 24, 32, 35 Estratégia de Serviço
2, 8, 11, 12, 13, 15, 16, 17, 19, 20, 33, 39, 42, 63 Desenho de Serviço
3, 4, 9, 10, 18, 34, 67 Melhoria Contínua de Processo
25, 26, 27, 28, 29, 30, 66 Transição de Serviço
31, 36, 37, 38, 40, 41, 43, 68 Operação de Serviço
44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 64,
Scrum
65
57, 58, 59, 60, 61, 62 XP
69, 70, 71, 72 Kanban
Tabela 4 - Relação do Instrumento de Avaliação com as Áreas Estudadas.
66
1, 2, 5, 6, 7, 21, 35 Não existem metas ou objetivos claros para
equipe.
3, 10, 34, 67 Não existe nenhum indicador ou métrica.
13, 14, 15, 16, 17 Os serviços prestados não estão catalogados.
9, 18, 53, 54, 55, 56 Não existe nenhum processo de melhoria
contínua aplicado a essas equipes.
36, 37, 68 Ferramenta para cadastro de requisição
desatualizada.
Tabela 5 – Relação do Instrumento de Avaliação com Pontos Negativos.
Participante 1
Tempo de experiência na área de TI: 19 anos
Tempo de experiência na área de serviços de TI: 11 anos
Tempo de experiência no Projeto AGHU: 3 anos
Atividades atuais na equipe de operação do AGHU:
• Lidera da equipe de operação;
• Monitora bancos de dados utilizados Projeto AGHU;
• Monitora ambientes utilizados para o Projeto AGHU.
Participante 2
Tempo de experiência na área de TI: 8 anos
Tempo de experiência na área de serviços de TI: 5 anos
Tempo de experiência no Projeto AGHU: 3 anos
Atividades atuais na equipe de operação do AGHU:
• Analista da equipe de operação;
67
• Administra bancos de dados utilizados Projeto AGHU;
• Administra ambientes utilizados para o Projeto AGHU;
• Controla implantações do software AGHU.
Participante 3
Tempo de experiência na área de TI: 7 anos
Tempo de experiência na área de serviços de TI: 5 anos
Tempo de experiência no Projeto AGHU: 1 ano e 8 meses
Atividades atuais na equipe de operação do AGHU:
• Analista de banco de dados da equipe de operação;
• Administra bancos de dados utilizados Projeto AGHU;
• Administra ferramentas de integração contínua do AGHU.
Tabela 6 - Perfil dos Participantes da Avaliação Inicial.
Gerência de
Serviços –
Inicial Repetível Definido Gerenciado Otimizado
Projeto
AGHU
Estratégia
15 18 0 0 0
de Serviço
Desenho de
24 17 1 0 0
Serviço
68
Transição
4 17 0 0 0
de Serviço
Operação de
5 14 5 0 0
Serviço
Melhoria
Contínua de 12 9 0 0 0
Processo
Scrum 27 17 1 0 0
XP 9 7 2 0 0
Kanban 8 3 0 0 1
Tabela 7 - Respostas da Avaliação Agrupadas por Nível de Maturidade.
A figura 15 demonstra que o processo em sua grande maioria está classificado com nível
inicial e repetível. O gráfico (figura 15) apresenta os números descritos na tabela 7 sendo que
os valores foram transformados para percentual.
A tabela 8 que segue apresenta a média das respostas obtidas por cada área de
conhecimento do instrumento de avaliação.
69
Gerência de Serviços – Projeto AGHU Média
Estratégia de Serviço 1,54
Desenho de Serviço 1,45
Transição de Serviço 1,80
Operação de Serviço 2
Melhoria Contínua de Processo 1,43
Scrum 1,42
XP 1,61
Kanban 1,58
Tabela 8 - Média de Pontuação por Área de Conhecimento.
Através dos dados apresentados na tabela 8 foi obtido o gráfico presente na figura 16. Ao
analisar este gráfico fica evidente a baixa qualidade do processo onde a área que mais se
destacou com média de 2 foi a de Operação de Serviço, foco principal deste trabalho.
Após essa primeira avaliação realizada e seus resultados analisados o próximo capítulo
descreve a definição do novo processo a ser implantado na célula de serviços de TI do Projeto
AGHU, a fim de melhorar os resultados referentes à situação atual.
70
5 DEFINIÇÃO
Este capítulo descreve, principalmente, a definição de um processo embasado nos temas
estudados para este trabalho como PMBOK, ITIL v3, práticas ágeis e contexto atual do
Projeto AGHU, pois é importante conhecer a realidade antes de desenhar um processo.
Para iniciar a definição deste novo processo é necessário se entender onde os temas
estudados apresentam características em comum a fim de elaborar um processo lógico, correto
e com justificativas. A primeira seção deste capítulo tem o objetivo de apresentar tais
características em comum, para assim, justificar decisões tomadas nas próximas seções deste.
71
Um fator fundamental para o sucesso da fase de Operação de Serviço é a eficiência e
eficácia da comunicação entre equipes. É primordial a comunicação na área de gerenciamento
de serviços, logo o processo definido deve ter muita atenção neste ponto. E mais uma vez se
percebe uma forte relação com as práticas ágeis especificamente com o valor “Indivíduos e
interação entre eles mais que processos e ferramentas” (BECK, 2001). O valor da
comunicação para a ITIL v3 é bem próximo do valor citado nas práticas ágeis, onde não
significa de maneira alguma que não se devem ter processos e ferramentas, mas que, a
interação entre os envolvidos é o mais importante.
Uma das fases presentes na ITIL v3 é a Melhoria Contínua de Processo, descrita no
capítulo 3 deste documento, tal fase é essencial para a evolução do serviço conforme as
estratégias definidas. Novamente é possível perceber mais outra forte relação com as práticas
ágeis que de acordo com o guia do Scrum, um dos métodos ágeis, sugere que, um dos pilares
desse framework seja a “Adaptação” embasado totalmente no processo de melhoria contínua,
onde sugere uma reunião de retrospectiva, descrita no capítulo 3.
Conclui-se que a ITIL v3 e metodologias ágeis apresentam muitos princípios em comum.
O PMBOK também apresenta relação com algumas práticas dessas áreas, como por exemplo,
gerenciamento de riscos presente na fase de estratégia de serviços (ITIL v3) e diariamente no
Scrum através das reuniões diárias, gerenciamento de tempo (acordos de níveis de serviço e
sprint), gerenciamento de escopo (portfólio de serviços e planejamento de release), entre
outros. Isto deve facilitar bastante na definição do processo que poderá ser visualizado nas
seções que seguem.
72
Figura 17 - Estrutura para Equipes de Central de Serviços de TI.
Conforme pode se observar na figura acima (17), estas equipes de suporte nível 1 devem
estar formadas em todos HUF’s onde o AGHU se encontra implantado. Além disso, devem
escalar requisições de nível 2 ou 3 para equipe de serviços localizada em Porto Alegre (Célula
de Serviços de TI AGHU/POA). Na tabela 9 que segue, é descrito a função de cada um dos
papéis referenciados na figura 17.
Papel Função
Deve exercer liderança servidora, seguindo os
padrões ágeis, bem como, garantir que o
Líder de Equipe processo foi entendido e está sendo aplicado
pela equipe. Pode atuar em qualquer outra
função da equipe.
Apresenta como principal função a resolução de
Analista de Suporte requisições de serviço e incidentes de nível 1,
atuando de forma autogerenciável.
Apresenta como principal função a resolução de
Célula de Serviços de TI
requisições de serviço, incidentes e problemas
AGHU/POA
de nível 2 e 3. Sendo que esta função é
73
composta de varias equipes que pode ser
visualizada na figura 18.
Tabela 9 - Papéis Equipes de Central de Serviços.
74
Nesta proposta de reestruturação de organograma é possível perceber a presença dos
conceitos estudados, como por exemplo, a existência de cinco pequenas equipes variando de
quatro a cinco pessoas por equipe (Agile), cada equipe com responsabilidades definidas de
acordo com as funções presentes na Operação de Serviço (OGC, 2007e) bem como o nível de
suporte onde cada equipe atua. Na tabela 10, que segue, é apresentada a responsabilidade de
cada uma das equipes.
Equipe Responsabilidade
Equipe de sustentação dos serviços de TI (nível
2) fornecidos pela célula de serviços de TI
AGHU/POA, deve trabalhar com uma matriz de
Delivery prioridades onde requisições relacionadas ã
implantação da aplicação AGHU devem ser
avaliadas com maior prioridade do que as
demais requisições.
Equipe de sustentação dos serviços de TI (nível
2) fornecidos pela célula de serviços de TI
AGHU/POA, deve trabalhar com uma matriz de
Sustentação – Operação
prioridades onde incidentes devem ser tratados
com maior prioridade do que as demais
requisições.
Equipe de responsável por manter todo o ciclo
de vida dos serviços de TI antes que esses
cheguem em ambiente de produção (nível 2),
Sustentação – Aplicação deve trabalhar com uma matriz de prioridades
onde requisições de serviço devem ser tratadas
com maior prioridade do que as demais
requisições.
Equipe de responsável por manter todo o ciclo
de vida dos serviços de TI (nível 3) e
Infraestrutura principalmente responsável por tomar as
decisões técnicas de infraestrutura do projeto,
deve trabalhar com uma matriz de prioridades
75
onde requisições de serviço devem ser tratadas
com maior prioridade do que as demais
requisições, entretanto deve focar no processo
de gerenciamento de eventos a fim de alertar as
equipes de operação caso algum incidente esteja
próximo de ocorrer, se tornando pró-ativo e não
mais reativo.
Equipe de sustentação dos serviços de TI (nível
3) fornecidos pela célula de serviços de TI
AGHU/POA e principalmente responsável por
tomar as decisões técnicas de software do
Arquitetura projeto, deve trabalhar com uma matriz de
prioridades onde problemas devem ser tratados
com maior prioridade do que as demais
requisições, atendendo também outras áreas do
projeto através de requisições de serviço.
Tabela 10 - Responsabilidades das Equipes de Serviços de TI.
Na tabela 11, que segue, são apresentadas as funções de todos os papéis citados na figura
18.
Papel Função
Deve exercer liderança servidora e situacional,
sua principal função está no gerenciamento de
todos os serviços de TI prestados por esta
Gerente de Serviços célula, incluindo o controle das operações e o
gerenciamento das instalações. Além disso,
deve ser um facilitador do trabalho realizado
por suas equipes.
Pode atuar em qualquer outra função da equipe,
deve exercer liderança servidora, seguindo os
Líder de Equipe
padrões ágeis, bem como, garantir que o
processo foi entendido e está sendo aplicado
76
pela equipe.
Apresenta como principal função a resolução de
requisições de serviço e incidentes de nível 2
Desenvolvedor de Sistemas
vinculados ao software AGHU, atuando de
forma autogerenciável.
Este papel deve atuar garantindo a qualidade do
produto que esta sendo instalado em ambiente
de produção. Uma de suas atividades é sempre
Testador
que houver uma correção de um incidente este
deve ser testado a fim de garantir que sua
correção está de acordo.
Deve garantir a disponibilidade, performance e
DBA confiabilidade de todos os bancos de dados
existentes no Projeto AGHU.
Apresenta como principal função a resolução de
requisições de serviço e incidentes de nível 2
Analista de Integração vinculados a problemas de integração ou
configuração, atuando de forma
autogerenciável.
Deve realizar todo o gerenciamento de
Analista de Configuração configuração e controle de versões do projeto,
incluindo criação de branches, tags e merges.
Deve estruturar, implantar e sustentar toda
Analista de Infraestrutura
infraestrutura necessária para o Projeto AGHU.
Este papel deve fornecer habilidades técnicas
para a melhoria contínua do suporte fornecido
Arquiteto de Software pelas equipes de nível 2, bem como estruturar,
desenvolver e sustentar a arquitetura de
software do Projeto AGHU.
Tabela 11 - Papéis equipes da Célula de Serviços de TI AGHU/POA.
77
possível a constituição de um novo processo que deve ser orientado também pela estratégia
desta célula:
78
1. Não existe qualquer tipo de documentação de processos, padrões ou de
implantações;
2. A equipe possui o conhecimento interdisciplinar centralizado em seus membros;
3. Não existe controle de mudanças;
4. Não é realizado nenhum planejamento;
5. Não existem metas ou objetivos claros para equipe;
6. Não existe nenhum indicador ou métrica;
7. Os serviços prestados não estão catalogados;
8. Não existe nenhum processo de melhoria contínua aplicado a essas equipes;
9. Distância entre equipe de infraestrutura e integração;
10. A equipe não possui conhecimento de boas práticas de gestão;
11. Ferramenta para cadastro de requisição desatualizada.
79
Figura 19 - Workflow Níveis de Serviço.
80
De acordo com a figura 19 apresentada é possível verificar quatro papéis atuantes neste
processo reconhecidos como: usuários, central de serviços ou suporte de nível 1 (fundo
verde), suporte de nível 2 (fundo azul) e suporte de nível 3 (fundo vermelho). As cores
referenciadas também estão presentes nos organogramas apresentados (figuras 17 e 18) a fim
de facilitar a compreensão.
O processo proposto é dividido em cinco fases, segue na tabela 12 a descrição de cada
uma dessas fases.
Fase Descrição
Fase onde é identificada pelo usuário a necessidade de solicitar
uma requisição de serviço, sendo que essa é finalizada quando
Iniciação a equipe responsável toma o conhecimento da requisição
desejada pelo usuário, normalmente através do registro desta
em uma ferramenta de apoio.
Fase onde a equipe responsável classifica e prioriza as
Avaliação
requisições abertas baseado em um catálogo de serviços.
Fase onde a equipe responsável inicia a construção da
requisição solicitada, sendo que nesta fase também devem ser
Execução realizados testes a fim de verificar se a requisição foi atendida
e somente se encerra caso a requisição tenha sido construída e
verificada.
Fase onde a equipe de central de serviços deve solicitar que o
Validação usuário realize uma validação a fim de verificar se sua
requisição foi atendida, caso positivo a fase se conclui.
Momento de finalização do atendimento. Inicia-se quando o
usuário finaliza a fase de validação e se encerra após a
Encerramento
atualização do registro na ferramenta de apoio e o envio da
pesquisa de satisfação para o requisitante.
Tabela 12 - Fases dos Níveis de Serviço.
81
Atividade Descrição Responsável
Atividade na qual o usuário Usuário
identifica uma requisição e
Defeito encontrado
comunica a central de serviços da
situação encontrada.
Central de serviços recebe a Equipe de Central de
Registrar requisição requisição e registra em sua Serviços
ferramenta de apoio.
Central de serviços classifica e Equipe de Central de
Classificar e
prioriza a requisição baseado em Serviços
priorizar requisição
um catálogo de serviços.
No caso da equipe de central de Equipe de Central de
serviços ter o conhecimento da Serviços
solução da requisição e esta ser de
Realizar suporte de nível 1 o próprio membro desta
nível 1 equipe atende a requisição,
normalmente através de
configurações na ferramenta
AGHU.
Caso a equipe de central de Equipe de Central de
serviços não tenha o conhecimento Serviços
da solução da requisição ou a
mesma seja de um nível superior,
Escalar para esta deve ser escalada para o
suporte de nível 2 suporte de segundo nível que é
realizado via o registro da
requisição na ferramenta de apoio
utilizada pela célula de serviços de
TI AGHU/POA.
Atividade na qual é investigado e Equipes de Suporte de
Investigar e realizado um diagnóstico da Nível 2
diagnosticar S2 requisição registrada, a fim de
avaliar sua classificação e
82
priorização a nível nacional.
No caso da equipe de suporte de Equipes de Suporte de
Realizar suporte de nível 2 ter o conhecimento da Nível 2
nível 2 solução da requisição, esta realiza o
atendimento necessário.
Após a conclusão do Equipes de Suporte de
macroprocesso de realizar o suporte Nível 2
de nível 2, a equipe deste nível
deve comunicar, via ferramenta de
Notificar central de
apoio, a central de serviços que
serviços S2
registrou a requisição para que esta
de continuidade, junto ao usuário
de seu HUF, na resolução de sua
requisição.
Caso a equipe de suporte de nível 2 Equipes de Suporte de
não tenha o conhecimento da Nível 2
solução da requisição ou a mesma
seja de um nível superior, esta deve
Escalar para ser escalada para o suporte de
suporte de nível 3 terceiro nível que é realizado via
reclassificação do registro da
requisição na ferramenta de apoio
utilizada pela célula de serviços de
TI AGHU/POA.
Atividade na qual é investigado e Equipes de Suporte de
realizado um diagnóstico da Nível 3
Investigar e
requisição registrada, a fim de
diagnosticar S3
avaliar sua classificação e
priorização a nível nacional.
No caso da equipe de suporte de Equipes de Suporte de
Realizar suporte de nível 3 ter o conhecimento da Nível 3
nível 3 solução da requisição, esta realiza o
atendimento necessário.
83
Após a conclusão do Equipes de Suporte de
macroprocesso de realizar o suporte Nível 3
de nível 3, a equipe deste nível
deve comunicar, via ferramenta de
Notificar central de
apoio, a central de serviços que
serviços S3
registrou a requisição para que esta
de continuidade, junto ao usuário
de seu HUF, na resolução de sua
requisição.
Atividade na qual a central de Equipe de Central de
serviços requisitante homologa Serviços
Validar junto ao
junto de seu usuário se o
requisitante se a
atendimento está de acordo com o
requisição foi
que era esperado, caso positivo, se
atendida
inicia o encerramento do
atendimento.
Realizar o Atividade na qual a central de Equipe de Central de
encerramento do serviços encerra o atendimento da Serviços
atendimento requisição.
Tabela 13 - Atividades Workflow de Níveis de Serviço.
Com estas informações é possível ter uma visão em alto nível do processo que é o
objetivo deste trabalho. As próximas seções devem explicar de forma mais especifica cada
etapa deste processo.
De acordo com a fase de Operação de Serviço presente na ITIL v3, deve existir uma
equipe de central de serviços que atue como ponto único de contato entre o provedor de
serviços e os usuários a fim de gerenciar requisições de serviço, incidentes e a comunicação
com esses usuários.
Entendendo a realidade de um hospital e a exigência de disponibilidade de serviço que
esta área de negócio exige, tomou-se a decisão de que cada Hospital Universitário Federal
84
(HUF) que receber o AGHU deve formar uma equipe de central de serviços local, conforme
ilustrado na figura 20, estas pessoas serão treinadas pelos consultores técnicos do Projeto
AGHU, membros da célula de serviços de TI AGHU/POA, a fim de aperfeiçoar a qualidade
desta função.
85
Com esta decisão, significa que o atendimento de nível 1 sempre será realizado localmente pela própria central de serviços do HUF e
somente será escalado para célula de serviços de TI do AGHU caso a requisição seja de nível 2 ou 3, onde a equipe do HUF não possui o
conhecimento necessário para encaminhar a solução. Na figura 21 pode se visualizar como deve ser realizado o suporte de nível 1.
87
Figura 22 - Workflow Processo de Realizar Encerramento do Atendimento.
88
pesquisa de preenchimento da pesquisa de
satisfação satisfação do atendimento.
Tabela 15 - Atividades do Processo de Realizar Encerramento do Atendimento.
89
5.3.3 Workflows por Tipos de Requisição
Nesta seção serão apresentados os diferentes tipos de requisições que a célula de serviços
de TI AGHU/POA deve atender, bem como, os fluxos utilizados por cada tipo, assim
representando o macroprocesso de realizar suporte de nível 2 e 3, sendo que esses fazem parte
da fase de execução ilustrada no workflow de níveis de serviço (figura 19).
Qualquer solicitação que não se caracteriza por uma falha ou melhoria de aplicação pode
ser considerada uma requisição de serviço. A figura 23 apresenta o workflow do fluxo
principal de uma requisição de serviço desde seu registro na ferramenta de apoio até o
encerramento de seu atendimento, sendo que os estados representados na cor verde
representam o fluxo principal deste workflow, na cor azul são atividades implícitas ao
processo.
O fluxo completo pode ser visualizado no Apêndice B.
90
Figura 23 - Workflow Requisição de Serviço.
91
O workflow proposto é dividido em cinco fases, segue na tabela 16 a descrição de cada
uma dessas fases.
Fase Descrição
Fase onde o requisitante (equipe de suporte nível 1) identifica
a necessidade de escalar a requisição para o próximo nível e
formaliza sua necessidade através do registro desta na
Iniciação ferramenta de apoio utilizada pela célula de serviços de TI do
AGHU. Esta fase se encerra no momento em que um membro
da equipe de nível 2 identifica e inicia a avaliação desta
requisição.
Fase onde a equipe responsável classifica e prioriza as
Avaliação
requisições abertas baseado em um catálogo de serviços.
Fase onde a equipe responsável inicia a construção da
requisição solicitada, sendo que nesta fase também devem ser
Construção realizados testes a fim de verificar se a requisição foi atendida
e somente se encerra caso a requisição tenha sido construída e
verificada.
Fase onde a equipe responsável notifica a central de serviços
que a requisição está concluída e que estes devem iniciar sua
Validação
fase de validação a fim de verificar se a requisição foi atendida,
caso positivo a fase se conclui.
Momento de finalização do atendimento. Inicia-se quando a
equipe de central de serviços finaliza a fase de validação e
confirmando que a requisição está de acordo com o solicitado a
Encerramento
fase se encerra para equipes de nível 2 ou 3 e continua para
equipe de central de serviços a fim de finalizar o atendimento
junto ao usuário.
Tabela 16 - Fases Workflow de Requisições de Serviço, Incidentes e Problemas.
Segue, na tabela 17, a relação das atividades apresentadas na figura 23, bem como, as
atividades que compõe os fluxos alternativos (Apêndice B), além de sua descrição e o
responsável de cada atividade.
92
Atividade Descrição Responsável
Atividade na qual a central de serviços escala a Equipe de Central de
requisição para o nível 2 de suporte, Serviços (Nível 1)
Nova
registrando esta na ferramenta de apoio da
célula de serviços de TI AGHU/POA.
Equipes de sustentação realizam investigação a Equipes de
fim de categorizar e priorizar a requisição a Sustentação
Investigação nível nacional, onde esta deve entrar em uma (Operação e
e Diagnóstico fila de atendimento organizada por ordem de Aplicação)
prioridade de acordo com o diagnóstico
realizado.
Membro da equipe que realizou a atividade de Equipes de
investigação e diagnóstico deve verificar se a Sustentação
Lançar atividade demora mais de um dia para ser (Operação e
Atividade no concluída, caso afirmativo, esta deve ser Aplicação)
Quadro de colocada no Kanban de sua equipe, caso
Tarefas contrário, não é necessário colocar no Kanban,
visto que a mesma pode e deve ser alinhada na
reunião diária desta equipe.
Este estado significa que a requisição se Equipes de
encontra na fila de atendimento nacional, Sustentação
categorizada e priorizada de acordo com os (Operação e
Avaliado
vetores de impacto e urgência. É a partir desta Aplicação)
fila que as equipes devem iniciar a fase de
construção.
Este estado ocorre quando o membro, que esta Equipe de Central de
realizando a fase de avaliação, não Serviços (Nível 1)
compreende a descrição da requisição ou ainda
Aguardando
a requisição não está de acordo com o padrão
Retorno do
de redação aceito pela célula de serviços de TI
Usuário
do AGHU. Sendo que a responsabilidade da
requisição retorna para o requisitante a fim de
que este complemente as informações
93
necessárias.
Este estado representa que o atendimento de Equipes de
uma requisição se encontra impedido por Sustentação
Impedido
depender de um serviço que não esta (Operação e
disponível no momento. Aplicação)
No caso da equipe de sustentação em comum Equipes de
acordo com a equipe de central de serviços Sustentação
Rejeitado
entenderem que a requisição não faz mais (Operação e
sentido então esta deve ser rejeitada. Aplicação)
Equipes de
Após a fase de avaliação é possível iniciar a
Em Sustentação
construção de um serviço, onde é dado inicio a
Construção (Operação e
implementação do serviço solicitado.
Aplicação)
Após a construção do serviço a equipe que Equipe de Central de
Em atendeu este deve solicitar que o requisitante Serviços (Nível 1)
Homologação valide o serviço a fim de verificar se o serviço
atende ou não.
Caso na fase de validação o requisitante Equipe de Central de
entenda que o serviço entregue não atende ao Serviços (Nível 1)
que foi especificado este deve reabrir a
Reaberto
atividade para que as equipes de sustentação
possam avaliar e iniciar o atendimento
novamente.
Caso o serviço atendido esteja de acordo com Equipes de
o solicitado pelo requisitante este é concluído Sustentação
Concluído
finalizando o atendimento por parte da célula (Operação e
de serviços de TI AGHU/POA. Aplicação)
Tabela 17 - Atividades Workflow Requisição de Serviço.
95
Figura 24 - Workflow Incidentes e Problemas.
96
Na figura 24, conforme citado anteriormente, é apresentado o fluxo principal para realizar
atendimento de nível 2 e 3. Este esboça o workflow principal executado quando é registrado
um incidente ou problema na ferramenta de apoio da célula de serviços de TI AGHU/POA.
Segue, na tabela 18, a relação das atividades apresentadas na figura 24, bem como, as
atividades que compõe os fluxos alternativos (Apêndice C), além de sua a descrição e o
responsável de cada atividade, entretanto será descrito apenas as atividades que não foram
descritas na tabela 17.
Após a definição dos processos por tipo de requisição, esta seção descreve a definição do
método de trabalho das equipes da célula de serviços de TI do AGHU. De acordo com
organograma apresentado na figura 18, a célula será composta de cinco equipes de trabalho
97
separadas por responsabilidades e prioridades. Essas equipes apresentam o tamanho máximo
de cinco pessoas sendo que todas essas equipes possuem o papel de Líder, sendo que este
deve ser o facilitador e o responsável por fazer com que a equipe entenda e execute o método,
conforme o Scrum sugere.
Os membros das equipes devem ser maduros suficientes para trabalhar em grupo com alta
capacidade de comunicação e ser capazes de se autogerenciarem sem depender de uma pessoa
para dizer o que deve ser feito, sendo que as principais características exigidas são:
1. Maturidade;
2. Pró-atividade;
3. Transparência;
4. Flexibilidade;
5. Alta capacidade de comunicação;
6. Alta capacidade de trabalhar em equipe.
Estas características são fundamentais para o sucesso do método. Além disso, vale
lembrar que a ITIL v3 sugere um plano de comunicação que não seja complexo a fim de
agilizar o processo principalmente na fase de operação de serviço (OGC, 2007e).
Analisando o contexto de uma área de serviços de TI, fica claro que esta não possui
tempo hábil para reunir toda sua equipe a fim realizar reuniões de planejamento de sprint ou
revisão de sprint, conforme o sugerido no Scrum, essas cerimônias têm um tempo variável de
acordo com o tamanho da sprint, por exemplo, para uma sprint de duas semanas é sugerido
uma reunião de quatro horas para o planejamento da sprint (SCHWABER, 2011). Seguindo
essa lógica, caso fosse realizada uma sprint de uma semana seria necessário uma reunião de
planejamento de duas horas o que ainda se torna arriscado para uma equipe de serviços de TI.
Nesse momento surge a necessidade de unir os conceitos de ITIL v3, Kanban, Scrum e XP a
fim de solucionar pontos como:
1. Comunicação rápida e eficiente;
2. Capacidade de planejamento;
3. Rápida resposta a mudanças;
4. Priorizar serviços corretamente;
5. Trabalho em equipe;
6. Melhoria contínua;
98
7. Promoção da colaboração;
8. Processo deve estar vinculado ao planejamento estratégico.
1. Todas as equipes devem possuir um quadro de Kanban, sendo que suas fases
devem ser as mesmas apresentadas na figura 24, ou seja, devem seguir o mesmo
fluxo configurado na ferramenta de apoio a fim de facilitar o processo. Desta
forma é criado um ambiente informativo, conforme orientação do XP,
aumentando assim a capacidade de comunicação, pois esta passa a ganhar apoio
de forma visual e, além disso, expõe gargalos e falhas do processo para toda a
equipe, oportunizando a autogestão desta e a participação de todos na melhoria
contínua deste processo, pois cada membro desta equipe deve perceber seu valor
no resultado final e com isso sugerir melhorias para toda célula de serviços.
2. Cada equipe deve realizar uma reunião diária em pé, conforme sugerido no
Scrum, em frente ao Kanban com duração máxima de dez minutos. Nesta
cerimônia cada membro deve comunicar à equipe o que fez desde a última
reunião, o que pretende fazer até a próxima e se possuí algum impedimento
(SCHWABER, 2011). Em virtude do cenário de uma equipe de serviços de TI ser
muito dinâmico, esta cerimônia não deve ter um horário fixo para ser realizada,
apenas deve acontecer diariamente e seu tempo de duração foi reduzido pela
mesma característica;
3. Somente devem ser colocadas no Kanban atividades que demorem mais de um
dia de trabalho (8 horas) para serem solucionadas a fim de agilizar o atendimento,
sendo que atividades que não estão no Kanban devem ser alinhadas com a equipe
na reunião diária realizada;
99
4. As equipes devem trabalhar em sprints (conforme sugerido no Scrum) de uma
semana, pois as atividades, em sua grande maioria, não apresentam a mesma
complexidade de uma estória de usuário sendo assim á possível reduzir não
somente o tempo da sprint como os tempos das cerimônias;
5. Cada equipe deve realizar o planejamento da sua sprint no primeiro dia da
iteração, conforme sugerido no Scrum. Sendo que esta cerimônia deve ser
realizada de pé com duração máxima de 25 minutos e em frente ao Kanban, as
atividades devem ser movimentadas a fim de montar o planejamento. Após o
término desta, as atividades planejadas devem ser atualizadas na ferramenta de
apoio.
Nas cinco primeiras definições é possível visualizar de forma clara a união de diferentes
conceitos a fim de maximizar a produtividade e qualidade de todo processo, sendo que, o
Scrum contribuiu especificamente na inclusão de suas cerimônias (reunião diária,
planejamento da sprint e a própria sprint). Para dar seguimento às próximas definições é
necessário um melhor entendimento de como planejar e o que exatamente será planejado,
visto que se trata de uma célula de serviços de TI, onde apresenta atividades operacionais.
A célula de serviços de TI do AGHU deve atender três tipos de atividades: requisições
de serviço, incidentes e problemas (conforme descrito na seção 5.3.3). Entretanto, requisições
de serviços e incidentes são atendidas por ordem de prioridade, porém existem serviços
registrados pela própria equipe que possibilitam a melhoria contínua no atendimento, como
por exemplo, a instalação de uma ferramenta de monitoramento ou a atualização de versão de
qualquer outra ferramenta. Estes serviços são priorizados pela própria equipe a fim de atingir
o planejamento estratégico da célula de serviço de TI do AGHU, bem como outros tipos de
requisições. Sendo assim segue mais algumas definições, principalmente em relação à
cerimônia de planejamento:
100
2. As atividades que não forem de alta prioridade devem ser planejadas a fim de ser
executadas dentro da sprint;
3. Requisições do tipo problema ou atividades para melhoria continua devem entrar
no planejamento da sprint, sendo que, devem ser priorizadas de acordo com o
planejamento estratégico da célula;
4. Toda equipe deve possuir métricas (vide Apêndice E) a fim de entender quanto
tempo à equipe gasta com demandas operacionais, para assim ser possível a
realização de um planejamento mais coerente com sua realidade. Devido a esta
variável de demandas operacionais as equipes devem trabalhar com o conceito de
folga, sugerido no XP.
Com boa parte do método das equipes definido, ainda sobre a sprint, o Scrum sugere uma
reunião de revisão da sprint, com a finalidade de inspecionar o que foi feito e caso necessário
adaptar o backlog do produto (SCHWABER, 2011). Porém, no cenário de serviços de TI, essa
reunião não se faz necessária, pois não está sendo construído um produto e sim entregando
serviços. Entretanto, a fim de promover a colaboração entre equipes e alinhamento entre
essas, define-se que:
1. Deve ser realizada uma reunião de revisão de sprints com todas as equipes a cada
três semanas, sendo que esta deve ser realizada em pé e deve ter duração máxima
de 20 minutos. A intenção principal, além de promover a colaboração e o
alinhamento, é que todos saibam se o trabalho realizado está de acordo com o
planejamento estratégico da célula de serviços, caso não esteja, todos os membros
terão a liberdade de colaborar com novas ideias para que o trabalho realizado
tome o rumo correto.
Definida mais uma das cerimônias, existe um conceito que, apesar de ser comentado,
ainda não foi definido que é a melhoria contínua do trabalho realizado. Um dos pilares do
Scrum, adaptação (SCHWABER, 2011), na qual equipe precisa ser transparente para que na
inspeção se encontre pontos falhos e a partir destes a equipe deve ter a capacidade de adaptar-
se para assim melhorar de forma contínua. Uma das fases da ITIL v3, melhoria contínua de
processo, também se refere à necessidade de sempre estar melhorando.
Talvez uma das grandes vantagens da união da ITIL v3 com algumas práticas ágeis seja
na promoção da colaboração, ou seja, não deve existir mais uma pessoa responsável pela
101
melhoria contínua do trabalho e sim todos os membros da célula de serviços do AGHU
apresentam o mesmo grau de responsabilidade por melhorar continuamente todos os serviços
prestados, pois as práticas ágeis incentivam a colaboração e isto acelera a melhoria continua.
Pela importância destacada no parágrafo acima, define-se que:
1. Devido ao dinamismo das equipes de serviço e com isso a dificuldade de se
realizar uma reunião com todos durante um tempo considerável, cada uma das
equipes deve montar um quadro de lições aprendidas, onde deve ser possível
colocar pontos positivos e pontos negativos em papéis adesivos e lançar estes no
quadro a qualquer momento, ficando visível para todas as equipes;
2. O quadro de lições aprendidas deve ter quatro colunas, peso (1 a 3 para pontos
fortes e -1 a -3 para pontos fracos), ponto forte ou fraco, causa raiz e plano de
ação, sendo que qualquer uma das colunas pode ter uma atividade lançada a
qualquer momento;
3. Deve ser realizada uma revisão do quadro de lições aprendidas no intervalo
máximo de 3 semanas, ou seja, a equipe pode realizar a revisão a qualquer
momento, mas não deve demorar mais do que 3 semanas para realizar esta
revisão. Nesta revisão serão analisados e discutidos brevemente os pontos em
destaque e em comum acordo será definido o plano de ação necessário para
solução destes. Cada plano de ação definido deve ser transformado em atividades
planejáveis que farão parte do Kanban da equipe. Esta cerimônia deve ter duração
máxima de 30 minutos e pode ser realizada em frente ao quadro de lições
aprendidas.
Com estas últimas definições conclui-se a forma de como as equipes devem trabalhar,
com grande foco no trabalho em equipe e na promoção da colaboração entre todos os
membros desta célula. O grande objetivo destas definições esta na tentativa de seguir os
valores ágeis, ou seja, ser ágil e não apenas seguir suas práticas. Obviamente, já descrito neste
trabalho, existe um elo entre os conceitos e o contexto atual que possibilitaram a união destes
a fim de melhorar a realidade atual.
Na próxima seção serão apresentadas adaptações realizadas na ferramenta de apoio
escolhida para o gerenciamento dos serviços de TI prestados pela equipe do AGHU.
102
5.3.5 Ferramenta de apoio
Devido ao Projeto AGHU ser construído com tecnologias de software livre e utilizar o
Redmine (LANG, 2006) como ferramenta de gerenciamento de projetos, entende-se que é
possível utilizar a mesma ferramenta, com algumas customizações e atualizações, para gestão
de serviços. Entretanto, o Redmine apresenta algumas limitações em nível de gestão, mas que,
devido à dificuldade de adquirir uma nova ferramenta e a facilidade para customizar o
Redmine, tomou-se a decisão de utilizar este aplicativo para controle de todas as requisições
de serviço. Para utilização do Redmine será necessário a execução das seguintes tarefas:
103
6 EXECUÇÃO
Com o processo definido, foi iniciada a sua implantação. Este capítulo está dividido em
três seções, são elas: Planejamento da Implantação onde será apresentado um pequeno plano
de implantação; Execução da Implantação onde será apresentado o dia a dia da execução com
fotos e comentários da evolução da implantação; Reaplicação do Instrumento de Avaliação
onde será reaplicado com mais participantes o instrumento de avaliação executado antes da
implantação do novo processo.
Com a relação de atividades definida, as mesmas devem ser executadas de acordo com o
seguinte cronograma:
104
Atividade Semana
1, 2 e 3 1
4 2
5 3
6e7 4
8 5
9 6
10 7, 8 e 9
Tabela 19 - Cronograma de Execução de Atividades de Implantação por Semana.
105
Figura 25 - Calendário do Mês de Julho.
Ainda sobre a construção de um ambiente informativo que agregue valor no trabalho das
equipes da célula de serviços de TI do AGHU, foi elaborado um quadro para representar a
situação dos HUF’s, este segue na figura 26. Esta figura apresenta a situação em relação à
implantação de todos os HUF’s do Brasil, sendo que estes estão divididos por porte de 1 (para
hospitais menores) a 4 (para hospitais maiores).
Abaixo segue a legenda da figura 26:
• HUF’s escritos em vermelho representam hospitais de porte 4;
• HUF’s escritos em preto representam hospitais de porte 3;
• HUF’s escritos em verde representam hospitais de porte 2;
• HUF’s escritos em azul representam hospitais de porte 1.
106
Figura 26 - Situação HUF's.
107
Figura 27 - Kanban e Quadro de Lições Aprendidas.
108
• Em Homolog. (Homologação - Validação): após liberação para o ambiente de
staging, pode se iniciar a homologação junto a central de serviços e está etapa
representa a execução da homologação;
• Homologado (Validação): neste deve ser listada todas as atividades que já estão
homologadas e prontas para ser colocada em ambiente de produção;
• Em Transição (Encerramento): atividades que iniciaram o processo de transição
a fim de disponibilizar estas em ambiente de produção;
• Pronto (Encerramento): representa que a atividade se encontra disponível em
produção.
Na figura apresentada (29) é possível verificar que o fluxo está sendo executado, restando
apenas uma atividade que ainda não iniciou sua execução. Também pode-se verificar que a
atividade definida como “Folga”, conforme orientação do XP, ainda não iniciou sua execução.
110
No decorrer da semana a equipe seguiu exatamente o processo definido, inclusive
respeitando o tempo máximo de cada reunião, ainda foi possível perceber alguma dificuldade
de alguns membros da equipe em trabalhar com o Kanban, por se tratar de uma mudança de
cultura. Entretanto todos se demonstraram motivados e acreditando nesse novo processo.
Durante a semana a equipe teve diversas conversas entre si com a finalidade de melhorar
o processo e nessa mesma semana já foi possível identificar algumas falhas internas através
de alguns gargalos apresentados no Kanban. Foi possível perceber de forma clara a promoção
da colaboração dessa equipe com todo o processo, que é um dos grandes objetivos do
processo descrito neste trabalho.
A próxima figura (Figura 30) nos apresenta a situação do Kanban após o planejamento da
segunda sprint de execução da implantação do novo processo.
Na figura 30 é interessante analisar alguns pontos, como por exemplo, nem todos os itens
da planejados na sprint anterior foram concluídos, alguns ficaram trancados na fase de
transição e outros na fase de homologação. Seguindo este exemplo é possível identificar
111
gargalos nesses pontos do fluxo de trabalho e a partir disso a equipe percebeu um ponto a
melhorar e iniciou a utilização do quadro de lições aprendidas. Ainda nesta figura é possível
perceber uma atividade lançada dentro do contexto de “folga” do XP e, além disso, a ideia de
limites por membro da equipe a fim de promover a troca de conhecimento, ninguém da equipe
está trabalhando em mais de três atividades.
O quadro de lições aprendidas que aparece nas figuras 28, 29 e 30, deve alavancar de
maneira colaborativa a melhoria contínua do processo executado pela equipe, os pontos fracos
devem estar relacionados a uma causa raiz e baseado nesta deve ser elaborado um plano de
ação ou atividade que será planejada pela equipe para ser executada dentro de uma sprint,
assim tem-se um processo melhoria cíclica.
Ao final da terceira semana de execução do novo processo foi reaplicado o instrumento
de avaliação a fim de validar os resultados obtidos, na próxima seção será detalhada essa nova
execução do instrumento.
Participante 1
Tempo de experiência na área de TI: 19 anos
Tempo de experiência na área de serviços de TI: 11 anos
Tempo de experiência no Projeto AGHU: 3 anos
Atividades atuais na equipe de aplicação do AGHU:
112
• Líder de equipe de aplicação;
• Monitora bancos de dados utilizados Projeto AGHU;
• Monitora ambientes utilizados para o Projeto AGHU.
Participante 2
Tempo de experiência na área de TI: 8 anos
Tempo de experiência na área de serviços de TI: 5 anos
Tempo de experiência no Projeto AGHU: 3 anos
Atividades atuais na equipe de operação do AGHU:
• Líder de equipe de operação;
• Responsável pela sustentação e implantação do Projeto AGHU.
Participante 3
Tempo de experiência na área de TI: 6 anos
Tempo de experiência na área de serviços de TI: 1 ano
Tempo de experiência no Projeto AGHU: 1 ano e 3 meses
Atividades atuais na equipe de operação do AGHU:
• Desenvolvedor de sistemas;
• Resolução de incidentes e problemas relacionados ao Projeto AGHU;
• Instalações vinculadas ao Projeto AGHU.
Participante 4
Tempo de experiência na área de TI: 8 anos
Tempo de experiência na área de serviços de TI: 2 anos
Tempo de experiência no Projeto AGHU: 1 ano e 3 meses
Atividades atuais na equipe de operação do AGHU:
• Desenvolvedor de sistemas;
• Resolução de incidentes e problemas relacionados ao Projeto AGHU;
• Instalações vinculadas ao Projeto AGHU.
Participante 5
Tempo de experiência na área de TI: 9 anos
Tempo de experiência na área de serviços de TI: 2 anos
Tempo de experiência no Projeto AGHU: 3 anos
Atividades atuais na equipe de operação do AGHU:
• Desenvolvedor de sistemas;
113
• Resolução de incidentes e problemas relacionados ao Projeto AGHU;
• Instalações vinculadas ao Projeto AGHU.
Participante 6
Tempo de experiência na área de TI: 12 anos
Tempo de experiência na área de serviços de TI: 1 ano
Tempo de experiência no Projeto AGHU: 3 anos
Atividades atuais na equipe de operação do AGHU:
• Analista de Qualidade;
• Responsável pela garantia de qualidade do produto AGHU.
Tabela 20 - Perfil dos Participantes da Avaliação Final.
Gerência de
Serviços –
Inicial Repetível Definido Gerenciado Otimizado
Projeto
AGHU
Estratégia
1 4 17 27 17
de Serviço
Desenho de
6 13 30 26 9
Serviço
Transição
0 7 21 8 6
de Serviço
Operação de
2 2 15 14 15
Serviço
Melhoria
Contínua de 2 7 13 13 7
Processo
114
Scrum 3 10 13 32 32
XP 5 9 12 5 5
Kanban 0 0 3 3 18
Tabela 21 - Respostas da Reavaliação Agrupadas por Nível de Maturidade.
A figura 31 que segue apresenta os números descritos na tabela 21 sendo que os valores
foram transformados para percentual.
Esta seção encerra este capítulo. No próximo capítulo será realizado uma análise dos
resultados obtidos.
115
7 ANÁLISE DOS RESULTADOS
Através dos dados apresentados na tabela 22 foi obtido o gráfico comparativo (avaliação
inicial versus final) presente na figura 32.
116
Figura 32 - Gráfico Comparativo da Execução do Instrumento de Avaliação.
117
7.1 Análise de Pontos Positivos e Negativos
Após a execução final do instrumento de avaliação, mesmo que esse tenha obtido um
resultado satisfatório, foi possível identificar pontos positivos e negativos no novo processo
definido. Segue uma relação dos pontos positivos levantados durante a execução deste novo
processo:
Além dos pontos positivos, também foi possível identificar alguns pontos negativos:
Na próxima seção será realizada uma pequena análise dos pontos fracos citados.
Com o detalhamento dos pontos, este capítulo se encerra. No próximo capítulo será
concluído este trabalho.
120
8 CONCLUSÃO
A oportunidade de realização deste trabalho nasceu devido ao Projeto AGHU e a
necessidade de constituir uma célula de serviços de TI a fim de sustentar este projeto em 46
Hospitais Universitários Federais. Esta célula de serviços já possuía uma estrutura, no
entanto, esta era insuficiente para os planos desejados para o projeto. Além disso, a equipe
não possuía maturidade em nível de processo ou qualquer outra boa prática conhecida para
gerenciamento de serviços.
Este trabalho se iniciou com o objetivo principal de definir e implantar um processo de
gerenciamento de serviços constituído com base na ITIL v3 com foco na fase de operação de
serviço e práticas ágeis aplicadas à realidade do Projeto AGHU, para assim, melhor atender as
necessidades dos HUF’s. Considera-se que o objetivo principal foi alcançado, pois hoje a
célula de serviços funciona com o processo definido neste trabalho.
Além disso, este trabalho possibilitou um melhor entendimento das boas práticas
sugeridas pela ITIL v3 e os métodos ágeis, o que norteou a definição do novo processo, bem
como o entendimento do contexto da área de serviços de TI para o Projeto AGHU, ponto
fundamental para estruturação deste. Após a execução, foi realizada uma reavaliação dos
resultados para assim verificar se houve o ganho esperado com o novo processo. Com isso
entende-se que o trabalho alcançou todos os objetivos inicialmente definidos.
O novo processo apresentou resultados positivos em comparação com a avaliação
realizada antes de sua implantação, sendo que, as duas avaliações foram realizadas por
membros da própria equipe de serviços de TI que já nas primeiras semanas de execução
levantaram pontos positivos e negativos. Os pontos negativos geraram atividades que deram
início ao ciclo de melhoria contínua sendo possível visualizar claramente a promoção da
colaboração.
Vale salientar também que este trabalho foi selecionado para a sessão de pôsteres do IX
Seminário de Gerenciamento de Projetos. Durante sua finalização foi enviado seu conteúdo
em formato de pôster para o IX Seminário de Gerenciamento de Projetos e este se deu por
vencedor (PMI, 2012).
Por fim, considera-se que um dos pontos mais relevantes deste trabalho, além das
melhorias que o novo processo trouxe para esta célula, foi o entendimento de que os
princípios ou valores são fundamentais para construção de qualquer processo, visto que este
121
trabalho uniu várias boas práticas a fim de constituir um processo que sempre esteve
preocupado com seus valores.
122
Independente do trabalho que for realizado é fundamental que se tenha cuidado com o
número de pessoas que poderão participar da avaliação do instrumento de pesquisa, pois uma
das limitações deste trabalho foi exatamente o baixo número de pessoas que responderam o
instrumento. Além do instrumento de avaliação, seria interessante a comparação de métricas
ou indicadores antes e depois da implantação do trabalho para melhor entender os resultados.
123
REFERÊNCIAS BIBLIOGRÁFICAS
BOEG, Jasper. Priming Kanban - A 10 step guide to optimizing flow in your software
delivery system. Denmark: Chronografisk A/S, 2011.
BON, Jan van. IT Service Management: An Introduction. Van Haren Publishing, 2002.
LANG, Jean. Redmine. Disponível em <http://redmine.org/ >, 2006. Último acesso em:
23/08/2012.
OGC, Office of Government Commerce. ITIL v3 The Official Introdution to the ITIL
Service Lifecycle. United Kingdom: The Stationery Office, 2007a.
OGC, Office of Government Commerce. ITIL v3 Service Strategy. United Kingdom: The
Stationery Office, 2007b.
OGC, Office of Government Commerce. ITIL v3 Service Design. United Kingdom: The
Stationery Office, 2007c.
124
OGC, Office of Government Commerce. ITIL v3 Service Transition. United Kingdom: The
Stationery Office, 2007d.
OGC, Office of Government Commerce. ITIL v3 Service Operation. United Kingdom: The
Stationery Office, 2007e
RASMUSSON, Jonathan. The Agile Samurais - How Agile Masters Deliver Great
Software. United States of America: Susannah Davidson Pfalzer, 2010.
SKARIN, Mattias et al. Kanban e Scrum - obtendo o melhor de ambos. United States of
America: C4Media Inc., 2009.
125
APÊNDICE A – Dados coletados no instrumento de avaliação
Questão Participante 1 Participante 2 Participante 3
1 2 1 2
2 2 1 1
3 1 1 1
4 2 2 2
5 2 2 2
6 1 2 1
7 1 1 1
8 1 1 1
9 2 2 2
10 1 2 2
11 1 2 1
12 1 2 1
13 2 2 2
14 2 2 2
15 1 2 1
16 1 1 1
17 1 1 1
18 1 1 1
19 2 2 2
20 1 2 2
21 2 2 2
22 2 2 1
23 1 2 1
24 1 2 1
25 2 2 2
26 2 2 2
27 2 2 2
28 2 1 2
126
29 2 1 2
30 1 1 2
31 1 1 1
32 1 1 2
33 1 2 2
34 1 1 1
35 1 1 2
36 2 2 2
37 1 2 1
38 2 3 3
39 1 1 2
40 2 3 2
41 2 3 2
42 1 3 1
43 2 2 2
44 2 1 2
45 2 1 2
46 2 1 2
47 2 1 2
48 1 1 1
49 1 1 1
50 1 1 1
51 2 1 2
52 2 1 2
53 1 1 1
54 1 1 1
55 1 1 1
56 1 1 1
57 1 3 1
58 1 1 2
59 2 2 2
60 1 3 1
127
61 2 2 2
62 1 1 1
63 1 2 2
64 2 2 2
65 2 3 2
66 2 2 2
67 1 1 2
68 2 3 2
69 1 2 1
70 2 5 2
71 1 1 1
72 1 1 1
Média 1,46 1,68 1,58
Tabela 23 - Dados Primeira Execução do Instrumento de Avaliação.
128
APÊNDICE B – Fluxo completo de uma requisição de serviço
129
APÊNDICE C - Fluxo completo de um incidente ou problema
130
APÊNDICE D – Catálogo de serviços
1º Nível
Como Atendimento
Nível 1 Nível 2 Nível 3 Descrição do serviço Equipe solicitar o prove
serviço suporte
inicial?
Banco de Alteração Qualquer mudança de Sustentação - Ferramenta
Dados Estrutural estrutura nos bancos Aplicação de Apoio.
suportados pelo time do
AGHU.
Banco de Configuração Manutenção de Sustentação - Ferramenta
Dados configuração nos bancos Aplicação de Apoio.
suportados pelo time do
AGHU.
Banco de Carga de Manutenção dos dados Sustentação - Ferramenta
Dados Dados nos bancos suportados Aplicação de Apoio.
pelo time do AGHU.
Banco de Esperanto Carga de Dados Manutenção das tabelas Sustentação - Ferramenta
Dados do banco de dados Aplicação de Apoio.
denominado Esperanto.
Banco de Parametrização Manutenção da tabela Sustentação - Ferramenta
Dados AGH_PARAMETROS. Aplicação de Apoio.
Banco de Versionamento Aplicação de Objetos de Sustentação - Ferramenta
Dados Banco. Versionamento Aplicação de Apoio.
do banco conforme a
aplicação.
131
Banco de Publicação Aplicação de mudanças Sustentação - Ferramenta
Dados no banco de dados em Aplicação de Apoio.
ambientes.
Banco de Backup "Criação de scripts para Sustentação - Ferramenta
Dados agendamento de backup Aplicação de Apoio.
de dados. Validação
periódica dos
agendamentos de
backup."
Banco de Restore Restaurar o backup da Sustentação - Ferramenta
Dados base de dados. Aplicação de Apoio.
Banco de Sequence Manutenção de Sustentação - Ferramenta
Dados sequence de banco de Aplicação de Apoio.
dados.
Banco de Permissões Manutenção de Sustentação - Ferramenta
Dados permissões de banco de Aplicação de Apoio.
dados.
Software Aplicação Publicação Compilar aplicação no Sustentação - Ferramenta
ambiente solicitado e Aplicação de Apoio.
publicar no respectivo
servidor.
Software Integração Novo serviço Solicitar automação de Sustentação - Ferramenta
Contínua processos. Aplicação de Apoio.
Software Integração Manutenção dos Alterar serviços Sustentação - Ferramenta
Contínua serviços existentes existentes na ferramenta Aplicação de Apoio.
de automação.
Software Qualidade Automatização de Execução de Testes Sustentação - Ferramenta
Testes - Execução Automatizados para Operação de Apoio.
liberação de nova
versão.
Software Configuração Criação de branch / Criar novo repositório Sustentação - Ferramenta
Tag de desenvolvimento. Aplicação de Apoio.
132
Software Configuração Manutenção de Restaurar, alterar e Sustentação - Ferramenta
branch / Tag excluir repositórios de Aplicação de Apoio.
desenvolvimento.
Software Configuração Realização de Realizar a manutenção Sustentação - Ferramenta
Merge de revisions entre Aplicação de Apoio.
respositórios diferentes.
Software Configuração Liberação de Criar versão definitiva Sustentação - Ferramenta
Versão de ambiente. Aplicação de Apoio.
Software Manutenção Perfis Configuração de Perfis Sustentação - Ferramenta Sim
do AGHU. Delivery de Apoio.
Software Manutenção Impressoras Configuração de Sustentação - Ferramenta Sim
impressoras para Delivery de Apoio.
impressão no AGHU.
Software Manutenção Usuários Configuração dos Sustentação - Ferramenta Sim
usuários cadastrados no Delivery de Apoio.
AGHU.
Software Manutenção Unidades Cadastrar, vincular Sustentação - Ferramenta Sim
Funcionais impressoras, editar e Delivery de Apoio.
excluir unidades
funcionais.
Software Manutenção Parâmetros Configuração de Sustentação - Ferramenta Sim
parâmetros de sistema. Delivery de Apoio.
Software Manutenção Reindexação Reindexação de tabelas Sustentação - Ferramenta Sim
como: AipCidades, Operação de Apoio.
AipTipoLogradouros,
AipSinonimosOcupacao,
AipOcupacoes,
AipLogradouros.
Software Manutenção Refonetização Refonetizar software de Sustentação - Ferramenta Sim
busca Lucene. Operação de Apoio.
Software Manutenção Microcomputadores Cadastrar, editar, Sustentação - Ferramenta Sim
133
associar ou excluir Operação de Apoio.
microcomputadores.
Software Manutenção Arquitetura Qualquer problema Arquitetura Ferramenta
identificado na de Apoio.
arquitetura da aplicação.
Software Manutenção Pacientes Serviços, Incidentes ou Sustentação - Ferramenta
Problemas encontrados Operação de Apoio.
na aplicação no módulo
de Pacientes.
Software Manutenção Internação Serviços, Incidentes ou Sustentação - Ferramenta
Problemas encontrados Operação de Apoio.
na aplicação no módulo
de Internação.
Software Manutenção Prescrição Médica Serviços, Incidentes ou Sustentação - Ferramenta
Problemas encontrados Operação de Apoio.
na aplicação no módulo
de Prescrição Médica.
Software Manutenção Indicadores Serviços, Incidentes ou Sustentação - Ferramenta
Hospitalares Problemas encontrados Operação de Apoio.
na aplicação no módulo
de Indicadores.
Software Manutenção Farmácia Serviços, Incidentes ou Sustentação - Ferramenta
Problemas encontrados Operação de Apoio.
na aplicação no módulo
de Farmácia.
Software Manutenção Registro Serviços, Incidentes ou Sustentação - Ferramenta
Colaborador Problemas encontrados Operação de Apoio.
na aplicação no módulo
de Registro
Colaborador.
Software Manutenção Ambulatório Serviços, Incidentes ou Sustentação - Ferramenta
Problemas encontrados Operação de Apoio.
134
na aplicação no módulo
de Ambulatório.
Software Manutenção Estoque Serviços, Incidentes ou Sustentação - Ferramenta
Problemas encontrados Operação de Apoio.
na aplicação no módulo
de Estoque.
Software Manutenção Exames Serviços, Incidentes ou Sustentação - Ferramenta
Problemas encontrados Operação de Apoio.
na aplicação no módulo
de Exames.
Software Manutenção Controle de Serviços, Incidentes ou Sustentação - Ferramenta
Pacientes Problemas encontrados Operação de Apoio.
na aplicação no módulo
de Controle de
Pacientes.
Software Manutenção SICON Serviços, Incidentes ou Sustentação - Ferramenta
Problemas encontrados Operação de Apoio.
na aplicação no módulo
SICON.
Software Manutenção Outros Serviços, Incidentes ou Sustentação - Ferramenta
Problemas encontrados Operação de Apoio.
na aplicação.
Implantação Inspeção Viagens, Relatórios, Sustentação - Ferramenta
Reuniões, etc. Tudo que Delivery de Apoio.
for referente a etapa de
inspeção de HUF’s.
Implantação Instalação Toda a instalação Sustentação - Ferramenta
necessária para Delivery de Apoio.
implantar o AGHU.
Implantação Treinamento Treinamentos em geral. Sustentação - Ferramenta
Delivery de Apoio.
135
Implantação Testes Automatizado Testes automatizados Sustentação - Ferramenta
para garantir a qualidade Delivery de Apoio.
da versão que se deseja
implantar.
Implantação Testes Regressional Testes regressionais para Sustentação - Ferramenta
garantir a qualidade da Delivery de Apoio.
versão que se deseja
implantar.
Implantação Suporte Suporte ou apoio em Sustentação - Ferramenta
atividades do Delivery de Apoio.
planejamento de
implantação.
Redmine Inclusão Inclusão de novos Sustentação - Ferramenta
usuários, projetos, tipos Delivery de Apoio.
de tarefas, etc.
Redmine Alteração Alteração de dados de Sustentação - Ferramenta
usuários cadastrados, Delivery de Apoio.
projetos, tarefas, etc.
Redmine Exclusão Exclusão de dados de Sustentação - Ferramenta
usuários cadastrados, Delivery de Apoio.
projetos, tarefas, etc.
Redmine Treinamento Treinamento de como Sustentação - Ferramenta
solicitar um serviço para Delivery de Apoio.
equipe de suporte do
AGHU pelo Redmine.
Redmine Coaching Coaching de como Sustentação - Ferramenta
melhor utilizar a Delivery de Apoio.
ferramenta para solicitar
um serviço para equipe
de suporte do AGHU
pelo Redmine.
136
Redmine Dúvida Diversas Dúvidas em relação a Sustentação - Ferramenta
ferramenta, desde que Delivery de Apoio.
tenham relação com o
AGHU.
Infraestrutura Instalação SVN Instalar SVN. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Instalação Jboss Instalar Jboss. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Instalação Postgres Instalar PostgreSQL. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Instalação Redmine Instalar Redmine. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Instalação Maven Instalar Maven. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Instalação Archiva Instalar Archiva. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Instalação Jenkins Instalar Jenkins. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Instalação CUPS Instalar CUPS. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Instalação Pentaho Instalar software de Infraestrutura Ferramenta
business intelligence - de Apoio.
Pentaho.
Infraestrutura Instalação LDAP Instalar LDAP. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Instalação Servidor Instalar Servidor. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Instalação Rede Instalar Rede. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Instalação Storage Instalar Storage. Infraestrutura Ferramenta
de Apoio.
137
Infraestrutura Instalação Firewall Instalar Firewall. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Instalação Monit Instalar Monit. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Instalação Gateway SSH Instalar gw ssh. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Instalação Apache Instalar Apache. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Instalação XenServer Instalar Infraestrutura Ferramenta
XenServer(appliances). de Apoio.
Infraestrutura Instalação DNS Instalar DNS. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Instalação Monitoramento Instalar ferramentas para Infraestrutura Ferramenta
monitoramento. de Apoio.
Infraestrutura Instalação SO Instalar Sistema Infraestrutura Ferramenta
Operacional. de Apoio.
Infraestrutura Manutenção Jboss Manutenção do Jboss. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Manutenção PostgreSQL Manutenção do Infraestrutura Ferramenta
PostgreSQL. de Apoio.
Infraestrutura Manutenção Redmine Manutenção do Infraestrutura Ferramenta
Redmine. de Apoio.
Infraestrutura Manutenção Maven Manutenção do Maven. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Manutenção Archiva Manutenção do Archiva. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Manutenção Jenkins Manutenção do Jenkins. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Manutenção CUPS Manutenção do CUPS. Infraestrutura Ferramenta Sim
de Apoio.
138
Infraestrutura Manutenção Pentaho Manutenção do Pentaho. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Manutenção LDAP Manutenção de LDAP. Infraestrutura Ferramenta Sim
de Apoio.
Infraestrutura Manutenção Servidor Manutenção de Infraestrutura Ferramenta
Servidor. de Apoio.
Infraestrutura Manutenção Rede Manutenção de Rede. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Manutenção Storage Manutenção de Storage. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Manutenção Firewall Manutenção de Infraestrutura Ferramenta
Firewall. de Apoio.
Infraestrutura Manutenção Monit Manutenção Monit. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Manutenção Gateway SSH Manutenção gw ssh. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Manutenção Apache Manutenção Apache. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Manutenção XenServer Manutenção XenServer Infraestrutura Ferramenta Sim
(appliances). de Apoio.
Infraestrutura Manutenção DNS Manutenção DNS. Infraestrutura Ferramenta Sim
de Apoio.
Infraestrutura Manutenção SO Manutenção SO. Infraestrutura Ferramenta
de Apoio.
Infraestrutura Manutenção Monitoramento Manutenção das Infraestrutura Ferramenta Sim
ferramentas de de Apoio.
monitoramento.
Suporte Dúvidas Diversas Dúvidas sobre o AGHU. Todas Ferramenta
de Apoio.
Suporte Dúvidas Usabilidade Dúvidas sobre Todas Ferramenta Sim
usabilidade do AGHU. de Apoio.
139
Suporte Dúvidas Negócio Dúvidas sobre negócio Todas Ferramenta Sim
do AGHU. de Apoio.
Suporte Informações Diversas Informações sobre o Todas Ferramenta
AGHU. de Apoio.
Tabela 24 - Catálogo de Serviços
140
APÊNDICE E – Métricas
O gráfico que segue (figura 35) representa o número total de requisições (serviços,
incidentes e problemas) que são registradas por sprint para célula de serviços de TI do
AGHU. Com essa informação é possível analisar a demanda operacional existente e com isso
entender quais os momentos aonde será necessário maior ou menor capacidade a fim de
melhor sustentar as demandas registradas.
Segue, na figura 36, o número total de requisições (serviços, incidentes e problemas) que
são concluídas por sprint pela célula de serviços de TI do AGHU. Com essa informação é
possível analisar a capacidade de resposta da equipe a cada sprint.
141
Figura 36 - Número de Requisições Concluídas por Sprint.
142
Figura 37 - Número de Requisições de Tipo “Serviço” registradas por Sprint.
143
Figura 38 - Número de Requisições do Tipo “Incidente” registradas por Sprint.
Segue, na figura 39, ilustração que representa o número total de requisições por item do
catálogo de serviços que são registradas por sprint para célula de serviços de TI do AGHU.
Com essa informação é possível analisar toda demanda existente especificamente por item do
catálogo de serviço. Possibilitando o conhecimento dos serviços mais solicitados bem como
os menos solicitados.
144
Figura 39 - Número de Requisições por Item do Catálogo de Serviços.
No gráfico que segue, representado na figura 40, representa o número total de requisições
que são registradas por HUF para célula de serviços de TI do AGHU. Com essa informação é
possível analisar toda demanda registrada por Hospital Universitário Federal.
145
Na figura 41 que segue, é apresentado um gráfico com o número total de requisições que
são registradas por prioridade de atendimento para célula de serviços de TI do AGHU. Com
essa informação é possível analisar toda demanda registrada dividida por prioridade e com
isso melhor entender a qualidade do serviço entregue.
146
APÊNDICE F – Exemplos de Ambiente Informativo
147
APÊNDICE G – Dados coletados na reavaliação do
instrumento de pesquisa
148
29 2 3 3 3 3 3
30 3 3 4 3 3 3
31 3 3 5 4 4 3
32 3 4 5 5 4 4
33 3 3 3 4 4 4
34 3 3 1 3 3 3
35 3 3 4 4 4 2
36 3 3 4 3 4 2
37 1 3 1 3 3 2
38 4 4 5 5 5 5
39 4 2 5 5 4 4
40 3 4 5 5 5 4
41 3 4 5 5 5 4
42 3 4 3 4 4 3
43 3 4 3 5 4 3
44 3 4 5 5 5 4
45 3 4 5 5 4 5
46 3 1 1 2 4 1
47 3 4 5 5 4 4
48 2 3 5 5 4 5
49 2 2 5 3 3 5
50 3 4 5 5 4 4
51 3 4 5 5 4 4
52 2 4 5 5 4 4
53 2 4 5 5 4 5
54 2 4 5 5 4 5
55 2 4 5 5 4 5
56 2 4 5 5 4 4
57 2 5 5 5 4 5
58 2 4 5 4 4 4
59 3 2 3 2 3 2
60 2 2 3 3 3 1
149
61 3 2 3 3 3 3
62 1 2 1 1 3 1
63 2 3 4 3 4 3
64 2 3 5 3 4 3
65 3 4 5 4 4 4
66 2 3 5 5 3 2
67 2 4 5 4 4 3
68 3 4 5 5 5 4
69 3 4 5 5 5 5
70 4 5 5 5 5 5
71 3 5 5 5 5 5
72 3 5 5 4 5 5
Média 2.76 3.29 4.11 4 4.01 3.375
Tabela 25 - Dados Segunda Execução do Instrumento de Avaliação.
150