Produtividade em Desenvolvimento de Software

ProdutividadeemDesenvolvimentodeSoftware
by rildosan® v6-2016
#deveweb
Produtividade em
Desenvolvimento de Software
Rildo Santos (@rildosan)
www.etecnologia.com.br
rildo.santos@etecnologia.com.br
rildosan@rildosan.com
skype: rildo.f.santos
10 mitos sobre produtividade em desenvolvimento de software
1

#deveweb
Produtividade em Desenvolvimento de Software
1 - Foco. O enigma do fator de foco
2 - Estimativa não é prazo
3 - Desempenho da equipe. Quem anda rápido é um carro de F1
4 - Métodos ágeis. Scrum não é bala de prata
5 - Escolha duas opções: Prazo, Qualidade e Custo
6 - Priorização. Quando não se prioriza tudo é importante
7 - Tecnologias emergentes. Só sei que nada sei
8 - Comunicação. É simples quando flui
9 - Desengajamento e imaturidade, é a receita para resultados inconsistentes
10 - Líder, Salvador da Pátria ou Super Herói. Quem poderá me ajudar?
Produtividade em desenvolvimento de software é cercada de mitos e tabus, às
veze ela é ela ignorada, outras vezes incompreendida e até confundida com
velocidade da equipe, eficácia, eficiência, efetividade, retorno de investimento e
etc.
A palestra apresenta e discute os principais mitos e fatores que influenciam a
produtividade em desenvolvimento de software na experiência do palestrante.
2@rildosan | www.etecnologia.com.br | rildo.santos@etecnologia.com.br

ProdutividadeemDesenvolvimentodeSoftware Palestrante:
Apaixonado por Tecnologia, Inovação e Gestão.
Sou consultor, estrategista, mentor, facilitador, arquiteto de software, palestrante, escritor.
Também sou ex-desenvolvedor java.
Tem mais de 10 mil horas de experiência em Gestão, Inovação, Engenharia de Software
e Métodos Ágeis.
Sou presidente do BCI (Business Case Institute) capítulo Brazil.
www.businesscaseinstitute.org
Atua com Pessoas, Inovação, Planejamento Estratégico, Processos, Gestão, Análise de
Negócio, Liderança, Empreendedorismo, Tecnologia da Informação e Métodos Ágeis.
Sou Administrador de Empresas, Especialista em Didática do Ensino Superior e
Mestrando em Engenharia da Software pelo Mackenzie.
Minha experiência com Desenvolvimento de Software vem projetos onde trabalhei
como Instrutor Java, Desenvolvedor, Arquiteto de Software, Consultor de
Tecnologia e Agile Coach.
@rildosan | www.etecnologia.com.br | rildo.santos@etecnologia.com.br 3

Mentoria
Serviços da eTecnologia
Treinamento
Consultoria
Desenvolver e
capacitar pessoas
Pessoas
capacitadas
Necessidades e
Expectativas
eTecnologia oferece um conjunto de serviços com objetivo de transformar e gerar
valor para as organizações:
Resultados
e Valores
Ganhos:
Eficiência
e Eficácia
Ganho:
Efetividade
4
Transformação
de resultados
Melhoria de
Desempenho da
Empresa
Pessoas
habilitadas
@rildosan | www.etecnologia.com.br | rildo.santos@etecnologia.com.br
Desenvolver
habilidades

ProdutividadeemDesenvolvimentodeSoftware Compartilhamento de Conhecimento:
5
Acesse: www.slideshare.net/ridlo/presentations
Compartilhamento de conhecimento é parte da missão da eTecnologia:
Contribuímos para que as pessoas possam alcançar seus sonhos pessoais e
profissionais.
Publicamos nosso conteúdo, apresentações no slideshare, faça uma visita.
* Já alcançamos a
marca de mais de
1.000.000 de
views

1 - Foco
Foco. O enigma do fator de foco

7
1- Foco. O enigma do fator de foco
100%
Fator de Foco
Foco e disponibilidade
em único projeto
Fator de Foco (FF) demonstra como uma equipe é focada e sua disponibilidade
para atuar em projetos. Exemplo abaixo mostra o FF da Marina, ela tem 100%
do seu tempo disponível e foco em único projeto, ou seja, ela tem o FF 100%.
Quando maior o FF, maior as chances de alta produtividade

8
50%
Fator de Foco
Projeto CRM
Novas Funcionalidades
50%
Fator de Foco
Este exemplo mostra o FF do Rafael, ele tem 50% do seu tempo dedicado para
desenvolvimento de novas funcionalidades e 50% para de correção de bugs.
O Rafael tem o FF 50%.
Projeto CRM
Correção de Bugs
Quando menor o FF, menor as chances de alta produtividade

