Trilha Agile

Coordenadores: Annelise Gripp e Rafael Helm

Por que devemos utilizar métodos ágeis?

Rafael Zulin

A palestra de Rafael Zulin apresentou os 4 itens do Manifesto Ágil, bem como os 12 princípios que regem o Manifesto. Analisando os princípios, identificamos que o SCRUM, e quaisquer outros frameworks ágeis utilizados, tem por objetivo maior entregar valor ao usuário.

Contudo, cabe uma análise sobre o que é valor ao usuário. Valor é uma métrica que depende muito do contexto de cada cliente. Para alguns, um controle de qualidade maior significa maior valor. Para outros, uma grande quantidade de funcionalidades. Para outros ainda, uma única funcionalidade bem desenvolvida agrega mais valor que várias mais ou menos.

É preciso se atentar que nesse conceito, o valor transcende ao dinheiro ou resultado monetário. Porém não pode ser descuidado.

Agile UX vs Lean UX - Eu devo escolher uma delas?

Alessandra Rosa

A palestrante Alessandra Rosa é designer e apresentou um pouco das dificuldades dela no início da carreira, quando entrou em um time e foi recebendo demandas, sem realmente ter que realizar o o trabalho de análise de UX, pois esse era feito pelos analistas na empresa que trabalhava. Posteriormente ela começou a conseguir espaço, trabalhando junto ao PO na formulação das propostas. Essa postura é diferente do que acontece em muitos casos na MSTECH, em que o design é solicitado pelo SM em tempo de execução de projeto.

A palestrante então apresentou o conceito de UX, que é uma mediação coordenada entre várias disciplinas e que o UX tradicional se intersecta em alguns pontos com o Agile UX e o Lean UX.

O Agile UX tem as seguintes características:

• Colaboração criativa
• Brainstorming
• Board Colaborativo (Kanbam)
• Ideação
• Product Roadmap
• Personas -> Jornadas

Já o Lean UX tem por objetivo trabalhar com a construção de MVPs (mínimos produtos viáveis) e a criação de small badges para trazer maturidade ao produto com mais agilidade. O Lean também promove engajamento, pois todos participam do processo.

Ainda não há uma receita clara sobre a junção das visões diferentes de UX, depende do time e da sua maturidade, porém é importante entender e tratar a intersecção entre as três visões (tradicional, Lean e Agile).

Ponto que chama a atenção na palestra é o fato do designer atuar como um "par" do PO, inclusive participando de levantamentos. E, por trabalhar em sprints diferentes do time de desenvolvimento, se lançarem atividades junto com os devs, acabam por afetar o burndown.

Extreme Value-Driven Coaching: 4 sprints em 5 dias

Luiz Rodrigues

Luiz é Agile Coach da K21 (Knowledge21)

A palestra apresentou um modelo de trabalho chamado EVDNC. Esse modelo tem por objetivo evidenciar os problemas que impedem de entregar valor ao final de uma sprint.

Trata-se de uma atividade que gera 4 sprints em 5 dias. Esse processo deve ser rodado com um coach experiente para que se tenha um resultado produtivo. As atividades são divididas da seguinte forma:

Dia 0: alinhamento com a Gestão sobre os objetivos da atividade; Dia 1: Time e negócios juntos, discutindo e identificando Produtos Reais que participarão da ação; A partir do dia 2: Execução de 1 sprint por dia. Foco máximo. No início do dia, planning, ao final uma review e retrospectiva. O objetivo aqui é falhar rapidamente para rápida aprendizagem do que deve ser melhorado. Nessa etapa fica claro que a equipe, incluindo o PO teme não entregar nada em 1 dia, mas aos poucos se vê que não é bem assim. No último dia é feita uma big review e big retrospectiva

O problema mais encontrado nas sessões já executadas pela K21 é o PO. Este acaba sendo um papel negligenciado no processo.

Por fim, Luiz citou uma frase "Scrum é um meio, não o fim". O fim é o cliente satisfeito.

Agile sem indicadores globais funciona?

