Você está na página 1de 318

Bootcamp

Engenharia de Software Ágil


Fundamentos – Capítulo 1 – Introdução à Engenharia de Software

ANALÍA IRIGOYEN
Engenharia de Software Ágil
Aula 1.1. Fundamentos e cenário da Engenharia de Software

ANALIA IRIGOYEN
Reflexão...
“Por que os custos de
“Por que leva tanto tempo desenvolvimento são
altos?”
para concluir o software?”

“Por que não podemos


achar todos os erros “Por que gastamos tanto
antes de entregar o tempo e esforço mantendo
software aos clientes?” programas existentes?”
Reflexão...

“Sendo um sociólogo, constatei que [o desenvolvimento]


de software é um processo social altamente
cooperativo.”
Jorg Strubing, 1991
Engenharia de Software
Engenharia de
Software?

 O desenvolvimento de software é uma atividade de


Engenharia?
 Pode-se falar numa Engenharia de Software?
Engenharia (Significado)
Engenharia de
Software?

“Arte de aplicar conhecimentos científicos e empíricos e


certas habilitações específicas à criação de estruturas,
dispositivos e processos que se utilizam para converter
recursos naturais em formas adequadas ao atendimento das
necessidades humanas” – Dicionário Aurélio
Engenharia de Software
Atualmente o termo ENGENHARIA DE SOFTWARE é mais comumente usado para
referir-se a:
Engenharia de
 modelos de ciclo de vida
Software?
 métodos e ferramentas

 técnicas para estimativa de custos

 documentação

 técnicas para controle da qualidade

O termo GERENCIAMENTO DE SOFTWARE é muito mais


apropriado para esta situação
Engenharia de Software

 ENTRETANTO o desenvolvimento de software é um problema de Engenharia.

 BUSCA-SE:
 A criação de soluções econômicas para problemas práticos.

 Construir objetos a serviço da sociedade.


Cenário atual do
Desenvolvimento de Software

 Pressão constante por parte do cliente pela

entrega rápida.
Cenário atual do
Desenvolvimento de Software

 Cliente acha que em uma única reunião de 30 min já somos

capazes de desenvolver um software.


Cenário atual do
Desenvolvimento de Software
Cenário atual do
Desenvolvimento de Software

 Desenvolvedores são orientados à solução: desejam começar logo a programar sem ter

um entendimento claro do que é necessário.


Engenharia de Software Ágil
Aula 1.2. Por que o Software falha?

ANALIA IRIGOYEN
Porque o software falha!?

 Qual o problema mesmo?


Porque o software falha!?
Engenharia de Software –
Definição
 “Enfoque sistemático para o desenvolvimento, operação, manutenção e descontinuação

do software” – IEEE Glossary of Software Terminology.

 “Aplicação prática do conhecimento científico no projeto e construção de programas e

da documentação requerida para desenvolver, operar e manter esses programas” –

Barry Boehm.

 “Criação e a utilização de sólidos princípios de engenharia a fim de obter softwares

econômicos que sejam confiáveis e que trabalhem eficientemente em máquinas reais” –

Fritz Bauer.
Software: características

 O software é desenvolvido, não manufaturado (no sentido clássico).

 A fase de fabricação de hardware pode gerar problemas de qualidade que

são facilmente corrigidos no caso de software.


Software: características

 Software não se desgasta.

 O software se deteriora por modificações, que introduzem novas falhas.

 O hardware apresenta muitas falhas no início de sua vida por falhas de projeto e

no final por desgaste do material.

18
Software: características

Curva de Falhas para o Hardware

Mortalidade
Infantil
Desgaste

Taxa de
Falhas

Tempo
Software: características
Curva de Falhas para o Software
Falha por
Efeito Colateral

Taxa de
Falhas
Curva Real

Idealizada
Modificação

Tempo
Software: características

 A maioria dos softwares é feita sob encomenda.

 Analogia: Um engenheiro para construir uma ponte não precisa projetar um parafuso.

 O software precisa caminhar para a idéia de software baseado em componentes (ESBC).

 Frameworks prontos.

 Componentes de negócio reutilizáveis.

 SOA (Service Oriented Architecture).

21
Tipos de aplicações

Software de Sistema

 Software que serve a outro software, hardware, processos, pessoas, etc.

 Windows, Linux, Ios, Android, MACos

Software de Aplicação

 Programas isolados que resolvem uma necessidade específica do negócio.

 Suite Office, Jogos, Browsers, Banco de Dados, etc.

Sistemas de Tempo Real

 Sistema que deve responder com suficiente rapidez (milisegundos) ou o ambiente ficará fora de controle.

 Ex: ATMs (Caixa eletrônico), orientação aérea, monitoração de pacientes, validadores de transporte público.
Tipos de aplicações

Software Científico e de Engenharia

 Processamento de grandes cálculos (astronomia, biologia molecular, vulcanologia, etc.).

Software Embutido ou Embarcado

 Reside dentro de um produto ou sistema (controle de aparelhos domésticos (microondas, geladeira,


cofres), automóveis (controle de combustíveis, dasboard de avaliação dos sistemas automotivos), etc.).

Aplicações Web

 Dados são introduzidos remotamente.

 Interação com o computador através de terminais.

 Dados armazenados são rapidamente acessados.


Tipos de aplicações
Software de linha de produto

 Software que provê capacidade específica a ser usada por muitos clientes.

 Editores de Texto, Planilhas eletrônicas, Apresentação, etc.

Software baseado em conhecimento (inteligência artificial)

 Aplicações que utilizam algoritmos para resolver problemas complexos que não são passíveis de
computação ou análise direta, exigindo interpretação.

 sistemas especialistas, processamento de padrões de imagem e voz, sistemas de jogos


inteligentes, redes neurais, etc.

Computação Ubíqua

 Tornar a interação pessoa-máquina invisível, ou seja, integrar a informática com as ações e


comportamentos naturais das pessoas.
Tipos de aplicações

Software Legado – Desenvolvidos há um longo tempo e algumas vezes:

Têm projetos não extensíveis.

Código complicado.

Documentação pobre ou inexistente.

Casos de testes não documentados.

Histórico de modificações mal geridas.

25
Engenharia de Software Ágil
Aula 1.3. Mitos e Verdades

ANALIA IRIGOYEN
Mitos e Verdades

“Um livro de padrões de projeto e procedimentos de programação basta


para prover a minha equipe todo o conhecimento necessário para
desenvolver software de qualidade.”

• Verdade:

• Soluções em alto nível.

• Difícil compreensão e aplicação prática.

• Voltado para situações genéricas.

27
Mitos e Verdades

“Minha equipe possui as ferramentas mais atuais de


Engenharia de Software e os computadores mais
modernos.”

• Verdade:

• Mesmo a melhor ferramenta não pode fazer um desenvolvedor

mediano se tornar um bom desenvolvedor.

28
Mitos e Verdades
“Se estivermos atrasados, iremos adicionar mais
pessoas à equipe.”
• Verdade:
• Ruídos de comunicação, overhead de gerência.
• Nem todas as tarefas podem ser divididas (paralelizadas).
• Novas pessoas precisam ser treinadas pelas pessoas que já estão
no projeto.
• Acrescentar mais pessoas a um projeto atrasado faz com que ele
se atrase mais.

29
Mitos e Verdades

“Uma ideia geral dos objetivos é suficiente para começar a escrever os


programas.”

• Verdade:

• A falta de identificação adequada dos objetivos é a principal causa do fracasso


de projetos.

• A descrição detalhada dos requisitos de informação, funções, desempenho e


interface, das restrições de projeto e dos critérios de validação é essencial e
deve ser feita com o usuário/cliente.
30
Mitos e Verdades

“Os requisitos mudam constantemente, mas é fácil acomodar estas mudanças, afinal
o software é flexível.”

• Verdade:

• Requisitos mudam continuamente mas o impacto das mudanças varia de acordo com
o momento em que estas ocorrem (quanto mais a frente estivermos, mais caro será!).

• Software deve ser manutenível!

31
Mitos e Verdades

“Uma vez escrito o programa, meu trabalho está feito.”

• Testes, manutenções, etc.

“Até ter algo sendo executado, não posso analisar a qualidade.”

• Software pode ser avaliado desde a sua concepção através de revisões

que são mais efetivas do que testes.

32
Mitos e Verdades

“O único produto a ser entregue em um projeto de

software de sucesso é o programa rodando.”

• Um programa funcionando é apenas parte de uma configuração de

software que inclui programas, documentação e dados.

33
Mitos e Verdades

O programa está 95% pronto

Realidade
• Programadores são extremamente otimistas.

• Programadores costumam acreditar na própria.


capacidade de resolver problemas de forma imediata,
mesmo na contínua evidência do contrário.
Bootcamp
Engenharia de Software Ágil
Fundamentos – Capítulo 2 – Processos e Ciclos de Vida de Desenvolvimento de Software (CVDS)

ANALÍA IRIGOYEN
Engenharia de Software Ágil
Aula 2.1. Processos de desenvolvimento de software

ANALIA IRIGOYEN
O que é um processo?

• Série de passos para criar o software dentro do prazo e custo, com uma alta
qualidade.

• Engenheiros de software, gerentes e stakeholders participam.

• É importante porque evita o caos.

• Os produtos finais são: programas, documentos e dados.

• Processos podem ser avaliados de acordo com modelos.


O que é um processo?

• Base para o controle gerencial de projetos de software.

• Estabelecem o contexto no qual:

• Métodos técnicos são aplicados,

• Produtos de trabalho são produzidos,

• Marcos são estabelecidos,

• Qualidade é assegurada

• Modificações são adequadamente geridas..