Fator de Foco
25%
Projeto A
9
25%
Fator de Foco
Projeto A
25%
Fator de Foco
Projeto C
25%
Fator de Foco
Projeto D
Quando menor o fator de foco por projeto, maior as chances de impacto na
produtividade, ou seja, baixa produtividade.
Este exemplo mostra FF do João, ele atua em quatro projetos distintos:
Melhorias, Novas funcionalidades, Correção de bugs e Customização.
João tem o FF 25%.

10
Fator de Foco da equipe de desenvolvedores para Projeto xCode para uma Sprint
FF = 100%
20 Dias
Disponíveis
FF = 100%
20 Dias
Disponíveis
FF = 50%
10 Dias
Disponíveis
FF = 20%
4 Dias
Disponíveis
FF = 50%
10 Dias
Disponíveis
FF = 100%
20 Dias
Disponíveis
FF = 100%
20 Dias
Disponíveis
FF = 10%
2 Dias
Disponíveis
Quando menor o fator de foco da equipe por projeto, menor produtividade...

2 - Estimativa
2 - Estimativa não é prazo

ProdutividadeemDesenvolvimentodeSoftware 2 - Estimativa em desenvolvimento de software
Um dos desafios do processo de Desenvolvimento de Software é definir o prazo
de entrega. Para vencer este desafio, é necessário fazer estimativas.
Por que Estimar é Difícil ?
- Estimativa (no mundo real) representa um valor aproximado.
- Estimativa (em desenvolvimento de software) para algumas pessoas representa
um valor exato.
Técnicas para fazer Estimativas:
Para definir um prazo de entrega é preciso fazer estimativa. Existem diversas
técnicas para fazer estimativas:
- Análise de Ponto de Função (APF)
- Use Case Point (Pontos de Casos de Uso)
- Planning Poker (prática ágil)
- Dias Ideais (prática ágil).
Entretanto, independente da técnica escolhida, estimar é dar uma previsão de
data de quando o software ficará pronto.
Estimativa não é prazo. É uma previsão de prazo.

ProdutividadeemDesenvolvimentodeSoftware 2 - Estimativa não é prazo
Podemos considerar a estimativa como um palpite, mas não há comprometimento,
nenhuma promessa foi feita.
Estimativas podem ser classificadas:
- Estimativa otimista
- Estimativa pessimista
- Estimativa Realista
Estimativas são cheias de erros, por isso são chamadas de estimavas. Uma
forma de tratar o erro é usar a vantagem oferecida pela Lei dos Números
Grandes. Quebrar tudo em pequenas partes e estima-las. Exemplo:
Estimar as histórias do usuário.
Desenvolvedores tem uma visão
otimista em relação a estimativa,
geralmente eles dão a menor data
mesmo sabendo que não podem ou
não vão cumprir.
Encarar a estimativa como um prazo certo causa impacto na produtividade,
da equipe e alguns casos cobranças indevidas que leva stress a equipe.
Recomendação: Utilizar o conceito de timebox (tempo imutável), no Scrum
ele está presente em alguns eventos e nas Sprints, pois, desta forma a
discussão passa a ser o que a equipe pode produzir em 30 dias.

3 - Desempenho
da equipe
3 - Desempenho da equipe.
Quem anda rápido é um carro de F1

ProdutividadeemDesenvolvimentodeSoftware 3 - Desempenho da Equipe
Velocidade não é produtividade, pois a velocidade depende do nível de
maturidade da equipe, do nível de complexidade do trabalho, do uso de
tecnologias emergentes e etc...
A velocidade mede a quantidade de pontos que podem ser feitos em
uma Spring.
A produtividade diz respeito a entrega da meta da Sprint.
Questões chaves:
- Quantos pontos conseguimos fazer dentro de um Sprint?
- Conseguiremos entregar a meta da Sprint?
Para responder estas questões precisamos saber qual é velocidade
da equipe...
Mas, velocidade não quer dizer alta velocidade. Quem anda rápido é um carro
de F1...

ProdutividadeemDesenvolvimentodeSoftware 3 - Desempenho da Equipe
Estimar as “Histórias do Usuário”:
Se a Estória do Usuário tem 8 pontos e a equipe tem a velocidade de 2 pontos por
dia, isto significa que a equipe precisará de 4 dias para implementar a Estória.
Titulo: Impressão do Livro Diário
Prioridade: Alta
Quem ?
como um contador
O que ?
preciso fazer a impressão do livro diário
Por que ?
com objetivo atender a legislação
Pontos: 8
Exemplo de Histórias do Usuário:
Importante:
Para fazer a estimativa, você deve levar em consideração outros aspectos além da codificação da
História, como por exemplo: realização do teste unitários, preparação do ambiente de teste e outras
coisas que são necessário e importantes (mesmo que elas sejam de baixo valor para o negócio) para
que você entregue o software funcionando.

