Metodologia de Gestão de projetos baseado em AGIL

85  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. É 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.

86 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.

Figura 24 – Diagrama Gestão do conhecimento

88

Tabela 8 – Matriz de responsabilidade Gestão do conhecimentoCoordenador Assessoria da CTI Atividades do processo Gestão do Diretor do DSA conhecimento Treinar partes interessadas Atualizar documentação do projeto Gerar/atualizar documentação de apoio

89Assessora DSA Gerente de sistemas A/R R RController A/R RArquiteto de sistemas RRAnalista de sistemas Desenvolvedor Gerente de qualidade Gerente de qualidade Analista de qualidade Técnico de qualidade Cliente

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  Diagramas de processos

91  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).

Figura 25 – Diagrama Gerenciamento de incidentes

95

Tabela 9 – Matriz de responsabilidade Gerenciamento de incidentesCoordenador Assessoria da CTI Atividades do processo de Gerenciamento de incidentes Realizar análise inicial Realizar suporte Encerrar o chamado Encaminhar para o nível 3 Examinar o problema Registrar no backlog da Sprint Registrar no product backlog Definir chamado em cronograma

C Diretor do DSA Assessora DSA A/R Gerente de sistemas R Controller Arquiteto de sistemas A/R Analista de sistemas A/C R Desenvolvedor Gerente de qualidade R Analista de qualidade A/R Técnico de qualidade Cliente RI R/A 96

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.

Figura 26 – Diagrama Gerenciamento de liberações

102

Tabela 10 – Matriz de responsabilidade Gerenciamento de liberaçõesCoordenador Assessoria da CTI Atividades do processo Gerenciamento de liberações Aprovar release Publicar versão Gerar hotfix Comunicar partes interessadas Planejar subida de nova versão

A/R Diretor do DSA A/R Assessora DSA Gerente de sistemas I A/I Controller Arquiteto de sistemas R Analista de sistemas 103 I Desenvolvedor Gerente de qualidade AR Analista de qualidade R IIII Técnico de qualidade R/A Cliente

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 1. Qualidade 2. Gerente de 3. Gerente de sistemas sistemas • Atesta que • Sistema • Verificação houveram publicado em que não testes e que o produção houve fluxo está de problemas no acordo deploy 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.

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. 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

108 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. 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 9 Representa a quantidade de esforço requerido para implementar uma user story, podendo também ser entendido como uma medida de complexidade.

109 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)

110

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. 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.

112 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. 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.

113 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 Backlog: O conjunto de work itens que ainda não foram finalizados, representando um trabalho que esta Action recording: Um arquivo onde são gravadas sendo considerado ou ainda não foi completado. todas as entradas e ações de um usuário em uma determinada aplicação. Sendo possível, Branch: Permite que uma coleção de arquivos possa posteriormente, reproduzir nos testes, automatizando ser dividida em dois ou mais caminhos. Branching é alguns passos. normalmente usada quando o time necessita manter duas ou mais bases de código, por exemplo, quando Activity: Um padrão de trabalhos realizados juntos um produto é liberado e o trabalho deve começar na para uma única finalidade. Uma atividade pode usar ou próxima versão. No source controle, branch é análoga produzir produtos de trabalho e podem ser controlados a uma operação de cópia do sistema de arquivos. por um item de trabalho. Bug: um tipo de work item que registra uma fonte Análise de requisitos: A determinação das potencial de descontentamento com o produto. O nome características funcionais e de desempenho da solução comum de um tipo de work item para defeitos de com base em análises de necessidades, expectativas e código. restrições do cliente. Build: É um nome dado a conjunto entregáveis de Application lifecycle management: Coordenação dos componentes, em uma versão “compilada”, que requisitos, desenho, desenvolvimento, construção, poderão integrara versão final do produto. teste e liberação do software. Requer integração dos processos de software, definindo relacionamentos Build definition: Um conjunto de a) atividades b) entre o trabalho dos produtos permitindo condições em que o workflow é ativado, que junto a rastreabilidade, gerenciamento do projeto e relatar build, constroem uma solução ou um conjunto de todas as atividades e todas as fases. solução para o time do projeto. A build definition inclui o nome da build, a fonte de controle no Área: Um nó na hierarquia dos Serviços de Estruturas workspace para os arquivos construídos, a localização Comuns que representa uma área característica. É uma do TFSBuild.proj no arquivo do projeto, o agente de divisão onde uma equipe executa serviços em comum. build, a politica de build e o gatilho da build. A build definition pode também incluir atividades para criar Autor do teste: Quem cria um teste e o manipula ambientes e deploy implementar aplicações dentro do Visual Studio Application Lifecycle construídas nesses ambientes. Management (ALM). C B Caso de uso: Uma sequência de comportamentos relacionada de interações que um ator realiza em um

