1.
Entregando Software
com “Valor”
Maicon Carlos Pereira

2.
Maicon Carlos Pereira
• Graduado em Ciência da Computação
• MBA em Gerenciamento de Projetos
• + 12 anos desenvolvendo software

3.
Objetivos

4.
Ciclos de Vida de um
projeto

5.
Cascata
Início
do Projeto
Término
do Projeto
planejamento acontece no início e a execução ocorrendo
em uma única vez, num processo sequencial.

6.
Estudo
Análise
Projeto
Execução
Testes
Implantação
Cascata - Waterfall

7.
Incremental
fornece entregáveis finalizados que o cliente poderá usar
imediatamente
Início
do Projeto
Término
do Projeto

8.
Iterativo
permite o feedback sobre trabalho inacabado através de
protótipos para melhorar o produto final
Início
do Projeto
Término
do Projeto

9.
Ágil – Iterativo e Incremental
Feedback e entregas frequentes.
Início
do Projeto
Término
do Projeto

10.
Ágil ou Cascata?

11.
Funciona?

12.
Em produção de produto, carro, eletrodoméstico...
Onde os procedimentos Claros.
Um projeto passado é de fácil reprodução e sucesso
Funciona?

13.
Resumindo,
Cascata no desenvolvimento de software, Funciona?

14.
Por que não funciona?
• Desenvolver software é um processo criativo
• É um processo artesanal
• É um processo empírico (o conhecimento vem da experiência)
• Exige pesquisa
• ...

15.
E como se faz??

16.
Metodologia Ágil

17.
Manifesto Ágil
 Desenvolvedores e consultores de software se juntaram
para compartilhar valores e princípios que eram utilizados
em suas práticas
 Agile Software Development Alliance
Ward
Cunningham
2001
Robert C.
Martin
...

18.
Manifesto Ágil
Estamos descobrindo maneiras melhores de desenvolver
software, fazendo-o nós mesmos e ajudando outros a fazerem o
mesmo. Através deste trabalho, passamos a valorizar:
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação
abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
http://www.manifestoagil.com.br/

19.
Princípios Ágeis
1. Nossa maior prioridade é satisfazer o cliente, através da
entrega adiantada e contínua de software de valor.
2. Aceitar mudanças de requisitos, mesmo no fim do
desenvolvimento. Processos ágeis se adequam a mudanças,
para que o cliente possa tirar vantagens competitivas.
3. Entregar software funcionando com freqüencia, na escala de
semanas até meses, com preferência aos períodos mais curtos.

20.
Princípios Ágeis
4. Pessoas relacionadas à negócios e desenvolvedores devem
trabalhar em conjunto e diáriamente, durante todo o curso do
projeto.
5. Construir projetos ao redor de indivíduos motivados. Dando a
eles o ambiente e suporte necessário, e confiar que farão seu
trabalho.
6. O Método mais eficiente e eficaz de transmitir informações
para, e por dentro de um time de desenvolvimento, é através
de uma conversa cara a cara.

21.
Princípios Ágeis
7. Software funcional é a medida primária de progresso.
8. Processos ágeis promovem um ambiente sustentável. Os
patrocinadores, desenvolvedores e usuários, devem ser
capazes de manter indefinidamente, passos constantes.
9. Contínua atenção à excelência técnica e bom design, aumenta
a agilidade.

22.
Princípios Ágeis
10. Simplicidade: a arte de maximizar a quantidade de trabalho
que não precisou ser feito.
11. As melhores arquiteturas, requisitos e designs emergem de
times auto-organizáveis.
12. Em intervalos regulares, o time reflete em como ficar mais
efetivo, então, se ajustam e otimizam seu comportamento de
acordo.

23.
Espere ai... Vamos calma...

24.
Ser Ágil
não é ser
Rápido ou
Veloz

25.
Ser ágil é:
É entregar valor com frequência,
gerando feedback e
adaptando-se (rapidamente)
às mudanças.

26.
Entrega de valor com frequência...?

27.
Não é o mais forte que sobrevive,
nem o mais inteligente,
mas o que melhor
se adapta às mudanças
Charles Darwin
Adaptando-se às mudanças...
“

28.
Ágil é
falhar rápido

29.
Falhar rápido???

30.
Ágil não é uma bala de prata.
Não é a solução de todos os problemas.

31.
Quando ser ágil?
• Exigem pesquisa e
desenvolvimento;
• Têm altas taxas de mudança;
• Têm requisitos, incerteza ou
risco pouco claros ou
desconhecidos; ou
• Têm um objetivo final difícil de
descrever
Agile Practice Guide

