Please enable JavaScript.
Coggle requires JavaScript to display documents.
Management 3.0 Gestão Ágil de Projetos (Princípios Ágeis (Nossa maior…
Management 3.0
Gestão Ágil de Projetos
Início
Processo
de Software
“Processo de software é um conjunto de atividades e resultados
que produzem um produto de associados que software.”
Processo de software é um conjunto de atividades, práticas, métodos e ferramentas necessárias que são utilizadas para transformar os requisitos do usuário num produto de software.
Cenário
Atual
O que o mercado
quer das empresas?
Alta qualidade
Alta produtividade
Alta satisfação do cliente
Custos mais baixos
Entregas previsíveis
Leitura das mentes
Alto retorno do investimento(ROI)
Como está
o desenvolvimento
dos projetos nas empresas
mas por que
usamos processos?
Nós temos
medo de:
Que o projeto produza um produto de baixa qualidade.
Que o projeto atrase.
Que o projeto produza um produto errado.
De precisar de 80 horas por semana;
De quebrar os compromissos;
DE NÃO NOS DIVERTIR.
O custo da
mudança :warning:
No ambiente dinâmico em que estamos
é importante entender que:
Nada é fixo, tudo
muda o tempo todo
:red_flag:B. Boehm (Software Engineering Economics – 1981)
Quanto mais tempo de projeto, mais caro é a mudança : :red_flag:
X
No gráfico de Boehm observamos que
o custo da mudança de erros descobertos tardiamente é muito alto
Com isso costuma-se fazer grandes
investimentos no início em análise e projeto
Cascata e projeto do tipo BDUF
(Big Design Up Front)
Passam a ser sabedoria convencional
X
Mas o custo da
mudança mudou
Novas linguagens/tecnologias e arquiteturas orientadas a
serviço fazem os softwares mais fáceis de serem
alterados;
Computadores estão várias ordens de magnitude mais
velozes e baratos;
Test-Driven Development (TDD) e Integração Contínua
permite a captura de erros rapidamente;
A compilação de um programa não leva mais 1 dia;
Nós temos ferramentas melhores;
X
:checkered_flag:K. Beck (Extreme Programming Explained – 1999) :checkered_flag:
Custo da mudança suavizada
Nós só pagamos pelo que vamos usar;
Nós pagamos por trabalho especulativo, que pode
estar errado;
Se a curva da mudança pode ser suavizada,
investimentos em uma fase inicial do projeto são
desnecessários;
É economicamente viável adiar decisões até o
momento correto;
Tempo e
Incerteza
Se você implementar uma funcionalidade hoje, e
se mostrar inútil no futuro, você perde dinheiro e
oportunidade;
Tempo responde questões e remove incertezas;
. :star:
NÓS PRECISAMOS DE UM PROCESSO QUE
EXPLORE A SUAVIZAÇÃO DA CURVA DE
MUDANÇA E REDUZA A INCERTEZA
Escopo e
Comunicação
Qual percentual de
funcionalidades são
usadas pelos usuários?
O maior custo do desenvolvimento de software utilizando
processos tradicionais são as funcionalidades extras
(Standish Group).
Comunicação
e Escopo
Das funcionalidades
definidas inicialmente:
45% nunca são usadas
13% são utilizadas frequentemente
19% raramente são utilizadas
16% as vezes são usadas
7% sempre são usadas
O pesadelo do
gerenciamento de escopo:
Pergunte aos usuários tudo que eles querem no início do
projeto e eles podem não saber, ou pior, pensar que sabem;
Faça o BUFD;
BDUF é um acrônimo (Big Design Up Front) usado para indicar que todo o desenho da solução é feito antes da execução. Isso é algo bem típico no modelo tradicional de desenvolvimento de software, onde há explicitamente uma etapa de Análise que antecede a etapa de implementação. Assim, no final das contas, BDUF é arte das coisas que não deveriam ser feitas.
Puna-os por mudarem de ideia (requisição de mudança);
80% do valor vem tipicamente de 20% das funcionalidades
Gerenciamento
de escopo
O cliente decide o que vai ser desenvolvido primeiro;
O cliente pode mudar de ideia a qualquer momento;
Desenvolva e instale as funcionalidades que deem o maior valor de negócio, maximizando o ROI;
O trabalho deve ser
interrompido quando:
Acabar o tempo;
Acabar o dinheiro;
Cliente satisfeito com o valor de negócio entregue;
Escreva menos código;
X
E na sua
Empresa?
Estimativas quase sempre equivocadas ?
Falta de visibilidade do estágio atual do projeto
Frases como: “Nós queremos estabilizar os requisitos
e mitigar as mudanças, mas nunca conseguimos.”
Muitas horas extras?
Pouca troca de conhecimentos/soluções técnicas ?
Efetividade da
Comunicação
Metodologias Ágeis
Harvard Business Review, Jan, 1986, Takeuchi e Nonaka
Manifesto para Desenvolvimento
de Software Ágil
Estamos descobrindo maneiras melhores de desenvolver
Software fazendo-os nós mesmos e ajudando outros a fazê-los.
Através deste trabalho, passamos a valorizar:
Software Funcionando sobre documentação abrangente;
Colaboração com o Cliente sobre negociação de contrato;
Indivíduos e Interações sobre processos e ferramentas;
Responder as Mudanças sobre seguir um plano;
ou seja, os itens da direita tem sua importância, porém os itens
da esquerda são ainda mais importantes.
Princípios
Ágeis
Nossa maior prioridade é satisfazer o cliente através de entrega de
software de forma contínua e começando o mais cedo possível;
Aceitamos de bom grado as mudanças de requisitos mesmo em um estágio adiantado de desenvolvimento. Processos ágeis utilizam isso como vantagem competitiva;
Entregamos software de forma contínua e frequente. Quanto maior a frequência, melhor;
Pessoas que Entendem do Negócio e Desenvolvedores devem trabalhar juntos;
Construímos projetos através de pessoas motivadas - criando um
ambiente apropriado, apoiando no que for preciso e confiando que eles vão fazer o trabalho;
A maior e mais eficiente forma de comunicação é a conversa cara a cara;
Atenção contínua a excelência técnica
Software funcionando é a principal métrica de progresso;
Simplicidade é essencial
As melhores arquiteturas, requisitos e designs emergem de times auto-organizados
Práticas são
Ferramentas
não leis
NÃO ADIANTA TER 60% DA
DO ESCOPO FUNCIONANDO
E TUDO DOCUMENTADO !
AGILE NÃO É FICÇÃO
CIENTÍFICA
ELA EXISTE MESMO !
Qual o fator mais
importante do projeto?
Pessoas
SCRUM - è um processo ágil para desenvolvimento de Software
Segue os princípios
do Manifesto Ágil
Os membros do Time e todos os stakeholders devem ter acesso a tudo que está acontecendo
Os objetivos são claramente definidos e todos comprometidos.
As Responsabilidade e Autoridade claramente definidas
-VISIBILIDADE
-HONESTIDADE
-TRANSPARÊNCIA
Orientado a resultados
O Time é responsável pelo trabalho, não o Gerente, nem o Cliente
O Time deve se comprometer com os resultados;
Palavras
Chave
Sprint Planning Meeting
- Reunião de 4 horas onde a equipe define o escopo do sprint, retirando do backlog os itens a implementar;
Sprint
– Conjunto fixo de tarefas fechadas entregues de forma iterativa e curta (de duas a quatro semanas);
Product Backlog
– Conjunto de tarefas ordenadas por prioridade referentes ao trabalho a ser feito;
Daily Meeting
– Reunião diária onde os membros do time falam sobre as atividades em andamento e as que irão fazer, discutindo impedimentos e soluções;
Sprint retrospective
– Avaliação do sprint realizada ao termino do mesmo;
O que é o
Product Backlog ?
Lista de tudo o que é necessário para terminar o projeto;
Funcionalidades, correções, atividades, …
-Visível
-PRIORIZADO
-ESTIMADO
-Mais detalhes para itens prioritários
-Mantido pelo Product Owner
Product Owner
Não pode interferir ou
influenciar nas estimativas !
-É a pessoa que faz a voz do cliente na equipe, faz a ponte entre o cliente e o time;
-Desenvolve e mantém o Product Backlog;
-Prioriza o Product Backlog;
-Apresenta e Explica o Product Backlog para o Time;
-Elimina a confusão de múltiplos chefes, opiniões diferentes e interferência;
-Gerencia Releases.