diálogo com um sistema para fornecer algum valor 115 mensurável para o ator; uma coleção de cenários. Escopo do projeto: O trabalho acordado e Changeset: Um grupo lógico de mudanças. O documentado entre o patrocinador do projeto e da proposito do changesets é agrupar todas as equipe do projeto, a fim de planejar e entregar o escopo atualizações dos arquivos e work items que foram da solução. entregues em um único “check-in action” Estrutura Analítica do Projeto (EAP): Um Check in: Colocar um arquivo ou projeto no banco de agrupamento orientado a entrega de elementos do dados para ser armazenado. projeto que organiza e define o escopo total de trabalho do projeto. Cada nível descendente representa uma Check-in notes: Comentários associados a um definição cada vez mais detalhada do trabalho do changeset que são adicionados durante o processo de projeto. A estrutura analítica do projeto (EAP) deve check-in pela análise de dados específicos. Check-in também identificar as relações dos elementos entre si notes podem ser configuradas para serem obrigatórios e com o produto final. por qualquer administrador. Execução de teste: Um conjunto de pares de casos de Check out: Colocar uma cópia do arquivo ou projeto teste e configurações de teste a ser executado. Os do Visual SourceSafe database uma pasta de trabalho resultados deste conjunto de emparelhamentos podem ser vistos em conjunto. Os ensaios em circulação são Cliente: Um individuo que espera ganhar um valor de ou automático ou manual. negócio a partir da solução. Também, beneficiário do produto ou serviço. F Coded UI test: Um teste automático da interface de Feature: Um conjunto de requisitos funcionais uma aplicação usada pelo usuário. Um coded UI test relacionados logicamente que oferece uma capacidade exerce ações do usuário e valida resultado esperados. para o usuário e permite a satisfação de um objetivo de negócio. Critério de aceitação: Os critérios que um componente ou um produto de um componente deve Framework: um conjunto de suposições, conceitos, obedecer para ser aceito por um usuário, cliente ou valores e práticas que constituem uma forma de ver a outra entidade autorizada. realidade. D Function: Descrição do desempenho de uma característica, produto ou componente. Desenvolvimento interativo: o desenvolvimento de um solução por intermédio de uma build, de testes e do G “deploy” de um núcleo de conjuntos de características básicas, depois adicionar características em uma Garantia de qualidade: Um meio planejado e versões sucessivas sistemático para garantir que define normas, práticas, procedimentos e métodos que são aplicados ao projeto E e seus resultados. Isso inclui o processo de avaliação do desempenho global do projeto em uma base regular

