Portal da Transparência TJPI

PODER JUDICIÁRIO DO ESTADO DO PIAUÍ SECRETARIA DA PRESIDÊNCIA - SECPRE  Pça Des. Edgard Nogueira s/n - Bairro Cabral - Centro Cívico - CEP 64000-830 Teresina - PI - www.tjpi.jus.br

---

Portaria (Presidência) Nº 911/2021 - PJPI/TJPI/SECPRE, de 09 de abril de 2021

Dispõe sobre a instituição da Metodologia de Desenvolvimento de Sistemas no âmbito do Poder Judiciário do Estado do Piauí.

O PRESIDENTE DO TRIBUNAL DE JUSTIÇA DO ESTADO DO PIAUÍ, Excelentíssimo Desembargador José Ribamar Oliveira, no uso de suas atribuições legais e regimentais;

CONSIDERANDO a Resolução nº 370, de 28 de janeiro de 2021, do Conselho Nacional de Justiça (CNJ), que institui a Estratégia Nacional de Tecnologia da Informação e Comunicação do Poder Judiciário (ENTICJUD);

CONSIDERANDO o disposto no item 2.5, do Levantamento iGovTIC-Jud-2020 do CNJ, referente à formalização e cumprimento do processo de software;

CONSIDERANDO a Tecnologia de Informação (TIC) como ferramenta indispensável à realização as funções institucionais do TJPI e como instrumento para viabilizar soluções que conduzam ao alcance dos objetivos estratégicos do Tribunal;

R E S O L V E:

Art. 1º Instituir a Metodologia de Desenvolvimento de Sistemas no âmbito da Secretaria de Tecnologia da Informação e Comunicação (STIC) do PJPI, que passa a vigorar conforme Anexo Único desta Portaria.

Art. 2º Esta Portaria entra em vigor na data de sua publicação.

Publique-se. Registre-se. Cumpra-se.

GABINETE DA PRESIDÊNCIA DO EGRÉGIO TRIBUNAL DE JUSTIÇA DO ESTADO DO PIAUÍ, em Teresina, 09 de abril de 2021.

ANEXO ÚNICO

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS - MDS-TJPI

TRIBUNAL DE JUSTIÇA DO ESTADO DO PIAUÍ

TERESINA -  2021

VERSÃO 1.0

1. INTRODUÇÃO​

Esta Metodologia de Desenvolvimento de Sistemas visa descrever e normatizar os processos de gerenciamento, desenvolvimento e manutenção de sistemas utilizados no Tribunal de Justiça do Piauí.

Em engenharia de software, uma metodologia de desenvolvimento comumente é entendida como um conjunto estruturado de práticas que pode ser repetível durante o processo de produção do sistema ou, ainda, a forma de se utilizar um conjunto de práticas, métodos ou processos para se desenvolver ou manter um produto de software, de modo que se evite subjetividade na execução do trabalho. O uso de metodologias visa à produtividade das equipes e à qualidade do produto.

Atualmente, modelos de melhoria de processos de software, como o CMMI (Capability Maturity Model Integration ou Modelo Integrado de Maturidade em Capacitação) e o MPS.Br (Melhoria do Processo de Software Brasileiro), bem como a jurisprudência do Tribunal de Contas da União (Acórdãos 953/2009, 1.233/2012, 3.132/2012 e 1.167/2013, todos do Plenário do TCU), têm utilizado o termo “processo de software” em detrimento a “metodologia de desenvolvimento de software”, embora as definições de ambos sejam, em essência, idênticas.

As metodologias ágeis são representadas por um conjunto de valores e princípios a ser utilizado no processo de desenvolvimento de sistemas. Esse conjunto de valores e princípios foi externado em 2001, por meio da divulgação do Manifesto para Desenvolvimento Ágil de Software, criado por um grupo de dezessete especialistas em processos de desenvolvimento de software que, individualmente, já utilizavam práticas e teorias adaptadas.

