Secretaria de Tecnologia da Informação/SETI

1PADSPROCESSO ÁGIL DE DESENVOLVIMENTO DE SOFTWARE

Núcleo de Escritório de Projetos de Tecnologia da Informação/NUPROJ

Secretaria de Tecnologia da Informação/SETI


“Tornar a prestação jurisdicional mais

negócio e criando a cultura de inovação no desenvolvimento de softwares de qualidade.” Propósito da Secretaria de Desenvolvimento de Sistemas da Coordenadoria-Geral

de Tecnologia da Informação do TJDFT (SEDES/CGTI) levantado, colaborativamente, pelos servidores desta unidade usando Golden Circle.

Núcleo de Escritório de Projetos de Tecnologia da Informação/NUPROJ

Secretaria de Tecnologia da Informação/SETI


AgradecimentosO Escritório de Projetos - NUPROJ agradece a participação e colaboração das pessoas que participaram do evento de Desing Thinking no dia 06 de Fevereiro de 2019.

Alessandra Guaracy de Oliveira SanchesAllan Timo Gomes

Antonio Francisco Osório JúniorCynthia Carvalho Branco Vitoriano Xavier

Edgar Luciano Morais MartinsEmerson Luiz Venerato Bandeira

Euziane Meire de Medeiros RochaIrinaldo Pereira de Sales

Irving Rocha Monteiro LopesIsaac Ismael da Silva Santos

Jailson Luiz Mota dos SantosJairo Simão Santana Melo

Jorge Torres CoelhoJosé Gonçalo dos Santos

Juliana Sousa NogueiraLucinéia Turnes

Luiz Eduardo dos Santos

Marcelo Campos BritoMarcelo Nardelli Pinto SantanaMarcelo Vinicius de Sousa CamposMárcio Jose da SilvaMarcus Vinicius dos Passos PerussoMauricio Fagundes da CostaMichelle Kakoi LelisNairon Nunes da SilvaNatasha Ribeiro Prado BarrosNelson Paiva MeirelesOtacílio Francisco de Souza NetoPlinio Miranda de Carvalho NetoRafael Barbosa de Oliveira CostaRicardo Pinheiro OrtegalRobson Rodrigo Tenório GonzagaThiago Arruda NevesTobias Ricken de MedeirosVanessa Rocha


Expediente

Tribunal de Justiça do Distrito Federal e dos Territórios – TJDFTSecretaria de Tecnologia da Informação – SETI

Subsecretaria de Apoio à Governança e Gestão Integrada de Tecnologia da Informação – SUATI Coordenadoria de Gestão Integrada de Serviços e Projetos de Tecnologia da Informação – COGISP

CONTEÚDO E EDIÇÃONúcleo de Escritório se Projetos de Tecnologia da Informação - NUPROJ/COGISP/SUATI/SETI

REVISÃO TEXTUALNúcleo de Escritório se Projetos de Tecnologia da Informação - NUPROJ/COGISP/SUATI/SETI

PROJETO GRÁFICO E DIAGRAMAÇÃONúcleo de Gestão da Comunicação e Padronização de Tecnologia da Informação – NUGCOM/COGISP/SUATI/SETI


Histórico de versões

Data Versão Autor Descrição

12/03/2019 1.0 SERESC Versão inicial

21/06/2019 1.1 SERESC Incluída seção de Segurança da Informação e atualizada seção de Recomen-dações Legais e Referências.

06/01/2021 1.2 EProjTI Incluído na Sprint Zero no item “Arquitetura do Projeto” uma referência a “Diretrizes para Integração de Sistemas e Desenvolvimento de novos módu-

los no PJe”.

10/09/2021 1.3 NUPROJ Incluída seção Critérios de Acessibilidade e a sua referência em Eventos, Ar-tefatos e Práticas Principais.

13/09/2021 1.4 NUPROJ Atualização do nome das unidades do TJDFT após o REORG do Tribunal.


Sumário

Agradecimentos............................................................................ 3Expediente....................................................................................4Histórico de versões.......................................................................5Introdução.....................................................................................7Processo Ágil de Desenvolvimento................................................9Papéis e Responsabilidades...........................................................9O Processo....................................................................................10Processo Ágil de Desenvolvimento de Software (PADS)...............11Scrum..........................................................................................12Início do Projeto...........................................................................14Planejamento Inicial....................................................................15Sprint Zero..................................................................................16Planejamento do Sprint...............................................................17Execução do Sprint.......................................................................18Reunião Diária.............................................................................20Sessão de Refinamento................................................................22Revisão do Sprint.........................................................................24Homologação Assistida...............................................................26Retrospectiva do Sprint................................................................28

Cancelamento do Sprint..............................................................30Product Backlog..........................................................................31Sprint Backlog............................................................................32Incremento do Produto...............................................................33Release do produto.....................................................................34Definição de Preparado e de Pronto............................................35Definição de Meta......................................................................37Distribuição de Trabalho.............................................................38Testes e Integração Contínua......................................................39Feedback dos Parceiros................................................................40Feedback do Time.......................................................................41Divulgação do Produto...............................................................42Feedback dos Usuários................................................................43Práticas Complementares...........................................................44Comunicação..............................................................................45Segurança da Informação...........................................................46Critérios de Acessibilidade..........................................................47Recomendações Legais...............................................................50Referências.................................................................................54


Introdução

Nomeado como Processo Ágil de Desenvolvimento de Softwa-re (PADS), o presente documento descreve o processo de desenvol-vimento de sistemas de informação para projetos desta natureza no âmbito da Secretaria de Tecnologia da Informação – SETI do TJDFT em cumprimento à Resolução do CNJ nº 211/2015 , Art. 12, III - macropro-cesso de software, c) de processos de desenvolvimento e sustentação.

Destaca-se que o processo é contextualmente baseado em boas práticas ágeis de mercado, especialmente no Scrum, além do Lean Kanban, Lean Inception, DevOps, Desenvolvimento Orientado a Tes-tes (TDD), Programação em Par, Testes Automatizados, Integração Contínua e Entrega Contínua.

O Scrum não é uma metodologia, não define regras, mas sim es-tabelece um conjunto de boas práticas, entre elas, a transparência, inspeção e adaptação - pilares do Scrum - constantes na execução do processo de desenvolvimento. Dessa forma, é possível priorizar entregas de maior valor ao negócio, responder tempestivamente às mudanças, aprimorar comunicação, incentivar feedbacks constantes, consequentemente, promover melhorias inerentes ao processo.

Sendo assim, este guia não é prescritivo, estabelece diretrizes mí-nimas, não regras estritas, para que o objetivo da metodologia seja al-cançado: cadência de entregas de maior valor de negócio, primando

sempre pela qualidade do produto.A Figura a seguir apresenta os cinco Valores do Scrum1: coragem,

foco, comprometimento, respeito e abertura.

Destaca-se que a observação constante destes valores é alta-1 Cinco valores do Scrum disponível em http://www.metodoagil.com/valores-do-scrum/.

O time Scrum precisa ter coragem para fazer a coisa certa e trabalhar em problemas difíceis.

CORAGEM

As pessoas se comprometem pes-soalmente em alcançar os objeti-vos do time de Scrum.

COMPROMETIMENTO

Os membros do time Scrum respeitam uns aos outros para serem capazes e independentes.

RESPEITO

O time Scrum e seus Stakeholders concordm em estarem abertos a todo o trabalho e aos desafios com a execução dos trabalhos.

ABERTURA

Todos focam no trabalho de Sprint e nos objetivos do time Scrum.

FOCOT

O

Oec

A

Valores doScrum

http://www.metodoagil.com/valores-do-scrum/


mente recomendada, pois visa maximizar o sucesso do processo de desenvolvimento de sistemas na Subsecretaria de Desenvolvimento de Sistemas (SUDES) da SETI, conduzindo para entrega de produtos que satisfaçam os usuários.

Nesta esteira, impende2 esclarecer que este guia e seus anexos trazem o processo ágil de desenvolvimento de software da TI por meio da definição de papéis e responsabilidades, de um fluxo de eventos, de práticas e de artefatos que combinados dão suporte ao processo de desenvolvimento desde o planejamento inicial do projeto de soft-ware, seus ciclos de iterações3 de desenvolvimento do sistema até a implantação das entregas (releases).

Salienta-se que o guia de desenvolvimento de software da SETI é elaborado/atualizado conforme referências bibliográficas elencadas no final deste documento, na experiência com o atual processo da SUDES, bem com nas sugestões e ideias apresentadas em Workshop de Design Thinking realizado no dia 06 de Fevereiro de 2019 com os servidores da SUDES.

2 é imperativo; é obrigatório; não se pode deixar de3 Repetir; tornar a fazer


Processo Ágil de Desenvolvimento

PAPÉIS E RESPONSABILIDADES

