A Metodologia de Desenvolvimento de Sistemas do TJ-RS (MDS-TJRS) tem como objetivo guiar o desenvolvimento de sistemas para entregar aos clientes o melhor resultado com qualidade e agilidade.

É integrada com os processos organizacionais da Direção de Tecnologia da Informação e Comunicação (DITIC), tal como o Processo de Gerenciamento de Projetos, Processo de Gerenciamento de Mudanças e o Processo de Gerenciamento de Incidentes.

Tem como objetivo manter-se um guia organizacional sucinto, flexível, evolutivo, de fácil acesso e entendimento a todos da DITIC.

A figura a seguir ilustra a MDS-TJRS:

Revisões da MDS-TJRS

Ciclo de Vida Iterativo e Incremental

É a forma ágil de trabalho baseada em ciclos semanais de planejamentos e entregas frequentes. É a forma recomendada quando se trabalha em time em desenvolvimento de novas funcionalidades, ou evolução de funcionalidades já existentes.

O planejamento e executado em iterações (sprints) de duração de uma a quatro semanas. Em cada iteração, o time desenvolve as funcionalidades priorizadas do sistema. Uma entrega pode necessitar de mais de uma iteração para ser desenvolvida. Mesmo assim, busca-se dividira entrega em partes de valor e entregáveis ao cliente.

O framework Scrum e a metodologia ágil eXtreme Programming descrevem as práticas, reuniões e cerimônias desse ciclo iterativo e incremental. No início de cada iteração, o time planeja o que e como as funcionalidades serão desenvolvidas. A cada dia da iteração, o time realiza uma reunião diária para sincronização e replanejamento do trabalho sendo feito. No final de cada iteração, realiza-se a reunião de revisão para ver o que foi concluído como pronto, e a reunião de retrospectiva para criar ações de melhoria no processo do time.

1.    Fases do processo

1.1.  Kanban de Descoberta

Tem por objetivo receber as demandas direcionadas ao desenvolvimento, classificá-las e executar técnicas de Discovery para os diversos requisitos definidos a fim de gerar Backlog priorizado para os times de desenvolvimento.

Esse fluxo de recebimento de demandas é feito de forma contínua sempre que uma nova necessidade é aberta, ela é categorizada, seus requisitos são levantados e a sua prioridade no desenvolvimento é realizada, podendo alterar o Kanban de Desenvolvimento do time.

Processos:

Solicitar complemento da documentação:

Processo de definir, preparar e alinhar toda a documentação da demanda e integrá-las a documentação de requisitos.  O principal benefício deste processo é analisar e verificar a necessidade de complemento de toda a documentação. O conteúdo da documentação varia dependendo da área de aplicação e complexidade da demanda. Esse processo resulta na análise de gaps de uma determinada demanda.

Documentar a Demanda ou Tarefa:

Documentar a demanda ou tarefa é o processo de determinar, documentar e gerenciar as necessidades e requisitos das partes interessadas a fim de atender aos objetivos do projeto.

O principal benefício deste processo é o fornecimento da base para definição e gerenciamento do escopo da demanda, incluindo o escopo da demanda ou tarefa.

Reunião de Planejamento das Entregas:

O planejamento das entregas consiste em criar a subdivisão das entregas e do trabalho.

O principal benefício desse processo é o fornecimento de uma visão estruturada do que deve ser entregue.

O plano de entrega consiste em definir o escopo total do trabalho a ser executado pela equipe do projeto a fim de alcançar os objetivos e criar as entregas requeridas.

O trabalho planejado é contido dentro dos componentes de nível mais baixo, que são chamados de pacotes de trabalho. Um pacote de trabalho pode ser usado para agrupar as atividades onde o trabalho é agendado, tem seu custo estimado, monitorado e controlado.

Analisar os Requisitos:

Analisar os requisitos é o processo de desenvolvimento de uma descrição detalhada dos requisitos. O principal benefício deste processo é que ele descreve os limites, serviços ou resultados ao definir quais dos requisitos coletados serão incluídos e quais serão excluídos do escopo.

Todos os requisitos identificados selecionam os requisitos finais do projeto a partir da documentação de requisitos entregue durante este processo.  Em seguida é feita uma descrição detalhada dos requisitos.

A preparação detalhada da especificação do escopo é crítica para o sucesso do projeto e baseia-se nas entregas principais, premissas e restrições que são documentadas durante a iniciação do projeto.

O grau e o nível de detalhe no qual a análise de requisitos define o trabalho que será executado e o que será excluído pode ajudar a determinar a capacidade da equipe de controlar o escopo geral.