Alguns órgãos da administração pública adotam metodologia ágil no desenvolvimento de software: Tribunal Superior do Trabalho (TST), Banco Central do Brasil (BACEN), Instituto Nacional de Estudos e Pesquisas Educacionais Anísio Teixeira (Inep); Supremo Tribunal Federal (STF); Tribunal Superior Eleitoral (TSE), Tribunal de Justiça do Paraná (TJPR), Sistema de Administração de Recursos de Tecnologia da Informação do Governo Federal (SISP) e etc.

Considerando o Indicador de Governança, Gestão e de Infraestrutura de Tecnologia da Informação do Poder Judiciário (iGovTIC-JUD), foi elaborada uma metodologia de desenvolvimento de software, visando atender o item "Processos de Software”.

Assim os processos de software do iGovTIC-JUD devem conter os seguintes processos:

• Gerenciamento de escopo e requisitos
• Gerenciamento de Arquitetura
• Processo de Desenvolvimento
• Processo de Sustentação ou Manutenção
• Gerenciamento de solução de software

Esse processo foi elaborado considerando as melhores práticas de desenvolvimento ágeis, na qual encontram-se artefatos das metodologias, métodos e frameworks disponíveis no mercado como UML, XP, Scrum e Kanban.

Scrum e Kanban são frameworks dentro dos quais pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível.

1.1 Objetivo

Implantar uma Metodologia Desenvolvimento de Sistemas visando organizar, padronizar e melhorar os processos de software, considerando as recomendações do Conselho Nacional de Justiça.

Esta metodologia define grupo de processos de desenvolvimento de software baseados em desenvolvimento iterativo, onde os requisitos e as soluções para os problemas evoluem através da colaboração das equipes, visando a utilização de um conjunto de boas práticas de engenharia de software, permitindo entregas freqüentes com alto grau de qualidade.

2. METODOLOGIAS DE DESENVOLVIMENTO E MANUTENÇÃO DE SISTEMAS​

Tendo em conta a grande diversidade da natureza das demandas de TI e a variedade do tamanho e configuração das equipes de trabalho, definir somente uma metodologia de desenvolvimento e manutenção de software pode, dependendo da situação, criar um entrave para o bom andamento das atividades, ainda que se trate de um processo ágil. Isto posto, serão apresentadas duas formas de trabalho possíveis - Scrum  e Kanban - de modo de, independente de qual for adotada, o objetivo principal será atendido, que é a entrega rápida e eficaz de resultados, com gerenciamento ágil do andamento dos trabalhos.

2.1 SCRUM

O Scrum é recomendado para equipes de três ou mais pessoas, e escopo de trabalho claro o bastante para a definição de iterações de tempo fixo (de duas a quatro semanas cada).

2.1.1 Papéis Envolvidos

2.1.2 Definições do Processo

Backlog: É uma lista que contém todas as funcionalidades desejadas para um novo produto ou para a evolução de um já existente. O conteúdo dessa lista é definido pelo Product Owner. O backlog do produto é dinâmico e construído ao longo do projeto.

Critérios de aceitação: O critério de aceite nada mais é que os pontos que os desenvolvedores devem cumprir antes de considerar aquela história como finalizada. O que deve ser feito, o que será testado e quais os resultados esperados são itens que podem estar na lista de critérios para cada uma das histórias. É responsabilidade do Product Owner, juntamente com o Time Scrum, levantar os critérios de aceite para cada história de usuário.

Daily Scrum: Breve reunião diária feita pelos membros da Equipe como forma de disseminar o conhecimento sobre o que foi feito no dia anterior, identificar problemas e priorizar o que deve ser feito no dia que se inicia. A reunião é feita "em pé", como forma de salientar seu caráter de duração rápido. Cada membro do time responde as seguintes perguntas: O que você fez ontem? O que você fará hoje? Há algum impedimento em seu caminho? Durante a reunião não se deve efetivamente resolver os problemas/impedimentos detectados, o que faria a reunião se estender, isso deve ser feito em um momento posterior com o apoio do Scrum Master.

