MGDA - Informações Complementares

1 Introdução

Este documento descreve a Metodologia de Gestão de Demandas de Desenvolvimento Ágil de Software do TCE – MGDA-TCE, um guia de gestão de demandas de desenvolvimento e manutenção de software baseado em metodologias ágeis.

Esse guia foi elaborado com o propósito de definir processos de trabalho de desenvolvimento e manutenção com foco na entrega de software funcionando o mais rápido possível, com segurança e qualidade, seguindo as metodologias Scrum e Kanban e em conformidade com as melhores práticas de mercado.

Nos últimos anos as demandas por soluções de software alinhadas às necessidades das áreas de negócio têm forçado a TI a procurar meios de entregar resultados no menor tempo possível. Modelos tradicionais de desenvolvimento de software muitas vezes resultam em horas de trabalho destinado a gerar e manter documentos que não agregam valor ao negócio.

A adoção de um processo ágil baseado em Scrum e Kanban para gerenciamento de demandas de desenvolvimento e manutenção de software é alternativa de se gerenciar o trabalho de desenvolvimento de maneira eficiente em equipes pequenas, aumentando a capacidade de se adequar a mudanças. O Scrum faz parte do rol de metodologias ágeis mais conhecidas no mercado de TI. Trata-se de um processo para gestão de projetos complexos, interativo e incremental e sem prescrição de práticas de engenharia de software.

O foco do Scrum é entregar o maior valor ao negócio no menor tempo possível, sem abrir mão da qualidade e da segurança, através de ciclos de duas a quatro semanas chamados de Sprints. Tem como requisito a composição de equipes auto-organizadas de modo a reduzir supervisão e aumentar a comunicação entre os participantes. Como acontece na maioria dos processos ágeis, para que se obtenha um produto de qualidade, o cliente, aqui chamado de Responsável pelo Produto, deve se tornar parte da equipe de desenvolvimento, participando diretamente do processo.

O Kanban é uma metodologia para acompanhamento visual do andamento do fluxo de trabalho de equipes através de cartões de sinalização. Utilizando o Kanban gerencia-se o trabalho através de um quadro que contém todas as tarefas. Dessa forma é possível entender quais tarefas precisam ser realizadas, quais foram concluídas e principalmente quais são os gargalos no fluxo de trabalho.

A MGDA-TCE foi estruturada de forma que demandas de novos sistemas ou manutenções evolutivas em sistemas já existentes sejam executadas utilizando processos baseados em Scrum. Manutenções corretivas ou refatorações, por sua natureza mais simples e de necessidade imediata, devem ser preferencialmente tratadas utilizando processos baseados em Kanban. Em ambos os modelos não se percebe processo de engenharia de software prescrito. Por essa razão, utilizam-se complementarmente os seguintes métodos, conceitos e melhores práticas, de acordo com a conveniência:

  • XP – Extreme Programming
  • TDD – Test Driven Development;
  • Refactoring, Cobertura de Código e Integração Contínua

A metodologia aqui descrita tem como objetivo definir o fluxo de trabalho, passo-a-passo, para gerenciar demanda de desenvolvimento ou manutenção de software, artefatos obrigatórios ou opcionais de acordo com o tipo de demanda e marcos de avaliação da qualidade do produto de trabalho.

Portanto, não tem objetivo de estabelecer como construir um software, pois define apenas os passos que devem ser seguidos e os produtos esperados para acompanhamento, monitoramento e controle do trabalho.

Dessa forma, não deve ser vista como um processo de desenvolvimento de produtos de software. Aspectos específicos de como construir software, como testar, como implantar e também quais padrões de qualidade de produto, são definidos em documentos complementares e adotados de acordo com o tipo de demanda associada.

Essa metodologia deve ser seguida tanto por equipes internas quanto por empresas contratadas para desenvolvimento de software.

Essa metodologia é fortemente baseada no Scrum e possui os seguintes princípios norteadores:

PrincípioDescrição
Envolvimento do cliente requisitanteO cliente deverá estar ativamente envolvido no processo de desenvolvimento, fornecendo, validando e priorizando requisitos.
Foco nos resultadosA entrega de software funcionando deve ser priorizada em detrimento de um processo rígido de desenvolvimento.
Aceitação de mudançasO projeto e a equipe devem ser capazes de se ajustar a mudanças de requisitos, que mudam a todo tempo.
Entrega incrementalEntregar a solução em partes funcionais em curtos períodos de forma a entregar valor ao negócio o mais cedo possível e reduzir o risco de erros no entendimento de requisitos.
Manter a simplicidade
Comunicação simplesPromover sempre que possível a comunicação simples entre todos as pessoas envolvidas no projeto, independente de papel, vínculo funcional, cargo ou hierarquia.

2 Conceitos

Uma solução de software neste documento é definida como software genérico, parcial ou total, que atende a uma necessidade de negócio, agregando valor à organização. São exemplos de soluções de software: sistemas de informação, aplicativos, ferramentas, portais, sítios, blogs.

Uma demanda de software é a materialização de uma necessidade de negócio relatada por um cliente. Uma demanda possui o ciclo de vida independente do ciclo de vida de desenvolvimento ou manutenção de software. Uma demanda é classificada em:

  • Demanda de construção de software novo: quando o cliente identifica a necessidade de sistematização de um processo de negócio novo através de um sistema de informação, ou a necessidade de reconstrução de um software a partir de um legado.
  • Demanda de manutenção evolutiva de software: o cliente identifica necessidade de inclusão, alteração ou exclusão de funcionalidades a um software já existente. Quando uma demanda evolutiva provocar consumo de muitos recursos de TI, a critério da Alta Administração, poderá ser classificada como demanda de construção de software novo.
  • Demanda de manutenção corretiva de software: o cliente identifica a necessidade de correção de um defeito, ou seja, uma funcionalidade que não está em conformidade com requisitos acordados.
  • Demanda de adequação de software: o cliente identifica que um requisito de negócio mudou e a aplicação deve se adaptar a tal mudança.