para fornecer a confiança de que o projeto irá satisfazer 116 os padrões de qualidade relevantes e as expectativas documentados da solução que descrevem o quão bem empresa. Neste paradigma, é necessário inspeção e ele deve executar para satisfazer as necessidades dos adaptação frequente, com trabalho em equipe, auto- clientes. organização e responsabilidade de todos para o sucesso do projeto. Gated check-in: Uma opção de build que requer arquivos para construir antes mesmo de serem My Queries: A pasta sob o nó itens de trabalho de apresentados. Se a build falhar, os arquivos não podem cada projeto Team Foundation que contém consultas ser apresentados. definidas por, e visto somente pelo usuário atual. Get: Substituir a versão do workplace pela versão mais P recente. Patrocinadores: indivíduos que iniciam e aprovam I um projeto e seus resultados Iteração: Um período de tempo, aproximado de um Plano de teste: um conjunto de casos de teste, suas mês, que o software é desenvolvido e verificado para informações de teste de configuração associadas. Os resultar em um incremento entregue do produto ou do casos de teste podem ser organizados em uma projeto. hierarquia de suíte de testes para usar ao executar o conjunto de teste. M Plano de projeto: Um documento formal, aprovado Manual de testes: Um documento feito por um usado para guiar tanto a execução do projeto e controle humano que normalmente é feito no Word e que lista do projeto. Os principais usos do plano de projeto são os passos as passos dos testes. para documentar os pressupostos e as decisões de planeamento, facilitar a comunicação entre as partes Merge: O processo de combinar as alterações em dois interessadas, e documento aprovado linhas de base ramos branch. A operação de fusão leva mudanças que escopo, custo e cronograma. Um plano de projeto pode ocorreram no branch de origem e integra-as no branch ser resumido ou detalhado. alvo. Mesclando integra todos os tipos de mudanças no branch de origem, incluindo mudanças de nome, Papel: 1) Um grupo de atividades normalmente (mas edições de arquivo, adições de arquivos e exclusões de nem sempre), realizado por uma pessoa e muitas vezes arquivos. realizada com um grupo de segurança. Muitas vezes, uma pessoa pode desempenhar várias funções. 2) No Métodos ágeis: Uma família das melhores práticas de Team Test, uma parte ou função específica em um engenharia de software com o objetivo de possibilitar aplicativo ou arquitetura. Por exemplo, um servidor a entrega rápida de software de alta qualidade e uma Web, um servidor de banco de dados, ou um cliente. 3) abordagem de negócios que alinha o desenvolvimento No domínio de ferramentas específicas de idioma, uma com as necessidades dos clientes e os objetivos da representação de um lado (a origem ou o destino) de um relacionamento. Propriedades de função incluem sua multiplicidade e seu papel jogador. 3) Uma parte

ou função específica em um aplicativo ou arquitetura. 117 Por exemplo, um servidor Web, um servidor de banco de dados, ou um cliente Service level agreement (SLA): Um acordo entre Processo: Uma coleção de atividades que produzem duas organizações detalhando o nível e natureza do um resultado, produto ou serviço; geralmente uma apoio que uma equipe se compromete a fornecer, e operação contínua. Uma série de ações ou operações para a qual a outra equipe se compromete a destinadas a alcançar um fim. compromissos recíprocos. O SLA formaliza os Project portal: O Windows SharePoint Services site requisitos do cliente / usuário para níveis de serviço e que é usado para armazenar e apresentar trabalhos não define as responsabilidades de todas as partes que codificados e avisar o time do projeto. participam. Q Shared steps: Um grupo de passos do teste que podem Query: o nome dado a um conjunto de critérios que o ser reutilizados entre casos de teste. Vistual Studio Team Foundation server usa para exibir os work itens. Source Control Explorer: Utilizado para visualizar e gerenciar Team Foundation itens que podem incluir os R projetos da equipe, pastas e arquivos. Release: Uma build promovida para uso ou implantação. Uma versão pode ser interna e utilizada Stack rank: ordenação dos work item por priorização. para os ensaios ou externa e liberada ou implantado. Release candidate: Uma versão de uma compilação Stakeholders: Indivíduos e organizações que estão que foi testado e está pronto para o lançamento. ativamente envolvidas no projeto ou cujos interesses Requirement: (1) A condição ou capacidade podem ser positiva ou negativamente afetados como necessária por um usuário para resolver um problema resultado da execução do projeto ou a conclusão do ou alcançar um objetivo. (2) Uma condição ou projeto. Eles também podem exercer influência sobre capacidade que deve ser cumprida ou possuída por um o projeto e seus resultados. produto ou componente de produto para satisfazer um contrato, padrão, especificação ou outros documentos T formalmente impostos. (3) Uma representação documentada de uma condição ou uma capacidade tal Task: um tipo de work item que registra uma tarefa de como em (1) ou (2). [IEEE 610,12-1990] desenvolvimento ou uma tarefa de teste. S 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. Team Explorer: Usado para acessar os projetos da equipe que você está trabalhando.