32.
Como ser ágil?

33.
E ágil combina com T.I.?
Ou apenas empresas de Software?

34.
TI vs Core Business da Empresa

35.
https://eitisolucoes.com.br/blog/entendendo-o-que-e-ti-bimodal-maratonista-ou-velocista-no-que-sua-empresa-se-encaixa/
TI Bimodal = Maratonista + Velocista
Diferentes, mas essenciais
https://eitisolucoes.com.br/blog/entendendo-o-que-e-ti-bimodal-maratonista-ou-velocista-no-que-sua-empresa-se-encaixa/ https://www.gartner.com/it-glossary/bimodal/

36.
https://eitisolucoes.com.br/blog/entendendo-o-que-e-ti-bimodal-maratonista-ou-velocista-no-que-sua-empresa-se-encaixa/
Modo 1 – Maratonista Modo 2 – Corredor/Velocista
Confiabilidade Objetivo Agilidade
Desempenho Valor
Retorno, marca, valor ao
cliente, UX
Cascata, ITIL, Cobit, ISO, ... Abordagem
Ágil, Kanban, Lean IT, DevOps,
...
Dirigida por planos e níveis de
aprovação
Governança
Empírica, contínua, baseada
em processos
Fornecedores corporativos e
relações a longo prazo
Parceiros
Fornecedores novos,
pequenos e curto prazo
Bom em processos
convencionais e em projetos
Talento
Bom em projetos novos e
incertos
Centralizada em TI Cultura
Centralizada no negócio e
próxima aos usuários
Longo (meses) Ciclo Curto (dias, semanas)
TI Bimodal = Maratonista + Velocista
Diferentes, mas essenciais
https://eitisolucoes.com.br/blog/entendendo-o-que-e-ti-bimodal-maratonista-ou-velocista-no-que-sua-empresa-se-encaixa/ https://www.gartner.com/it-glossary/bimodal/

37.
TI Bimodal é o caminho para a transformação digital...”
As empresas precisam desenvolver ações inovadoras e
disruptivas
ao mesmo tempo em que continuam a fazer
negócios como sempre
https://www.gartner.com/it-glossary/bimodal/
“

38.
http://cio.com.br/opiniao/2016/09/27/bimodal-ja-era/
“O modelo de TI bimodal reforça a mensagem que os
clientes corporativos querem ouvir,
que as disrupções podem ser controladas e adotadas gradualmente.
Mas acaba gerando procrastinação e atrasando a
velocidade da empresa em fazer sua transformação de negócios.
Cezar Taurion
Head & Partner Digital Transformation at KICK
“

39.
“Estamos desconstruindo a nossa TI Bimodal.
Eu mesmo a implementei.
Ela foi importante e hoje já não basta.
Não existe transformação digital sem velocidade,
sem mudar a cultura do meu time e da própria empresa.
É uma nova TI, pronta para o futuro”
Cristiano Barbieri,
CIO da SulAmerica
https://www.itforum365.com.br/encontros/ti-bimodal-estrategia-digital/
“

40.
... na nossa visão, foi vital usar a metodologia ágil,
com ciclos curtos, entregas rápidas.
Isso exigiu uma reestruturação do time.
É fundamental somar competências,
muito treinamento, alinhamento e capacitação.
Cristiano Barbieri,
CIO da SulAmerica
https://www.itforum365.com.br/encontros/ti-bimodal-estrategia-digital/
“

41.
https://www.itforum365.com.br/encontros/ti-bimodal-estrategia-digital/
“A TI Bimodal hoje não faz parte do novo cenário
composto por exemplo
pela metodologia Ágil,
que tem novos propósitos.
Estamos na migração do 100% Ágil”
Viviane Lusvarghi
CIO da Santher
“

42.
https://epocanegocios.globo.com/Empresa/noticia/2018/07/transformacao-digital-leva-itau-mudar-avaliacao-de-desempenho.html
A tecnologia estudava aquilo, fazia um road map e dois anos depois tínhamos a solução
implantada”,
O problema é que 50% de todos os projetos produzidos acabavam descartados.
Quando ficavam prontos, já não faziam sentido.
Não dá pra falar que você vai fazer uma
transformação digital sem mudar o jeito como faz as coisas,
70% da avaliação agora é feita com base em indicadores coletivos
O foco é muito mais na colaboração e menos na competição
Lineu Andrade
Diretor Itau Unibanco
“

43.
Resistência

44.
Opções

45.
é um framework para
desenvolver
e manter produtos
complexos

