Foi escolhida a figura da pirâmide em função da estabilidade que ela representa. A pirâmide lean é divida em 3 camadas (estratégia, gerenciamento e engenharia) e ao redor dela são os resultados alcançados ao utilizá-la.
Last active
December 19, 2015 23:09
-
-
Save lcobucci/6033039 to your computer and use it in GitHub Desktop.
Este material são as anotações que fiz no workshop ministrado por Samuel Crescêncio sobre a Pirâmide Lean.
Ficando no topo da pirâmide, a estratégia define os conceitos básicos que orientam a forma de trabalho e os valores da instituição.
- Jidoka: automação inteligente de processos, com o objetivo de remover recursos humanos das atividades repetitivas, apronveitando-os em outras atividades;
- Poka-yoka: criar um processo a prova de erros (ex: checklist);
- Heijunka: Nivelamento de carga nas etapas de produção, evitando ociosidade e sobrecarga.
Apenas produz aquilo que é necessário, no local necessário e na quantidade necessária. Busca o equilíbrio entre produção e demanda.
Parada estratégica na produção para resolução de erros, focando na CAUSA RAIZ. Busca os MOTIVOS das falhas com objetivo de fazer com que o problema não ocorra novamente. De preferência criando testes automatizados que garantam que não haverá recorrência.
Vivenciar as tarefas da linha de produção para conhecer e respeitar as pessoas e seus trabalhos. No momento que alguém lhe interromper o trabalho, parar e dar 100% de atenção para a pessoa, independentemente da importância daquilo que você está fazendo.
Treinamento contínuo das pessoas, para obter maestria nas tarefas. Cada indivíduo possui um coaching, que tem o objetivo de orientar e fazer o empowerment da pessoa que está sob sua tutela, utilizando técnicas como a maiêutica para delegar a responsabilidade a ela, tornando-a parte fundamental do processo.
Mudar processos continuamente, gradativamente e sistematicamente para o crescimento da instituição (através de ciclos Plan-Do-Check-Act).
Analizar processos, buscando desperdícios de tempo nos ciclos (cycle time), somando o tempo total do processo (lead time) e criando o coeficiente de produtividade ao somar as horas que REALMENTE agregam valor ao cliente e dividindo pelo lead time.
- Construir com integridade
- Integridade conceitual: se dá através de um fluxo de comunicação claro e tranquilo entre os desenvolvedores;
- Integridade percebida: estabele nível de comunicação entre devs e stakeholders.
- Respeito às pessoas
- Entrega rápida: entrega contínua de valor, early adoption (pioneirismo)
- Ver o todo: ter a visão dos objetivos estratégicos, possibilita o auto-gerenciamento
- Visibilidade: no modelo tradicional de desenvolvimento a visibilidade do processo é forte apenas no início e no final do projeto
- Adaptabilidade: a capacidade de adaptação de um software desenvolvimento no modelo tradicional diminui cada vez mais com o passar do tempo
- Entrega de valor: no desenvolvimento ágil a entrega de valor é realizada constantemente e não apenas no final do processo
- Risco: quando se utiliza desenvolvimento ágil, é focado inicialmente naquilo que possui maior risco, tendendo à eliminar a possibilidade de risco no final do projeto
- Muda: valor não agregado ao cliente final (ex: documentação excessiva, reuniões improdutivas, ...)
- Muri: sobrecarga de trabalho sobre os recursos (físicos e humanos). Extremamente nociva por diminuir a qualidade dos resultados. Muitas vezes causada por excesso de falhas.
- Mura: Defeitos ou irregularidades (ex: falhas nos processos, bugs ou qualquer coisa que não deveria estar ali)
- Estoque
- Documentação não codificada
- Código não documentado
- Código não testado
- Código que não foi pra produção
- Código não sincronizado (fora do repositório, ou apenas na máquina do desenvolvedor)
- Funcionalidades extras (que nunca serão utilizadas)
- Excesso de processos
- Espera
- Defeitos
- Complexidade (código, forma de comunicação com clientes, modelo de negócio, ...)
A partir do compartilhamento da visão da organização é possível utilizar o empowerment para tornar as pessoas auto-gerenciáveis, responsáveis e partes fundamentais da empresa.
Deve haver comunicação efetiva, todos são responsáveis pelas decisões
- Business experts: analistas de negócio, trazem as necessidades de negócio
- Product Champion: engenheiro chefe, realiza as definições arquiteturais
- Competence Leader: desenvolvedor-líder, facilita a resolução de impedimentos da equipe técnica
- Expert Engineering: desenvolvedores, produzem valor
Importante -> manter registros!
No meio da pirâmide, as técnicas de gerenciamento garantem que o desenvolvimento dos projetos sigam os valores definidos na camada de estratégia. O objetivo principal principal destas técnicas é possibilitar o desenvolvimento incremental através de iterações, entregando continuamente valor aos clientes.
O maior objetivo é que o processo possa ser "puxado" ou invés de "empurrado". Por "empurrado" entendemos como um processo onde as tarefas são DELEGADAS no planejamento, já o processo "puxado" as tarefas não possuem donos pré-determinados, as pessoas são assim responsáveis por "puxar" para si uma tarefa no momento que for desenvolvê-la. Dessa forma não existe a possibilidade de existir sobrecarga nem ociosidade na equipe (evitando desperdícios).
Para possibilitar o desenvolvimento incremental, é necessário quebrar a visão do projeto em estórias (pequenas unidades que representam basicamente uma funcionalidade necessária). Criamos assim uma lista de desejos, conhecida por product backlog, ou simplesmente backlog.
Para que as estórias sejam efetivas, é necessário seguirmos a seguinte estrutura:
Usuário (quem vai fazer a ação) -> ação (descrição do que deve ser criado) -> valor gerado (qual o benefício que a história traz, os motivos).
As estórias também devem também possuir:
- Critérios de aceite: lista de requisitos básicos que DEVEM ser atingidos;
- Restrições: limitações tecnológicas, de negócio ou data limite;
- Estimativa: pontos de esforço (definido pela equipe técnica), risco (analisado pela equipe toda) e valor de negócio (definido pelo PO/stakeholders);
- Prioridade: definida pela posição da estória no backlog;
- Personas (opcional): lista de pessoas fictícias envolvidas, criadas para poder focar nas características do público alvo;
- Wireframes (opcional): conjunto de desenhos que indicam como será a organização visual da funcionalidade.
Obs. 1: Uma estória não deve possuir mais de 20% do esforço total da iteração, caso possua ela deve ser quebrada em outras estórias.
Obs. 2: Idealmente as estórias devem ser independentes.
Após listadas todas as estórias, devem ser definidos o valor de negócio e risco de cada uma. Dessa forma podemos organizar as estórias focando naquilo que podemos dar o MAIOR retorno e diminuir o risco. Assim podemos começar os ciclos de desenvolvimento do produto.
Obs. 1: Ao decorrer do desenvolvimento novas estórias podem ser adicionadas, e as estórias ainda não alocadas para os sprints podem sofrer alterações.
Obs. 2: Para estimativa de valor de negócio e risco, não é utilizada nenhuma escala padronizada, portanto cada instituição pode definir como serão estas estimativas.
Cada ciclo de desenvolvimento é formado por 6 etapas, e todas são importantes para termos as iterações bem planejadas e ocorrêndo sem impedimentos. Ao término do ciclo, todas as tarefas planejas devem ser entreges 100% funcionais. Cada ciclo pode durar o tempo que for acordado, normalmente são 2 semanas (importante não passar de 4 semanas, para que possa haver entrega contínua).
Reunião de planejamento, onde todos participam, seus objetivos são: estimar o esforço de algumas estórias do product backlog e criar o sprint backlog (lista de estórias para a próxima iteração).
O plaining poker é utilizado para estimar o esforço das estórias, seu objetivo é fazer com que a estimativa seja colaborativa e sem influência entre as pessoas. É jogado pela equipe técnica, mas o project owner (PO) deve estar presente para que possam ser tiradas dúvidas. Cada jogador possui um conjunto com as seguintes cartas:
| Carta | Comentário |
|---|---|
| 1 | Fibonacci |
| 2 | ... |
| 3 | ... |
| 5 | ... |
| 8 | ... |
| 13 | ... |
| 20 | Arredondamentos |
| 40 | ... |
| 100 | ... |
| ∞ | Valor imenso |
| ? | Não sei/entendi |
| Descanso de 5 minutos |
Se inicia com a leitura de uma estória do backlog, os jogadores selecionam uma carta e abaixam-a (sem mostrá-la para os outros). Após todos baixarem, as cartas são viradas ao mesmo tempo revelando seu conteúdo.
Caso houverem cartas de valores diferentes, as pessoas que colocaram o maior e menor valor devem dividir com a equipe os motivos que levaram elas utilizarem estes números. Ao fim das explicações, todos recolhem suas cartas e o jogo é jogado novamente para a estória até seja encontrado um acordo sobre o valor. Caso não seja possível chegar num valor comum, o maior valor é utilizado como esforço da estória.
Este procedimento é realizado com as tarefas do backlog até que se tenha estimado uma quantidade de estórias.
Assim que exista um número relevante de estórias com estimativa de esforço, deve ser construída a lista de estórias que será implementada na próxima iteração. Uma vez definido o sprint backlog é fundamental que as estórias contidas nele não sejam alteradas.
A quantidade de estórias do sprint backlog deve estar sempre de acordo com a capacidade produtiva da equipe. Na primeira iteração normalmente não se sabe esta capacidade, portanto é feita uma estimativa (não muito alta, nem muito baixa). Nas próximas deve ser realizada a média das anteriores, buscando sempre alcançar as metas. Exemplo:
| Iteração | Estimado | Realizado | Comentários |
|---|---|---|---|
| #1 | 20 | 15 | Foi utilizado 20 pontos como meta, sem embasamento |
| #2 | 15 | 21 | 15 / 1 = 15 |
| #3 | 18 | 22 | (15 + 21) / 2 = 18 |
| #4 | 19 | (15 + 21 + 22) / 3 = 19.3333 |
Após selecionadas as estórias a equipe técnica se reúne para dividir as estórias em tarefas, discutir as questões técnicas e realizar modelagem de dados usando os conceitos do agile modeling.
Reunião diária da equipe técnica, podendo ou não ter a participação do PO (virtual ou presencial), o objetivo aqui é alinhar as pessoas a respeito do andamento das tarefas (o que foi realizado ontem), organizar o dia (o que será realizado hoje) e dividir problemas que estão atrapalho o andamento (impedimentos).
A ideia desta reunião é ser extremamente rápida (por volta de 15min) e qualquer questão que deva ser aprofundada deve ser resolvida após o término.
Neste processo, alguns membros da equipe técnica organizam junto com o PO as próximas estórias do backlog, reordenando (se necessário) e verificando se as próximas estórias possuem todos os dados necessários para terem o esforço estimado no próximo sprint plaining.
Aqui são verificados se as estórias selecionadas foram concluídas e se os critérios de aceitação delas foram satisfeitos pelas soluções implementadas. Nesta etapa todos membros devem estar presentes (equipe, PO e stakeholders) para que possa ser validada a conclusão do sprint.
Esta é uma das etapas mais importantes, onde o processo todo é revisado. São buscadas as coisas que podem ser melhoradas e as que foram boas, ideias de melhorias são sugeridas e escolhidas para que o próximo sprint seja mais produtivo e com menos impedimentos.
Para uma retrospectiva eficaz podemos seguir os seguintes passos:
- Set the stage: preparar ambiente da retrospectiva (contexto) e determinar limite de tempo
- Técnica de apreciação (pode ser utilizada também no final da retrospectiva): cada pessoa diz algo que aprecia na outra, algo que tenha feito a diferença na iteração. É possível utilizar um objeto (token of appreciation) caso ninguém queira iniciar, desta forma uma pessoa faz a apreciação e entrega o objeto para a pessoa, e esta por sua vez deve fazer o mesmo.
- Gather data: coleta de dados para ver o que deve ser mantido e aprimorado
- Utilizando post-its cada pessoa escreve sua opinião e posicionam numa cartolina (existem várias possibilidades de organizar as opiniões, as imagens abaixo são apenas sugestões)
- Após posicionar os post-its, registra-se (foto) e é feita uma análise olhando de longe para verificar qual a localização da maioria dos papéis;
- Depois os post-its são agrupados pelos assuntos similares (sem tirar da posição)
- Cada pessoa recebe 3 adesivos para votar nos assuntos que acham mais relevantes
- Generate ideas: elencar ideias para resolver as limitações
- Juntam-se os assuntos mais votados e as pessoas desenvolvem ideias para melhorar os sprints, removendo os desperdícios e trazendo mais valor nas entregas.
- Decide what to do: decidir quais das ideias serão utilizadas para aprimorar o processo
- Closing retrospective: fechamento da retrospectiva
Legal @screscencio! Foi muito bom te conhecer e participar do workshop, espero que possamos continuar trocando várias ideias ;-)
Eu estou editando ainda as coisas, mas suas contribuições são mto bem vindas!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Fala Luís, muito legal esse resumo. Segunda, quando for juntar os demais materiais para passar para todos, vou dar um up em algumas coisas aqui. Foi muito bacana ter te conhecido pessoalmente e conhecido tuas idéias e feedbacks pro OnTrack. Grande abraço.