Please enable JavaScript.
Coggle requires JavaScript to display documents.
Assessment para os níveis de maturidade (Agilidade (Níveis (2 - Explorado …
Assessment para os níveis de maturidade
Agilidade
Níveis
2 - Explorado
:neutral_face:
Objetivo
- Planejamento de projetos; Melhorias em engenharia ágil de requisitos; Práticas orientadas a clientes e stakeholders; Aprimoramento de Valor, Colaboração e Planejamento;
Alvos
Planejamento de projeto
Assessment
Existe entendimento do escopo do projeto
Release planning é usada para definir a melhor forma de entregar o trabalho realizado. :!?:
A velocidade do projeto é medida
O projeto é dividido em iterações
Estimativas são feitas pelos desenvolvedores
Estimativas de experiências anteriores e técnicas de pontuação (T-shirt sizing, Story points) são usadas
Planejamento do trabalho é feito baseado em valor de negócio.
O PO está presente em todas as cerimônias de estimativa.
Trabalha-se de forma iterativa e incremental.
Conciliam-se a capacidade do time e o escopo do projeto.
Usa-se Planning para criar planos de projeto
Desenvolvimento orientado a User Histórias (engenharia de requisitos)
Assessment
Template de história definido
Existe um backlog priorizado para administrar as Histórias de Usuário.
Há entendimento completo das histórias
Há compromisso do time de desenvolvimento com as Histórias/Atividades
Consegue-se identificar inconsistencias entre História de usuário, épicos, demandas objetivos estratégicos.
O PO fala diretamente com a área de negócio sobre suas necessidades.
Há um plano para tratar mudanças de Histórias de usuário
Histórias de usuário são escritas sob diversos pontos de vista
Histórias de usuário são escritas para endereçar questões de engenharia de requisitos.
Cliente e time juntos
Assessment
As decisões de negócio são feitas pelo PO.
O cliente também se compromete com o escopo da história do usuário.
O cliente está sempre disponível
O cliente domina com maestria o assunto.
Introdução de TDD
Assessment
Testes unitários são identificados a partir das tarefas.
1 - Inicial
:cry:
3 - Definido
:open_mouth:
Objetivo
- Satisfação do cliente; Melhoria de comunicação; Qualidade de software; Aprimoramento de práticas e padrões de código;
Alvos
Gestão da relação com o cliente
Assessment
Metáfora do sistema definida, permitindo que o representante do cliente entenda o sistema. :warning:
Cliente e representante do cliente presentes ou ao menos convidados para sessões de estimativa.
Pequenas e frequentes refatorações encorajadas. Refatorações grandes são repriorizadas com o cliente.
São feitos pequenos releases frequentemente
Histórias de usuário são escritas
Planos de projetos (portifólios?) são criados para criar planos de projeto. :red_flag:
Colabora-se efetivamente com o cliente.
Entrega frequente de software funcional
Assessment
São realizados frequentemente pequenos releases que criam um ciclo de feedback. (homolog?) :red_flag:
Apenas um par integra código de cada vez
Há integração contínua
Programação em pares
Assessment
Intercalam-se os pares
O cliente visita frequentemente o time de desenvolvimento
Todo código que vai para produção é criado em Pair Programming? :recycle: (validado seria mais adequado)
Há ownership coletivo do time para com o código
Informações sobre horas extras são coletadas e publicadas (too much??):warning:
Interação mútua
Assessment
Todo código criado é feito Pair Programming :red_flag: (too much)
As histórias de usuário são criadas em colaboração entre cliente (ou seu representante) e o time de desenvolvimento
Comunicam-se os resultados usando testes de aceitação :recycle: (KPIs seria mais adequado??)
Pequenas e frequentes refatorações encorajadas. Refatorações grandes são repriorizadas com o cliente.
No time os membros têm um ambiente aberto que possibilita colaboração e conversas
Test Driven Development (TDD)
Assessment
Primeiramente codificam-se testes unitários.
Refatoração acontece sempre onde e quando for possível
Todos os codigos devem ter testes unitários :recycle: sempre??
Todo código deve passar pelo teste unitário e seu resultado deve ser publicado antes que o release ocorra
Quando um bug é encontrados, testes são criados
As melhores práticas para teste automatizado são encorajadas, reconhecidas e colocadas em prática nos projetos.
Os integrantes do time revisam os trabalhos uns dos outros.
Analisam-se resultados e são identificadas as ações corretivas cabíveis.
Implementação e Interação
Assessment
Nenhuma funcionalidade é incluida prematuramente.
Integração frequente
Testes automatizados são frequentemente usados para suportar testes de integração.
O time entrega conteúdo útil para revisão de negócios a cada 1-4 semanas.
Sem antecipações desnecessárias. :recycle: (pressa no deploy)
A lista de histórias de usuário é repriorizada com base em avaliações atualizadas do projeto a cada iteração.
As melhores práticas de integração contínua são encorajadas, reconhecidas e em uso no projeto.
Há preparação para integração entre projetos.
Uma sequencia de integração é determinada.
Padrões de código
Assessment
Codigo deve ser escrito de acordo com padrões básicos definidos pela arquitetura.
Testes unitários baseados nos cenários de testes
Todo código em produção é revisado em par
Domínio coletivo do código.
4 - Melhorado
:smiley:
Objetivo
- Times empoderados e recompensas; Gestão de projetos; Avaliação de Riscos; Sem horas extras; Simplicidade;
Alvos
Gestão de projetos
Assessment
Uso de processos definidos para execução dos projetos :red_flag: Talvez isso não faça sentido já que a gestão de processos é definida por uma gestão que inclusive o
RafaelRedondo
é gestor.
A medida primária de progresso é rastreada por meio de progresso em funcionalidades, tais como histórias completadas versus histórias restantes, gráficos Burn Up ou Cumulative Flow Diagram. :recycle: Acrescentar métricas do plano de qualidade.
Coordenar e colaborar com stakeholders ou cliente
Comprometer-se com um plano viável
Integração de planos
Uso de visão compartilhada do projeto
Ritmo sustentável
Assessment
Os membros do time têm um ambiente aberto que proporciona colaboração e discussões.
As pessoas têm empowerment para tomar decisões relacionadas a como o trabalho deve ser organizado e executado.
O time aceita responsabilidades durante o tempo de vida do projeto.
Sem horas extras (40 horas por semana) :warning:
Time de gestão trabalha em ritmo sustentável. :warning:
Auto organização do time
Assessment
Acredita-se que os processos de gestão de mudança estejam aptos e tendam a encorajar eventuais submissões de mudança. :recycle: Adaptar para a realidade GMUD (precisamos discutir a GMUD as is)
O time regularmente desafia a si e os processos da empresa com objetivo de minimizar desperdícios e gerar eficiencia.
O time de projetos está considerando fazer a coisa mais simples que possivelmente possa funcionar. :recycle: (com qualidade)
O time toma decisões em conjunto com o cliente e o Gerente de Projetos :recycle: remover figura GP
O time regularmente reflete a respeito do trabalho feito e agradece participantes chave
Verificação de risco
Assessment
Preparar a gestão de risco
Criar soluções para reduzir risco
Monitorar riscos do projeto por meio de testes de aceitação
Mitigar riscos.
Identificar e analisar riscos
Planejamento de Otimização de código
Assessment
Adiam-se otimizações o máximo possível. :!?:
5 - Sustentado
:stuck_out_tongue:
Objetivo
- Melhoria de contexto; Administração da incerteza; Melhorias de performance de projetos; Prevenção de defeitos;
Alvos
Planejamento de projetos (Release Planning)
Assessment
Ausência de horas extras :warning:
Satisfação do cliente deve ser atingida :recycle: medida??
Todo código deve passar pelos testes unitários
Toda história de usuário é criada com testes de aceitação
Regularidade na disponibilidade do cliente (Mais de 2h por dia em média) :warning:
Desenvolvimento orientado a User Stories
Assessment
As requisições de mudança e correções são tratadas futuramente com funcionalidades planejadas em colaboração transparente com o cliente.
Implementam-se testes de aceitação com histórias de usuário
Determinam-se causas de defeitos :red_flag: isso é sempre possível??
São coletados dados de defeitos para análise
Causas de defeitos são endereçadas
Implementam-se ações propostas
Avaliam-se os efeitos das mudanças
Tecnologia e processos
Níveis
1 :cry:
Objetivo
- Processos irrepetíveis, pouco controlados e reativos.
Ambientes e Implantação
Artefatos diferentes por ambiente
Processo manual de deploy
Ambiente estático (imagens de VM específicas)
Gestão de releases e conformidade
Alteração de código dentro do servidor
Deploy sem comunicação no slack
Represamento de entregas
Falta de rastreio das mudanças
Gestão de construção e Integração Contínua
Construção de artefato manual
Não utiliza qualquer processo ou ferramanta corporativa
Teste
Teste feito em ambiente específico
Incapacidade de fazer testes locais
Testes unitários desatualizados ou não confiáveis
2 :neutral_face:
Objetivo
- Processos documentados e parcialmente automatizados
Gestão de construção e Integração contínua
Artefatos gerados automaticamente e armaenados junto com tags no código
Deploy pelo Jenkins CI
Ambientes e Implantação
Configuração de ambiente no terraform
Configuração criada no repositório app-script
Utilização de gitflow junto com Jenkins CI
Gestão de releases e conformidade
Deploy pelo Jenkins CI
Histórias não marcadas no commit
Comunicação de deploy apenas pela mensagem automatizada do Slack
Teste
Testes unitários com cenários fundamentais da história
Utilização de TDD
3 :open_mouth:
Objetivo
- Processos automatizados aplicados em todo o ciclo de vida da aplicação
Gestão de Construção e Integração contínua
Teste unitário e cobertura rodando pelo Jenkins CI
Utilização de frameworks para manter padrão de desenvolvimento
Qualidade mínima da cobertura atendida
Ambiente e Implantação
Aplicação com regras de autoscaling implementadas
Tamanho de servidores adequados
Definir alarmes de monitoria básicas
Gestão de releases e conformidade
Abertura de GMUD para toda mudança
Changelog das versões no repositório (changelog.md)
Teste
Sem testes não confiáveis (no flaky tests)
Escrita de cenários avançados de teste
QA Coach fazendo Test Review
4 :beer::smiley:
Objetivo
- Processo mensurado e controlado
Gestão de construção e Integração contínua
Métricas do SonarQube como Avaliação de Qualidade para integração contínua
Nenhum build pode ser mantido quebrado
Ambientes e Implantação
Mapeamento de sistemas consumidores afetados
Ambiente sem dowtime durante deploy
Monitorias baseadas em métricas de negócio
Gestão de Releases e conformidade
Aplicação expondo suas métricas de conformidade
Teste
Teste de stress em homolog a cada deploy
5 :stuck_out_tongue::beer_mugs::stuck_out_tongue:
Objetivo
- Foco na melhoria do processo
Gestão de construção e Integração contínua
Ambientes e Implantação
Gestão de Releases e conformidade
Teste