46.
Por quê SCRUM?
• Devido as constantes mudanças nos requisitos do projeto, o
modelo tradicional (cascata) não tende a ter o mesmo sucesso
que um modelo iterativo;
• Quando é indicado o Scrum:
• Mudanças constantes;
• Aprendizado durante o desenvolvimento;
• Complexidade e incerteza reduzem a visibilidade;
• Colaboração é importante;

47.
Pilares
SCRUM

48.
Pilares

49.
Diferença entre comprometimento e
envolvimento

50.
Como funciona?

51.
Framework

52.
Product Backlog
• Lista ordenada de tudo que é necessário
para criação do produto
• Única fonte dos requisitos
• É dinâmico; mudando para ser mais apropriado,
competitivo e útil.
• Normalmente escritos no formato de Histórias de
Usuário

53.
Product Owner (Dono do Produto, ou PO)
• Representa a voz do cliente e dos envolvidos ao time
• Gerenciar o Product Backlog
• Expressar claramente os itens do Backlog do Produto;
• Ordenar os itens do Backlog do Produto para alcançar melhor as
metas e missões;
• Garantir o valor do trabalho realizado pelo Time de
Desenvolvimento;
• Garantir que o Backlog do Produto seja visível, transparente, claro
para todos, e mostrar o que o Time Scrum vai trabalhar a seguir;
e,
• Garantir que a Equipe de Desenvolvimento entenda os itens do
Backlog do Produto no nível necessário.

54.
Time de Desenvolvimento (Dev Team)
• São auto-organizáveis
• escolhem qual a melhor forma para completarem seu trabalho, em vez
de serem dirigidos por outros de fora da equipe.
• São multifuncionais
• possuem todas as competências necessárias para completar o trabalho
sem depender de outros que não fazem parte da equipe.
• O modelo de equipe no Scrum é projetado para aperfeiçoar a
flexibilidade, criatividade e produtividade.

55.
Time de Desenvolvimento
• Um grupo de pessoas com cargos diferentes que vai trabalhar
junto para cumprir as metas estabelecidas.
• É a galera que vai por a mão na massa e entregar um produto
“pronto” ao final do ciclo de desenvolvimento.
• Desenvolvedor, Analista de Sistema, ... Não importa o seu cargo
todos tem o mesmo título: desenvolvedor.

56.
Time de Desenvolvimento
Indivíduos e interações mais que processos e ferramentas
• Tamanho: 3-9 membros
• São Especialistas/Generalistas (T-Shaped, Por exemplo, Programar e Testar)
• Comprometimento
• Membros dedicados a equipe

57.
Dedicado?
...”A multitarefa reduz a produtividade do trabalho da equipe e
afeta a capacidade da equipe de prever a entrega de forma
consistente”...
...”porque os membros da equipe perdem tempo mudando de
contexto e/ou esperando uns aos outros para a conclusão de
outros trabalhos”...

58.
Scrum Master
• Facilitador
• Conhecedor do Scrum
• Coach e Agente de mudança, capaz de disseminar o mindset
ágil
• Protege a equipe de interferências externas
• Remove impedimentos, garantindo o fluxo e andamento da
sprint
• Garantir o SCRUM
• Convidar pessoas apropriadas para as reuniões de
acompanhamento

59.
Scrum Master
• Não é:
• Chefe
• Secretário
• Super-herói
http://www.barryovereem.com/stances-of-a-scrum-master-high-quality/

60.
Liderança Servidora
• Servir o time
• Ajudar o crescimento das pessoas
• Disseminar o ágil
• Facilitar a comunicação
• Identificar e remover gargalos e
impedimentos
• Educar as partes interessadas sobre o por
que e como ser ágil.

61.
Gerente de Projeto
O valor dos gerentes de projeto não está na sua posição, mas na
capacidade que têm de melhorar as outras pessoas.

62.
Gerente de Projeto
Equipes Multifuncionais e Auto-Organizadas
“projetos commuitas mudanças, há mais complexidade do que uma pessoa pode
gerenciar.
Em vezdisso,
as equipes multifuncionais coordenam seu próprio trabalho e colaboram com o
representante de negócios”...

63.
Gerente de Projeto
...“Aotrabalhar em um projeto ágil, os gerentes de projeto deixam uma posição central para servir a equipe e a
gerência”...
• são líderes servidores
• coaching de pessoas
• promovem maior colaboração na equipe
• alinham as necessidades das partes interessadas.
• incentivam a distribuição de responsabilidades