Equipe/Time: A equipe técnica se organiza para definir a melhor maneira de entregar as funcionalidades de maior prioridade. Uma equipe de Scrum é composta de 3 a 9 indivíduos – requisito fundamental para a boa prática da metodologia. Deve ser multifuncional, ou seja, composta por profissionais de diversas especialidades, desenvolvedores, arquitetos da informação, designers, testadores, etc. É importante que todos os membros se dediquem, em tempo integral, à equipe. Exceções aplicam-se aos profissionais que exercem papéis pontuais: administradores de base de dados, analistas de suporte e equipe de infraestrutura. As equipes devem ser auto-organizáveis, não havendo títulos ou hierarquia entre seus membros.

História de usuário: É um texto ou parágrafo de explicação da funcionalidade, que define suas características. O objetivo da história não é definir o escopo global do sistema, mas sim estimar a complexidade de cada parte do sistema visando possibilitar a estimativa do esforço necessário para a sua implementação. Recomenda-se que as histórias mais importantes e/ou mais difíceis tenham prioridade.

Kanban: É um termo de origem japonesa e significa literalmente “cartão” ou “sinalização”. Além de representar o quadro de atividades, Kanban é também um método de gestão de mudanças que dá ênfase aos seguintes princípios: visualizar o trabalho em andamento; visualizar cada passo em sua cadeia de valor, do conceito geral até software que se possa lançar; tornar explícitas as políticas sendo seguidas, entre outros princípios. Pode-se utilizar cartões (post-it e outros) para indicar o andamento do desenvolvimento do software, colocando neles indicações sobre uma determinada tarefa, por exemplo: “para executar”, “em andamento” ou “finalizado”.

MGP: Metodologia de Gestão de Projetos.

Planning Poker: Técnica usada para estimar o tamanho de uma história. Cada membro da equipe recebe um baralho de 13 cartas. Sempre que uma história for estimada, cada membro escolhe uma carta que represente a sua estimativa de tempo (em pontos por história) colocando-a virada para baixo sobre a mesa. Quando todos os membros da equipe tiverem feito sua estimativa, as cartas são reveladas simultaneamente. Dessa forma, cada membro da equipe é forçado a pensar por si próprio ao invés de basear-se na estimativa de outra pessoa. Se houver uma grande divergência entre duas estimativas, a equipe discute as diferenças e tenta chegar a uma visão comum do trabalho envolvido na história. Eles podem fazer algum tipo de decomposição de tarefas. Depois disso, a equipe faz novamente a estimativa. Esse processo é repetido até que as estimativas de tempo cheguem a uma convergência, isto é, até que todas as estimativas sejam aproximadamente a mesma para cada história.

Product Owner: É a nomenclatura que identifica o indivíduo no papel de cliente no processo de desenvolvimento de software. O Product Owner é responsável por determinar as prioridades do que deve ser feito no software. Deve ser capaz de sanar as dúvidas de requisitos.

Scrum: É um método ágil para gerenciamento de projetos baseado em times pequenos e auto-organizados, forte visibilidade e rápida adaptação e que permite trabalhar de forma iterativa para garantir a inspeção e adaptação do produto de forma incremental.

Scrum Master: É um facilitador cuja função primária é remover impedimentos à capacidade da equipe para entregar o objetivo da Sprint. O Scrum Master garante que o processo Scrum seja usado como pretendido. Ele não é líder da equipe, já que as equipes são autogerenciadas, mas atua como um mediador entre a equipe e qualquer influência desestabilizadora. Outra função extremamente importante de um Scrum Master é a de assegurar que a equipe esteja utilizando corretamente as práticas de Scrum, motivando os integrantes, mantendo o foco na meta da Sprint.

Sprint: Uma Sprint é a unidade básica de desenvolvimento em Scrum. Tende a durar entre duas semanas e um mês, sendo um esforço em uma "caixa de tempo" (restrito a uma duração específica) de comprimento constante.

Sprint Backlog: Subconjunto de funcionalidades do Backlog alocadas para serem implementadas em uma determinada Sprint.

Sprint Planning: Reunião de planejamento efetuada antes do início de uma Sprint para priorizar os itens do Product Backlog e selecionar as funcionalidades que entrarão para o Sprint Backlog de acordo com a capacidade da Equipe.

Sprint Review (Apresentação da Sprint): É uma reunião que deve ser realizada nos últimos dias da Sprint, com a participação  de todos, para apresentar o resultado do trabalho de toda a Sprint e, também, levantar os pontos positivos e negativos. Nessa reunião, podem ser levantadas novas funcionalidades que não foram entregues e a necessidade de novos itens.