O que é um processo?

Engenharia de Software

Ferramentas

Métodos

Processo

Foco na Qualidade
O que é um processo?

Qualidade do processo:
Aumento da qualidade do produto
Diminuição do retrabalho
Maior produtividade
Redução do tempo para atender o mercado
Maior competitividade
Maior precisão nas estimativas.
O que é um processo?
O interesse no processo de software está baseado em duas premissas:

1. A qualidade de um produto de software é fortemente dependente da


qualidade do processo pelo qual ele é construído e mantido.

2. o processo de software pode ser definido, gerenciado, medido e


melhorado.
O que é um processo de software?
Um processo definido está descrito em detalhes de forma a poder
ser usado de forma consistente e ser repetido por qualquer
pessoa.
Framework do Processo?
• Estabelece o alicerce

• Conjunto de atividades aplicáveis a todos os projetos de software

• Três fases genéricas:

• Definição

• Desenvolvimento

• Manutenção
Framework do Processo?
• Framework do Processo

• Comunicação – Comunicação e colaboração com clientes e outros


interessados

• Planejamento – Tempo, custos, recursos humanos, riscos, recursos


materiais, ...

• Modelagem – Requisitos + Projeto

• Construção – Codificação + testes

• Implantação – Software entregue


Fase Definição
• Foco: o que?

• Atividades:

• Engenharia de sistemas e da informação

• Planejamento do projeto

• Análise e especificação de requisitos


Fase de Desenvolvimento

• Foco: como?

• Atividades:

• Projeto do software

• Codificação

• Testes
Fase de Manutenção
• Fase de Manutenção
• Foco: mudanças no produto

• Razões:

• Correção de erros

• Adaptação por mudanças no ambiente

• Evolução por mudanças nos requisitos do usuário.

• Tipos de Manutenção:

• Corretiva

• Adaptativa

• Evolutiva ou de Melhoria

• Preventiva
Engenharia de Software Ágil
Aula 2.2. Atividades de apoio e Ciclos de Vida

ANALIA IRIGOYEN
Atividades de apoio
• As fases são complementadas por atividades guarda-chuva (de apoio).

• Acompanhamento e controle

• Gestão de Risco

• Revisões técnicas formais

• Garantia da Qualidade

• Gestão de Configuração

• Documentação

• Medição

• Gestão do reuso

• Preparação e produção do produto de trabalho


Modelos de Processos

Em geral, os modelos de processo diferem:


• Fluxo geral de atividades e tarefas e interdependência
• Grau no qual as tarefas são definidas
• Grau no qual os produtos de trabalho são detalhados
• Maneira como as atividades de garantia da qualidade são aplicadas
• Modo como a monitoração e controle é aplicada
• Grau de detalhes e rigor no qual o processo é descrito
• Grau de participação dos clientes e interessados
• Nível de autonomia da equipe
• Organização e detalhamento da equipe
Papéis x Funções

• Gerentes de projeto

• Analistas

• Arquitetos de software

• Programadores

• Clientes

• Testadores
Modelos de Ciclo de Vida - Prescritivos

• Definem um conjunto de atividades, ações, tarefas, marcos e produtos de

trabalho que são necessários para fazer engenharia de software com qualidade.

• Escolhidos de acordo com a natureza da aplicação e as características do

projeto.

• Correspondem ao que usualmente se chama de Ciclo de Vida.


Modelos de Ciclo de Vida - Prescritivos

• Diferentes modelos

• Não existe melhor nem pior

• Escolha depende:

• do domínio da aplicação,

• das características do grupo desenvolvedor,

• do grau de conhecimento sobre o problema.


Modelos de Ciclo de Vida - Cascata

• Tendência na progressão sequencial entre uma fase e a seguinte.


Modelos de Ciclo de Vida - Cascata

• Assume que é possível declarar detalhadamente todos os requisitos

antes do início das demais fases do desenvolvimento.

• propagação de erros pelas as fases do processo.

• Uma versão de produção do sistema não estará pronta até que o ciclo

do projeto de desenvolvimento chegue ao final.

• Projetos reais raramente seguem um fluxo sequencial.


Modelos de Ciclo de Vida - Cascata

• Características:
• Modelo ainda mais usado,

• Simples e de fácil gestão,

• Todo o sistema é entregue de uma só vez.

• Problemas:
• Mudança de requisitos (retornar a fases anteriores),

• Sistemas grandes (entrega única levaria muito tempo),

• Detecção tardia de erros (maior impacto e custo de correção).


Engenharia de Software Ágil
Aula 2.3. Principais Ciclos de Vida – Interativos

ANALIA IRIGOYEN
Modelos de Ciclo de Vida - Prototipagem Rápida

Objetivo:
• Mecanismo para identificar requisitos de software.

Procedimento:
• Constrói-se, rapidamente, uma implementação parcial com os aspectos
pouco entendidos para o usuário avaliar.

• O usuário usa e dá feedback.

• O protótipo é descartado e desenvolve-se a versão final.


Modelos de Ciclo de Vida - Prototipagem Rápida
Modelos de Ciclo de Vida - Prototipagem Rápida

Problemas:
• Custo (será descartado o protótipo).

• Usuário tende a gostar do protótipo e entender que é o produto


final.

Análise Projeto Codificação Teste Manutenção

Protótipo
Rápido
Modelos de Ciclo de Vida - Iterativos

• Divide o desenvolvimento de um produto de software em ciclos.

• Em cada ciclo de desenvolvimento executam-se as fases de análise, projeto,


implementação e testes.

• Cada ciclo considera um subconjunto de requisitos (conhecidos ou não).

• Contraposição ao cascata, na qual as fases são realizadas uma única vez.


Modelos de Ciclo de Vida - Iterativos

Desenvolvimento em “mini-cascatas”.
Modelos de Ciclo de Vida - Iterativos

• Vantagens:

 Incentiva a participação do usuário.

 Riscos do desenvolvimento podem ser mais bem gerenciados.

• Desvantagens:

 Mais difícil de gerenciar.


Modelos de Ciclo de Vida – Iterativo e Incremental

• Iterativo: o sistema de software é desenvolvido em vários passos


similares.

• Incremental: Em cada passo, o sistema é estendido com mais


funcionalidades.
Modelos de Ciclo de Vida – Iterativo e Incremental

• O sistema é desenvolvido em incrementos até ficar completo.

• Desenvolve-se uma versão parcial e vai-se adicionando funcionalidades.

• Pode fornecer versões preliminares aos usuários.

• Bom para prazos apertados e pouca mão de obra.

• Reduz riscos (identificação de erros rápida).


Modelos de Ciclo de Vida – Incremental

Incremento 1

Comunicação Planejamento Modelagem Construção Implantação

...

Incremento 2 Comunicação Planejamento Modelagem Construção Implantação

Incremento 3 Comunicação Planejamento Modelagem Construção Implantação

Incremento n Comunicação Planejamento Modelagem Construção Implantação


Modelos de Ciclo de Vida – RAD

• Desenvolvimento Rápido de Aplicações (Rapid Application


Development).

• Adaptação de “alta velocidade” do modelo cascata.

• Exige requisitos bem compreendidos e escopo fechado.


Modelos de Ciclo de Vida – RAD

Características

• Sistema plenamente funcional entre 60 e 90 dias.

• Incremental (ciclos curtos).

• Baseado em Componentes.

• Modularidade (equipes distintas).

• Requisitos precisam estar bem definidos e o escopo deve ser


restrito.
Modelos de Ciclo de Vida – RAD

Comunicação:
• Entender os problemas do negócio (requisitos) com o cliente.
Planejamento:
• Essencial para paralelismo de equipes.
Modelagem:
• Modelagem de negócio.
• Modelagem de dados.
• Modelagem de processo.
Construção:
• Uso de componentes.
Implantação
• Base para iterações subsequentes.
Modelos de Ciclo de Vida – RAD

Comunicação Planejamento

equipe n

equipe 2 Modelagem

equipe 1 Modelagem
Construção
Modelagem
Construção

Construção

Implantação
Modelos de Ciclo de Vida – RAD

equipe # 1 equipe # 2 equipe # 3

modelagem modelagem modelagem


do negócio do negócio do negócio

modelagem modelagem modelagem


dos dados dos dados dos dados

modelagem modelagem modelagem


do processo do processo do processo

geração da geração da geração da


aplicação aplicação aplicação
teste e teste e teste e
modificação modificação modificação

60-90 dias
Modelos de Ciclo de Vida – RAD

• Geração da Aplicação:

– Assume o uso de técnicas de 4a. Geração (geradores de código,


IDEs, etc.);.

– Reusa componentes quando possível ou cria componentes


reutilizáveis;

– Ferramentas automatizadas são utilizadas para gerar software.


Modelos de Ciclo de Vida – RAD

• Teste e Modificação:

– Por reutilizar componentes, muitas vezes


eles já foram testados, o que reduz o tempo
de teste;

modelagem – Os novos componentes devem ser testados


do negócio
e as interfaces devem ser exercitadas.
modelagem
dos dados

modelagem do
processo
geração da
aplicação
teste e
modificação
Modelos de Ciclo de Vida – RAD

Desvantagens

• Requer recursos humanos suficientes para criar um número


adequado de equips.

• Requer um comprometimento entre desenvolvedores e clientes


para que as atividades possam ser realizadas rapidamente e o
sistema seja concluído em um tempo abreviado. Se o
comprometimento for abandonado por qualquer das partes, o
projeto falhará.

• Não é apropriado quando os riscos são grandes.


Modelos de Ciclo de Vida – RAD

Condição

• A aplicação deve poder ser modularizada de forma a permitir