As demandas existentes estão registradas no Plano Diretor de TI (PDTI) do TCE-GO e estão sujeitas a alterações considerando o processo de revisão deste Plano.

Todas as demanda não previstas no PDTI devem ser avaliadas pela Administração de modo a verificar alinhamento estratégico, sua viabilidade e prioridade.

A Ordem de Serviço – O.S. - é o instrumento de acordo e execução de tarefas entre o TCE e a Fábrica de Software. Todas as atividades de construção, manutenção, testes, documentação de software serão solicitadas previamente através desse instrumento.

A Fábrica de Software se compromete a entregar produtos seguindo padrões de qualidade definidos na ordem de serviço, que contém artefatos e tarefas que seguem as disciplinas e melhores práticas da engenharia de software.

Uma demanda de software, quando aprovada pela Alta Administração, pode gerar uma ou mais ordens de serviços. Uma ordem de serviço executada deve produzir um resultado que agregue valor ao negócio. Uma ordem de serviço pode ser classificada em:

  1. O.S. Construção de Software.
  2. O.S. Manutenção Evolutiva/Adaptativa
  3. O.S. Documentação de Sistemas.
  4. O.S. Garantia
  5. O.S Gestão de Projetos

2.3.1 O.S. de Construção de Software

  • Criadas a partir de uma demanda de software novo, tem como objetivo:
  • Criar um sistema integralmente a partir de requisitos de negócio;
  • Reconstruir um sistema a partir de um legado em produção ou não;
  • Construção de sistema a partir de sistemas provenientes de convênios com outros órgãos ou que código fonte tenha sido cedido ou obtido por outros meios;

2.3.2 O.S. de Manutenção Evolutiva/Adaptativa

Criadas a partir de uma demanda de manutenção evolutiva/adaptativas de software, tem como objetivos:

  • a adição, alteração ou exclusão de funcionalidades em sistemas em produção.
  • a correção de defeitos de software que afetam sua qualidade funcional ou adaptação de funcionalidades devido a mudança de requisitos
  • a melhoria da estrutura interna de código sem afetar funcionalidades;

2.3.3 O.S. de Documentação de Sistemas

Criadas a partir de uma demanda de documentação de sistemas, tem como objetivo gerar ou atualizar documentação de sistemas legados. Importante ressaltar que toda O.S de Construção, Evolução ou Manutenção de software deve possuir documentação mínima composta por:

  • Manual de usuário;
  • Modelo entidade relacionamento (MER);
  • Código fonte documentado;
  • Documento de especificação das funcionalidades requeridas na OS (Estórias de usuário ou Casos de uso);
  • Portanto, não se deve abrir O.S. de Documentação de Sistemas para software que desenvolvido ou mantido pela Fábrica de Software já utilizando esta metodologia, pois tais artefatos devem constar na documentação, exceto quando houver necessidade de atualização dessa.

2.3.4 O.S. de Garantia

Criadas quando o defeito ocorrer por falha da Fábrica de Software em artefato que ela desenvolveu ou quando for detectado construção de artefatos com má qualidade. Uma O.S de Garantia será aberta para correção de inconformidades sem ônus para o TCE.

2.3.5 O.S. de Gestão de Projetos

Criadas mensalmente para atividades de gerenciamento de projetos, tem como objetivos:

  • Executar, acompanhar e monitorar diariamente projetos;
  • atualizar sistemas de gerenciamento de projetos;
  • garantir a integridade dos sistemas de gestão de projetos;

Releases referem-se ao lançamento de uma nova versão oficial de um produto de software. Demandas de contrução de software podem gerar releases de produção e homologação.

As releases de produção são pacotes de funcionalidades do product backlog que serão entregues ao usuário. Uma release de produção pode ser quebrada em n releases de homologação. A release de homologação são pacotes parciais entregues aos usuários que requerem a aprovação do mesmo. Cada release de homologação pode ser quebrada em n sprints do Scrum.

Cada release de homologação está ligada a uma Ordem de Serviço, e ela só será considerada homologada quando o responsável pelo produto ou chefe do serviço de sistemas atestar o aceite.

Débitos técnicos são inconformidades com padrões estabelecidos, mas que não comprometem o uso do artefato entregue. Nesse caso o artefato pode ser aceito com ressalva. Um artefato pode conter mais de um Débito Técnico, de forma que cada não conformidade com um padrão corresponde individualmente a uma ocorrência de Débito Técnico.

As atividades de construção de um artefato são divididas em tarefas. Uma tarefa não entregue corresponde a inexecução total ou execução parcial de uma tarefa. Neste caso, uma tarefa não finalizada pode provocar a não aceitação de determinado artefato, conforme critérios de aceitação previamente estabelecidos pelo TCE.

Após definição dos tipos de demandas e ordens de serviços, os fluxos de trabalho mapeados descrevem as etapas que devem ser seguidas para se construir um software no Tribunal de Contas. Para cada tipo de Ordem de Serviço – O.S. - segue qual deve ser o subprocesso seguido:

Tipo de ProjetoSubprocesso
O.S. Construção de SoftwareDesenvolver Sistema
O.S. Manutenção Evolutiva/AdaptativaCorrigir Sistema
O.S. Documentação de Sistemas.Desenvolver Sistema ou Corrigir Sistema
O.S GarantiaCorrigir Sistema