Gerenciamento de equipes no desenvolvimento de software

6,196 views

Published on

Gerenciamento de equipes no desenvolvimento de software

  1. 1. 14/11/2011
  2. 2.  Programador com experiência em Clipper, Foxpro, c#, .Net, Java, SQL, PHP, ASP Analista de Sistemas Analista de Negócio Analista de Processos Formado em Desenvolvimento de Aplicações Web – FANESE Pós Graduado em Gestão de Projetos de Software – FANESE Gestor de Projetos da DPSISTEMASContato  (79) 3259-1038  roberto@dpsistemas.com.br  dp.sistemas@gmail.com
  3. 3.  “Projeto de Software é a parte da engenharia de software que se encarrega de transformar os resultados da Análise de Requisitos em um documento ou conjunto de documentos capazes de serem interpretados diretamente pelo programador.”  http://pt.wikipedia.org/wiki/Projeto_de_software
  4. 4.  A única certeza que temos num projeto de software é a mudança.
  5. 5.  Organizar, planejar e executar atividades que facilitem o processo de trabalho. Atividade relativas ao gerente, administrador ou líder. A gerência pode-se dar sobre coisas, pessoas ou ambos. O gerente organiza seu ambiente de trabalho, toma decisões, direciona o trabalho de funcionários ou membros de uma equipe.
  6. 6.  Podemos definir “Equipe”, como um conjunto de pessoas trabalhando para atingir o mesmo objetivo (Projeto);
  7. 7. Pouco Informal Clássico Ágil Planejada• Caos • Pressão • PMI • SCRUM • RUP • LEAN • XP
  8. 8.  Não se sabe o que vai se fazer; Tudo é urgente; Entrega imediata; Não tem como medir eficiência, prazo e custo; Sem gerenciamento de risco; Sem comunicação formal; Tarefas não documentadas;
  9. 9.  Sabe-se mais ou menos o que vai se fazer; Tudo é urgente; Entrega imediata; Não tem como medir eficiência, prazo e custo; Sem gerenciamento de risco; Sem comunicação formal; Tarefas não documentadas;
  10. 10.  Sabe-se exatamente o que vai se fazer; Tudo é planejado; Entrega é planejada; Pode-se medir eficiência, prazo e custo; Possui processo de implantação. Possui gerenciamento de risco; Possui comunicação formal; Tarefas documentadas;
  11. 11.  Sabe-se mais ou menos o que vai se fazer; Tudo é planejado; Entrega planejada; Tem como medir eficiência, prazo e custo; Pode haver gerenciamento de Risco; Comunicação constante com stakeholder; Tarefas pouco documentadas;
  12. 12.  Uma alternativa de utilizar métodos ágeis na gerência de projetos Pode ser aplicável a qualquer tipo de projeto É simples  Processo, artefatos e regras são poucos e fáceis de entender  A simplicidade pode ser decepcionante aos acostumados com metodologias clássicas
  13. 13.  Clássico  Ágil Qualidade Escopo Escopo Prazo Qualidade Prazo Custo Custo
  14. 14.  Planejamento Sprints  Reuniões Diárias  Revisão  Retrospectivas Encerramento
  15. 15.  Relativamente curto Projeto da arquitetura do sistema Estimativas de datas e custos Criação do backlog  Participação de clientes e outros departamentos ▪ Levantamento dos requisitos e atribuição de prioridades Definição de equipes e seus líderes Definição de pacotes a serem desenvolvidos
  16. 16.  O time recebe uma parte do backlog para desenvolvimento  O backlog não sofrerá modificações durante o Sprint Duração de 1 a 4 semanas Sempre apresentam um executável ao final
  17. 17.  Cerca de 15 minutos de duração Todos respondem às perguntas:  O que você realizou desde a última reunião?  Quais problemas você enfrentou?  Em que você trabalhará até a próxima reunião? Benefícios:  Maior integração entre os membros da equipe  Rápida solução de problemas ▪ Promovem o compartilhamento de conhecimento  Progresso medido continuamente ▪ Minimização de riscos
  18. 18.  Deve obedecer à data de entrega  Permitida a diminuição de funcionalidades Apresentação do produto ao cliente  Sugestões de mudanças são incorporadas ao backlog Benefícios:  Apresentar resultados concretos ao cliente  Integrar e testar uma boa parte do software  Motivação da equipe
  19. 19.  Finalização do projeto Atividades:  Testes de integração  Testes de sistema  Documentação do usuário  Preparação de material de treinamento  Preparação de material de marketing
  20. 20.  Todas as responsabilidades de gerenciamento são divididas entre três papéis:  Product Owner  Scrum Master  Time Para o bom funcionamento do Scrum as pessoas responsáveis pelo projeto devem ter autoridade para fazer o que for necessário pelo seu sucesso Pessoas não responsáveis não podem interferir no projeto  Gera aumento de produtividade  Evita situações constrangedoras para os envolvidos
  21. 21.  Responsável por apresentar os interesses de todos os stakeholders Define fundamentos iniciais do projeto, objetivos e planos de release Responsável pela lista de requisitos (Product Backlog) Certifica se as atividades com maior valor para o negócio são desenvolvidas primeiro  Priorização freqüente das funcionalidades antes de cada iteração
  22. 22.  Responsável pelo sucesso do Scrum Ensina o Scrum para os envolvidos com o projeto Implementa o Scrum na empresa de forma adaptada a sua cultura, para continuamente gerar benefícios Certifica se cada pessoa envolvida está seguindo seus papéis e as regras do Scrum Certifica que pessoas não responsáveis não interfiram no processo
  23. 23.  Responsável por escolher as funcionalidades a serem desenvolvidas em cada interação e desenvolvê-las O time se auto-gerencia, se auto-organiza Todos os membros do time são coletivamente responsáveis pelo sucesso de cada iteração
  24. 24.  O ScrumMaster deve se certificar de que cada envolvido no projeto siga suas regras As regras permitem a execução correta do Scrum Mudanças das regras devem se originar do time  O ScrumMaster deve ser convencido de que todos envolvidos entenderam suficientemente as regras do Scrum para o correto discernimento  Discussões desnecessárias são perda de tempo de produção da equipe
  25. 25. Plan (Planejamento)Do (Execução)Check (Checagem)Act (Ação)
  26. 26.  Escrever teste antes de código (TDD); Programação em pares; Comunicação frente a frente (video conferencia para trabalho remoto); Prescença do cliente; Integração continua; Refatorar codigo quando necessário; Padrões de codificação (design pattern)
  27. 27. Lean (Magro)
  28. 28.  Eliminar todo tipo de desperdício;  Bugs;  Retrabalho;  Interrupções;  Desperdício de mão-de-obra; Eliminar requisitos pouco específicos; Eliminar burocracia; Eliminar comunicação lenta Executar decisões tardia; Entregar o quanto antes; Ampliar aprendizado.
  29. 29. 25201510 50 1940 1950 1960 1970 1980 1990 2000 2010 Complexidade Envolvimento Cliente Documentação Formal
  30. 30.  Qual a melhor abordagem de gerenciamento para o desenvolvimento de software conduzido por metodologias ágeis? Grandes projetos podem ser gerenciados de forma ágil?  Como é possível?  É confiável? Gerenciamento ágil para qualquer tipo de projeto  Construção de edifícios, aviões, robôs  Como é possível?

×