que cada função de mais alto nível possa ser desenvolvida em
até três meses (cada função pode ser alocada a uma equipe
diferente e depois integrada ao todo).
Engenharia de Software Ágil
Aula 2.4. Principais Ciclos de Vida – Evolutivos

ANALIA IRIGOYEN
Modelos de Ciclo de Vida – Evolutivos

• Software evolui com o tempo e o uso das versões iniciais.

• Também é um modelo Iterativo.

• Requisitos são parcialmente definidos e depois são refinados.

• Desenvolve-se uma versão parcial que atinge requisitos conhecidos.

• A partir do conhecimento adquirido com o uso, evolui-se o produto.


Modelos de Ciclo de Vida – Evolutivos

...
Comunicação Comunicação Comunicação

Planejamento Planejamento Planejamento

Modelagem Modelagem Modelagem

Construção Construção Construção

Implantação Implantação Implantação


Modelos de Ciclo de Vida – Prototipação Evolucionária

• Processo que possibilita que o desenvolvedor crie um modelo do software que deve
ser construído.

• Idealmente, o modelo (protótipo) serve como um mecanismo para identificar os


requisitos de software.

• Apropriado para quando o cliente definiu um conjunto de objetivos gerais para o


software, mas não identificou requisitos de entrada, processamento e saída com
detalhes.

• Associa vantagens dos modelos evolutivo e prototipagem rápida.


Modelos de Ciclo de Vida – Evolutivos

Novas necessidades
Usuário

Prototipador

Protótipo
Rápido e Sujo
Novos requisitos

Análise

Projeto

Codificação

Teste
Modelos de Ciclo de Vida – Evolutivos

Simplificando
Plano Rápido

Comunicação

Modelagem
Projeto Rápido

Implantação,
entrega e Construção do
feedback Protótipo
Modelos de Ciclo de Vida – Evolutivos

Problemas:

• Cliente não sabe que o software que ele vê, não considerou, durante o
desenvolvimento, a qualidade global e a manutenibilidade a longo
prazo. Força a utilização do protótipo como produto final;

• Desenvolvedor freqüentemente faz uma implementação comprometida


com o objetivo de produzir rapidamente um protótipo. Depois de um
tempo ele se familiariza com essas escolhas.
Modelos de Ciclo de Vida – Evolutivos

• Comentários:

 Ainda que possam ocorrer problemas, prototipação é um modo de


vida eficiente.

 Deve-se definir as regras do jogo logo no início.

 O cliente e o desenvolvedor devem ambos concordar que o protótipo


seja construído para servir como um mecanismo a fim de definir os
requisitos.
Modelos de Ciclo de Vida – Espiral

• Combina a iteração da Prototipagem com aspectos do Cascata.

• Software desenvolvido em versões evolucionárias.

• Primeiras versões (ciclos) podem ser modelo de papel, segunda um


protótipo, etc.

• Modelo guiado por riscos.

• Abordagem cíclica.

• Aumentar incrementalmente o grau de definição e implementação de


um sistema enquanto seu grau de risco diminui.

• Marcos de Ancoragem .

• Garantir o comprometimento dos interessados.


Modelos de Ciclo de Vida – Espiral

Planejamento
Estimativa
Cronograma
Recursos
Análise de Riscos

Comunicação

Início Modelagem
Análise e
Projeto

Implantação Construção
entrega
Código e
feedback
Teste
Modelos de Ciclo de Vida – Espiral

• Marcos de Ancoragem: ajudam a estabelecer quando um ciclo


é completado em torno da espiral e fornecem marcos de
decisão antes do projeto de software prosseguir

1. Objetivos do ciclo de vida.

2. Arquitetura do ciclo de vida.

3. Capacidade inicial de operação.


Modelos de Ciclo de Vida – Espiral

• Usa uma abordagem que capacita o desenvolvedor e o cliente a

entender e reagir aos riscos em cada etapa evolutiva.

• Pode ser difícil convencer os clientes que uma abordagem

"evolutiva" é controlável.

• Exige considerável experiência na determinação de riscos e

depende dessa experiência para ter sucesso.


Engenharia de Software Ágil
Aula 2.5. RUP

ANALIA IRIGOYEN
RUP- Rational Unified Process

• Processo de desenv. de SW criado e mantido pela Rational/IBM.

• Baseado no ciclo de vida em espiral (refinamentos sucessivos).

• Baseada em disciplinas.

• Tarefas.

• Responsabilidades.

• Guia para a utilização de UML.

• Desenvolvimento dirigido por Casos de Uso.

• Processo Configurável (customizável).

• Avaliação contínua dos riscos do projeto.

• Geração de produtos interdependentes em todas as interações.


RUP- Rational Unified Process
RUP- Rational Unified Process

• Dimensões:
• Eixo horizontal representa o tempo
• Expressa em termos de fases, iterações e marcos.

• Eixo vertical representa as disciplinas


• Agrupam atividades por natureza.
• Descrito em termos de componentes, disciplinas,
atividades, fluxos de trabalho, artefatos e papéis do
processo
RUP- Rational Unified Process - Características

• Desenvolvimento iterativo-incremental

• Iteração:
• Conjunto de atividades de modelagem de negócios, requisitos, análise e projeto,
implementação, teste e implantação, em várias proporções, dependendo do local
em que ela está localizada no ciclo de desenvolvimento.

• Disciplina:
• Conjunto de atividades relacionadas a uma 'área de interesse' importante em
todo o projeto.
• Papeis:
• O comportamento e as responsabilidades de um indivíduo ou de um conjunto de
indivíduos.
RUP- Rational Unified Process - Características

• Porque desenvolver iterativamente?


• Design inicial contém falhas
• Descoberta tardia de defeitos de design tem grande impacto
• Todo projetos têm riscos
• Quanto mais cedo verificar menor o risco
RUP- Rational Unified Process
RUP- Rational Unified Process

• Uma passagem pelas quatro fases é um ciclo de desenvolvimento;

• Cada passagem pelas quatro fases produz uma geração do


software.
RUP- Rational Unified Process

Concepção Elaboração Construção Transição


 Documento de Visão  Protótipo Arquitetural  Software (componentes)  Incremento de Software
(principais requisitos,  Lista de Riscos (revisada e  Plano de Implantação (Build)
características e restrições) analisada)  Modelo de Implementação  Notas de release
 Casos de Negócio (definidos  Casos de Desenvolvimento (expandido)  Artefatos de instalação
e aprovados)  Ferramentas  Conjunto de testes  Material para treinamento
 Lista de Riscos (identificação (implementados e  Material de suporte ao usuário
 Documento de Arquitetura executados)
inicial) final
 Modelo de Projeto  Materiais de Treinamento  Relatório de Testes (beta)
 Plano de Desenvolvimento de
 Modelo de Dados (manuais de usuário, etc)  Realimentação geral do
Software (fases iniciais)
 Modelo de Implementação  Plano de Iteração (para a fase usuário
 Plano de Iteração (para a de transição concluído)
primeira iteração)  Visão (refinada)
 Modelo de Projeto
 Casos de Desenvolvimento  Plano de desenvolvimento de
 Caso de Desenvolvimento
software
 Ferramentas  Ferramentas
 Plano de Iteração (p/ fase de
 Glossário  Modelo de Dados
construção e transição)
 Modelo de Caso de Uso  Documentos de apoio
 Modelo de Casos de Uso (manuais de usuário,
(identificação de atores e UCs
(80% concluído) instalação)
mais importantes, fluxos de
eventos para casos de uso  Especificações
críticos) Suplementares
 Conjunto de Testes
 Modelo de Análise
Bootcamp
Engenharia de Software Ágil
Fundamentos – Capítulo 3 – Metodologias Ágeis

ANALÍA IRIGOYEN
Engenharia de Software Ágil – Aula 1
Aula 3.1.1. Metodologias Ágeis (Parte 1)

ANALIA IRIGOYEN
Conceitos Ágeis e
Motivação
Conceitos O que TODOS
queremos?
• Aumento da maturidade da organização em
desenvolvimento de processos

• Abordagens mais ágeis com foco em aumento do


valor de negócio para a organização

• Alta Competitividade e Alta Qualidade


http://www.freeimages.com/
Conceitos
Agilidade e os modelos tradicionais de gestão, como
PMBOK

São
É São
possível?
complementares
compatíveis? ?
http://www.freeimages.com/
Conceitos
Os modelos tradicionais de gestão e os
métodos ágeis tem o mesmo objetivo:

O sucesso do projeto.

http://www.freeimages.com/
Motivação
• Como implementar práticas ágeis
aderentes às expectativas dos modelos
tradicionais?

• Como, eventualmente, e quando


necessário, adaptar estas práticas ao
contexto organizacional? http://www.freeimages.com/
Motivação

O objetivo é:

Aumentar o Valor de Negócio da


Organização

http://www.freeimages.com/
Histórico
Anos 90

• XP (Kent Beck e Ron Jeffries);

5 valores, 14 princípios e TDD.

• Scrum (Sutherland, Schwaber, Beedle)

Foco no gerenciamento.

• Crystal (Alistair CockBurn)

Mais flexível que XP.


http://www.freeimages.com/
• Lean (manufatura).
Histórico

Anos 2000

• Divulgação e algumas experiências relatadas.

Anos 2001

• Agile Manifesto

• Agile Alliance
http://www.freeimages.com/
Histórico
-1995
XP - Kent Beck, Ron Jeffries (5
valores, 14 princípios e TDD).
- SCRUM
-2009 CMMi x
-JeddSutherland,Ken Schwaber,Mike
Beedle. SCRUM x XP
- Crystal - Alistair CockBurn (mais -PMBOK x
flexível que XP). SCRUM
- Lean - Manufatura.
- Divulgação
-Algumas
experiências -BOOM
-Manifesto Ágil relatadas -MPS.BR x
-Agile Alliance Agilidade
-Google(?),
Globo..