Marcos Santos

Marcos é CEO em sua empresa e contou um case de geração de indicadores.

Em sua empresa, o produto é tratado como um serviço. Cada cliente pode pedir o que deseja e no prazo que quiser para customização. Eles trabalham com 1 semana e trabalham na priorização do backlog.

O palestrante citou que eles tinham problemas com a priorização e entrega de demandas ao usuário, deixando-o insatisfeito. Para tentar modificar a situação começaram a trabalhar com dois tipos de planning: Uma "Product Planning" que é uma reunião com o cliente (presencial ou não) sobre as priorizações das próximas sprints, e a "Sprint Planning".

Isso causou uma melhora imediata, mas logo o cliente voltou a se tornar insatisfeito. Isso era causado porque todos tinham uma visão míope do dia e que a gestão não tinha a visão da capacidade total do time.

Passaram a trabalhar com medições: Burndown e Burndown com capacidade produtiva. Essa medida olha só a sprint, mas desconsidera como o cliente está enxergando. No caso deles o burndown mostrava clara evolução das tarefas, porém o cliente continuava enxergando muito atraso e muitos erros nas entregas.

Ao buscar a visão do cliente e fazer com que a gestão tivesse a mesma visão, com métricas da visão de cliente, o time ficou focado em se ter compromisso com o pacote de requisitos atual, trouxe uma maior qualidade e maior visão da capacidade produtiva. Só colocar o SCRUM, sem métricas de qualidade, não funcionou para ele.

A revolução de um time de produto: como ter ownership e arrumar a casa

Lívia Vasconcelos de Arruda Amorim / Filipi Santana de Assis

Livia e Filipi trabalham na Resultados Digitais de Florianópolis e contaram o case dessa empresa.

Nela, houve um crescimento descontrolado nos últimos anos, sem especialização da atividade, missão clara e visão de futuro para nenhuma equipe. Isso causou muitos problemas com os funcionários, sem contar o aumento das demandas de suporte e bugs da ferramenta principal (que é um SaaS).

Para tentar obter a volta ao crescimento, os diretores foram ao Vale do Silício aprender como funciona o crescimento das empresas de lá:

• Usam muito o modelo pregado pelo Spotify. Aliás, esse modelo do Spotify foi comentado em várias palestras (referência encontrado sobre o assunto: http://arquiteturadeinformacao.com/recursos/metodologia/a-cultura-organizacional-do-spotify/)
• Adoção dos Líderes Horizontais e Guildas: Os líderes horizontais são similares ao que implementamos com o especialistas, de ser um ponto de organização e referência por área de conhecimento. As guildas são grupos organizados por similaridade. Um exemplo desse são os fóruns que organizamos de especialidades, mas podem haver guildas de outros tipos de atividades, como podcasts por exemplo.

Nos produtos passaram a utilizar uma metodologia chamada de Lean Growth (referência: http://growthdevil.com/lean-growth-methodology/)

Essas ações resolveram algumas questões, mas apareceram outros problemas novos. Primeiramente, a contratação de novos funcionários ficou mais difícil pela régua que foi estabelecida. Além disso a autonomia dada às equipes precisa ser acompanhada, pois pode gerar problema.

Por fim, há uma preocupação em como aculturar e receber novos membros e times. Nessa empresa eles usam ferramentas de Onboarding (http://www.caliper.com.br/produtos-solucoes/desenvolvimento-de-talentos/onboarding/)

Agile e a Transformação Digital

Thiago Simões de Almeida / Murilo Gimenes Rodrigues

Thiago é Agile Coach e presta consultorias individuais.

Começou a palestra setando algumas informações importantes. Primeiramente, que 52% das empresas TOP 500 da Revista Fortune em 2000 não existem mais. Outra informação que, segundo ele, "Digital" já é coisa do passado, e dará lugar à computação cognitiva (aplicativos como Siri, Cortana, Facebook Now, Watson) e APIs inteligentes.

Deu alguns conselhos aos participantes, como ter um mentor, identificar quem você segue, ir atrás de material original (grande maioria em inglês) de pessoas que são referências mundiais do assunto. Verificar o que te limita, se você tem escolhas.

Estratégia para evolução: Engajar líderes, criar uma estratégia, promover transformação, avaliar resultados, adaptar e evoluir.

É fundamental ter a visão clara do dono e compartilhada com toda a empresa. Tem que ser muito claro e todos estarem cientes dela.

Também comentou que o Ágil é apenas uma ferramenta, não é solução mágica. Comentou que a adoção do método deve considerar os Fatores Ambientais Organizacionais. Tentar adotar o SCRUM puro, ou qualquer outro método puro, é certeza de fracasso.

Ser ágil é fazer o PDCA mais rápido. É ter o mindset de parceria na empresa. Ser ágil é a soma do envolvimento do negócio e da TI com o Mindset ágil.

Em toda adoção de metodologia haverão exceções, isso é inevitável. Isso é provado pela lei 80% / 20%. Temos que tratar todas as exceções, mas nem todo projeto acabará se encaixando no método. É necessário deixar claro também os problemas para a gestão, não esconder (ele ilustrou como "Morango x Melancia", enquanto no morango o vermelho é evidente, a melancia tudo parece verde, mas por dentro tudo é vermelho).

Por fim comentou sobre os passos que ocorrem na formação de um time:

Forming -> Storming -> Norming -> Perform

Dark Launching: Minimizando os riscos de alterações críticas em produção

Guilherme Baptista

Guilherme é engenheiro na Localweb. Em uma palestra rápida mostrou como são feitos os deploys na localweb. Anteriormente deploys eram um assunto traumático na empresa, que tem muito legados. Todo deploy quebrava alguma coisa.

Começaram a trabalhar com o modelos de publicação de Feature Toggles (basicamente, on/off de funcionalidade) e Dark Launching, que é um modelo de convivência temporário entre código antigo e novo. O código antigo continua sendo responsável por retornar dados ao cliente, porém a execução é repetida pelo código novo e os resultados são comparados. Quando há entendimento do funcionamento do código novo, a chave é virada.

Guilherme também indicou alguns artigos para leitura: "Hammering Usernames", "Feature Toggle" e "Dark Launching".

Feature Leads ou Tech Leads?

Vinicius Vieira Gomes

Vinícius trabalha na Thoughtworks e contou um case de um projeto desenvolvido por eles que teve um escopo muito grande, inclusive de integrações.

No início identificaram um problema de "bus factor" no projeto, ou seja, total dependência da liderança. Isso causava sobrecarga na liderança e emperrava o projeto.

Começaram a usar o modelo de Feature Leads, que se baseia em dividir para conquistar. Ao invés de concentrar tudo em uma única pessoa, dividiram a liderança entre outras pessoas. A primeira tentativa causou problemas de confusão, gargalos e improdutividade, porque ninguém sabia quem estava com o quê.

Em seguida reorganizaram as pessoas no segundo experimento. Foi comunicada a toda a empresa quem eram os líderes dos clientes, e de qual assunto. Delegaram de fato a demanda para esses responsáveis.

O time técnico, sabendo quem tratava do assunto, passou a dar foco em prioridades e detalhes, passou a compartilhar responsabilidades e passou a ter um maior sentimento de pertencimento, além de "desafogar" o líder do projeto

De São Paulo a Sidney, Ágil em times distribuídos

André Suman Pereira

André é engenheiro, trabalha em seus projetos com equipes espalhadas em 4 locais diferentes e comentou um pouco das dificuldades do trabalho remoto.

Ele afirmou que um dos maiores problemas nesse tipo de trabalho é o isolamento de quem está remoto. Este não pode ser esquecido de forma alguma.

Assim como Hardware e Software, André comenta do Peopleware, ou seja, da integração de todas as pessoas do time: cafezinho, almoço em time, futebol, formas de motivação e de todos se conhecerem. Promover integração também com os participantes remotos (ele citou uso de videogames, por exemplo) porque é necessário muita colaboração, entrosamento e engajamento em times remotos.

Por fim ele comentou do uso de câmeras full time para que todos tenham a visão de todos os membros do time.

Acelerando o feedback e deploy com Automação de Testes!

Elias Nogueira

A automação de testes é necessária e fundamental para que seja criada uma rede de segurança. Elias ainda cita que se trabalha com agilidade mas não tem testes unitários não é ágil.

Elias cita a pirâmide de automação de tarefa, composto de: (topo) UI - Serviços - Integração - Unidade(base)

Quanto mais alto na pirâmide, maior é o impacto, tempo e custo das demandas. Dentro dessa pirâmide, é possível dividir em duas sub-pirâmides:

Pirâmide do Desenvolvedor: (topo)Serviços - Integração - Unidade(base) Pirâmide do Testador: (topo)UI - Serviços(base)

Elias também diferenciou os conceitos de testes de aceitação e funcional Teste de aceitação: Validar o sistema como a utilização de um usuário em geral (esse teste vem primeiro); Teste funcional: Teste aprofundado na perspectivas das regras de negócio.

#NoEstimates do jeito errado

Samuel Moro Bergamo Cavalcante / Caroline Wirtti

Samuel e Caroline são SM e PO da Digitho. Na palestra apresentaram o uso do SCRUM na Digitho.

Começaram a tentar usar o framework "by the book". Acabaram caindo numa armadilha. No modelo inicial, tudo foi direcionado para os DEVs; Suporte, PO, etc. A preocupação do time estava apenas nos pontos, não no valor entregue ao usuário.

Na sprint se construía várias histórias, mas várias delas não tinham metas bem estabelecidas. O usuário não via o valor de negócio nas entregas.

Passaram a definir o objetivo de cada sprint. O que estava fora desse objetivo não entrava na sprint. Também começaram a usar métricas para avaliação: Vazão do time, o tempo de cada ciclo e "work in progress" limitado. Também verificaram que a timebox fixa para o time não funcionava bem, então passaram a limitar a sprint pelo objetivo (meta).

Trabalhando desa forma, verificaram uma diminuição aguda na abrangência de cada história. No Grooming, o time pode revisar datas de entrega, e o PO tenta renegociar essas datas.

Passaram a usar metas com métricas também (OKR)

Por fim, viram que para eles era melhor não fazer mais planning, fazem apenas o grooming. Além disso, quando o PO volta do cliente, é feito um alinhamento com todo o time sobre o que foi conversado.

Métricas que importam!

Victor Hugo Germano

Victor começou a falar do Efeito Hawthorne: Índividuos modificam seu comportamento pela consciência de estarem sendo observados. Em seguida começou a falar do uso das métricas em empresa.

Victor citou o uso de métricas de vazão (por exemplo Burndown e Velocidade). Essas métricas tendem a guiar o time para um comportamento errado porque, para aumentar a velocidade, por exemplo, um modelo é aceitar menos pontos.

Na verdade deve ser medido "o que está sendo entregue" ao invés de "quanto você está entregando".

Métricas são a junção do diagnóstico e valor:

• Diagnóstico: entendemos o que está acontecendo?
• Valor: Estamos no caminho correto

Diagnóstico e valor pode ser entendido da seguinte forma: A partir de uma hipótese, tentar minimizar o tempo para chegar a uma validação. O monitoramento para minimizar o tempo é o diagnóstico. A validação é em cima do Valor.

Victor aconselhou a definir 1 métrica de valor dentro do contexto da empresa e focar nessa métrica (OKR)

Por fim, citou o livro de Alistair Croll "Lean Metrics Analitics" como referência.

Slack de Agilidade

Anderson Diniz Hummel / Rafael Barbosa Camargo

Anderson e Rafael comentaram sobre o uso do Slack para disseminação do conhecimento. Existe uma rede nacional no Slack para discutir o assunto. Para participar, basta realizar inscrição no site http://agilidade.org para ter acesso ao Slack no endereço http://agilidade.slack.com