Metodologia de Gestão de projetos baseado em AGIL

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) .............................................25 5.1 Pilares do ALM.................................................................................................................25 5.1.1 Pessoas .............................................................................................................................25 5.1.2 Processos ..........................................................................................................................27 5.1.3 Ferramentas ......................................................................................................................28 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 figuras Figura 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 tabelas Tabela 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. 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

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

17 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 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,

18 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 resultado

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

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 Diretor Gerente de Gerente de sistemas Qualidade Controller Controller Arquiteto de Analista de Desenvolvedor Analista de Técnico de sistemas sistemas qualidade qualidade 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

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

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

29 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 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. Figura 6 – Macrofluxo MGPS-DSA

32

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

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.

Figura 7 – Diagrama do processo de Gerenciamento da demanda

35

Tabela 1 – Matriz de responsabilidade Gerenciamento da demanda Atividades do processo Gestão da demanda Coordenador Assessoria da CTI Realizar triagem da demanda R Analisar alinhamento ao PDTI/PTI/PE Estimar data do projeto Comunicar partes interessadas Responder solicitação Definir chamado em cronograma

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

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

39 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 Concepção da aplicaçãoConcepçã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).

Figura 8 – Diagrama do processo Concepção da aplicação

41

Tabela 2 – Matriz de responsabilidade concepção da aplicaçãoCoordenador Assessoria da CTI Atividades do processo Gerenciamento da demanda Elaborar (TAP) Termo de Abertura do Projeto Elaborar LTI Alocar Recursos Configurar Plataforma ALM Documentar requisitos de Negócio(Epics) Elaborar Plano de entregas (release)

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

43 7.1.4 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.1.5 CONCEPÇÃO DA APLICAÇÃO: ATIVIDADES 7.1.5.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.1.5.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.1.5.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.1.5.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.1.5.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.1.5.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.1.5.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 grupo do

46 TFS “Project Administrator”. As informações de grupos e permissões pode ser visualizado no documento de Permissões do ALM. 7.1.5.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.1.5.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.1.5.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 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.