1995 2001 2007 2009 2010


Histórico
Atualmente

• Google, Yahoo, Borland, Chemtech

• Petrobrás, Spotify, ProMove,......, Uber,

Nuban,..

• Globo – Horizonte

• Caelum e LocalWeb
http://www.freeimages.com/
• Mc Donalds´s
Mitos – Agilidade

• Ambientes ágeis são ad hoc, caóticos e indisciplinados.

• Agilidade significa nenhuma documentação.

• Processos ágeis são imaturos e não são rigorosamente seguidos.


Mitos – Agilidade

• Não funcionam para equipes geograficamente distribuídas.

• Não funcionam com equipes grandes.

• Não funcionam em empresas que não são de software.


Mitos – Modelos Tradicionais

• Modelos de referência exigem documentos inúteis.

• Processos tradicionais são lentos e burocráticos.

• Processos tradicionais só funcionam para projetos grandes em

“cascata”.
Contexto
• Cada equipe é diferente; cada projeto e cada cliente são

diferentes.

• Cada implementação de agilidade deve ser diferente.

• Cada prática descrita deve ser avaliada, levando em conta a

cultura da empesa, a equipe e o contexto do projeto.

• O CONTEXTO IMPORTA SIM !!!


Engenharia de Software Ágil
Aula 3.1.2. Metodologias Ágeis (Parte 2)

ANALIA IRIGOYEN
Manifesto Ágil – Valores
Indivíduos e interações mais que processos e ferramentas.

Trabalhar no software mais que documentação abrangente.

Colaboração do cliente mais que negociação contratual.

Responder às mudanças mais que seguir um plano.


Manifesto Ágil – Princípios

• Aprendizado

• Feedback

• Desenvolvimento iterativo

Métodos Ágeis - Características


Manifesto Ágil – Princípios

Satisfação do cliente em primeiro lugar

Modificações são bem vindas

Entregas frequentes

Clientes juntos aos desenvolvedores

Métodos Ágeis - Características


Manifesto Ágil – Princípios

Equipe constantemente motivada

Conversa face-a-face

Software funcionando

Ritmo constante

Excelência técnica

Métodos Ágeis - Características


Manifesto Ágil – Princípios

Simplicidade: “a arte de maximizar o trabalho não

feito.”

Equipes auto organizadas.

Reflexão de como ser mais efetivo em intervalos

regulares.

Métodos Ágeis - Características


Manifesto Ágil – Princípios

Modelo iterativo ao invés de cascata.

• Redução de riscos

Métodos Ágeis - Características


Manifesto Ágil – Princípios

Tempo fixo ao invés do Escopo fixo.

Manifesto Ágil - Princípios

Métodos Ágeis - Características


Manifesto Ágil – Princípios

Mudanças de requisitos fazem parte!


Custo

Tempo de Projeto

$1 $ 10 $ 100 $ 1.000 $ 10.000


Requisitos Análise Design Implem. Testes

Métodos Ágeis - Características


Manifesto Ágil – Princípios

Melhoria contínua.

• Orientado a pessoas mais que a processos...

Métodos Ágeis - Características


Manifesto Ágil – Princípios

Desenvolvimento em fatias

Métodos Ágeis - Características


Referências bibliográficas

Schwaber, Ken e Sutherland, Jeff - Scrum Guide


Engenharia de Software Ágil
Aula 3.2.1. SCRUM (Parte 1)

ANALIA IRIGOYEN
Definição dos Papéis e Artefatos
Definição

• É um processo iterativo e incremental para o desenvolvimento de qualquer produto

e gerenciamento de qualquer projeto.

• Não é metodologia.

• É um framework. É atitude!
Definição

• É adaptável.

• Promete alta qualidade.

• Promete alta produtividade.


SCRUM – Pilares

• Transparência.

• Inspeção.

• Adaptação.
SCRUM – Pilares

• Transparência

• Tudo que afeta o resultado final deve ser visível para aqueles
que gerenciam os resultados.

• Inspeção

• Adaptação
SCRUM – Pilares

Inspeção

• O processo deve ser inspecionado com uma frequência


suficiente para identificar variações inaceitáveis.

• Cuidado: Inspeções demais podem atrapalhar!


SCRUM – Pilares

Adaptação

• Caso aspectos do processo ou produto


estejam fora dos limites, ajustes devem
ser feitos o mais rápido possível.
SCRUM – Pilares

• Framework baseado em:

• Times de Scrum (Papéis)

• Time-Boxes (Eventos)

• Artefatos

• Regras
SCRUM – Papéis

• Projetados para otimizar flexibilidade e


produtividade.

• Compostos por:

• Product Owner

• Scrum Master

• Team
SCRUM – Papéis
Product Owner
Garante o ROI
Conhece as necessidades do cliente
Scrum Master
Remove os impedimentos do time
Garantir o uso do Scrum
Protege o time de interferências externas
Time
Multi-disciplinar
Auto-gerenciado
Produz com qualidade e valor para o cliente
SCRUM – Scrum Master

• Remover as barreiras entre desenvolvimento e cliente;


• Ensinar a maximização do valor agregado;
• Melhorar o dia-a-dia dos membros do time;
• Combater a ilusão do comando-controle;
• Priorizar os impedimentos e removê-los;
• Facilitar reuniões.
SCRUM – Product Owner

• Mantém os itens do backlog atualizados e priorizados


• Aceita ou rejeita o que foi produzido
• Alta participação no início e no fim do sprint
• Gerenciar os requisitos
• Planejar entregas (releases)
• Disponível para esclarecer dúvidas
SCRUM – Time
• Auto-organizados
• Multidisciplinares
• Máximo 9 integrantes
• Comprometidos
• Responsáveis pelo alcance do objetivo
• Comunicativos
• Responsáveis pela resolução de conflitos
Engenharia de Software Ágil
Aula 3.2.2. SCRUM (Parte 2)

ANALIA IRIGOYEN
SCRUM – Fluxo

Temas,
Pré- Épicos, Testes Aceitação Final Pós-
Product Backlog, Documentação
Game Arquitetura Game
Planejamento da Release.
SCRUM – Fluxo: Descrição

1. Planejamento
Product owner e team decidem quais stories são viáveis de serem movidas do Product
backlog para o Sprint backlog.

2. Sprint
O team deve produzir as stories conforme se comprometeram durante o planejamento
do sprint. O product owner pode estar presente nos “daily scrums” se for realmente o
desejo a obtenção de um status mais detalhado do projeto.
SCRUM – Fluxo: Descrição

3. Review
O time apresenta o trabalho que foi feito neste sprint e verifica a
satisfação do cliente e o valor agregrado que foi atingido.
SCRUM – Artefatos – User
Story

• Uma user story são requisitos elaborados em uma ou duas


frases na linguagem natural do usuário.

• É escrita pelo Product Owner, com ajuda do Scrum Master


e do Team, caso seja necessário.
SCRUM – Artefatos – User
Story

• Assim que as histórias estiverem completas, elas são


inseridas no Product Backlog e priorizadas, pelo Product
Owner (considerando sempre o Valor Agregado).

• Antes de “desenvolver” a Story, os critérios de aceitação


devem ser definidos para garantir que os objetivos da Story
sejam atendidos.
SCRUM – Artefatos – User
Story

• Who (user role) – é um cliente, um colaborador ou o


administrador do Sistema?

• What (goal) – Qual é o objetivo especifico do projeto que


esta funcionalidade vai alcançar (ou ajudar)?

• Why (reason) – Qual o motivo desta Story?


SCRUM – Artefatos – User
Story

• Exemplo:

“Como um usuário autenticado, eu quero entrar no


sistema para que eu possa registrar minhas atividades.”
SCRUM – Artefatos – User
Story
I.N.V.E.S.T
Independent
Negotiable
Valuable
Estimatable
Small
Testable
SCRUM – Artefatos – User
Story
• 1 ou 2 frases em linguagem natural.
• Escrita pelo PO, com ajuda do SM e Team.
• Inseridas e priorizadas no Product Backlog, considerando o Valor
Agregado.
• Cada User Story é quebrada em Tasks (tarefas) que duram no máximo 1
(um) dia.
• Cada Task vira um Post-it.
• Sprint Backlog – Conjunto de tasks de cada uma das stories da Sprint
atual.
Engenharia de Software Ágil
Aula 3.2.3. SCRUM (Parte 3)

ANALIA IRIGOYEN
Planejamento no SCRUM – Aula 3
SCRUM – Planejamento

• Cada story/item de backlog deve ser quebrada em tasks e


duram no máximo um dia.

• Cada task vira um post-it.

• As atribuições de responsabilidade são diárias.

• Sprint Backlog – Conjunto de tasks de cada uma das stories da


Sprint atual.
SCRUM – Quadros
SCRUM – Quadros
SCRUM – Quadros
SCRUM – Quadros
SCRUM – Quadros
SCRUM – Cerimônias
Burndown Chart

24
hrs
Incremento
Product potencialmente
Backlog 2a4 implantável
semanas do produto
Sprint
Backlog

Tasks
Sprint
Planning 1
Meeting

Estimation
Meeting
SCRUM – Cerimônias

• Sprint Planning 1 e Estimation Meeting.


• Selected Backlog (Sprint Backlog) são preenchidos
com os itens de maior prioridade.
• Product Owner propõe alterações.
• Define-se o objetivo da Sprint.
• Participantes: PO, Team, SM.
SCRUM – Cerimônias
Burndown Chart