Team Foundation Server: Um conjunto de 118 ferramentas e tecnologias que permitem uma equipe colaborar e coordenar seus esforços para a construção Teste de estresse: (1) Um teste desenvolvido para de um produto ou conclusão de um projeto. As determinar a resposta de um sistema sob carga. (2) For ferramentas incluem source control, acompanhamento MSF Agile: um teste que determina os pontos de de work item, building, team Project portal, relatórios ruptura de uma aplicação e força a aplicação a superar e gerenciamento de projetos. os seus limites quando os recursos estão saturados. Team Project: O nome dados a uma coleção de work Teste de regressão: Um teste que é executado após a itens, código, produtos do trabalho e assim por diante, compilação diária para verificar que a compilação do usado por uma definição junto ao Visual Studio Team código-fonte foi construída com sucesso. Foundation para rastrear um conjunto comum de trabalhos relacionados. Teste de validação: Um teste que assegura que a funcionalidade pedida em um cenário ou a qualidade Team project portal: O site do Windows SharePoint do requisito de serviço está funcionando. Service (WSS) para cada projeto da equipe. Um portal do projeto permite os membros da equipe armazenar e Testes unitários: Um teste que confirma a compartilhar documentos, relatórios, e informações funcionalidade e o desempenho dos módulos de código relacionadas a um projeto especifico. e comportamentos específicos. Muitas vezes, um subconjunto de testes de unidade que são utilizados Test: Um programa, um script (manual ou como testes de check-in para descobrir erros antes de automático), um conjunto específico de passos, ou uma compilação. instruções gerais que podem ser executados repetidamente nos software em teste, e que irá produzir Test step: uma ação a ser tomada quando o teste é um resultado de teste, tais como aprovação, executado, e, possivelmente, o resultado esperado reprovação, ou outros resultados que resolvem passar daquela ação. ou deixar como inconclusivos. Suíte de teste: Um conjunto de casos de teste Teste de caixa preta: Testes que são baseados no selecionados. Uma suíte de teste pode conter outras comportamento atual do componente sem levar em suítes de testes, mas cada suíte de teste pode conter consideração a implementação desse componente. apenas uma outra suíte de teste. Teste de aceitação: Realização de testes formais, U realizados por um cliente ou outra entidade autorizada, Usuário Final: A pessoa que realmente usa a solução que permitem a eles determinarem se aceitam ou não tecnológica, diferente do cliente que paga pela solução. um componente do produto Usuário: O cliente que usa um sistema de computador Teste Exploratório: O teste de um produto sem o uso ou de um produto de software. As pessoas que fazem de um conjunto de testes avançados definidos. Testers uso de alguma coisa. fazem o teste assumindo um usuário e realizando o que esse usuário normalmente realiza. V

Velocidade: Uma medida do trabalho realizado por 119 unidade de tempo, por exemplo, iteração. W Versão: O status de um item no source control, que reflete uma ou mais alterações de uma forma anterior. Work item: 1) Um registro de banco de dados que o Quanto maior o número de versão, mais recente versão Visual Studio Team Foundation usa para controlar a atribuição e o estado do trabalho. Um work item Versão Alpha: Um lançamento antecipado de uma representa os arquivos e pastas que são armazenados versão de um produto para obter feedback preliminar no servidor de source control de origem do Team sobre o conjunto de recursos e usabilidade. Foundation Server. Os tipos são: tarefa, solicitação de mudança, de risco, avaliação, exigência, e bug. 2) Uma Versão beta: Um pré-lançamento de um produto que instância de um tipo de work item, é uma unidade de foi liberado para os clientes e parceiros para avaliação trabalho atribuída a um usuário no Team Foundation e feedbakcs. Server. Versão de controle: A criação e manutenção de linhas Work item type: Nome dado a uma associação a um de base e a identificação de alterações dessas linhas projeto do Team Foundation Server. Tipos são que tornam possível para voltar à linha de base compostos por campos, formulários ou work flows. anterior. Eles sã definidos usando XML. Definições são portáteis entre os Servers do Team Foundation. 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.