O documento discute a aplicação do framework Scrum e da metodologia Kanban usando a ferramenta Trello para gerenciar projetos. Ele explica brevemente o que são Scrum, Kanban e Trello e como eles podem ser usados juntos para melhorar a produtividade de equipes.

1. SCRUM-BAN + TRELLO
Uma aplicação ao seu processo

2. Desenvolvedor FullStack há 3 anos. Todos eles
usando Scrum como framework.
Microsoft Evangelist.
AngularJS Enthuasiast.
https://github.com/RonaldoDev
https://twitter.com/_RonaldoDev
http://www.meetup.com/pt/members/188670521/
Institucional

3. O que o Scrum é?
Uma framework milagrosa baseada em conceitos ágeis que
aumenta a produtividade da sua equipe de forma alarmante.
O que o Scrum NÃO é?
Uma framework milagrosa baseada em conceitos ágeis que
aumenta a produtividade da sua equipe de forma alarmante.
O que o Scrum promete?

4. Quem utiliza?

5. • 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 se adiantam as
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.
AGILE MANIFESTO

6. • 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.
AGILE MANIFESTO

7. • 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.
AGILE MANIFESTO

8. • 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.
AGILE MANIFESTO

9. • Stakeholders
• Product Owner
• Scrum Master
• Burndown charts
• User Stories
• Planning Poker
Homework

10. São todas as partes interessadas no produto(cliente,
usuários, representantes de negócios, etc...)
Stakeholders

11. • Representa todos os demais stakeholders (cliente,
usuários, representates de negócios, etc).
• Não é um comitê mas sim uma única pessoa.
• É o único responsável pela manutenção do Backlog.
• Não pode ser o ScrumMaster
Product Owner(PO)

12. • Ensina e treina a equipe de forma que ela seja auto
gerenciável e multifuncional.
• Garante que os valores e as práticas do Scrum foram
entendidos pelo time e estão sendo seguidas.
• Ensina/Garante que o Product Owner também está
desempenhando seu trabalho.
• Remove impedimentos (visíveis e não-visíveis)
(internos e externos)
Scrum Master

13. • Não é o líder técnico (guru).
• Não deve ser o Product Owner
• Não gerencia ou dirige a equipe.
• Não toma decisões pela equipe.
O que não faz o Scrum Master

14. • Responsável por tornar os requisitos em um produto
para o usuário.
• Responsável pela entrega do produto e pela
qualidade do mesmo.
• Deve ser composto de todos os membros
necessários para tomar decisões e realizar as tarefas, ou
seja ela é multifuncional.
Equipe de desenvolvimento

15. • Responsável pela seleção, detalhamento das
atividades e estimativas de cada Sprint e pelo
comprometimento do trabalho a ser executado, ou seja
ela é auto gerenciada, nenhum gestor define quem irá
realizar determinada tarefa.
Eles se auto organizam para realizar e terminar o
prometido no prazo especificado.
• Compartilham as responsabilidades
Equipe de desenvolvimento

16. Sprint

17. • O Product Backlog é uma lista contendo todas as
funcionalidades desejadas para um produto. O
conteúdo desta lista é definido pelo Product Ownder.
O Product Backlog não precisa estar completo no
início de um projeto. Pode-se começar com tudo
aquilo que é mais óbvio em um primeiro momento.
Com o tempo, o Product Backlog cresce e muda à
medida que se aprende mais sobre o produto e seus
usuários.
Product Backlog

18. O Sprint Backlog é uma lista de tarefas que o Scrum
Team se compromete a fazer em um Sprint. Os itens do
Sprint Backlog são extraídos do Product Backlog, pela
equipe, com base nas prioridades definidas
pelo Product Owner e a percepção da equipe sobre o
tempo que será necessário para completar as várias
funcionalidades.
Sprint Backlog

19. Release Planning
• Clarificar as prioridades dos itens do backlog;
• Estabelecer o objetivo (macro) de cada entrega/iteração;
• Identificar o número de iterações (sprints) necessárias;
• Identificar os principais riscos.
• Sprint Planning
Esta é a reunião de Planejamento do Sprint.
Input: Product Backlog organizado e priorizado/ordenado.
Output: O objetivo do sprint.
Daily Scrum
• O que foi feito desde ontem?
• O que planeja fazer de hoje até amanhã?
• Qual o impedimento (se houver)?
Meetings/ Cerimônias

20. Sprint Review / Demo
É a reunião para a apresentação do produto produzido durante o Sprint.
A apresentação atrai feedback vital dos stakeholders;
Força a equipe a realmente terminar as coisas e liberá-las (mesmo que seja
apenas em um ambiente de teste)
Retrospectiva
É a reunião de lições aprendidas– o que podemos fazer melhor no próximo
sprint?
• Bom: se pudéssemos faríamos do mesmo modo.
• Poderia ter sido melhor: faríamos tal ítem de maneira diferente;
• Melhorias: ideias concretas de como melhorar o processo / ferramentas, etc...
...no próximo sprint.
Meetings/ Cerimônias

21. Ciclo de Vida Scrum

22. Kanban

23. Trello

24. Trello
https://trello.com/techmeeting