Os papéis de um time de desenvolvimento de sistemas no pro-cesso ágil baseado em Scrum deve compreender uma equipe de espe-cialistas em TI composta por três papéis: Scrum Master, Product Ow-ner e Dev Team. O chamado Time Scrum é formado por um Scrum Master, um Product Owner e três a sete membros técnicos no Dev Team. O número ideal de membros de um Time Scrum varia entre 5 a 9. A seguir, o quadro resumo das competências e responsabilidades de cada papel do Time Scrum.

FacilitadorScrum Master

COACH

LÍDER

AUTORIDADE NO PROCESSO

ESCUDO CONTRA INTERFERÊNCIAS

REMOVEDOR DE IMPEDIMENTOS

AGENTE DE MUDANÇA ORGANIZACIONAL

Define o produtoProduct Owner

PARTICIPAÇÃO NO PLANEJAMENTO

DEFINE A VISÃO DO PRODUTO

AUTORIDADE DO PRODUTO

DEFINE OS CRITÉRIOS DE ACEITAÇÃO

REFINAMENTO DO BACKLOG

COLABORA COM O DEV TEAM

Desenvolve o produtoDev Team

EXECUTA A SPRINT

RITMO SUSTENTÁVEL

COMUNICAÇÃO FREQUENTE

AUTO-ORGANIZADO

MULTI-FUNCIONAL

FOCADO E COMROMETIDO

Time Scrum - papéis e suas principais competências e responsabilidades

O Product Owner poderá ser um profissional da área de TI ou da área de negócio. O perfil desse profissional geralmente abrange ca-racterísticas como: conhecimento das regras e dos processos de ne-gócio, disponibilidade integral para se dedicar ao projeto de forma a construir o backlog do produto, fatiar, descartar e priorizar as fun-cionalidades e apoiar os demais membros do Time Scrum durante o projeto, conhecimento das práticas e técnicas ágeis, características in-terpessoais para resolver conflitos e conciliar visões e opiniões diver-sas. Na maioria das vezes, pode não ser fácil encontrar um profissional

com esse perfil, sendo necessário desen-volvê-lo ao longo do tempo por meio de treinamentos e de coaching contínuo.

Um papel importante, que não faz parte especificamente do Time Scrum, mas atua de forma estratégica no proje-to, é o parceiro do projeto ou stakehol-der. São pessoas e/ou organizações que podem ser afetadas pelo projeto direta ou indiretamente e têm influência sobre determinadas tomadas de decisão ao longo do processo.


O Escritório de Projetos de TI - NUPROJ, em seu papel de guar-dião do processo de desenvolvimento de sistemas, é responsável por apoiar os Times Scrum no uso da metodologia, na comunicação e in-teração com os parceiros do projeto, pelo coaching e facilitação do uso da metodologia pelos times de projeto da SUDES.

É também responsabilidade do NUPROJ promover a melhoria contínua e a adaptação da metodologia proposta a partir de avalia-ções periódicas, de feedbacks recebidos dos servidores envolvidos no processo (times Scrum e parceiros do projeto), da evolução de mo-delos e práticas de mercado, bem como do atendimento a normati-vos deste Tribunal e de órgãos de controle.

O PROCESSO

O Processo Ágil de Desenvolvimento de Software (PADS), apre-sentado na figura abaixo, é composto por ciclos de desenvolvimento iterativos e incrementais com duração de 2 semanas, chamados de Sprints.

A partir da indicação e autorização para a SUDES iniciar o proje-to, a primeira etapa do processo é o Planejamento Inicial que tem o objetivo de definir o time Scrum, identificar os parceiros do proje-to (usuários, gestores de negócio, patrocinadores, etc), promover o alinhamento, o entendimento do escopo e necessidades do projeto com todos os principais envolvidos, além das prerrogativas de execu-ção do projeto estabelecidas pela TI, como timebox e contrato de es-copo. A etapa de Planejamento Inicial é descrita com mais detalhes no Guia de Gerenciamento de Projetos da SETI.

Após a etapa de Planejamento Inicial, ocorre a etapa chamada de Sprint Zero, gerando como resultado os artefatos para construção da lista priorizada de funcionalidades (Product Backlog). Além disso, a Sprint Zero promove o alinhamento com relação a arquitetura, tec-nologias, soluções, práticas e definições de “tarefa preparada” e “tarefa pronta” a serem adotadas pelo time Scrum para o desenvolvimento do projeto nos ciclos de Sprint. Na sequência à Sprint Zero, inicia-se

Parceiros do projeto

• Alta administração• Grupo Gestor

• Usuários do sistema

Decisões estratégicasTime Scrum

• Scrum Master• Product Owner

• Dev Team

Decisões técnicas


o ciclo iterativo de execução dos Sprints. Vale destacar que os vários eventos previstos no ciclo de execu-

ção dos Sprints representam oportunidades que o Time Scrum possui para promover transparência, inspeção e adaptação do processo, artefatos e do produto de desenvolvimento de software em constru-ção com o objetivo de rodar o processo de desenvolvimento de forma eficiente e gerar o produto correto e com qualidade.

PROCESSO ÁGIL DE DESENVOLVIMENTO DE SOFTWARE (PADS)

O Sprint Backlog gerado na etapa de Planejamento da Sprint é baseado na premissa de entrega do próximo incremento de produto de maior valor priorizado no topo do Product Backlog. A definição de meta do Sprint proposta pelo Product Owner é discutida em conjunto com o Dev Team no Planejamento do Sprint. Nesta etapa destaca-se, ainda, que o time de desenvolvimento deve tentar balancear, sempre que possível, a distribuição de trabalho entre seus membros de forma a não sobrecarregar e onerar sempre apenas alguns desenvolvedores, considerando as premissas básicas do ágil: ”Pare de começar e come-ce a terminar!”.

Durante a Execução do Sprint, o Dev Team realiza rápidas

Reuniões Diárias para discutir e alinhar o andamento das tarefas. Durante este mesmo ciclo de desenvolvimento (Sprint), o Product Owner provoca Sessões de Refinamento, onde são discutidas, conjuntamente com o Dev Team, as tarefas do próximo Sprint, tornando mais eficiente o Planejamento seguinte.

Na Revisão do Sprint o feedback dos parceiros do projeto é co-letado, possibilitando a projeção do produto no ciclo seguinte. As-sim, a cada ciclo de desenvolvimento o Product Backlog é refinado, buscando o próximo maior valor a ser entregue.

No ciclo de desenvolvimento (Sprint) recomenda-se utilizar o re-curso de homologação assistida em que os usuários são convida-dos a operar o incremento do produto entregue no Sprint, tornando mais eficiente o processo de coleta de feedbacks. Essa atividade pode ser realizada antes ou depois da Revisão do Sprint, dependendo do acordo que for realizado entre o time Scrum e os usuários que farão a homologação assistida. Sugere-se que o evento de “homologação assistida” ocorra quando o incremento do produto for candidato a uma release.

Ao final de cada ciclo, todo o time Scrum se reúne na Retros-pectiva do Sprint, compartilhando a experiência, pontos positivos e dificuldades enfrentadas no Sprint visando a adaptação e melhoria


Processo Ágil de Desenvolvimento de Software – PADS

Legenda

PRÁTICASPRINCIPAIS

PRÁTICASCOMPLEMENTARES

EVENTOS

ARTEFATOS

Inspeção e adaptaçãoCronometrando as cerimôniasExperiência do usuárioPauta das cerimôniasHorário das cerimôniasProgramação em par

Planejamento Inicial

Execução do Sprint

Revisão do Sprint

Planejamento do Sprint

Sprint Zero

Distribuiçãode Trabalho

DistribuiiiiççççãããããããããããããããooooooooooooTrabalho

Definição

de Meta

o do Spri

Testes e IntegraçãoContínua

Definição de

Preparado e

de Pronto

Feedbackdos Parceiros

Feedbackdo Time

FFeedback

Homologação

Assistida

ProductBacklog

SprintBacklog

Cancelamentodo Sprint

Feedback dos Usuários

Feedbackkkkk dos Usuários

Divulgaçãodo Produto

ss

ãodutoRelease

do produto

Incrementodo Produto

TTTestes e Inte

Sessão de

Refinamento

TTTTTTTTTTTee

SSSSSeessão de

RefinamReun

ião Diár

ia

Execuçãã d Sprint

SeRe

E

5

Retrospectiva do SprintRetrospe ti do SpriinRR

7

CICLO DE DUASSEMANAS

SprintCICLO DE DUAS

SEMANAS

Início do Projeto

Planeje am to Inicial

Revisão d Sprint

HAssi

RR

6

ooo 1

PP

2

Planeje am to do Spri

ããããooooooooooooo

P

o

PP

4

Sprint Z

D

S

3

C ll

12