24
hrs
Incremento
Product potencialmente
Backlog 2a4 implantável
semanas do produto
Sprint
Backlog

Tasks

Sprint Sprint
Planning 1 Planning 2
Meeting Meeting

Estimation
Meeting
SCRUM – Cerimônias

Sprint Planning 2 :

• Definir tarefas a partir das histórias selecionadas.


• Participantes.
• Team + SM.
• PO (opcional).
Autogerenciamento no SCRUM
SCRUM – Cerimônias
Daily
Scrum
Meeting

Burndown Chart

24
hrs
Incremento
Product potencialmente
Backlog 2a4 implantável
semanas do produto
Sprint
Backlog

Sprint Sprint
Sprint
Planning 1 Planning 2
Review
Meeting Meeting
Meeting
Estimation Sprint
Meeting Retrospective
SCRUM – Cerimônias
Daily Scrum Meeting

• Comunicar progresso (status diário)


• Identificar impedimentos
• Manter Foco
• Noção de Time
• Comprometimento Individual

• Participantes:
• Team
• SM (opcional)
SCRUM – Cerimônias
Daily
Scrum
Meeting

Burndown Chart

24
hrs
Incremento
Product potencialmente
Backlog 2a4 implantável
semanas do produto
Sprint
Backlog

Sprint Sprint
Sprint
Planning 1 Planning 2
Review
Meeting Meeting
Meeting
Estimation Sprint
Meeting Retrospective
SCRUM – Cerimônias

Task Board (Quadro)

• To-Do, Doing e Done.

• Conceito do DONE deve ser bem definido e


claro para todos.

• Outros itens (Burn-down Chart,


impedimentos, notícias, limbo, etc.)
Remaining Effort in Hours

5/
3/
2

BDC

100
200
300
400
500
600
700
800
900

0
5/ 00
5/ 2
2
5/ 002
7/
2

752
5/ 00
9/ 2
5/ 200
11 2
5 / /2 0

762
13 02
/
5/ 200

664
15 2
/
5/ 200
17 2
5 / /2 0
Progress

619
19 02
/
5/ 200

Date
21 2

304
5 / /2 0
23 02
/
5/ 200
25 2
/
5/ 20 264
27 02
/
5/ 200 180
29 2
5 / /2 0
31 02
/2
00
2
104
20
SCRUM – Cerimônias
SCRUM – Cerimônias
Melhoria Contínua no SCRUM
SCRUM – Cerimônias

Sprint Review

• Revisar último sprint e andamento global do projeto


• Participantes:
• Team, SM e PO
SCRUM – Cerimônias

Sprint Retrospective:

• Melhoria Continua (rediscutir o processo de desenvolvimento)

• Participantes:

Team, SM
SCRUM – Cerimônias

Sprint Retrospective
• Mini Avaliação 180

Participantes:
• Team, SM
SCRUM – Cerimônias
SCRUM – Lições Aprendidas

• Times pequenos;
• Objetivos claros;
• Product Owners conhecedores do negócio;
• Scrum Masters influentes na organização;
• Garantia da disponibilidade dos recursos;
• Auto-gerenciamento fluente;
• Práticas de Engenharia de Software presentes (Arquitetura, Gerência de
Configuração, Verificação, Validação).
Engenharia de Software Ágil
Aula 3.3. Kanban

ANALIA IRIGOYEN
Definição dos Papéis
Mitos e fatos

• O KANBAN e SCRUM são opostos.

• O SCRUM usa KANBAN, é possível usar os dois.


Mitos e fatos

• O KANBAN é vítima da Lei de Parkinson (o trabalho se


expande..).

• É uma preocupação válida, mas como estamos sempre


medindo (cycle time, feedback curto, entregas contínuas),
mantém o foco no controle.
Mitos e fatos

• Não existe o time box.

• Não tem esta exigência, mas devem ser utilizados sempre que
o fluxo for otimizado.
Mitos e fatos

• Não existe estimativa

• Não tem esta exigência, devem ser utilizadas sempre que


apropriadas.
Mitos e fatos

• O KANBAN substitui outras metodologias (KANBAN, Crystal,


XP, FDD).

• O KANBAN pode ser utilizado com todas estas tecnologias e


não substitui o SCRUM, por exemplo.
Definição dos papéis

• Defina seus papéis.

• Respeite o processos atual e seus papéis,


responsabilidades e cargos.

• Kanban usa conceito Kaizen (melhoria contínua).

• Mude devagar e sempre.


O Fluxo
O Fluxo

• Passo 1 – Visualizar o Fluxo de Trabalho:

• Mapear todo o fluxo de trabalho para realizar a entrega de


um serviço ou projeto – Ciclo de Vida.

• Mapear a Cadeia de Valor.


O Fluxo

Fonte: Site da AdaptWorks


O Fluxo
Visualizar o sistema de
entregas
O Fluxo

Fonte: Site da AdaptWorks


Buffer Stage
O Fluxo

• Deve:

• Focar no “todo”.

• Gerar transparência.

• Identificação de desperdícios.
O Planejamento
O planejamento

• Passo 2 – Limitar o trabalho em progresso:

• WIP (Work in Progress).

• Lead Time – Desde a chegada até entrega.

• Tempo de Ciclo – Desde a seleção até a entrega.


O planejamento
O planejamento

• A definição do WIP (pequeno motiva o sistema puxado):

• Terminar mais do que começar.

• O desconforto é por impedimento.

• Quebrar tarefas.
O planejamento
Se o WIP fosse 2

Fonte: Site da AdaptWorks


O planejamento

• Passo 3 – Estabelecer política de qualidade:

• Poka Yoke (Pocá ioquê): evitar que erros sejam


realizados – incluindo, por exemplo, fluxos e regras
automatizados.

• Padrões e Checklists antes de completar as tarefas.

• Analisar cada defeito (Stop the line, conceito lean para


prevenir).
O planejamento

Jesper Boeg, Kanban em 10 pessoas, Otimizando o fluxo de trabalho em sistemas de


entrega de software, InfoQ Brasil
O planejamento

• Obter comprometimento com a política e melhoria contínua do


processo.
Autogerenciamento e execução
Execução

• Passo 4 – Ajustar as cadências (sequência, ritmo, sucessão


regular):

• Custos associados a entregas de um produto ou serviço.

• Custo de espera – Espera da aprovação, planejamento,


qualidade, verificação, por exemplo.

• Este custos prejudicam o feedback.


Execução
Execução

• Passo 5 – Medir o Fluxo:

• Diagrama de Fluxo Cumulativo.

• Tempo de Ciclo.

• Índice de Defeitos.

• Itens Bloqueados.
Execução
Execução

• Diagrama de Fluxo Cumulativo.

• Se a distância entre duas linhas em progresso aumentarem: sinal de


gargalo.

• Se a linha de backlog estiver mais inclinada que a linha do done,


está entrando mais coisas que podemos entregar.

• Pode medir tempo médio de ciclo e quantidade de itens na fila.


Execução – tempo de ciclo

• Tempo de Ciclo individual.

• Registrar Data de Início.

• Registrar Data de Entrega.


Execução – tempo de ciclo

• Tempo de Ciclo individual.

• Os números indicam consistência?

• Registrar Data de Entrega.

• Como está a tendência.

• É possível analisar Outliers.

• Calcular data de entrega (90% entregues em 1 semana).


Execução – defeitos

• Índice de defeito.

• Por que o número de novos defeitos tem aumentado?

• Como o índice alto de defeitos afetou o tempo do ciclo?


Execução – tempo de ciclo

• Índice de defeito.
• Defina Metas.
Execução – itens
bloqueantes

• Itens bloqueantes:

Jesper Boeg, Kanban em 10 pessoas, Otimizando o fluxo de trabalho em sistemas de entrega de software, InfoQ Brasil
Execução – itens
bloqueantes

• Itens bloqueantes:
Execução – priorização

• Passo 6 – Priorização:

• Custo de Atraso: a maior prioridade deve ser o item com


mais alto item de atraso ou mais complexo.

• O mais prioritário é o que está mais acima.


Execução – priorização

Jesper Boeg, Kanban em 10 pessoas, Otimizando o fluxo de trabalho em sistemas de entrega de software, InfoQ Brasil
Execução – priorização

• Passo 6 – Priorização:

• Levar em consideração quando fizer a priorização:

• Maior risco e incerteza.

• Necessidades básicas (infraestrutura).

• Tamanho equilibrado.

• Tipo de estória equilibrado.

• Dependências.
Execução – classes de
serviço
• Passo 7 – Identificação de Classes de Serviço.

• Tipos de Trabalho:

• Histórias.

• Defeitos.

• Relatórios Manuais.

• Tarefas de Suporte.

• Instalação.
Execução – classes de
serviço
• Passo 7 – Identificação de Classes de Serviço

• Classes de Serviço

• Classe Padrão: Defeitos Cosméticos, Estórias

• Classe Prioritária: Defeitos Críticos, estórias de Alta


Prioridade

• Classe de Prazo Fixo: Estórias, tem prioridade se o prazo


estiver próximo

• Classe Urgente: Defeito impeditivo, rompe limites do WIP


Execução – classes de
serviço

Jesper Boeg, Kanban em 10 pessoas, Otimizando o fluxo de trabalho em sistemas de entrega de software, InfoQ Brasil
Execução – Fluxo

• Passo 8 – Gerenciamento do Fluxo.

• Filtro de Decisões Agile:

• Estamos obtendo progresso?

• Estamos encorajando a cultura baseada em


confiança?

• Estamos tratando o WIP como risco e não como um


ativo?
Execução – Fluxo

