Qualidade de Software | Metodologia Ágil (Scrum) | Palestrante: Guilherme Ítalo Vasconcelos

Slides utilizados em aula na disciplina Qualidade de Software do Instituto de Ciências Exatas e Informática - Sistemas de Informação. Pontifícia Universidade Católica de Minas Gerais - Unidade Barreiro, 1º Semestre 2015.

1. Metodologia Ágil (SCRUM) Guilherme Vasconcelos Guilhermeivasconcelos@gmail.com
2. Motivação • Gartner: 80% usarão até 2012 • 2008 a 2011 triplicou sua adoção
3. • Segundo Standish Group: ''A vasta maioria dos projetos falham por falta de clareza – sobre funções pessoais, responsabilidades e requisitos – e também por inabilidade para acompanhar o que ocorre em cada um dos diferentes passos do ciclo de vida.''
4. Principais problemas em projetos • Falta de planejamento • Mudança constante de requisitos • Escopo mal definido • Falta de participação do cliente • Comunicação falha.
5. Filosofia Ágil
6. Práticas ágeis não são apropriadas para todos os cenários. Em especial, a agilidade é melhor aproveitada nas seguintes situações: • Projetos cujo esforço é intelectual; • Escopo altamente sujeito a mudanças; • Restrições agressivas de tempo.
7. Filosofia Ágil
8. Tradicional Ágil Waterfall/Cascata/Sequencial Iterativo e Incremental Planejamento e Controle Inspeção e Adaptação Orientado a processos Orientado a pessoas Orientado a camadas Orientado a fatias Negociação de contrato Negociação de parceria
9. Scrum Origem Papéis Artefatos Eventos
10. Scrum
11. Scrum • Product Owner • Responsável por garantir o ROI (Retorno de Investimento); • Responsável por conhecer as necessidades do(s) cliente(s); • Proxy em ambientes com mais de um cliente; • ScrumMaster • Responsável por remover os impedimentos do time; • Responsável por garantir o uso de Scrum; • Protege o time de interferências externas; • Time • Definir metas das iterações; • Auto-gerenciamento; • Produzir produto com qualidade e valor para o cliente;
12. Scrum Master Como um ScrumMaster ScrumMaster você deve: • Remover a barreira entre desenvolvimento e cliente • Ensinar o cliente a maximar o ROI e atingir seus objetivos através do Scrum • Melhorar o dia-a-dia dos membros do time facilitando a criatividade e fortalecimento • Combater a ilusão do comando-controle • Priorizar os impedimentos e combatê-los • Determinar onde Scrum está, comparado com onde poderia estar • Auxiliar o Product Owner com o Product Backlog • Garantir uso do Scrum • Facilitar reuniões
13. Product Owner Como um Product Product Owner você deve: • Definir a visão do produto (product vision); • Gerenciar o retorno de investimento ( ) ROI ; • Apresentar ao time os requisitos necessários para a entrega do produto; • Priorizar cada requisito de acordo com seu valor para o negócio/cliente; • Gerenciar a entrada de novos requisitos e suas priorizações; • Planejar entregas (releases) ; • Atuar como facilitador quando mais de um cliente estiver envolvido no projeto; • Garantir que Especialistas de Domínio estejam disponíveis para o time;
14. Time Times Scrum são: • Auto-organizados • Multidisciplinares • Compostos por no máximo 9 integrantes • Comprometidos com o trabalho • Responsáveis por fazer aquilo que for necessário para atingir a meta da Sprint • Comunicativos • Organizadas em um espaço físico apropriado para o trabalho • Responsáveis pela resolução de conflitos
15. Processo Scrum
16. Sprint • A Sprint é um time-box de 2 a 4 semanas semanas no qual o time do projeto projeto irá produzir produzir uma parte do produto definida pelo cliente • O conceito de Sprint nos remete à necessidade de estarmos frequentemente entregando algo de valor para o cliente. Diferentemente dos modelos tradicionais”, onde você desenvolve o produto em um longo período de tempo e, apenas no final – com o produto “pronto” - o entrega ao cliente, em Scrum você sempre entregará “parte” do produto em pequenos intervalos de tempo, sendo que esta “parte” é a prioridade do cliente, ou seja, o que ele realmente está precisando naquele momento • Uma Sprint deve ser empreendida por um time multidisciplinar com não mais que 9 membros • Cada Sprint deve ter uma meta específica específica que represente represente o desejo do cliente cliente para aquele time-box específico
17. Scrum – Product Backlog • O primeiro passo em um projeto Scrum é de responsabilidade do Product Owner, que deve articular a visão do produto; • Representa esta visão, ele deve ser apresentado no formato de uma lista com itens priorizados e ordenados de acordo com o valor que representam para o cliente e negócio;
18. O Product Backlog irá existir por todo o ciclo de vida do projeto (e não da sprint),e é regularmente atualizado pelo P.O para refletir as mudanças e necessidades do cliente, mudanças estratégicas ou tecnológicas, novas idéias, enfim...mudanças; • Um Product Backlog é composto composto de vários tipos de itens: funcionalidades, requisitos de desenvolvimento, exploração técnica, estudo, documentação, bugs, etc. • Apenas um Product Backlog deve existir, e ele deve definir uma visão de tudo que precisa ser feito;
20. Scrum – Daily Meeting • O que eu fiz desde a ultima reunião? • O que pretendo fazer? • Estou tendo algum impedimento? A daily meeting não é: • Café • Bate papo • Conversa sobre relação
21. Sprint Planing
22. Sprint Planing
23. Release planing
24. Scrum – Sprint Review Apresentação do resultado da iteração para os clientes • •Todos os envolvidos no projeto participam: • Devolver ao Product Backlog funcionalidades não terminadas e repriorizá-las • Remover do Product Backlog funcionalidades que foram finalizadas antecipadamente. • Trabalhar com o ScrumMaster para reformular a equipe
25. • Repriorização do Product Backlog • Solicitar o fechamento de um Release com as funcionalidades demonstradas , sozinhas ou com o incremento de Sprints anteriores • Escolha não avançar mais com o projeto e não autorizar outra Sprint • Solicitar que o progresso do projeto seja acelerado autorizando a inclusão de times adicionais para trabalhar no Product Backlog
26. Scrum – Sprint Retrospective • Melhoria de processos no final de cada Sprint • Falicitada pelo ScrumMaster • O que foi bom? O que deve ser melhorado? • O ScrumMaster prioriza os itens citados de acordo com a direção do time • O t time propõe soluções para a maioria dos problemas que a atrapalham/irritam • Retrospectivas são a essência do conceito de inspeção e adaptação
27. Duvidas?
28. • Guilherme Vasconcelos • guilhermeivasconcelos@gmaii.com • Guilherme Vasconcelos • guilhermeivasconcelos@gmail