contínua do processo. O Scrum Master acompanha todo o processo, removendo impedimentos, mediando conflitos e propondo, se pos-sível, um plano de ações buscando corrigir as dificuldades e garantir que o time esteja aderente às boas práticas e ao processo.

O Incremento do Produto gerado no Sprint poderá represen-tar uma nova Release do Produto, quando ocorrer a sua publicação em produção. Essa ação deve ser coordenada pelo time Scrum com os stakeholders para que ocorra a devida divulgação do produto com as funcionalidades entregues em produção e, também, para que se avalie o feedback dos usuários referente a nova versão do produ-to disponibilizada. A partir da análise do feedback dos usuários pelo time Scrum poderá ocorrer o refinamento do Product Backlog com a priorização de novas necessidades de melhorias identificadas. Dessa forma, é realizada a melhoria contínua da qualidade do produto base-ada em feedbacks reais de usuários e o atendimento de expectativas dos usuários finais com relação ao produto entregue.


Eventos

ObjetivosDes

crição

Duração prevista Envolv

idos

01 02

0304

É o marco que de�ne o início de um projeto de desenvolvimen-to de software na SUDES.

Marco zero

Scrum

Comitê deGovernança

de T.I.

(ou outrodemandante)

SEPG SETI

Início doProjeto

Dar início ao desenvolvimento do projeto na SUDES, quando prioriza-do, autorizado e estabelecer o Time Scrum (Scrum Master, Product Owner, Dev Team) que atuará no projeto.

Detalhes destas tratativas para início do projeto estão contempladas no Guia de Gestão de Projetos.

14PADS


Eventos

ObjetivosDes

crição


idos

01 02

0304

É o marco que de�ne o início de um projeto de desenvolvimen-to de software na SUDES.

Marco zero

Scrum

Comitê deGovernança

de T.I.

(ou outrodemandante)

SEPG SETI

Início doProjeto

Dar início ao desenvolvimento do projeto na SUDES, quando prioriza-do, autorizado e estabelecer o Time Scrum (Scrum Master, Product Owner, Dev Team) que atuará no projeto.

Detalhes destas tratativas para início do projeto estão contempladas no Guia de Gestão de Projetos.

15PADS


SprintZero

ObjetivosDes

crição


idos

01 02

0304

Etapa de alinhamento interno do Time Scrum com relação ao projeto. Envolve as de�nições de arquitetura, soluções técnicas, ferramentas, adoção de práticas, preparação de ambientes e a elaboração do roadmap do pro-duto.

2 semanasUm Sprint

Scrum Escrever o backlog inicial do produto;

De�nir a arquitetura do projeto;

Escolher as práticas ágeis que serão utilizadas no projeto;

Planejar a priorização do 1º sprint;

Preparar os ambiente e as ferramentas;

Re�nar o Roadmap inicial do projeto;

Estabelecer acordo sobre de�nição de tarefa preparada e de tarefa pronta;

Time Scrum• Scrum Master

• Product Owner• Dev Team

Se necessário o PO pode atualizá-lo conforme sessões de re�namento realizadas durante a Sprint Zero.

Na Sprint Zero, o Time Scrum tem autonomia para escolher as ferra-mentas, as práticas e as soluções técnicas que serão utilizadas no desenvolvimento do produto. Esta autonomia foi sugerida também pelos servidores que participaram do Workshop de Design Thinking

Se houver necessidade de alguma integração com o PJe, acesse “Diretrizes para integração de Sistemas e Desenvolvimento de novos módulos no PJe”.

Eventos

Planejar os Critérios de Acessibilidade do Produto.

16PADS

http://pje.wiki.tjdft.jus.br/index.php/Diretrizes_para_integra%C3%A7%C3%A3o_de_sistemas_e_desenvolvimento_de_m%C3%B3dulos_no_PJE


Planejamentodo Sprint

ObjetivosDes

crição


idos

01 02

0304

Nesta etapa o Dev Team discute a meta proposta pelo Product Owner para o ciclo de desen-volvimento a ser iniciado. As tarefas incluídas nesta meta são aquelas que agregam maior valor ao produto. As tarefas mais

importantes estão sempre no topo do Product Backlog, que constantemente é re�nado. Nesta etapa o Dev Team tem a responsabilidade de realizar a estimativa de esforço para execução de cada tarefa. Ao �nal, este conjunto de tarefas estimadas resultam no Sprint Backlog, que é a meta proposta acordada entre o Product Owner e o Dev Team para o iminente ciclo de desenvolvimento.

1 a 2 horas

Scrum

Estimativa do esforço das tarefas;

Estabelecer metas de boas práticas que serão utilizadas pelo time durante o Sprint (opcional);

Realizar a distribuição do trabalho aos membros do Dev Team. De forma dinâmica, poderá ser revista pelo Dev Team durante o Sprint, de forma a buscar o cumpri-mento da meta do Sprint.

As tarefas que forem entrar no planejamento do Sprint devem observar a De�nição de preparado.

Discutir a meta do Sprint proposta pelo Product Owner, resultando no Sprint Backlog;



Eventos 17PADS


Execuçãodo Sprint

ObjetivosDes

crição


idos

01 02

03042 semanas

Scrum

Transformar a meta proposta do Sprint em incremento do produto potencialmente entregável.

Etapa de desenvolvimento das tarefas definidas no Backlog do Sprint para o cumprimento da meta do Sprint e a entrega do incremento do produto.Enquanto o Product Owner é responsável por definir e espe-cificar o problema ...



Eventos 18PADS


Execuçãodo Sprint

Des

crição

(continuação)

01 ... a ser resolvido em uma lista priorizada (Backlog Sprint), o Dev Team tem a autoridade pela solução técnica a ser aplicada, combinando a experiência e capacidade técnica dos seus membros. O Dev Team deve trabalhar de forma colaborativa na equipe para transfor-mar completamente a meta proposta em um incremento de software poten-cialmente entregável.O Dev Team pode requisitar a qualquer tempo o auxílio do Product Owner para o esclarecimento de regras de negócio, bem como, do Scrum Master para questões que impeçam a continuação do ciclo de desenvolvimento, sejam elas técnicas ou organizacionais.Entretanto, o Dev Team deve ter autonomia para resolver internamente na equipe as dificuldades e impedimentos técnicos e, caso necessário, deve solicitar auxílio ao Scrum Master quando se tratar de impedimentos fora do escopo de ação do Dev Team.Durante a execução do Sprint, é recomendável que o PO se reúna com o Dev Team e o Scrum Master para discutirem itens de backlog que são os desejos, ou seja, antes de ser realizado uma sessão de refinamento. O time sugere ao PO abordagens para solução de um problema. Essa prática gera convergência entre os membros do Scrum Team e permite uma participação mais ativa na definição de itens importantes que em breve serão desenvolvidos.

Eventos 19PADS


ObjetivosDes

crição


idos

01 02

030415 minutos

Scrum

Etapa diária de alinhamento interno do Dev Team sobre o andamento das atividades em execução no Sprint e oportuni-dade de tratar impedimentos.Comumente, durante o ciclo de desenvolvimento, questões téc-nicas ou impedimentos...

Discutir impedimentos e alinhamento das tarefas do Sprint atual, observando o seguinte roteiro:

O QUE EU FIZ ONTEM QUE AJUDOU O DEV TEAM A ATENDER A META DO SPRINT?

O QUE EU FAREI HOJE PARA AJUDAR O DEV TEAM A ATENDER A META DO SPRINT?

EU VEJO ALGUM OBSTÁCULO QUE IMPEÇA A MIM OU O DEV TEAM NO ATENDIMENTO DA META DO SPRINT?

No máximo (opcional)

ProductOwner

DevTeam

(opcional)

ScrumMaster

ão pr

(Execução do Sprint)

Reunião Diária

Eventos 20PADS


Des

crição

01 ... surgem a todo tempo. As reuniões diárias são o momento oportuno para discussão e alinhamento dos membros do Dev Tem quanto aos problemas identificados. São encontros rápidos, durando não mais que 15 minutos, onde os membros respondem as perguntas: o que eu fiz até agora? o que farei em seguida? existe algum impedimento? A critério do Dev Team, o Scrum Master e o Product Owner podem ser convida-dos. Importante salientar que o objetivo da reunião não inclui questionamen-to sobre regras de negócio, apenas a discussão sobre o progresso do desen-volvimento e seus possíveis impedimentos.Como boa prática, o Product Owner poderá participar da reunião diária como ouvinte. Constata-se que quando o Product Owner participa ativamente das cerimônias do Scrum, o engajamento e confiança aumentam e estimulam o chamado fator 3C (Cartão, Conversa, Confirmação).


Reunião Diária

Fator 3C está disponível neste site.

Eventos 21PADS