• Passo 8 – Gerenciamento do Fluxo.

• Filtro de Decisões Lean:

• O valor é mais importante que o fluxo.

• O fluxo é mais importante que eliminação de


desperdícios.

• Elimine desperdícios para melhorar a eficiência.

• Alivie Gargalos.

• Introduza Buffers.
Execução – Fluxo

• Passo 8 – Gerenciamento do Fluxo:

• Planeje entregas.

• Otimize o Fluxo.

• Experimente.
Execução – SLA

• Passo 9 – Estabeleça SLA

• Considera a base
histórica

• Deixe visível

Jesper Boeg, Kanban em 10 pessoas, Otimizando o fluxo de trabalho em sistemas de entrega de software, InfoQ Brasil
Melhoria Contínua

• Passo 10 – Melhoria Contínua:

• Mude.

• Experimente.

• Ajuste os WIPS.

• Ajuste o Quadro.

• Aumente a Visibilidade.
Referências

Jesper Boeg, Kanban em 10 pessoas, Otimizando o fluxo de trabalho em


sistemas de entrega de software, InfoQ Brasil

Foggetti, Cristiano - Gestão Ágil de Projetos - São Paulo: Education do


Brasil, 2014.

Schwaber, Ken e Sutherland, Jeff - Scrum Guide


Engenharia de Software Ágil
Aula 3.4. Fundamentos do Scrumban

ANALIA IRIGOYEN
Definições

Simon Bennett Fonte: InfoQ SCrumBan-Evolução ou Contradição


Definições

• Progressos ainda mais rápidos

• Kanban:

• é uma evolução.

• Scrum:

• é uma revolução.
Simon Bennett Fonte: InfoQ SCrumBan-Evolução ou Contradição
Vantagens

• Qualidade.

• Inspeções.

• Análise de causas de problemas/defeitos.

• Diminui o desperdício;
SCRUMBAN

Fonte: https://agilewheel.com/tag/scrumban/
SCRUMBAN - Planejamento

• Use os papéis do SCRUM.


• Mudanças fazem parte do escopo.
• Sistema puxado.
• Planeje pequenas iterações de planejamento (todos os
dias).

• Crie outros papéis.


SCRUMBAN - Planejamento

• Aumente o quadro, inclua raias de atividades e buffer.

• Não indique o nome das pessoas nos cartões.

• Limite o Backlog (WIP) – Use regras de priorização.


SCRUMBAN –
Monitoramento e execução

• Ache os bloqueadores do fluxo analisando os WIPs,


Diagrama de Fluxo Cumulativo.

• Utilize métricas de Tempo de Ciclo.


• Repriorize diariamente.
• Faça reuniões do tipo Short Kaizen:
• Stop the line, follow-up, planning
SCRUMBAN –
Melhoria contínua

• Use Restrospectiva (SCRUM).

• Use Reviews, se necessário.

• Analise a causas dos defeitos ao longo.


Engenharia de Software Ágil
Aula 3.5. Fundamentos do XP

ANALIA IRIGOYEN
XP • Desenvolvida para:

• Equipes médias e pequenas (2 a 12 pessoas).

• Projetos com requisitos vagos e em constante evolução.

• A codificação é a atividade principal.

• Características:

• Revisão permanente do código,

• Testes frequentes,

• Participação do usuário final,

• Refatoramento contínuo,

• Integração contínua,

• Planejamento, design e redesign a qualquer hora.


XP

• Valores:

• Comunicação

• Simplicidade

• Feedback

• Coragem
XP
• Comunicação:

• Usa-se o melhor meio possível para comunicação, formal ou


não.

• Preferência à comunicação mais ágil:

• Telefonema é melhor do que e-mail.

• Presença física é melhor do que comunicação remota.

• Usa-se a comunicação com as respostas mais rápidas


possíveis.
XP
• Simplicidade:

• Incentivo a práticas que reduzam a complexidade do sistema.

• Solução deve ser sempre a mais simples para se alcançar os


objetivos esperados:

• Tecnologias, design, algoritmos e técnicas mais simples.

• Design, processo e código podem ser simplificados a


qualquer momento.

• Não pensar em iterações futuras.


XP
• Feedback:

• Feedback sobre qualidade do código:

• testes de unidade, programação em pares, posse coletiva.

• Feedback sobre estado do desenvolvimento:

• estórias do usuário final, integração contínua, jogo do planejamento.

• Permite maior agilidade:

• Erros detectados e corrigidos imediatamente.

• Requisitos e prazos reavaliados mais cedo.

• Permite estimativas mais precisas.

• Maior segurança e menos riscos para investidores.


XP
• Coragem:

• Práticas do XP aumentam a confiança do programador coragem para:

• Melhorar o design de código que está funcionando para torná-lo mais


simples.

• Jogar fora o código desnecessário.

• Investir tempo no desenvolvimento de testes.

• Mexer no design em estágio avançado do projeto.

• Pedir ajudar aos que sabem mais.

• Dizer ao cliente que um requisito não vai ser implementado no prazo


prometido.

• Abandonar processos formais e fazer design e documentação em


forma de código.
XP
Extreme Programming

Aplicação das boas práticas de Foca em Código

desenvolvimento de software
levadas ao extremo
Bootcamp
Engenharia de Software - Métodos Ágeis
Fundamentos – Capítulo 4 - Implantação Azure DevOps - Agile

ANALÍA IRIGOYEN
Engenharia de Software
Aula 4.1. Azure DevOps - Agile

ANALIA IRIGOYEN
Azure DevOps

Pré- Temas, Testes Aceitação Final Pós-


Game
Épicos, Documentação Game
Product Backlog,
Arquitetura
Planejamento da Release.
Azure DevOps – Agile
Azure DevOps – Agile

Marcos
do
Projeto Capacidades
do software

História do Usuário
do backlog/no Correção de defeitos em
Sprint desenvolvimento ou
Menor unidade produção
desenvolvimento
Ágil
Impedimentos do Sprint
Azure DevOps
Visão
Geral do
Projeto

Controle do
Projeto com
Kanban e
Dashbooards
Repositório
de arquivos
do projeto
Controle de
CI/CD em
Toda gestão
cloud
de testes e
testes
Gestão de exploratórios
pacotes
nuget/npm e
Azure DevOps

Criação de
Projetos
Azure DevOps
Engenharia de Software
Aula 4.2.1. Case Prático – Azure (Parte 1)

ANALIA IRIGOYEN
Engenharia de Software
Aula 4.2.2. Case Prático – Azure (Parte 2)

ANALIA IRIGOYEN
Engenharia de Software
Aula 4.2.3. Case Prático – Azure (Parte 3)

ANALIA IRIGOYEN
Engenharia de Software
Aula 4.2.4. Case Prático – Azure (Parte 4)

ANALIA IRIGOYEN
Engenharia de Software
Aula 4.3. Case Prático – Trello

ANALIA IRIGOYEN
Trello
Kanban
Trello
Vamos usar:

https://trello.com/b/5FldI0TK/template-kanban

 Diferença dos Quadros Kanban (customizado) e SCRUM (to-do, doing, done)

 Comunicação no Trello.

 A utilização dos checklists e funções básicas do trello

 Indicadores mais utilizados no Kanban e como os Power-Ups podem ajudar (Corello, por exemplo)
Bootcamp
Engenharia de Software Ágil
Fundamentos – Capítulo 5 – Introdução ao DevOps

ANALÍA IRIGOYEN
Engenharia de Software Ágil
Aula 5.1. Introdução ao DevOps

ANALIA IRIGOYEN
Introdução ao DevOps

 Motivação
 Por que DevOps?

 Introdução ao DevOps

 O que é DevOps Calms

 Princípio das 3 maneiras


Por que DevOps?

256
Por que DevOps?
Falhas inaceitáveis

• Milhões de • Dados dos

Hospital NHS - 2018


HSBC - 2016

Vazados 988 mil arquivos -2019


• Falha de
clientes sem pacientes cartórios
acesso a inacessíveis expõe dados
conta por 2 de ao menos
dias 1 milhão de
pais, mães e
filhos...

https://computerworld.com.br/2018/07/12/10-grandes-falhas-da-tecnologia-nos-ultimos-anos/
ultimas-noticias/2019/10/29/falha-de-cartorios-expoe-dados-de-ao-menos-1-milhao-de-pais-maes-e-filhos.htm?cmpid=copiaecola
Por que DevOps?

“Código mal escrito” gera perdas de US$ 85


bi por ano às empresas

40% do tempo das Estudo com mil


equipes dedicado para Desenvolvedores e mil
correções executivos C-level

https://www.itforum365.com.br/carreira/codigo-mal-escrito-gera-perdas-de-us-85-bi-por-ano-as-empresas/
Por que DevOps?

Mindset aceitável no passado Mindset digital exige DevOps


Filas no checkin para embarcar Checkin via app
Blockbuster multa por atraso Netflix entrega vídeo sob demanda
TV domina conteúdo e audiência Netflix domina conteúdo e audiência
Guia 4 rodas para viagem Google compra Waze por U$ 1 Bi
Momento kodak em papel Facebook compra instagram por U$ 1 Bi
Comunicação por email Facebook compra WhatsApp por U$ 22 Bi
Filas para transações bancárias Transações na palma da mão
Filas no orelhão Qtd de celular supera qtd de pessoas
Táxi acessível para poucos Uber acessível para muitos
Anúncio caro: TV, jornal e revista Domínio do Google e mídias sociais
Reembolso médico em papel Reembolso digital e ágil
Linear e analógico Exponencial e digital

Livro Jornada DevOps: MUNIZ; SANTOS; IRIGOYEN; MOUTINHO (Brasport, 2019)