Sprint Retrospective: Reunião efetuada após a Sprint para identificar o que funcionou bem durante a Sprint e deve ser mantido para as próximas, o que funcionou mal e deve ser melhorado e que ações serão tomadas para melhorar.

TAP: É o artefato da MGP por meio do qual a abertura do projeto é formalizada. Nele está contida a descrição dos objetivos macros, requisitos de alto nível e riscos preliminares elaborados com a participação do cliente (ou Product Owner).

TEP: Artefato da MGP responsável por formalizar o encerramento do projeto.

Técnicas de Extreme Programming (XP): O Scrum é focado nas práticas de gerenciamento e organização, enquanto o XP dá mais atenção às tarefas de programação. Muitas das técnicas do XP são utilizadas largamente pelas equipes de programação. Cita-se, como exemplos: programação em par; desenvolvimento orientado a testes (TDD); design incremental; integração contínua; propriedade coletiva do código; ambiente de trabalho informativo; padrão de codificação, entre outros.

2.1.3 Visão Geral

A Metodologia de Desenvolvimento de Sistemas - SCRUM do Tribunal de Justiça do Piauí - MDS-SCRUM-TJPI é composta por quatro etapas que abrangem todo o ciclo de vida do desenvolvimento de sistemas e que promovem a agilidade no atendimento às necessidades dos projetos do TJPI.

As etapas são: Iniciar Projeto, Produzir a Sprint, Encerrar a Sprint e Encerrar do Projeto. Essas etapas são compostas por subprocessos que detalham sua execução.Os novos sistemas e as manutenções nos sistemas já implantados devem seguir as fases da Metodologia de Desenvolvimento de Sistemas.

2.1.3.1 Projeto de Sistema

Projeto de Sistema é um serviço disponibilizado pela Área de Tecnologia da Informação para atender várias necessidades do órgão. São exemplos de um projeto de sistema:

• Novo Desenvolvimento: Um novo sistema de informação pode ser desenvolvido integralmente ou reconstruído a partir de um legado;
• Customização e Implantação: A partir de novas necessidades de negócio, podem ser encontrados sistemas de informação já existentes para estas necessidades, dispensando a construção de um novo. Nestes casos o projeto pode ser a customização e implantação do sistema dentro da estrutura e arquitetura da instituição, utilizando um código-fonte que foi, em todo ou em parte, cedido ou repassado à instituição, ou obtido por outros meios;
• Manutenções Evolutivas: Em geral as demandas de evolução de sistemas de informação são de responsabilidade da equipe de sustentação. Estas demandas quando de tamanho ou complexidade maiores poderão ser tratadas como projetos de sistema. Manutenções adaptativas, perfectivas e cosméticas são exemplos de evoluções de sistemas de informação.

2.1.3.2 Análise da Demanda

Formulário de Solicitação - Contém a Solicitação da Unidade Requisitante.

Termo de Abertura do Projeto - Caso a solicitação se desdobre em um projeto, será necessária a elaboração do referido termo que conterá: justificativa, produtos e serviços participantes, cronograma macro, restrições, premissas e assinaturas, conforme definido no Modelo de Gerenciamento de Projetos e Ações de TIC.

2.1.4 Iniciar Projeto

2.1.4.1 Definir Product Owner

Definição da pessoa responsável pelo produto, denominada Product Owner - P.O.

O P.O deve ser uma pessoa capaz de subsidiar as decisões e informações necessárias para a construção da solução a ser proposta e deve conhecer integralmente as necessidades do cliente.

2.1.4.2 Definir a Visão do Produto

Definição da Visão do produto - juntamente com clientes, gestores, interessados, executivos entre outros - descrevendo o seu problema atual, as suas necessidades e as expectativas que subsidiarão a razão da existência do projeto.

2.1.4.3 Definir os itens do Backlog do Produto

Identificação das funcionalidades e das condições de desenvolvimento para atender à visão do Product Owner.

2.1.4.4 Priorizar os itens do backlog do produto