https://www.agilealliance.org/glossary/three-cs/#q=~(infinite~false~filters~(postType~(~'page~'post~'aa_book~'aa_event_session~'aa_experience_report~'aa_glossary~'aa_research_paper~'aa_video)~tags~(~'three*20cs))~searchTerm~'~sort~false~sortDirection~'asc~page~1)




ObjetivosDes

crição


idos

01 02

03041 a 2 horas

Scrum

Etapa de refinamento das tare-fas priorizadas no Backlog do Produto visando melhorar seu entendimento para o Dev Team e prepará-las para serem executa-das nos próximos ciclos de de-senvolvimento (Sprint)...

ProductOwner

DevTeam

ão pr


Sessão de Refinamento

Antecipar e discutir as próximas tarefas, resultando no refinamento do Product Backlog.

Eventos 22PADS


Des

crição

01 ... As Sessões de Refinamento são provocadas pelo Product Owner, periodica-mente, durante a Execução do Sprint. Entretanto, as tarefas discutidas referem-se ao próximo Sprint, uma vez que a meta do Sprint corrente não deve ser modificada. Este é o momento em que o Product Owner e Dev Team alinham as expectativas e refinam o entendimento sobre as tarefas a serem executadas. Deste modo, os próximos Planejamentos de Sprint são mais preci-sos e objetivos, já que há entendimento prévio sobre as tarefas do topo do Backlog do Produto. Não há periodicidade pré-definida para realização da Sessão de Refinamento, mas deve ocorrer, sempre que o possível para clarear melhor os requisitos e manter a cadência das entregas.


Sessão de Refinamento

Eventos 23PADS


ObjetivosDes

crição


idos

01 02

0304

Scrum

Coletar feedback e projetar conjun-tamente o direcionamento do produto.

Observar as tarefas que forem con-cluídas devem atender às de�nições de pronto.

Etapa de apresentação do resultado do Sprint para os usuários e envolvidos no projeto.Concluída a Execução do Sprint, este é o momento onde todos os envolvidos no projeto reúnem-se para discutir o resultado entregue...

Revisãodo Sprint

ProductOwner

ScrumMaster

DevTeam

Parceirosdo Projeto1 hora

No máximo

Eventos 24PADS


Des

crição

01 ... O Time Scrum, comumente um membro do Dev Team, apresenta o incre-mento do produto aos Parceiros do Projeto. Este é um dos momentos principais de coleta de feedback, mas a Revisão do Sprint não deve ter caráter de homologação. Em termos práticos, o Product Owner deve estimular a análise dos Parceiros do Projeto sob a perspectiva do direcionamento dado ao produto. Os Parceiros do Projeto podem ser convida-dos a utilizar o sistema durante a reunião. Com o objetivo de aprimorar o feedback, é uma boa prática solicitar a pre-sença de um representante de cada persona identificada no projeto na Revisão do Sprint.

Revisãodo Sprint

Eventos 25PADS


ObjetivosDes

crição


idos

01 02

0304

Scrum

Nesta dinâmica os parceiros do projeto são convidados a par-ticipar, de forma ativa, dos testes no Incremento de Produto antes ou depois da Revisão de Sprint. Essa de�nição do momento cabe ao time Scrum durante...

Coletar feedback dos parceiros do projeto quanto ao uso do Incre-mento do Produto antes de publicá-lo em produção.

(Revisão do Sprint)

HomologaçãoAssistida

Parceirosdo Projeto



2 horasNo máximo

Eventos

Observar as tarefas que forem con-cluídas devem atender às de�nições de pronto.

26PADS


Des

crição

01 ... o planejamento do sprint, visto que a homologação assistida ocorre dentro do ciclo de desenvolvimento. O processo de homologação assistida, embora opcional, é recomendado principalmente quando há uma nova versão do produto, pois possibilita acordar com as partes interessadas a implantação do produto em produção.Esta dinâmica requer tempo de preparação, convocação das partes interessa-das e execução. Portanto, caso haja poucos cartões a serem homologados, sugere-se postergar ou avaliar o custo versus benefício de realizar o evento. A etapa de preparação consiste na criação de massa de dados para os testes, validação do ambiente de homologação pelo Dev Team, com o objetivo de garantir a estabilidade do sistema. Essa etapa exige, ainda, a reserva de local físico com computadores à disposição e criação de roteiro com os itens a serem homologados.Salienta-se que a preparação da Homologação Assistida resulta em ambiente de sistema estável, testado pelo time Scrum e aberto a feedbacks dos par-ceiros do projeto. Outro benefício relevante do processo de homologação assistida é a identificação e alinhamento de pequenos ajustes que possibilitam a tempestiva solução, já que o Dev Team participa do evento.


HomologaçãoAssistida

Eventos 27PADS


ObjetivosDes

crição


idos

01 02

0304

Scrum

Compartilhar experiências e dificuldades, visando adaptação e melhoria do processo.

Este evento é interno ao Time Scrum e ocorre quando se encer-ram todas as etapas de um ciclo de desenvolvimento (Sprint).Na Retrospectiva do Sprint são compartilhadas as experiên-cias e dificuldades encontradas ao longo...

1 a 2 horas

ão pr

Retrospectivado Sprint



Eventos 28PADS


Des

crição

01 ... do Sprint (lições aprendidas). O Time Scrum debate possíveis alternativas para melhoria contínua do processo. É o papel do Scrum Master procurar meios para resolução dos impedimentos encontrados, sejam eles questões técnicas ou organizacionais, que estão afetando direta ou indireta-mente o time. A qualquer tempo, o Scrum Master pode requisitar o auxílio do Escritório de Projetos da TI para resolução de determinados impedimentos e dificuldades, especialmente aqueles que envolvem níveis tático e estratégico. É neste momento que se incentiva o feedback do time em relação à metodologia, o processo e o produto. Os relatos podem ser feitos de diversas formas, por meio de técnicas aplicadas pelo Scrum Master ou por meio de debates dos problemas e ideias que foram percebidas pelo time Scrum.O propósito de realizar uma sessão de feedback é proporcionar melhoria con-tínua no processo, melhorar o engajamento do time e entregar produtos de maior valor conforme aumenta a maturidade do time.

Retrospectivado Sprint

Eventos 29PADS


ObjetivosDes

crição


idos

01 02

0304

Este evento pode ocorrer a qualquer momento du-rante a execução do Sprint e por decisão do Product Owner.Em função de imprevistos, mudanças relevantes nas tarefas do Sprint ou eventos externos ao time que alteram a meta do Sprint corrente, o Product Owner ao analisar esse contexto pode decidir pelo cancelamento do Sprint. Essa decisão deve ser compartilhada com o Dev Team e Scrum Master, destacando os fatores que influenciaram a decisão de cancelamento. O Time Scrum deverá, nessa reunião, decidir quais serão os próximos eventos, no caso, o Planejamento do Sprint ou ações necessárias para a continuidade do projeto. Essa decisão é tomada exclusivamente pelo Product Owner.

ão p

Cancelamentodo Sprint

Avaliar a interrupção da execu-ção do Sprint e informar ao Dev Team e ao Scrum Master sobre os motivos que levaram ao Cancela-mento do Sprint.

15 minutosNo máximo

ProductOwner

Eventos 30PADS


Artefatos

Objeto

Responsáve

is

02

03

Desc

riçã

o

01O Product Backlog contém as necessi-dades, funcionalidades e principais requisitos do produto. O Product Owner é o único responsável pela manutenção, refinamento e prioriza-ção do Product Backlog. O Product Owner tem autoridade sobre o produto.Existem situações específicas como débitos técnicos ou identificação de erros (hotfixes) em produção que o próprio time deve observar em suas atividades diárias. Assim, os mesmos podem incluir novos cartões no Product Backlog que, pos-teriormente, serão priorizados pelo Product Owner conforme acordo com o Dev Team no Planejamento do próximo Sprint.

Scrum

ProductBacklog

(principal)

ProductOwner

(opcional)

DevTeam

Lista das funcionalidades previs-tas para o sistema, priorizada e refinada constantemente.

31PADS


Artefatos

Objeto

Responsáve

is

02

03

Desc

riçã

o

01Este é o conjunto de tarefas para meta proposta do Sprint. A meta apresentada pelo Product Owner é discutida pelo Dev Team. Durante o Planejamento do Sprint, a meta proposta pode ser modificada ou re-priorizada de acordo com a experiência e capacidade de produção do Dev Team. Entretanto, uma vez iniciado o Sprint a meta não deve ser modificada.Neste momento, questões como débito técnico e/ou erros identificados em produção pendentes devem ser avaliados pelo Product Owner. A decisão de quais itens do Product Backlog serão priorizados para o próximo ciclo é atividade conjunta do Dev Team com o Product Owner, considerando as necessidades de negócio, capacidade do time, além dos itens de ordem técnica (débito técnico) ou estabilidade do sistema (erros em produção). Lembrando que não existe hierarquia dentro dos times, e havendo discordância entre os itens escolhidos para o Sprint Backlog, o Scrum Master poderá intervir e verificar quais são os pontos de discordância, conduzindo o pro-cesso até que se encontre consenso.

