roteiro para implantacao atlassian em orgaos de

Transcrição

Roteiro de Implantaçao Atlassian ALM
VERSÃO 20140529
Roteiro de Apoio para Implantação Atlassian ALM em
Órgãos de Governo no Brasil
FÁBRICA DE SOFTWARE | OUTSOURCING | MENTORIA | CONSULTORIA | ATLASSIAN | JBOSS | SPARXSYSTEMS | GESTÃO COMPARTILHADA
Av. Getúlio Vargas, 1594 salas 203, 703 e 704 – Menino Deus
CEP: 90150-000 – Porto Alegre – RS – Brasil
Fone: +55.51.3023.4139 | Skype: treelayer | Twitter: /3layer | Email: [email protected] | Web: www.3layer.com.br
3layer - comercial - roteiro para implantacao atlassian em orgaos de governo.docx
Página. 2 de 34
Porto Alegre, 29 de Maio de 2014
Prezado/a senhor/a.
Este documento é um roteiro de apoio para órgãos de governo interessados na implantação da plataforma
Atlassian ALM (Application LifeCycle Management), que inclui software como Jira, Confluence e correlacionados em
seus departamentos, setores, dependências, áreas e afins.
Baseado na experiência da 3layer Tecnologia em projetos anteriores de semelhante contexto, o texto a seguir
cobre, de maneira idônea e ética e, dentro do conhecimento da empresa nos princípios legais da Lei 8.666 sobre
Licitações e Contratos da Administração Pública, um passo-a-passo de como uma entidade com a sua, sob a égide do
Governo Brasileiro, pode desenvolver um projeto Atlassian ALM desde o lampejo da idéia inicial até a contratação
efetiva de um projeto de licenciamento, implantação e suporte continuado nesta plataforma.
Acreditamos que as informações aqui presentes sejam suficientes para vossa apreciação e tomada de decisão
quanto ao avanço do projeto.
Entretanto, caso tenha alguma dúvida ou necessite de maiores esclarecimentos, sinta-se à vontade para acionar
nossa equipe a qualquer momento.
Atenciosamente,
Julio Cesar Silveira
Marcelo Mrack
CIO
3layer Tecnologia
[email protected]
Skype: juliocsmac
Fone: 51.81870853
CEO
3layer Tecnologia
[email protected]
Skype: marcelo.mrack
Fone: 51.81870048
FÁBRICA DE SOFTWARE | OUTSOURCING | MENTORIA | CONSULTORIA | ATLASSIAN | REDHAT | SPARXSYSTEMS | GESTÃO COMPARTILHADA
Av. Getúlio Vargas, 1594 salas 203, 703 e 704 – Menino Deus
Página. 3 de 34
Sumário
PARTE 1 ............................................................................................................................................................................. 5
1
2
Introdução ................................................................................................................................................................. 5
1.1
Público-alvo ....................................................................................................................................................... 5
1.2
Organização do Texto ....................................................................................................................................... 5
1.3
Não Confidencialidade e Não Compromisso .................................................................................................... 6
3layer Tecnologia, a consultoria ............................................................................................................................... 7
2.1
Serviços Oferecidos ........................................................................................................................................... 7
2.2
Alianças Comerciais........................................................................................................................................... 7
3
Atlassian , a fabricante .............................................................................................................................................. 8
4
ALM Atlassian, a solução........................................................................................................................................... 9
4.1
O Mercado ALM ................................................................................................................................................ 9
4.1.1
Tipos de Solução ALM ............................................................................................................................... 9
4.1.2
Quadrante Mágico ALM ............................................................................................................................ 9
4.2
A Solução ALM da Atlassian ............................................................................................................................ 10
4.3
Os Produtos dentro do ALM Atlassian ............................................................................................................ 10
4.4
Termos e Conceitos na ALM Atlassian ............................................................................................................ 15
PARTE 2 ........................................................................................................................................................................... 17
5
A Contratação Atlassian no Governo ...................................................................................................................... 17
5.1
A Necessidade ................................................................................................................................................. 17
5.2
O Levantamento Inicial ................................................................................................................................... 18
5.2.1
Produtos ALM Atlassian .......................................................................................................................... 18
5.2.2
Stakeholders............................................................................................................................................ 18
5.2.3
Áreas Envolvidas ..................................................................................................................................... 19
5.2.4
Soluções Atuais ....................................................................................................................................... 20
5.2.5
Necessidades, Prioridades e Prazo.......................................................................................................... 20
5.2.6
Número de Usuários ............................................................................................................................... 21
5.2.7
Processos................................................................................................................................................. 21
5.2.8
Softwares de Interesse na ALM .............................................................................................................. 22
5.2.9
Os Administradores da Solução ALM ...................................................................................................... 23
5.2.10
Plano de Projeto Inicial ........................................................................................................................... 23
5.3
O Primeiro Contato com as Revendas ............................................................................................................ 24
5.4
A Formação do Escopo .................................................................................................................................... 26
5.5
As Propostas de Balizamento Comercial......................................................................................................... 27
5.6
A Confecção do Edital e o Termo de Referência ............................................................................................. 28
Av. Getúlio Vargas, 1594 salas 203, 703e 704 – Menino Deus
Página. 4 de 34
5.6.1
5.7
O Cálculo da Reserva Orçamentária ....................................................................................................... 28
A Publicação do Edital e as Propostas Finais .................................................................................................. 29
5.7.1
Edital Presencial ou Pregão Eletrônico ................................................................................................... 29
5.8
O Dia do Certame ............................................................................................................................................ 30
5.9
A Assinatura do Contrato e o Lançamento do Projeto ................................................................................... 30
5.10
A Execução do Projeto .................................................................................................................................... 30
5.10.1
Reunião de Kickoff .................................................................................................................................. 30
5.10.2
O dia-a-dia do Projeto ............................................................................................................................. 31
5.10.3
A Entrega do Projeto e a Passagem do Bastão ....................................................................................... 32
5.11
O Pós-Projeto e Contrato de Suporte ............................................................................................................. 32
5.12
A Renovação Anual ......................................................................................................................................... 32
PARTE 3 ........................................................................................................................................................................... 34
6
CASEs de Mercado .................................................................................................................................................. 34
7
Material de Apoio ................................................................................................................................................... 34
Página. 5 de 34
PARTE 1
1 INTRODUÇÃO
Diferentes entidades possuem diferentes formas para contração de produtos e de serviços. Enquanto o mundo
corporativo se utiliza de premissas geralmente próprias para seleção e contratação de fornecedores, as entidades
ligadas ao Governo necessitam atender inúmeros critérios legais para que uma contratação seja consistente e
aderente perante à Lei. No âmbito dos governos Federal, Estadual e Municipal, a Lei 8.666 que trata das Licitações e
Contratos da Administração Pública é a diretriz primária em qualquer processo de contratação. Embora esta Lei
tenha ampla divulgação, a interpretação dela pode ser distinta e palco de discussões que podem dificultar o
andamento de projetos importantes para o governo. Assim, de especial interesse aos envolvidos neste tipo de
contratação é a existência informações que auxiliem o processo de uma contratação. Guias, Tutoriais, Modelos,
Roterios, Bases de Conhecimento, Exemplos, Estudos de Caso e materiais de apoio com cenários reais de
contratações de sucesso balizadas pela Lei 8.666 são elementos-chave para o sucesso dessas iniciativas no governo.
A 3layer Tecnologia já tendo executado projetos de sucesso com órgãos de Governo acumulou experiência neste
meio e, com base nisso, apresenta este Roteiro de Implantação Atlassian ALM como uma ferramenta de apoio para
entidades governamentais interessadas na contratação de produtos e serviços Atlassian. Neste âmbito, o texto a
seguir cobre, de maneira idônea e ética e, dentro do conhecimento da empresa nos princípios legais da Lei 8.666,
um passo-a-passo de como uma entidade sob a égide do Governo pode avançar neste tipo de contratação desde o
lampejo da idéia inicial até a contratação efetiva de um projeto de licenciamento, implantação e suporte continuado
dessa plataforma.
1.1 Público-alvo
Devem tirar melhor proveito da leitura deste documento os seguintes papéis:

Diretores, Superintendentes, Coordenadores, Gestores e Gerentes de Projeto

Arquitetos, Analistas e Especialistas em desenvolvimento de sistemas

Equipes de Planejamento, de Qualidade e de Processos

