Outubro 2015

Treinamento Ágil & Scrum

Módulo Security Solutions

Agenda❖ Um pouco de Contexto

❖ Por que ágil?❖ Agile Manifesto❖ Agile Mindset❖ Scrum

❖ Papeis❖ Cerimônias❖ Artefatos

❖ Mitos e Fatos❖ Falácias da Agilidade❖ Questões Polêmicas❖ Resources

Por que precisamos nos preocupar com isso?

❖ De forma geral, a taxa de sucesso em projetos sempre foi muito baixa. Segundo o PMI esse número gira em torno de 30% (onde sucesso = projetos acabando no escopo, no prazo, no custo, na qualidade e com o cliente “satisfeito”).

❖ Com projetos de desenvolvimento de Software esse número é ainda pior.

❖ Normalmente a necessidade/demanda é variável no tempo;

❖ O custo de manutenção é muito mais baixo, logo sua “manutenção” as vezes equivale a refazer todo o projeto;

❖ A tecnologia evolui muito mais rápido nas ciências/engenharias novas do que nas tradicionais (Lei de Moore);

❖ Sistemas de Computação e Ciência de Computação ainda são “ciências” muito “novas" quando comparadas às suas contra-partidas tradicionais.

Problema 1 - Você conhece a sua necessidade?

❖ Antes de mais nada, na engenharia tradicional, quase sempre, sua demanda/necessidade é conhecida e se mantém (relativamente) estável ao longo da vida do projeto

❖ Se você quer construir uma ponte, a) o cliente sabe exatamente o que ele quer, e b) a necessidade dele é (quase) a mesma no início do projeto e 2 anos depois.

❖ Quando você desenvolve um produto/sistema de software, na grande maioria das vezes, você só entende/realiza o que realmente quer, depois de ver alguma coisa pronta.

❖ E se o projeto leva 2 anos, é CERTO que o que você queria 2 anos atrás é 100% diferente do que você quer hoje.

❖ Para piorar, muitas vezes quando você coloca seu produto de software na “rua" você descobre que a demanda para ele é bem diferente do que o que você imaginou.

O Cone da IncertezaO cone da incerteza

descreve a quantidade de incerteza ao longo da

vida de um projeto. No começo, pouco se sabe e a incerteza é grande. À

medida que progredimos no projeto, aprendemos

mais e a incerteza diminui. Antes do início

de um projeto de desenvolvimento de software a incerteza

quanto ao tempo e ao custo pode variar de 4

vezes a até 1/4 do inicialmente estimado.

Problema 2 - O custo da mudança é baixo❖ Quando você constrói uma hidrelétrica (ou um prédio comercial inteiro, por exemplo), você faz

muitas manutenções ao longo da vida útil da construção, mas nenhuma delas faz a hidrelétrica virar uma termo-elétrica, ou o prédio virar uma usina de refino de açúcar.

❖ Quando isso acontece, quase sempre é “encarado" como uma NOVA obra/projeto, onde você “destrói” tudo que foi feito e começa do zero novamente. (você não transforma uma ponte normal em uma ponte levadiça, mesmo sendo “só uma funcionalidade a mais na ponte”).

❖ Na maioria das vezes você troca uma peça desgastada por uma nova, ou coisa parecida.

❖ Quando você constrói um produto de tecnologia (software), muitas vezes a manutenção muda a forma como todo o sistema funciona. É comum termos mudanças “estruturais" no produto (as famosas mudanças de “arquitetura”).

❖ Dificilmente um cliente aceita fazer um “novo" produto (uma nova obra) para mexer em questões estruturais do software. É esperado que você faça a mudança.

❖ Dificilmente você re-cria as coisas do Zero.

Problema 3 - Rápida evolução tecnológica❖ Lei de Moore : Sua capacidade de processamento dobra a cada 18 meses.

❖ Hoje, o “computador" que existe no seu smartphone é mais potente do que era o supercomputador de 1980.

❖ Em 1988, o IBM PC “top de linha” tinha 8MHz de velocidade, 100 Kb de memória e 8 Mb de Disco.