Scrum

ProductOwner

DevTeam

Lista de tarefas para a meta proposta do Sprint.

SprintBacklog

32PADS


Artefatos

Objeto

Responsáve

is

02

03

Desc

riçã

o

01Ao final do Sprint é gerado um incremento de produto com-posto pelos itens de software que atenderam aos requisitos da definição de pronto. É decisão do Product Owner, em comum acordo com os stakeholders, a liberação deste incremento de produto como uma release a ser publicada em produção.

Scrum

ProductOwner

DevTeam

Código-fonte ou qualquer parte de solução de software utilizável. Deve corresponder a itens do Sprint Backlog que foram entregues em conformidade com os critérios da definição de pronto.


33PADS


Artefatos

Objeto

Responsáve

is

02

03

Desc

riçã

o

01Um ou vários incrementos de produtos aprovados que serão publicados em produção pelo Dev Team após anuência do Product Owner e a homologação dos usuários do produto.

Scrum

ProductOwner

DevTeam

Incremento(s) de produto que foi(ram) aprovado(s) pelo Product Owner.

Releasedo produto

34PADS


Práticas Principais

Objeto

Responsáve

is

02

03

Desc

riçã

o

01É um acordo, válido ao longo do projeto, em que o time determi-na as condições mínimas para se iniciar (de�nição de prepa-rado) ou concluir (de�nição de pronto) uma determinada tarefa. Tais de�nições devem contemplar requisitos básicos de aderência ao processo, incluindo, por exemplo, padro-nização na escrita e testes auto-matizados. Para ser considerada preparada, por exemplo, uma tarefa deve estar re�nada, com regras bem de�nidas e estar formatada com seus respectivos critérios de aceitação antes que possa ser incluída...

Scrum

Acordo válido entre o Time Scrum sobre os critérios mínimos de qualidade para que uma tarefa do Backlog possa ser desenvolvida (de�-nição de preparada) e, no Sprint, e seja entre-gue como incremento do produto (de�nição de pronto).

Considerar os Critérios de Acessibilidade ao iniciar e concluir uma tarefa.

ProductOwner

ScrumMaster

DevTeam

(Sprint Zero)

De�nição de Preparado e de Pronto

35PADS



Desc

riçã

o

01 ... incluída no Planejamento do Sprint. Para ser considerada pronta, por exemplo, a tarefa deve passar por testes automatizados, bem como por testes cruzados (testes por membro do time que não participou da tarefa) antes de ir para o ambiente de homologação. Estas são boas práticas que garantem que as tarefas sigam um padrão mínimo de qualidade ao longo de todo processo. A Figura a seguir apresenta os pontos de impacto das defini-ções de preparado e pronto das tarefas durante o ciclo de desenvolvimento (Sprint).

Pontos de impacto das definições de preparado e pronto

CICLO DE DUASSEMANAS

SprintCICLO DE DUAS

SEMANAS

Sprint

Definição de prontoDefinição de preparado

ProductBacklog

SprintBacklog


(Sprint Zero)

Definição de Preparado e de Pronto

36PADS


Objeto

Responsáve

is

02

03

Desc

riçã

o

01A meta do Sprint representa o principal objetivo que será satisfeito dentro do Sprint através da implementação do Backlog do Produto, e que for-nece a orientação para o Dev Team sobre o porquê dele estar construindo o incremento.É possível que um Sprint tenha mais de um objetivo sendo o Product Owner o responsável por trazer a proposta para avaliação do Time Scrum.

Scrum

(Planejamento do Sprint)




Definiçãode Meta

Os itens do topo do Backlog do Produto, ao serem agrupa-dos, definem a meta do Sprint.

37PADS


Objeto

Responsáve

is

02

03

Desc

riçã

o

01No planejamento do Sprint deve ser tratada a distribuição das tarefas aos participantes do Dev Team de forma a balancear a carga de trabalho e seu en-volvimento na execução e no alcance da meta do Sprint. De forma dinâmica e nas reuniões diárias do Time Scrum, a distri-buição do trabalho poderá ser revista para corrigir desvios e suprir as necessidades e deman-das do Dev Team de forma a buscar o cumprimento da meta do Sprint.

Scrum

(Planejamento do Sprint)


Distribuiçãode Trabalho

Backlog do Sprint e balancea-mento da carga de trabalho para os membros do Dev Team na exe-cução dos itens do Backlog do Sprint.

ScrumMaster

DevTeam

38PADS


Objeto

Responsáve

is

02

03

Desc

riçã

o

01Teste é uma prática fundamental para que o Incremento do Produto atenda aos critérios de qualidade estabelecidos. Cabe ao Dev Team definir a melhor estratégia para planejamento e execução dos testes, incluindo as técnicas, os níveis, os tipos e a cobertura dos testes a ser atingida.A integração contínua é uma prática de desenvolvimento de software de DevOps em que os desenvolvedores, com frequência, reúnem suas alterações de código em um repositório central. Depois disso, builds e testes são executados. Os principais objetivos da integração contínua são encontrar e investigar bugs mais rapidamente, melhorar a qualidade do software e reduzir o tempo que leva para validar e lançar novas atualizações. Neste modelo, testes automatizados são obrigatórios e garantem a integridade do processo. As atividades de Entrega/Deploy Contínuo complementam o fluxo, automatizando o pro-cesso de ponta a ponta.

Scrum

DevTeam

Testes em diversos níveis: unitário, integração e aceitação. Uma esteira automatizada de Inte-gração Contínua, compreendendo atividades de builds, testes automati-zados e deploys.


Testes e Integração Contínua

Prática de engenharia de

software que possibilita

unificar o desen-volvimento de

software (Dev) e a operação de

software (Ops).

Processo de construção do

código executá-vel do sistema.

Práticas Principais 39PADS


Objeto

Responsáve

is

02

03

Desc

riçã

o

01Durante a realização da cerimô-nia de Revisão do Sprint são co-letados diversos feedbacks positivos e negativos quanto ao Incremento de Produto que foi entregue pelo Dev Team. Essas opiniões serão utilizadas para aprimoramento do produto. Recomenda-se obter feedbacks de usuários reais do produto, não somente de ges-tores ou grupos gestores.

Scrum

Incremento do produto.


Feedbackdos Parceiros

Stakeholders• Usuários

• Grupo Gestor• Patrocinadores

• Interessados





Objeto

Responsáve

is

02

03

Desc

riçã

o

01Normalmente ocorre na Retrospecti-va do Sprint, momento em que os membros do time são encorajados, especialmente pelo Scrum Master, a dar feedbacks em relação à meto-dologia, o processo e o produto, objetivando o amadurecimento e o maior engajamento do time na exe-cução do projeto.Os relatos podem ser feitos de diver-sas formas, por meio de técnicas aplicadas pelo Scrum Master ou por meio de debates dos problemas e ideias que foram percebidas pelo time Scrum.O propósito de realizar uma sessão de feedback é proporcionar melho-ria contínua no processo e entregar produtos de maior valor conforme aumenta a maturidade do time.

Scrum

Maturidade do Time Scrum.



(Retrospectiva do Sprint)

Feedbackdo Time



Objeto

Responsáve

is

02

03

Desc

riçã

o

01Embora opcional, a divulgação dos itens de software que compõe o Incremento de Produto pode ser realizado em parceria com os stakeholders do projeto ou apenas pelo Time Scrum, mas alinhado com as partes interessadas. O intuito é destacar o valor entregue em pro-dução, bem como benefícios no dia a dia do trabalho dos usuários finais do sistema. Sugere-se incluir essa atividade no planejamento do sprint, pois deman-da algum esforço do time. Um bom trabalho de divulgação, além de valorizar o trabalho do time Scrum gera transparência tanto para o time, quanto para os usuários, gestores e alta administração do TJDFT.

Scrum



• Interessados



(Release do Produto)

Divulgaçãodo Produto

Divulgação em canal próprio do Tribunal sobre Incremento de Produto que será disponibilizado aos usuários, destacando as vantagens e facilidades das funcio-nalidades entregues ou correções de erros que geraram estabilizações impor-tantes.



Objeto

Responsáve

is

02

03

Desc

riçã

o

01Possibilitar feedbacks dos usuários finais do produto de software (aqueles que utilizam o sistema diariamente), seja em implantação piloto, ou implanta-ção em massa. Essas impressões, sugestões ou reclamações podem ser coletadas em formu-lários on-line, pesquisas de satis-fação e, preferencialmente, por meio de reuniões presenciais, para posterior análise do Time Scrum.

Scrum



• Interessados

Usuários

(Release do Produto)