Priorização dos itens do backlog do produto sob a perspectiva do Product Owner, os quais ajudarão na composição das Sprints conforme a produtividade do Time Scrum.

2.1.4.5 Formar o Time Scrum

Definição do Time Scrum que atenderá ao projeto, caso seja desenvolvido por equipe interna do TJPI. Se ele for desenvolvido por fábrica de software, o TJPI definirá quem comporá o time de acompanhamento do projeto.

2.1.4.6 Estimar o tamanho do produto

Estimativa do tamanho funcional do produto por pontos de história de usuário ou por análise de ponto de função. Caso o projeto seja atendido por fábrica de software, a métrica por ponto de função é contratualmente obrigatória.

2.1.5 Produzir a Sprint

2.1.5.1 Definir Escopo da Sprint

Trata-se de uma das tarefas mais importantes do processo, durante a qual se reúnem o Product Owner e o Time Scrum para selecionar os itens do backlog do produto que comporão o escopo da entrega ao final da Sprint (Sprint Backlog), conforme a prioridade do Product Owner. Ainda, nessa tarefa, deve ser definida a meta da Sprint para orientar as ações do Time Scrum.

No caso de sistema novo, orienta-se que a primeira Sprint, denominada Sprint 0, a fim de validar a arquitetura e testar o ambiente de desenvolvimento, tenha como foco a definição da arquitetura do software, a construção do modelo de dados lógico ou conceitual, com base no backlog do produto, e a implementação de ao menos uma funcionalidade básica.

2.1.5.2 Planejar a Sprint

Reunião com o objetivo de definir como os itens selecionados para a Sprint serão construídos visando criar um incremento e atingir sua meta. Para isso, o Time Scrum, com a participação do Product Owner, imagina, para cada item do Backlog, uma lista de atividades que possam ser executadas no período de um dia a fim de facilitar o acompanhamento diário.

2.1.6 Executar a Sprint

Conjunto de tarefas a partir do qual o Time Scrum executa as atividades de construção dos itens da Sprint praticando as técnicas e princípios de métodos ágeis até que seja possível a conclusão do incremento do produto a ser entregue.

2.1.6.1 Realizar Reunião Diária

Realização de reuniões diárias com o Time Scrum, preferencialmente de curta duração e que possam ser feitas em pé, nas quais cada membro deve participar ativamente relatando as atividades executadas desde a última reunião, as atividades a serem executadas no dia e os impedimentos encontrados. Dessa maneira é possível ganhar visibilidade sobre o caminho para alcançar a meta da Sprint, atuar nos impedimentos relatados e planejar as atividades do dia seguinte.

Durante as reuniões, as questões que requeiram mais tempo de discussão devem ser tratadas separadamente com os envolvidos para não comprometer todo o time. Os impedimentos que configurarem riscos de caráter mais abrangente ou institucional devem ser registrados na ferramenta de gestão de projetos para monitoramento e, se for o caso, escalonamento.

2.1.6.2 Elicitar os requisitos

Identificação, detalhamento, documentação e gerenciamento dos requisitos que compõem os itens da Sprint, conforme padrões de modelagem do projeto ou do Time Scrum.

2.1.6.3 Construir os itens da Sprint

Implementação dos requisitos com apoio dos padrões de arquitetura, de banco de dados e de design estabelecidos para o projeto, com a intenção de entregar algo que possa gerar resultado observável ao Product Owner.

2.1.6.4 Testar os requisitos construídos

Aplicação das estratégias de teste definidas pelo projeto para minimizar os defeitos e não conformidades do produto no momento de sua verificação no ambiente de homologação, aumentando as chances de sua aprovação pelo Product Owner.

2.1.6.5 Implantar versão no ambiente de homologação do TJPI

Implantação, no ambiente de homologação do TJPI, de tudo o que foi construído para que haja validação por parte do Product Owner quanto à qualidade do produto entregue e à satisfação do cliente. Após cada implantação incremental do produto, será necessário realizar os procedimentos da construção contínua quanto à verificação dos testes automatizados (unitário, de integração e funcional), à auditoria do código-fonte e ao incremento da versão.

