Upload
geraldo-b-farias
View
362
Download
2
Embed Size (px)
Citation preview
Desenvolvimento de Produtos Digitais consolidando
Múltiplos Times escalando Metodologias Ágeis
Desenvolvemos produtos digitais
Geraldo B FariasAgile Professional
br.linkedin.com/in/geraldobf @[email protected]
CONHECENDO O PROBLEMA...
Desenvolver um produto de Mobile Banking, nas plataformas nativas Android, iOS e Windows Phone, utilizando práticas ágeis de desenvolvimento de software.
• Prazo “apertado”• App para 4MM de usuários
• Organização em transição para um Modelo de Desenvolvimento Ágil
• Elevado nível de dependências no produto
• Product Backlog pré-definido (em nível de épicos)
DEPENDÊNCIAS DO TIME
FRONT-END
• UX• Devs• DevOps• QA
FRAMEWORK
API SEGURANÇA
• Comunicação
• Regras de Negócio• Transacional
• Backend da Segurança
COMPOSIÇÃO DO TIME
Para isso, contamos com um time de 27 pessoas.
Tech Lead
Tech Lead
Tech Lead
DEV DEV DEV DEVDEV DEV DEV DEVDEV DEV DEV DEV UX UI UX
QA
DEVOPS
TIME DE GESTÃO
PO POTech Lead
PM SM I. API
PRINCIPAIS PROBLEMAS:
DAILY ÚNICO(30 A 40 MIN POR
DAILY)
ASSINCRONIA COM DEPENDÊNCIAS
TIMES DESBALANCEADOS E
EM FORMAÇÃO
PRAZO INICIAL ARROJADO
COMO ABORDAR O PROBLEMA...
Scrum-of-Scrums(SoS)
PO meta-scrum
Large Scale Scrum(LeSS)
Larman/Vodde
Scaled Agile Framework (SAFe)
Leffingwell
Discipled Agile Delivery (DAD) + Agility at ScaleAmbler/Lines
Spotify "model" (Tribes, Squads,
Chapters & Guilds)
Recipes for AgileGovernance (RAGE)
DSDM Drive StrategyDeliver More
• ALGUMAS MANEIRAS DE ABORDAR O PROBLEMA DE ESCALAR ÁGIL EM PROJETOS
Scrum at ScaleSutherland/Brown
Nexus
Scrum.org
TENTANDO SE BASEAR NO NEXUS
PRIMEIRAS AÇÕES:
SEPARAR OS TIMES POR PLATAFORMA +
TIME UX
FORMAR O “TIME DE CONSOLIDAÇÃO”
EVENTOS POR TIME / PLATAFORMA
SESSÕES DE REFINING COM TECH
LEADS + UX
NA PRÁTICA, A TEORIA É OUTRA...
SESSÕES DE REFINING:
PO + TECH LEADS + UX ( 1 HR)
[SOB DEMANDA]
PL iOSTech Lead +
Devs (“2” hrs)
PL AndroidTech Lead +
Devs (“2” hrs)
PL W. PhoneTech Lead +
Devs (“2” hrs)
Daily iOSTC + Tech Lead
+ Devs
Daily AndroidTC + Tech Lead
+ Devs
Daily W. PhoneTC + Tech Lead
+ Devs
Daily UXTC + UXers
PRE-RETRO:TIME DE
CONSOLIDAÇÃO(30 MIN)
RV/RT iOSTC + Tech Lead
+ Devs(2 HRS)
RV/RT AndroidTech Lead +
Devs(2 HRS)
RV/RT WPhoneTech Lead +
Devs(2 HRS)
RV/RT UXTC + Uxers
(2 HRS)
POS-RETRO:TIME DE
CONSOLIDAÇÃO(30 MIN)
10:00 ~ 10:15
10:20 ~ 10:35
10:40 ~ 10:55
11:00 ~ 11:15
PRE-PLANNING:PO + TECH LEADS +
UX( 2 HRS)
AÇÕES:
DAILYS SIMULTÂNEOS
QA INSERIDO NOS REFININGS E PRE-
PLANNINGPLANNING DE UX
O QUE FIZEMOS BEM?
TIME 15 MIN DE DAILY
RETROSPECTIVAS EFETIVAS
COMEÇARAM A IDENTIFICAR OS
PROBLEMAS
SESSÕES DE REFINING
COMEÇARAM A “CLAREAR” O
BACKLOG
ALGUNS PROBLEMAS PERMANECERAM E NOVOS APARECERAM...
TIME DE CONSOLIDAÇÃO COM 01H20M DE DAILY /
DIA
ALGUNS EVENTOS ESTOURANDO TIME-
BOX
DIFICULDADE DAS DAILYS DE UX QA PARTICIPA ONDE? UX FAZ PLANNING?
APÓS 01 SPRINT...
EVENTOS DE SCRUM
SESSÕES DE REFINING:
PO + TECH LEADS + UX + QA ( 1 HR)[SOB DEMANDA]
PL iOSTech Lead +
Devs (“2” hrs)
PL AndroidTech Lead +
Devs (“2” hrs)
PL W. PhoneTech Lead +
Devs (“2” hrs)
Daily iOSTC + Tech Lead
+ Devs
Daily AndroidTC + Tech Lead
+ Devs
Daily W. PhoneTC + Tech Lead
+ Devs
Daily UXTC + UXers
PRE-RETRO:TIME DE
CONSOLIDAÇÃO(30 MIN)
RV/RT iOSTC + Tech Lead
+ Devs
RV/RT AndroidTech Lead +
Devs
RV/RT W. Phone
Tech Lead + Devs
RV/RT UXTC + UXers
POS-RETRO:TIME DE
CONSOLIDAÇÃO(30 MIN)
10:30 ~ 10:45
PRE-PLANNING:PO + TECH LEADS +
UX + QA( 2 HRS)
Plano de Jogo do RV / RT
- Dinâmicas a serem utilizadas
- Agenda- Necessidade de
materiais- Divisão dos times
entre os membros do TC
Discussão dos problemas em comum
- Quais os problemas estão afetando todos os times?
- Há interdependência nos problemas?
- O que fizemos bem e o que podemos melhorar pra próxima como TC?
Discussão das histórias entre PO e
Tech Leads
Discussão de fluxo
POS-DAILY:TIME DE
CONSOLIDAÇÃO(15 MIN)
10:45 ~ 11:00
Algum impedimento?
PL UXUXers + PO
(“2” hrs)
Quebrar as histórias do Sprint em tarefas
INSPECIONANDO E ADAPTANDO
O QUE FIZEMOS BEM?
FLUIDEZ DOS DAILYS
O GARGALO NÃO DESAPARECE. ELE SÓ MUDA DE LUGAR...
UX E QA FORA DO TIME: CASCATEANDO
O ÁGIL
ASSINCRONIA EXCESSIVA COM AS
DEPENDÊNCIAS
DIFICULDADE NO ATENDIMENTO DAS
DEFINIÇÕES DE PRONTO
COMO O PO VALIDA O PRODUTO NO
REVIEW?
TIME NÃO PARTICIPAVA
DIRETAMENTE DA DISCUSSÃO DAS
HISTÓRIAS
MELHORIA NA PREPARAÇÃO DAS RETROSPECTIVAS
MELHORIA NAS ESPECIFICAÇÕES DE
TESTES
APÓS ALGUNS SPRINTS..
LEAD TIMES ELEVADOS
ALTO NÍVEL DOS ESTOQUES
ESTUDANDO MAIS UMA VEZ O PROBLEMA..
Feature1
Feature2
Feature3
Feature1
Feature2
Feature3
Feature1
Feature2
Feature3
Feature1
Feature2
FeatureC
Feature1
Feature2
FeatureA
Feature1
FeatureX
Feature3
Feature1
Feature2
FeatureB
API FMWSEG QA
• Modelo “celular”: Alto nível de dependência entre os times
• O time não tem autonomia pra se auto-organizar e atender a definição de pronto
• Estoque, estoque e mais estoque
• Problemas na identificação e resolução dos impedimentos entre times
REDUZINDO AS DEPENDÊNCIAS: CORTE POR FUNCIONALIDADES
Feature 1
API FMWSEG
QA
• Corte por funcionalidade: redução das dependências
Feature 2
API FMWSEG
QA
Feature 3
API FMWSEG
QA
• Team Ownership: a responsabilidade de atender a definição de pronto é do time
• Utilização do sistema Kanban, com review por funcionalidade
• Retrospectivas quinzenais: o time reflete como melhorar a forma de trabalho
• Workshop de Histórias: o time “funcional” não deverá ter dúvidas a respeito do que precisa entregar
CONCLUSÃO: 7 LIÇÕES APRENDIDAS
1) Traga as dependências para dentro do time
2) Deixe claro as definições de pronto
3) Nada fala melhor que software funcionando: coloque o app em produção
4) “Abuse” das sessões de Refining: as histórias precisam estar o mais CLARO possível pro time
5) Centralizar e gerenciar as dependências fora do time: gerencie a integração6) Retrospectiva é para o time, não para o projeto
7) Inspecionar e adaptar SEMPRE!
Desenvolvimento de Produtos Digitais consolidando
Múltiplos Times escalando Metodologias Ágeis
Desenvolvemos produtos digitais
br.linkedin.com/in/geraldobf @[email protected]
OBRIGADO !!!