Feedbackdos Usuários

Percepções dos usuários finais sobre o Incremento de Produto, observando pontos positivos e/ou negativos.



Práticas Complementares

Frequentemente, deve-se inspecionar os artefatos Scrum e o progresso do projeto em direção ao objetivo da Sprint para detectar variações indesejadas e que poderão resultar em produto de baixa qualidade ou que não respeitam critérios estabeleci-dos, por exemplo, na Definição de Pronto. Nesse caso, essas variações deverão ser ajustadas o mais breve possível (adaptação) para minimizar mais desvios no processo, no produto (backlog) ou nos artefatos que estão sendo produzidos. A inspeção não deve, no entanto, ser tão frequente que atrapalhe a própria execução das tarefas. As inspeções são mais benéficas quando realizadas de forma diligente por inspetores especializados no trabalho a se verificar.

Scrum = Inspeção + Adaptação

O time estabelece o horário das cerimônias no Sprint Zero e segue como rotina no mesmo horário para os demais Sprints, favorecendo a preparação e criação do hábito quanto ao cumprimento dos horários estabelecidos. O horário poderá ser revisto nas retrospectivas de sprint.

Horário das cerimôniasPrática comumente usada no desenvolvimento ágil, sugere que duas pessoas usem a mesma máquina, revezando-se no teclado. Esta prática facilita a disseminação de conheci-mento, seja técnico, seja de negócio entre os membros do time, promovendo melhor integração e comunicação por meio de troca constante de informações.

Programação em par

É boa prática informar a pauta das cerimônias aos partici-pantes com antecedência para que possam estar cientes e se preparar para o evento. Tal prática demonstra preocupa-ção com o tempo dos participantes e objetividade nas discussões, dispensando introduções e repasses alongados durante os eventos.

Pauta das cerimôniasA experiência do usuário (User Experience - UX) está relacionada à satisfação do usuário com a acessibilidade, usabilidade e eficiência ao navegar pelo sistema. Existem diversas formas de coletar esses dados dos usuários e aplicar o feedback no desenvolvimento dos incremen-tos de produto seguintes. Quanto mais o sistema se aproxima do uso real do usuário, maior o valor percebido, maior a eficiência e eficácia do produto.

Experiência do usuário

Para cada evento Scrum, a literatura de referência sugere o tempo máximo de execução. Assim, recomenda-se a utiliza-ção de cronômetros para que as cerimônias sejam mais objetivas, eficientes, evitando desperdício de tempo de seus participantes.

Cronometrando as cerimônias

Guia do Scrum. https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Portuguese-Brazilian.pdf

Práticas sugeridas pelos participantes do evento de Design Thinking.

Podem ser aplicadas em um ou mais eventos do processo ágil de desenvolvimento de software. 44

PADS


Comunicação

A comunicação1 é instrumento essencial para garantir a transparência e o engajamento de todos os envolvidos em “Papéis”, “Eventos” e “Ar-tefatos” do processo ágil de desenvolvimento de sistemas.

De acordo com o Scrum Guide, aspectos significativos do proces-so de desenvolvimento devem estar visíveis aos responsáveis pelos resultados, ou seja, a todas as partes interessadas, incluindo o Time. A transparência requer que estes aspectos tenham uma definição pa-drão comum para que os observadores compartilhem um mesmo en-tendimento comum do que está sendo visto, evitando distorções de compreensão. Comunicação falha acarreta desperdício. Dentre as boas práticas recomendadas para alinhamento está o Lean Inception proposto por Paulo Caroli, além das cerimônias do Scrum, quadro e cerimônia do Lean Kanban, práticas já experimentadas na SUDES. Outra ferramenta essencial para a boa comunicação são os feed-backs relacionados no item de práticas deste documento.

1 Outra prática muito recomendada durante o evento de Design Thinking para pensar a metodologia foi a comunicação.

Comunicação é um instrumento essencial


Segurança da Informação (SI)

Segundo a norma ABNT NBR ISO/IEC 27001:2013, Segurança da Infor-mação é a proteção das informações contra as ameaças, para assegu-rar a continuidade dos negócios, minimizar prejuízos e maximizar o retorno de investimentos e oportunidades.

A Segurança da Informação deve estar presente em todo o pro-cesso de desenvolvimento de software, com o objetivo de se construir sistemas de informação protegidos contra:

• ataques no login;• negação de serviço a usuários autorizados;• intrusão;• acesso, modificação e utilização não autorizada de dados ou in-

formações.Desde a concepção do projeto até a implantação em produção,

a SI é um aspecto importante que deve ser considerado pelo time Scrum com objetivo de minimizar as ameaças, vulnerabilidades, ata-ques e impactos decorrentes de incidentes.

A Política de Segurança da Informação define diretrizes, normas, procedimentos, ferramentas e responsabilidades dos colaboradores que lidam com as informações, com o objetivo de disciplinar o com-portamento e a postura da organização perante os riscos de seguran-ça e os objetivos de negócio.

À medida que as aplicações tornam-se cada vez mais críticas, complexas e interligadas a processos de negócios, torna-se impera-tivo o seu desenvolvimento de forma segura, com vistas a minimizar riscos que possam comprometer a integridade e imagem do TJDFT. O guia OWASP1 (Open Web Application Security Project ou Projeto Aberto de Segurança em Aplicações Web), mundialmente conhecido como forma de conscientizar programadores para o desenvolvimento segu-ro, tornou-se um padrão a ser seguido na área de segurança de aplica-ções. Nosso processo deverá seguir, pelo menos, a mitigação dos dez riscos mais críticos encontrados nas aplicações Web2.

O TJDFT e o CNJ estabelecem algumas diretrizes, recomendações e políticas de segurança, classificação e acesso da informação que de-vem ser conhecidas e aplicadas por todos os colaboradores do Tribu-nal, vide Recomendações Legais. A exemplo da Resolução nº 21, de 8/11/2016, interna do TJDFT que dispõe sobre o Sistema de Gestão de Segurança da Informação (SGSI) e a Política Corporativa de Segu-rança da Informação (PCSI) com o objetivo de estabelecer, implemen-tar, manter e melhorar, continuamente, mecanismos e controles para promover a gestão da segurança da informação no nosso Tribunal.

1 https://www.owasp.org/index.php/Main_Page2 https://www.owasp.org/images/0/06/OWASP_Top_10-2017-pt_pt.pdf

https://www.owasp.org/index.php/Main_Page

https://www.owasp.org/images/0/06/OWASP_Top_10-2017-pt_pt.pdf


Critérios de Acessibilidade

Os critérios de acessibilidade tratam de um tema com bastante re-levância no contexto de sistemas de informação e produtos digitais porque é a partir dele que será promovido o acesso à informação, in-dependentemente de qual seja o usuário ou de suas deficiências ou habilidades. Estamos falando do direito de todos à informação e que esses produtos digitais produzidos pela TI sejam acessíveis à toda po-pulação.

É a partir dessa ótica que o Processo Ágil de Desenvolvimento de Software traz à tona observações e boas práticas a serem seguidas de forma sistemática nos 3 pontos a seguir:

1. SEGUIR OS PADRÕES WEB

Para se criar um ambiente online efetivamente acessível é necessário, primeiramente, que o código esteja dentro dos padrões Web inter-nacionais definidos pelo W3C. Para conhecer as boas práticas em de-senvolvimento de sítios de acordo com os padrões veja a página do Escritório Brasileiro do W3C que provê a Cartilha de Acessibilidade na WEB.

O Governo Federal também oferece em seu portal gov.br uma seção inteira sobre o tema Acessibilidade Digital. Nessa área é pos-sível conhecer em detalhes o modelo de acessibilidade, ferramentas,

padrões web em governo eletrônico, referências e modelos de imple-mentação, material de apoio e recursos de acessibilidade. Nesse con-texto, destaca-se o conteúdo de Padrões Web em Governo Eletrôni-co com cartilhas (codificação, usabilidade, redação web e desenho e arquitetura de conteúdo) e guia de administração.

2. SEGUIR AS DIRETRIZES E RECOMENDAÇÕES DE ACESSIBILIDADE

Atualmente, a legislação brasileira conta com diversas diretrizes que envolvem tal tema, dentre elas destacam-se:

• Lei Nº 13.146/2015 que Institui a Lei Brasileira de Inclusão da Pessoa com Deficiência (Estatuto da Pessoa com Deficiência);

• Resolução CNJ 370/2021 sobre a “Estratégia Nacional de Tec-nologia da Informação e Comunicação do Poder Judiciário (EN-TIC-JUD)”, estabelecendo em seu art. 33, parágrafo único, item V - Modelo de Acessibilidade em Governo Eletrônico - eMAG;