Agentes, Departamentos, Áreas de P&D e Responsáveis por Contratação e Compras
1.2 Organização do Texto
A Parte 1 do documento apresenta a 3layer Tecnologia, revenda oficial Atlassian no Brasil e responsável pelo
licenciamento e por projetos de consultoria, implantação e suporte continuado. Também apresenta a empresa
australiana Atlassian, fabricante do software JIRA que faz parte da sua suíte ALM, líder no Quadrante Mágico do
Gartner Group e em franco crescimento no Brasil. A plataforma ALM Atlassian é mostrada ao final desta parte.
A Parte 2 apresenta os principais passos envolvidos em um processo de contratação de produtos e serviços
Atlassian por órgãos de governo regidos pela Lei 8.666. Como base deste passo-a-passo, é utilizada a experiência da
3layer Tecnologia em projetos já realizados com a Administração Pública desde o ano de 2010.
A Parte 3 apresenta um conjunto de CASEs, ou seja, casos de sucesso de implantação de projetos Atlassian pela
3layer Tecnologia, como forma de embasar o texto aqui apresentado e a metodologia de trabalho da 3layer. Esta
parte se encerra com a referência a alguns documentos que podem ser utilizados como templates e exemplos para
implantação do processo aqui descrito e links com mais informações e contatos a respeito do assunto.
Página. 6 de 34
1.3 Não Confidencialidade e Não Compromisso
Este documento não tem carácter sigiloso, podendo ser utilizado por qualquer órgão de governo interessado na
contratação de produtos ou serviços Atlassian, apto ser publicado ou distribuído a terceiros deliberadamente, desde
que mantendo inalterado o formato original aqui contido.
Este documento não gera nenhuma obrigação contratual ou comercial entre a 3layer Tecnologia, a Atlassian ou
qualquer órgão de governo, nem tampouco corresponde à promessa ou obrigação legal de nenhuma parte.
Página. 7 de 34
2
3LAYER TECNOLOGIA, a consultoria
A 3layer Tecnologia é uma brasileira de Tecnologia da Informação (TI) focada em soluções para o mercado
corporativo e governamental. Desenvolvimento em plataforma Java é seu business core.
Com operações iniciadas em 2010 e matriz em Porto Alegre, possui bases
operacionais em Florianópolis e São Paulo, tendo rede de atendimento presente em
diversos pontos do país e projetos ativos nos estados do Sul, Sudeste, Centro-Oeste e,
recentemente, Norte brasileiro.
Amparada por parcerias nacionais e internacionais, como Atlassian, Redhat, Google
e Sparxsystems, conta com profissionais certificados altamente qualificados, prestando
serviços com transparência, flexibilidade e agilidade, seguindo os moldes de processos
e metodologias referências de mercado, entre elas FDD, PMBOK e Scrum.
Com mais de 50.000 horas de projetos já executadas, é evangelista do Software
Livre e acredita no movimento Open Source como força motriz para disseminação de
Nossos clientes hoje
tecnologias de vanguarda a um custo reduzido. Não obstante, possui a área de projetos
públicos 3layer.org que mantém diversas iniciativas neste meio, como o Processo 3PUP e o projeto Mizura.
Em 2014 a empresa inicia seu processo de certificação MPSbr, tendo como meta o Nível C.
2.1 Serviços Oferecidos
Os seguintes serviços são prestados por nossa equipe de profissionais:
FÁBRICA DE SOFTWARE
OUTSOURCING
CONSULTORIA
GESTÃO COMPARTILHADA
Guiada por práticas semiágeis usando o Processo 3PUP,
desenvolve
soluções
em
plataforma Java enteprise e
mobile,
com
frameworks
Apache, Google, Redhat e
Postgres.
Nela,
sprints
quinzenais orientam o projeto
através de backlogs priorizados
junto ao cliente.
Cessão de profissionais em
modelo body shop, com ênfase
em arquitetos, desenvolvedores
e testadores em plataforma
Java. Com um ciclo PDCA
exclusivo, tem-se a garantia de
planejamento,
controle
e
evolução saúdavel dos contratos
de cessão dos profissionais.
Especialistas
de
ampla
experiência prestando serviços
remotos
ou
onsite
para
implantação,
customização,
integração de produtos e
passagem de conhecimento
sobre tecnologias Atlassian,
Sparxsytems e Redhat em todas
as fases do projeto.
Serviço de suporte mensal
pró-ativo com três modelos de
atendimento (Ouro, Prata e
Bronze) para ambientes de missão
crítica sobre tecnologias Apache,
Atlassian, Redhat e Postgres que,
com SLAs agressivos e equipe
dedicada,
garantem
a
tranquilidade do cliente em todos
os cenários.
2.2 Alianças Comerciais
Para operar todo o portfólio comercial, a 3layer Tecnologia conta com as seguintes alianças comerciais:
REVENDA AUTORIZADA
Licenciamento, implantação,
customização, integração,
desenvolvimento de plugins,
treinamento e consultoria em
todos os produtos Atlassian.
PARCEIRA
FÁBRICA DE SOFTWARE
PARCEIRA
Single Sign On, desenvolvimento
para nuvem, armazenamento
BigData, solução para emails,
mobile, comunicação e
documentos online.
Fábrica de software
homologada para
desenvolvimento de projetos
Java EE com selo Redhat em
tecnologias como
JBoss/WildFly, Hibernate,
Webeans, Drools e outras.
Treinamento, implantação,
customização, integração da
ferramenta Enterprise Architect
com outras ferramentas ALM
junto ao ciclo de
desenvolvimento de sistemas.
Página. 8 de 34
3 ATLASSIAN , a fabricante
Fundada em 2002, a Atlassian é uma empresa inovadora
com mais de 35.000 clientes em 150 países, incluindo 30 das
50 maiores companhias do mundo.
Fornecedora de 85 empresas da Fortune100, em 2012 a
empresa entrou no roll dos líderes em soluções Application
LifeCycle Managament (ALM) no Quadrante Mágico do
Gartner Group (ao lado), e vem trabalhando fortemente na
adição de funcionalidades nos seus produtos, com ênfase em
integração de conteúdo e extensões, na ampla documentação
e na fortificação dos seus canais de suporte e apoio aos
clientes, além do seu Marketplace, sucesso absoluto na
Internet.
Em relação ao suporte, os canais da Atlassian estão entre
os melhores do mundo e contam com rede global de experts
(a 3layer Tecnologia é um deles), website de documentação
totalmente
aberto
para
todos
os
produtos
(https://confluence.atlassian.com), fórum de discussão
extremamente ativo (http://answers.atlassian.com), área de
desenvolvedores
(https://developer.atlassian.com),
API
pública de todos os produtos (https://docs.atlassian.com) ,
canal de suporte exclusivo para usuários licenciados
(https://support.atlassian.com) incluindo atendimento por
telefone 24x7 para usuários de licenças “enterprise”, canal de
vídeos no Youtube (http://www.youtube.com/user/GoAtlassian),
Webinarios gratuitos, além de eventos globais anuais (o
Atlassian Summit e o AtlasCamp) que agregam fornecedores,
clientes, desenvolvedores e entusiastas da plataforma.
Completa
o
circuito
a
área
do
Marketplace
(http://marketplace.atlassian.com), um canal de vendas online
e discussão sobre produtos e soluções.
Não obstante, a Atlassian é solidária com movimentos
sociais, oferecendo inúmeras licenças gratuitas e apoiando
diversos programas educativos e assistenciais ao redor do
globo.
Junto à Atlassian, a 3layer Tecnologia é revenda oficial para
produtos e serviços em todo o Brasil.
Figura 1 - Atlassian no Quadrante Mágico do Garnter em
2013 (acima) e seu escritório na California, EUA
(abaixo).
Página. 9 de 34
4 ALM ATLASSIAN, a solução
4.1 O Mercado ALM
Application LifeCycle Management, ou simplesmente ALM é o termo utilizado para designar o conjunto de
ferramentas de apoio para a gestão e execução de todo o ciclo de vida de uma aplicação, desde sua concepção até
sua entrada em produção e posterior operação continuada.
Em outras palavras, um produto ALM é tido como completo se ele puder gerenciar adequadamente todas as
fases de execução de um projeto, desde o levantamento da idéia inicial, necessidades, requisitos, análise,
modelagem, projeto técnico, planejamento, construção, testes, homologação e aceite, incluindo não apenas as
tarefas do projeto, mas também os artefatos produzidos, como cronogramas, relatórios, documentos, código-fonte,
diagramas, modelos, itens de mídia como figuras, áudio ou vídeo, fazendo ainda gerenciamento de comunicação, de
versionamento, rastreabilidade, publicação de informações, segurança e auditoria. De forma geral, produtos ALM
são plataformas grandes e que mostram o valor agregado após meses, ou anos de implantação, tunning, integração,
customização e estabilização de uso pelas inúmeras pessoas e áreas envolvidas.
Diversos fabricantes no mundo oferecem suítes para gerenciamento ALM. Players como Microsoft, IBM, HP, e
Oracle são alguns exemplos válidos. A Atlassian é um desses fabricantes. E é líder global nesta área.
4.1.1 Tipos de Solução ALM
Grosso modo, plataformas ALM dividem-se em dois conjuntos, descritos brevemente a seguir:

Black Box: Este primeiro grupo envolve plataformas ALM completas e auto-contidas, as quais devem ser
implantadas “as is”, ou seja, elas já vêm pré-configuradas para atender uma visão, um cenário, um nicho,
um formato ou metodologia específica de trabalho. Produtos dessa linha tendem a ter um tempo menor
de implantação, embora, impliquem ao cliente fazer conceções e se adaptar às regras da ferramenta para
que o ciclo ALM funcione à sua maneira. A solução ALM da fabricante IBM pode ser considerada um
exemplo deste tipo de ferramenta.

White Box: Este grupo é o oposto do primeiro, e envolve plataformas de software flexíveis e
intercambiáveis, as quais não vêem configuradas para um nicho específico de mercado, mas sim podem
ser vistas como uma grande caixa de ferramentas, onde o cliente escolhe os módulos mais adequados
para o seu negócio e constrói as regras da ALM conforme a sua necessidade. Um trabalho maior de
implantação pode ocorrer aqui, mas a solução final cumpre a necessidade exata e bem dimensionada do
cliente. A solução ALM Atlassian é exemplo dessa linha.
Optar por um ou outro tipo de linha ALM é questão estratégica a ser respondida como primeiro movimento de
um projeto ALM.
4.1.2 Quadrante Mágico ALM
A consultoria americana Gartner (www.gartner.com) é referência de mercado em qualquer assunto relacionado à
pesquisas e relatórios sobre assuntos corporativos. O chamado Relatório de Quadrante Mágico é uma de suas
publicações mais famosas.
De simples interpretação, este relatório segmenta os players de uma área negócio por sua Visão (um eixo
horizontal) e por sua Capacidade de Entrega (um eixo vertical). A área entre estes eixos é separada em quadrantes
compreendendo os Niche Players (os quais atuam em apenas uma área do mercado, sem grande representação), os
Visionaries (que possuem extrema inovação, mas não tem capacidade de atender o que prometem), os Challengers
(tem capacidade de entrega, mas não agregam inovação) e os Leaders (possuem inovação e capacidade de entrega).
Página. 10 de 34
Haja visto produtos ALM terem evoluído bastante nos últimos anos e exigirem grandes investimentos de TI, a
Gartner vem publicando anualmente um relatório Quadrante Mágico para soluções ALM há algum tempo.
O último relatório, publicado em Novembro de 2013 pode ser apreciado no link abaixo, mostrando detalhes
sobre as plataformas ALM que são líderes hoje no mercado:
http://www.gartner.com/technology/reprints.do?id=1-1MN598P&ct=131105&st=sb
Desde 2012 a Atlassian é líder neste segmento ALM e vem crescendo a passos largos, com tendência a se tornar
líder isolada nos próximos anos.
O mesmo relatório acima está no ANEXO 8 para fins de apreciação.
4.2 A Solução ALM da Atlassian
O primeiro produto da Atlassian foi o software JIRA, em 2002, o qual continua sendo seu carro-chefe e por este
nome lembrada na maioria das empresas no mundo.
Porém, ao longo dos anos, e seguindo a visão estratégica da empresa de crescimento e valor agregado, diversos
outros softwares foram sendo construídos e incorporados à sua plataforma. Nesse iterím, o produto JIRA evoluiu
muito e hoje é um dos pilares da sua plataforma ALM, mostrada abaixo:
Figura 2 - Plataforma ALM Atlassian.
De forma resumida, a ALM Atlassian é
composta de vários produtos, que interagem
entre si para atender o ciclo completo de
desenvolvimento de um projeto.
Os pilares dessa solução são mostrados ao
centro, com os softwares JIRA, Crowd, Agile e
ServiceDesk.
No sentido horário, o ciclo se inicia com a
ferramenta
CASE
Enterprise
Architect
(integrada à solução ALM e explicada a seguir),
indo para o Confluence, Team Calendars, Stash
até o HipChat.
Toda a suíte Atlassian é construída sobre
plataforma Java, o que permite suportar
múltiplos Sistemas Operacionais e Bancos de
Dados. Com extensibilidade projetada para
módulos (Addons) também possui suporte 24x7
e atendimento onsite com parceiros locais,
chamados de Experts, como a 3layer Tecnologia.
As nuvens, à direita ao topo da figura, indicam que a plataforma pode operar em formato SaaS, via ambientes
montados em clouds comerciais, como a própria Atlassian oferece no seu serviço OnDemand.
4.3 Os Produtos dentro do ALM Atlassian
Todos os produtos da Atlassian são projetados para operar em dois formatos: Standalone e Integrados.
Quando operam em formato Standalone, o produto é auto-suficiente, e oferece todas as suas funcionalidades
nativas sem nenhuma perda nem dependência externa. Por exemplo, é possível utilizar o JIRA ou o Stash ou o
Bamboo isoladamente e tirar todo o benefício de em seu formato original separadamente. Porém, nestes casos,
você não está obtendo o benefício da integração da ALM.
Página. 11 de 34
Quando se instalam os produtos e ativa-se a integração entre eles, como por exemplo ativando o Single Sign On
(SSO) ou configurando os Application Links entre os produtos, eles se “descobrem” entre si e começam a trocar
dados, segurança e outras informações formando o tão esperado ciclo ALM. Neste formato o valor agregado é
maximizado.
É por este motivo que a solução ALM Atlassian é classificada como White Box, pois ela permite escolher usar ou
não um ou outro produto ou módulo, e optar quando deve ser dado “um passo a mais” e aplicar a verba de TI para,
por exemplo, utilizar o produto Clover para automatizar os testes de cobertura de código-fonte, entre outros.
Salienta-se também outro item da plataforma ALM Atlassian: a interoperabilidade com produtos de terceiros.
Este ponto é de especial interesse, pois conforme mostra a figura ALM anterior, os produtos Subversion e, mais
imporante ainda, o Enterprise Architect fazem parte do ciclo ALM, mas são de outros fabricantes.
Pela característica White Box e pela ampla capacidade de integração da sua arquitetura, a ALM Atlasssian se
integra com produtos externos via APIs de diferentes sabores, como REST, SOAP, XML, CSV, banco de dados ou API
Java. O Enteprise Architect (da fabricante Sparxsystems, em www.sparxsystems.com/products/ea), através do seu
plugin EA Connector se integra com o JIRA e permite exportar, importar e sincronizar objetos UML com tarefas de
um projeto. Por exemplo, um Caso de Uso dentro do Enterprise Architect pode ser visto com uma tarefa de projeto
dentro do JIRA. E tudo isso estar sincronizado naturalmente no ciclo ALM das ferramentas. Da mesma forma, o
software Subversion (da fabricante Tigris, em subersion.tigris.org) se integra na plataforma ALM Atlassian para
fornecer serviços de versionamento de artefatos (documentos, código-fonte, etc.).
É no canal de vendas marketplace.atlassian.com da Atlassian que estão centralizadas centenas de extensões
desenvolvidas pelas empresas parceiras, todas elas em sintonia com as políticas de qualidade e licenciamento
defendidas pelas Atlassian. Estas extensões também são consideradas como parte natural da plataforma Atlassian, e
são apresentadas neste documento como parte da solução ALM, se de interesse do cliente. Mais de 500 módulos
existem hoje no Marketplace da Atlassian.
Com base na experiência em diversos projetos, a 3layer Tecnologia apresenta na tabela abaixo uma lista com um
conjunto de software e extensões de módulos que se mostraram de grande valia para formar um ciclo ALM Atlassian
em clientes de médio e grande porte.
IMPORTANTE
O conjunto abaixo tende a ser um superset das possibilidades e precisa ser dimensionado conforme cada caso
para cada cliente. De forma geral, uma implantação ALM Atlassian usará apenas alguns desses módulos e plugins,
exceto realmente a complexidade do negócio do cliente exigir toda esta lista ou quiçá, mais outros produtos do
Marketplace.
TABELA 1 - Listagem de alguns produtos do ALM Atlassian (outros podem ser vistos no Marketplace Atlassian). Os marcados
em azul são produtos da própria Atlassian; os demais são de fabricantes parceiros no ecossistema.
SOFTWARE / MÓDULO
USO
JIRA
Ferramenta central da solução, gestão de demandas (incluindo bugs), de projetos, de suporte com
permissão granular, workflows, telas, campos, dashboards, listagem, gráficos, relatórios, mensageria
customizados. É o carro-chefe da plataforma, e geralmente o primeiro produto que o cliente
demonstra interesse em utilizar. Diferencia-se de outras ferramentas de gestão de projetos e e bugtracking por ter uma extrema capacidade de configuração e uma engine de workflow integrada flexível
para rodar qualquer fluxo de trabalho que possa ser imaginado.
Roadmaps for Jira
Módulo para planejamento ágil, permite de forma visual via drag-and-drop ao gestor de um projeto
organizar entregas, milestones, sprints, tarefas, montar as raias de um Gantt e prever ações de longo
curto, médio e principalmente de longo prazo de um projeto. Ao fazer este planejamento, mostra as
super alocações das equipes e permite fazer reorganizações facilmente a fim de acomodar o escopo
do projeto. Após isso, durante o monitoramento e controle do projeto, traz vários gráficos para
visualizar custos, horas, áreas do projeto, entre outras informações.
Módulo Workload
Traz suporte à visualização da carga de trabalho alocada para as pessoas do projeto, amparando
gerência na distribuição das demandas no dia-a-dia dos trabalhos. Permite ao gestor e envolvidos
detectar facilmente super e sub-alocações de pessoas.
Página. 12 de 34
Módulo Jira Workflow Toolbox
Adiciona dezenas de regras configuráveis sobre as funções de workflows nativas do Jira. Todas
instalações ALM Atlassian, de qualquer tamanho, se beneficiam largamente deste módulo.
Módulo JQL Tricks
Adiciona mais de 50 (cinquenta) funções avançadas para busca de informações dentro do Jira.
Essencial para montagem de dashboards avançados e filtragem de informações para gráficos e
relatórios. Filtros de informações extremamente complexos podem ser montados com este módulo.
Módulo JEMH
Caso o Jira venha ser utilizado para processamento (entrada e saída) de emails, este módulo é
essencial. Possui suporte à criação de profiles de configuração permitindo criar chamados, anexos,
comentários, movimentar workflows e preencher campos de tarefas via emails para o Jira.
Módulo Tempo Timesheets
Essencial para equipes de trabalho onde o planejamento e o controle apurado de horas é usado. Tem
ainda suporte à relatórios e categorização de horas por centro de custo ou campos customizados de
apontamento de horas. Ainda traz um avançado timesheet e capacidade de exportação de dados.
Módulo Tempo Planner
Complementa o Tempo Timesheets, permitindo fazer planejamento de horas para as pessoas do
projeto. Integrando-se naturalmente ao módulo Jira Agile, permite visualizar super e sub-alocações,
reorganizar times de projeto para acomodar a carga de trabalho e organizar a entrada e saída de
pessoas no projeto (como férias, trocas de pessoas, indisponibilidades, etc.) mantendo a organização
da carga de trabalho dentro dos parâmetros esperados para a condução do projeto.
Módulo Misc Workflow Extensions
Complementar ao Jira Workflow Toolbox, também agrega funções para regras de workflow no Jira.
Salienta-se que as capacidades de regras de workflow no Jira são o grande diferencial frente a outras
ferramentas de gestão de demandas/projetos e ter uma gama ampla de regras de workflow maximiza
o valor agregado da solução nesta área. Qualquer instalação ALM, de qualquer tamanho, se beneficia
largamente deste módulo.
Módulo Jira Agile
Essencial para equipes ágeis. Traz Quadro de Planejamento (que permite estimar e priorizar itens de
backlog), Quadro Kanban e Gráficos Burndow ao Jira, tudo isso em uma interface Web 2.0 totalmente
drag-and-drop. Tem diversos relatórios para acompanhamento da agilidade do time, como métricas de
velocidade de ciclo (sprint), orçado x realizado e acompanhamento de horas ou pontos (points)
consumidos.
Módulo IDE Connector (Mylyn)
Módulo cliente, a ser instalado sobre a plataforma EclipseIDE de cada desenvolvedor. Permite aos
desenvolvedores criar bugs, acompanhar tarefas, registrar horas, comentários, anexos e outras
operações do dia-a-dia sem ter que acessar a interface web do Jira. Para desenvolvedores Java, é
utilíssimo. É gratuito.
Módulo Profields
Caso o ambiente de gestão de projetos precise qualificar e quantificar atributos de projeto, como Tipo
do Projeto, Status do Projeto, Área de Conhecimento do projeto ou qualquer outra informação, este
módulo é essencial. Em outras palavras, ele permite criar campos customizados (data, numéricos,
texto, combos, listas, etc.) para projetos e obter gráficos e relatórios sobre estes campos.
Módulo Billing Tracking Collection
Agrega nada menos do que 30 tipos diferentes de relatórios para projetos no Jira, como
acumuladores, totalizadores, médias, gráficos (barra, pizza, linhas) e listagens. Permite ainda criar
novos tipos de relatórios (usando linguagem Velocity). Traz também um robusto e configurável
mecanismo de billing, ou seja, transformação de horas trabalhadas em valores monetários (exemplos
de uso incluem quantificar o custo de um time de desenvolvimento, de uma tarefa, de um projeto ou
de uma área de negócio, como atendimentos de suporte ou fábrica de software). É um dos mais
valiosos módulos de relatórios para o JIRA.
Módulo TeamLead
Este módulo permite visualizar as tarefa de projeto em calendarários, dando noção de alocação de
recurso por dia de trabalho. Útil quando processos de gestão bastante rígidos, que controlam os
horários das tarefas de projeto estão presentes.
Módulo Saved Filter With Columns
Complementa os dashboards do Jira, permitindo ao administrador padronizar telas de listagem da
ferramenta, a fim de minimizar o esforço de Gerência de Configuração do ambiente ALM. É perfeito
para organizar cenários de dashboards e filtros quando múltiplas equipes e formas de visualizar
informações co-existem dentro da ALM.
Módulo Zephyr
Módulo voltado à area de gestão de testes. Permite a criação de dashboards voltados ao
planejamento, execução e controle de testes sobre o Jira. Essencialmente, tarefas do Jira podem ser
interpretadas como testes e serem controladas via workflows específicos em ciclos de teste planejados
ou adhoc (ex. smoke tests). O uso deste módulo, corretamente configurado junto ao plugin
JiraCapture (abaixo), ao Enterprise Architect, ao Bamboo e Crucible, permite fazer uma gestão muito
granular de testes na plataforma ALM, rastreando completamente requisitos, código-fonte e bugs.
Módulo Capture
É um módulo a ser instalado nos browsers dos usuários finais de aplicações. Sua função é facilitar o
ciclo de identificação de bugs em sistemas. Usando este módulo, um usuário que detecta um bug em
uma aplicação web qualquer pode acionar uma tecla de atalho no browser e rapidamente criar um
bug no Jira, já anexando um screenshot do bug com um editor integrado ao browser (estilo MSPaint).
O bug criado já identifica vários dados, como usuário logado, tipo do browser, Sistema Operacional
em uso e timestamp, informações muito importantes para o processo de resolução do bug.
Módulo Servicedesk
Voltado para ambientes de ServiceDesk, HelpDesk e ITIL, onde cálculo de SLAs e relatórios de
métricas de atendimento de tempos de resposta ou de solução de chamados são necessários, este
módulo é essencial. Ele permite criar regras avançadas de cálculo de start, stop e congelamento de
SLAs, bem como criar campos diferentes de SLA e ainda com suporte à múltiplos calendários e
timezones. Relatórios diversos de acompanhamento podem ser produzidos e publicados.
Módulo nFeed
Caso o projeto exija o consumo de dados legados (databases externos), o módulo nFeed é a solução.
Ele permite conectar campos customizados do Jira em bases SQL, Webservices, arquivos XML ou CSV.
No caso de bases SQL, permite ainda criar dependências de campos, o que é muito útil para criação
Página. 13 de 34
de campos cascata em múltiplos níveis. Utilizando este módulo, o esforço para integração com dados
de outros sistemas é bastante reduzido.
Módulo Folio
O Folio é um módulo recente do Jira. Criado pelo mesmo time que criou o plugin Agile há 4 anos
atrás, ele traz o suporte ao gerenciamento de porfólios no Jira. Permite controlar orçado x realizado de
projetos, de tarefas, de equipes e de custos extras do projeto. Traz ainda análise de EVA ( Earned
Value Analysis), computando os clássicos indicadores EAC, VA, CP, , SPI, AC, PV, etc, além de diversos
relatórios gerenciais e análise de forecast de projetos e portfólios. É indicado para times que
realmente precisem de um controle apurado destes indicadores e não querem ter o esforço de
gerenciar estas métricas em outras ferramentas, como MSProject, TraceGP, Excel etc.
Módulo JavaMelody
Módulo administrativo, que permite o monitoramento avançado de várias partes do Jira, como
consumo de CPU, memória, rede, disco, banco de dados e outros recursos. É gratuito e altamente
indicado para ambientes de missão crítica.
Módulo Timesheet
É um complemento ao módulo Tempo. Não é essencial se o modulo Tempo Timesheets for utilizado,
mas para o usuário final (aquele que registra horas no dia-a-dia do Jira) possui uma interface de mais
rápido acesso, dando maior usabilidade à ferramenta.
Módulo Wings Mobile
Para usuários que querem utilizar o Jira via iPhone o Android, é o módulo cliente a ser instalado no
tablet ou celular. Permite realizar a maioria das ações sobre uma tarefa, como criar novas demandas,
atualizar campos, comentários, apontar horas, entre outras ações.
CROWD
É a ferramenta de Single Sign On da Atlassian. Interface totalmente Web, com integração Active
Directory, LDAP ou repositórios legados de usuários. Suporta padrão OpenID (o que indica que é
possível acessar redes sociais como LinkenIn, Facebook, GMail, etc. usando o próprio login
corporativo), tem alta escalabilidade e suporte à múltiplos repositórios de autenticação simultâneos
(ex. alguns usuários autenticam pelo AD, outros são “terceiros” e autenticam diretamente no Jira, etc).
Por possuir API extensível, permite que a empresa o adote como plataforma de autenticação para
seus produtos, unificando autenticação e autorização de seus sistemas em uma plataforma única e
robusta de SSO.
ENTERPRISE ARCHITECT
Ferramenta CASE consagrada no mercado, operando em plataforma Windows tem suporte completo à
UML, permite geração de documentação customizada em formato HTML ou RTF, API Java ou COM
para integração, permite modelagem de banco de dados, geração de código-fonte em várias
linguabens, suporte à tecnologia MDA para uso de cartuchos de transformação de modelos em
artefatos de projeto (código, esquemas, etc), esquema granular de permissões, permite salvamento
de informações em banco de dados, trabalho multiusuário e ampla documentação.
Plugin EA Connector for Jira
Este plugin permite que elementos modelados no Enterprise Architect (ex. Requisitos, Casos de Uso,
etc.) sejam transpostos para o JIRA e tratados neste como elementos de projeto (ex. tarefas de
projeto) e sejam evoluídos pelo time (workflow) sendo mantidos sincronizados em tempo integral com
a ferramenta CASE. Com esta abordagem tem-se 100% de rastreabilidade de elementos de
modelagem versus tarefas de projeto. Se utilizado Fisheye ou Stash na ALM, tem-se ainda a
rastreabilidade em nível de código-fonte, inclusive.
Plugin MDG Link for Eclipse
Permite integração entre o Enterprise Architect e a IDE Eclipse, onde código-fonte gerado pelo
Enteprise Architect é instantemente acessível dentro do Eclipse, e vice-versa. Ao usar este plugin, é
possível criar profiles de projetos e orquestrar o trabalho em múltiplas frentes de desenvolvimento
sem ter que estar a cada instantante reconfigurando paths de classes e pacotes, além e evitar que o
esquecimento de refreshs de código impactem em perda de edição de código-fonte.
Plugin MDG Link for Visual Studio
Idem acima, mas para plataforma .NET.
CONFLUENCE
É a plataforma de colaboração da Atlassian. Ferramenta Web 2.0 com interface amigável permite a
criação de espaços de trabalho compostos de páginas que são criadas e editadas pelo time de
desenvolvimento ou mesmo usuários finais (ex. páginas de documentação de sistema). Semelhante a
uma wiki tradicional, o Confluence excede expectativas integrando conteúdo externo, textual,
imagens, áudio, vídeo, documentos da linha Office, PDFs através de um rico editor de páginas. Os
espaços de trabalho (conjuntos de páginas) podem ser segmentados em vários níveis de permissão e
terem leioute e aparência (logo, cores, fontes, rodapés, cabeçalhos, etc.) totalmente customizáveis.
Tal como o Jira, o Confluence é projetado para ser complementado com módulos adicionais, que
trazem funções extras ao produto.
Módulo Adhoc Workflows
Este módulo permite criar workflows para aprovação de publicação de páginas no Confluence. Por
exemplo, imagine o cenário onde uma pessoa é responsável por criar páginas e outra pela aprovação
antes delas serem publicadas. Outro cenário são páginas com certos conteúdos que podem precisar
aprovações duplas (ex. supervisor e gerente) antes de serem publicadas. Também a edição de
páginas pode ser moderada. De forma simples, este módulo permite a criação de workflows diversos
com várias camadas de aprovação de páginas, aumentando a consistência das informações
veiculadas.
Módulo Team Calendars
Todos conhecem o Google Calendar. Imagine algo semelhante integrado totalmente ao seu ambiente
de páginas e projetos, mostrando agendas de pessoas, de tarefas e de entregas de projeto em uma
interface simples e funcional. É o módulo Team Calendars para o Confluence. Ele permite a criação de
agendas para pessoas e projetos, importação de agendas externas (pelo padrão iCal), e exibição de
tarefas e entregas de um projeto em uma interface limpa e amigável. Toda a operação do Team
Calendars é feita dentro das páginas do Confluence, que são compartilhadas de forma segura para o
time de desenvolvimento ou clientes finais conforme critérios configuráveis de permissões.
Módulo RefinedWiki
Por padrão o Confluence traz um conjunto de “temas” pré-definidos para configuração de leioute e
aparência dos espaços e páginas. Eles já permitem uma boa estruturação das informações.
Entretanto, com o uso do módulo RefinedWiki, as possibilidades são maximizadas. Este módulo
Página. 14 de 34
permite customizar de forma visual as cores, fontes, estrututuras de navegação e conteúdo,
cabeçalhos, rodapés e várias outras partes do Confluence através de uma interface simples e
funcional. Também permite a criação de “categorias” de espaços, o que permite agrupar áreas de
conhecimento do Confluence em partes distintas conforme a necessidade.
Módulo RefinedWiki Mobile
É o complemento do RefinedWiki que traz um conjunto de CSS e javascript especialmente
desenvolvido para maximizar a usabilidade da ferramenta através do acesso mobile.
Módulo Balsamiq Mockups
Este módulo é um designer para prototipação rápida de interfaces de usuário. Com uma interface de
fácil uso permite criar mockups (também conhecidos como wireframes) de telas de sistemas, durante
a fase de análise e modelagem. Para equipes ágeis é uma ferramenta excelente, pois analista e
usuário podem desenhar de forma iterativa as telas de um novo sistema em desenvolvimento
diretamente sobre páginas wiki do Confluence. Como o editor é online, a alteração dos mockups
também é fácil. E, se usado o módulo Adhoc (acima), evidencia-se um forte esquema de gerência de
configuração, pois as alterações no mockup (ou seja, alterações de requisitos) serão publicadas para o
programador somente após aprovação do analista ou do usuário responsável, por exemplo.
Módulo Gliffy
É semelhante ao Balsamiq Mockups, ou seja, também é um desiger visual para o Confluence. Porém,
o foco do Glify é a criação de diagramas mais genéricos. Quem conhece o MSVisio pode ter uma idéia;
imagine uma versão web do MSVisio: é o Gliffy. O Gliffy permite criar figuras e diagramas diversos,
como UML, de rede, gráficos, prototipar telas ou qualquer outro tipo de diagrama que envolva figuras
geométricas.
É o novo produto da Atlassian (lançado em 2012) e sem similares no mercado. É um gerenciador web
para repositórios Git. Integrado ao Crowd, permite autenticação de usuários e autorização de acesso
extremamente granular. Permite criação de repositórios, definição de permissões, criação de branches,
tags e outras operações em interface web 2.0 amigável. Se a empresa optar por pelo uso de
repositórios versionados distribuídos (DVCS), o Stash é sem dúvida alguma o melhor produto de
mercado para isso.
STASH
Módulo SourceTree
É um módulo cliente, gratuito, a ser instalado nos computadores de cada usuário do Stash. Permite
realizar os commits, analisar log, operações de push, pull e outras ações típicas de desenvolvimento.
Possui uma interface limpa e funcional, com versões para Windows, Linux e MacOS. Para equipe que
utiliza IDEs como o Eclipse que possuem plugins próprios para trabalhar com o Git, este módulo é
supérfluo.
FISHEYE
É a ferramenta de indexação, pesquisa, visualização e comparação de artefatos versionados da
Atlassian. Suportando repositórios CVS, Subversion, Perforce, Git e Mercurial, permite localizar
facilmente itens versionados nos repositórios da empresa. Como o Fisheye opera integrado ao Jira,
quando um commit é realizado e na mensagem deste a chave da tarefa de projeto é informada,
fecha-se o ciclo de rastreabilidade da solução ALM. Em outras palavras, como os modelos do
Enterprise Architect estão conectados com o Jira (via plugin EA conector for Jira), eles agora são
rastreados com os respectivos código-fontes comitados no repositório versionado. Rastreabilidade
total, desde os modelos até o código-fonte.
CRUCIBLE
É a ferramenta para revisão de código-fonte da Atlassian. Operando de forma integrada ao Fisheye,
na mesma interface web, permite que trechos de código-fonte, ou classes ou arquivos inteiros, ou
mesmo changesets inteiros sejam marcados para revisão. Cada revisão pode operar em formato ágil
(com workflow menor para ser finalizada) ou mais tradicional (com workflow que exige uma
aprovação antes de ser finalizada). O time pode trabalhar colaborativamente sobre as revisões em um
clássico estilo de “fórum de discussão”, onde trheads podem ser montadas discutindo cada revisão em
andamento. Como o Crucible ainda está integrado ao Jira, é possível a montagem de workflows no
Jira que sejam bloqueados (ex. uma tarefa de programação) até que a revisão de código associada
seja aprovada.
BAMBOO
É a ferramenta de Integração Contínua da Atlassian. Com uma arquitetura altamente escalar e
componentizada, permite a criação de builds segmentados em partes e que podem ser distribuídos em
vários servidores. Possui sistema de notificação customizado, permissão avançada, publicação de
artefatos de builds, dependências entre builds e geração de relatórios. Como está integrado ao
Fisheye, Crucible e Stash, ele condensa nos builds todas informações de rastreabilidade, como tarefas
de projeto que fizeram parte do build, revisões de código associadas e commits envolvidos. Da mesma
forma que o Crucible, pode ser integrado aos workflows do Jira e evitar que tarefas de projeto (ex.
Programação) sejam dadas como finalizadas se existir algum build associado quebrado. Uma vez que
o Bamboo é neutro em relação à tecnologia de build, ele permite trabalhar com scripts de console,
Ant, Maven, NBuilder ou qualquer outra tecnologia que a equipe utiize para compilar, analisar, testar,
empacotar ou distribuir aplicações. Como o Bamboo também permite uso de extensões, ele pode ser
conectado em servidores externos, como Sonar (geração de métricas de desenvolvimento) ou Nexus
(publicação de artefatos). Ainda, como possui integração com o módulo IDE Connector, ele permite
disparo de processos de build através da IDE Eclipse. Finalmente, quando integrado ao Stash e
usando o “desenvolvimento por branches”, ele possui um sistema exclusivo de criação, autoconfiguração, disparo, execução e apagamento de builds, algo sem similares em nenhuma ferramenta
de builds da atualidade. Vale a pena olhar todos os vídeos deste módulo no website da Atlassian antes
de pensar em utilizar ferramentas como Hudson, Jenkins, CruiseControl ou outras.
CLOVER
É a solução da Atlassian para análise testes de cobertura. Com o Clover são identificados os pontos
fracos no código-fonte de um sistema, como relação entre classes e métodos mais utilizados versus
quantidade de testes associados a eles, métricas de complexidade algorítimica, de tamanho de código
e outras análises que buscam minimizar os riscos sobre estruturas de código-fonte de uma aplicação.
O Clover está disponível para uso sobre linguagens Java e Groovy. Integrado ao Bamboo, ciclos de
build podem executar ações do Clover durante o processo de Integração Contínua. Por fim, o Clover
pode ser executado de forma standalone, dentro das IDEs Eclipse dos desenvolvedores. Um Caso de
Uso muito interessante do Clover + Bamboo é dado pela NASA (agencia espacial americana) com os
Página. 15 de 34
robôs que foram lançados para o planeta Marte. Todos os ciclos de teste de solidez do código-fonte
desses robôs foram amparados pela suíte Atlassian.
4.4 Termos e Conceitos na ALM Atlassian
Como exposto, uma solução ALM é uma plataforma ampla, com vários termos, conceitos, nomes, siglas que
precisam ser corretamente entendidas pelos envolvidos a fim de evitar dúvidas de contratação e uso.
No cenário Atlassian, os principais itens do vocabulário são mostrados abaixo:
TABELA 2 – Termos e conceitos comumente utilizados no cenário ALM Atlassian.
TERMO / CONCEITO
SIGNIFICADO
ATLASSIAN
É a fabricante da ALM que contém softwares como o JIRA e outros. É líder mundial neste segmento, e em franca
expansão. No Brasil ainda está crescendo, mas já presente em centenas de organizações de vários tamanhos e nichos
de mercado.
3LAYER TECNOLOGIA
É uma das revendas autorizadas Atlassia no Brasil. Possui milhares de horas em consultoria em implantação ALM e
outros projetos. Com sede em Porto Alegre e pontos de atendimento em São Paulo e Florianópolis, atende clientes de
todos os portes e nichos em todo o Brasil.
Conceito de PRODUTO
É formalmente um produto da solução ALM, que pode ser utilizado isoladamente (conceito White Box) na sua
completude. Os produtos Atlassian são: JIRA, Confluence, Stash, Fisheye, Crucible, Bamboo, HipChat, Clover, Crowd,
SourceTree. Os produtos de fornecedores externos abordados neste documento são Subversion e Enterprise Architect.
Conceito de MÓDULO
Também chamado de Plugin ou Addon, é um complemento, uma extensão dentro de um produto. Não pode ser
utilizado isoladamente; precisa ser usado dentro de um produto. Serve para adicionar funcionalidades dentro de um
produto para atender mais adequadamente um determinado nicho de negócio ou função. Existem módulos para
diversos nichos, como para para o gerenciamento de projetos, para o tratamento de SLAs/ITIL/HelpDesk, para a
documentação, para a comunicação, para regras de workflows, para adicção de funcionalidades em telas/campos,
para a gestão de horas, para relatórios, para dashboards, para a integração com código-fonte/IDEs, para a publicação,
para uso de áudio/mídia, para incremento da segurança/auditoria, para o monitoramento dos produtos, etc. De fato,
existem atualmente mais de 500 módulos disponíveis à venda no Marketplace, alguns da Atlassian e outros de
diversos fornecedores no mundo. Entre eles cita-se: Jira Agile, ServiceDesk, EA Connector for Jira e nFeed.
NOTA: De especial atenção neste ponto para a seleção correta de quais módulos são ao mais indicados para um
projeto de implantação ALM é a presença de um especialista, um expert Atlassian, como a 3layer Tecnologia, junto ao
seu projeto.
EXPERT
É toda e qualquer revenda autorizada Atlassian, formalmente apta a vender licenças e dar suporte e consultoria em
projetos. Cada expert pode oferecer serviços diferenciados, como Treinamento, Consultoria, Desenvolvimento de
Plugins e Infraestrutura de serviços Atlassian. Alguns experts, como a 3layer, trabalham com todos os serviços
Atlassian. A lista de experts Atlassian no mundo está disponível no endereço eletrônico:
https://www.atlassian.com/resources/experts, filtrando por país ou área de especialidade.
PLATINUM EXPERT
É o expert que atingiu um limite mínino de vendas de licenças no ano fiscal da Atlassian. Em nível qualidade ou
experiência em serviços, um parceiro Platinum não tem diferença alguma de um expert normal. Essa informação
precisa ser analisada pelo cliente na hora da filtragem para escolhar o parceiro, ou seja o Expert que vai lhe ajudar na
implantação ALM, sob pena de excluir parceiros que podem atender melhor suas expectativas mesmo não sendo um
parceiro expert platinum.. A 3layer Tecnologia não é ainda parceira Platinum, mas está buscando alcançar essa meta
comercial em 2014.
ENTERPRISE EXPERT
É o expert especializado em serviços avançados de implantação, cobrindo cenários complexos da ALM. Para obter este
“selo”, o Expert precisa atender diversos requisitos do fabricante Atlassian, evidenciando capacidade plena com Cases
de Sucesso sedimentados, provas de qualificação técnica do seu time de consultores, fluência para atendimento de
cenários críticos e capacidade operacional para atender clientes grandes. Em início de 2014 a 3layer Tecnologia iniciou
este processo de qualificação, que visa ser finalizado no terceiro trimestre deste ano. Não existe ainda nenhum
parceiro Enterprise Expert no Brasil.
MARKETPLACE
É o canal de vendas online de produtos e módulos da Atlassian. Permite ao cliente adquirir diretamente os produtos
Atlassian, sem intermediários e com pagamento via remessa bancária ou cartão de crédito para o exterior. Está em
franco crescimento, com mais e mais módulos disponíveis para a compra a cada semana.
NOTA: Observe que devido legislação tributária do Brasil, quando o cliente final (ex. você) adquire licenças
diretamente do Marketplace é necessário realizar o pagamento de Importo de Renda (~15%) sobre os valores do site,
além da regularização da importação do software, uma vez que a Atlassian não emite Nota Fiscal direta para o cliente
final.
ATLASSIAN UNIVERSITY
É um programa de treinamento online e gratuito da Atlassian. Nele, um website com conteúdo estruturado de
informações permite ao usuário iniciante em um produto ou módulo (apenas os produtos e módulos da Atlassian estão
disponível, e não os de outros fabricantes) aprender os conceitos básicos de uso da ALM. Disponível em:
https://university.atlassian.com
MY ATLASSIAN
É a área do cliente Atlassian. Um espaço online e seguro que usuários Atlassian têm para gerenciar suas licenças e
trocar informações com outros usuários Atlassian, via fóruns de discussão. Disponível em http://my.atlassian.com
COMPRA DIRETA
É o ato de comprar licenças Atlassian diretamente pelo Marketplace. Qualquer pessoa ou empresa pode fazer isso.
Entretanto, conforme já exposto, devido políticas tributárias brasileiras, é importante salientar que essas operações
representam remessa de valores ao exterior, e por isso são passíveis de tributação direta, como Imposto de Renda
Página. 16 de 34
(~15%) sob o preço anunciado no site, além de exigir a regularização do software importado na Receita Federal.
Quando é realizada uma compra direta do site Marketplace da Atlassian, todos estes tramites são de responsabilidade
do próprio comprador, onde os Experts não se envolvem. Por não haver emissão de Nota Fiscal da fabricante Atlassian
neste formato, entidades de Governo não podem fazer esta compra, pois as leis brasileiras exigem tanto este artefato,
quanto canais de suporte nativo no Brasil para atendimento em casos de problemas com o software.
COMPRA POR REVENDA
É o ato do cliente realizar a compra de licenciamento através de uma revenda, ou seja, de um Expert. Neste caso, a
revenda adquire o software da Atlassian e entrega as chaves de licenças ao cliente final mediante a emissão de uma
Nota Fiscal para o cliente. Neste caso, haja visto que as leis brasileiras sobre software ainda são precárias, não existe
consenso jurídico único se licença de software é um produto ou serviço e assim, cada Expert ao emitir a Nota Fiscal
pode fazê-lo via NF de Serviço (passível de ISS, por exemplo) ou NF de Produto (passível de ICMS, por exemplo),
gerando diferenças, por vezes, significativas no preço final. De qualquer forma, para órgãos de Governo, é o caminho
natural para aquisição de licenças e serviços Atlassian mediante, um edital de compra o carta-convite.
LICENCIAMENTO ACADÊMICO
Para entidades sem fins lucrativos, geralmente acadêmicos ou de pesquisa, a Atlassian oferece licenças com 50% de
desconto em relação ao preço de tabela do Marketplace. Porém, uma comprovação jurídica é necessária, conforme
termos disponíveis em: https://www.atlassian.com/survey/classroom-license-request . Importante salientar que nem
todos os outros fabricantes de módulos da ALM oferecem este benefício, então é imprescindível analisar cada módulo
a ser utilizado na ALM.
LICENCIAMENTO OPENSOURCE
Projetos sem fins lucrativos e abertos ao público podem utilizar licenças gratuitas da Atlassian, de todos os seus
produtos e módulos. Fabricantes presentes no Marketplace também oferecem este modelo, mas nem todos. Para
saber mais, acesse: https://www.atlassian.com/software/views/community-license-request
LICENCIAMENTO ENTERPRISE
Quando as licenças possuem mais de 500 usuários, a Atlassian oferece o modelo de licenciamento Enterprise que
oferece benefícios como suporte 24x7 por telefone (em inglês), acesso a treinamentos gratuitos, área avançada de
treinamentos dentro do Atlassian University, acesso a conteúdos exclusivos de documentação, workshops (via
Internet) avançados com técnicos da Atlassian e um TAM (Tecnical Account Management) que é um ponto de contato
único entre o cliente e a Atlassian, melhorando a comunicação entre o cliente final e a fabricante.
LICENCIAMENTO INICIAL
É a compra inicial das licenças Atlassian. Uma vez adquirida das licenças, o software Atlassian é de uso perpétuo (tal
qual como um MS Windows ou um MS Office). O licenciamento inicial pode ser feito para 12, 24 ou 36 meses, e
durante este período, existe o suporte do fabricante (via Internet ou telefone no caso de licenças Enterprise) e a
garantia do direito à atualização do software caso uma nova versão venha ser lançada. O roadmap dos produtos e
módulos da ALM ocorre entre 3 e 6 meses, geralmente, o que indica que, de forma geral, duas atualizações estão
para o cliente.
RENOVAÇÃO DE LICENCIAMENTO
Quando o licenciamento inicial vence o cliente é convidado a fazer a renovação do licenciamento. Se ele optar por
isso, o investimento é geralmente 40% ou 50% do licenciamento inicial, e habilita o cliente a continuar usando o
suporte e o direito a novos upgrades. Caso o cliente não faça a renovação do licenciamento, o software continua
funcionando, mas sem suporte nem direito a upgrades.
UPGRADE DE LICENCIAMENTO
É o ato do cliente estar utilizando uma faixa de usuários e decidir aumentar esta faixa para um nível maior. Por
exemplo, o cliente pode ter uma licença de 100 usuários e decidir fazer um upgrade para 500 usuários ou então 2.000
usuários. Neste momento, o cliente deve realizar uma nova compra para o número de usuários desejados, onde vai
realizar o pagamento apenas da diferença de valores entre sua licença atual e nova. Uma vez realizado o upgrade, a
licença anterior é desativada, não sendo mais passível de utilização. O ato inverso, de possuir uma licença maior e
decidir pela sua redução é chamado Downgrade.
ON DEMAND
É a nuvem de serviços da Atlassian. É uma opção de baixo custo para o cliente utilizar as soluções Atlassian sem ter
que investir em hardware, espaço e pessoas para administrar uma infraestrutura de servidores. Conhecido como SaaS
(Software as a Service), é tendência no mundo. Porém, importante salientar que nem todos os produdos Atlassian
podem ser utilizados na nuvem e, por esta nuvem estar dispersa no globo, sanções legais podem ser aplicadadas sob
os dados. Por exemplo, órgãos militares ou judiciários podem ter restrições a salvar dados de cidadãos ou do Governo
fora do país de origem, como o Brasil. Conhecer a legislação de seu órgão neste momento e os limites da nuvem da
Atlassian é questão primordial para escolher a forma de implantação ALM.
DICA: Outra opção, caso o cliente tenha interesse em utilizar SaaS e a nuvem da Atlassian não oferecer todos os
recursos desejados é contatar empresas que oferecem nuvens particulares, onde o software ALM pode ser instalado. A
3layer Tecnologia, por exemplo, tem CASEs de sucesso nessa linha, tendo montado ambientes de nuvem utilizando
plataforma Amazon para clientes que operam em mais de 15 países simultaneamente.
ANSWERS
É o fórum de discussão online e aberto da Atlassian. Uma área de perguntas e respostas extremamente ativa.
Acessado em https://answers.atlassian.com
LICENÇAS DE U$ 10,00
É o nível mais básico de licenciamento da plataforma Atlassian, onde os produtos e módulos são vendidos pelo preço
simbólico de U$ 10,00 (dez dólares) para um limite de até 10 (dez) usuários. É a forma da Atlassian garantir que 100%
de seus usuários tenham licenciamento e suporte garantidos, diferente de modelos Open Source, onde um software
gratuito não tem suporte de nenhum fabricante. De especial interesse ao leitor neste ponto é saber que 100% do
valor obtido com este tipo de licenciamento é revertido para fins sociais, onde em 2012, U$ 2 milhões foram
destinados à doações para entidades não governamentais pela Atlassian no mundo.
NÚMERO DE USUÁRIOS
Define a faixa de licenciamento dos produtos e módulos da ALM Atlassian. Atualmente, as faixas de licenciamento são:
até 10, até 25, até 50, até 100, até 500, até 2.000, até 10.000 e Mais de 10.000 usuários. Quando o cliente opta por
implantar a solução Atlassian, ele deve escolher uma dessas faixas de licenciamento. Outro ponto importante aqui é
que o conceito de “usuário” na ALM Atlassian é qualquer usuário que acessa um produto via uma conta de usuário
(login). Em outras palavras, não existe diferença entre um usuário interno (técnico) ou usuário externo (cliente final)
ou um administrador (admin).
Página. 17 de 34
PARTE 2
5 A CONTRATAÇÃO ATLASSIAN NO GOVERNO
Os capítulos anteriores contextualizaram a solução ALM Atlassian e os principais elementos envolvidos no seu
cenário, enfatizando a importância da presença de um revenda, ou seja, um Expert, no apoio na caminhada de
implantação desse ferramental.
Neste capítulo agora é mostrada uma sequência de passos que pode ser utilizada para implantação ALM Atlassian
no Governo, a qual é baseada na compilação de materiais, estratégias, movimentos, ações e práticas já realizadas
pela 3layer Tecnologia, e que são considerados casos de sucesso sempre sob a luz da Lei 8.666 de Licitações e
Contratos da Administração Pública.
Cada seção abaixo cobre um momento diferente da implantação, conduzindo uma sequência de ações desde o
lampejo da necessidade inicial até o processo de renovação anual da solução ALM Atlassian.
5.1 A Necessidade
Diferentes eventos motivam o interesse em uma suíte ALM, como a oferecida pela Atlassian, entre eles:

Sistema internos ou de terceiros utilizados para o controle de demandas, de projetos e de documentos
não atendem mais as necessidades atuais ou previstas dos setores, departamentos e áreas;

Uma nova diretoria, gerência ou coordenação assume uma área e deseja renovar o parque instalado com
software mais robusto e atualizado, buscando maior excelência nos controles realizados;

Normas externas precisam ser seguidas a fim de manter ou evoluir a organização, como implantação do
Processo MPSbr, CMMI, ISSO, ITIL, COBIT, entre outros;

Outro órgão do Governo já vem utilizando a solução, a qual também se mostra adequada à repartição,
que deseja implantá-la para também usufruir de seus benefícios;

Soluções atuais em Software Livre, embora com custo de licenciamento zero, se mostram por demais
onerosas (gerência de configuração, ações manuais, falta de suporte de um fabricante, ausência de
documentação, etc.) e precisam ser subistuídas por uma plataforma comercial;

Soluções criadas internamente (software caseiro, planilhas eletrônicas, gerenciamento via emails, etc.)
não atendem mais a crescente demanda, ao mesmo tempo em que as áreas tornam-se reféns de equipes
internas, sempre indisponíveis para um suporte pró-ativo e evolução;

O fornecedor da solução ALM atual não dá mais o suporte necessário, nem mais agrega valor ao negócio,
tornando negativa a relação custo-benefício da plataforma em uso;

Os produtos em uso não escalam para o número de usuários ou de dados desejado;

Os mecanismos de controle de acesso, segurança e integridade de dados exigem um produto mais
robusto, a fim de preservar as informações sigilosas e consistentes;

Existem vários sistemas independentes que atendem necessidades pontuais, porém não existe sinergia
nem integração entre eles; Não ocorre o ciclo ALM aqui.
 Muitos outros.
Como exposto, muitos cenários podem fomentar o desejo de uma solução ALM, na amplitude que for.
Independente de quais sejam eles, a pedra fundamental foi lançada, e um movimento de resposta deve ser dado.
Página. 18 de 34
5.2 O Levantamento Inicial
Identificada a necessidade, um responsável deve assumir o projeto nascente. Geralmente, uma pessoa da área
técnica, como um Analista de Sistema ou um Gerente/Gestor de Projetos é a pessoa que se encarrega disso.
Independente do cargo, a pessoa que assume esta tarefa de levantamento inicial deve ter competência na área
de diálogo com as pessoas que vão utilizar o produto final e alguma experiência anterior em softwares ALM é bemvinda também. Ter tempo para o envolvimento no dia-a-dia que vai ser o projeto de implantação ALM e a
perseverança de avançar e conduzir todos os próximos passos com calma também são requisitos importantes.
Neste momento de levantamento inicial, o objetivo é angariar o máximo de informações para o projeto, a fim de
definir o escopo em abrangência da necessidade inicial. Abaixo, algumas informações que precisam ser levantadas
aqui:
5.2.1 Produtos ALM Atlassian
É importante ter conhecimento, pelo menos básico, sobre os produtos e módulos que compõem a ALM Atlassian.
Ver algumas telas funcionando (mesmo em vídeo), conhecer algumas funcionalidades, entender o vocabulário
básico são ações primárias para quem vai conduzir o projeto ALM dentro do órgão do governo.
Assim, se a pessoa responsável não conhece nada sobre ALM Atlassian, a dica mais rápida para fazer uma
imersão inicial é ler as páginas de Overview dos produtos Atlassian e os assistir os vídeos introdutórios de cada
ferramenta. Abaixo os endereços eletrônicos para acesso rápido a este material:
 JIRA: https://www.atlassian.com/software/jira
o Módulo Agile: https://www.atlassian.com/software/jira/agile
o Módulo Service Desk: https://www.atlassian.com/software/jira/jsd
o Módulo Capture: https://www.atlassian.com/software/jira/capture

Confluence: https://www.atlassian.com/software/confluence
o Módulo Questions: https://www.atlassian.com/software/confluence-questions
o Módulo Team Calendars: https://www.atlassian.com/software/confluence/team-calendars
o Módulo Sharepoint Connector: https://www.atlassian.com/software/sharepoint-connector/overview

Stash: https://www.atlassian.com/software/stash
 Fisheye: https://www.atlassian.com/software/fisheye/overview
 Crucible: https://www.atlassian.com/software/crucible/overview
 Bamboo: https://www.atlassian.com/software/bamboo
 Crowd: https://www.atlassian.com/software/crowd/overview
 HipChat: https://www.atlassian.com/software/hipchat
De cinco a dez minutos para olhar cada link são suficientes para entender o objetivo de cada ferramenta. Então,
em menos de duas horas é possível entender todo o circuito de ferramentas essenciais da ALM.
Explore elas. Não deixe de fazê-lo.
5.2.2 Stakeholders
Importantíssimo é identifcar, pelo menos, os seguintes perfis que serão necessários durante todo o projeto, e
ainda depois durante sua operação continuada manter contato e participação ativa deles. São eles:

Patrocinadores: Quem é o órgão, diretoria, gerência, coordenação ou afim que é o responsável pela
aprovação do orçamento para o projeto. Garantir que vai existir verba disponível para o projeto (e neste
momento de quantidade ainda desconhecida) é importante desde já. Uma resposta negativa neste
momento evita muito trabalho perdido. Uma resposta inconclusiva vai derivar para um estudo mais
detalhado, o que é explorado neste texto. E uma resposta positiva, de que qualquer montante pode ser
angariado (o que é pouco provável) pode facilitar a jornada, mas não exime um amplo embasamento,
Página. 19 de 34
haja visto a Lei 8.666 exigir a transparência e legitimilidade de todos os custos do projeto. Então, quem
tem a caneta para a rubrica é a pessoa-chave a ser localizada e convencida. E é a primeira pessoa da lista.

Usuários Líderes: Uma vez que a solução ALM pode abranger muitas áreas, eventualmente muitas
pessoas podem ter voz ativa no momento de definir os requisitos e de aprová-los. Escutar todas as
pessoas afetadas pode ser inviável. Então, a melhor estratégia é identificar quem são os multiplicadores
de conhecimento, o que é chamado aqui de usuários-líderes, aqueles nos quais as grandes massas se
apoiam. Se o seu órgão for dividido em vários deparatamentos, áreas, etc, ter um representante de cada
uma delas pode ser uma boa prática. Conversar com essas pessoas, abrir um canal de comunicação fluído
desde o início e enfatizar a importância da participação delas em todo o cenário é de suma importância.
Sem usuários líderes interessados, os requisitos são mal definidos. Requisitos mal definidos não são
homologados. E requisitos sem homologação derivam para usuários insatisfeitos, projetos sem entrega e
problemas comerciais e jurídicos com o fornecedor da ALM, inevitavelmente.

Product Owner: Independente da quantidade de usuários-líderes, até talvez um deles, deve assumir o
papel de Dono do Projeto ou Dono do Produto, do inglês Product Owner. Esta pessoa é figura
fundamental no projeto. Ela vai garantir um ordenamento das prioridades entre os vários usuárioslíderes, dar report constante ao Patrocinador, interagir com o gerente de projetos do fornecedor,
remover impedimentos no seu lado (financeiros, administrativos, humanos, etc.). Enfim, deve zelar
incessantemente pelo sucesso do projeto. O Product Owner é o representante oficial de todos os
usuários líderes do projeto. Talvez, você que esteja lendo este documento agora seja esta figura.
Eventualmente, um gerente de projetos pode ser alocado pelo lado do cliente, ou seja, pelo órgão de governo a
fim de apoiar a gestão da implantação que deve ocorrer pela consultoria, ou seja, o Expert. Porém, isso não é
necessário, uma vez que a consultoria geralmente provê este recurso para o projeto, onde ele trabalha diretamente
com o Product Owner organizando a fila dos trabalhos (backlog) e quaisquer outros itens do projeto.
5.2.3 Áreas Envolvidas
Da mesma forma que identificar as pessoas, identificar quais são as áreas envolvidas no projeto, sejam como
demandantes ou como afetadas é de suma importância.
Um grande erro que ocorre na implantação de projetos ALM é subestimar o interesse de áreas vizinhas ou
envolvidas na cadeia do processo, ou seja, aquelas que vêem antes, depois, acima e abaixo da área principal do
projeto. A experiência da 3layer Tecnologia mostra que muitos projetos poderiam ter sido melhor desenvolvidos se
esta sinergia, este interesse múto, tivesse disso identificado desde o levantamento inicial. Quando isso não ocorre, é
comum que a implantação que fora bem sucedida em uma área, com planejamento, qualidade e consistência seja
copiada inadvertidamente, sem muitos critérios, para uma área vizinha, com a esperança que ela também funcione
lá. Ledo engano, pois cada área têm suas necessidades específicas, e são os detalhes que fazem a diferença quando
se trata de ALM. É imprescindível, ajustar, tunar, os requisitos da ALM para cada área interessa. Somente assim a
condição de sucesso do projeto é alcançada.
Assim, neste momento, disparar um email interno comunicando o assunto e solicitando uma reunião para
apresentar a idéia à outras áreas pode ser uma iniciativa fácil, rápida e efetiva.
De forma geral, quanto mais áreas envolvidas, maior será a visibilidade do projeto, e mais facilmente pode ser
alcançada a massa crítica para fazer o projeto acontecer.
Pontuar os itens dessa reunião de áreas em uma ata, e garantir o repasse dela à todos, bem como um tempo de
sedimentação para a coleta de feedback pode ajudar a garantir que nada e nenhuma área fora esquecida. Guarde
esta ata, ela será necessária nos próximos passos.
Por fim, certique-se que o patrocinador do projeto tenha ciência do seu conteúdo.
Página. 20 de 34
5.2.4 Soluções Atuais
Ao juntar diferentes áreas, setores, departamentos, repartições ou grupos de trabalho é provável que mais idéias
e propostas de soluções apareçam. Muitas delas possivelmente já estão em uso e implementadas em algum
software que pode até ser desconhecido por outras áreas e pessoas até então.
Explorar as soluções em uso atualmente é importante, de forma garantir que os anseios por uma nova solução
ALM sejam consistentes. Neste momento, a tabulação das informações pode começar a ser feita, em uma planilha
simples ou Matriz SWOT (de forças e fraquezas) para os produtos em uso na casa. Esta estruturação vai ajudar a
garantir que os recursos de interesse (as forças) dos softwares/soluções atuais sejam preservados, e que as
deficiências (fraquezas) sejam corrigidas/minimizadas com o novo software ALM.
A tabela abaixo mostra um exemplo de como a tabulação das soluções atuais (sejam implementadas em software
ou operadas manualmente) pode ser feita:
TABELA 3 – Modelo para identificação das soluções atuais para o projeto ALM.
Solução
Visão Geral
Usos
Pontos Positivos
Pontos Negativos
Oportunidades
Mais Informações
Nome
do
Sistema ou
da
Forma
Tal de fazer
algo hoje
Um ou dois parágrafos
descrevendo a
solução/sistema existente
para atender a
necessidade
Exemplos de
uso da
solução; as
principais
coisas que ela
faz
Características boas
na solução, que
todos gostam e que
deveriam ser
preservadas
Características ruins ou
vícios, limitações,
problemas, coisas que
devem ser sanadas
com a nova solução
Idéias de como
pontos negativos
poderia ser
corrigido, dicas,
sugestões de como
sanar os
problemas
Links, figuras, exemplos,
materiais complementares
que descrevem em
detalhes esta solução,
enfatizando figuras e
descrições que cubram os
pontos positivos, negativos
e as oportunidades sempre
que possível
Um exemplo prático disso pode ser visto no ANEXO 1. Nele, é mostrada uma planilha que fora montada durante a
escrita do Documento de Visão de um projeto de implantação ALM Atlassian. Observe que ela evidencia claramente
quais softwares e soluções estão sendo ou serão afetados pela implantação da nova ALM.
Se seu Termo de Referência (discutido adiante) já conter esta planilha como anexo, será um diferencial valioso
para o seu projeto.
5.2.5 Necessidades, Prioridades e Prazo
Com a matriz de soluções atuais contendo propostas de melhoria, é o momento de priorizar os itens. Assim como
prega o Framework Scrum, é importante ter uma única lista de referência com as necessidades para o projeto, ou
seja, o Backlog. Este backlog deve ser uma lista priorizada, com somente um item 1, somente um item 2, somente
um item 3 e assim sucessivamente. Ao ordenar as necessidades por prioridade, se garante que o orçamento do
projeto seja aplicado nos itens mais importantes primeiro. Se o dinheiro acabar antes de (ou não for suficiente para)
executar todos os itens da lista, os itens mais importantes terão sido satisfeitos. E qual a forma mais rápida de
unificar as necessidades de todas as pessoas em todas as áreas em uma única lista? O algoritmo abaixo pode ajudar
nisso:
1. Peça que cada pessoa em cada área faça uma lista pessoal priorizada de todas as suas necessidades;
2. Cada gestor em cada área, reúne as pessoas de sua área e unifica estas listas pessoais em uma única lista
priorizada, ou seja, a lista priorizada da sua área;
3. O Product Owner do projeto (quem sabe você!) reúne os gestores de cada área, e as listas priorizadas de
cada área são unificadas em uma única lista priorizada, ou seja, a lista priorizada do projeto.
4. Ao fim, todos os itens, de todas as pessoas em todas as áreas estão em uma única lista priorizada, sem
conflito de prioridades.
Guarde esta lista, ela representa a unificação das necessidades.
Uma questão natural que surge a partir do Backlog é quanto tempo ele levará para ser construído? Neste
momento, ninguém sabe. Não foram feitas estimativas. E também não foram feitos detalhamentos exatos de cada
uma das necessidades levantadas.
Página. 21 de 34
O que pode ser discutido aqui é se o projeto tem alguma data pré-concebida, como um regulamento jurídico,
uma legislação que deve entrar em vigor ou alum evento inadiável, como Olimpíadas, data-limite para declaração do
Imposto de Renda ou Eleições, por exemplo. Neste caso, esta informação de prazo é importante, e deve ser anexada
junto à pasta de documentação do projeto.
5.2.6 Número de Usuários
Outro fator importante no cenário ALM é o número de usuários, ou seja, de pessoas que vão utilizar a solução.
No cenário ALM Atlassian, como exposto na TABELA 2, o licenciamento da plataforma ocorre por faixas de usuários,
que podem variar entre até 10, até 25, até 50, até 100, até 500, até 2.000, até 10.000 e ilimitado. De suma
importância, então, é identificar quantas pessoas devem utilizar a solução a curto, médio e a longo prazos.
O cenário de curto prazo diz respeito ao momento do piloto do projeto, ou seja, dos testes iniciais para a
homologação. Iniciar com um piloto de implantação em uma ou duas áreas/departamentos/setores apenas é uma
prática comum, abrangendo poucos usuários. Assim, mensure quantos seriam os usuários envolvidos neste
momento. Dica: A sua lista de prioridades pode ajudar nisso, pois os primeiros itens da lista estão relacionados
diretamente aos respectivos usuários envolvidos.
O cenário de médio prazo é a operação a pleno vapor, com a plataforma rodando em todas as áreas que
demonstraram interesse na solução (Seção 5.2.3). Este deve ser o número mínimo de usuários a ser licenciado ao
solicitar as cotações de licenças para a suíte ALM Atlassian.
O cenário de longo prazo pode ser a perspectiva, geralmente após mais de um ano de uso da solução, de quais
outras áreas podem vir a utilizar a plataforma. São as áreas que demonstraram vago interesse na solução nos
levantamentos iniciais e não quiseram entrar na primeira leva de implantação, mas sim aguardar os resultados das
áreas mais inovadoras para tomar sua decisão. Provavelmente, quando a plataforma ALM for renovada, o número
de usuários deve aumentar para cobrir também estas áreas, e um projeto serviços para evolução do ambiente
instalado deve ser feito aqui, ou seja, um novo Edital de Serviços, ou então fazer uso de um contrato de suporte
(Seção 5.11 e Seção 5.12), por exemplo.
Reforçando, no tocante ao licenciamento, que é balizado pelo número de usuários (logins), o projeto deve ser
dimensionado para o cenário de Médio Prazo. É este o volume do orçamento que deve ser pleiteado junto ao
patrocinador. Orçamento a menos vai criar restrições na implantação e “jeitinhos” de fazer as coisas, como usuários
compartilhados (conhecidos também como “usuários genéricos”) ou pior ainda, liberação de acesso anônimo.
Qualquer uma delas vai impactuar negativamente no uso dos produtos causando transtorno às pessoas por vários
motivos1. Orçar a valores a mais para licenciamento, encarece o projeto desnecessariamente, pois não serão
utilizadas estas licenças extras num primeiro momento. Neste caso, se existir verba disponível, guarde ou direcione
este dinheiro para utilizar em serviços de implantação e suporte do expert que vai atendê-lo.
Então, neste momento, é importante ter este dimensionamento já calculado. Esta pergunta será uma das
primeiras que o Expert, ou seja, a revenda Atlassian vai fazer à você.
Como saída neste momento, tenha três números:

Número de Usuários a Curto Prazo (Fase de Piloto);

Número de Usuários a Médio Prazo (Uso a Pleno Vapor);

Número de Usuários a Longo Prazo (Possiblidade de Expansão Após Um Ano).
5.2.7 Processos
Identificadas as áreas, pessoas e necessidades, é imporante caracterizar um pouco o aspecto dinâmico da ALM,
ou seja, quais são os principais processos envolvidos junto às necessidades mapeadas.
1
Alguns exemplos de problemas ao liberar acesso anônimo, mesmo em Intranets: Perda de rastreabilidade da informação,
vazamento de informações, dashboards não otimizados para uma determinada pessoa (poluição visual), refatoração de
configurações desnecessária quando o licenciamento for ajustado para a volumetria correta, Workflows ineficientes, entre
outros.
Página. 22 de 34
Novamente, um formato de planilha simples ajuda, como o exemplo abaixo:
TABELA 4 – Exemplo fictício de tabulação de processos de alto nível.
Necessidade
Visão Geral
Processos Envolvidos
Pontos Importantes
Controlar o
Atendimento de
Demandas de
Usuários no
Helpdesk
Existe uma área de helpdesk que atende
chamados diversos de manutenção de
impressoras, equipamentos, etc e também
sobre atende pedidos de manutenção e
suporte de sistemas internos. Os chamados
vêem de usuários diversos e são priorizados
pela gerência, e depois vão para as áreas fins
de atendimento. Algumas regras de SLA
existem, mas precisam ser melhoradas.
1.
2.
3.
4.
5.
6.
7.
Abertura de chamados
Priorização de chamados
Repriorização de chamados
Controle de SLAs
Acompanhamento de chamados
Direcionamento de chamados p/ áreas fins
Acompanhamento de métricas
1. É necessário seguir o modelo ITIL,
conforme nova Norma 5593.3 a ser utilizada
por todos os órgãos da nossa instituição
2. Alguns campos do chamado devem vir do
sistema Morpheus que contem os cadastros
de todos os itens do patrimônio.
Controlar horas
gastas em
atividades de
projeto
Todas pessoas do Setor de TI precisam
registrar o tempo gasto em atividades de
projetos da área, e as pessoas trabalham em
vários projetos ao mesmo tempo. Os
relatórios de horas precisam ser aprovados
pelos gestores.
1.
2.
3.
3.
4.
Apontar horas diariamente
Editar/alterar/corrigir horas
Verificar timesheet semanal de horas
Gestor analistar timesheets de horas
Gestor aprovar/solicitar ajustes de horas
1. Deve existir integração dos apontamentos
de horas com o sistema de RH, pois as
pessoas não podem logar mais horas diárias
do que o RH permite e nem podem logar
horas se estiverem de férias ou sem ter
passado pela catraca no dia.
Observa-se que este planilhamento pode se tornar bastante extenso. Não é objetivo aqui fazer um detalhamento
findo, mas sim garantir que os principais pontos sejam identificados, e que qualquer coisa que seja relevante seja
pontuado na coluna “Pontos Importantes”.
Como será visto mais adiante, este planilhamento servirá de base para a RFP (Request For Propostal) que será
parte integrante do Termo de Referência do projeto e que constará no edital licitatório.
Um momento de reflexão é importante aqui, sobre duas questões:

É bastante trabalho fazer isso, é necessário mesmo?
 Isso não será feito depois durante a execução do projeto?
E a resposta para as duas questões é SIM. É bastabte trabalho e também será feito em maiores detalhes durante
a execução do projeto. Porém, caso não seja feito agora, como um Expert poderá dar um preço e prazo justos para
executar este trabalho, se ele não conhecer nada do seu ambiente ?
5.2.8 Softwares de Interesse na ALM
Na Seção 4.3, mais precisamente na TABELA 1 são mostrados os produtos mais comumente utilizados em uma
implantação completa da solução ALM Atlassian. Agora, com base nas informações levantadas e estes produtos,
você tem condições de fazer um cruzamento das necessidades versus produtos da solução ALM.
Então, é o momento de listar quais são os softwares da ALM que parecem ser os mais adequados, sob o seu
ponto de vista para o projeto, colocando uma breve descrição ao lado, conforme o exemplo:
TABELA 5 – Exemplo de uma Lista de Interesse sobre Softwares ALM.
Software (Produto ou Módulo)
JIRA
Jira Agile
Tempo Timesheets
ServiceDesk
Descrição
Deve ser usado para controlar o atendimento de chamados e controle de projetos. Também apoiará a gestão do portfólio
dos Setores, em conjunto como MS Project.
Vai ser utilizado pela equipe de desenvolvimento de sistemas, que está usando Scrum
Todos vão utilizar para logar horas. E gostamos muito dos relatórios de agrupamento que a gente viu nos vídeos de
exemplos do Marketplace.
Precisamos controle de SLAs apurados nos chamados, pois ano que vem temos interesse de implantar ITIL e também
porque existe políticas internas de remuneração para equipes com bons atendimentos de chamados.
Confluence
Já utilizamos outra wiki gratuita (a MediaWiki), mas gostarmos muito do que a plataforma da Atlassian oferece e queremos
explorar isso. Achamos que existe muita possibilidade aqui. No Anexo XX existem alguns screenshots da nossa wiki atual e
uma figura mostrando toda a árvore de páginas atual.
Zephyr
A área de gestão de testes está entrando dentro dos controles da ISO9001 e por isso é interessante ter controles melhores
aqui. Este módulo interessou bastante.
Página. 23 de 34
Conforme pode ser visto, esta é uma listagem simples, bem didática e objetiva. Ela ajuda muito a contextualizar
as necessidades e os produtos. A descrição associada é importante também, porque uma simples palavra ou termo
utilizado ali pode dar indícios de mais recursos que a ALM pode oferecer, agregando ainda mais valor para a solução.
5.2.9 Os Administradores da Solução ALM
Uma atenção especial deve ser dada às pessoas que devem ser eleitas para serem os administradores da solução
ALM. São os comumente chamados “Jira Admin”, “Confluence Admin”, “Bamboo Admin” e aí por diante.
A plataforma ALM Atlassian é grande, e devido a sua amplitude é muito difícil para uma única pessoa assimilar o
conhecimento para manter e administrar todo o parque instalado quando vários softwares e módulos estão
presentes.
Assim, é importante descobrir o mais breve possível no início do projeto quais são as pessoas com melhor
afinidade para cada tipo de ferramenta e direcioná-las o quanto antes para as futuras atividades de administração de
cada parte da ALM.
Vamos dar alguns exemplos:

Pessoas com perfil voltado ao desenvolvimento (ex. um Arquiteto de Software) pode ser a pessoa mais
indicada para ser o eleito a administrar softwares como Bamboo, Stash, Fisheye e Crucible;

Pessoas da área da Qualidade e Processos pode ser mais indicada para administrar os aspectos de
Workflows, telas e campos do Jira;

Um gerente de projetos pode ser alocado parcialmente para definir, manter e talvez até evoluir regras
sobre Kanbans, Timesheets e outras.
De qualquer forma, é fato que várias pessoas possam ter que compartilhar a função de administrar a ALM. E
selecionar estas pessoas pelos seus skills desde o início é de suma importância, para elas acompanharem todo o
processo de implantação da ALM. Pessoas “backup” para estas funções também precisam ser previstas, para cobrir
períodos de férias, ausências ou eventos não programados.
E, importante salientar que, mesmo que pessoas suficientes sejam alocadas para esta função de administração
ALM, isso não exime um possível contrato de suporte de serviços com um expert para ações mais avançadas ou uma
“mão extra” para atender sazonalidades.
5.2.10 Plano de Projeto Inicial
Com o material levantado até o momento é a hora de fazer uma estruturação das idéias, visando dimensionar o
escopo do projeto. Um arquivo .doc é um local excelente para isso. As seções indicadas para este momento são as
seguintes:
TABELA 6 – Modelo de documento para formatação do escopo inicial do projeto ALM.
Seção
Descrição
Título do Projeto
Data de Atualização
Data de Aprovação
Área Responsável
Patrocinador
Product Owner
Usuários Líderes
Justificativa
Resumo do Projeto
Meta do Projeto
Um título simples, objetivo e que seja compreendido facilmente pelos stakeholders e usuários.
Data da última atualização do documento.
Data da aprovação do documento por todos envolvidos, incluindo o patrocinador.
Nome da área/departamento/setor/órgão/grupo de trabalho/etc que conduzirá o projeto e é responsável por ele.
Nome, email, telefone, cargo da pessoa patrocinadora (ex. um diretor) do projeto, com seu respectivo aceite.
Nome, email, telefone, cargo da pessoa patrocinadora (ex. um analista de sistema) do projeto, com seu respectivo aceite.
Nome, email, telefone, cargo e área de cada usuário líder do projeto com sua respectiva ciência/conhecimento da causa.
Entre 5 e 7 parágrafos descrevendo o porquê, o evento causador, o motivo, a justificativa de porque o projeto deve existir.
Entre 5 e 7 parágrafo descrevendo o que é o projeto, seu contexto, limites, envolvidos, áreas e intenções.
Uma frase objetiva, no formato imperativo, que condensa todo o escopo e objetivos do projeto. É para isso que todos
Página. 24 de 34
esforços serão direcionados desde o primeiro dia do projeto. Será a bandeira da venda interna do projeto na organização.
Objetivos do Projeto
Soluções Existentes
Principais Processos Envolvidos
Riscos Identificados
Fora de Escopo
Quantidade de Usuários
Produtos ALM
Lista numerada dos objetivos a serem atingidos pelo projeto. Usar a premissa SMART2 é uma ótima forma de fazer isso.
A tabulação das soluções existentes pode ser usada aqui como anexo e referência com algum complemento. É aqui que
deve ser descrito o porquê estas soluções não atendem mais e exigem uma nova solução, complementando a Justificativa
inicial.
O detalhamento da Seção 5.2.7 sobre processos é o texto que deve estar presente aqui. São estes processos que devem
ser antendidos pela solução ALM a ser implementada. Pode ser informado como Anexo para evitar poluição visual.
1. Não existe atualmente nenhuma pessoa que possa ser alocada para as funções de administração das ferramentas
2. Disponibilidade diária dos usuários-líderes é pequena, talvez um máximo de 1h ou 2h diárias para prestar informações e
se envolver no projeto
3. Devido troca da superintendência prevista para o fim do ano, o projeto piloto precisa entrar no ar até dia 20-Set-2014.
Não é preciso integrar os usuários com o Active Directory
Um valor numérico aqui é o objetivo. Se esta tabulação puder ser feita em detalhes, melhor ainda, como usuários em cada
área e o tipo de usuário (por função cargo, por exemplo) em cada área. Isso ajuda a dimensionar o número de usuários
para cada produto da solução ALM a ser implementada.
Baseado na TABELA 1 de produtos da solução ALM Atlassian e na Seção 5.2.8, é aqui que são listados os softwares e
módulos que, na sua visãoo, apresentaram aderência às necessidades. Também o Marketplace da Atlassian pode ser
consultado para ter mais idéias. Importante salientar que está é a sua visão sobre o caso, e mais ou menos softwares e
módulos poderão entrar ou sair do projeto conforme análise recomendativa da consultoria (o Expert).
Observe que, neste momento, sua iniciativa já ganha um formato de projeto, propriamente dito.
A formalização deste documento internamente é importante, pois dá ciência aos envolvidos da importância e
formalidade do projeto que está em formação.
Repasse o documento para todos os envolvidos e obtenha um aceite deles. Dê tempo para uma análise e colete
feedback. Caso ajustes sejam necessários, execute eles e repasse novamente para apreciação.
Após todos os aceites, você está apto a acionar os fornecedores, ou seja, os Experts Atlassian, para discutir o seu
projeto. Use esse documento como seu apoio.
5.3 O Primeiro Contato com as Revendas
De posse do Documento de Escopo Inicial, é o momento de acionar os Experts Atlassian para iniciar o processo de
contratação externa.
Conforme apresentado na TABELA 2, você pode consultar o website da Atlassian e pesquisar pelos experts no
Brasil. Filtrar por apenas parceiros Platinum, Enterprise ou de uma área de conhecimento específica (ex.
Treinamento) é uma prerrogativa sua. Porém, conforme exposto, fechar as portas de algum expert já neste
momento não é interessante. Converse, escute e obtenha o feedback de todos sobre o seu projeto antes de iniciar
uma filtragem por algum critério.
A forma de contato mais simples é enviar um email para o expert ou acioná-lo via telefone, solicitando ajuda. Os
dados de contato de cada expert geralmente estão disponíveis no próprio website da Atlassian ou nas páginas de
cada parceiro.
Ao fazer o contato inicial, você pode fazer algumas perguntas ao expert, a fim de conhecê-lo melhor. Lembre-se:
Aqui você ainda não sabe qual expert vai ajudar você melhor, muito menos qual deles será o vencedor do processo
licitatório que virá. É sua responsabilidade, como Product Owner, fazer as perguntas certas e começar a moldar o
formato desejado que um expert precisa ter para atender melhor o seu projeto.
Algumas perguntas são relevantes neste processo de descoberta, tais como:

Quantos clientes o expert já atendeu ?

Quais os tamanhos desses clientes ?

Os projetos atendidos foram parecidos com o meu ?
2
SMART: Acrônimo do inglês Specific, Measurable, Attainable, Realistic e Time Bound, é uma forma de descrever objetivos que
sejam passíveis de crivo, de verificação se foram satisfeitos ou não ao final de um projeto. Mais informações em
http://en.wikipedia.org/wiki/SMART_criteria.
Página. 25 de 34

Quantas horas de consultoria/mentoria/desenvolvimento ALM este parceiro já fez ?

Quais foram as taxas de sucesso e de fracasso desses projetos ? Posso falar diretamente com seus
clientes ?

O expert têm experiência em todos os produtos e módulos que eu tenho em mente de utilizar ?

Qual a metodologia que este expert utiliza para realizar a implantação ? Ela é compatível comigo ?

Quais os canais de atendimento e suporte que este expert pode me oferecer ? Quais SLAs envolvidos ?

Qual a experiência e didática dos consultores que vão me ajudar ? Qual o currículo deles ?

Mê de alguns exemplos de documentações produzidas em projetos, para eu saber o que vou receber
além de software funcionando e conhecimento verbal.

Terei atendimento onsite no meu projeto ? E depois, terei suporte de vocês se precisar ? Que garantia eu
tenho sobre isso ?

Se eu quiser desenvolver alguns testes, uma preliminar das possibilidades da ALM, eu posso ? Isso pode
ser feito gratuitamente ? Existe um ambiente demonstrativo para eu degustar ?
Essas são algumas perguntas exploratórias básicas. Você pode necessitar fazer outras. Explore o máximo. E
certifique-se de tabular estas informações obtidas e registrá-las na sua pasta de projeto, pois agora sim você começa
a fazer um filtro dos experts.
As respostas os experts são essenciais, pois vão balizar o nível técnico do Termo de Referência do projeto que
você precisa escrever.
Por exemplo, se você considera que a gerência do projeto deverá ser feita por um gerente certificado PMP do
expert, e nenhum dos experts poder oferecer isso, você não terá sucesso na empreitada, pois nenhum expert
conseguirá enviar as documentações comprobatórias para isso. Neste caso, você precisa baixar as suas exigências,
ou rediscutir com os experts a importância do assunto, onde obrigatoriamente uma certificação dessas ou
equivalente será exigida. O mesmo vale para outras certificações ou atestados técnicos.
É por este motivo que este contato inicial com os experts vai ajudar você a nivelar a parte técnica do edital, a fim
de garantir uma concorrência justa e que atenda as necessidades do seu projeto.
Por outro lado, cortar todos os requisitos (ex. não exigir uma certificação técnica ou um Atestado de Capacidade)
do expert também é nocivo, pois você dá margem para oportunistas aparecerem no dia do certame, e todo o seu
trabalho (que pode levar meses) ir por água abaixo ao perceber que um expert menos qualificado tecnicamente foi o
vencedor do certame.
IMPORTANTE: Lembre-se, a Lei 8.666 baliza sempre a compra justa para o Governo, onde em iguais condições
técnicas, o menor preço vence. Então cabe a você dizer qual é o nível técnico mínimo aceitável para o seu projeto.
Não esqueça isso. Você, e apenas, você é responsável por isso.
Alguns exemplos de certificados que podem ser solicitados aos experts como qualificação técnica:

Certificação PMP3 ou CSM ou CSP (para gerentes);

Certificação ITIL (para consultores);

Certificação Java (para desenvolvedores);

Certificação ISO (para a empresa);

Certificação CMMI ou MPSbr (para a empresa);

Atestados de Capacidade Técnica (para a empresa), vide ANEXO 3 para exemplo deste;
 Atestado de Autorização do Fabricante para Revenda e Serviços Atlassian;
IMPORTANTE: Este último atestado é de suma importância, e não deve ser subestimado. Explica-se: Ao exigir que
somente parceiros oficiais, ou seja, experts legalmente representantes da Atlassian possam efetuar a revenda e
implantação da solução, você minimiza muito a chance de empresas oportunistas (popularmente conhecidaas como
3
PMP: Project Manager Professional; CSM: Certified Scrum Master; CSP: Certified Scrum Professional.
Página. 26 de 34
“picaretas”) entrarem no seu projeto. A 3layer Tecnologia ressalta isso aqui porque já participou de editais onde este
item fora ignorado e empresas não legitimadas entraram no processo licitatório no dia do certame, ocasionando
transtornos grandes, pois elas não puderam atender as necessidades do projeto num segundo momento. O cliente,
no caso o Governo, perdeu tempo e dinheiro.
Mas, lembrando, exigir critérios muito altos ou baixos, incompatíveis com a realidade do seu projeto, pode limitar
suas opções e abrir margem para discussão no certame, talvez até invalidando-o juridicamente. Tente achar o meio
termo para suas necessidades usando o bom senso.
5.4 A Formação do Escopo
Com base nos retornos obtidos de cada expert, você tem condições de evoluir o seu plano de projeto.
Agora é chegada a hora de transformar as estruturas iniciais um documento mais organizado, obtido a partir das
conversas e possibilidades traçadas com cada expert. Este documento será, naturalmente, conhecido como Termo
de Referência mais para frente.
A melhor forma de definir o escopo de um projeto é a construção de uma Request For Proposal (RFP). Ela tabula
todo o escopo do projeto, definindo áreas de conhecimento e requisitos a serem satisfeitos. Ela também identifica
as prioridades (que devem ser aderentes às prioridades das necessidades já levantadas pelas áreas) e pesos para
cada item. O modelo abaixo é um típico formato de planilha RFP:
TABELA 7 - Modelo de Planilha RFP para projeto ALM.
Número
Área de
conhecimento
Recurso
Importância
10 = Essencial
5 = Importante
1 = Desejável
Atendimento
5 = Nativo
2 = Exige Desenvolvimento
0 = Não implementa
Pontuação
Produtos ALM
Observações
Numeração de 1
em diante para
localização
unívoca
do
recurso
Área
de
conhecimento à
qual o recurso
se aplica.
Descrição
exata do
que
se
deseja ser
atendido
pela
solução
ALM.
Uma
das
opções,
evidenciando
claramente
importância
recurso.
três
É a forma com que a solução
ALM vai atender este recurso.
a
do
Esta coluna não é preenchida
por você, mas sim pelo expert
que vai receber esta planilha.
Multiplicação
da
Importância x
Atendimento.
Nome
dos
softwares ALM
que devem ser
utilizados
para
atender
este
recurso.
Também
é
preenchido pelo
expert.
Espaço
para
complementação de
informações,
por
parte sua ou do
expert
que
está
preenchendo
Nesta planilha, algumas dicas extras:

Número: É um número sequencial, iniciando em 1 e incrementado de forma unitária para localizar
univocamente cada recurso a ser contemplado pela solução ALM. Interessante é que esta seja a mesma
ordem de prioridade do Backlog, ou seja, os itens mais importantes são os primeiros.

Área de Conhecimento: Diz respeito à qual área, grupo lógico de recursos, o recurso que está sendo
mensurado se aplica e não a qual departamento ou setor ele se aplica. Lembre-se: Quando foram
unificadas as necessidades em uma única lista (o Backlog), não se tem mais uma visão separada, disjunta
das necessidades, mas sim uma visão unificada. Então, aqui na RFP é esta visão unificada que deve ser
tratada. O agrupamento por área de conhecimento ajuda a leitura do documento, onde recursos
relacionados estão juntos uns aos outros. Como dica para preencher esta coluna, podem ser utilizadas as
áreas de conhecimento do Guia PMBOK na (são as áreas: Integração, Gestão de Escopo, Gestão de
Tempo, Gestão de Custos, Gestão de Qualidade, Gestão de Pessoas, Gestão da Comunicação, Gestão de
Riscos, Gestão de Aquisições, Gestão de Afetados) ou uma segmentação pensando em lógica de
desenvolvimento de sistemas (Análise, Modelagem, Gerenciamento, Desenvolvimento, Testes,
Homologação). Outro exemplo ainda é segmentar essas áreas de conhecimento em Gestão de Processo,
Gerência de Portfólio, Gerência de Projetos, Gestão de Testes, Requisitos e Design, Gerência de
Configuração, Garantia da Qualidade, Medição e Análise. Na prática, esta organização é você que pode
estruturar, e o objetivo dela é agrupar recursos semelhantes.
Página. 27 de 34

Recurso: Visto vários usuários/setores terem visões diferentes de importância para um mesmo recurso, o
valor a ser preenchido deve sempre ser o mais alto de todos. A forma gramatical mais adequada para
preencher cada recurso é uma frase imperativa, no formato “A solução deve...”.
Como exemplos práticos de RFP de projetos já desenvolvidos pela 3layer Tecnologia, considere o ANEXO 2.
Antes de fechar a RFP, valide-a internamente com todos os setores/áreas/grupos de trabalho envolvidos e
integre-a à pasta do seu projeto. Caso ela leve a alterações no Plano de Projeto Inicial, atualize-o também.
5.5 As Propostas de Balizamento Comercial
Uma vez construída a RFP, já existe um material substancial para fazer a 2ª rodada de conversação com os
experts.
Neste momento o objetivo é enviar a RFP que foi construída para os experts preencherem as informações
necessárias, quais são: as colunas Atendimento, Produtos ALM e Observações, caso você utilize o modelo sugerido na
TABELA 7.
Solicite a cada expert uma proposta comercial para atender a sua RFP e garanta que a RFP seja preenchida na
íntegra, sendo incluída como anexo da proposta comercial. Haja visto que você já iniciou um canal de comunicação
com os experts antes, cada um já está contextualizado sobre a sua demanda e terá condições de estimar uma ordem
de grandeza de custo e prazo para satisfazer sua necessidade.
Claro, eventualmente, se seu projeto for grande, é provável que questionamentos sejam feitos ainda pelos
experts, de forma a sanar dúvidas remanescentes itens da RFP ou novas necessidades ou opções que surgiram neste
meio tempo. Assim, a garanta uma janela mínimia de umas duas a quatro semanas para que os experts possam
trabalhar com você a sua RFP, buscando obter propostas comerciais realmente aderentes à sua necessidade.
A troca de emails é importante nessa fase, mas iterações via reuniões remotas, ou se possível até presenciais
(apresentações onsite pelos experts) são grandes diferenciais para conseguir dar aos experts todas as informações
para que uma proposta comercial detalhada, objetiva e consistente seja apresentada, o que você certamente vai
precisar para justificar o seu projeto junto ao patrocinador.
IMPORTANTE: Ao solicitar as propostas comerciais neste momento, enfatize para os experts que são propostas
comerciais que precisam maior longevidade para expirar, pois o momento da compra, a data exata, ainda é
desconhecida. Um prazo de 90 ou 120 dias é algo bem provável aqui. Isso é importante, pois será fator decisivo para
formatação do seu orçamento para o projeto.
É importante você coletar pelo menos 3 (três) propostas comerciais diferentes para balizar a formação do teto
orçamentário para o seu Termo de Referência.
Ao receber as propostas comerciais, evite balizar-se apenas pelo preço. Ao contrário, busque embasamento
técnico na proposta, algo que mostre consistência, qualidade, aderência ao seu empreendimento. Algumas dicas ao
analisar as propostas comerciais recebidas podem ser:

Clareza da proposta comercial frente à sua RFP e às necessidades do seu plano de projeto;

Mecanismos de controle que serão usados no projeto, como metodologia a ser seguida, marcos de
controle durante a execução do projeto, processo de testes ou homologação;

Qualificação técnica (nível de senioridade) dos profissionais que o expert vai alocar para executar seu
projeto;

Prazo do projeto (prazos muito curtos ou muito longos de uma proposta em relação às demais propostas
recebidas podem evidenciar que o expert não entendeu muito bem o seu projeto ou está super ou
subestimando ele; nesses casos, rediscuta a proposta com o expert ou desconsidere-a em último caso);

Preço do projeto (idem prazo);

Local de execução do projeto (se onsite ou remoto). Esse ponto é importante ser clarificado muito bem,
pois isso pode ser um dos principais componentes do preço do projeto, devido gastos extras envolvidos,
Página. 28 de 34
como passagens aéreas, hotel, alimentação, pernoites, etc. dos consultores que vão atuar na implantação
da ALM;

Listagem clara, mostrando o nome dos softwares ALM (produtos e módulos) que serão utilizados na
solução, bem como a faixa de usuários de cada um deles, e o tipo de licenciamento (se acadêmico,
normal ou enterprise);

Forma de faturamento do projeto e as regras envolvidas para isso, como parcelamento ou
condicionamento de pagamentos às entregras de uma determinada fase ou período (ex. mensal);

Como ocorre o processo de homologação das entregas, e o prazo envolvido para isso. De fato, a
homologação de projetos ALM que envolvem workflows ou itens mais customizados pode ser difícil se
não estiver muito claro isso já na proposta comercial;
De posse das propostas comerciais balizadoras, é momento de reunir o material e montar a versão final do Termo
de Referência, documento essencial ao processo licitatório que virá.
5.6 A Confecção do Edital e o Termo de Referência
Agora, dando uma parada, e recapitulando o se tem até aqui, a sua pasta de projeto deve conter os seguintes
materias:

Listagem das Soluções Atuais em uso pelos setores/áreas/departamentos/etc (TABELA 3);

Lista Priorizada de Necessidades Por Áreas de Conhecimento (TABELA 4);

Listagem dos softwares de interesse sobre a ALM (TABELA 5);

Documento com o Plano do Projeto Inicial (TABELA 6);

RFP do projeto (com pelo menos três já preenchidas por cada um dos experts acionados) (TABELA 7);

Pelo menos três propostas comerciais dos experts para atender o projeto, cada uma apresentando
possivelmente formas diferentes de acomodar suas necesssidades;
Com base neste material é chegada a hora de confeccionar o Termo de Referência que será a base técnica para o
processo licitatório;
O Termo de Referência é um documento técnico que abrange a totalidade das necessidades e requisitos que
devem ser atendidos pelo expert que for o vencedor do certame.
Salientando novamente, é o Termo de Referência que vai balizar a qualidade e retorno do valor agregado que seu
projeto terá, pois ele será o filtro principal para seleção do expert que vai atende-lo.
Para fins de exemplificação de Termos de Referência de alguns projetos de Governo sobre ALM Atlassian,
considere os ANEXO 4 e ANEXO 5.
A escrita final do Termo de Referência é trabalho seu, e não pode ser influenciado por nenhum expert ou
empresa que vai se envolver no processo licitatório. Em outras palavras, você tem todos os sinais e materiais de
apoio neste momento, e deve fazer a escrita agora por conta própria.
Caso alguma dúvida exista, acione os experts para fins de consulta, mas não direcione o Termo de Referência
para um ou outro expert em momento algum. Fazer isso é ilegal.
5.6.1 O Cálculo da Reserva Orçamentária
De posse das propostas comerciais, você tem condições de estimar o valor final do seu budget, ou seja, do
orçamento que é necessário alocar para a execução do projeto.
Erro comum é fazer uma média direta simples dos valores (de serviços e de licenças) obtidos das propostas
comerciais recebidas. E por quê isso ? Porque, mesmo que você já tenha solicitado um prazo maior para os valores
das propostas-base, cada proposta em si tem conteúdo, consistência, aderência, metodologia, forma diferente de
execução. Isso leva a preços com diferenças, às vezes, significativas entre elas. Por exemplo, um expert pode ter
vislumbrado um prazo menor (com mais pessoas envolvidas) para executar o projeto e isso faz com que seu preço
fique maior num certo período de tempo. Já outro pode ter colocado uma condição de qualificação técnica
Página. 29 de 34
(senioridade da equipe a ser alocada) um pouco menor (pois talvez a RFP e uma discussão fraca nas fases de prévenda deram margem a esse entendimento) e por consequência seu preço ficou menor. Muitas outras variações
podem ocorrer.
Assim, uma forma mais sensata para fazer a reserva orçamentária pode ser uma média ponderada entre as
propostas recebidas (propostas mais consistentes têm peso maior), ou ainda adicionar um percentual chamado no
Guia PMBOK de Reserva Gerencial4, ou seja, um coeficiente para suportar um risco desconhecido que porventura
venha ocorrer. Exemplos desses riscos podem ser a alteração de legislação, uma variação cambial inesperada, o
encerramento das atividades comerciais de um dos experts envolvidos ou qualquer outro evento não esperado.
Conforme diz do Guia PMBOK, a reserva gerencial é sua “carta na manga” para cobrir coisas não previstas.
Esses dois últimos parágrafos são colocados aqui como forma de lembrete, pois a 3layer Tecnologia já esteve
presente em editais onde a reserva orçamentária que fora alocada para o projeto, ou seja o teto financeiro que o
pregoeiro dispunha no dia do certame fora insuficiente. Possivelmente, houve um cálculo inadequado para a
dotação orçamentária do projeto. Neste referido exemplo, o edital foi cancelado, pois nenhum expert conseguiu
atender a demanda dentro do teto financeiro extremamente baixo que estava disponível. Todo processo recomeçou
da estaca zero para um novo edital. Prejuízo inegável para todos os envolvidos no processo.
Para fins de exemplo de editais sobre a suíte ALM Atlassian, vide o ANEXO 6 e ANEXO 7.
5.7 A Publicação do Edital e as Propostas Finais
A publicação do edital, informando a data e hora do certame, incluindo seus anexos, como o Termo de Referência
(e dentro desse materiais como a RFP) é procedimento formal, a ser feito via Diário Oficial.
Isso, entretanto, não vai garantir que os experts tenham conhecimento dessa publicação. Então, é imprescindível
também fazer uma comunicação direta para eles, via email ou telefone. Isso vai aumentar as chances de mais
experts participarem do processo de seleção, dando mais oportunidades de escolha para você no dia do certame.
Se o certame for presencial, é provável que as propostas finais de cada expert somente sejam recebidas e abertas
no dia do certame. Se o certame for remoto, via um Pregão Eletrônico, as propostas comerciais serão recebidas de
antemão, e no dia do certame apenas os experts que enviaram propostas poderão fazer a concorrência que busca,
via regra, o menor preço.
Novamente salientando, caso o Termo de Referência tenha sido mal escrito, com margens à interpretação,
incompleto, inconclusivo, dúbio, mal delimitado, o resultado esperado da concorrência não será alcançado.
Por fim, certifique-se que todos os experts aguardados (pelo menos os três das propostas balizadoras) enviaram
propostas.
5.7.1 Edital Presencial ou Pregão Eletrônico
Item importante a ser decidido na escrita do edital é o formato com que ele será conduzido, se presencial ou se
realizado eletronicamente, de forma remota.
Via regra, pode-se dizer que editais presenciais atuam como um ótimo critério de filtragem, pois apenas experts
realmente interessados no projeto se farão presentes. Entretanto, é fato que eles são mais onerosos. Isso ocorre
porque, além da estruturação física que você deve prover para tal evento (sala, pessoas, etc.), os experts Atlassian
estão localizados em regiões geográficas distintas no Brasil, ênfase para região Sul e Sudeste. Mesmo quando um
edital é relizado em uma dessas regiões de melhor mobilidade (ex. Sudeste) os experts de outras regiões precisam se
deslocar até o local do edital. E isso tem custo para eles. E, inevitavelmente este custo é incluído nas suas propostas
comerciais.
Assim, é importante levar em consideração o valor total do projeto frente aos custos de viagem/estadia do expert
até o local do edital presencial. Faça uma pesquisa sobre preços de hotéis e passagens aéreas/urbanas até o seu
local e mensure isso frente ao valor total do projeto. Se este fator (ou seja, o deslocamento do expert para participar
4
Grosso modo: CONTINGÊNCIA é reserva financeira para os riscos identificados; RESERVA GERENCIAl é a reserva para os riscos
desconhecidos.
Página. 30 de 34
presencialmente no dia do edital) tiver, por exemplo, uma dimensão maior que 5% ou do valor total do projeto, é
provável que um edital presencial não se justifique. É por este motivo que editais de apenas licenciamento (sem
serviços de consultoria) geralmente utlizam pregões eletrônicos a fim de minimizar custos para todos. Porém,
mesmo esses editais podem ser feitos presencialmente, como por exemplo quando o órgão de governo já tem
interesse em aproveitar a ocasião para conhecer pessoalmente os experts e traçar um projeto voltados a serviços na
sequência (ex. em alguns meses ou próximo ano).
Já durante a solicitação das propostas comerciais balizadoras comunique os experts da sua intenção sobre um
edital presencial ou eletrônico. Isso ajudará a evitar surpresas em alterações de preços e condições no dia do
certame.
5.8 O Dia do Certame
O certame é o momento prático da competição entre os fornecedores, ou seja, os experts.
De forma geral, aprovados os experts nos quesitos documentais (comprovantes de regularidade fiscal,
administrativa, contábil, etc.) e técnicos (Atestados de Capacidade, Certificações, etc.) eles estão aptos a competir
pelo quesito menor preço, geralmente menor preço global.
Neste ponto, este roteiro não acrescenta muito, pois todo o trabalho necessário anterior já foi feito e agora é
apenas necessário aguardar o resultado do certame.
5.9 A Assinatura do Contrato e o Lançamento do Projeto
Passado o dia do certame e o expert tendo sido selecionado, pode ocorrer algum prazo para apresentação de
documentações finais, algo como um ou dois dias. Se neste prazo algum item remanescente ainda não for satisfeito
(ex. uma certificação ou comprovação fiscal pendente), é provável que este expert perca seu direito de vencedor em
favor do segundo colocado, e assim por diante. A Lei 8.666 possui diretrizes para esta sucessão. Fato é, uma vez
homologado o vencedor definitivo do edital, um expert será o seu parceiro de agora em diante.
Importante aqui é o período de assinatura do contrato, o que é comum entre 15 e 30 dias. Neste período, certo já
do expert vencedor, aproxime relações com ele, caso ele ainda não tenha feito. Abra todos os canais de
comunicação com ele: telefone, chat, email, vídeo calls, reuniões, etc.
Aproveite este período para ir alinhando o planejamento do projeto, possíveis viagens, estadias, alocações das
equipes que serão envolvidas, alocação de espaço físico no seu departamento para receber os consultores que
estarão implantando a solução ALM. Já vá providenciando o material de apoio que será necessário, como Quadro
Branco, Flipchart, canetas, papel, acesso à rede, criação de logins internos para os consultores, acesso a banco de
dados e outros materiais para o dia-a-dia do projeto que será iniciado em algumas semanas.
Quanto mais envolvimento neste período, mais rapidamente serão os passos iniciais para ganhar velocidade no
projeto.
5.10 A Execução do Projeto
5.10.1 Reunião de Kickoff
Marcada a data de início formal do projeto, e com os consultores onsite, seu projeto inicia. A indicação aqui é
fazer uma reunião de Kickoff com todos os envolvidos (lembre-se de seu Plano de Projeto Inicial). Certifique-se que o
Patrocinador, os Usuários Líderes e o Produt Owner (possivelmente você!) estejam presentes. De parte do expert, é
importante a presença de todos os consultores que trabalharão onsite, bem como do gerente de projetos alocado e,
remotamente (via vídeo call) da equipe de apoio (programadores, arquitetos, etc.).
Repasse todos os pontos do Termo de Referência, enfatizando a RFP. Porém, prepare a uma apresentação (ex.
slides .PPT) de antemão. Seja breve no discurso introdutório e, junto com o gerente de projetos do expert, atue
como moderador na reunião. Evite discursos filosóficos e fora do contexto. Garanta que o patrocinador permaneça
até o final da reunião e não apenas na sua abertura.
Página. 31 de 34
Abaixo algums itens que não podem ficar de fora desta reunião inicial:

Revisão geral do Termo de Referência;

Item a item da RFP;

Escopo da implantação ALM;

Meta geral do projeto;

Objetivos a serem alcançados;

Cronograma e Marcos e Prazo;

Riscos a serem gerenciados;

Metodologia a ser seguida;

Itens fora de escopo;

Participantes, Papéis e Responsabilidades;

Mecanismo de aprovação dos itens do escopo;

Mecanismo para suportar as (pequenas) alterações de escopo – sim, elas vão ocorrer;

Mecanismo para gerenciamento de agendas, reuniões e processos de homologação;

Ferramentas e mecanismos de controle do projeto, com horas trabalhadas, documentação, atas, etc;

Canais de comunicação formais e informais (ex. ferramenta de controle do projeto, chats, emails, etc.);

Dias e horários, e alocação das equipes envolvidas;

Processo de faturamento e prazos e aceites envolvidos;

Objetivo, escopo e condução da fase de “pilotagem” da solução ALM e escolha de antemão dos
processos/projetos/pessoas envolvidas para isso;

Marco de encerramento do projeto;
 Espaço final para dúvidas e questionamentos.
Estes são alguns itens, outros podem surgir. Discuta abertamente, sem receios todos os assuntos. Explore a
presença importantíssima de todos neste momento. Provavelmente juntar todas essas pessoas novamente somente
será possível ao final do projeto. A partir deste momento, o projeto entra em fase de execução.
5.10.2 O dia-a-dia do Projeto
O formato exato para a condução do projeto vai depender da metodologia que o expert aplicar no projeto.
Considerando a 3layer Tecnologia, por exemplo, toda a implantação é feita em formato iterativo, com a participação
diária do cliente, em ciclos evolutivos e focando prioridades conforme cada ferramenta ALM a ser implantada. Isso é
chamado de Mentoria. Muito uso de quadro branco e documentação no formato wiki + fotografias é feito.
Ao considerar a ferramenta JIRA, por exemplo, o foco começa com o mapeamento das Áreas, Serviços, Processos
e Perfis envolvidos, passando daí para mapeamento de Workflows, SLAs, telas, campos, notificações e regras de
negócio, indo para Dashboards, Quadros Kanban, Gadgets, Dashboards e relatórios, culminando na montagem dos
projetos e criação de tarefas (issues) de teste para homologação.
Já um projeto voltado ao Confluence pode envolver um projeto gráfico e navegacional, wireframes para leioute,
projeto de segurança da informação, gerenciamento de espaços, etc. Cada ferramenta da ALM vai exigir pessoas e
forças diferentes em diferentes momentos.
A palavra de ordem aqui é: confie no consultor do expert. Ele provavelmente já passou por diversos, dezenas, de
projetos e pode dar o caminho das pedras para você. Às vezes, na realidade bem comum este fato, é o cliente exigir
certas regras e formas de solucionar um problema no entendimento que o seu cenário é único e diferente de todos
os outros. Ledo engano. Regra geral, sempre é possível fazer algo diferente e muitas vezes melhor. Ouça a equipe do
expert e garanta que o Escopo, a sua RFP, o seu Termo de Referência seja satisfeito.
Página. 32 de 34
De sua parte, como Product Owner, garanta que os usuários líderes estejam sempre disponíveis (conforme
cronograma e matriz de reuniões) e remova diariamente todos os impedimentos para o expert.
5.10.3 A Entrega do Projeto e a Passagem do Bastão
Conforme o projeto ir se direcionando para o seu final é o momento de planejar o repasse do bastão, ou seja, o
voô solo da sua equipe.
O projeto piloto que fora selecionado na reunião de Kickoff (ou não muito depois disso) para testar a efetividade
da solução ALM deve entrar no ar, e sua condução deve ser feita pelo seu time, onde o expert geralmente atua em
segundo plano.
Opere o piloto e mensure a aderência dele frente aos objetivos iniciais do projeto, aqueles que motivaram o uso
da ALM Atlassian. É neste momento em que o valor agregado da solução ALM começa a ser percebido por todos.
Dependendo da dimensão do projeto, mais de um piloto pode ser necessário; dois ou três às vezes.
A fase de pilotagem é essencial para sentir “segurança” na solução ALM, revisar documentações e processos de
trabalho e alocar em definitivo as pessoas que trabalharão sobre a solução ALM, com ênfase para seus
administradores.
Quando o piloto se mostrar sustentável é o momento de formalizar o fechamento do projeto, ou seja, o que a
3layer Tecnolgia chama de repasse final. Se a proposta comercial, o cronograma e os controles foram bem
dimensionados, a entrega do piloto será uma fase tranquila e dentro das expectativas.
Agende uma nova reunião com todo o grupo que participou da reunião de Kickoff e apresente os resultados do
projeto. Discuta as Lições Aprendidas (que já devem ter sido compiladas algum tempo atrás). Pontue os objetivos, a
meta, mostre números e resultados para todos. O gerente de projetos do expert pode conduzir isso tudo para e com
você.
Garanta uma ata final e dê o projeto como encerrado.
5.11 O Pós-Projeto e Contrato de Suporte
Se o seu Termo de Referência havia previsto isso, é possível que você conte com um contrato de suporte de
serviços do próprio expert, além do contrato de suporte às licenças que você já tem direito.
Um contrato de suporte de serviços é algo muito imporante, pois formaliza o apoio do expert durante o uso da
ALM. Se você não tiver este contrato de suporte, qualquer eventualidade que ocorra no ambiente é de sua exclusiva
atenção e você precisará contar apenas com o seu conhecimento e os canais de suporte da fabricante Atlassian para
solucionar. Não que os canais sejam ruins, muito pelo contrário, são ótimos. Entretanto, talvez os prazos para
respostas aos seus questionamentos, bem como o nível e tipo de questionamento que você possuir não se
enquadrem dentro do que o fabricante oferece.
A 3layer Tecnologia oferece um serviço exclusivo no mercado para suporte pós-projeto ALM chamado Gestão
Compartilhada. Com este suporte é possível contar com a dedicação da 3layer Tecnologia para tanto administrar de
forma pró-ativa quando atender qualquer tipo de evento que venha ocorrer após a implantação do seu projeto,
tendo a garantia de tempo de resposta e a presença onsite se necessário. Para saber mais sobre este serviço,
consulte o ANEXO 9 e o ANEXO 10.
5.12 A Renovação Anual
Finalmente, outro item de grande importância para constar no seu projeto é a previsão para a renovação anual
do seu projeto. Tanto do licenciamento quanto dos serviços do expert.
Em relação ao licenciamento, as ferramentas Atlassian estão em constante evolução, agregando funcionalidades
a cada nova versão. Grosso modo, a cada três meses um novo release de uma ou outra ferramenta/módulo ALM é
lançada. Isso indica que em um período de um ano aproximadamente, três ou quatro releases estejam disponíveis
para atualização. Durante o prazo do licenciamento inicial, geralmente 12 meses (ou 24 ou até 36 dependendo do
Página. 33 de 34
que foi o escopo do projeto) você tem direito a atualizar o software para esta nova versão. Após este período, é
necessário renovar o licenciamento.
Conforme já comentado na TABELA 2, a renovação anual representa um valor percentual do valor da aquisição e,
se comparado a outras linhas de produtos (alguns clientes comparam muito com softwares como o Microsoft
Windows que oscila em torno de 20% a renovação), pode parecer que o valor percentual para renovação do
licenciamento ALM Atlassian seja grande. Porém, conforme exposto, é importante salientar a quantidade de
features que estão sendo incorporadas a cada nova versão, as quais são muitas quando comparadas a softwares de
prateleira como o Windows ou mesmo outras soluções ALM mais prosaicas, sem visão de evolução. Assim,
mantenha contato com os experts para dimensionar esta evolução e garantir que o período de renovação não
expire, ficando sem suporte. A previsão disso no seu Termo de Referência, atencipando esta necessidade, pode
ajudar muito a justificativa desse investimento recorrente.
Outro ponto importante a ser salientado aqui é que a renovação do licenciamento dos softwares Atlassian tem
como data-base a data de vencimento da licença corrente. Assim, se você perder o prazo para renovar um software
ALM, ao fazê-lo a posteriori, o período de suporte do fabricante já terá sido consumido neste meio tempo. Então, a
dica aqui é: cerca de 6 meses antes da renovação já inicie o processo interno de compra para a próxima renovação. E
se possível, adquira licenças para mais de um ano, como por exemplo 24 ou 36 meses, dando menos correria interna
para você e envolvidos.
Como última palavra deste capítulo está a renovação do suporte dos serviços e a continuidade da parceria com o
seu parceiro expert. Se você optou por um contrato como de Gestão Compartilhada da 3layer Tecnologia você já
estará coberto pelo prazo contratual deste apoio e pró-atividade na administração do ambiente. Porém, se você não
tem isso, é provável que a plataforma ALM instalada começe a ficar defasada em relação as novidades do mundo
Atlassian. Isso acontece porque, naturalmente, seu time interno não conseguirá sem apoio de um expert se manter
sintonizado e atualizado com a quantidade de módulos, artigos, novidades, vídeos, tendências, eventos,
documentações e diversas outras ações que a Atlassian promove continuamente. Apenas com a presença de um
expert parceiro atendendo você continuamente é que seu ambiente ALM estará em sintonia com as novidades e
saudável em questão de configurações, permissões, backup, segurança, desempenho e outros atributos. Mensure
isso no seu Termo de Referência também, de forma a garantir um contrato de suporte junto ao expert que implantar
a sua solução ALM Atlassian.
Página. 34 de 34
PARTE 3
6 CASES DE MERCADO
Os capítulos anteriores tentaram dar uma luz ao provável cliente de governo interessado de como um ciclo de
contratação, implantação e evolução da plataforma ALM Atlassian pode ocorrer sob a ótica da Lei 8.666 de
Licitações e Contratos da Administração Pública.
Para fins de exemplos sobre casos de implantação de soluções Atlassian da 3layer Tecnologia, que mostram a
amplitude que um projeto ALM Atlassian pode ter, considere o ANEXO 11, o qual está disponível e atualizado no
endereço eletrônico abaixo:
http://3layer.com.br/confluence/display/public/3LAYER/Cases
7 MATERIAL DE APOIO
Encerrando este documento, segue a lista completa dos anexos discutidos:
Anexo
Conteúdo
ANEXO 1
Exemplo de Planilha de Solucoes Existentes Pre-Implantacao ALM Atlassian
ANEXO 2
Fragmentos de Exemplos de RFP para projetos ALM Atlassian
ANEXO 3
Modelo de Atestado de Capacidade Tecnica
ANEXO 4
Termo de Referencia do Edital 102-2010 do TJMS
ANEXO 5
Termo de Referencia do Edital 0655-2013 da IPLANRIO
ANEXO 6
Edtial ALM Atlassian do 102-2010 do TJMS
ANEXO 7
Edital Treinamento ALM Atlassian 0655-2013 da IPLANRIO
ANEXO 8
Relatorio Quadrante Magico Gartner 2013 para solucoes ALM
ANEXO 9
Acordo de Nivel de Servico (SLA) do Servico Gestao Compartilhada 3layer Tecnologia
ANEXO 10
Minuta do Contrato do Servico de Gestao Compartilhada 3layer Tecnologia
ANEXO 11
Sintese dos Cases Comerciais da 3layer Tecnologia até 2011

roteiro para implantacao atlassian em orgaos de

Transcrição

Documentos relacionados

Gestão de Resíduos Eletroeletrônicos

LISTAGEM DE SOFTWARES DA PLATAFORMA

Kit 471 - Balaska Equipamentos

As Sete Regras de Ouro da Ecocardiografia

vila de coloane m95 bacia norte do patane c659 hotline

titulo do artigo

Lisbon - ArrivalGuides.com

Baixe o folder com o mapa do evento aqui.

Preços minímo duas noites

Visualizar

Opman SVG2 v11.qxd - Fieldpiece Instruments