64.
Eventos
• Quem nunca perdeu tempo em uma reunião longa e sem
propósito?
• As vezes conversar demais (e fazer de menos) pode ser
prejudicial para qualquer empresa.
• Pensando nisso todos os eventos Scrum são time-boxed, ou
seja, tem uma duração fixa de tempo.
• Desta forma a comunicação é sempre mais clara, objetiva e ágil.

65.
Sprint
• O coração do Scrum é a Sprint
• É um time-box de um mês ou
menos, onde se obtêm uma
versão incremental
potencialmente utilizável do
produto
• Cadência

66.
Sprint
• Durante a Sprint:
• Não são feitas mudanças que podem afetar o objetivo
da Sprint;
• A composição da Equipe de Desenvolvimento
permanecem constantes;
• As metas de qualidade não diminuem; e,
• O escopo pode ser clarificado e renegociado entre o
Product Owner e a Equipe de Desenvolvimento quanto
mais for aprendido

67.
Reunião de Planejamento
Sprint Backlog
Product Backlog
Velocidade do Time
Último incremento
Capacidade projetada
4hs para Sprint de 2 semanas
Objetivo da Sprint

68.
Reunião de Planejamento
• Planejamento das atividades da Sprint que se
inicia;
• Avaliar capacidade considerando feriados,
folgas, férias, ...
• Quem deve estar:
• Todo Time Scrum
• AN (se necessário para esclarecimento de
determinado assunto)
• Defina um objetivo da Sprint

69.
Reunião de Planejamento
• 4 horas para uma Sprint de 2 semanas
• Em cada metade da reunião duas perguntas
devem ser respondidas:
• O que será entregue como resultado?
• Seleção da histórias
• Como o trabalho necessário para entregar o produto
será realizado?
• Quebra em tarefas
• A quantidade de histórias que podem ser
realizadas na Sprint é definida pelo Dev.Team.

70.
Estimativas
• A Equipe de Desenvolvimento é responsável por todas as
estimativas dos itens do Backlog
• O Product Owner deve influenciar o Time, ajudando no
entendimento e nas decisões conflituosas de troca, mas as
pessoas que irão realizar o trabalham fazem a estimativa final.

71.
Sprint Backlog
• é um conjunto de itens do Backlog do
Produto selecionados para a Sprint Sprint
Backlog

72.
Reunião Diária
• A idéia da reunião diária, ou stand-up meeting, é juntar a
equipe para um bate-papo de 15 minutos no máximo para
revisar o andamento do projeto.
• Objetivo é estabelecer o comprometimento, descobrir
problemas e garantir que o Scrum funcione;
• Não é uma reunião de status;

73.
Reunião Diária
• Quem deve estar:
• Time de Desenvolvimento
• Scrum Master
• Cada membro da equipe deve responder as
seguintes perguntas:
• O que eu consegui completar ontem?
• O que farei hoje?
• Quais obstáculos estão impedindo o meu
progresso?

74.
Reunião Diária
• Não é hora de discussões; apenas de apontar
necessidades de conversas, impedimentos;
Reuniões podem ser marcadas para discutir
os temas posteriamente;
• Questão extra:
• Alguém está trabalhando em algo que não esteja
no quadro?

75.
Revisão da Sprint
• Revisar todos os itens desenvolvidos e demonstrar as partes que
foram entregues com o objetivo de coletar feedbacks;
• O PO pode aceitar ou rejeitar histórias;
• A duração desta reunião considerando um sprint de um mês é 4
horas.
• Quem?
• Time Scrum
• Interessados: Suporte, PMO, ...

76.
Retrospectiva da Sprint
• A sprint acabou!
• Kaizen – Melhoria contínua
• Agora é hora de olhar para trás e repensar o que deu certo, o
que deu errado e planejar o que pode ser melhorado no futuro.

77.
Como funciona?

78.
Burndown Chart
• É um gráfico que tem a função de monitorar o desenvolvimento
da equipe.
• Funciona da seguinte maneira:
• todos os dias você anota quantas tarefas do seu Sprint Backlog foram
efetivamente cumpridas.
• Desta maneira você pode saber com antecedência a velocidade que
sua equipe trabalha.

79.
Burndown Chart

80.
Grooming session
• Preparação das histórias da próxima iteração;
• + - 1 hora por iteração
• O PO apresenta as ideias
• O Trio (Dev + Tester + AN) discutem e
detalham os cenários de aceitação;
• Refinam e quebram as histórias quando
necessário;

81.
Aumentando a Qualidade
do que entra e do que saí....