• Resolução CNJ 401/2021 que traz o desenvolvimento de dire-trizes de acessibilidade e inclusão de pessoas com deficiência nos órgãos do Poder Judiciário e de seus serviços auxiliares, e regulamenta o funcionamento de unidades de acessibilidade e inclusão.

https://www.w3c.br/Materiais/PublicacoesW3C

https://www.w3c.br/Materiais/PublicacoesW3C

https://www.gov.br/governodigital/pt-br/acessibilidade-digital

https://www.gov.br/governodigital/pt-br/acessibilidade-digital/padroes-web-em-governo-eletronico

https://www.gov.br/governodigital/pt-br/acessibilidade-digital/padroes-web-em-governo-eletronico

http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2015/lei/l13146.htm

https://atos.cnj.jus.br/atos/detalhar/3706

http://emag.governoeletronico.gov.br/



3. REALIZAR A AVALIAÇÃO DE ACESSIBILIDADE

Orienta-se que toda e qualquer ação de planejamento de um novo sistema, ou de evolução, contemple o tema acessibilidade e inclua estudo, planejamento, execução, testes e homologação nos eventos identificados no fluxo do PADS.

Para realizar uma validação efetiva da acessibilidade do software, é indispensável o teste com usuários e/ou futuros usuários do siste-ma que possuam necessidades especiais ou dificuldades técnicas. De tal forma, quanto maior e mais diversificado o número desses usuá-rios participando da avaliação de acessibilidade, mais eficaz e robusto será o resultado. Com foco para se atingir esse objetivo de validação do software da melhor forma possível, orienta-se que tais validações e/ou verificações sejam realizadas dentro dos eventos integrantes do PADS, intitulados “Revisão do Sprint” e “Homologação Assistida”.

EVENTOS DO PADS

Planejamento InicialLevantar os Critérios de Acessibilidade do produto

Nessa fase do fluxo do PADS é quando o sistema de informação ainda não existe, e portanto, deve-se pensar em levantar quais critérios são

necessários para prover acessibilidade no novo sistema de informa-ção a ser disponibilizado aos usuários considerando os requisitos fun-cionais iniciais conhecidos. Esse levantamento não precisa ser uma lista muito extensa, entretanto, que seja possível mitigar quais neces-sidades o novo sistema deverá prover aos usuários na versão inicial do produto.

No Planejamento Inicial é importante lembrar de alinhar o pro-duto a ser desenvolvido quanto à conformidade com a legislação sobre acessibilidade, principalmente com relação a Resolução CNJ 370/2021 (ENTIC-JUD).

Os critérios de acessibilidade farão parte do backlog do produto e serão refinados a cada ciclo de execução (sprint). Assim, a equipe de projeto irá se planejar para atender a esses requisitos do sistema como parte integrante do produto.

Sprint Zero Planejar os Critérios de Acessibilidade do produto

Durante a execução do Sprint Zero é possível planejar com um pouco mais de clareza quais Critérios de Acessibilidade serão considerados como prioritários na criação das primeiras versões do produto e que




irão influenciar na escolha de infraestrutura necessária ou arquitetura inicial desenhada para o novo sistema.

O importante nessa fase é ter acesso aos critérios de acessibilida-de que foram levantados na etapa anterior e começar o trabalho de planejamento para atendê-los em um momento breve nos próximos Sprints que virão. O produto já nasce conhecendo qual meta de aces-sibilidade pretende atender.

Destaca-se que o uso de padrões web deve ser levado em consi-deração, principalmente, na fase de Sprint Zero do projeto onde são definidas a arquitetura da aplicação, boas práticas adotadas e ferra-mentas usadas. Porém, precisam ser constantemente relembrados a cada ciclo do processo de desenvolvimento para poder entregar um software com acessibilidade.

Os critérios de acessibilidade podem, ainda, ser condições a se-rem atendidas na seção do PADS que fala sobre “Definição de Prepa-rado e Pronto”. É nessa prática principal que serão estabelecidas as condições para que uma tarefa esteja disponível para entrar em um Planejamento de Sprint (Definição de Preparado) e as condições para que uma tarefa seja considerada concluída (Definição de Pronto). Cri-térios de Acessibilidade podem compor o checklist das definições de Preparado e Pronto.


Recomendações LegaisSalienta-se que na construção de quaisquer soluções de software devem ser observadas as recomendações legais a seguir:

Lei nº 11.419/2006 de 19/12/2006

Informatização do Processo judicial.(Lei n° 11.419/2006)

Lei nº 12.527/2011 de 18/11/2011

Lei de Acesso à Informação (Lei nº 12.527/2011)

Lei nº 13.709/2018 de 14/08/2018.

Dispõe sobre a proteção de dados pessoais e altera a Lei nº 12.965, de 23 de abril de 2014 (Marco Civil da Internet).http://www.planalto.gov.br/ccivil_03/_Ato2015-2018/2018/Lei/L13709.htm

Portaria Conjunta nº 03/2013 de 17/01/2013

Regulamenta a utilização dos recursos de Tecnologia da Informação e Comunicação - TIC no Tribunal de Justiça do Distrito Federal e dos Territórios - TJDFT.https://www.tjdft.jus.br/publicacoes/publicacoes--oficiais/portarias-conjuntas-gpr-e-cg/2013/portaria--conjunta-3-de-17-01-2013


Utilização da Chancela Eletrônica por meio da utiliza-ção da Certificação Digital.https://www.tjdft.jus.br/publicacoes/publicacoes-ofi-ciais/portarias-conjuntas-gpr-e-cg/2007/00024.html


Regulamenta a criação, o desenvolvimento, a manu-tenção e a atualização de conteúdos do Tribunal de Jusitça do Distrito Federal e dos Territórios - TJDFT na internet e na intranet.https://www.tjdft.jus.br/publicacoes/publicacoes--oficiais/portarias-conjuntas-gpr-e-cg/2013/portaria--conjunta-30-de-06-05-2013


Política de Dados Abertos do TJDFT. (http://www.tjdft.jus.br/publicacoes/publicacoes-oficiais/porta-rias-conjuntas-gpr-e-cg/2018/portaria-conjunta-32--de-17-04-2018).


Dispõe sobre o Processo Judicial Eletrônico no âmbi-to dos Juizados Especiais.https://www.tjdft.jus.br/publicacoes/publicacoes-ofi-ciais/portarias-conjuntas-gpr-e-cg/2007/00049.html


Plano de classificação de documentos http://www.tjdft.jus.br/publicacoes/publicacoes-oficiais/portarias-conjuntas-gpr-e-cg/2016/portaria-conjunta-72-de-02-09-2016


Regulamenta o acesso à informação no âmbito do TJDFT http://www.tjdft.jus.br/publicacoes/publicacoes-oficiais/portarias-conjuntas-gpr-e-cg/2016/portaria-conjunta-102-de-10-11-2016

http://www.planalto.gov.br/ccivil_03/_Ato2004-2006/2006/Lei/L11419.htm





https://www.tjdft.jus.br/publicacoes/publicacoes-oficiais/portarias-conjuntas-gpr-e-cg/2013/portaria-conjunta-3-de-17-01-2013



https://www.tjdft.jus.br/publicacoes/publicacoes-oficiais/portarias-conjuntas-gpr-e-cg/2007/00024.html





http://www.tjdft.jus.br/publicacoes/publicacoes-oficiais/portarias-conjuntas-gpr-e-cg/2018/portaria-conjunta-32-de-17-04-2018











Política de backup e restauração de arquivos http://www.tjdft.jus.br/publicacoes/publicacoes-oficiais/portarias-conjuntas-gpr-e-cg/2016/portaria-conjunta-105-de-17-11-2016

Portaria GPR nº 1982/2016 de 09/11/2016

Institui o Comitê Gestor de Segurança da Informação http://www.tjdft.jus.br/publicacoes/publicacoes-oficiais/portarias-gpr/2016/portaria-gpr-1982-de-09-11-2016

Portaria GPR nº 2183/2015 de 01/12/2015

Regulamenta o provimento e a gestão de soluções de Tecnologia da Informação e Comunicação – TIC no Tribunal de Justiça do Distrito Federal e dos Territó-rios – TJDFT. https://www.tjdft.jus.br/publicacoes/publicacoes--oficiais/portarias-gpr/2015/portaria-gpr-2183--de-01-12-2015

Resolução GPR nº 16/2016 de 25/08/2016

Política de gestão documental para os processos judiciaishttp://www.tjdft.jus.br/publicacoes/publicacoes-oficiais/resolucoes-do-pleno/2016/resolucao-16-de-25-08-2016

Resolução GPR nº 21/2016 de 08/11/2016

Sistema de Gestão de Segurança da Informação - SGSI e a Política Corporativa de Segurança da Informação – PCSI http://www.tjdft.jus.br/publicacoes/publicacoes-oficiais/resolucoes-do-pleno/2016/resolucao-21-de-08-11-2016

Resolução GPR nº 16 de 13/12/2017

Regulamenta o Portfólio de Projetos Estratégicos do Tribunal de Justiça do Distrito Federal e dos Territó-rios.

Resolução CNJ nº 90/2009 de 29/09/2009

Dispõe sobre os requisitos de nivelamento de tecno-logia da informação no âmbito do Poder Judiciário.https://www.conjur.com.br/dl/resolucao-90.pdf


Institui o Modelo de Requisitos para Sistemas Infor-matizados de Gestão de Processos e Documentos do Poder Judiciário e disciplina a obrigatoriedade da sua utilização no desenvolvimento e manutenção de sis-temas informatizados para as atividades judiciárias e administrativas no âmbito do Poder Judiciário. http://www.cnj.jus.br/images/atos_normativos/reso-lucao/resolucao_91_29092009_10102012201030.pdf


Dispõe sobre a divulgação de dados processuais ele-trônicos na rede mundial de computadores, expedi-ção de certidões judiciais e dá outras providências.http://www.cnj.jus.br/images/resolucoes/Resolucao_n_121-GP.pdf


Dispõe sobre diretrizes para as contratações de So-lução de Tecnologia da Informação e Comunicação pelos órgãos submetidos ao controle administrativo e financeiro do Conselho Nacional de Justiça (CNJ).http://www.cnj.jus.br/images/atos_normativos/reso-lucao/resolucao_182_17102013_18102013175226.pdf

https://www.tjdft.jus.br/publicacoes/publicacoes-oficiais/portarias-gpr/2015/portaria-gpr-2183-de-01-12-2015



https://www.conjur.com.br/dl/resolucao-90.pdf

http://www.cnj.jus.br/images/resolucoes/Resolucao_n_121-GP.pdf

http://www.cnj.jus.br/images/resolucoes/Resolucao_n_121-GP.pdf

http://www.cnj.jus.br/images/atos_normativos/resolucao/resolucao_182_17102013_18102013175226.pdf





Institui o Sistema Processo Judicial Eletrônico - PJe como sistema de processamento de informações e prática de atos processuais e estabelece os parâme-tros para sua implementação e funcionamento.http://www.cnj.jus.br/busca-atos--adm?documento=2492


Dispõe sobre a Política Nacional de Formação e Aper-feiçoamento dos Servidores do Poder Judiciário.http://www.cnj.jus.br/busca-atos--adm?documento=2485


Institui Política Nacional de Atenção Prioritária ao Pri-meiro Grau de Jurisdição e dá outras providências.http://www.cnj.jus.br/busca-atos--adm?documento=2483


Dispõe sobre o Planejamento e a Gestão Estratégica no âmbito do Poder Judiciário e dá outras providên-cias.http://www.cnj.jus.br/busca-atos--adm?documento=2733


Institui a Estratégia Nacional de Tecnologia da Infor-mação e Comunicação do Poder Judiciário (ENTIC--JUD).Art. 12, III - macroprocesso de software, c) de proces-sos de desenvolvimento e sustentação.http://www.cnj.jus.br/atos--normativos?documento=2227