4 - Métodos
Ágeis
Métodos ágeis. Scrum não é bala de prata

ProdutividadeemDesenvolvimentodeSoftware 4 - Métodos Ágeis
Artefatos
Sprint
Backlog
Produto
Planejamento
da Sprint
Reunião
diária
2-4 Semanas
24 horas
Revisão
da Sprint
Retrospectiva
da Sprint
Visão
Reuniões
Product
Backlog
Legenda:
• Product Owner (PO)
• ScrumMaster (SM)
• Equipe Desenvolvimento
• Product Backlog
• Sprint Backlog
• Incremento do Produto
Papéis
Eventos (Reuniões)
Artefatos
 Planejamento da Sprint
 Diária
 Revisão da Sprint
 Retrospectiva da Sprint
Pré-Game Game Pós-Game
The New, New
Product
Development
Game
TimeBoxes
Iterative,
Incremental
Development
SmallTalk
Engineering
Tools
Adotar o Scrum, que é um método ágil, não aumenta a produtividade da equipe...
Pois, ele não resolver todos os problemas do desenvolvimento de software...
“Scrum não é bala de prata”

Gestão de Demanda
Backlogde
Demandas
Novas funcionalidades
Melhorias
Bugs (Correções)
Novas funcionalidades = Melhorias = Bugs
Sim
Não
4 - Métodos Ágeis

Gestão de Demanda: Sim são iguais
Planejamento
Desenvolvimento (Sprint)
Reuniões Diárias (inspeção)
Revisão da Sprint
Retrospectiva (Adaptação)
Teste
Liberação
Scrum é bala de prata
4 - Métodos Ágeis

Backlog
Backlog do
Produto
Demanda
Sprint Backlog
Sprint
Reunião diária
Revisão do
produto
Retrospectiva
Reunião
Planejamento
Backlog do Produto
Gestão de Demanda
Prazo de Entrega =
Tempo Planejamento +
Duração da Sprint +
Tempo de Teste +
Tempo de Liberação
Custo =
Planejamento +
Sprint + Teste +
Liberação
4 - Métodos Ágeis

Houston, we have a problem
Se são diferentes....
4 - Métodos Ágeis

Bugs (correções) é diferente...pois
Requer pouco ou nenhum planejamento
Pouca ou nenhuma inspeção
Pouca ou nenhuma revisão
Teste, sim
Liberação, sim
Gestão de Demanda: São diferentes
Scrum não é bala de prata
4 - Métodos Ágeis
Ok, são diferentes,
mas como tratar os
bugs ?

Backlog
Backlog do Produto
Novas
funcionalidades
e Melhorias
Bugs
Scrum
Backlog
Sprint Backlog
Sprint
Reunião diária
Revisão do
produto
Retrospectiva
Reunião
Planejamento
Backlog do Produto
Selecionados WIP(1) Teste Feitos
dev1
dev2
dev3
dev4
dev5 t3
t2
t1
1 – WIP = work in progress
Kanban
Kanban
Scrum
4 - Métodos Ágeis
Ganho de
Produtividade
50% no Lead Time
das demandas de
correção de bugs
Demanda

5 - Prazo,
Qualidade e
Custo
Prazo, Qualidade e Custo.
Escolha duas opções

ProdutividadeemDesenvolvimentodeSoftware 5 - Prazo, Qualidade e Custo
Prazo Qualidade
Custo
Produto
Custo Fixo
(Folha de
Pagamento)
Qualidade é
abstrata...
Estimativa é
uma
previsão
Escolha duas opções?
[ x ] Prazo
[ x ] Custo
[ ] Qualidade

ProdutividadeemDesenvolvimentodeSoftware 5 - Prazo, Qualidade e Custo
Escolher Prazo e Custo geralmente é uma
armadilha que leva ao retrabalho, ou seja, o
desprezo pela qualidade do código, falta de testes é
caminho certo para fazer e refazer até dar certo. Em
desenvolvimento de software, a correção de bugs é
um exemplo clássico de retrabalho.
Retrabalho pode matar a produtividade da
equipe, quando maior o percentual de retrabalho
menor será a produtividade.

6 - Priorização
6 - Priorização
Quando não se prioriza tudo é importante
6 - Priorização