2.1.6.6 Preparar a apresentação da Sprint

Preparação do Time Scrum para a apresentação do resultado da Sprint ao Product Owner, elencando os problemas enfrentados e as soluções adotadas, além do alinhamento do time quanto ao alcance total ou parcial da meta da Sprint.

​2.1.6.7 Apresentar a Sprint

Apresentação ao Product Owner das funcionalidades concluídas, demonstrando o que foi feito e o que não foi. O Product Owner aceitará (ou não) o produto como entregue, informando, se houver, as não conformidades e sua criticidade.

Se forem apontadas não conformidades críticas que comprometam a meta da Sprint, o Product Owner poderá optar por aceitar a Sprint com ressalvas e definir que as não conformidades sejam corrigidas nas próximas Sprints.

Caso o desenvolvimento seja feito por uma fábrica de software, essa apresentação é premissa para a formalização do aceite provisório dos produtos entregues, e os itens não aprovados serão medidos e não remunerados, voltarão para o Backlog do produto e aguardarão nova priorização.

2.1.6.8 Formalizar a entrega do Sprint

O gestor do sistema formaliza o aceite da entrega da Sprint, por parte do Product Owner, com ou sem ressalvas quanto a possíveis não conformidades encontradas. Após o aceite, o incremento do produto se torna apto para ser implantado em ambiente de produção, caso esse tenha sido o acordo entre o Time Scrum e Product Owner.

Se o projeto utiliza serviços de fábrica de software, o aceite provisório dos produtos entregues em conformidade pela contratada deve ser formalizado.

2.1.7 Encerrar a Sprint

2.1.7.1 Gerar Laudo de Garantia de Qualidade

Verificação da qualidade dos produtos entregues quanto aos padrões corporativos e do projeto por meio da emissão de laudos de conformidade. Para projetos de fábrica de software, os laudos a serem emitidos serão indicados na ordem de serviço que autorizou a execução da Sprint. Projetos que não utilizam serviços de fábrica de software também podem solicitar emissão de laudos de qualidade, pois eles auxiliam o Scrum Master a atestar a qualidade dos produtos, assim como sua conformidade com os padrões definidos. Nesse caso, a emissão dos laudos deve ser previamente negociada com os analistas de conformidade.

​2.1.7.2 Aprovar Sprint

Realiza a verificação dos laudos emitidos pelos analistas de conformidade e decide pela aprovação dos produtos entregues na Sprint. A aprovação pode ser integral ou parcial (com ressalvas). A aprovação parcial se dará quando as não conformidades apontadas pelos laudos forem admissíveis, em comum acordo com o Product Owner. Nesse caso, as não conformidades devem ser ajustadas pela contratada de acordo com a definição do Gestor do sistema.

​2.1.7.3 Rejeitar Sprint

Realiza a verificação dos laudos emitidos pela equipe de avaliação de conformidade e decide pela rejeição da qualidade do produto entregue na Sprint.

Caso o projeto utilize fábrica de software, o aceite definitivo dos produtos previstos na ordem de serviço não será concedido à contratada, e os itens retornarão ao Backlog do produto, aguardarão nova priorização e autorização para serem executados.

Nesse caso, recomenda-se avaliar a conveniência de abrir uma Sprint específica para entrega desses produtos rejeitados mediante abertura de nova ordem de serviço.

​2.1.7.4 Realizar reunião de retrospectiva da Sprint

Realiza a revisão do processo de trabalho de execução da Sprint para identificar os itens que possam ser melhorados e, assim, tornar o processo mais agradável e eficiente na próxima Sprint.

2.1.8 Encerrar Projeto

​2.1.8.1 Implantar versão no ambiente de produção do TJPI

Realiza a implantação do produto ou do seu incremento final no seu ambiente de produção.

​2.1.8.2 Transmitir conhecimento

Transmite o conhecimento sobre o produto aos usuários finais, Service Desk e equipes de suporte a fim de proporcionar as condições mínimas necessárias para a sua operação, o seu suporte e o encaminhamento de chamados.

​2.1.8.3 Encerrar o projeto

Esta Tarefa consiste em realizar o encerramento formal do projeto conforme o processo da Metodologia de Gestão de Projetos do Escritório de Projetos do Tribunal de Justiça do Piauí.

