August 15, 2015

CSM - ScrumAlliance - AdaptWorks - Dia 1

Anotações do curso de certificação de Scrum Master da Scrum Alliance, pela AdaptWorks, ministrado pelo Alexandre Magno.

Dia 1

  • Todas as atitudes do Scrum Master são direcionadas com o jeito com que o time está trabalhando, e com o ambiente no qual estão fazendo isso
  • Temos processos adequados para nossas pessoas tirarem o máximo de valor para clientes, stakeholders, etc?
  • Foco em Processos e Pessoas.
  • scrum master não tem como base se o produto é certo ou nao.
  • Ele também não está cobrindo a área tecnológica
  • projetos ágeis são projetos com tempo fixo
  • como SM você precisa confiar na sua equipe para que eles produzam melhor, seguindo seu próprio estilo, sem um modelo imposto, respeitando a complexidade do projeto e suas restrições
  • os desenvolvedores precisam ter uma visão clara do objetivo, e o escopo depende de objetivo pra objetivo
  • em um projeto normal existe escopo, prazo e custo
  • Na forma tradicional, fixamos os três pontos. Mas no Scrum nós trabalhamos com prazo fixo, custo fixo e escopo flexível, aberto e incremental
  • O escopo precisa ter uma visão ligada a ele. Uma visão macro, um objetivo. O que o cliente vai ganhar no final? Qual a estrutura de visão do produto? São definições macro do produto, que deverão ficar fechados.
  • O escopo é flexível, mas você não pode mudar no meio do caminho o objetivo macro do projeto/história
  • o fato do time não saber o que vai fazer e como fazer nos próximos dias, não quer dizer que o escopo vai ser modificado ou o projeto vai atrasar.
  • Mas como garantimos isso? Por que esse processo é o plano vai se adaptar de acordo com a variação do projeto
  • FDD - Feature Driven desenvolvimento
  • métodos ágeis não são o fim, empresas que não admitem seus próprios problemas em processos, pessoas e clientes, falharão usando Agile
  • Muitas empresas praticam um Agile fake, com grandes falhas
  • Identifique quais os problemas que você tem no seu projeto
  • se há muita incerteza nas definições, manter escopo de funcionalidades flexível maximiza a geração de valor para o negocio
  • Ter requisitos estáveis significa que eles continuarão imutáveis por bastante tempo, dessa forma Você consegue medir a complexidade do ambiente

Origem do Scrum

  • 1994: nascimento do Scrum
  • começou a ficar mais popular só lá na frente, nos anos 2001, 2002, 2003, mas estourou mesmo em 2009 por que em 2008 teve uma crise econômica imobiliária
  • Onde aprendemos sobre incertezas e planejamentos a longo prazo
  • scrum fala que no máximo em 1 mês você precisa entregar incrementos do projeto
  • Isso na década de 90 era um horror por causa das tecnologias existentes
  • Hoje, com a tecnologia avançada, conseguimos criar produtos mais modulares, o que facilitou a vida de quem usa scrum
  • outro ponto era que o mercado não achava que o problema da não entrega do software, era do método, mas das pessoas
  • scrum é só para desenvolvimento de software? Não, hoje em dia há empresas relacionadas a manufatura e negócios que usam o scrum
  • Mas o scrum nasceu no desenvolvimento de software, ele nasceu para software
  • Os criadores de chamam Ken Schwaber e Jeff Sutherland
  • Scrum é uma jogada do Rugby para retomar a posse de bola, isso é uma jogada que depende muito da auto-organização da equipe
  • Conceito de auto-organização
  • naquele tempo, todos os métodos para desenvolvimento de software, eram baseados no método waterfall, que vem do modelo industrial, linha de produção, onde se pega todo o trabalho que existe, divide em especialização e divide em fases
  • O Scrum se baseia num processo interativo e incremental, onde em cada interação, temos certeza de que temos todas as especialidades para entregar um incremento funcional.
  • Como cada interação tem todas as especialidades para criar um pedaço do projeto por inteiro, é possível entregar pedaços funcionais do projeto, em um escopo flexível, mas com tempo de entrega definido
  • Antigamente os métodos eram baseados em uma gestão centralizada. Quem faz gestão não executa e quem executa não faz gestão, vem do modelo de Taylor, onde o que você tinha na execução aquela pessoa que dava a “mão de obra”
  • gestão e execução são situacionais. Há um tempo no projeto que você precisa fazer mais ou menos gestão do projeto e outras que precisa se concentrar na execução
  • O scrum tenta misturar os dois, em cada um dos ciclos de desenvolvimento
  • não adianta ter equipes multidisciplinares se você não compartilha a gestão.
  • Não adianta utilizar scrum se seu fluxo ainda é waterfall
  • Não adianta usar scrum se você tem um gerente cobrando entregas e produtividade em cima do time de desenvolvimento