Por que DevOps?
Modelo tradicional Cultura DevOps
Cultura do medo e grito Confiança e experimentação
Causa da falha foi o fulano Resolvemos a falha sistêmica
Competição entre departamentos Colaboração multidisciplinar
Cada um no seu quadrado Visão mais horizontal
Teste manual no final Teste automatizado na origem
Merge complexo e demorado Integração em lotes pequenos
Tudo funciona na minha máquina Ambiente similar de produção
Implantação manual Implantação automatizada
Implantação demorada Implantação contínua
Big bang Teste A/B
Acho que o problema foi xxx Fatos e dados com telemetria

Livro Jornada DevOps: MUNIZ; SANTOS; IRIGOYEN; MOUTINHO (Brasport, 2019)


Introdução e adoção do Devops – Conceitos Básicos

Livro Jornada DevOps: MUNIZ; SANTOS; IRIGOYEN; MOUTINHO


(Brasport, 2019)
Introdução e adoção do Devops – Conceitos Básicos

# JUNTOS

Livro Jornada DevOps: MUNIZ; SANTOS; IRIGOYEN; MOUTINHO


(Brasport, 2019)
Introdução e adoção do Devops – Conceitos Básicos

Indivíduos e interações mais que processos e ferramentas.


Trabalhar no software mais que documentação abrangente.
Colaboração do cliente mais que negociação contratual.
Responder às mudanças mais que seguir um plano.
Introdução e adoção do Devops – Conceitos Básicos

AUDITORIAS
Quer
garantir
qualidade
Introdução e adoção do Devops – Conceitos Básicos

265
http://jornadaparanuvem.com.br/interessante-tabela-periodica-da-xebialabs/
Introdução e adoção do Devops – Conceitos Básicos

A má implementação ou excesso
de customização pode destruir
uma ótima ferramenta…

Incentive a opinião das equipes


no chão de fábrica!
Vá ao gemba !
Introdução e adoção do Devops – Conceitos Básicos

NÃO EXISTEM MAIS TESTES MANUAIS


O CÓDIGO SÓ VAI PARA PRODUÇÃO SE ESTIVER COM ALTA QUALIDADE, VALIDADO
AUTOMATICAMENTE
NINGUÉM TEM ACESSO ÀS MÁQUINAS DE PRODUÇÃO
TODA INSTALAÇÃO É AUTOMATIZADA
OS DESENVOLVEDORES POSSUEM UM AMBIENTE IDÊNTICO AO PRODUÇÃO EM SUAS MÁQUINAS
LOCAIS
OS ANALISTAS DE INFRAESTRUTURA SE TORNAM DESENVOLVEDORES DE CÓDIGO
OS DESENVOLVEDORES SE TORNAM ANALISTAS DE INFRAESTRUTURA
TODOS TEM VISIBILIDADE POR TODO O AMBIENTE
NÃO EXISTEM BARREIRAS ENTRE EQUIPES DE TI, TODOS SÃO DESENVOLVEDORES DE PROJETOS
NINGUÉM TEM CULPA POR UM ERRO DE PRODUÇÃO
TODO O AMBIENTE DE PRODUÇÃO É RECONSTRUÍDO EM MINUTOS
ESCALONAMENTO DE AMBIENTE É FEITO EM MINUTOS
Introdução e adoção do Devops – Conceitos Básicos

Benefício

Aumento da frequência de deployments Cógido sempre entregável


Aumento da colaboração entre departamentos Visibilidade do Pipeline
Redução de tempo construindo e mantendo Sistema sempre validado
aplicações
Aumento de qualidade e performance de aplicações Arquitetura orientada a
padrões
Redução do “time-to-market” Equipes trabalhando de
forma igual
Redução de custos de desenvolvimento Desenvolvimento otimizado
Redução de pessoas trabalhando no processo de Deploy contínuo
deploy
Paralelização de desenvolvimento Separação do
desenvolvimento
Facilidade na realocação de recursos entre projetos Projetos padrões
Redução do tempo de treinamento de novos Ambientes prontos
funcionários
.... entre outros ...
Introdução e adoção do Devops – Conceitos Básicos

269
Livro Jornada DevOps: MUNIZ; SANTOS; IRIGOYEN; MOUTINHO (Brasport,
2019)
Introdução e adoção do Devops – Conceitos Básicos
Introdução e adoção do Devops – Conceitos Básicos

KANBAN – Produção Puxada

WIP
Livro Jornada Ágil Digital: MUNIZ; IRIGOYEN (Brasport, 2019)
Introdução e adoção do Devops – Conceitos Básicos

Framework Cynefin