Dispõe sobre a aplicação da Lei de Acesso à Informação no âmbito do Poder Judiciáriohttp://www.cnj.jus.br/busca-atos-adm?documento=3062


Versa sobre acessibilidade ou “tecnologia as-sistiva”. (http://www.cnj.jus.br/busca-atos--adm?documento=3141).

Acórdão TCU 1200/2014-P Diagnóstico da Situação da Estrutura de Recursos Humanos Alocadas na Área de Tecnologia da Infor-mação das Instituições Públicas Federais. Aspectos Quantitativos e Qualitativos. Identificação de Carên-cias e Oportunidades de Melhoria. Recomendações.https://contas.tcu.gov.br/pesquisaJurispruden-cia/#/detalhamento/11/*/KEY:ACORDAO-COMPLE-TO-1305441/DTRELEVANCIA%20desc/false/1

Acórdão TCU 1603/2008-P Situação da Governança de Tecnologia da Informa-ção - TI na Administração Pública Federal. Ausência de Planejamento Estratégico Institucional. Deficiência na Estrutura de Pessoal. Tratamento Inadequado à Confidencialidade, Integridade e Disponibilidade das Informações. Recomendações.https://contas.tcu.gov.br/pesquisaJurispruden-cia/#/detalhamento/11/*/KEY:ACORDAO-COMPLE-TO-40269/DTRELEVANCIA%20desc/false/1

http://www.cnj.jus.br/busca-atos-adm?documento=2485






http://www.cnj.jus.br/atos-normativos?documento=2227

http://www.cnj.jus.br/atos-normativos?documento=2227



https://contas.tcu.gov.br/pesquisaJurisprudencia/#/detalhamento/11/*/KEY:ACORDAO-COMPLETO-40269/DTRELEVANCIA desc/false/1




Acórdão TCU 2308/2010-P Avaliação da Governança de Tecnologia da Informa-ção na Administração Pública Federal. Constatação de Precariedades e Oportunidades de Melhoria. De-terminações, Recomendações e Comunicações.https://contas.tcu.gov.br/pesquisaJurispruden-cia/#/detalhamento/11/*/KEY:ACORDAO-COMPLE-TO-1156420/DTRELEVANCIA%20desc/false/1

Acórdão TCU 2.523/2012-P de 19/09/2012

Relatório consolidado de auditorias operacionais. Tema de maior significância nº 7 de 2011 sobre siste-mas informatizados de gestão das empresas estatais. Oportunidades de melhoria, recomendações.https://contas.tcu.gov.br/pesquisaJurispruden-cia/#/detalhamento/11/*/KEY:ACORDAO-COMPLE-TO-1247601/DTRELEVANCIA%20desc/false/1

Acórdão TCU 2585/2012-P Avaliação da Governança de Tecnologia da Informa-ção na Administração Pública Federal. Oportunidades de Melhoria. Recomendações.https://contas.tcu.gov.br/pesquisaJurispruden-cia/#/detalhamento/11/*/KEY:ACORDAO-COMPLE-TO-1248749/DTRELEVANCIA%20desc/false/1

Acórdão TCU 3051/2015-P Tomada de Contas Especial. Convênio. Omissão no dever de prestar contas. Não Comprovação da Apli-cação Regular dos Recursos. Citação. Revelia. Contas Irregulares. Débito. Multa.https://contas.tcu.gov.br/pesquisaJurispruden-cia/#/detalhamento/11/*/KEY:ACORDAO-COMPLE-TO-1448053/DTRELEVANCIA%20desc/false/1














Referências

• SABBAGH, Rafael. Scrum: Gestão ágil para projetos de sucesso. São Paulo: Casa do Código, 2014.

• SCHWABER, Ken e SUTHERLAND, Jeff. Guia do Scrum. E-book. Scrum Alliance, 2009

• Lean Kanban (https://edu.leankanban.com/)

• CAROLI, Paulo. Lean Inception: como alinhar pessoas e construir o produto certo. 1ª ed. - São Pau-lo: Editora Caroli, 2018. (http://www.caroli.org/lean-inception/)

• ALBINO, Raphael Donaire.Métricas Ágeis: Obtenha melhores resultados em sua equipe. Casa do Código, 2018.

• DUVALL, P; MATYAS, S; GLOVER, A. Continuous Integration. Pearson Education, 2007

• MARTIN, ROBERT C. Código Limpo - Habilidades Práticas do Agile Software. Alta Books, 2009

• VIEIRA, DENNISON. Scrum: A Metodología Ágil Explicada de forma Definitiva, 2014. Disponível em: <http://www.mindmaster.com.br/scrum>. Acessado em: 08/01/2018

• Continuous Integration, Delivery, and Deployment with GitLab. Disponível em: <https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab>. Acessado em: 08/01/2018

• O que significa integração contínua? Disponível em: <https://aws.amazon.com/pt/devops/conti-nuous-integration>. Acessado em: 08/01/2018

• Scrum Guide em Português - versão de Novembro de 2017, disponível em: <https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Portuguese-Brazilian.pdf>

• Diretrizes para a Gestão da Segurança da Informação no Judiciário http://www.cnj.jus.br/images/dti/Comite_Gestao_TIC/Diretrizes_Gestao_SI_PJ.pd

• Open Web Application Security Project (OWASP). https://www.owasp.org/index.php/Main_Page • OWASP Top 10 – 2017. The Ten Most Critical Web Application Security Risks. https://www.owasp.org/images/0/06/OWASP_Top_10-2017-pt_pt.pdf

https://edu.leankanban.com/

http://www.caroli.org/lean-inception/

https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Portuguese-Brazilian.pdf

http://www.cnj.jus.br/images/dti/Comite_Gestao_TIC/Diretrizes_Gestao_SI_PJ.pd




Documents

Secretaria de Tecnologia da Informação/SETI