A especificação detalhada do escopo do projeto inclui, seja diretamente ou por referência a outros documentos auxiliares:

-  Descrição do escopo do produto.

-  Critérios de aceitação.

- Entrega.

- Exclusão do projeto.

- Restrições.

Aprovar os Requisitos:

Aprovar os requisitos é o processo de formalização, onde o principal benefício é que ele proporciona a aceitação dos requisitos e aumenta a probabilidade da aceitação final da demanda, através da validação de cada entrega.

Neste processo são obtidas como resultado a documentação dos requisitos ou da linha de base do escopo, assim como os dados de desempenho do trabalho.

Atualizar o Backlog do Time:

É o processo de organizar e fazer a manutenção do backlog do produto. Isso significa detalhar e priorizar os itens de maneira estratégica.

O objetivo é preparar os itens do backlog para as sprints. É o período de realização de um conjunto de tarefas que compõem uma etapa do desenvolvimento do produto. Assim, os itens do backlog precisam trazer detalhes, informações e especificações relevantes para otimizar a produtividade do time quando a sprint começar.

O principal responsável pelo backlog é o chefe de equipe com o papel de PO (Product Owner) e o time também precisa participar do processo de decisão daquilo que irá entrar no backlog, avaliando se as tarefas estão detalhadas o suficiente.

O PO pode propor reuniões específicas para fazer o backlog do produto. Nesse caso, os objetivos do projeto devem ser relembrados, assim como a necessidade de cada tarefa no momento considerado.

Durante essa reunião, as pessoas também podem aproveitar para esclarecer suas dúvidas sobre as tarefas analisadas. Tudo isso ajuda no refinamento dos itens do backlog e no entendimento sobre o que deve ser priorizado nas próximas sprints.

A atualização de backlog é uma etapa importante para a equipe, já que o refinamento dos itens do backlog traz:

• Otimização da produtividade do time;
• Alinhamento entre o time;
• Planejamento;
• Mais tranquilidade para a realização das tarefas.

Além disso, esta etapa também pode ajudar os profissionais a terem um senso maior de propósito, já que eles têm mais clareza sobre o que estão fazendo e o porquê de estarem fazendo determinada tarefa em um momento específico da sprint.

1.2 Kanban de Desenvolvimento

Se refere a todas as etapas seguintes do fluxo de trabalho a partir do backlog gerado no kanban de descoberta. É onde o backlog será de fato selecionado, desenvolvido e testado. Essa etapa é onde o trabalho comprometido passará pelo fluxo de entrega.

Processos:

Reunião de planejamento

Executar um bom evento planejamento de sprint requer disciplina. O PO deve estar preparado, combinando lições da revisão do sprint anterior e feedback das partes interessadas para que possa definir o cenário para o sprint.  Por questões de transparência, o backlog deve ser atualizado e refinado para fins de esclarecimento.

O planejamento do sprint é um evento que inicia o sprint. O objetivo do planejamento do sprint é definir o que pode ser entregue no sprint e como esse trabalho vai ser alcançado. O planejamento do sprint é feito em colaboração com todo o time.

O planejamento do sprint requer algum nível de estimativa. A equipe precisa definir o que pode e o que não pode ser feito no sprint. As estimativas são sugeridas e por natureza, previsões baseadas no conhecimento disponível. Técnicas como pontos da história ou tamanho das camisetas agregam valor ao processo, oferecendo à equipe maneiras diferentes de encarar o problema.

A equipe dever selecionar itens do Backlog com os quais compromete-se a concluir. Esses itens já devem ter sidos previamente refinados no rito na fase anterior.

O que fazer:

• Selecionar itens de backlog
• Decompor os itens de backlog caso necessário
• Detalhar itens de backlog
• Estimar
• Verificar se os itens estão prontos para desenvolver

Desenvolvimento

Após o planejamento é o momento de desenvolvimento de todo o trabalho definido. Aqui são desenvolvidos códigos, testes unitários e documentações do que está sendo implementado.

O desenvolvimento e a entrega no Agile são iterativos. O trabalho é feito em pequenas iterações, geralmente com duração de 1 ou 2 semanas. Às vezes até 4. Também é incremental porque em cada iteração você constrói pequenas fatias de software de trabalho que podem se manter de pé.

Código versionado e publicado para teste

A cada trabalho desenvolvido deve-se versionar os fontes, testar e publicar uma versão para os testes de aceitação do que o time se comprometeu na sprint.

• Ao final da Sprint, o trabalho desenvolvido deve estar pronto
• Mas o que significa “pronto”? O Time e o Product Owner devem definir o que significa “pronto”
• Quando alguém diz que algo está “pronto”, todos devem entender o que isso significa Ex: de software: codificado, testado e documentado