• CFD
• Dependências externas ao time - Gargalo
• Eficiência do Fluxo
• Leadtime (Lembrar do ponto de compromisso)
• Tamanho dos itens (P/M/G)
• Touch time (tempo que eu levo efetivamente
desenvolvendo
• WIP (Lei do Little – limitar tarefas em andamento)
• Waiting time (tempo de espera)

Livro Jornada Ágil Digital: MUNIZ; IRIGOYEN (Brasport, 2019)


Introdução e adoção do Devops – Conceitos Básicos
Dívida técnica (Débito técnico)

✓ Representa o resultado das decisões do curto prazo que


geram problemas que se tornam cada vez mais difíceis de
resolver com o passar do tempo

✓ Reduz a performance da equipe e aumenta o TCO

✓ Os objetivos conflitantes das áreas Dev e Ops contribuem


para o aumento do débito técnico

Livro Jornada DevOps: MUNIZ; SANTOS; IRIGOYEN; MOUTINHO (Brasport, 2019)


Introdução e adoção do Devops – Conceitos Básicos

Algumas causas da dívida técnica


✓ Ausência de testes

✓ Requisitos não claros

✓ Documentação pobre

✓ Pouco foco em refatoração

✓ Equipes não colaborativas

✓ Conflitos de interesse

✓ Pressão de chefes e áreas de negócio


Engenharia de Software Ágil
Aula 5.2. Princípios das 3 Maneiras

ANALIA IRIGOYEN
Introdução e adoção do Devops – Conceitos Básicos

Princípios Lean
Fluxo de valor: É o processo que concretiza uma
necessidade de negócio em um produto ou serviço Gemba: É o local onde as coisas acontecem e
para entrega de valor ao cliente. todos deveriam ir ao gemba com frequência para
conhecer o “chão de fábrica” e evitar suposições
Mapeamento do fluxo de valor: Visa entender sem dados e fatos.
como o processo funciona com foco na entrega de
valor ao cliente e identifica gargalos ou Obeya: Também conhecida nas organizações como
desperdícios. “sala de guerra”, o objetivo é facilitar a gestão visual
e a coordenação para solução de problemas sem
os entraves das estruturas organizações clássicas.

Livro Jornada DevOps: MUNIZ; SANTOS; IRIGOYEN; MOUTINHO (Brasport, 2019)


Introdução e adoção do Devops – Conceitos Básicos

Desperdício
Existem 8 tipos de desperdícios identificados no Lean:
 Defeito e retrabalho: Desfazer, refazer algo.
 Movimentação: Caminhadas, deslocamentos, viagens.
 Espera: Pessoas aguardando informações, materiais ou Corda de Andon: Dispositivo que existe nas

outras equipes. fábricas da Toyota para interromper a linha de

 Transporte: Transferências desnecessárias de materiais produção quando é encontrado algum defeito nos

ou informações. produtos. O objetivo é aglomerar imediatamente

 Estoques: Informações ou materiais sem uso. todas as equipes e líderes que podem ajudar a

 Processamento: Etapa redundante ou desnecessária. resolver o problema na origem, podendo mobilizar

 Desconexão ou superprodução: Fluxo deficiente ou falta os executivos e a alta administração.

de sincronismo entre etapas (antes ou depois do


necessário).
 Conhecimento: Não aproveitar as habilidades das
pessoas adequadamente.
Livro Jornada DevOps: MUNIZ; SANTOS; IRIGOYEN; MOUTINHO (Brasport, 2019)
277
Princípios das 3 maneiras

Livro Jornada DevOps: MUNIZ; SANTOS; IRIGOYEN; MOUTINHO (Brasport, 2019)


Princípios das 3 maneiras

Livro Jornada DevOps: MUNIZ; SANTOS; IRIGOYEN; MOUTINHO (Brasport, 2019)


Princípios das 3 maneiras

Livro Jornada DevOps: MUNIZ; SANTOS; IRIGOYEN; MOUTINHO (Brasport, 2019)


Princípios das 3 maneiras – Diferença para o
DevOps

Sistemas de registro e engajamento


Sistema Tipo Bimodal (Gartner) Ritmo de mudanças

Registro Tipo 1: Fazer direito com foco Mais lento e costuma ter requisitos
em estabilidade e confiabilidade normativos e conformidade

Engajamento Tipo 2: Fazer rápido com foco Mais rápido e permite experimentos
em flexibilidade e inovação em ambientes incertos

Livro Jornada DevOps: MUNIZ; SANTOS; IRIGOYEN; MOUTINHO (Brasport, 2019)


281
Organização Papéis DevOps
Papel Responsabilidades

Dono do Produto A voz interna da empresa que define as funcionalidades

Desenvolvimento Criar as funcionalidades dos aplicativos

QA Realiza loops de feedback para garantir qualidade

Operações Manter o ambiente de produção e alcance do SLA

Segurança Manter a segurança de sistemas e dados

Gerente de release Administrar e coordenar a implantação em produção

Gerente fluxo Garantir que alcance os requisitos do cliente

Livro Jornada DevOps: MUNIZ; SANTOS; IRIGOYEN; MOUTINHO (Brasport, 2019)


Organização

Lei de Conway: O design do sistema sempre é uma cópia da estrutura de


comunicação da organização

Tipo de Estrutura Características Resultados

Organizações Pouca colaboração e Sistemas centralizados, processos


hierarquizadas, comando e comunicação ineficaz engessados e lentidão de resposta
controle ao mercado e clientes

Organizações flexíveis e Forte colaboração e Sistemas modulares, fluxo de


equipes com grande objetivos valor efetivo e adaptabilidade
autonomia compartilhados para atender mercado e clientes

Livro Jornada DevOps: MUNIZ; SANTOS; IRIGOYEN; MOUTINHO (Brasport, 2019)


283
Organização

Etapas para a Transformação DevOps


Etapa Características importantes

1. Equipe Coloque em um espaço físico separado os melhores generalistas que


dedicada tenham uma relação respeitosa e de longa data

2. Meta SMART Equipes tem autonomia para combinar meta compartilhada

3. Sprints curtos Entregas constantes e adaptabilidade do plano

4. Requisitos não Reservar pelo menos 20% do ciclo de melhoria para reduzir a dívida
funcionais técnica

5. Visibilidade Disponibilizar informação atual com evolução das melhorias

6. Ferramentas Backlog unificado entre todas as equipes gera mais empatia

Livro Jornada DevOps: MUNIZ; SANTOS; IRIGOYEN; MOUTINHO (Brasport, 2019)


284
Organização

Livro Jornada DevOps: MUNIZ; SANTOS; IRIGOYEN; MOUTINHO (Brasport, 2019)


285
Organização

Integrando Ops no trabalho diário de Dev

✓ Participar das reuniões diárias: O que foi feito


ontem, o que será feito hoje e os impedimentos

✓ Participar da retrospectiva para aumentar


aprendizado: O que teve êxito, o que pode melhorar
e como aplicar as lições nos próximos sprints

✓ Deixar visível o trabalho de Ops necessário para


que a aplicação funcione em produção

Livro Jornada DevOps: MUNIZ; SANTOS; IRIGOYEN; MOUTINHO (Brasport, 2019)


286
Engenharia de Software Ágil
Aula 5.3. Conceitos de Arquitetura Lean

ANALIA IRIGOYEN
Conceitos de Arquitetura Lean

• Arquitetura Mínima Viável


• Implantação Contínua
• Iteração 0 (zero)
• Squad de Produto
• As três maneiras

Paulo Caroli and Alexandre Corrêa Barbosa - Lean Software Engineering


288
Arquitetura Mínima Viável

Paulo Caroli and Alexandre Corrêa Barbosa - Lean Software Engineering

289
Implantação contínua

Paulo Caroli and Alexandre Corrêa Barbosa - Lean Software Engineering

290
Iteração 0 (zero)

Paulo Caroli and Alexandre Corrêa Barbosa - Lean Software Engineering

291
Squad de Produto

Paulo Caroli and Alexandre Corrêa Barbosa - Lean Software Engineering

292
As três maneiras

Paulo Caroli and Alexandre Corrêa Barbosa - Lean Software Engineering

293
Engenharia de Software Ágil
Aula 5.4. Disciplined Agile (DA)

ANALIA IRIGOYEN
Disciplined Agile (DA)

Tradicional Ágil

• PMBOK Guide, CMMi v 2.0 e


normas incluem/estão incluindo
conteúdo Agile
https://www.pmi.org/disciplined-agile/lifecycle/agile-lifecycle
Disciplined Agile (DA)

• Toolkit para ajudar na tomada de decisões junto aos times,


considerando o contexto

Esta Foto de Autor Desconhecido está


licenciado em CC BY-SA-NC
https://www.pmi.org/disciplined-agile/lifecycle/agile-lifecycle
Que atividades são essas?

• DAD – Soluções para entregas, prevê vários ciclos de vida


(baseados no Scrum, Kanban, entrega contínua ou não)

• DevOps – Soluções de tecnologia para desenvolvimento e


operação

• DAIT – Inclui atividades como: arquitetura corporativa, gerência


de dados, portfolio e governança de TI.

• DAE – Habilidade para mudança e adaptação, uma organização


que aprende com a estrutura adequada (Cultura + Aprendizado
+ Adaptação + Times decidem)
Que atividades são essas?

https://www.pmi.org/disciplined-agile/lifecycle/agile-lifecycle
As 4 visões do DA

https://www.pmi.org/disciplined-agile/lifecycle/agile-lifecycle
Princípios

https://www.pmi.org/disciplined-agile/lifecycle/agile-lifecycle (traduzido)
Principais papéis

Líder do Time

“Dono” do Produto

“Dono” da Arquitetura

Membro do Time

Stakeholder

https://www.pmi.org/disciplined-agile/lifecycle/agile-lifecycle (traduzido)
Papéis Suporte

Líder do Time

Tester (independente)

Especialista

Expert em algum domínio

Expert Técnico

Integrador

https://www.pmi.org/disciplined-agile/lifecycle/agile-lifecycle (traduzido)
Times de projeto x Times estáveis

Projeto: trazer time


para o trabalho

Projeto: Projeto: eventos de


Produto: trazer motivação/integração
potencialmente prazo
trabalho para o time com quem está
e custos ultrapassados
disponível
Produto: o
orçamento é direto Produto: motivação do
Projeto: focos curtos aprendizado e o modo
motivam “atalhos” na como o time trabalha
qualidade (WoW)
Produto: foco em ações de
longo prazo: sustentação,
qualidade e evolução

https://www.pmi.org/disciplined-agile/lifecycle/agile-lifecycle (traduzido)
Times escolhem seu próprio ciclo de vida

Continuous
Agile Delivery: Agile Exploratory

Lean Continuous Program


Delivery: Lean
https://www.pmi.org/disciplined-agile/lifecycle/agile-lifecycle (traduzido)
Times escolhem seu próprio ciclo de vida

Continuous
Agile Delivery: Agile Exploratory

Lean Continuous Program


Delivery: Lean
https://www.pmi.org/disciplined-agile/lifecycle/agile-lifecycle (traduzido)
Agile (baseado no SCRUM)
Quando usar Agile Scrum?

O trabalho pode ser


O trabalho consiste em Uma boa escolha
identificado, priorizado e
melhorias ou novas quando temos novas
estimado no início do
funcionalidades equipes ágeis
projeto

A equipe está A equipe normalmente


familiarizada com Scrum está trabalhando em um
e XP projeto
Entrega contínua: Agile

https://www.pmi.org/disciplined-agile/lifecycle/agile-lifecycle
Quando usar entrega contínua: Agile

•Projetos que
•Soluções que podem
•O trabalho precisam entregar
ser entregues às
permanece valor rapidamente,
partes interessadas de
relativamente estável antes que toda a
forma frequente e
em uma iteração solução esteja
incremental
concluída.

•As equipes têm


práticas DevOps
•Organizações possui
maduras em vigor,
práticas e
incluindo integração
procedimentos de
contínua, implantação
implantação
contínua e teste de
simplificados
regressão
automatizado

https://www.pmi.org/disciplined-agile/lifecycle/agile-lifecycle
Lean (baseado no Kanban)

https://www.pmi.org/disciplined-agile/lifecycle/agile-lifecycle
Quando usar Lean?

O trabalho pode ser dividido em A equipe favorece a abordagem


itens de trabalho muito enxuta de minimizar o tamanho
pequenos de aproximadamente do lote (o que ajuda a reduzir o
o mesmo tamanho trabalho em andamento) e
qualquer planejamento antes da
execução do trabalho

O trabalho é difícil de prever com


antecedência. Por exemplo,
equipes que corrigem defeitos ou A equipe normalmente está trabalhando
lidam SLAs (serviços de suporte) em um projeto
são bons candidatos para este
ciclo de vida

https://www.pmi.org/disciplined-agile/lifecycle/agile-lifecycle
Entrega Contínua: Lean

https://www.pmi.org/disciplined-agile/lifecycle/agile-lifecycle
Quando usar Entrega contínua: Lean?

Soluções podem ser entregues Organização possui práticas e


às partes interessadas de forma procedimentos de implantação
frequente e incremental simplificados

Equipes com práticas de DevOps maduras,


Novos trabalhos/serviços incluindo; integração contínua,
implantação contínua e teste de regressão
chegam frequentemente
automatizado

https://www.pmi.org/disciplined-agile/lifecycle/agile-lifecycle
Exploratório (Lean Startup)

https://www.pmi.org/disciplined-agile/lifecycle/agile-lifecycle
Quando usar Exploratório (Lean Startup)

As partes interessadas e a
A solução aborda casos de
equipe de entrega são muito
alta incerteza, como um novo
flexíveis na adaptação da
mercado inexplorado ou um
solução à medida que ela
novo produto
está sendo desenvolvida
Você tem uma ou mais
hipóteses/ estratégias válidas Você está disposto a experimentar e
para testar com critérios claros desenvolver sua ideia com base em
vai/ não vai para quando o teste seus aprendizados
terminar

https://www.pmi.org/disciplined-agile/lifecycle/agile-lifecycle
Programa (Program Teams)

https://www.pmi.org/disciplined-agile/lifecycle/agile-lifecycle
Programa (Program Teams)

Você precisa de uma grande equipe de


equipes. Alguns problemas exigem uma
grande equipe e, em alguns casos, você
pode até decidir organizar essa grande
equipe em uma equipe de equipes.

Você tem as habilidades


para agir com agilidade em
grande escala.

https://www.pmi.org/disciplined-agile/lifecycle/agile-lifecycle
A escolha do Ciclo de Vida (DA)

Você também pode gostar