2.1.9 Conjunto de Artefatos

Os modelos dos documentos serão disponibilizados na intranet e o seu preenchimento é de responsabilidade dos envolvidos no processo, conforme definido em cada atividade. A Seção de Planejamento Estratégico e Gestão de Projetos de TIC pode auxiliar na definição dos artefatos indicados para cada disciplina da engenharia de software, assim como, se for o caso, produzir novos artefatos ou versões atualizadas de produtos de trabalho existentes a fim de evoluir o processo e torná-lo cada vez mais útil para as equipes de projetos de desenvolvimento.

Alguns produtos de trabalho devem ser elaborados obrigatoriamente para o sistema desenvolvido ter o mínimo de documentação necessária para sua manutenção. Já os produtos de trabalho opcionais poderão ser utilizados conforme a definição do responsável do projeto. Os artefatos de um processo podem e devem ser utilizados de forma complementar a outros.

Abaixo, segue uma relação dos principais artefatos disponibilizados pelas metodologias vigentes no TJPI.

2.2 KANBAN

Kanban é uma abordagem ainda mais enxuta para o desenvolvimento ágil de software, e mostra-se mais adequada para atividades que não possibilitam planejamento por um tempo fixo, e nos casos em que atividades de planejamento e estimativas tornem o método moroso. É útil também para pequenas equipes, com fluxo de trabalho sob demanda, como manutenção e suporte de sistemas. Pode ser adotada para projetos de toda natureza, não apenas de desenvolvimento de software.

2.2.1 Premissas

2.2.1.1. Visualize o fluxo de trabalho: divida o trabalho em tarefas, para cada item gere um cartão e coloque no quadro de tarefas (o quadro Kanban), e use colunas nomeadas para ilustrar onde cada item está no fluxo de trabalho (backlog, fazendo, concluído, implantado, etc).

2.2.1.2. Defina o limite do trabalho em progresso (WIP - work in progress): associe limites explícitos para quantos itens podem estar em progresso em cada estado do fluxo de trabalho. A princípio esses limites são definidos, mas devem ser ajustados à medida em que se identifica gargalos ou folgas em cada etapa do fluxo. Aos poucos o WIP passa a ser reconhecido, em vez de definido, e assim passa a representar a realidade da equipe. A partir disso, pode-se implantar melhorias no processo a fim de otimizar o resultado do trabalho.

2.2.1.3. Identifique o tempo de execução da tarefa: identificar o tempo médio para completar um item, o chamado de “tempo de ciclo”. Não se define o tempo para a tarefa, mas se percebe o tempo médio delas, com base no histórico de tarefas. Esse indicador é útil para monitoramento do processo e como feedback das ações para melhoria do mesmo, devendo buscar o menor e mais previsível possível tempo de ciclo. Além disso, rever o tempo gasto em todo o fluxo nos permite uma maior fidelidade aos ANS - Acordos de Nível de Serviço (ou do inglês SLAs – Service-Level Agreements) e fazer planos de entrega mais realistas.

2.2.2 Artefatos

Dessa forma, os artefatos básicos no MDS-Kanban são o próprio quadro Kanban, com a organização visual das atividades, e as entregas propriamente ditas (artefatos entregues, que, em se tratando de software, é o software implantado). Porém não se restringe a isso, podendo utilizar alguns dos artefatos definidos para o Scrum.

2.2.3 Papéis

No contexto do TJPI, o Kanban necessita apenas do requisitante, de um líder de equipe (que pode ser o chefe de seção, coordenador, ou um membro designado por estes) e a equipe de trabalho. Esses papéis também existem no Scrum (respectivamente, PO, Scrum Master e time), e têm basicamente as mesmas funções.

2.2.4 Comparação entre SCRUM e KANBAN

Percebe-se que os dois métodos são ágeis, têm alguns aspectos em comum, e ainda a possibilidade de adotar práticas um do outro de modo a tornar o processo ainda mais adequado à realidade do projeto e cada vez mais eficaz. Suas diferenças de maior destaque são explanadas a seguir:

• Scrum é baseado em iterações de tempo fixo. No Kanban, iterações de duração fixa não são prescritas. É livre a escolha sobre quando planejar, melhorar processo e entregar. Pode-se escolher, por exemplo, fazer essas atividades numa periodicidade regular (“release toda segunda”), ou por demanda (“release sempre que tivermos algo útil a entregar”). Uma equipe orientada para eventos pode definir seu processo de trabalho da seguinte forma: "Nós Iniciamos uma reunião de planejamento sempre que esgotamos nosso trabalho a fazer. Iniciamos uma release sempre que temos um grupo Mínimo Aceitável de Funcionalidades (MAF's) pronto para entrega. Iniciamos um círculo de qualidade espontâneo sempre que nos deparamos com o mesmo problema pela segunda vez. Também fazemos uma retrospectiva mais profunda toda quarta semana."
• Kanban limita WIP por estado de fluxo de trabalho, Scrum por iteração. Então, tanto Scrum quanto Kanban limitam as atividades em andamento, mas de formas diferentes. Equipes Scrum geralmente medem a velocidade por iteração (quantos itens  serão feitos ao longo do tempo). Uma vez que a equipe sabe sua velocidade, esta torna-se seu limite de atividades em andamento. Uma equipe que tem velocidade média de 10, geralmente, não irá colocar mais de 10 itens (ou “pontos da estória”) em uma iteração. Desta forma, em Scrum as atividades em andamento são limitadas por unidade de tempo. Em Kanban as atividades em andamento são limitadas pelo fluxo de trabalho (quantos itens podem ser feitos ao mesmo tempo, independente da cadência).
• Scrum resiste a mudanças dentro de uma iteração, enquanto o Kanban segue o princípio geral de ”um item fora = um item dentro” (controlado pelos limites de trabalho em andamento).
• Em Scrum, o Product Owner não pode alterar o quadro Scrum quando a equipe já estiver comprometida com determinados de itens na iteração. Já em Kanban, você precisa definir suas próprias regras básicas sobre quem tem permissão de modificar o que no quadro, e normalmente o Product Owner pode fazer quaisquer modificações nos itens “A Fazer” ou “Backlog”.

2.3 Critérios para definição do método a ser adotado

Para facilitar a compreensão de qual método adotar, segue algumas questões a ser respondidas a fim de que se perceba qual a escolha mais adequada.

1. Trata-se de projeto ou ação priorizado segundo o Processo de Gerenciamento de Projetos e Ações de TIC? Scrum.
2. Trata-se de equipe de manutenção ou suporte a sistemas, que realiza tarefas sob demanda, pequenas, e atribuídas de forma pontual pelo coordenador da equipe? Kanban.
3. A equipe de trabalho é composta por três ou mais pessoas? Scrum.
4. A equipe de trabalho é composta por até três pessoas? Kanban.
5. O escopo do trabalho solicitado é definido e tem tamanho que permite um planejamento de trabalho com tempo fixo (duas a quatro semanas)? Scrum.
6. As prioridades mudam diariamente, é complicado passar alguns dias trabalhando num projeto sem ter de parar a todo instante para atender demandas aleatórias? Kanban.
7. Não há conhecimento de planejamento e gerenciamento de projetos e atividades? Kanban.

Tanto Scrum quanto Kanban são empíricos no sentido que se espera que o processo seja experimentado e personalizado ao ambiente. Nem um nem outro fornecem todos os mecanismos necessários para a realização do trabalho – eles apenas fornecem um conjunto básico de restrições para conduzir o seu próprio processo de melhoria. Então, é preciso adequar a escolha a cada contexto, desde que não se deturpe o processo, tornando-o tão personalizado que deixe de apresentar o mínimo definido para o TJPI (que é o Kanban).

3. DOCUMENTOS DE REFERÊNCIA​

Documento assinado eletronicamente por José Ribamar Oliveira, Presidente, em 09/04/2021, às 16:11, conforme art. 1º, III, "b", da Lei 11.419/2006.

A autenticidade do documento pode ser conferida no site http://sei.tjpi.jus.br/verificar.php informando o código verificador 2315091 e o código CRC D1C4D471.