❖ Hoje você tem o equivalente a 8 vezes 3.6 GHz de velocidade (dual-quad core), 16 Gb de memória e 4 Tb de Disco.

❖ Estamos falando de um computador ORDENS DE GRANDEZA mais rápido, em 25 anos.

❖ A tecnologia que permeia o desenvolvimento de software evolui MUITO, mas MUITO mais rápido que a tecnologia que permeia as engenharia tradicionais.

❖ Uma ponte hoje é construída quase que com as mesmas técnicas e processos que eram usadas a 30, 40 anos atrás (porém com materiais muito melhores).

❖ Seu computador hoje vai ser peça de museu daqui a 10 anos.

❖ Isso faz com que o perfil de profissional que utilizamos na confecção de produtos/sistemas de software seja completamente diferente do tipo de profissional que é utilizado em engenharia tradicionais

Problema 4 - Ciência nova❖ A ciência da computação, em comparação com as demais ciências tradicionais ainda é

muito nova.

❖ O 1o computador pessoal é do final da década de 70 (1972).

❖ O primeiro IBM PC é de 80 (1981).

❖ A internet surgiu no início da década de 80.

❖ A World Wide Web é de meados de 90 (1994).

❖ O smartphone (como conhecido hoje) é de 2004 (o primeiro iPhone é de 2006)

❖ Por outro lado, as demais engenharias tem bem mais experiência… A construção civil por exemplo é de “antes de cristo”.. Tem mais de 2000 anos.

❖ Quando você junta uma ciência nova e uma tecnologia em franca e acelerada evolução, com demandas extremamente voláteis e com necessidades “de momento”, a forma tradicional de desenvolver software “quebra".

Precisamos resolver problemas diferentes, ou seja, ter soluções diferentes.

Agilidade é uma proposta de solução para esses problemas

O Manifesto Ágil

Indivíduos e interações

mais que

processos e ferramentas

Fonte: http://www.starwarsreport.com/2015/02/18/the-jedi-twl-118/

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

Princípios❖ Nossa maior prioridade é satisfazer o cliente através

da entrega contínua e adiantada de software com valor agregado.

❖ Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.

❖ Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.

❖ Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.

❖ Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.

❖ O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.

❖ Software funcionando é a medida primária de progresso.

❖ Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.

❖ Contínua atenção à excelência técnica e bom design aumenta a agilidade.

❖ Simplicidade --a arte de maximizar a quantidade de trabalho não realizado--é essencial.

❖ As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.

❖ Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

Agilidade não é o CAOS, nem anarquia

Na verdade é muito mais disciplinado do que você pode imaginar

Agilidade é um mindset que permeia todas as decisões ao longo do desenvolvimento do projeto/produto

Sem o mindset correto, de nada adianta seguir os métodos e as cerimônias a risca.

Melhoria continua permeia todo o mindset ágil. Sem ele você não chega a lugar nenhum no longo prazo.

Mindset Ágil❖ Por quê dizem que Ágil é contra documentação?

❖ Muitos dos documentos gerados ao longo do processos de desenvolvimento não agregam valor ao produto e são difíceis de serem mantidos atualizados ao longo do ciclo de desenvolvimento

❖ A documentação que agrega valor para o usuário e/ou para o produto, deve sim ser produzida.

❖ Por quê os ciclos são curtos?❖ Por que assim se força a entregar coisas

funcionando com mais frequência, facilitando o feedback e a adaptação do produto às necessidades de negócio

❖ Além disso, você diminui o risco da necessidade do cliente mudar e você não ficar sabendo em tempo hábil suficiente para fazer as mudanças necessárias

❖ Por quê o Big Design Up Front é ruim?

❖ Você consegue prever o futuro? Fazer todo o design no início implica a premissa que você sabe como vai ser o futuro.

❖ Pressupõe que o sistema não sofrerá grandes alterações ao longo do seu ciclo de desenvolvimento ou que você sabe quais as mudanças vão ocorrer - de modo a planeja—las desde o início, o que dificilmente ocorre na prática.

❖ Quando você pensa em TODO o sistema no início, você toma muitas decisões que dificultam mudanças nos estágios não iniciais do projeto, e nesses casos o custo da mudança fica muito alto.