Testar

O teste ágil demanda o envolvimento de toda a equipe. O fluxo de trabalho consiste em entregas pequenas e incrementais, ou seja, vão somando-se até construir o corpo do produto final. Além disso, durante ciclos mais curtos de desenvolvimento, elemento característico da implementação do ágil, a entrega é realizada em pequenos blocos que contemplam o produto final e o feedback é mais rápido, o que facilita a eficiência em cada sprint.

Nesse sentido, os times não ficam dependentes da figura do testador como um executor isolado, que corre atrás dos bugs na aplicação antes da entrega final, e sim, a incorporação de uma mentalidade do agile testing. Essa integração se apresenta quando a expertise de Q.A está no cotidiano do time ágil.

Manifesto do Teste

• Testar continuamente mais que testar no final;
• Prevenir defeitos mais que encontrar defeitos;
• Entender o teste mais que verificar a funcionalidade;
• Construir o melhor sistema mais que quebrar o sistema;
• Time responsável pela qualidade mais que responsabilidade do testador.

A prática de Bult-In Quality compreende a ideia de que a busca pela qualidade não advém em eventos de testes subsequentes após finalizada uma etapa, mas são realizados de forma concomitante e incremental ao processo de concepção e desenvolvimento. Dessa forma, a qualidade é o foco e não a velocidade de entrega.

Publicar em homologação

O processo de homologação é a comprovação, pelo cliente e demais partes interessadas, de que o produto resultante do projeto de software atende aos critérios de aceite previamente estabelecidos com o cliente.

Abertura de bugs

O processo de abertura de bugs consiste em atividades técnicas de manutenção continuada de soluções de software implantadas nos ambientes de homologação e produção, cujo principal resultado seja a correção de defeitos, manutenção da disponibilidade, estabilidade e desempenho de soluções. Além desses, estão incluídas no escopo, intervenções tempestivas ou pontuais de caráter perfectivo, corretivo, preventivo, atendimento ao usuário ou atividade operacional, não se limitando a essas, conforme segue:

• Manutenção de disponibilidade
• Estabilidade e desempenho
• Intervenção Corretiva
• Análise e solução de incidentes
• Monitoramento contínuo
• Apoio à produção
• Operação de soluções de software
• Integração e entrega contínua.

Reunião kanban (daily)

É a etapa de inspeção do time.

Reunião de 15 minutos realizada todo dia e na mesma hora.

Todos respondem às perguntas:

• O que você realizou desde a última reunião?
• Quais problemas você enfrentou?
• Em que você trabalhará até a próxima reunião?

Benefícios:

• Maior integração entre os membros da equipe
• Identificação de impedimentos
• Promovem o compartilhamento de conhecimento
• Progresso medido continuamente
• Minimização de riscos

Reunião técnica com a área de negócio

Esse processo consiste em reunião para entendimento e retirada de dúvidas em relação aos produtos.

1.3 Kanban de Homologação

Se refere a todas etapas de revisão, publicação para produção e melhoria continua.

Processos:

Reunião de revisão de incremento

Essa etapa consiste da revisão que é executada no final de cada release para inspecionar o incremento e adaptar o backlog do produto se necessário.

Durante a reunião de revisão o time e as partes interessadas colaboram sobre o que foi feito na release. Esta não é uma reunião de status, e a apresentação do incremento destina-se a motivar e obter comentários e promover a colaboração.

A reunião de revisão inclui os seguintes elementos:

• Os participantes incluem o time e os convidados pelo product owner;
• O product owner esclarece quais itens do backlog do produto estão “prontos” e quais não estão “prontos”;
• O time de desenvolvimento discute o que foi bem durante a sprint, quais problemas ocorreram dentro da sprint, e como estes problemas foram resolvidos;
• O time de desenvolvimento demonstra o trabalho que está “pronto” e responde as questões sobre o incremento;
• Análise da próxima versão esperada do produto. O resultado da reunião de revisão da sprint é um backlog do produto revisado.

Retrospectiva de time

A retrospectiva é uma oportunidade para o time inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima sprint. A retrospectiva ocorre depois da revisão da sprint e antes da reunião de planejamento da próxima sprint.

Esta é uma reunião time-boxed de até três horas. O propósito da retrospectiva da sprint é:

• Inspecionar como a última sprint foi em relação às pessoas, aos relacionamentos, aos processos e às ferramentas;
• Identificar e ordenar os principais itens que foram bem e as potenciais melhorias;
• Atualizar o artefato de lições aprendidas