Embed Size (px)
Citation preview
PABLO MARQUESI
METODOLOGIA DE GERENCIAMENTO DE PROJETOS DE SOFTWARE DO
TRIBUNAL DE JUSTIÇA DO ESTADO DE MATO GROSSO BASEADO EM
MÉTODOS ÁGEIS
Trabalho apresentado ao curso MBA em
Gerenciamento de Projetos, Pós-Graduação lato
sensu, da Fundação Getulio Vargas como requisito
parcial para a obtenção do Grau de Especialista em
Gerenciamento de Projetos.
ORIENTADOR: Prof. André do Valle
Cuiabá - MT
Dezembro/ 2014
FUNDAÇÃO GETULIO VARGAS
PROGRAMA FGV MANAGEMENT
MBA EM GERENCIAMENTO DE PROJETOS
O Trabalho de Conclusão de Curso METODOLOGIA DE GERENCIAMENTO DE
PROJETOS DE SOFTWARE DO TRIBUNAL DE JUSTIÇA DO ESTADO DE MATO
GROSSO BASEADO EM MÉTODOS ÁGEIS, elaborado por Pablo Marquesi e aprovado pela
Coordenação Acadêmica do curso de MBA em Gerenciamento de Projetos, foi aceito como
requisito parcial para a obtenção do certificado do curso de pós-graduação, nível de
especialização do Programa FGV Management.
Cuiabá, 10 de dezembro de 2014
André Bittencourt do Valle
Coordenador Acadêmico Executivo
André Bittencourt do Valle
Professor Orientador
DECLARAÇÃO
A empresa ............................, representada neste documento pelo Sr.(a) .....................,
(cargo) ............, autoriza a divulgação das informações e dados coletados em sua organização, na
elaboração do Trabalho de Conclusão de Curso intitulado (título) ..........., realizados pelo(s)
aluno(s) ......................., do curso de MBA em Gerência de Projetos, do Programa FGV
Management, com o objetivo de publicação e/ ou divulgação em veículos acadêmicos.
Local, Data
(assinatura)
(cargo)
(Empresa)
TERMO DE COMPROMISSO
O(s) aluno(s) Pablo Marquesi, abaixo assinado(s), do curso de MBA em Gerenciamento de
Projetos, Turma 06 do Programa FGV Management, realizado nas dependências da Unic no
período de 15/06/2012 a 31/01/2014, declara que o conteúdo do Trabalho de Conclusão de Curso,
METODOLOGIA DE GERENCIAMENTO DE PROJETOS DE SOFTWARE DO
TRIBUNAL DE JUSTIÇA DO ESTADO DE MATO GROSSO BASEADO EM
MÉTODOS ÁGEIS é autêntico, original e de sua autoria exclusiva.
Cuiabá, 10 de dezembro de 2014
Pablo Marquesi
RESUMO
Este trabalho apresenta a metodologia de gerenciamentos de projetos de software do criada
exclusivamente para o Departamento de Sistemas e Aplicações (DSA) do Tribunal de Justiça do
Estado de Mato Grosso.
O trabalho foi elaborado com o objetivo normatizar os processos de gerenciamento de projeto
desde sua concepção até sua entrega utilizando ferramentas e técnicas que dão apoio a métodos
ágeis de gerenciamento de projetos de software.
Palavras-chave: Métodos ágeis, ALM, metodologia, iterativo, incremental
ABSTRACT
This paper presents the methodology managements software projects created exclusively for the
Departamento de Sistemas e Aplicações (DSA) of the Tribunal de Justiça do Estado de Mato
grosso.
The work was done in order to standardize project management processes from conception to
delivery using tools and techniques that support agile software project management
Key words: Agile, ALM, methodology, iterative, incremental.
ÍNDICE
1 INTRODUÇÃO..................................................................................................................12
1.1 Objetivo da metodologia..................................................................................................12
1.2 Fundamentação teórica....................................................................................................12
1.3 Metodologia científica......................................................................................................13
1.4 Público...............................................................................................................................13
1.5 Como utilizar a MDS?......................................................................................................14
2 DESAMBIGUAÇÕES........................................................................................................16
2.1 Metodologia x Framework...............................................................................................16
2.2 Projetos x Operações........................................................................................................16
2.3 Gerenciamento de Projetos Tradicional x Ágil..............................................................16
2.4 ALM x SDLC....................................................................................................................17
3 MÉTODOS ÁGEIS PARA DESENVOLVIMENTO DE SOFTWARE.......................19
3.1 Manifesto para o desenvolvimento ágil de software......................................................19
3.2 Princípios por trás do Manifesto Ágil.............................................................................19
3.3 Principais métodos ágeis para desenvolvimento de software.......................................20
3.3.1 Scrum................................................................................................................................20
3.3.2 Extreme programming......................................................................................................21
3.3.3 Microsoft Framework Solutins.........................................................................................21
4 MODELO ITERATIVO E INCREMENTAL.................................................................23
5 APPLICATION LIFECYCLE MANAGEMENT (ALM)..............................................24
5.1 Pilares do ALM.................................................................................................................25
5.1.1 Pessoas..............................................................................................................................25
5.1.2 Processos..........................................................................................................................27
5.1.3 Ferramentas.......................................................................................................................27
6 GRUPOS DE PROCESSOS MGPS-DSA........................................................................31
7 FASE DE DEFINIÇÃO.....................................................................................................33
7.1 Gerenciamento da demanda............................................................................................34
7.1.1 Gerenciamento da demanda: Entradas..............................................................................37
7.1.2 Gerenciamento da demanda: Atividades..........................................................................37
7.1.3 Gerenciamento da demanda: Saídas.................................................................................39
7.2 Concepção da aplicação...................................................................................................40
7.2.1 Concepção da aplicação: Entradas....................................................................................43
7.2.2 Concepção da aplicação: Atividades................................................................................43
7.2.3 Concepção da aplicação: Saídas.......................................................................................50
8 FASE DE CONSTRUÇÃO................................................................................................51
8.1 Desenvolvimento da aplicação.........................................................................................51
8.1.1 Desenvolvimento da aplicação: Entradas.........................................................................55
8.1.2 Desenvolvimento da aplicação: Atividades......................................................................55
8.1.3 Desenvolvimento da aplicação: Saídas.............................................................................92
9 FASE DE OPERAÇÃO.....................................................................................................93
9.1 Gerenciamento de incidentes...........................................................................................94
9.1.1 Gerenciamento de incidentes: Entradas............................................................................97
9.1.2 Gerenciamento de incidentes: Atividades........................................................................97
9.1.3 Gerenciamento de incidentes: Saídas.............................................................................100
9.2 Gerenciamento de liberações.........................................................................................101
9.2.1 Gerenciamento de liberações: Entradas..........................................................................104
9.2.2 Gerenciamento de liberações: Atividades......................................................................104
9.2.3 Gerenciamento de liberações: Saídas.............................................................................106
10 MONITORAMENTO E CONTROLE...........................................................................107
10.1 Backlog Grooming..........................................................................................................107
10.2 Monitorar burdown chart..............................................................................................107
10.3 Controlar prazos de ofício e expedientes......................................................................108
10.4 Controlar capacidade da iteração.................................................................................108
10.5 Conduzir release planning.............................................................................................109
12 REFERÊNCIAS BIBLIOGRÁFICAS...........................................................................111
13 GLOSSÁRIO....................................................................................................................114
Sumário de figurasFigura 1 – Manifesto ágil...............................................................................................................19
Figura 2 – Como funciona o scrum................................................................................................21
Figura 3 – Processo iterativo..........................................................................................................24
Figura 4 – Processo incremental.....................................................................................................24
Figura 6 – Organograma do Departamento de Sistemas e Aplicações..........................................26
Figura 7 – Macrofluxo MGPS-DSA...............................................................................................32
Figura 8 – Diagrama do processo de Gerenciamento da demanda................................................35
Figura 9 – Diagrama do processo Concepção da aplicação...........................................................41
Figura 10 – Criando um novo projeto no visual Studio.................................................................45
Figura 11 – Organização das branches na metodologia.................................................................45
Figura 12 – Fluxo de uma release...................................................................................................47
Figura 13 – Relação requisitos x work items..................................................................................49
Figura 14 – Diagrama de do processo Desenvolvimento da aplicação..........................................53
Figura 15 – Cadastro de user story no team web access................................................................56
Figura 16 – Formato dos detalhes de uma user story.....................................................................57
Figura 17 – Diagrama do processo planejar iteração.....................................................................59
Figura 18 – Diagrama Executar iteração........................................................................................65
Figura 20 – Diagrama do processo Construção e testes unitários..................................................68
Figura 21 – Diagrama de status da user story.................................................................................72
Figura 22 – Diagrama do processo Planejar testes.........................................................................74
Figura 23 – Transição de status dos bugs no MSF.........................................................................80
Figura 19 – Ciclo de vida das releases...........................................................................................81
Figura 24 – Diagrama Executar testes de sistema..........................................................................82
Figura 25 – Diagrama Gestão do conhecimento............................................................................88
Figura 26 – Diagrama Gerenciamento de incidentes.....................................................................95
Figura 27 – Diagrama Gerenciamento de liberações...................................................................102
Figura 28 – Fluxo padrão para deploy em produção via release management............................104
Figura 29 – Gráfico burndown do Team Foundation Web Access..............................................108
Figura 30 – Velocidade do time no Team Foundation Web Access 2013...................................109
Figura 31 – Artefatos utilizados no Microsoft Solutions Framework (MSF)..............................109
Lista de tabelasTabela 1 – Matriz de responsabilidade Gerenciamento da demanda.............................................36
Tabela 3 – Matriz de responsabilidade concepção da aplicação....................................................42
Tabela 4 – Matriz de responsabilidade planejar iteração...............................................................59
Tabela 5 – Matriz de responsabilidade Executar iteração..............................................................65
Tabela 6 – Matriz de responsabilidade Construção e testes unitários............................................69
Tabela 7 – Matriz de responsabilidade Planejar testes...................................................................75
Tabela 8 – Matriz de responsabilidade Executar testes de sistema................................................83
Tabela 9 – Matriz de responsabilidade Gestão do conhecimento..................................................89
Tabela 10 – Matriz de responsabilidade Gerenciamento de incidentes.........................................96
Tabela 11 – Matriz de responsabilidade Gerenciamento de liberações.......................................103
12
1 INTRODUÇÃO
Desde o início da computação, surgiram diversas metodologias e modelos de maturidade todas
com o propósito direto ou indireto de garantir a entrega da aplicação dentro do tempo acordado,
com os recursos planejados e atendendo as funcionalidades esperadas, porém é importante
ressaltar que não há modelo ou metodologia perfeita, cada empresa deve procurar a que for mais
adequada.
O Departamento de Sistemas e Aplicações (DSA), visando melhorar a qualidade de seus
produtos, estabeleceu uma Metodologia de Gerenciamento de Projetos de Software (MGPS) para
ser usada em todos os projetos do departamento. Esta metodologia foi escrita para atender as
necessidades de todas as equipes do DSA. Reconhece-se que esta metodologia deve ser escalável
para poder atender aos requisitos de projetos grandes e pequenos.
1.1 Objetivo da metodologia
O propósito deste documento é descrever todos os passos necessários para o desenvolvimento e
manutenção de produtos de software no DSA em todas as fases do ciclo de vida. Este documento
fornece um ponto de referência comum para falar e escrever sobre a prática de desenvolvimento
de sistemas no DSA.
Essa base comum se destina a aumentar a consciência e profissionalismo dos envolvidos
demonstrando papéis e responsabilidades durante o processo. Os papéis do Comitê Consultivo de
Mudança (CCM), Patrocinador, Gerente de Projetos, Time de desenvolvimento e outras partes
interessadas. Um entendimento comum sobre os requisitos e as razões subjacentes a esses
requisitos são fatores-chave para melhorar os resultados do projeto.
1.2 Fundamentação teórica
No último relatório do caos, ou CHAOS manifesto em inglês, desenvolvido pela (STANDISH
GROUP, 2013)1, apenas 39% dos projetos de TI são entregues dentro do prazo, custo e escopo. É
uma taxa relativamente baixa, porém já foi muito pior nos anos anteriores.
1 Instituto que realiza pesquisas sobre o desenvolvimento dos projetos de TI nas organizações.
13
De 2004 a 2012 a taxa de sucesso em projetos de TI cresceu aproximadamente 35% e a Standish
Group atribui este aumento á vários fatores, sendo um deles o aumento da adoção de métodos
ágeis no gerenciamento de projetos de TI.
O Departamento de Sistema e Aplicações (DSA) até então trabalhava seguindo um modelo
tradicional de gerenciamento de projetos de software e apesar de não medir a taxa de sucesso nos
projetos, era visível que na maioria dos casos os projetos não eram entregues com a qualidade
esperada.
Atualmente 29% dos projetos de desenvolvimento de software utilizam métodos ágeis (OSEIK,
2011). Baseando-se nessa visão e acompanhando uma tendência de mercado, o DSA decidiu
adotar estas práticas para projetos de software no sentido de aumentar a qualidade do produto
entregue.
1.3 Metodologia científica
De acordo com o (MPS.BR, 2012) para se chegar em um nível de maturidade onde a gerência de
projeto é feita com base em um processo definido é necessário antes que este processo já esteja
sendo executado na organização. Portanto, antes da Metodologia de Gerenciamento de Projetos
de Software (MGPS) do Tribunal de Justiça de Mato Grosso começar a ser escrita vários projetos
foram experimentados utilizando abordagem dos métodos ágeis.
Seguindo o método de pesquisa empírica diversos experimentos foram realizados no decorrer de
18 meses, onde ferramentas, processos e técnicas foram implementadas de forma gradual dentro
do departamento de sistemas e aplicações do Tribunal de Justiça do Estado de Mato Grosso. Cada
item pesquisado era implementado, testado, amadurecido e validado em reuniões de
acompanhamento e se não fosse bem aceito, este item era modificado ou até mesmo retirado do
ciclo de vida do projeto de software.
Este trabalho não teve como foco a exposição dos resultados em números, sendo utilizada uma
metodolgogia de pesquisa qualitativa, onde o principal indicador de progresso do sucesso das
práticas adotadas era reuniões de feed back e a aceitação das práticas durante o tempo.
14
1.4 Público
A Metodologia de Gerenciamento de Projetos de Software (MGPS) foi criada para ser utilizada
por todos os colaboradores do Departamento de Sistemas e Aplicações (DSA), e a equipe de
tecnologia do Departamento de Aprimoramento da Primeira Instância (DAPI). O DSA é formado
por quatro equipes: Equipe de Qualidade de Software, Equipe Administrativa, Equipe Judiciária e
Equipe de Recursos Humanos, todas devem utilizar a metodologia como corpo de conhecimento
para auxilio nas rotinas diárias.
1.5 Como utilizar a MDS?
A Metodologia de Gerenciamento de Projetos de Software (MGPS) está dividida em duas partes:
Conceitualização e Metodologia e Processo.
A primeira parte introduz o leitor à vários conceitos utilizados na metodologia, aborda várias
disciplinas utilizadas no gerenciamento de projetos de software, construção e melhoria do
processo. Tem o objetivo de promover o alinhamento do conhecimento das partes interessadas
sobre as práticas que serão utilizadas durante todo o ciclo de vida do software.
A segunda parte descreve a metodologia em si, está organizada de forma a demonstrar suas fases,
processos e atividades. São no total 3 fases: definição, construção e operação. Cada processo
possui um diagrama (representação básica do processo focada nas principais atividades), uma
Matriz de Responsabilidade (RACI)2, entradas dos processos, atividades a serem executadas e
saídas.
2 RACI é uma ferramenta utilizada para atribuição de responsabilidades, dentro de um determinado processo, projeto, serviço ou mesmo no contexto de um departamento / função (PALMA, 2013). R: Responsável por executar uma atividade (o executor); A: Autoridade, quem deve responder pela atividade, o dono (apenas uma autoridade pode ser atribuída por atividade); C: Consultado, quem deve ser consultado e participar da decisão ou atividade no momento que for executada; I: Informado, quem deve receber a informação de que uma atividade foi executada.
15
Parte I - Conceitualização
16
2 DESAMBIGUAÇÕES
2.1 Metodologia x Framework
De acordo com (PMI, 2008) um framework de gerenciamento de projetos é um conjunto de
conhecimentos amplamente reconhecido como boa prática. Tais práticas são aplicáveis à maioria
dos projetos e na maior parte do tempo em sua e que existe um consenso geral de que a aplicação
correta dessas habilidades, ferramentas e técnicas pode aumentar as chances de sucesso em uma
ampla gama de projetos. Uma boa prática não significa que o conhecimento descrito deva ser
sempre aplicado uniformemente em todos os casos, a organização e/ou a equipe de
gerenciamento do projeto é responsável por determinar o que é apropriado para um projeto
específico.
Uma metodologia além de dizer “o que fazer” deve dizer “como fazer”, isso significa que, todas
atividades devem ser seguidas para que se obtenha êxito. Uma metodologia também reúne boas
práticas, porém devem ser seguidas de forma prescritiva e organizada. Segundo (MAIA, 2011)
uma metodologia é um conjunto de métodos e técnicas aplicadas para um determinado fim. É o
caminho percorrido, a maneira utilizada para atingir o objetivo, em outras palavras, em uma
metodologia todos os processos são conhecidos e previamente definidos.
2.2 Projetos x Operações
O conceito mais difundido sobre o que é um projeto vem do (PMI, 2008), que diz que é um
esforço temporário empreendido para se criar um produto, serviço ou resultado exclusivo. Ao
contrário de projetos, conforme explica (RODRIGUES, CAMPOS, et al., 2011), operações,
também chamadas de rotinas, são funções organizacionais que realizam a execução contínua de
atividades que produzem o mesmo produto ou fornecem um serviço repetitivo. As operações são
esforços permanentes que geram saídas repetitivas, com recursos designados a realizar
basicamente o mesmo conjunto de atividades, de acordo com os padrões institucionalizados no
ciclo de vida de um produto ou serviço.
17
2.3 Gerenciamento de Projetos Tradicional x Ágil
Gerenciamento de um projeto é a aplicação de conhecimentos, habilidades, ferramentas e
técnicas às atividades do projeto a fim de atender aos seus requisitos. Projetos serão sempre
projetos independentemente da forma como são gerenciados, porém projetos diferentes precisam
de métodos diferentes.
Em geral gerenciamento ágil de projetos são mais adaptáveis à projetos de escopo aberto, tais
como: desenvolvimento de software, melhoria continua de produto e projetos de escopo
indefinido. Já gerenciamento de projetos tradicionais são melhores aceitos em construções civis,
infraestrutura de TI, móveis sob medida, etc.
De acordo com (BUILDER, 2013) em métodos tradicionais de gerenciamento entende-se que o
produto só faz sentido quando é entregue em sua totalidade, ou seja, apenas com 100% do projeto
cumprido é que o cliente irá perceber algum valor. Por outro lado, métodos ágeis devem ser
usados em projetos que permitem que um conjunto mínimo de funcionalidades já servirá para
entregar valor e também quando existe grande incerteza sobre a solução que o cliente busca.
Outro ponto importante entre os dois métodos é que, em métodos ágeis, combinado que o projeto
irá entregar as funcionalidades mínimas o cliente nem sempre tem noção do custo total do
produto. Em métodos tradicionais o valor é fechado junto com o escopo e cumprir esse escopo
acaba sendo responsabilidade apenas da empresa
Práticas ágeis não são apropriadas para todos os cenários. Em especial, a agilidade é melhor
aproveitada nas seguintes situações: Projetos cujo esforço é intelectual; escopo altamente sujeito
a mudanças; restrições agressivas de tempo.
2.4 ALM x SDLC
É muito comum a comparação entre o Gerenciamento do Ciclo de Vida da Aplicação, do inglês
Application Lifecycle Management (ALM) e o Ciclo de Vida de Desenvolvimento de Sistemas
(CVDS), do inglês Systems Development Life Cycle (SDLC).
O SDLC está ligado com o desenvolvimento de um aplicativo de software, incluindo requisitos,
arquitetura, codificação, testes e gerenciamento de configurações. Já o ALM se preocupa com o
18
processo de ponta-a-ponta, pois este envolve todo o tempo em que a organização está investido
recursos com esse ativo, desde a sua ideia inicial até o fim da vida do aplicativo.
“Até há pouco tempo atrás falávamos de SDLC ao invés de ALM. Daí dá para perceber
que nos preocupávamos apenas com o ciclo de vida de desenvolvimento da aplicação e,
por isso, focamos mais nas ferramentas usadas pelos times de desenvolvimento.”
(ABADE, 2014).
19
3 MÉTODOS ÁGEIS PARA GERENCIAMENTO DE PROJETOS DE SOFTWARE
O termo “Metodologias Ágeis” tornou-se popular em 2001 quando dezessete especialistas em
processos de desenvolvimento de software representando os métodos Scrum, Extreme
Programming (XP) e outros, estabeleceram princípios comuns compartilhados por todos esses
métodos (SOARES, 2013). Foi então criada a Aliança Ágil e o estabelecimento do “Manifesto
Ágil”.
O manifesto ágil é um documento, que declarou uma nova forma de entender projetos que lidam
diariamente com imprecisão e imprevisibilidade, características inerentes ao processo de
desenvolvimento de software e tecnologia (AUDY, 2013). Os métodos envolvidos no Manifesto
criaram uma nova filosofia para gerenciamento de projetos de software, que passaram a ser
chamados de "Métodos Ágeis".
3.1 Manifesto para o desenvolvimento ágil de software
Figura 1 – Manifesto ágil
3.2 Princípios por trás do Manifesto Ágil
1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de
software com valor agregado.
2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento.
3. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o
cliente.
20
4. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com
preferência à menor escala de tempo.
5. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo
o projeto.
6. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte
necessário e confie neles para fazer o trabalho.
7. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de
desenvolvimento é através de conversa face a face.
8. Software funcionando é a medida primária de progresso.
9. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores,
desenvolvedores e usuários devem ser capazes de manter um ritmo constante
indefinidamente.
10. Contínua atenção à excelência técnica e bom design aumenta a agilidade.
11. Simplicidade -a arte de maximizar a quantidade de trabalho não realizado--é essencial.
12. As melhores arquiteturas, requisitos e designs emergem de equipes auto organizáveis.
13. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e
ajusta seu comportamento de acordo.
3.3 Principais métodos ágeis para desenvolvimento de software
Existem diversas disciplinas no mercado para auxiliar no gerenciamento de projetos ágeis de
desenvolvimento de software e todas se baseiam na filosofia e nos princípios do manifesto ágil
que foi citado logo acima. A Metodologia de Gerenciamento de Projetos de Software (MGPS)
utiliza diversas téncicas dos métodos ágeis citados abaixo:
3.3.1 SCRUM
Scrum é um processo de gerenciamento de projetos ágeis, adaptado para a área de
desenvolvimento de software, pelo especialista Ken Schwaber (JUNIOR e RAHAL, 2012). Ken
define Scrum, em um de seus livros, como: “um processo Ágil ou ainda um framework para
gerenciamento de projetos Ágeis. É um processo de gerência de projetos, certamente não é uma
metodologia, pois isto seria pesado demais”.
21
Figura 2 – Como funciona o scrum
Fonte: http://www.brq.com/metodologias-ageis/
3.3.2 EXTREME PROGRAMMING
Programação extrema (do inglês eXtreme Programming), ou simplesmente XP, é uma
metodologia ágil para equipes pequenas e médias e que irão desenvolver o software com
requisitos vagos e em constante mudança. Para isso, adota a estratégia de constante
acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software
(WIKIPEDIA, 2014).
3.3.3 MICROSOFT FRAMEWORK SOLUTINS
O Microsoft Solutions Framework (MSF) tem sido usado pela Microsoft como o seu "método"
para desenvolvimento de soluções de software dentro da Microsoft e também para os milhares de
clientes e parceiros da Microsoft em todo o mundo. A disseminação deste método, agora na
versão 4.0 no Visual Studio 2005, normalmente induz as pessoas a compará-lo com outros
"métodos" da indústria, como o RUP ou XP, entre outros. É importante entender, entretanto, o
que são estes elementos antes de compará-los.
Assim como em outros frameworks de desenvolvimento ágil, um projeto MSF é regido por ciclos
ou iterações. A cada ciclo, cada componente da equipe executa suas funções e atualiza o
22
resultado do seu trabalho conforme a necessidade. Os ciclos se repetem até que o projeto seja
concluído ou cada versão seja lançada.
A Microsoft não classifica o MSF como uma metodologia, mas sim como um framework.
Basicamente que o MSF serve como um guia e uma coleção de boas práticas.
3.3.4
23
4 MODELO ITERATIVO E INCREMENTAL
Em projetos muito complexos, como é o caso do projeto de software, o cliente pode não estar
apto a definir os requisitos logo no início ou pode não ter certeza de como quer o produto final. O
modelo iterativo e incremental é mais flexível em garantir que qualquer requisição de mudança
feita pelo cliente possa ser incluída como parte do projeto.
O processo de desenvolvimento iterativo e incremental é dividido em iterações, onde ao final de
cada uma delas é gerado um incremento do software que é um avanço na conclusão do produto.
As iterações são pequenos projetos onde existem etapas de fluxos de trabalho como captura dos
requisitos, análise dos requisitos, projeto, implementação e teste.
O uso do desenvolvimento iterativo faz-se necessário durante o desenvolvimento devido a
algumas razões, como:
Melhor gerenciamento da evolução do sistema desenvolvido: melhor adaptação a
mudanças nos requisitos;
Redução do risco de entendimento dos requisitos: Cliente vê resultado mais cedo e pode
dar retorno a tempo de fazer pequenos ajustes sem grandes impactos no planejamento do
projeto;
Aumenta confiabilidade do sistema desenvolvido;
Aceleração do tempo de desenvolvimento: desenvolvedores buscam resultados de escopo
pequeno e claro e a capacidade de reutilização aumenta.
De acordo com (WIKIPEDIA, 2013) o desenvolvimento iterativo é uma estratégia de retrabalho
em que o tempo de revisão e melhorias de partes é pré-definido. Começa com uma
implementação simples de um pequeno conjunto de requisitos de software e de forma iterativa
aumenta as versões evoluindo até que o sistema completo seja implementado e pronto para ser
implantado, conforme pode ser visto na Figura 3 – Processo iterativo.
Ainda de acordo com (WIKIPEDIA, 2013) o desenvolvimento incremental é uma estratégia de
planejamento estagiado em que várias partes do sistema são desenvolvidas em paralelo, e
integradas quando completas o contrário desta abordagem é desenvolver todo o sistema com uma
integração única. Veja o exemplo na Figura 4 – Processo incremental.
24
Figura 3 – Processo iterativo
Figura 4 – Processo incremental
25
5 APPLICATION LIFECYCLE MANAGEMENT (ALM)
ALM descreve métodos para gerenciar o desenvolvimento de software e iniciativas de TI
automatizando processos de ponta-a-ponta e integrando a informação de várias formas.
Integração fornece consistência, previsão e também introduz oportunidades de automação.
De acordo com (GARCIA, 2011), o ALM é a união entre gerência de negócio com engenharia de
software, suportada por ferramentas que facilitam e integram processos como análise de
requisitos, modelagem de arquitetura, desenvolvimento de código, gerenciamento de mudanças,
gerenciamento de testes e gerenciamento de versões de produtos realizados.
ALM é todo o processo que norteia toda a vida útil de uma aplicação desde a sua concepção,
passando pela construção, operação e evolução. Não observa apenas qual é o método de
construção, mas preocupa também na governaça da instituição (CONDÉ, 2009).
O ALM tem seu foco na produtividade dos recursos alocados, bem como auditar suas tarefas e
ações durante o projeto. Essa gestão aliada ao processo de melhores práticas escolhido, como os
métodos ágeis, seja ele qual for (CMMI, RUP, MSF, PMI, SCRUM, XP ou qualquer outro),
possibilita gerar padrões de avaliação. Pilares do ALM
5.1 Pilares do ALM
O ALM é estruturado com base em três pilares que se complementam, são eles: pessoas,
processos e ferramentas. Quando unidos, fornecem os recursos necessários para que as empresas
possam gerenciar o ciclo de vida das suas aplicações (CONDÉ, 2009).
5.1.1 PESSOAS
De acordo com (CONDÉ, 2009) a participação de pessoas é o pilar mais importante da tríade.
Pessoas bem treinadas e capacitadas formam a cola que une adequadamente as ferramentas e os
processos do ALM. Cada uma destas pessoas possui seus objetivos, segue abaixo os principais
papeis dentro deste pilar:
26
5.1.1.1 Estrutura organizacional do DSA
O Departamento de sistemas e aplicações utiliza uma estrutura organizacional clássica, mostrada
na Figura 5 – Organograma do Departamento de Sistemas e Aplicações, onde cada colaborador
possui um superior bem definido.
Figura 5 – Organograma do Departamento de Sistemas e Aplicações
Analista de Testes: O objetivo do Analista de Testes é desenhar as fundações do teste. Inclui
estruturar tanto do ponto de vista lógico, como físico de como o testes funcionarão, bem como o
seu comportamento nos ambientes.
Apesar do analista de teste estar lotado dentro de uma equipe de sistemas, ele está subordinado
ao gerente de qualidade, conforme visto na Figura 5 – Organograma do Departamento de
Sistemas e Aplicações.
Arquiteto: O objetivo do Arquiteto é desenhar as fundações da aplicação. Inclui estruturar tanto
do ponto de vista lógico, como físico de como a aplicação funcionará, bem como o seu
comportamento no ambiente de produção. Em paralelo, o Arquiteto procura reduzir a
Diretor
Gerente de sistemas
Arquiteto de sistemas
Analista de sistemas Desenvolvedor
Controller
Gerente de Qualidade
Analista de qualidade
Técnico de qualidade
Controller
27
complexidade da aplicação, dividindo-a em partes simples. O uso de boas práticas e modelos de
mercado ajuda o Arquiteto na execução do seu trabalho.
Controller de projetos: O controlador de projetos deverá manter relatório consolidado das
atividades delegadas por meio do sistema de Gestão de Atendimento, das Ordens de Serviço e
dos bilhetes de atividades inseridos nas ferramentas de desenvolvimento, com os respectivos
prazos estabelecidos.
Desenvolvedor: O objetivo do desenvolvedor é transformar as especificações em código. O
desenvolvedor também ajuda na criação da especificação física de algumas funcionalidades,
estimar tempo para a construção, compilar e preparar a aplicação para a distribuição.
Diretor do departamento: O diretor do departamento controla a execução dos projetos
estratégicos e operacionais de todo o departamento. Atua na fiscalização dos contratos para
assegurar o seu correto cumprimento. Fornece parecer aos documentos enviados ao
departamento.
Gerente de sistemas: O objetivo do Gerente do Projeto é entregar o projeto dentro do orçamento
e prazo acordados. Seu trabalho se concentra no planejamento do projeto, elaboração do
cronograma, monitoração das atividades do projeto.
Gerente de qualidade: No ciclo de vida de desenvolvimento de software, o gerente de qualidade
responde pelas ações de controle de qualidade dos produtos, ou seja, se estes foram
desenvolvidos de acordo com as especificações acordadas e se atendem às expectativas dos
clientes (BASTOS, RIOS, et al., 2007).
Técnico de qualidade: O objetivo do técnico de qualidade é descobrir problemas na aplicação e
informá-los para a correção. O trabalho do Testador consiste em executar testes pré-definidos ou
exploratórios, coletar as amostras dos resultados e compará-las com o esperado. Uma vez
detectado um problema, o Testador deve informar à equipe as condições para reprodução do
problema.
28
5.1.2 PROCESSOS
O pilar “processos” é identificado como todo o conjunto de boas práticas, artefatos, guias e
manuais que conduzem a construção e manutenção de uma aplicação.
Entenda que ao falarmos de processos, estamos falando desde os processos de levantamento das
necessidades.
5.1.3 FERRAMENTAS
As “ferramentas” são os meios/equipamentos/tecnologias que automatizam e facilitam a
condução dos processos pelas pessoas. Existem no mercado diversas ferramentas que suportam o
ciclo de vida de aplicações baseada em de ALM, segue abaixo uma lista das que são utilizadas na
Metodologia de Gerenciamento de Projetos de Software (MGPS) do DSA:
Microsoft Team Foundation Server: O Team Foundation Server (TFS) é a plataforma de
colaboração na essência da solução de gerenciamento do ciclo de vida de aplicativos (ALM) da
Microsoft. O TFS oferece suporte para práticas de desenvolvimento ágeis, para vários IDE’s e
plataformas localmente ou na nuvem e fornece as ferramentas necessárias para gerenciar com
eficiência projetos de desenvolvimento de software em todo o ciclo de vida de TI.
Microsoft Visual Studio: O Visual Studio é um pacote de ferramentas de desenvolvimento de
software baseadas em componentes e outras tecnologias para a criação de aplicativos avançados
de alto desempenho. Além disso, o Visual Studio é otimizado para projeto, desenvolvimento e
implantação em equipe usando Visual Studio Online ou Team Foundation Server.
Microsoft Test Manager: Utilizado para testar os aplicativos desenvolvidos. O MTM armazena
planos e resultados de teste no Team Foundation Server (TFS).
Microsoft Sharepoint Server: A integração entre Visual Studio Team Foundation Server e
Produtos do SharePoint fornece a administradores, líderes de projeto e colaboradores do projeto
com o compartilhamento eficiente de dados de conhecimento e ferramentas organizacionais. Essa
integração inclui a opção para criar um site, conhecido como um team project portal, para cada
projeto de equipe. As equipes podem usar este portal para compartilhar a orientação do processo,
os documentos de projeto, modelos e relatórios de acordo com a função de cada membro da
equipe do projeto. É possível usar qualquer versão suportada do Produtos do SharePoint com
Team Foundation Server.
29
Microsoft Project Server: É uma solução online flexível para o gerenciamento de portfólio de
projetos (PPM) e para o trabalho diário. Permite priorizar investimentos em portfólio de projetos
e produzir o valor de negócios pretendido de praticamente qualquer lugar.
Microsoft Release Management: Com o Microsoft Release Management é possível configurar,
aprovar e implantar os aplicativos para qualquer ambiente e de forma automatizada, não importa
o quão complexa é a configuração. O software permite criar um fluxo padrão de subida de verão
com rastreabilidade e qualidade.
Microsoft System Center Operation Manager: A sincronização entre o operations manager e
o team foundation server (TFS) possibilita uma comunicação eficiente entre os desenvolvedores
e as operações de tecnologia da informação (TI). A integridade do ambiente do TFS é essencial
para todos os processos de desenvolvimento. Conforme o ambiente utilizado, é possível importar
pacotes de gerenciamento e monitoramento do TFS que ofereçam visibilidade em tempo real da
integridade do ambiente de desenvolvedor do TFS.
Microsoft System Center Virtual Machine Manager (SCVMM): O Virtual Machine Manager
(VMM) é uma solução de gerenciamento para o datacenter virtualizado, permitindo configurar e
gerenciar o host de virtualização, as redes e os recursos de armazenamento para criar e implantar
máquinas virtuais e serviços nas nuvens privadas criadas.
30
Parte II – Metodologia e processo
31
6 GRUPOS DE PROCESSOS MGPS-DSA
A Metodologia de Gerenciamento de Projetos de Software (MGPS) é composta por três fases e
seis principais processos conforme pode ser visualizado na Metodologia de Gerenciamento de
Projetos de Software (MGPS)Figura 6 – Macrofluxo.
Tudo se inicia sempre que houver algo a ser feito, desde um pedido de melhoria em um sistema à
um projeto de novo de sistema. O processo de Gerenciamento da demanda a demanda é
responsável por fazer a triagem da demanda e direcionar para os outros processos.
O processo de monitoramento e controle suporta todos os outros processos no sentido de fornecer
atividades necessárias para acompanhar, analisar e organizar o progresso e o desempenho do
projeto.
32
Figura 6 – Macrofluxo MGPS-DSA
33
7 FASE DE DEFINIÇÃO
O objetivo desta fase é garantir que a aplicação esteja sempre aderente as necessidades do
negócio. Esta fase também é responsável por estruturar a ideia, definir estratégias, métodos e
ferramentas para guiar a manutenção do produto ou o surgimento. Esta fase é composta pelos
seguintes processos e subprocessos:
1.1. Gerenciamento da demanda
1.2. Concepção da aplicação
1.3.
34
7.1 Gerenciamento da demanda
Este processo tem por objetivo receber todas as demandas originadas pelas áreas de negócio e dar
um tratamento inicial, sejam elas: um projeto, uma manutenção evolutiva ou uma manutenção
corretiva. Para cada tipo de demanda existirá um tratamento específico.
Ao executar as atividades do processo de forma eficiente, amplia-se a colaboração entre a área de
TI e os clientes.
O Gerenciamento de demanda trata-se de um processo contínuo que realiza o encadeamento das
demandas com os serviços e projetos de TI.
35
Figura 7 – Diagrama do processo de Gerenciamento da demanda
36
Tabela 1 – Matriz de responsabilidade Gerenciamento da demanda
Atividades do processo Gestão da demanda
Coo
rden
ador
Ass
esso
ria d
a C
TI
Dire
tor d
o D
SA
Ass
esso
ra D
SA
Ger
ente
de
sist
emas
Con
trolle
r
Arq
uite
to d
e si
stem
as
Ana
lista
de
sist
emas
Des
envo
lved
or
Ger
ente
de
qual
idad
e
Ana
lista
de
qual
idad
e
Técn
ico
de q
ualid
ade
Clie
nte
Realizar triagem da demanda R R/A R
Analisar alinhamento ao PDTI/PTI/PE R/A
Estimar data do projeto R/A C
Comunicar partes interessadas R
Responder solicitação R
Definir chamado em cronograma C R
37
7.1.1 GERENCIAMENTO DA DEMANDA: ENTRADAS
Processo/Expediente: Documentos oficiais do poder judiciário, físicos controlados por
sistema eletrônicos.
Chamado: Um chamado é um pedido de um cliente registrado em um sistema de
gerenciamento de chamados. Normalmente possui um número único, e um prazo de
atendimento.
E-mail: Pedido encaminhado pelo cliente via e-mail para a assessoria do DSA ou
gerentes de equipe;
ATA de reunião: Documento formal que registra as solicitações de clientes durante uma
reunião.
7.1.2 GERENCIAMENTO DA DEMANDA: ATIVIDADES
7.1.2.1 Realizar triagem da demanda
Identificar qual a classificação da demanda e definir para onde deve ser encaminhada. As
demandas são classificadas da seguinte forma:
Novo Projeto: Demanda classificada como Novo projeto deve ser direcionada para a
atividade “Analisar alinhamento ao PDTI/PETIC/PE.”
Manutenção corretiva: Demanda classificada como corretiva deve ser direcionada para
o Processo Gerenciamento de incidentes.
Manutenção evolutiva Demanda classificada como evolutiva, deve ser verificada qual a
forma de entrada:
Artefato de entrada:
Se o artefato de entrada for um oficio, a demanda deve ser direcionada para o
“Processo Gerenciamento do desenvolvimento da aplicação”
Se o artefato de entrada for um “chamado”, o mesmo deverá ser analisado e
inserido em cronograma e direcionado ao “Processo Gerenciamento do
desenvolvimento da aplicação”
38
7.1.2.2 Analisar alinhamento ao PDTI/PETIC/PE
Essa atividade tem como objetivo alinhar se as solicitações para desenvolvimento de novos
projetos estão de acordo com o Planejamento estratégico desse Tribunal, Planejamento
estratégico da TI e do Plano diretor de TI da CTI.
Analise de viabilidade estratégica é responsável por alinhar os projetos solicitados com a
estratégia do Poder Judiciário de Mato Grosso e da CTI, o escritório de projeto utiliza a
viabilidade estratégica para programar as prioridades de execução dos projetos, bem como
planejar a execução dos projetos aprovados parcialmente na viabilidade técnica. Os projetos que
necessitarem de aquisições para sua execução será solicitado ao Diretor do Departamento a
elaboração do termo de referência.
Quando a solicitação estiver alinhada ao PDTI/PETIC/PE deve ser executado o sub processo
Estimar data do projeto.
7.1.2.3 Estimar data do projeto
Este subprocesso tem como principal objetivo organizar os prazos das solicitações enviadas via
expediente ou processo para o Departamento de Sistemas e Aplicações.
Quando um ofício é enviado para alguma equipe de sistema as informações técnicas deverão ser
encaminhadas ao gabinete da diretoria em prazo hábil para a confecção da resposta.
Para as solicitações de novos projetos em que as informações fornecidas na solicitação não são
suficientes para estimar escopo inicial e prazos, é necessário solicitar ao cliente informações mais
detalhadas para que seja possível o andamento do projeto. Essas informações devem ser
registradas no documento “Formulário de pedido de novo sistema” disponível no portal do
departamento de sistemas e aplicações.
Quando esse prazo é suficiente para a resposta deve ser agendada a execução da solicitação no
cronograma, ou seja, deverá se dada uma data prevista de execução da solicitaçãop acordo com
os projetos em andamento e suas respectivas prioridades.
Quando a solicitação já vem com prazo pré-definido para a resposta e o mesmo não for suficiente
deve ser solicitada uma dilação de prazo. A dilaçãp de prazo é um pedido formal via e-mail
39
solicitando ao Coordenador de TI mais tempo para dar uma previsão de execução da solicitação,
para análise necessária e definição de prazo para execução do novo projeto.
7.1.2.4 Responder solicitação
Caso a solicitação não esteja alinhada ao PDTI/PETIC/PE uma resposta fundamentada deve ser
enviada ao solicitante sobre os motivos do indeferimento e o processo Gerenciamento de
Demanda deve ser finalizado.
7.1.2.5 Comunicar partes interessadas
Comunicar aos gestores, gerentes e colaboradores envolvidos no projeto as datas estimadas para
execução do mesmo, e as prioridades considerando os projetos em andamento.
7.1.3 GERENCIAMENTO DA DEMANDA: SAÍDAS
Despcho em ofício
Data prevista para analisar a solicitação
40
7.2 Concepção da aplicação
Concepção da aplicação contempla atividades necessárias à concordância das partes interessadas
com os objetivos, escopo, arquitetura e o planejamento do projeto. Ainda neste processo todas as
ferramentas da plataforma ALM são configuradas para suportar o novo projeto. Os requisitos
iniciais são levantados e registrados no Team Foundation Server (epics).
41
Figura 8 – Diagrama do processo Concepção da aplicação
42
Tabela 2 – Matriz de responsabilidade concepção da aplicação
Atividades do processo Gerenciamento da
demanda
Coo
rden
ador
Ass
esso
ria d
a C
TI
Dire
tor d
o D
SA
Ass
esso
ra D
SA
Ger
ente
de
sist
emas
Con
trolle
r
Arq
uite
to d
e si
stem
as
Ana
lista
de
sist
emas
Des
envo
lved
or
Ger
ente
de
qual
idad
e
Ana
lista
de
qual
idad
e
Técn
ico
de q
ualid
ade
Clie
nte
Elaborar (TAP) Termo de Abertura do Projeto A/R C
Elaborar LTI R A/R C
Alocar Recursos C
Configurar Plataforma ALM A/R
Documentar requisitos de Negócio(Epics) A/R I
Elaborar Plano de entregas (release) A/R
43
7.2.1 CONCEPÇÃO DA APLICAÇÃO: ENTRADAS
Formulário de pedido de novo sistema: Este documento foi criado para que o cliente
forneça o mínimo de informações necessárias para se iniciar a elaboração do termo de
abertura do projeto.
7.2.2 CONCEPÇÃO DA APLICAÇÃO: ATIVIDADES
7.2.2.1 Elaborar TAP
Elaborar o TAP (termo de abertura do projeto) é a atividade de desenvolvimento de um
documento que formalmente autoriza um projeto ou uma fase do projeto e a documentação dos
requisitos iniciais que satisfaçam as necessidades e expectativas das partes interessadas (PMI,
2008).
7.2.2.2 Elaborar LTI
O levantamento técnico inicial é um dos artefatos da análise estruturada para projetos de sistemas
de informação. Ele facilita uma análise preambular deste, sendo de grande relevância durante as
primeiras fases, permitindo a captura de todas as perspectivas que o sistema pode abranger
(WIKIPEDIA, 2013). Serva como ferramenta de auxílio, a evitar alguns dos problemas mais
custosos com que as pessoas envolvidas no projeto poderão ter que se confrontar.
Este documento descreve as perspectivas que o projeto pode abranger, como: Objetivos, Escopo,
Referencia, Benefícios, descrição dos Usuários, Visão geral do Produto, características funcionais
e não funcionais.
7.2.2.3 Alocar recursos
Alocação de recursos é o uma atividade pela qual recursos existentes são distribuídos entre usos
alternativos, que podem ser finais (programas ou atividades-fim), intermediários (os diversos
insumos e atividades necessários à produção do serviço final), ou definidos em termos dos
usuários dos serviços.
44
7.2.2.4 Configurar plataforma ALM
Essa atividade consiste em configurar as ferramentas da Plataforma ALM. A plataforma ALM
consiste de várias ferramentas com objetivos específicos para cada segmento no ciclo de vida da
aplicação.
7.2.2.4.1 Configurando o Project Server
Os projetos deverão ser gerenciados por meio da ferramenta Microsoft Project Server, para isso
deverá ser criado os projetos de acordo com o portfólio da Coordenadoria de Tecnologia da
Informação.
Após a criação do projeto no TFS, este deverá ser sincronizado com o projeto no Microsoft
Project Server de modo que as alterações feitas no TFS reflitam nos projetos no Project Server,
para isso utilize a aba “Team” e escolha “Choose Team Project” para poder criar e/ou exibir itens
do TFS.
7.2.2.4.2 Configurando o TFS
Para que a equipe do DSA possa começar a trabalhar, é necessário criar o Team Project no TFS
para estabelecer um repositório de código-fonte e um lugar para as equipes planejar, acompanhar
e colaborar com o ciclo de vida da aplicação.
Para isso utilize a ferramenta Microsoft Visual Studio e por meio da opção New Team Project
Wizard crie o Team Project, conforme pode ser visto na Figura 9 – Criando um novo projeto. Em
seguida escolha a última versão do MSF for Agile Software Development – TJMT3 e em seguida
escolha qual será o gerenciador de controle de versões podendo ser o TFS ou GIT.
3 Microsoft Solution Framework personalizad para a metodologia do DSA.
45
Figura 9 – Criando um novo projeto no visual Studio
Fonte: http://msdn.microsoft.com/en-us/library/ms181477.aspx
Quando terminar, é possível ver o Team Project no Team Explorer. Também é possível escolher
o Acesso Web link para se conectar ao seu Team project usando o Team Web Access.
7.2.2.4.3 Configuração das branches
É necessário também a criação da estrutura básica dos arquivos e Branches que está definida no
Documento “Padrões de Desenvolvimento” do DSA e ilustrada na Figura 10 – Organização das
branches na metodologia.
Figura 10 – Organização das branches na metodologia
Fonte: Adaptado http://vsarbranchingguide.codeplex.com/
Após a criação do projeto, devem ser adicionado os grupos da equipe do Active Directory em
cada grupo padrão do TFS. Ex.: Adicionar o grupo do AD “ALM_Gerentes_Qualidade” no
46
grupo do TFS “Project Administrator”. As informações de grupos e permissões pode ser
visualizado no documento de Permissões do ALM .
7.2.2.4.4 Visual Studio ou Eclipse
Para configurar o restante das ferramentas, é necessário a criação da arquitetura básica do
sistema. Esta arquitetura deve possuir o arquivo de configuração (.proj) dos projetos que serão
publicdados (este arquivo normalmente é criado pelas IDEs Visual Studio (.csproj) ou
Eclipse(.proj).
O Arquiteto da equipe deve criar a arquitetura do sistema e então realizar o primeiro check-in dos
arquivos para o TFS. Com isso, será possível a criação das Builds dos projetos publicáveis.
Deve-se então vincular as políticas de check in “Work Items” e “Changeset Comments Policy” no
projeto criado para que a equipe sempre informe e vincule as tarefas a suas mudanças de código.
7.2.2.4.5 Team Foundation Server – Builds
A Build do projeto é o processo de se gerar os arquivos de uma versão do sistema a partir do
código fonte. Esses arquivos podem conter scripts de banco de dados, imagens, binários, etc.
O Arquiteto da equipe deve criar as builds de cada projeto seguindo as configurações definidas
no Documento “Padrões de Desenvolvimento” do DSA. Neste processo, um administrador do
ALM pode acompanhar para colaborar com sua configuração.
O projeto deve possuir pelo menos 4 Builds que são referentes a cada ambiente disponibilizado
para a plataforma ALM. São elas: Alpha (ambiente de desenvolvimento), Beta (ambiente de
teste), RC (ambiente de homologação) e Stable (ambiente de produção).
7.2.2.4.6 Release Management
A ferramenta Release Management é responsável por distribuir os arquivos gerados por uma
Build e publicar em um ou mais servidores para lançar uma versão. Este processo é denominado
de Deploy. Permite executar qualquer tarefa necessária para o lançamento completo de uma
versão, tais como execução de script em um servidor de banco de dados, cópia dos arquivos em
determinado local no servidor de aplicação, configuração do servidor de aplicação, etc. Nesta
47
ferramenta, também é permitido aos administradores do ALM configurar o fluxo de aprovações
necessárias para que uma versão de sistema seja publicada em ambiente de produção.
Deverá também ser criado os Releases Templates de cada Build existente para seu ambiente
definido. As convenções/configurações estão definidas no Documento “Padrões de
Desenvolvimento” do DSA. Durante a criação da Release Template, as permissões a ela devem
ser atribuídas conforme o documento de Permissões no ALM .
Figura 11 – Fluxo de uma release
Só é possível criar uma Release Template a partir de uma Build existente.
7.2.2.4.7 Reporting Services
Reporting Services é um recurso que permite a visualização e criação de relatórios extraindo
informações de todas as ferramentas do ALM. Durante a criação de um projeto no TFS, alguns
relatórios são criados por padrão e servem como base para estratificar informações estatísticas
como “Quantidade de Bugs”, “Builds realizadas”, “Quantidades de Tarefas”, etc.
48
As permissões deverão ser atribuídas aos grupos da equipe no diretório do projeto para que estes
possam utilizar estes recursos. As permissões que devem ser atribuídas e os grupos que irão
recebe-las estão descritas no documento Permissões no ALM .
7.2.2.4.8 Sharepoint
Sharepoint é uma ferramenta para colaboração entre as equipes, disponibilização de artefatos
referente aos projetos, entre outros recursos. As permissões para a utilização dessa ferramenta
deverão ser atribuídas aos grupos da equipe no portal do projeto para que estes possam utilizar os
recursos do portal. As permissões serão concedidas de acordo com o documento Permissões no
ALM .
7.2.2.4.9 IIS (Servidor de Aplicação)
IIS é o Servidor de aplicação onde fica hospedada um sistema. Este servidor deversá ser
configurado em cada ambiente para que aponte para o local onde o Release Management fará o
Deploy dos arquivos.
7.2.2.4.10 Ambientes
O publicador do ALM é responsável por validar que as Builds, Releases Templates e Servidores
de Aplicação (IIS) estejam compatíveis e configuradas de acordo para que seu fluxo funcione de
forma rápida e célere. Os objetivos de cada ambiente são:
Ambiente de Desenvolvimento: Onde o desenvolvedor executa alterações e pode
visualizar a partir da sua própria branch. Normalmente é para desenvolver e testar uma
pequena feature.
Ambiente de Teste: Onde a equipe de qualidade pode testar uma versão completa do
sistema.
Ambiente de Homologação: Onde é testado o impacto das modificações a serem feitas
em produção e também onde o teste de aceitação é realizado.
Ambiente de Produção: Ambiente onde os usuários finais utilizam o sistema.
49
7.2.2.5 Documentar requisitos de negócio
Existem diversos tipos de requisitos que são normalmente classificados em níveis e são derivados
do mais alto nível ao mais baixo nível e a partir do problema de negócio é possível identificar os
requisitos de negócio.
Requisito de negócio é a definição de como o negócio funciona, ela evidencia as restrições
existentes para o funcionamento de determinado negócio, podendo abranger qualquer assunto.
Além disso, a regra de negócio não depende da existência de um sistema. Os requisitos de
negócios deverão ser cadastrados no Team foundation server no formato de Features conforme a
Figura 12 – Relação requisitos x work items.
Figura 12 – Relação requisitos x work items
7.2.2.6 Elaborar plano de entregas (release)
O plano de entregas estabelece a meta da versão, as maiores prioridades do Product Backlog, os
principais riscos e as características gerais e funcionalidades que estarão contidas na versão. Ele
estabelece também uma data de entrega e custo prováveis que devem se manter se nada mudar. A
organização pode então inspecionar o progresso e fazer mudanças nesse plano da versão para
entrega a cada Sprint.
Requisitos de negócio
Requisitos funcionais e não funcionais
Especificações (requisitos detalhados)
Feature
User story
Task
50
O plano de release define quando as funcionalidades ou um conjunto delas serão entregues ao
cliente. Seu principal objetivo é permitir que o time de desenvolvimento tenha uma visão de
quando as entregas serão efetuadas ao cliente.
7.2.3 CONCEPÇÃO DA APLICAÇÃO: SAÍDAS
Epics (lista de funcionalidades);
Plano de release;
Políticas do ALM;
Team collection do projeto;
Portal do sistema;
Portal do projeto.
51
8 FASE DE CONSTRUÇÃO
Esta fase está essencialmente relacionada à codificação e teste do sistema ou componente, ao
final deve-se ter um sistema de software em funcionamento e a documentação associada pronta
para ser liberada para os usuários (SENE, 2011).
É na fase de construção que a maior parte de codificação ocorre. É prevista para ocorrer de forma
iterativa e incremental, de acordo com o plano de releases criado na atividade Elaborar plano de
entregas (release).
As iterações são um time box4 de aproximadamente 2 a 4 semanas. Se todas as funcionalidades
demandarem esforço inferior a 4 semanas, sugere-se a utilização de apenas uma iteração. Caso a
duração seja superior, a construção deve considerar múltiplas iterações, com a priorização do que
deve ser implementado na iteração ocorrendo no início da mesma, conforme fluxo a ser
apresentado na próxima seção. Esta fase é composta pelos seguintes processos e subprocessos:
1.1. Desenvolvimento da aplicação
1.1.1. Planejar iteração
1.1.2. Executar iteração
1.1.2.1. Construção e testes unitários
1.1.2.2. Planejar testes
1.1.2.3. Executar testes
1.1.2.4. Gestão do conhecimento
8.1 Desenvolvimento da aplicação
O processo de Desenvolvimento da aplicação é responsável por organizar as iterações e executar
a construção da melhoria. A parte mais relevante deste processo ocorre dentro da iteração onde
estão a maior parte das atividades executadas. Iterações são eventos com duração fixa onde o
4 Termo utilizado em métodos ágeis que representa o prazo inflexível de tempo alocado para uma tarefa específica.
52
time busca sempre atingir a meta que foi estabelecida. Tanto a composição do time quanto as
metas de qualidade devem permanecer constantes durante a iteração (SCHWABER, 2009).
As iterações consistem na reunião de planejamento, o trabalho de desenvolvimento e a revisão da
iteração. A retrospectiva da iteração é opcional para as equipes e ocorre dentro da fase de
monitoramento e controle. As iterações deverão ocorrer uma após a outra, sem intervalos entre
elas.
53
Figura 13 – Diagrama de do processo Desenvolvimento da aplicação
54
Atividades do processo Desenvolvimento da
aplicação
Coo
rden
ador
Ass
esso
ria d
a C
TI
Dire
tor d
o D
SA
Ass
esso
ra D
SA
Ger
ente
de
sist
emas
Con
trolle
r
Arq
uite
to d
e si
stem
as
Ana
lista
de
sist
emas
Des
envo
lved
or
Ger
ente
de
qual
idad
e
Ana
lista
de
qual
idad
e
Técn
ico
de q
ualid
ade
Clie
nte
Levantar requisitos A/R C
Registrar user stories no product backlog A/R R
Planejar iteração R/A C C C
Executar iteração A/R R R R
Gerar build stable C/I A/R I I I
55
8.1.1 DESENVOLVIMENTO DA APLICAÇÃO: ENTRADAS
Requisitos de negócio
Plano de release
8.1.2 DESENVOLVIMENTO DA APLICAÇÃO: ATIVIDADES
8.1.2.1 Levantar requisitos
É essencial que os requisitos sejam completos, claros, corretos e consistentes, porque eles servem
como pilares da solução para as necessidades do negócio (Guia BABOK®, 2011).
Podem ser utilizadas diversas técnicas durante a execução desta atividade, porém a mais
amplamente aceita pelos os clientes do DSA é para levantamento de requisitos é a aplicação de
entrevistas e questionários.
Durante a atividade de levantamento de requisitos é essencial que os critérios de aceitação
sejam especificados junto ao cliente, pois é por meio destes que os testes serão executados e as
funcionalidades serão validadas pelo cliente.
Todos os documentos gerados no levantamento de requisitos, tais como atas, caso de uso,
modelos dentre outros, deverão ser armazenados na pasta Shared documents, que está
localizada dentro do portal do sistema, na subpasta
8.1.2.2 Registrar user stories no Product Backlog
O product backlog pode ser formado por diversos itens, como requisitos funcionais, requisitos
não-funcionais, correções ou outros itens que agregam valor ao produto (WEISS, 2013), porém
para esta metodologia o item a ser utilizado será a User Story5 quando se tratar de um requisito.
As user stories podem ser cadastradas utilizado o Team web access. As informações obrigatórias
no cadastro de uma user storie são:
5 A user story (história de usuário), é uma descrição concisa de uma necessidade do usuário do produto (ou seja, de um “requisito”) sob o ponto de vista desse usuário. A User Story busca descrever essa necessidade de uma forma simples e leve.
56
Figura 14 – Cadastro de user story no team web access
Título: Breve descrição do que a história irá entregar.
Details: Forneça detalhes suficientes para fazer a estimativa do trabalho necessário para
implementar a história. Foque no objetivo do recurso, no que os usuários desejam fazer e
por quê. Não descreva como o recurso deve ser desenvolvido. Forneça detalhes
suficientes para que sua equipe possa escrever tarefas e casos de teste para implementar o
item. Veja um exemplo dos detalhes de uma user story na Figura 15 – Formato dos
detalhes de uma user story
Assigned to: O proprietário da user story. De forma simplista, é o usuário ou o
interessado em um funcionalidade.
State: Quando o item de trabalho é criado, o status assume por padrão o valor New.
Conforme o trabalho progride, atualize-o para refletir o estado atual.
Story points: Estimativa da quantidade de trabalho necessária para concluir uma user
story usando qualquer unidade de medida que sua equipe preferir.
57
Area: Escolha o caminho de área associado ao produto ou à equipe, ou deixe em branco
até ser atribuído durante uma reunião de planejamento.
Iteration: Iteração em que o trabalho deve ser concluído, ou deixe em branco e atribua
posteriormente, durante uma reunião de planejamento.
Figura 15 – Formato dos detalhes de uma user story
Fonte: Adaptada de (WEISS, 2013)
Após registrar as user stories no Product backlog o fluxo deve ser direcionado para o processo
Planejar iteração.
8.1.2.3 Planejar iteração
O processo de Planejar iteração é uma reunião na qual estão presentes o cliente, o e todo o time6
de desenvolvimento, bem como qualquer pessoa interessada que esteja representando a gerência
ou o cliente (Sprint Planning Meeting, 2013).
O objetivo da primeira parte da reunião é entender o que cada user story representa e em seguida
selecionar quais serão desenvolvidas dando origem ao backlog da iteração. Coletivamente, o time
e o cliente definem um objetivo para o iteração, que é uma breve descrição daquilo que se tentará
alcançar.
6 No scrum um time é composto por três papéis: Scrum máster, product owner e a equipe
58
Na segunda parte da reunião de planejamento da iteração, a equipe7 se encontra separadamente,
sem o cliente, para conversar sobre como será desenvolvida cada user story e o quanto eles
podem se comprometer a fazer na iteração que será iniciada. Em alguns casos, haverá negociação
com o cliente, mas será sempre responsabilidade da equipe determinar o quanto ela será capaz de
se comprometer a fazer.
7 A equipe scrum é que desenvolve e testa o produto.
59
Figura 16 – Diagrama do processo planejar iteração
Tabela 3 – Matriz de responsabilidade planejar iteração
60
Atividades do processo Gerenciamento da
demanda
Coo
rden
ador
Ass
esso
ria d
a C
TI
Dire
tor d
o D
SA
Ass
esso
ra D
SA
Ger
ente
de
sist
emas
Con
trolle
r
Arq
uite
to d
e si
stem
as
Ana
lista
de
sist
emas
Des
envo
lved
or
Ger
ente
de
qual
idad
e
Ana
lista
de
qual
idad
e
Técn
ico
de q
ualid
ade
Clie
nte
Explicar user stories ao time A/R
Selecionar itens do backlog para iteração R R A/R
Decompor user stories em tasks R R
Estimar prazos para as tasks I C C R/C C C
Distribuir tasks A/R
61
8.1.2.3.1 Planejar iteração: Entradas
Capacidade do time: É um valor que representa a capacidade produtiva ou velocidade de
um time. É o mesmo que definir quantas histórias um time consegue entregar numa
iteração, baseando-se no histórico do time.
Backlog do produto priorizado: Backlog ordenado com as user story de maior valor
para o negócio em primeiro lugar da lista. Para que o product backlog já esteja priorizado
é necessário executar regularmente o processo Backlog Grooming.
Incremento do produto recente: Conjunto de funcionalidades potencialmente entregável
que foram desenvolvidas durante uma iteração. Incremento de produto
8.1.2.3.2 Planejar iteração: Atividades
8.1.2.3.2.1 Explicar user stories ao time
Esta atividade deve ser executada preferencialmente pelo cliente, porém existem projetos nos
quais o cliente não se envolve com o processo de desenvolvimento. Nesses casos deverá ser
elencado uma pessoa para representar o cliente durante as reuniões.
O cliente ou seu representante não precisa descrever todos os itens que estão no product backlog.
Dependendo do tamanho do Product Backlog e da velocidade da equipe, pode ser suficiente
descrever apenas os itens de maior prioridade, deixando a discussão dos itens de menor
prioridade para a próxima reunião de planejamento da iteração.
Nota: Para se executar esta atividade é necessário que o product backlog já esteja priorizado.
Esta priorização é feita na atividade de Backlog Grooming fase de .
8.1.2.3.2.2 Selecionar itens do product backlog
Depois de entender e estimar a complexidade dos itens de backlog o time de desenvolvimento
seleciona, respeitando a prioridade, os itens que acredita que consegue entregar na iteração e
acorda estes com o cliente, formando assim o backlog da iteração.
Para executar esta atividade é necessário que o backlog já esteja priorizado. Esta atividade é
feita regularmente no Backlog Grooming.
62
8.1.2.3.2.3 Decompor user stories em tasks
O time de desenvolvimento discute como entregar cada um dos itens selecionados e quais são as
tarefas (tasks) que precisam ser feitas. São discutidos todos os tipos de atividades que podem ser
necessárias, podendo ser dos seguintes tipos:
Desenvolvimento
Deploy
Desenho
Documentação
Levantamento de requisitos
Teste
8.1.2.3.2.4 Estimar prazos para as tasks
As tarefas deverão ser estimadas em horas e os responsáveis pelas atividades devem informar
quanto tempo será necessário para executar a atividade.
É importante que os prazos inseridos nas tarefas sejam realistas, pois será por meio deles que a
equipe poderá acompanhar se a meta da iteração será alcançada dentro do prazo acordado.
8.1.2.3.2.5 Distribuir tasks
As tarefas devem ser distribuídas para os responsáveis pela execução Para isso basta assinar a
tarefa com o nome de quem a executará. Para fazer a distribuição das tarefas siga os passos
abaixo:
1. Entre no Team Foundation Server (TFS) por meio de um navegador;
2. Procure pelo projeto desejado;
3. Clique na aba Work;
4. Clique em backlog;
5. Escolha a iteração atual;
Visualize os detalhes de cada tarefa e no campo Assigned to atribua o nome de quem executará a
tarefa. Faça isso para todas as tarefas de todas as histórias.
63
8.1.2.3.3 Planejar iteração: Saídas
Backlog da iteração: Os itens selecionados do backlog do produtos mais as tarefas
necessárias para transformá-los em incremento de software pronto e potencialmente
utilizável é. Após a execução do fluxo planejar iteração deve ser direcionado para o fluxo
executar iteração.
64
8.1.2.4 Executar iteração
O processo de executar iteração é onde os desenvolvedores e testadores trabalham com mais
intensidade, é basicamente a codificação e teste ocorrem de forma a concluir os itens do backlog
da iteração.
O processo de Executar iteração pressupõe que o desenvolvimento da aplicação e os testes sejam
realizados em paralelo ao longo de todo o processo de desenvolvimento conforme explica
(BASTOS, RIOS, et al., 2007).
65
Figura 17 – Diagrama Executar iteração
Tabela 4 – Matriz de responsabilidade Executar iteração
66
Atividades do processo Executar Iteração
Coo
rden
ador
Ass
esso
ria d
a C
TI
Dire
tor d
o D
SA
Ass
esso
ra D
SA
Ger
ente
de
sist
emas
Con
trolle
r
Arq
uite
to d
e si
stem
as
Ana
lista
de
sist
emas
Des
envo
lved
or
Ger
ente
de
qual
idad
e
Ana
lista
de
qual
idad
e
Técn
ico
de q
ualid
ade
Clie
nte
Construção e testes unitários R/A
Planejar testes C C R/A
Lançar versão beta R/A I
Executar testes de sistema C R/A
Gestão do conhecimento Ck A R R I
Lançar versão RC A/R
67
8.1.2.4.1 Executar iteração: Entradas
Tasks
8.1.2.4.2 Executar iteração: Atividades
8.1.2.4.2.1 Construção e testes unitários
A contrução e testes unitários é uma atividade exclusiva da equipe de desenvolvimento. O
desenvolvedor escreve o código necessário e faz alguns testes preliminares, utilizando a análise
de código e ferramentas de teste de unidade estáticos.
68
Figura 18 – Diagrama do processo Construção e testes unitários
69
Tabela 5 – Matriz de responsabilidade Construção e testes unitários
Atividades do processo Construção e testes
unitários
Coo
rden
ador
Ass
esso
ria d
a C
TI
Dire
tor d
o D
SA
Ass
esso
ra D
SA
Ger
ente
de
sist
emas
Con
trolle
r
Arq
uite
to d
e si
stem
as
Ana
lista
de
sist
emas
Des
envo
lved
or
Ger
ente
de
qual
idad
e
Ana
lista
de
qual
idad
e
Técn
ico
de q
ualid
ade
Clie
nte
Puxar Task A/R
Codificar Incremento A/R
Realizar Check in A/R
Gerar build alpha A/R I
Testes Unitários automatizados A/R
Marcar user stories como resolved A/R
70
8.1.2.4.2.1.1 CONSTRUÇÃO E TESTES UNITÁRIOS: ENTRADAS
Task
Padrões de desenvolvimento DSA
8.1.2.4.2.1.2 CONSTRUÇÃO E TESTES UNITÁRIOS: ATIVIDADES
8.1.2.4.2.1.2.1 Puxar task
Nesta atividade o desenvolvedor utiliza a própria IDE de desenvolvimento para iniciar a
execução de seu trabalho. O principal objetivo desta atividade é marcar a task com o status
Active. Para isso o desenvolvedor deverá procurar a task utilizando a ferramenta Team Explorer
localizada em View Team explorer. Em seguida procure pela opção Work Items e na seção
Queries procure pela query My tasks.
Visualize os detalhes na task que deseja iniciar o trabalho e em seguida altere seu status para
Active, salve e inicie o trabalho.
Caso o desenvolvedor possua o Visual Studio Premium ou superior é possível utilizar a opção
my work dentro do team explorer para dar andamento nas tasks ou outros tipos de work items
que estejam assinador para ele.
8.1.2.4.2.1.2.2 Codificar incremento
Nesta etapa o desenvolvedor começa a codificar de acordo com as normas estabelecidas no
documento “Padrões de desenvolvimento” localizado em: Padrões de Desenvolvimento .
Para todos os novos projetos ou onde for possível, deve-se criar os testes unitários que será
utilizado para validar o código.
Durante este desenvolvimento, qualquer mudança referente a arquitetura do sistema deve ser
acordado com o arquiteto da equipe.
8.1.2.4.2.1.2.3 Realizar check in
Realizar check in é o processo de envio do código realizado localmente na estação de trabalho do
desenvolvedor para o TFS.
71
Para executar esta ação no Visual Studio, abra a Solution Explorer (Menu View Solution
Explorer) e clique com o botão direito no item cujo seus respectivos itens abaixo na hierarquia
será enviado e clicar em Source Control Check In. Irá então abrir o “Team Explorer” na área
de “Pending Changes”, nesta deve-se informar em Comment as informações sobre o que
representa estas alterações e em Related Work Items deve-se adicionar os work items que estão
relacionados a estas alterações. Após isto é somente clicar em Check In para que as informações
sejam enviadas para o servidor.
Todos os check in devem obrigatoriamente possuir um comentário e um work item vinculado
definido pela política do projeto.
Ao realizar o check in, é gerada uma Build do tipo Alpha e realizado automaticamente o deploy
pela ferramenta “Release Management”. A Build Alpha está ligada a uma branch de
desenvolvimento (Dev) o que significa que esta build é para ser validada e testada somente
naquela feature que originou a Branch.
8.1.2.4.2.1.2.4 Testes Unitários Automatizados
Os testes unitários consistem em validar dados válidos e inválidos via I/O (entrada/saída) sendo
aplicado por desenvolvedores ou analistas de teste. Uma unidade é a menor parte testável de um
programa de computador. Esses testes devem ser executados automaticamente em cada build
criada, o que permite verificar a cobertura de código, quantidade de testes falhos e teste de
impacto.
8.1.2.4.2.1.2.5 Marcar User Story como Resolved
O status da user story é marcado como resolved quando seu código já está completo, ou seja,
quando todas as tarefas de desenvolvimento já foram concluídas, e nenhum defeito foi
encontrado nos testes unitários, conforme pode ser visto na Figura 19 – Diagrama de status da
user story.
72
Figura 19 – Diagrama de status da user story
Fonte: (MSDN, 2013)
8.1.2.4.2.1.3 CONSTRUÇÃO E TESTES UNITÁRIOS: SAÍDAS
User story construída
73
8.1.2.4.2.2 Planejar testes
Cada cenário será representado por um conjunto de casos de teste a ser validado por uma lista de
procedimentos, incorporados numa suíte de testes que posteriormente será executada. Os casos de
testes estabelecem quais informações serão empregadas durante os testes desses cenários, quais
os resultados esperados e a massa crítica de testes necessária para validar todos os requisitos de
software.
O plano de caso de teste é o documento que registra todo o planejamento dos testes dos requisitos
estabelecidos durante o ciclo de desenvolvimento do software. Esse documento determina o que
será testado, e seu principal objetivo consiste em identificar o maior número de cenários e
variações de determinado requisito de software (BASTOS, RIOS, et al., 2007).
74
Figura 20 – Diagrama do processo Planejar testes
75
Tabela 6 – Matriz de responsabilidade Planejar testes
Atividades do processo Planejar testes
Coo
rden
ador
Ass
esso
ria d
a C
TI
Dire
tor d
o D
SA
Ass
esso
ra D
SA
Ger
ente
de
sist
emas
Con
trolle
r
Arq
uite
to d
e si
stem
as
Ana
lista
de
sist
emas
Des
envo
lved
or
Ger
ente
de
qual
idad
e
Ana
lista
de
qual
idad
e
Técn
ico
de q
ualid
ade
Clie
nte
Receber task R
Organizar suítes de teste A/R
Elaborar / resetar casos de teste A/R
Reconhecer defeito(s) C R
Corrigir defeito R
Agendar correção A/R R
Encerrar o Bug R
Solicitar teste A/R
76
8.1.2.4.2.2.1 PLANEJAR TESTES: ENTRADAS
Task de teste
Critérios de aceitação
8.1.2.4.2.2.2 PLANEJAR TESTES: ATIVIDADES
8.1.2.4.2.2.2.1 Receber task
Antes de começar a realizar o planejamento dos testes é necessário que uma task já esteja
cadastrada na user story a ser testada. A task para planejar os testes deverá ser escrita durante o
processo de Planejar iteração, onde são definidos quais tarefas são necessárias para a entrega
daquele pacote, no caso a user story.
Para receber a task de teste siga os passos abaixo:
1. Abra o Microsoft Test Manager;
2. Selecione o projeto desejado;
3. Selecione o plano de teste
4. Clique na aba Track;
5. Abra a pasta Shared queries;
6. Abra a pasta Consutlas equipe de qualidade;
7. Execute a query Minhas tarefas;
8. Visualize os detalhes da task e altere o status para Active
9. Clique em salvar
8.1.2.4.2.2.2.2 Organizar suítes de teste
E recomendável que as as suítes de teste sejam organizadas utilizando o mesmo formato que a
arquitetura do software foi organizada. Os casos de teste devem estar organizados dentro de um
dos seguintes tipos de suítes de teste:
Suite de teste baseado em requisitos – Inclui qualquer caso de teste que esteja linkado à
uma user story. O mais indicado é que todas as suítes de testes sejam linkadas à algum
requisitos que estão sendo implementados na iteração. Desta forma, é possível criar e
77
executar casos de testes que verificam se a aplicação está entregando o que foi prometida
na funcionalidade.
Suite baseada em consultas – Permite que seja especificada um conjunto de work items
baseados em uma consulta. Por exemplo, é possível querer incluir todos os casos de teste
com prioridade de nível 1, mesmo se estes requisitos já foram concluídos em outras
iterações. Ajuda a garantir que funcionalidades críticas que já foram implementadas não
foram impactadas pelas novas alterações (teste de regressão).
Suite de teste estática – Trata-se de uma lista de casos de teste que podem ser adicionadas
manualmente na suíte. Uma suíte de teste estática também pode ser usada como um
contêiner para outras suítes de teste, fornecendo uma estrutura hierárquica para
organização dos testes.
Sempre que possível, utilize a suite de teste baseada em requisitos.
8.1.2.4.2.2.2.3 Elaborar / resetar casos de teste
Na ferramenta Microsoft Test Manager ao clicar na aba Plan Conteúdo, é possível e organizar
os casos de teste que compõem o Plano de teste. Um caso de teste é um conjunto de interações
com uma aplicação de software que são projetados para validar a funcionalidade ou o
comportamento do aplicativo. Por exemplo, pode existir um caso de teste que confirme que um
novo usuário pode criar uma conta dentro de sua aplicação.
8.1.2.4.2.2.2.4 Solicitar teste
Após a criação do planejamento de teste por meio de suítes de teste e casos de teste, o analista de
qualidade deve solicitar a execução desses testes. Para isso deverá ser aberta uma task de teste. A
abertura da task de teste deverá obrigatoriamente conter os seguintes campos:
1. Título: Nome da tarefa com título intuitivo como: “Testar user story”
2. Assigned to: Responsável por executar os testes;
3. Activity: Deverá ser escolhida a atividade “testing”
4. Details: Descrição de quais casos de testes deverão ser testados.
78
Após a execução da atividade solicitar teste, deve ser direcionado a execução do Processo
Executar Testes.
8.1.2.4.2.2.2.5 Reconhecer defeito(s)
Depois de detectado o defeito, o analista de teste em conjunto com o analista de sistemas devem
verificar e decidir se ele é válido ou não, e analisar sua criticidade. Um defeito que impacta na
release atual deveser corrigido o mais rápido possível, caso contrário sua correção deve ser
definida em qual release esta correção deve ser entregue. Se o defeito reportado pelos técnicos de
qualidade não for válido o fluxo deve ser direcionado para atividade Encerrar o Bug.
8.1.2.4.2.2.2.6 Corrigir defeito
Após o defeito ser reconhecido como válido e também como um defeito crítico, ou seja, um
defeito que irá impactar a release a ser lançada, é necessário realizar a correção deste.
8.1.2.4.2.2.2.7 Agendar correção
Um defeito reconhecido como válido mas não considerado urgente pode ser agendado para ser
corrigido em uma outra iteração. Para isso deve ser iniciado a execução do processo
Desenvolvimento da aplicação.
8.1.2.4.2.2.2.8 Encerrar o Bug
Caso o analista de teste e o analista de sistema identifiquem que o defeito não é válido, o bug
deverá ser encerrado. O status o bug deverá constar como closed e o campo Reason deverá estar
marcado como verified, como pode ser observado na Figura 21 – Transição de status dos bugs no
MSF. Para alterar o status do bug siga os passos abaixo:
1. Acesse o team projeto na ferramenta Team Fondation Web Access;
2. Escolha o projeto desejado;
3. Clique me work;
4. Clique em queries;
5. Procure o bug utilizando uma das queries já cadastradas;
6. Visualize os detalhes dos bugs;
79
7. Altere o campo State para Closed;
8. Clique em salvar no ícone semelhante a um disquete.
O framework da Microsoft MSF não trata dos bugs juntos ao backlog do produto, sendo tratado
em um processo chamado Bug triage, por isso há necessidade de consutlar os bugs por meio de
uma consulta.
Os bugs possuem status diferente das user stories e das tasks, seguindo o fluxo mostrado na
Figura 21 – Transição de status dos bugs no MSF.
8.1.2.4.2.2.3 PLANEJAR TESTES: SAÍDAS
Casos de teste
Bug encerrado
80
Figura 21 – Transição de status dos bugs no MSF
8.1.2.4.2.3 Lançar versão BETA
A versão beta é lançada após todos os itens previstos na iteração terem sido desenvolvidos e seus
testes planejados. Se algum teste unitário for reprovado a versão beta não poderá ser lançada até
que todos os defeitos primários tenham sido corrigidos.
Para lançar a versão Beta, deve-se fazer um merge da(s) branch(s) de desenvolvimento para a
branch MAIN (ambiente de teste), efetuar o check in e então gerar uma build Beta.
Para saber mais sobre o que cada versão represenda no fluxo do ALM veja a Figura 22 – Ciclo de
vida das releases.
81
Figura 22 – Ciclo de vida das releases
Fonte: Adaptado de (CAMARGO, 2009)
8.1.2.4.2.4 Executar testes de sistema
O responsável pelos testes deve utilizar a ferramenta Test Professional Manager para gerenciar e
executar um conjunto de casos de teste manuais, na intenção de encontrar a maior quantidade
possíveis de defeitos no software e registrar os bugs para a equipe de desenvolvimento.
Embora o ciclo de vida de teste seja totalmente independente do ciclo de vida de
desenvolvimento, os testes só poderão ser executados após a conclusão dos produtos do ciclo de
vida de desenvolvimento (BASTOS, RIOS, et al., 2007).
Os bugs gerados neste processo contêm diversas informações para o desenvolvedor, incluindo um
vídeo do test case executado pelo responsável dos testes (screenshots), log de eventos a partir do
momento que o teste iniciou.
As atividades do ciclo de vida de testes devem ser executadas por um grupo formalmente
definido para a realização dos testes, para que sejam bem realizadas.
Alpha- Versão em construção ainda não disponível para uso
Beta - Primeira versão disponibilizada para a equipe de qualidade ou alguns usuários.
Release candidate (RC) - O mais próximo da versão final, pois a maioria dos defeitos já foi corrigda
Stable - Versão final que vai para o ambiente de produção
82
Figura 23 – Diagrama Executar testes de sistema
83
Tabela 7 – Matriz de responsabilidade Executar testes de sistema
Atividades do processo Executar Testes
Coo
rden
ador
Ass
esso
ria
da C
TI
Dir
etor
do
DSA
Ass
esso
ra D
SA
Ger
ente
de
sist
emas
Con
trol
ler
Arq
uite
to d
e si
stem
as
Ana
lista
de
sist
emas
Des
envo
lved
or
Ger
ente
de
qual
idad
e
Ana
lista
de
qual
idad
e
Téc
nico
de
qual
idad
e
Clie
nte
Receber task R/A
Procurar defeito(s) R/A
Reprovar caso de teste I R/A
Relatar defeito(s) I I R/A
Encerrar task R/A
84
8.1.2.4.2.4.1 EXECUTAR TESTES DE SISTEMA: ENTRADAS
Casos de teste
Task de teste
8.1.2.4.2.4.2 EXECUTAR TESTES DE SISTEMA: ATIVIDADES
8.1.2.4.2.4.2.1 Receber task
Antes dos testes serem executados é necessário que uma task seja aberta, como forma de registro
da solicitação da execução dos testes. Quem registra essa task é o analista de teste e quem recebe
a task é o técnico de teste. Nesta task de teste deverá conter quais casos de testes deverão ser
testados. Para que o técnico de teste acesse a task deve ser verificado os passos abaixo:
1. Abra o Microsoft Test Manager e selecione a aba Track;
2. Abra a pasta My queries e realize a consulta;
3. Localize a Task desejada e visualize os detalhes
4. Mude o status da task para active.
8.1.2.4.2.4.2.2 Procurar defeitos
Nesta atividade o técnico de teste irá procurar defeitos nas features implementadas por meio de
heurística, ou seja, tenta identificar defeitos no software por meio da análise e interpretação de
um conjunto de princípios. Para executar os testes é necessário abrir a ferramenta test run
executando as seguintes instruções abaixo:
1. Abra o Microsoft Test Manager;
2. Escolha o projeto desejado;
3. Escolha o plano de teste desejado;
4. Selecione qual caso de teste será testado de acordo com a task aberta pelo analista de
teste;
5. Clique em run e o test runner será aberto;
6. Realize os testes de acordo com o que foi planejado.
85
Se precisar interromper a execução do teste, pause o teste, pois qualquer ação que não faça
parte do fluxo básico será capturada pela ferramenta.
Se durante a execução dos testes não for detectados defeitos, o fluxo do processo
deve ser direcionado a atividade encerrar task.
Se durante a execução dos testes for detectados defeitos, deve ser verificado se os
defeitos são defeitos no fluxo básico.
Se sim o fluxo deve ser direcionado a atividade Relatar defeito
Se não o fluxo deve ser direcionado a atividade Reprovar caso de teste
8.1.2.4.2.4.2.3 Reprovar caso de teste
Um caso de teste é reprovado quando o resultado esperado de qualquer um dos passos do caso de
teste não for atendido, em outras palavras quando qualquer passo do caso de teste for marcado
como fail. Esta marcação é feita durante a atividade Procurar defeitos onde é utilizada a
ferramenta Microsoft Test Runner como apoio para esta atividade.
Ao reprovar um caso teste o sistema não cria um bug automaticamente. Se um bug não for
registrado informando que um teste que falhou, o analista de teste ou desenvolvedor saberá que
existe um defeito no software.
8.1.2.4.2.4.2.4 Relatar defeito
Os defeitos devem ser reportados aos analistas de testes, por meio da abertura de um bug na
ferramenta Microsoft Test Manager.
Se estiver adicionando novas informações em um bug existente, clique na seta de bug e em
seguida escolha a opção Update an existing bug para adicionar novos anexos ou outras
informações ao bug. Quando se registra um bug por meio do Test Manager, todos os anexos do
teste atual são incluídos no bug, tornando fácil para os desenvolvedores entender como o defeito
foi descoberto e fornece várias outras informações que podem ser úteis para resolver o bug mais
tarde.
86
É possível também registrar um bug mesmo depois de um teste ter sido executado clicando na
aba Test Analyze test runs, abrindo o test run, selecionando o test e em seguida clicando em
Create bug.
8.1.2.4.2.4.2.5 Encerrar task
A task de execução de teste deve ser encerrada na ferramenta Microsoft Test Manager seguindo
os seguintes passos:
1. Abra o Microsoft Test Manager e selecione a aba Track;
2. Abra a pasta My queries e realize a consulta;
3. Localize a Task desejada e visualize os detalhes
4. Mude o status da task para closed.
8.1.2.4.2.4.3 EXECUTAR TESTES DE SISTEMA: SAÍDAS
Bugs Task de teste encerrada
87
8.1.2.4.2.5 Gestão do conhecimento
Este processo é responsável por disseminar o conhecimento sobre os produtos e serviços
desenvolvidos pelo DSA, seja por meio de treinamentos ou por meio de documentação de apoio.
É importante frisar que este processo deve ser executado sempre que a alteração impactar alguma
das partes interessadas.
88
Figura 24 – Diagrama Gestão do conhecimento
89
Tabela 8 – Matriz de responsabilidade Gestão do conhecimento
Atividades do processo Gestão do
conhecimento
Coo
rden
ador
Ass
esso
ria d
a C
TI
Dire
tor d
o D
SA
Ass
esso
ra D
SA
Ger
ente
de
sist
emas
Con
trolle
r
Arq
uite
to d
e si
stem
as
Ana
lista
de
sist
emas
Des
envo
lved
or
Ger
ente
de
qual
idad
e
Ger
ente
de
qual
idad
e
Ana
lista
de
qual
idad
e
Técn
ico
de q
ualid
ade
Clie
nte
Treinar partes interessadas A/R R R
Atualizar documentação do projeto A/R R
Gerar/atualizar documentação de apoio R R
90
8.1.2.4.2.5.1 GESTÃO DO CONHECIMENTO: ENTRADAS
Incremento do produto pronto
Releases notes
8.1.2.4.2.5.2 GESTÃO DO CONHECIMENTO: ATIVIDADES
8.1.2.4.2.5.2.1 Treinar partes interessadas
A equipe de qualidade em conjunto com a equipe de desenvolvimento deverá elaborar um plano
de treinamento para os usuários do sistema.
Dependendo da modificação não será necessário executar esta atividade, porém será necessário
realizar a devida comunicação enviando a documentação de apoio, e o documento de release
note.
O documento de release notes deverá ser cadastrado na WikiCTI e comunicado via mural de
avisos do sistema SDK. Este documento deve ser escrito com linguagem não técnica de modo
que até mesmo um usuário final consiga interpretá-lo.
8.1.2.4.2.5.2.2 Atualizar documentação do projeto
Alguns work items serão atualizados automaticamente dependendo do projeto, porém existem
entregas que não são. Estas deverão ser atualizadas com o percentual de conclusão, status e outras
informações.
Para fazer isso é necessário acessar a ferramenta web project, procurar o projeto na qual a release
está inserido e atualizar as informações no cronograma.
8.1.2.4.2.5.2.3 Gerar/atualizar documentação de apoio
Sempre que um incremento do produto for gerado é necessário rever a documentação de apoio e
caso não exista, a documentação deve ser criada. A documentação de apoio são os manuis de
sistema, diagramas, processos e POP’s.
8.1.2.4.2.5.3 GESTÃO DO CONHECIMENTO: SAÍDAS
Comunicação para as partes interessadas
91
Diagramas de processos
Documento de release notes
Manuais de sistema
Procedimentos operacionais padrão
O documento de release notes, manuais de sistema e procedimentos operacionais padrão
deverão ser cadastrados na WikiCTI
8.1.2.4.2.6 Lançar versão RC
Para lançar a versão RC, deve-se fazer um merge da branch Main para a branch Servicing
(ambiente de homologação), efetuar o check in e então gerar uma build RC. Para mais
informações sobr a organização das branches veja a Figura 10 – Organização das branches na
metodologia.
8.1.2.4.3 Executar iteração: Saídas
Release no ambiente de homologação
92
8.1.2.5 Gerar build stable
A build stable é utilizada quando o pacote de melhorias e correções (release) já está apto para
subir para produção. Para executar esta atividade abra a ferramenta visual Studio.
Já com o Visual Studio aberto clique em View Team explorer Builds. Selecione a build
com o nome stable. Em seguida clique com o botão direito em cima da build e selecione a opção
Queue new build. Após isso clique no botão Queue.
Para realizar esta atividade o team explorer do visual Studio deverá estar conectado no projeto
em questão.
8.1.3 DESENVOLVIMENTO DA APLICAÇÃO: SAÍDAS
Incremento do produto em produção
93
9 FASE DE OPERAÇÃO
A operação ocorre no momento em que a aplicação está construída (pronta), e vamos distribuí-la,
além de mantê-la funcional no ambiente dos clientes e da empresa.
9.1. Gerenciamento de incidentes
9.2. Gerenciamento de liberações
94
9.1 Gerenciamento de incidentes
O processo de gerenciamento de incidentes que tem como principal objetivo restaurar a operação
normal do serviço o mais rápido possível, minimizando os prejuízos à operação do negócio e
garantindo assim o melhor nível de serviço e disponibilidade.
O departamento de sistemas e aplicações tem responsabilidade de reestabelecer o mais rápido
possível o funcionamento de um produto ou serviço por eles disponibilizado. Um incidente pode
ser a parada completa de um serviço ou até mesmo a perda de qualidade deste. A operação
normal do serviço é definida dentro do acordo de nível de serviço que é um outro processo ITIL
(TECHNET, 2014).
95
Figura 25 – Diagrama Gerenciamento de incidentes
96
Tabela 9 – Matriz de responsabilidade Gerenciamento de incidentes
Atividades do processo de Gerenciamento de
incidentes
Coo
rden
ador
Ass
esso
ria d
a C
TI
Dire
tor d
o D
SA
Ass
esso
ra D
SA
Ger
ente
de
sist
emas
Con
trolle
r
Arq
uite
to d
e si
stem
as
Ana
lista
de
sist
emas
Des
envo
lved
or
Ger
ente
de
qual
idad
e
Ana
lista
de
qual
idad
e
Técn
ico
de q
ualid
ade
Clie
nte
Realizar análise inicial R
Realizar suporte C A/R
Encerrar o chamado R I
Encaminhar para o nível 3 R/A
Examinar o problema A/R
Registrar no backlog da Sprint R
Registrar no product backlog A/R
Definir chamado em cronograma A/C R
97
9.1.1 GERENCIAMENTO DE INCIDENTES: ENTRADAS
Chamado
9.1.2 GERENCIAMENTO DE INCIDENTES: ATIVIDADES
9.1.2.1 Realizar análise inicial
Nessa atividade é realizada a análise inicial do chamado, e em algumas situações quando o
chamado não tiver informações suficientes para análise o responsável pela atividade deve entrar
em contrato com o cliente para levantar mais informações acerca do chamado.
É necessário que o chamado possua o mínimo de informação para dar andamento e caso isso não
ocorra o chamado deverá ser rejeitado pela equipe de qualidade. Para rejeitar o chamado siga os
passos abaixo:
1. Abra o sistema SDK;
2. Procure pelo chamado que deseja rejeitar;
3. Visualise os detalhes do chamado;
4. Clique no botão Rejeitar;
5. Esolha o motivo da devolução;
6. Coloque as observações necessárias e clique me devolver
9.1.2.2 Realizar suporte
No Departamento de Sistemas e Aplicações o suporte inicial é realizado pela Equipe de
Qualidade de Software. Os serviços suportados pela equipe de qualidade são:
Suporte avançado no uso de sistemas do PJMT
Criação e atualização de Manual de Sistema
Criação e atualização de Vídeo Aula
Implantação de sistemas
Recebimento de treinamento
Repasse de treinamento
98
Se o chamado não estiver dentro de nenhum destes serviços ou se a equipe não possuir uma
solução de contorno para um determinado problema, este deverá ser encaminhado para os grupos
especialistas.
9.1.2.3 Encerrar chamado
Após realizar o suporte e conseguir solucionar o problema o chamado deverá ser encerrado na
ferramenta SDK informando com detalhes qual foi solução e marcado com o tipo incidente. É
importante o correto preenchimento das categorias, pois a partir dessas informações que serão
gerados os relatórios para tomada de decisão.
9.1.2.4 Encaminhar para o Nível 3
Após a análise inicial se o responsável pela atividade identificar que não é possível solucionar o
incidente, o chamado deve ser encaminhado ao grupo especialista Nivel 3, seguindo os seguintes
passos:
1. Acessar o sistema SDK;
2. Visualizar o chamado;
3. Selecionar a opção abrir subchamado;
4. Escolher o grupo especialista;
5. Inserir o parecer técnico detalhado;
6. Selecionar a opção “Abrir subchamado”.
O chamado só pode ser encaminhado ao grupo especialista quando o responsável da equipe de
qualidade não conseguir resolver a solicitação do cliente com base nos conhecimentos em
manuais e equipe.
9.1.2.5 Examinar o problema
Quando um chamado chega ao nível especialista é necessário examinar o problema e não
somente o incidente. De acordo com (JOBS, 2009) o processo de gerenciamento de problemas
visa identificar e remover erros do ambiente de TI, através da busca da causa raiz dos incidentes
registrados no Gerenciamento de Incidentes, a fim de garantir uma estabilidade máxima dos
serviços de TI.
99
9.1.2.6 Registrar no Backlog da Sprint
Se a solicitação tiver urgência de ser atendida, ela deve ser registrada no backlog da iteração para
ser desenvolvida na iteração atual. Para realizar o registro deve ser realizado os seguintes passos:
1. Abrir a ferramenta o team foundation server
2. Acessar a team collection
3. Selecionar a iteração corrente e cadastrar a história
4. Cadastrar o incidente como um BUG
9.1.2.7 Registrar no Product Backlog
Se o problema encontrado não for urgente, este deve ser registrado no product backlog como um
Bug para que em uma outra iteração seja corrigido.
O processo de Planejar iteração trata dos itens que serão executados na iteração podendo ser user
stories ou bugs.
9.1.2.8 Definir chamado em cronograma
Se o incidente não for urgente, ele deverá ser definido em cronograma. As datas fornecidas no
chamado deverão estar de acordo com as datas fornecidas no TFS de modo que quando o BUG
for encerrado no TFS o chamado deverá ser encerrado. Para definir um chamado em cronograma
siga os passos a seguir:
1. Abra o sistema SDK;
2. Procure pelo chamado que quer definir em cronograma;
3. Visualize os detalhes do chamado;
4. Clique em editar;
5. No campo tipo de ocorrência, selecione a opção projeto;
6. Em seguida fornecça as datas de início e fim prevista;
7. Clique em Salvar alterações.
É possível reprogramar as datas dos chamados definidos em cronograma até o último dia da
data prevista de fim. Se o chamado não for encerrado até a data prevista, este constará como
estourado no relatório de ANS.
100
9.1.3 GERENCIAMENTO DE INCIDENTES: SAÍDAS
Chamado encerrado: Chamado encerrado com a solução detalhada do incidente.
Bug
101
9.2 Gerenciamento de liberações
Este processo assegura que apenas versões de software autorizadas e com qualidade controlada
serão utilizadas no ambiente de produção. Garante também a comunicação das partes interessadas
quanto a release que foi colocada em produção.
Esse processo também trata do fluxo caso a release esteja com alguma inconsistência no
ambiente de produção.
102
Figura 26 – Diagrama Gerenciamento de liberações
103
Tabela 10 – Matriz de responsabilidade Gerenciamento de liberações
Atividades do processo Gerenciamento de
liberações
Coo
rden
ador
Ass
esso
ria d
a C
TI
Dire
tor d
o D
SA
Ass
esso
ra D
SA
Ger
ente
de
sist
emas
Con
trolle
r
Arq
uite
to d
e si
stem
as
Ana
lista
de
sist
emas
Des
envo
lved
or
Ger
ente
de
qual
idad
e
Ana
lista
de
qual
idad
e
Técn
ico
de q
ualid
ade
Clie
nte
Aprovar release A/R R
Publicar versão A/R I
Gerar hotfix A R
Comunicar partes interessadas I A/I R I I I I
Planejar subida de nova versão R/A
9.2.1 GERENCIAMENTO DE LIBERAÇÕES: ENTRADAS
Release: Work Item gerado pela ferramenta release management.
Termo de publicação: Termo devidamente preenchido e assinado pelos envolvidos no
processo da construção da release
9.2.2 GERENCIAMENTO DE LIBERAÇÕES: ATIVIDADES
9.2.2.1 Aprovar release
O processo de aprovação da release deverá ser feita por meio da ferramenta release management.
O fluxo padrão para liberação da release via ferramenta release management pode ser observado
na Figura 27 – Fluxo padrão para deploy em produção via release management.
Figura 27 – Fluxo padrão para deploy em produção via release management
A primeira aprovação é feita por um colaborador da equipe de qualidade, que irá conferir se o
que está subindo foi o que realmente foi testado.
Em seguida o gerente irá aprovar a release. É no momento da aprovação do gerente que o sistema
faz o deploy no ambiente de produção. O último passo do fluxo é quando o gerente verifica, após
a release entrar em produção, se não ocorreu nenhum erro com a versão e se nenhum problema
for detectado deverá ser dada a última aprovação.
Se o analista de qualidade identificar que estão subido itens que não foram testados na versão
ou que a versão que está sendo entregue não foi testada, este não deverá aprovar o deploy e
deverá ser reportado ao gerente de qualidade.
1. Qualidade
Atesta que houveram testes e que o fluxo está de acordo
2. Gerente de sistemas
Sistema publicado em produção
3. Gerente de sistemas
Verificação que não houve problemas no deploy
105
9.2.2.2 Publicar versão
A publicação da release em ambiente de produção é feita de forma automática assim que o
gerente da equipe aprovar a release via ferramenta release management. O fluxo de aprovação
segue a sequência abaixo:
9.2.2.3 Gerar hotfix
Gerar um hotfix é o ato de se corrigir algum problema que foi detectado em ambiente de
produção. Para gerar hotfix, deve-se primeiramente decidir se esta correção é emergencial ou
não.
Se o problema for emergencial, deve-se realizar um novo deploy na branch Release e então gerar
uma Build Stable para passar por aprovações necessárias e então ir para o ambiente de produção.
Se o problema não for emergencial, deve-se modificar na branch Servicing, testar no ambiente de
homologação, fazer merge para a branch release para então gerar a build stable que irá publicar a
versão em produção.
Todo hotfix realizado nas branchs Servicing e Release devem posteriormente ser feito o
Reverse Integration para as demais atualizando-as das modificações realizadas.
9.2.2.4 Comunicar partes interessadas
A comunicação depende da importância e impacto da release. A equipe de sistemas deverá saber
qual o público afetado pela versão e escolher o meio de comunicação adequado.
Podem existir casos que uma comunicação formal deverá ser enviada para o cliente por meio de
e-mail, mural de avisos, noticia no portal do TJMT ou intranet.
9.2.2.5 Planejar subida de nova versão
Se após 4 horas for encontrado uma falha na versão publicada em produção deve ser reagendada
uma nova release. Caso for em menos de quatro horas a equipe de desenvolvimento pode realizar
o rollback8.
8 O ROLLBACK faz com que todas as modificações da release atual sejam desfeitas.
106
O rollback é feito com a subida de uma nova versão nesses sem a necessidade de passar por todo
o fluxo de qualidade. Porém após as 4 horas será necessário executar o fluxo de testes e
aprovações da equipe de qualidade.
9.2.3 GERENCIAMENTO DE LIBERAÇÕES: SAÍDAS
Release em produção
107
10 MONITORAMENTO E CONTROLE
Os processos necessários para acompanhar, revisar e regular o progresso e o desempenho do
projeto, identificar todas as áreas nas quais serão necessárias mudanças no plano e iniciar as
mudanças correspondentes. O principal benefício deste grupo de processos é que o desempenho
do projeto é observado e mensurado de forma periódica e uniforme para identificar variações em
relação ao plano de gerenciamento. O grupo de processos de monitoramento e controle também
inclui:
10.1 Backlog Grooming
Os itens do backlog do produto devem estar preparados para entrar em uma iteração e para
mantê-lo organizado é necessário realizar regularmente o Backlog grooming.
O backlog grooming, também chamado de refinamento do backlog, é uma boa prática dos
métodos ágeis que garante que o product backlog esteja organizado de modo a sempre entregar o
maior valor. De acordo com (FARIA, 2011) organizar o backlog é um processo contínuo que
envolve:
1. A descoberta de novos itens, assim como alteração e remoção de itens antigos;
2. Quebrar Estórias muito grandes (épicos);
3. A priorização dos itens do backlog (trazendo os mais importantes para o topo);
4. Preparar e refinar os itens mais importantes para a próxima reunião de planejamento;
5. Estimar e corrigir estimativas dos itens do backlog (em caso de novas descobertas);
6. Incluir Critérios de Aceitação.
O grooming pode ser realizado a qualquer momento, sempre que houver necessidade, portanto
cabe a cada equipe definir a frequência de execução desta atividade.
10.2 Monitorar burdown chart
O gráfico de Burndown é uma forma visual de enxergar o status atual da iteração. Este gráfico
mostra a quantidade de trabalho restante dentro de uma iteração ao longo do tempo. É importante
para controlar se a meta da iteração será alcançada dentro do prazo estimado.
108
A cada iteração um novo gráfico será criado automaticamente pelo Team Foundation Web
Access conforme pode ser visto na Figura 28 – Gráfico burndown do Team Foundation Web
Access
Figura 28 – Gráfico burndown do Team Foundation Web Access
Em métodos ágeis a leitura do gráfico de burndown é diária, porém cada equipe ficará
responsável por definir a frequência com que este gráfico será visto e discutido com a equipe de
desenvolvimento.
10.3 Controlar prazos de ofício e expedientes
Esta atividade visa controlar os prazos dos expedientes que são encaminhados ao Departamento
de Sistemas e Aplicações. Esta atividade é realizada pela assessoria do DSA que tem por objetivo
não deixar ultrapassar o prazo de resposta para o cliente.
10.4 Controlar capacidade da iteração
O controle da capacidade da iteração serve como base para fazer o planejamento de outras
iterações sendo umas das entrada do processo de Planejar iteração.
109
Ao planejar uma nova iteração, é importante ter em mãos o resultado da iteração passada, isto é, a
soma das estimativas das histórias que foram desenvolvidas. Esse é o número de pontos9 de
estimativa que se pode esperar para a próxima iteração. Essa soma de pontos é conhecida como
velocidade da equipe (GOMES, 2013).
Figura 29 – Velocidade do time no Team Foundation Web Access 2013
10.5 Conduzir release planning
O plano de release deve ser conduzido de modo que as datas previstas da entregas sejam
cumpridas. Para isso o ALM fornece diversas ferramentas para fazer o controle do andamento do
projeto, como por exemplo os relatórios de progresso. A figura Figura 30 – Artefatos utilizados
no Microsoft Solutions Framework (MSF), mostra os relatórios disponíveis no framework do
MSF.
Para acessar estes relatórios vá na página inicial do projeto no TFS em seguida clique em View
Reports. O ALM já fornecerá diversos relatórios para fazer o acompanhamento do projeto bem
como a condução do plano de release.
Figura 30 – Artefatos utilizados no Microsoft Solutions Framework (MSF)
9 Representa a quantidade de esforço requerido para implementar uma user story, podendo também ser entendido como uma medida de complexidade.
110
11
111
12 REFERÊNCIAS BIBLIOGRÁFICAS
ABADE, I. O que o System Center tem a ver com TFS e ALM? tshooter, 18 Março 2014. Disponivel em: <http://www.tshooter.com.br/2014/03/18/o-que-o-system-center-tem-a-ver-com-tfs-e-alm/>. Acesso em: 19 Março 2014.
AUDY, J. H. Afinal, o que é o Manifesto e Métodos Ágeis? baguete, 2013. Disponivel em: <http://www.baguete.com.br/colunistas/colunas/1173/jorge-horacio-audy/09/01/2013/afinal-o-que-e-o-manifesto-e-metodos-ageis>. Acesso em: 23 Novembro 2014.
BASTOS, A. et al. Base de conhecimento em teste de software. 2ª. ed. São Paulo: Martis Editoria Livraria LTDA, 2007.
BUILDER, E. P. Gestão de projetos: Ágil ou tradicional? Entenda as diferenças. Project Builder, 6 Novembro 2013. Disponivel em: <https://www.projectbuilder.com.br/blog-pb/entry/blog-gestao-de-projetos/gestao-de-projetos-agil-ou-tradicional-entenda-as-diferencas>. Acesso em: 28 Março 2014.
CAMARGO, C. O que são versões Alfa, Beta, RC e Final? Tec mundo, 2009. Disponivel em: <http://www.tecmundo.com.br/mac-os-x/1698-o-que-sao-versoes-alfa-beta-rc-e-final-.htm>. Acesso em: 2014.
CONDÉ, L. Introdução ao Application Lifecycle Management (ALM). Microsoft Developer Network, Junho 2009. Disponivel em: <http://msdn.microsoft.com/pt-br/library/ee156630.aspx>. Acesso em: 14 Março 2014.
FARIA, A. Sessões de Backlog Grooming (Organização do Backlog). Blog do André Faria, 2011. Disponivel em: <http://blog.andrefaria.com/category/gerenciado/page/3>. Acesso em: 9 Dezembro 2014.
GARCIA, M. ALM – O que é isso? – Parte 01. Dev Media, 2011. Disponivel em: <http://www.devmedia.com.br/alm-o-que-e-isso-parte-01/14117>. Acesso em: 18 Março 2014.
GOMES, A. F. Agile - Desenvolvimento de software com entregas frequentes e foco no valor do negócio. [S.l.]: Casa do Código, 2013.
GUIA BABOK®. 2ª. ed. Toronto: [s.n.], 2011.
JOBS, M. F. ITIL: Diferença entre Problema e Incidente. Vivenciando TI, 2009. Disponivel em: <http://vivenciandoti.blogspot.com.br/2009/12/itil-diferenca-entre-problema-e.html>. Acesso em: 09 Dezembro 2014.
JUNIOR, N. A. S. R.; RAHAL, N. A. A. S. Blog do Abu, 2012. Disponivel em: <http://blogdoabu.blogspot.com.br/>. Acesso em: 2014.
112
MAIA, N. O que é metodologia? Educadores de sucesso, 5 Fevereiro 2011. Disponivel em: <http://educadoresdesucesso.blogspot.com.br/2011/02/o-que-e-metodologia.html>. Acesso em: 14 Março 2014.
MPS.BR. MPS.BR - Melhoria de Processo do Software Brasileiro. [S.l.]: Softex, 2012.
MSDN. User Story (Agile). MSDN, 2013. Disponivel em: <http://msdn.microsoft.com/pt-br/library/dd380634(v=vs.110).aspx>. Acesso em: 05 Dezembro 2014.
OSEIK, B. A. CHAOS Report: Métodos Ágeis Aumentam Taxa de Sucesso de Projetos. Blog My scrum half, 2011. Disponivel em: <http://blog.myscrumhalf.com/2011/02/metodos-ageis-impactam-positivamente-no-sucesso-de-projetos/>. Acesso em: 11 Dezembro 2014.
PALMA, F. A matriz RACI é a solução de seus problemas! Portal GTSI, 2013. Disponivel em: <http://www.portalgsti.com.br/2013/04/matriz-raci.html#comment-form>. Acesso em: 28 Novembro 2014.
PMI. PMBOK® Guide. 4ª. ed. Newtown Square: [s.n.], 2008.
RODRIGUES, et al. Metodologia de gerenciamento de projetos do SISP. 1ª. ed. Brasília: [s.n.], v. I, 2011. Disponivel em: <http://www.sisp.gov.br/mgpsisp/wiki/>.
SCHWABER, K. GUIA DO SCRUM. [S.l.]: [s.n.], 2009.
SENE, R. P. RUP – Primeiros Passos. Ti especialistas, 2011. Disponivel em: <http://www.tiespecialistas.com.br/2011/02/rup-primeiros-passos/>. Acesso em: 02 Dezembro 2014.
SOARES, M. S. Site do departamento de ciência da computação da Universidade Federal de Lavras, 30 Outubro 2013. Disponivel em: <http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf>. Acesso em: 2014.
SPRINT Planning Meeting. Desenvolvimento ágil, 2013. Disponivel em: <http://www.desenvolvimentoagil.com.br/scrum/sprint_planning_meeting>. Acesso em: 10 Novembro 2104.
STANDISH GROUP. Chaos Manifesto. The Standish Group. [S.l.], p. 48. 2013.
TECHNET. Recurso de IO: Processo de gerenciamento baseado em ITIL/COBIT. Site Technet da Microsoft, 2014. Disponivel em: <http://technet.microsoft.com/pt-br/library/bb821261.aspx>. Acesso em: 28 Novembro 2014.
WEISS, K. Fundamentos do scrum. Ti exames, 2013. Acesso em: 2014.
WIKIPEDIA. Documento de visão. Wikipedia, 2013. Disponivel em: <http://pt.wikipedia.org/wiki/Documento_de_vis%C3%A3o>. Acesso em: Novembro 2014.
113
WIKIPEDIA. Metodologia (engenharia de software). Wikipedia, 24 Março 2013. Disponivel em: <http://pt.wikipedia.org/wiki/Metodologia_(engenharia_de_software)>. Acesso em: 14 Março 2014.
WIKIPEDIA. Programação extrema. Wikipedia, 2014. Disponivel em: <http://pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_extrema>. Acesso em: 9 Dezembro 2014.
114
13 GLOSSÁRIO
A
Action recording: Um arquivo onde são gravadas
todas as entradas e ações de um usuário em uma
determinada aplicação. Sendo possível,
posteriormente, reproduzir nos testes, automatizando
alguns passos.
Activity: Um padrão de trabalhos realizados juntos
para uma única finalidade. Uma atividade pode usar
ou produzir produtos de trabalho e podem ser
controlados por um item de trabalho.
Análise de requisitos: A determinação das
características funcionais e de desempenho da
solução com base em análises de necessidades,
expectativas e restrições do cliente.
Application lifecycle management: Coordenação
dos requisitos, desenho, desenvolvimento,
construção, teste e liberação do software. Requer
integração dos processos de software, definindo
relacionamentos entre o trabalho dos produtos
permitindo rastreabilidade, gerenciamento do projeto
e relatar todas as atividades e todas as fases.
Área: Um nó na hierarquia dos Serviços de
Estruturas Comuns que representa uma área
característica. É uma divisão onde uma equipe
executa serviços em comum.
Autor do teste: Quem cria um teste e o manipula
dentro do Visual Studio Application Lifecycle
Management (ALM).
B
Backlog: O conjunto de work itens que ainda não
foram finalizados, representando um trabalho que esta
sendo considerado ou ainda não foi completado.
Branch: Permite que uma coleção de arquivos possa
ser dividida em dois ou mais caminhos. Branching é
normalmente usada quando o time necessita manter
duas ou mais bases de código, por exemplo, quando
um produto é liberado e o trabalho deve começar na
próxima versão. No source controle, branch é análoga
a uma operação de cópia do sistema de arquivos.
Bug: um tipo de work item que registra uma fonte
potencial de descontentamento com o produto. O
nome comum de um tipo de work item para defeitos
de código.
Build: É um nome dado a conjunto entregáveis de
componentes, em uma versão “compilada”, que
poderão integrara versão final do produto.
Build definition: Um conjunto de a) atividades b)
condições em que o workflow é ativado, que junto a
build, constroem uma solução ou um conjunto de
solução para o time do projeto. A build definition
inclui o nome da build, a fonte de controle no
workspace para os arquivos construídos, a
localização do TFSBuild.proj no arquivo do projeto, o
agente de build, a politica de build e o gatilho da
build. A build definition pode também incluir
atividades para criar ambientes e deploy implementar
aplicações construídas nesses ambientes.
C
Caso de uso: Uma sequência de comportamentos
relacionada de interações que um ator realiza em um
115
diálogo com um sistema para fornecer algum valor
mensurável para o ator; uma coleção de cenários.
Changeset: Um grupo lógico de mudanças. O
proposito do changesets é agrupar todas as
atualizações dos arquivos e work items que foram
entregues em um único “check-in action”
Check in: Colocar um arquivo ou projeto no banco
de dados para ser armazenado.
Check-in notes: Comentários associados a um
changeset que são adicionados durante o processo de
check-in pela análise de dados específicos. Check-in
notes podem ser configuradas para serem obrigatórios
por qualquer administrador.
Check out: Colocar uma cópia do arquivo ou projeto
do Visual SourceSafe database uma pasta de trabalho
Cliente: Um individuo que espera ganhar um valor
de negócio a partir da solução. Também, beneficiário
do produto ou serviço.
Coded UI test: Um teste automático da interface de
uma aplicação usada pelo usuário. Um coded UI test
exerce ações do usuário e valida resultado esperados.
Critério de aceitação: Os critérios que um
componente ou um produto de um componente deve
obedecer para ser aceito por um usuário, cliente ou
outra entidade autorizada.
D
Desenvolvimento interativo: o desenvolvimento de
um solução por intermédio de uma build, de testes e
do “deploy” de um núcleo de conjuntos de
características básicas, depois adicionar
características em uma versões sucessivas
E
Escopo do projeto: O trabalho acordado e
documentado entre o patrocinador do projeto e da
equipe do projeto, a fim de planejar e entregar o
escopo da solução.
Estrutura Analítica do Projeto (EAP): Um
agrupamento orientado a entrega de elementos do
projeto que organiza e define o escopo total de
trabalho do projeto. Cada nível descendente
representa uma definição cada vez mais detalhada do
trabalho do projeto. A estrutura analítica do projeto
(EAP) deve também identificar as relações dos
elementos entre si e com o produto final.
Execução de teste: Um conjunto de pares de casos de
teste e configurações de teste a ser executado. Os
resultados deste conjunto de emparelhamentos podem
ser vistos em conjunto. Os ensaios em circulação são
ou automático ou manual.
F
Feature: Um conjunto de requisitos funcionais
relacionados logicamente que oferece uma
capacidade para o usuário e permite a satisfação de
um objetivo de negócio.
Framework: um conjunto de suposições, conceitos,
valores e práticas que constituem uma forma de ver a
realidade.
Function: Descrição do desempenho de uma
característica, produto ou componente.
G
Garantia de qualidade: Um meio planejado e
sistemático para garantir que define normas, práticas,
procedimentos e métodos que são aplicados ao
projeto e seus resultados. Isso inclui o processo de
avaliação do desempenho global do projeto em uma
116
base regular para fornecer a confiança de que o
projeto irá satisfazer os padrões de qualidade
relevantes e as expectativas documentados da solução
que descrevem o quão bem ele deve executar para
satisfazer as necessidades dos clientes.
Gated check-in: Uma opção de build que requer
arquivos para construir antes mesmo de serem
apresentados. Se a build falhar, os arquivos não
podem ser apresentados.
Get: Substituir a versão do workplace pela versão
mais recente.
I
Iteração: Um período de tempo, aproximado de um
mês, que o software é desenvolvido e verificado para
resultar em um incremento entregue do produto ou do
projeto.
M
Manual de testes: Um documento feito por um
humano que normalmente é feito no Word e que lista
os passos as passos dos testes.
Merge: O processo de combinar as alterações em
dois ramos branch. A operação de fusão leva
mudanças que ocorreram no branch de origem e
integra-as no branch alvo. Mesclando integra todos os
tipos de mudanças no branch de origem, incluindo
mudanças de nome, edições de arquivo, adições de
arquivos e exclusões de arquivos.
Métodos ágeis: Uma família das melhores práticas de
engenharia de software com o objetivo de possibilitar
a entrega rápida de software de alta qualidade e uma
abordagem de negócios que alinha o desenvolvimento
com as necessidades dos clientes e os objetivos da
empresa. Neste paradigma, é necessário inspeção e
adaptação frequente, com trabalho em equipe, auto-
organização e responsabilidade de todos para o
sucesso do projeto.
My Queries: A pasta sob o nó itens de trabalho de
cada projeto Team Foundation que contém consultas
definidas por, e visto somente pelo usuário atual.
P
Patrocinadores: indivíduos que iniciam e aprovam
um projeto e seus resultados
Plano de teste: um conjunto de casos de teste, suas
informações de teste de configuração associadas. Os
casos de teste podem ser organizados em uma
hierarquia de suíte de testes para usar ao executar o
conjunto de teste.
Plano de projeto: Um documento formal, aprovado
usado para guiar tanto a execução do projeto e
controle do projeto. Os principais usos do plano de
projeto são para documentar os pressupostos e as
decisões de planeamento, facilitar a comunicação
entre as partes interessadas, e documento aprovado
linhas de base escopo, custo e cronograma. Um plano
de projeto pode ser resumido ou detalhado.
Papel: 1) Um grupo de atividades normalmente (mas
nem sempre), realizado por uma pessoa e muitas
vezes realizada com um grupo de segurança. Muitas
vezes, uma pessoa pode desempenhar várias funções.
2) No Team Test, uma parte ou função específica em
um aplicativo ou arquitetura. Por exemplo, um
servidor Web, um servidor de banco de dados, ou um
cliente. 3) No domínio de ferramentas específicas de
idioma, uma representação de um lado (a origem ou o
destino) de um relacionamento. Propriedades de
função incluem sua multiplicidade e seu papel
117
jogador. 3) Uma parte ou função específica em um
aplicativo ou arquitetura. Por exemplo, um servidor
Web, um servidor de banco de dados, ou um cliente
Processo: Uma coleção de atividades que produzem
um resultado, produto ou serviço; geralmente uma
operação contínua. Uma série de ações ou operações
destinadas a alcançar um fim.
Project portal: O Windows SharePoint Services site
que é usado para armazenar e apresentar trabalhos
não codificados e avisar o time do projeto.
Q
Query: o nome dado a um conjunto de critérios que o
Vistual Studio Team Foundation server usa para
exibir os work itens.
R
Release: Uma build promovida para uso ou
implantação. Uma versão pode ser interna e utilizada
para os ensaios ou externa e liberada ou implantado.
Release candidate: Uma versão de uma compilação
que foi testado e está pronto para o lançamento.
Requirement: (1) A condição ou capacidade
necessária por um usuário para resolver um problema
ou alcançar um objetivo. (2) Uma condição ou
capacidade que deve ser cumprida ou possuída por
um produto ou componente de produto para satisfazer
um contrato, padrão, especificação ou outros
documentos formalmente impostos. (3) Uma
representação documentada de uma condição ou uma
capacidade tal como em (1) ou (2). [IEEE 610,12-
1990]
S
Service level agreement (SLA): Um acordo entre
duas organizações detalhando o nível e natureza do
apoio que uma equipe se compromete a fornecer, e
para a qual a outra equipe se compromete a
compromissos recíprocos. O SLA formaliza os
requisitos do cliente / usuário para níveis de serviço e
define as responsabilidades de todas as partes que
participam.
Shared steps: Um grupo de passos do teste que
podem ser reutilizados entre casos de teste.
Source Control Explorer: Utilizado para visualizar
e gerenciar Team Foundation itens que podem incluir
os projetos da equipe, pastas e arquivos.
Stack rank: ordenação dos work item por
priorização.
Stakeholders: Indivíduos e organizações que estão
ativamente envolvidas no projeto ou cujos interesses
podem ser positiva ou negativamente afetados como
resultado da execução do projeto ou a conclusão do
projeto. Eles também podem exercer influência sobre
o projeto e seus resultados.
T
Task: um tipo de work item que registra uma tarefa
de desenvolvimento ou uma tarefa de teste.
Task de desenvolvimento: Work item de
desenvolvimento da unidade que é geralmente para
construir uma parte do cenário ou qualificar os
atributos do serviço.
Task de teste: Uma atribuição para criar casos de
teste e testar uma área específica do produto,
usualmente no contexto de um cenário ou qualidade
de serviço requisito.
118
Team Explorer: Usado para acessar os projetos da
equipe que você está trabalhando.
Team Foundation Server: Um conjunto de
ferramentas e tecnologias que permitem uma equipe
colaborar e coordenar seus esforços para a construção
de um produto ou conclusão de um projeto. As
ferramentas incluem source control, acompanhamento
de work item, building, team Project portal, relatórios
e gerenciamento de projetos.
Team Project: O nome dados a uma coleção de work
itens, código, produtos do trabalho e assim por diante,
usado por uma definição junto ao Visual Studio Team
Foundation para rastrear um conjunto comum de
trabalhos relacionados.
Team project portal: O site do Windows SharePoint
Service (WSS) para cada projeto da equipe. Um
portal do projeto permite os membros da equipe
armazenar e compartilhar documentos, relatórios, e
informações relacionadas a um projeto especifico.
Test: Um programa, um script (manual ou
automático), um conjunto específico de passos, ou
instruções gerais que podem ser executados
repetidamente nos software em teste, e que irá
produzir um resultado de teste, tais como aprovação,
reprovação, ou outros resultados que resolvem passar
ou deixar como inconclusivos.
Teste de caixa preta: Testes que são baseados no
comportamento atual do componente sem levar em
consideração a implementação desse componente.
Teste de aceitação: Realização de testes formais,
realizados por um cliente ou outra entidade
autorizada, que permitem a eles determinarem se
aceitam ou não um componente do produto
Teste Exploratório: O teste de um produto sem o
uso de um conjunto de testes avançados definidos.
Testers fazem o teste assumindo um usuário e
realizando o que esse usuário normalmente realiza.
Teste de estresse: (1) Um teste desenvolvido para
determinar a resposta de um sistema sob carga. (2)
For MSF Agile: um teste que determina os pontos de
ruptura de uma aplicação e força a aplicação a superar
os seus limites quando os recursos estão saturados.
Teste de regressão: Um teste que é executado após a
compilação diária para verificar que a compilação do
código-fonte foi construída com sucesso.
Teste de validação: Um teste que assegura que a
funcionalidade pedida em um cenário ou a qualidade
do requisito de serviço está funcionando.
Testes unitários: Um teste que confirma a
funcionalidade e o desempenho dos módulos de
código e comportamentos específicos. Muitas vezes,
um subconjunto de testes de unidade que são
utilizados como testes de check-in para descobrir
erros antes de uma compilação.
Test step: uma ação a ser tomada quando o teste é
executado, e, possivelmente, o resultado esperado
daquela ação.
Suíte de teste: Um conjunto de casos de teste
selecionados. Uma suíte de teste pode conter outras
suítes de testes, mas cada suíte de teste pode conter
apenas uma outra suíte de teste.
U
Usuário Final: A pessoa que realmente usa a solução
tecnológica, diferente do cliente que paga pela
solução.
Usuário: O cliente que usa um sistema de computador
ou de um produto de software. As pessoas que fazem
uso de alguma coisa.
119
V
Velocidade: Uma medida do trabalho realizado por
unidade de tempo, por exemplo, iteração.
Versão: O status de um item no source control, que
reflete uma ou mais alterações de uma forma anterior.
Quanto maior o número de versão, mais recente
versão
Versão Alpha: Um lançamento antecipado de uma
versão de um produto para obter feedback preliminar
sobre o conjunto de recursos e usabilidade.
Versão beta: Um pré-lançamento de um produto que
foi liberado para os clientes e parceiros para avaliação
e feedbakcs.
Versão de controle: A criação e manutenção de
linhas de base e a identificação de alterações dessas
linhas que tornam possível para voltar à linha de base
anterior.
Visão de projeto: A finalidade, motivação, e fundo
para a construção do sistema. O objetivo da visão do
projeto é alinhar a equipe em torno de um objetivo
central.
W
Work item: 1) Um registro de banco de dados que o
Visual Studio Team Foundation usa para controlar a
atribuição e o estado do trabalho. Um work item
representa os arquivos e pastas que são armazenados
no servidor de source control de origem do Team
Foundation Server. Os tipos são: tarefa, solicitação de
mudança, de risco, avaliação, exigência, e bug. 2)
Uma instância de um tipo de work item, é uma
unidade de trabalho atribuída a um usuário no Team
Foundation Server.
Work item type: Nome dado a uma associação a um
projeto do Team Foundation Server. Tipos são
compostos por campos, formulários ou work flows.
Eles sã definidos usando XML. Definições são
portáteis entre os Servers do Team Foundation.
120
![ApTI [Modo de Compatibilidade] · (Scrum)(Scrum)––––Gerenciamento Ágil de projetos de Gerenciamento Ágil de projetos de ... Definição de um plano de contingência para](https://img.document.onl/doc/110x75/5b29e8b47f8b9a20108b51bf/apti-modo-de-compatibilidade-scrumscrumgerenciamento-agil.jpg)