82.
Definition of Ready (DoR)
• Define uma lista de critérios que as histórias precisam
atender para fazerem parte do Sprint Backlog
• Exemplos:
• Aprovada pelo Gestor da Área
• Deve ser escrita em formato de história de usuário
• Foi estimada? O tamanho é menor que X?
• Deve conter cenários de aceitação
• A responsabilidade de atender as definições é do PO
• Não pode ser rígida a ponto de tornar o processo
Cascata
SECURITY
https://www.mountaingoatsoftware.com/blog/the-dangers-of-a-definition-of-ready

83.
Definition of Done (DoD)
• Define uma lista de critérios que as histórias precisam atender
para serem consideradas entregues
• Exemplos:
• Código foi revisado
• Passar pela pipeline de integração continua
• Passado pelo SonarQube
• Conter testes automatizados
• A responsabilidade de atender as definições é do Dev Team.

84.
Estimativas e Métricas
• As estimativas são feitas durante o Grooming/Planning, ou seja, só
são estimados as histórias que estão próximas de irem para o Sprint
Backlog;
• Medições empíricas e baseadas no valor;
• É medido o que se entrega e não o que se prevê que irá entregar;
• Algumas técnicas:
• Planning Poker
• 3 Pontos
• Ideal day
• P M G

85.
Estimativas e Métricas
• ...”Os patrocinadores geralmente querem saber quando o
projeto estará pronto. Uma vez que a equipe estabelece uma
velocidade confiável (histórias médias ou pontos de história por
iteração) ou o tempo médio do ciclo, pode prever quanto
tempo o projeto levará.”... (p.55)
• Acompanhamento com o Burndown/Burnup Chart
• Velocidade do Time

86.
https://targetteal.com/pt/blog/metodo-kanban/

87.
Kanban
• Sistema Toyota de Produção (TPS) na década de 60
• kanban significa Cartão/Sinalização
• Kanban é o método
• David J. Anderson trouxe para o mundo de Software

88.
Pare de começar,
e comece a terminar!
Foco na entrega contínua.
As equipes estão focadas no fluxo de trabalho até a conclusão e não iniciam
novos trabalhos até que o trabalho em andamento esteja concluído.
é mais importante completar o trabalho do que começar um novo trabalho

89.
Princípios
• Comece com o que você tem hoje
• Mapeie seu processo
• Busque mudanças incrementais e evolucionárias
• Faça hipóteses e faça pequenas mudanças
• Respeite o processo atual, papéis, responsabilidades e títulos

90.
Práticas

91.
Visualizar o Fluxo de Trabalho
• Da esquerda para
Direita
• Cada etapa
acrescenta valor ao
item

92.
Limitar o trabalho em progresso (WIP)

93.
Entendendo o WIP...

94.
Backlog Usando Ag. Lavar Lavando Ag. Guardar Guardado

95.
Backlog Usando
WIP [2]
Ag. Lavar
WIP [2]
Lavando
WIP [1]
Ag. Guardar
WIP [2]
Guardado

96.
Medir e gerenciar o fluxo

97.
Torne as políticas de processo explícitas
• Se usar cores para diferenciar, deixe explicito o que cada cor
representa
• Explicite os WIPs
• Regras de priorização

98.
Implemente ciclos de feedback e
• Certifique-se que está entregando o produto certo;
• Procure a melhoria contínua do processo (KAIZEN)
Melhore colaborativamente

99.
Squads
• 3-10 pessoas
• P.O. dedicado
• Estão próximos;
• Tem uma missão a longo prazo.
• Autônomos
• Auto organizados
• Responsáveis por realizar tudo que é necessário para entrega
do produto; tendo as qualificações e ferramentas necessárias
para desenvolver, testar, colocar em produção...

100.
Tribes
• Um conjunto de Squads da mesma área de
negócio;
• Geralmente compostos por umas 100 pessoas;
• Estão em uma mesma área física;
• Há espaço físico para colaboração e troca de
informações;
• Há um “Chefe da Tribo”

101.
Chapter
• Pessoas da mesma área técnica
• Ideal para pulverizar o conhecimento
através de encontros frequentes
• Divisão horizontal
• Exemplo Divisão de Devs,
• Reunião para apresentar/discutir o
release do C# 8, ...

102.
Guild
• Comunidade de interesses
• Pessoas de toda a organização e diferentes habilidades técnicas;
http://www.full-stackagile.com/2016/02/14/team-organisation-squads-chapters-tribes-and-guilds/
https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/

103.
Sendo ágil...

104.
Como ser ágil?

105.
Contamos com vocês!

106.
Bora ser
ágil?
Obrigado!

107.
Entregando Software
com “Valor”
Maicon Carlos Pereira