SIGEPRO - Mini Curso sobre Métodos Ágeis de Gestão de Projetos

Transcrição

1 SIGEPRO - Mini Curso sobre Métodos Ágeis de Gestão de Projetos Jonas Analista de Negócios e Gerente de Projetos Fone: Jonas.dc.cardoso@gmail.com 1

2 PROJETO Esforço temporário* para criar um produto, um serviço ou um resultado exclusivo. * inicio e fim (quando atingir os objetivos). 2

3 PROJETO É composto, basicamente por: META / OBJETIVO TEMPO CUSTOS / ORÇAMENTO PESSOAS 3

4 Gestão de Projeto, fácil de entender, mas difícil de aplicar! Tipo o cubo magico Mas por que? 4

5 A natureza de um projeto: se você não fizer nada, automaticamente, ele sairá errado; 5

6 Dependência do Produto. Para o projeto ser um sucesso é imprescindível que o produto seja um sucesso, mas para ele ser um fracasso não depende do produto; 6

7 Vários caminhos Vários interesses 7

8 Praticas de Gerenciamento Projetos de Escopo Aberto (Change-Driven) - Desenvolvimento de produtos Digitais; - Melhoria continua de produto; - Projetos de escopo indefinido. PMBOK Projetos de Escopo Fechado (Plan-Driven) - Móveis sob medida; - Construção Civil; - Infraestrutura de TI; 8

9 Quando usar o que? 9

10 Melhores práticas: 1 - Veja o todo! 2 - Pense como Cliente! 3 - Analise para determinar o que tem valor! 4 - Valide seus conceitos com exemplos reais! 5 - Procure entender o que é possível de ser realizado! 6 - Estimule a colaboração e a melhoria contínua! 7 Evite Desperdiço! 10

11 MANIFESTO ÁGIL Indivíduos e interação entre eles mais que processos e ferramentas 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 Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda. Fonte: 11

12 Manifesto Ágil: Valores e os Princípios que Scrum se apóia. PRINCÍPIOS 1) Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor 2) Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas; 3) Entregar software funcionando com freqüência, na escala de semanas até meses, com preferência aos períodos mais curtos; 4) Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto; 5) Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho; 6) O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara; 7) Software funcional é a medida primária de progresso; 8) Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes; 9) Contínua atenção à excelência técnica e bom design, aumenta a agilidade; 10)Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito; 11)As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis; 12)Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo 12

13 SCRUM 13

14 PILARES DO SCRUM Scrum Transparência Inspeção Adaptação 14

15 CICLO ITERATIVO DO SCRUM (SPRINT) 15

16 PAPÉIS DO SCRUM RELEASE RELEASE SPRINT SPRINT VISÃO MACRO mgnt (Product Owner) MICRO mgnt (Dev. Team) PROCESS mgnt (Scrum Master) 16

17 PROFISSIONAL SCRUM I T PROFISSIONAL I Extremamente especializado PROFISSIONAL T Possui especialidade, mas tem a visão o todo 17

18 FERRAMENTAS E PRÁTICAS ÚTEIS DA METODOLOGIA ÁGIL GESTÃO À VISTA KAN BAN BOARD: Objetivo: dar visibilidade de forma rápida e simples do que será feito, está sendo feito e foi feito. Contém normalmente tarefas e responsáveis. Exemplo de quadro de Kanban para desenvolvimento de software Quadro simples de Kanban 18

19 FERRAMENTAS E PRÁTICAS ÚTEIS DA METODOLOGIA ÁGIL REUNIÃO DIÁRIA Objetivo: cada integrante dá um status da tarefa por que se responsabilizou, o que foi feito, o que será feito e se encontrou algum impedimento. Normalmente é feito à frente do quadro de kan ban. 19

20 ENTÃO, COMO FUNCIONA O SCRUM? VISÃO PRODUCT BACKLOG Produto/Solução Público/Cliente Alvo; Problemas que irá resolver; Benefícios; Macro-funcionalidades; Diferenciais (...) Projeto Restrições Prazo / Custo Definições de Arquitetura Risco Papéis / Alocações (...) Processos Conformidades Configuração do Scrum Tempo da Sprint Done / Ready Scrum And (...) Prioridade: + Valor de Negócio REQUISITOS Sprint Planning (2h): primeira parte (D.O.D) PO seleciona e detalha os itens prioritários para a Sprint Sprint Planning (2h) : segunda parte (D.O.R) Dev. Team quebra os requisitos em tarefas, define esforço e avalia se cabe na Sprint Agora, o time (todos) podem definir a Meta da Sprint = compromisso

21 SPRINT BACKLOG INICIO DA SPRINT REQUISITOS TAREFAS (priorizados e detalhados pelo PO) (definidas e com esforço estimado pelo Dev. Team). Facilidade de quebrar ligado ao conhecimento Quadro de Tarefas ( Kanban )

22 Sprint Review (2h): Dev. Team apresenta as entregas ao PO para que ele as validar (conforme a meta da Sprint). Daily Meeting (15min): equipe apresenta o que fez, o que fará e fala se há algum impedimento Lei de Parkson e Sindrome do Estudandte. Análise do bom, a melhorar e ações Foco: aprimorar o produto e inspeção

23 FIM DA SPRINT (2 semanas) Retrospective Meeting (2h): Todo o Time Scrum analisa o que foi bom, o que melhorar e como melhorar. Foco: aprimorar o processo

24 TA, ENTÃO... Scrum: Fácil de entender; difícil de aplicar. Sprint: algo que está pronto e que queremos o feedback do cliente (pode entrar em produção ou não); Release: é um pacotão que entrará em produção para o cliente final. O PO é quem dá a direção da Sprint. É ele quem diz o que deverá ser feito. A micro-gestão é papel da equipe e não de um GP ou de um analista. O Scrum Master não delega tarefa ou as cobra. Ele cobra que aconteça a micro-gestão. Sua função é educar Atenção: o scrum master não é o GP. Este papel não existe no scrum. Ele foi diluído. Sem Scrum Master, o trabalho vira go horse. Em alto nível o PO responde pelo projeto e não o Scrum Master. 24

25 FEITO? PERGUNTAS? DUVIDAS? Jonas Analista de Negócios e Gerente de Projetos Fone: Jonas.dc.cardoso@gmail.com 25