Complexidade

  • Tamanho não é a medição mais adequada para se decidir se vai ou não vai usar Scrum.
  • A forma mais adequada é o nível de complexidade do seu projeto. Eles se basearam na Teoria da Complexidade
  • O que significa Complexidade? Complexidade não quer dizer difícil. Complexidade tem a ver com incerteza, com instabilidade. Algo é mais simples, quando é certo ou estável.
  • Existem vários frameworks no campo científico qua ajudam a discutir esse assunto. Um deles é o Stacey Diagram.
  • Quanto mais difícil a gestão por causa da instabilidade e incerteza do projeto, mais você pode descentralizar a gestão
  • Scrum foi criado para contemplar projetos fortemente complexos, mas que não chega a ser caótico
  • Normalmente confundimos caos com desordem. Caos quer dizer que temos um ambiente imprevisível, mas não desorganizado. Um pronto socorro é um ambiente caótico, mas imprevisível.
  • Cynefin Framework. Divide o ambiente em complexo, complicado, caótico e simples. No meio fica a desordem.
  • Na Sprint você tem mais estabilidade e conhecimento do que você tem no seu projeto. Isso é normal.
  • Não faz sentido usar scrum para Projetos com escopo fechado, arquitetura já definida. Se você já tem um escopo definido e uma arquitetura conhecida, você tem um projeto simples, talvez um pouco complicado.
  • Em projetos com uma stack e um escopo bem conhecido e definido, talvez os modelos de Waterfall seja o modelo mais acertado para esses projetos.
  • Entregar valor rápido para o cliente, é um efeito colateral e não um objetivo. Você não usa Scrum para entregar mais rápido.
  • Mas quanto mais rápido você entrega valor para o cliente, você está sujeito a mais mudanças, porque o cliente reage, o PO reage, o UX reage a estas entregas.
  • Somos ágeis para responder a mudanças de um ambiente de incertezas
  • Uma empresa de Games não podem entregar para o cliente metade de um jogo. Eles podem trabalhar com scrum e entregas incrementais, mas só vai entregar para o cliente quando o game estiver totalmente completo.
  • O topo do backlog do produto precisa ser as histórias estáveis, conhecidas, para que possamos diminuir o nível de incertezas e instabilidades do projeto.
  • Você decide se vai ou não usar scrum de acordo com o nível de incerteza do seu projeto

Agile

  • Agile não é uma metodologia ou ferramenta. Agile é um mindset. Está mais relacionado a comportamento do que método.
  • Valores Agile
    1. Pessoas e interações entre elas. Você precisa ter um ambiente que valorize as pessoas, por que são as pessoas que serão determinantes no sucesso do projeto. Facilite a comunicação entre as pessoas.
    2. Entregar software funcionando. É isso que gera valor. Não se dê o luxo de ficar 3 meses escrevendo documentação. O mindset ágil diz que a entrega de valor é entrega software funcionando o quanto antes.
    3. Colaboração com o cliente. Colaborar não é ser bonzinho. Colaborar é no sentido de trabalhar junto com o cliente. Não dá para dizer que você é ágil se o seu padrão de trabalho é separar o cliente durante o desenvolvimento do projeto.
    4. Responda à mudanças. Quem tem mindset ágil sabe que mudanças vão acontecer durante todo o projeto. Precisamos estar preparados para responder à mudanças de forma rápida.
  • Métodos ágeis são os princípios do mindset agile que materializam os valores Agile, fazendo com que esses valores não sejam mais um mantra, mas virem prática

O que é Scrum?

  • Scrum é um framework de processos emergentes em contextos predominantemente complexos.
  • Scrum é um framework. Scrum não é uma metodologia.
  • Scrum é baseado em Fluxo, Papéis, Artefatos, Cerimônias.
  • Metodologias são prescritas, ou seja, ela diz exatamente como você precisa seguir. Um framework também não é tão fácil de se alterar, mas você pode montar coisas em cima.
  • Metodologia está completa. Ela se vende como algo que está completo. É só implantar e usar. Um Framework se vende como incompleto, você vai precisar completá-lo, ele não acreditar ter o suficiente para o que você precisa.
  • Framework não é Ready to use. Por definição Scrum é incompleto, não por falha ou erro, mas por conceito.
  • Ele não define l que você precisa fazer (planejamento, documentação etc), por que ele não sabe o que será bom pra você. Ele deixa que essas decisões fiquem na sua mão, adequando de acordo com a sua necessidade.
  • Por exemplo: scrum não te fala como se estima projeto. O cara que entendeu o scrum como framework, entende que para estimar um projeto, depende do contexto e ele vai escolher qual a melhor solução/técnica para estimar projetos.
  • O Scrum também não diz como escrever requisitos, histórias etc. Para quem não conhece framework, diz que Scrum não escreve requisitos, o negócio é falar mesmo. Mas o que já conhece o conceito, decide que é melhor, para aquele projeto, usar User Case. Ou User Story em outro cenário.
  • O pior Scrum Master do mundo é aquele que só conhece Scrum.