Como gerenciar o Backlog de Demandas ?
Como equilibrar a DEMANDA e a
CAPACIDADE de entrega de TI ?
Como reduzir o “gap”
da capacidade da TI ?
Demandas Demandas
6 - Priorização
Com passar do tempo as demandas das áreas de negócio para equipe de
desenvolvimento são muitas e geralmente estão em crescimento, daí surgi o
primeiro grande desafio, como equilibrar as demandas com a capacidade limitada
das equipes de desenvolvimento.

ProdutividadeemDesenvolvimentodeSoftware 6 - Priorização
Para melhorar a produtividade da equipe e responder as demandas é
necessário estabelecer um mecanismo (baseado em critérios) para priorizar as
demandas.
Demandas de Negócio
(sem controle e critérios de
Priorização)
Desafio: Como identificar as
Demandas de Negócio que agregam
mais valor ao negócio
Definir critérios para priorização
ajuda na identificação de quais são
as demandas de maior valor
agregado ao negócio
Responder as demandas de negócio
priorizadas geram mais valor ao
negócio

ProdutividadeemDesenvolvimentodeSoftware 6 - Priorização
Funil de Priorização de Demandas
Classes:
- Novas funcionalidades
- Melhorias
- Bugs (Correções)
Demandas sem
priorização
Backlogde
Demandas
Novas funcionalidades
Melhorias
Bugs (Correções)
Qual é a
prioridade ?
O funil de demanda é
uma ação de priorizar
as demandas.
Alta
Média
Baixa
A priorização de demandas melhora a produtividade da equipe

6 - Priorização
7 - Tecnologias emergentes
“Só sei que nada sei”
7 - Tecnologias
Emergentes

ProdutividadeemDesenvolvimentodeSoftware Tecnologias Emergentes
DevOps, Internet das Coisas (IoT), Cloud
Computing, Entrega Contínua, Impressão
3D, Microservices, Containers, Full Stack
Developer, Computação Cognitiva...
Quando a equipe começa usar novas tecnologias ou tecnologias emergente
aprender tecnologias emergente ela entra em “modo on” de aprendizado, neste
cenário é natural ter baixa produtividade, afinal ainda se está aprendendo...

6 - Priorização
8 - Comunicação.
“É simples quando flui”
8 - Comunicação

Segundo Peter
Drucker*:
"60% dos
problemas de
produtividade
das empresas
resultam de
falhas na
comunicação“
8 - Comunicação:
Problemas de comunicação afetam a produtividade.

Em desenvolvimento de software, existe um mito:
Usuários “não” sabem o que querem
8 - Comunicação:
Isso pode gerar problemas de comunicação e afetar a produtividade da equipe...

Equipes não se comunicam adequadamente:
Products Owners
Equipe de Desenvolvimento
8 - Comunicação:
Falhas de comunicação das equipes provocam impactos na produtividade...

Problemas de Comunicação entre Usuários e Equipe de Desenvolvimento:
- Alguns clientes têm dificuldades em externar suas necessidades,
expectativas e preocupações de forma clara e objetiva.
- Geralmente fazem mudanças de requisitos durante o desenvolvimento ou
quando o software é entregue.
- Sempre precisam do software funcionando para ontem
- Não têm tempo e nem paciência para falar com os desenvolvedores.
Problemas de Comunicação entre Equipe de Desenvolvimento e Usuários:
- Dificilmente conseguem atender as demandas de negócio
- Têm dificuldade em se comunicar, entender os clientes ou não querem
conversar com o cliente
- Acham que os clientes não sabem o que querem
A maioria das funcionalidades nunca
são usadas pelos usuários
8 - Comunicação:
Problemas de comunicação entre usuários
e equipe de desenvolvimento fazem que
os desejos sejam entendidos como
necessidades.
O Gráfico ao lado mostra o percentual de
funcionalidades que nunca são usadas..
Identificar desejos ao invés de necessidades, é
um problema sério e que também provoca alto
impacto na produtividade.

Escolha o canal de comunicação adequado:
Para melhorar a comunicação, o primeiro passo é escolher o canal “certo”, fazer
essa escolha é garantir 50% de sucesso. Existem diversos canais do e-mail à
conversas face-a-face. O gráfico abaixo aponta quais são os melhores canais para
a comunicação fluir. Quando a comunicação flui, favorece a produtividade.
A melhor escolha
Temperatura do Canal de Comunicação
EficiênciadaComunicação
Frio Quente
papel
áudio
Conversas
por e-mail
Vídeo conferência
Conversas
por telefone
Conversas
face-a-face
menosmais
Emissor
/Receptor
Receptor
/Emissor
Contexto
Código
Mensagem
Canal (meio)
ElementosdaComunicação
Comunicação
8 - Comunicação:

6 - Priorização
9 - Desengajamento e imaturidade, é a
receita para resultados inconsistentes
9 - Desengajamento
e imaturidade

Desengajamento e imaturidade, é a receita para resultados inconsistentes, pois,
eles afetam diretamente a produtividade da equipe.
9 - Desengajamento e imaturidade
EngajadosFortemente Desengajados Desengajados
Carregadores
de Piano
Funcionário
Padrão
Desagregadores
e Sabotadores
Quando maior for nível de engajamento da equipe maior
será a produtividade. Entretanto, o nível de engajamento é baixo na maioria
das equipes...

ProdutividadeemDesenvolvimentodeSoftware 9 - Desengajamento e imaturidade
EngajadosFortemente Desengajados Desengajados
Carregadores
de Piano
Funcionário
Padrão
Desagregadores
e Sabotadores
Elevar o nível de engajamento da equipe, aumenta as chances
de alta produtividade
Desafio: Para melhorar a produtividade da equipe considere “retirar”os membros
que são fortemente desengajados e transformar os desengajadas em engajados...

6 - Priorização
10 - Líder, Salvador da Pátria ou Super
Herói. Quem poderá me ajudar?
10 - Líder, Salvador
da Pátria ou
Super Herói.

Autocrático
Toma as
decisões
sozinho
(sem consultar a
equipe)
Comando Controle
Pratica o
microgerenciamento
44
Perfil do Profissional de TI (passado)
10 - Líder, Salvador da Pátria ou Super Herói
Em alguns casos
Comunicação
violenta
Este perfil de profissional quando se torna
chefe de uma equipe seu comportamento
provoca desmotivação e baixa produtividade.

ProdutividadeemDesenvolvimentodeSoftware 10 - Líder, Salvador da Pátria ou Super Herói
Entender as
Pessoas
Entender o
Negócio
Já profissional com perfil atual,
quando se torna líder, gera
motivação e estimula a
produtividade.

ProdutividadeemDesenvolvimentodeSoftware Contato:
Você quer aumentar a produtividade da sua equipe de desenvolvimento?
Entre em contrato conosco:

ProdutividadeemDesenvolvimentodeSoftware Comunidade eTecnologia
Venha para comunidade eTecnologia
Os membros da comunidade podem participar dos eventos, treinamentos e cursos
gratuitos. Comunidade: http://etecnologia.ning.com/
Para participar da comunidade basta se cadastrar: http://etecnologia.ning.com
A missão da comunidade é compartilhar conhecimento, trocar experiências e prover
aprendizado.

ProdutividadeemDesenvolvimentodeSoftware Licença:
Você tem o direito de:
Compartilhar — copiar e redistribuir o material em qualquer suporte ou formato
Adaptar — remixar, transformar, e criar a partir do material O licenciante não pode revogar estes
direitos desde que você respeite os termos da licença.
De acordo com os termos seguintes:
Atribuição — Você deve atribuir o devido crédito, fornecer um link para a licença, e indicar se
foram feitas alterações. Você pode fazê-lo de qualquer forma razoável, mas não de uma forma
que sugira que o licenciante o apoia ou aprova o seu uso.
Não Comercial — Você não pode usar o material para fins comerciais.
Compartilhamento — Se você remixar, transformar, ou criar a partir do material, tem de distribuir
as suas contribuições sob a mesma licença que o original.
Sem restrições adicionais — Você não pode aplicar termos jurídicos ou medidas de caráter
tecnológico que restrinjam legalmente outros de fazerem algo que a licença permita.
Avisos:
Você não tem de cumprir com os termos da licença relativamente a elementos do material que
estejam no domínio público ou cuja utilização seja permitida por uma exceção ou limitação que
seja aplicável.
Não são dadas quaisquer garantias. A licença pode não lhe dar todas as autorizações
necessárias para o uso pretendido. Por exemplo, outros direitos, tais como direitos de imagem,
de privacidade ou direitos morais, podem limitar o uso do material.

by rildosan® v6-2016
#deveweb
Produtividade em
Desenvolvimento de Software
49

Produtividade em Desenvolvimento de Software

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Produtividade em Desenvolvimento de Software

Semelhante a Produtividade em Desenvolvimento de Software (20)

Mais de Rildo (@rildosan) Santos

Mais de Rildo (@rildosan) Santos (20)

Produtividade em Desenvolvimento de Software