❖ Outro ponto é que isso significa que você passa os primeiros meses de um projeto sem entregar nada de valor para o seu usuário

❖ O design emergente permite que o sistema evolua e se adapte conforme a necessidade do produto se altera

Mindset Ágil❖ Sempre é possível entregar alguma coisa de

valor, mesmo em sprints muito curtos (de 1 semana por exemplo). A questão fundamental é como se encara “valor”.

❖ O mindset tradicional encara que valor é só o que está pronto para ser realmente usado pelo cliente e o que ele vê

❖ O mindset ágil encara como qualquer incremento de produto que permita agregar algum valor ao produto ou no pior dos casos que permita verificar que o time está andando no caminho certo.

❖ Nem sempre valor se resume a histórias de usuário. Questões de performance e escalabilidade por exemplo, agregam muito valor ao produto, mas as vezes passam desapercebidas para o usuário final.

❖ Entre aumentar um sprint e fatiar uma história, o mindset ágil sempre vai optar por fatiar as histórias.

❖ No mindset ágil, ao perceber que uma história não será entregue, a primeira alternativa é sempre diminuir o ESCOPO e não a QUALIDADE.

❖ No mindset ágil, o time se cobra e se ajuda o tempo todo. Não existe distinção entre o PO, SM e o resto do time. Estão todos buscando a alta performance, e entregar um produto sensacional.

❖ No mindset ágil não existe o EU, só o NÓS. Se a história não foi entregue, nunca é culpa de uma pessoa, mas responsabilidade de todos (inclusive do PO e do SM).

❖ O mindset ágil privilegia as PESSOAS, e suas relações. Não os processos de comando em controle tradicionalmente usados.

Mindset ÁgilÉ principalmente uma grande mudança de paradigma

Cascata (Waterfall) >>> ÁgilDesenvolvimento em cascata >>> Desenvolvimento Iterativo

Escopo Fixo (tempo e qualidade variáveis) >>> Tempo e Qualidade Fixos (escopo variável)

Orientado a planejamento, comando e controle >>> Orientado a transparência, inspeção e adaptação

Orientado a processo >>> Orientado a pessoas

Times de especialistas >>> Times Multidisciplinares

Organização do time é imposta >>> É decidida on spot pelo time (e pode mudar ao longo do tempo)

BDUF / Mudanças são custosas >>> Mudanças são bem vindas, a qualquer tempo

Sem busca pela melhoria continua >>> Busca constante da melhoria continua

Agile vs Tradicional

Crédito: Material cedido pela Knowledge21

O que é o Scrum?

❖ É uma metodologia de gestão de projetos de software que se baseia no mindset ágil.

“Scrum is a management and control process that cuts through complexity to focus on building software that meets business needs. Management and teams are able to get their hands around the requirements and technologies, never let go, and deliver working software, incrementally and empirically.

Scrum itself is a simple framework for effective team collaboration on complex software projects. Ken Schwaber and Jeff Sutherland have written The Scrum Guide to explain Scrum clearly and succinctly.”