bases do processo Scrum

  • fluxo: O scrum se baseia no conceito de Sprint
  • O sprint é a forma com que o scrum expressa o ciclo incremental de trabalho
  • em papéis, temos 3: dev Team, Product Owner e Scrum Master
  • Artefatos: sprint Backlog, Product increment e Product Backlog
  • Eventos: sprint planning, Daily meeting, sprint review, sprint retrospective
  • E em seus valores temos os valores do manifesto ágil.
  • Essa é estrutura pra se desenvolver o mindset Agile

Papéis

  • A gestão de um projeto scrum é feita por três personagens: Product Owner
  • scrum Master e Dev Team.
  • o Product Owner não se preocupa ou não em fazer gestão se preocupando se o objetivo da sprint vai ser alcançado, se as tarefas estão no prazo, quais os riscos da sprint. Ele vê o macro, vê o projeto, risco do produto.
  • O que for micro gestão, fica com o desenvolvimento Team. Quem tem que estar preocupado com os riscos da sprint é o dev Team, o prazo, entregas e etc.
  • PO é macro gestão
  • desenvolvimento web Team é Micro Gestão.
  • Processos e Pessoas fica com o Scrum Master. Ele está preocupado todas as peculiaridades do time e do projeto, e propõem soluções para melhorar a produtividade do time
  • Scrum Master precisa ter pensamento de processo. Se está errado, é por que o processo está errado e não por que o time é ruim
  • Não é o time que é acomodado, é o processo que está falhando em aumentar o senso de urgência.
  • Processos são feitos para as pessoas entregarem melhor, se comunicarem melhor, trabalharem melhor.
  • o super poder do Scrum Master é se colocar no outro, ele precisa gostar de gente.
  • Quem vai levar porrada do PO se o sprint não for finalizado, é o desenvolvimento Team.
  • fazer a coisa certa, do jeito certo, em um ambiente sustentável.
  • PO garante que está fazendo a coisa certa
  • Dev Team garante o jeito certo
  • Scrum Master garante o ambiente sustentável
  • Alma do Scrum são os valores
  • Corpo são os fluxos, eventos, papéis e artefatos
  • Não dá pra ter só corpo ou só alma, precisa ter os dois juntos.
  • Ter os papéis do Scrum são a coisa mais importante pra ter uma transição pro Agile
  • Corpo sem alma é zumbi, alma sem corpo é fantasma.

Product Owner

  • PO gerencia as entregas, por que foi ele que acertou a entrega com o time
  • ele que combina o que vai e o que não vai entrar no sprint
  • satisfação do cliente é uma responsabilidade do PO. Por que é o cara que prioriza o que vai ou não ser feito é que detém a tomada de decisão
  • gestao e lideranca dos stakeholders
  • Cronograma do projeto PO
  • Custo
  • Comunicar prazos do projeto

Scrum Master

  • desenvolvimento web de competências. Se o time não está maduro para o processo, é dever do SM desenvolver essa competência no time
  • retira impedimentos do processo.
  • Facilitador
  • Retirar impedimentos
  • Dar ao Product Owner processos que o ajudem a dar mais visibilidade do projeto
  • qualquer coisa relacionada aos processos
  • scrum e Agile, é o Scrum Master que precisa ensinar para os pares

Dev Team

  • gerencia tarefas. Isso significa que nas sprints é dia a dia, eles discute entre eles quem tem mais habilidade pra fazer cada tarefa
  • são responsáveis se as tarefas vão ser entregues no dia, atrasos e etc
  • Resolução de conflitos entre pessoas do time. Qualquer resolução deveria surgir do próprio time
  • o time decide o que é impedimento ou não
  • cronograma da sprint
  • qualidade de entrega das tarefas

Hierarquia

  • Hierarquia no scrum é situacional, ela não é definitiva
  • PO precisa bater no Dev Team, questionando sobre as entregas e problemas nas tarefas do produto
  • Se o assunto for tecnologia/micro gestão, Dev Team é que decide e manda
  • Se for processos e pessoas, é o scrum master que comanda
  • Scrum é contra a liderança fixa, por que uma pessoa que não é boa em todos os assuntos deverá tomar decisões sobre tudo