Este documento resume as qualificações e experiências de um profissional de TI, incluindo programação, análise de sistemas e gestão de projetos. Ele fornece seus contatos e apresenta conceitos sobre metodologias ágeis como SCRUM.

1. 14/11/2011

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 DPSISTEMAS
Contato
 (79) 3259-1038
 roberto@dpsistemas.com.br
 dp.sistemas@gmail.com

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.  A única certeza que temos num projeto de
software é a mudança.

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.  Podemos definir “Equipe”, como um
conjunto de pessoas trabalhando para atingir
o mesmo objetivo (Projeto);

7. Pouco
Informal Clássico Ágil
Planejada
• Caos • Pressão • PMI • SCRUM
• RUP • LEAN
• XP

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.  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.  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;

12.  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;

13.  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

14.  Clássico  Ágil
Qualidade Escopo
Escopo Prazo Qualidade Prazo
Custo Custo

15.  Planejamento
 Sprints
 Reuniões Diárias
 Revisão
 Retrospectivas
 Encerramento

16.  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

17.  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

18.  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

19.  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

20.  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

21.  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

22.  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

23.  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

24.  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

25.  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

27. Plan (Planejamento)
Do (Execução)
Check (Checagem)
Act (Ação)

29.  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)

30. Lean (Magro)

31.  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.

32. 25
20
15
10
5
0
1940 1950 1960 1970 1980 1990 2000 2010
Complexidade Envolvimento Cliente Documentação Formal

34.  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?