(Ken Schwaber : https://www.scrum.org/resources/what-is-scrum)

O que é o Scrum❖ O Scrum é um método estruturado e baseado nos princípios ágeis.

❖ Como qualquer método é baseado em papeis/perfis e e atividades (chamadas no Scrum de Cerimônias).

❖ E com um conjunto “pequeno" de regras de conduta / operação para garantir que as coisas funcionam.

❖ Baseado na “Teoria de Controle de Processo Empíricos”

❖ Tem por pilares: Transparência, Inspeção e Adaptação

❖ Processos Empíricos :

❖ Complexos & imprevisíveis

❖ Diferentes entradas, diferentes saídas

O objetivo do Scrum é conseguir entregar o máximo de valor, no período mais rápido possível.

Não necessariamente todo o projeto/produto será entregue, isso depende basicamente da relação de

custo/benefício entre o valor agregado ao produto/serviço e seu custo para desenvolvimento

Por isso o Scrum é obcecado com a palavra VALOR. Ela deve permear tudo que o Product

Owner faz.

Teoria do Scrum❖ Abordagem incremental e

iterativa para

❖ Maximizar a previsibilidade

❖ Gerenciar o risco

❖ Baseado em

❖ Transparência & Visibilidade

❖ Inspeção

❖ Adaptação

Papeis do Scrum❖ Product Owner (PO)

❖ Scrum Master (SM)

❖ Development Team

❖ São COMPLETAMENTE não relacionados com a hierarquia e com cargos e posições da empresa.

❖ Não existe hierarquia definida no time Scrum. Ninguém manda no time

O Product Owner❖ Define a visão do produto e por

gerenciar o Product Backlog❖ É responsável por maximizar o

valor do produto e por❖ Prioriza e “fatia" o trabalho a

ser feito pelo time❖ É uma pessoa, não um comitê❖ Para ter sucesso, precisa ter

autonomia e suas decisões respeitadas

❖ Não é o dono nem chefe do time❖ Defini o que, e em que ordem

preferencialmente, mas não define o COMO, nem o de que forma

❖ Não é um proxy dos stakeholders

❖ Pode aceitar ou rejeitar o que foi feito pelo time

❖ Deve estar disponível para o time durante todo o sprint

O Scrum Master❖ Responsável por fazer o trabalho

andar de forma fluída e sem sobressaltos

❖ É o facilitador do time, que remove os impedimentos que aparecem ao longo do sprint

❖ Garante que a metodologia é seguida, por intermédio das cerimônias, as conduzindo

❖ Ajuda o time em seu processo de crescimento e amadurecimento

❖ Protege o time de interferências externas

❖ Não é o dono nem chefe to time❖ Não interfere nas decisões técnicas,

nem nas decisões de produto❖ Não é o representando do time

(para fora do mesmo)❖ Não é responsável por criar/

definir as histórias ou por pontua-las

❖ Ajuda o time e o PO em suas respectivas tarefas, servindo o time como um todo

O Time de Desenvolvimento❖ Apesar de “Development”, envolve

todas as pessoas que fazem o incremento de produto acontecer

❖ É quem implementa, testa, coloca em produto, etc..

❖ É responsável por pontuar, e entregar as histórias no maior nível de excelência e qualidades possível

❖ Pode ter 1 ou mais líderes técnicos❖ Responsável por elaborar as tarefas

/atividades necessárias para entregar as histórias

❖ Não “responde" hierarquicamente ao PO nem so SM

❖ Não tem autoridade para definir o produto, ou a visão do produto (no máximo ele influência o PO e os stakeholders para isso)

❖ Não define o como, nem o que, nem o porque.

❖ Idealmente tem entre 5 e 9 pessoas.

Ritos e Cerimônias do Scrum❖ Sprint

❖ Planejamento de Sprint

❖ Planning Poker

❖ Reunião Diária

❖ Revisão do Sprint

❖ Retrospectiva do Sprint

❖ Refinamento do Backlog

❖ Release

Sprint❖ Um sprint é uma quantidade

fixa de dias (um time-box), normalmente de 1 a 3 semanas

❖ Nunca maior que 1 mês

❖ Nesse período é produzido alguma coisa “pronta" e “usável”, que pode ou não ser liberado para o usuário

❖ Tem um objetivo: o que será entregue?

❖ Ao longo de um sprint

❖ Nenhuma mudança de escopo acontece

❖ Sua qualidade não é sacrificada para “entregar"

❖ O escopo pode ser “clarificado" conforme se entende mais do problema

❖ Se o escopo não cabe no time-box, diminui-se o escopo, MAS NÃO SE AUMENTA O PRAZO

Planejamento do Sprint❖ É a primeira cerimônia do Sprint

❖ Reunião onde o time (PO, Desenvolvedores e Scrum Master) planejam o que será feito no sprint

❖ Qual o objetivo do sprint?

❖ Quais histórias serão feitas?

❖ Qual o esforço estimado do trabalho?

❖ Como vamos saber que o que foi feito está "entregue"

❖ As histórias “candidatas" são detalhadas, até o time ter conforto em fazer uma estimativa de esforço

❖ Uma história quanto estimada em mais da metade do ciclo, idealmente deve ser quebrada

❖ Se o time acha que a história não faz sentido, ou ainda que ela está mal definida ou confusa, ele pode “recusar" a história

Estimativas de Esforço - Planning Poker❖ Cerimônia que tem por objetivo alcançar

um consenso em torno das estimativas de esforço para as histórias

❖ E que ocorre DENTRO da cerimônia de planejamento do sprint.

❖ As estimativas são feitas em termos abstratos, usando o “conceito de pontos”

❖ NÃO se usa Dia, ou Horas

❖ NEM se dá um prazo

❖ Todo o time de desenvolvimento se envolve na pontuação das histórias

❖ A pontuação se refere ao esforço (trabalho e complexidade) de implementação das histórias

❖ O planning poker é um processo iterativo, onde depois de todos terem entendido o que é para ser feito na história, cada membro do time estima uma quantidade de pontos para a mesma, ao mesmo tempo.

❖ As pontuações individuais são discutidas e após a discussão, chega-se a um consenso sobre a pontuação da história.

❖ As estimativas discrepantes são discutidas e após seus racionais entendidos, uma nova rodada de pontuação é feita.

❖ Normalmente se usa uma pontuação padrão (como a sequência de Fibonacci).

❖ A pontuação deve ser encarada como a mediana da sequência (ou seja, se a pontuação for 5, significa que a estimativa pode variar entre 3 e 8)

Estimativas de Esforço - Pontos vs Duração

❖ Por que usar pontos e não horas?

❖ Direciona o foco em tamanho, complexidade e esforço e não em duração.

❖ Usando hora/dia marcara performances individuais distintas, com pontos essas questões tendem a serem normalizadas

❖ Tarefas similares tendem a diminuir o hora/dia com o tempo

❖ Ao entrar uma pessoa nova no time, ao se usar hora/dia, se tem a impressão de um aumento imediato e irreal de produtividade

❖ Evita/minimiza a pressão externa em torno de dadas e prazos

❖ Minimiza os efeitos da Síndrome do Estudante e da Lei de Parkinson

❖ Minimiza a falsa sensação de “previsibilidade”. Falar em datas e prazos é sempre mais “preciso" do que falar em pontos (é abstrato por definição)

Reunião Diária❖ Todo dia, em horários pré-

combinados, todo o time se reune.

❖ Essa reunião é curta, não devendo durar mais de 15, 20 min.

❖ Cada integrante do time fala na reunião, com foco em 3 pontos

❖ O que eu fiz ontem

❖ O que vou fazer hoje

❖ Tenho algum impedimento?

❖ Tem por objetivo sincronizar as atividades do time e criar um “plano" para as próximas 24 hr

❖ Além disso, tem por objetivo mitigar riscos e desenvolver planos de ações que permitam atingir o objetivo do sprint

❖ A reunião não tem por objetivo RESOLVER os problemas, mas sim IDENTIFICAR os problemas❖ A solução é feita pelo time em

reunião ad-hoc posteriores

Revisão do Sprint❖ Ao final do sprint, o time

inteiro se reune, e apresenta o que foi desenvolvido

❖ Nessa reunião de apresentação, o time coleta feedback sobre o que foi entregue com o PO e com outros stakeholders relevantes

❖ Só pode ser considerado entregue, o que respeita a definição de “PRONTO" do time

❖ Com o resultado da reunião de revisão, o Product Backlog pode ser adaptado/revisado

❖ Essa não é uma reunião de progresso, e sim uma reunião para se obter feedback e facilitar a colaboração

❖ Nessa reunião, e com base no feedback, o time responde as perguntas que existirem

❖ Essas discussões servem de input para o planejamento do próximo sprint

Retrospectiva do Sprint❖ A retrospectiva é a cerimônia que provê

ao time, a oportunidade de se inspecionar e criar planos de melhoria para serem utilizados no sprint seguinte

❖ Enquanto a revisão do sprint é focado no que foi entregue no sprint, a retrospectiva é focada no processo de auto-organização e performance do time

❖ É onde o time faz uma auto-crítica para entender como o time pode melhorar (em todos os aspectos) e pensa no plano de ação para isso

❖ Essa cerimônia deve ocorrer após a revisão e antes do planejamento do sprint seguinte

❖ De forma geral a retrospectiva tem por objetivo responder 3 aspectos:

❖ Entender o que deu certo e que pode e deve continuar a ser feito?

❖ Entender o que deu errado, e por que? Como isso pode ser evitado

❖ Entender quais os pontos de melhoria que podem ser implementados? Quais as ferramentas, processos e dispositivos podem ser usados para implementar os pontos de melhora?

❖ Apesar de melhorias poderem ser feitas a qualquer momento, a retrospectiva fornece uma oportunidade forma e estruturada para isso.

Refinamento do Backlog❖ É uma reunião onde o time se reune com o PO, ANTES do

planejamento do release, para levantar pontos de dúvida e atenção nas histórias candidatas a serem implementadas no sprint seguinte

❖ Tem por objetivo permitir tanto ao PO quanto ao Time, se preparar melhor para a reunião de planejamento

❖ Pode ser feita a qualquer tempo, mas normalmente é feita no meio do sprint.

❖ Pode ser feita com todo o time, ou com membros individuais

Release❖ Ao longo dos sprints são gerados incrementos de

produtos.

❖ Cabe ao Product Owner identificar quando esses incrementos podem ser efetivamente liberados para os usuários / clientes.

❖ O Release pode ter um conjunto fixo ou não de sprints.

O processo do Scrum

Artefatos do Scrum❖ Histórias de Usuário

❖ Backlog de Produto

❖ Backlog do Sprint

❖ Burn Charts

❖ Incremento de Produto

❖ Taskboard

Backlog de Produto❖ É uma lista ordenada de tudo que é

supostamente necessário para o produto❖ É responsabilidade do Product Owner manter o

backlog de produto atualizado, ordenado e priorizado

❖ Para isso deve conversar com clientes, e demais stakeholders para conseguir entender os requisitos e demandas de negócio

❖ Por definição, o backlog de produto nunca está completo, uma vez que as necessidades do produto evoluem com o tempo

❖ O backlog é vivo, conforme o mercado muda e os clientes tem suas necessidades alteradas, o produto para se manter competitivo também precisa mudar, e com isso, o backlog também muda

❖ O detalhamento do backlog consistem em adicionar detalhes e informações relevantes aos itens do backlog, além de re-ordena-los.

❖ Conforme o detalhamento avança, o time prepara estimativas preliminares para ajudar o PO a priorizar a geração de valor das mesmas

❖ Quanto mais alto na lista de prioridade, mais detalhado e bem definido deve ser item do backlog. Inclusive com definições de “Pronto” mais completas.

❖ Os itens mais alto, são os primeiros candidatos a serem desenvolvidos nos sprints subsequentes

❖ O backlog pode ser re-priorizado e re-ordenado a qualquer hora, visando a geração de valor a partir do sprint subsequente.

Backlog do Sprint❖ Sprint a sprint, o Product Owner define

o que deve ser feito, para se atingir a visão do produto, ou seja é o conjunto de itens do backlog de produto que foram selecionados para aquele sprint

❖ Conforme o sprint se aproxima, o detalhamento do que precisa ser feito se aprimora, até o limite suficiente do time entender:

❖ O que precisa ser feito

❖ Por que aquilo precisa ser feito

❖ Quais as alternativas para entregar o que precisa ser entregue

❖ Os itens do backlog do sprint devem estar devidamente detalhados (eventualmente com wireframes de alto nível, exemplos de uso, etc).

❖ O backlog do Sprint é a previsão do time sobre qual funcionalidade será entregue ao final do sprint

❖ Assim, o backlog dá visibilidade e transparência ao trabalho necessário para atingir o objetivo do Sprint

❖ O backlog do sprint deve ter detalhes o suficiente de forma a ser possível monitorar seu progresso ao longo das reuniões diária

❖ Idealmente, as definições de “Pronto" e “Entregue”, também devem estar completas

Histórias de Usuário❖ Uma história de usuário é um

incremento de produto que gera valor para o usuário.

❖ É um formato comum que permite a todos os envolvidos identificar o que precisa ser feito (qual a funcionalidade), para quem (qual usuário do produto/sistema), e por que (qual o benefício é esperado por essa funcionalidade)

❖ É papel do Product Owner, ao elaborar o Sprint Backlog garantir que todas as histórias estejam formatas como histórias de usuário.

❖ As histórias de usuário no Scrum possuem o seguinte formato:❖ Eu, como <PAPEL>, desejo <FAZER O QUE>,

para <QUAL O BENEFÍCIO ESPERADO>.

❖ Os detalhes do que precisa ser feito, e como saberemos que aquele item foi “entregue" segundo a ótica do time, deve estar explicitada na “Definição de Pronto”.

❖ Outra informação importante é o “critério de aceite” da história, que detalhe qual o critério de sucesso que a história precisa atingir para ser considerada “aceita" pelo PO.

Histórias de Usuário - Critério de Aceite❖ Define os limites do que deve e do que não deve ser feito ao longo do

desenvolvimento da história

❖ Fornecem um conhecimento compartilhado (time, PO, SM) sobre o que deve ser feito.

❖ Guiam o time para evitar a adição de características de baixo (ou nenhum) valor agregado nas funcionalidades, focando os esforços em garantir desenvolver o mínimo necessário para entregar o valor proposto.

❖ Normalmente são expressos em frases curtas e simples e adicionados às histórias do usuário ao longo das sessões de refinamento do backlog, ou no máximo nas reuniões de planning.

❖ São o principal guia dos testes de aceitação, também fazendo parte da definição de “pronto” para a história.

Burn Charts & Velocidade❖ É um gráfico que tem por objetivo acompanhar o progresso as atividades do

sprint

❖ Existem 2 “sabores" de burn charts:

❖ Burn Down: acompanha o trabalho que AINDA FALTA ser feito

❖ Burn Up : acompanha o trabalho que já foi feito

❖ O gráfico, na verdade, consiste de 2 gráficos juntos (um mostrando o “esperado" e outro mostrando o “realizado), sendo que em um eixo temos o trabalho e no outro o tempo

❖ Considerando que ao longo do sprint não temos nenhum trabalho “adicionado”, é esperado que o burn chart seja uma curva “bem comportada” seja para cima (burn up) seja para baixo (burn down)

Burn Charts & VelocidadeBurn Chart

❖ É um gráfico que tem por objetivo acompanhar o progresso as atividades do sprint

❖ Existem 2 “sabores" de burn charts:❖ Burn Down: acompanha o trabalho que

AINDA FALTA ser feito❖ Burn Up : acompanha o trabalho que JÁ FOI

feito❖ O gráfico, na verdade, consiste de 2 gráficos juntos

(um mostrando o “esperado" e outro mostrando o “realizado), sendo que em um eixo temos o trabalho e no outro o tempo

❖ Considerando que ao longo do sprint não temos nenhum trabalho “adicionado”, é esperado que o burn chart seja uma curva “bem comportada” seja para cima (burn up) seja para baixo (burn down)

Velocidade❖ Velocidade é uma medida de “capacidade” de

um time, indicando, na média, quantos pontos um determinado time consegue entregar por sprint.

❖ A velocidade é calculada somando todos os pontos entregues pelo time no sprint, e ajustando esse valor ao longo de sprints sucessivos

❖ Por exemplo: se você diz que o time A tem velocidade de 20 pontos, significa que na média ele consegue entregar 20 pontos por sprints

❖ Muitos profissionais experiências no mundo Ágil tem resistências com essa métrica, uma vez que o ponto em sí já é uma abstração ruim (e imprecisa) da capacidade do time.

Burn Charts

Incremento de Produto❖ Incremento de produto é o resultado das histórias

entregues sprint a sprint.

❖ Esse incremento pode ou não ser disponibilizado para o usuário / cliente final (seja em forma demo, beta ou mesmo produto final).

❖ Essa decisão é tomada pelo Product Owner.

❖ O incremento de produto pode ser funcional ou não. Mas é fundamental que ele agrega valor ao produto ou ao usuário.

Taskboard❖ Quadro físico ou virtual onde as

atividades e tarefas do sprint são visualizadas e “gerenciadas”.

❖ Normalmente organizado em 3 colunas “básicas" : To-Do, Doing, Done (ou variações dessas colunas), mas pode ter mais colunas conforme decidido pelo time

❖ Deve mostrar claramente o andamento/progresso do time, inclusive seus (eventuais) impedimentos

O processo do Scrum - Revisão

Mitos & Fatos - Mais ComunsSobre o papel do Product Owner

❖ Mito: O PO é o representante do cliente, as vezes sendo o próprio cliente

❖ Mito: O PO deve cobrar do time o compromisso que todos os itens escolhidos para o Sprint sejam entregues

❖ Mito: A presença do PO é opcional

❖ Mito: O PO é o dono do time

❖ Fato: O PO deve balancear necessidades e desejos de diferentes stakeholders, mas só ele pode alterar o backlog do produto

❖ Fato: É responsabilidade do PO definir o produto certo a ser desenvolvido

❖ Fato: Deve existir um e somente um PO

Sobre o papel do Scrum Master

❖ Mito: O SM é o dono do time

❖ Mito: O SM gerencia o trabalho do time

❖ Mito: O SM precisa ter experiência como desenvolvedor

❖ Fato: O SM trabalha para remover todo e qualquer impedimento do time

❖ Fato: Ao impor, opinar e/ou interferir nas decisões de trabalho do time, o SM se torna menos eficiente como facilitador

❖ Fato: A meta do SM desenvolver o time a ponto dele mesmo ser desnecessário

❖ Fato: O SM trabalha para que o Scrum seja devidamente seguido e utilizado.

Falácias da Agilidade❖ O Product Owner não participa da

retrospectiva.❖ E se o “problema" for o PO?

❖ “Escalar" agile é fácil, tem receita pronta para isso.❖ Agile é baseado em pessoas e não em

processos. Escalar um processo baseado em pessoas é fácil?

❖ Agile não tem documentação.❖ Em qual princípio isso está escrito?

❖ Agile é só um processo.❖ E aquela questão de “people over

process”?

❖ Valor é só o que tem interface para o usuário.

❖ Quer dizer que se você deixar o sistema 100x mais rápido e conseguir atender 100x mais usuários, isso não tem nenhum valor?

❖ Ágil é "coisa" só para TI.

❖ O mindset é só de uma classe de profissionais? Por que?

❖ Ágil só funciona em startup

❖ Não é isso que o FBI ou a Federal Express, ou ainda o Salesforce dizem não…

Algumas questões polêmicas❖ Scrum vs PMBoK : É um erro preconizar o fim do PMI ou do PMBoK. Eles servem a

propósitos diferentes. Scrum é mais eficiente para projetos de tecnologia cercados de incerteza (o que não significa que não pode/deve ser usado em outros domínios).

❖ Mas muitas das ferramentas descritas no PMBoK são muito úteis e oferecem um ferramental mais estruturado para a gestão de projetos

❖ Os papeis do Scrum existem por uma razão. Então se você não tem os papeis sendo seguidos você não está fazendo Scrum.

❖ Parte do “problema" do Scrum é que ele é prescritivo (ao invés de descritivo). Ou seja, ele dá muita liberdade para o time se organizar para atingir os objetivos do sprint e do release. Onde está o problema?

❖ Se o time é imaturo, ele demora muito (se conseguir), até conseguir se auto-organizar, e começar a atuar como um time de verdade. E maturidade não tem a ver com qualidade técnica.

Resources❖ Scrum Alliance (http://www.scrumalliance.org)

❖ Scrum Org. (scrum.org : Ken Schwaber)

❖ Scrum Log (http://jeffsutherland.com/)

❖ Meta Frameworks para “escalar" métodos ágeis:

❖ SAFe

❖ LeSS

❖ Nexus

❖ Scrum @ Scale

Alberto A. Caeiro Júnior, CSPO, CSM, PMP

Head of Engineering, Módulo Security Solutions

Obrigado!