PSP-TSP-SPIN

Prévia do material em texto

PSP e TSP
Criando Equipes Nível 5
Atila Belloquim
Gnosis
2www.gnosisbr.com.br
Apresentação
• Atila Belloquim
– Bacharel em Ciência da Computação (IME-USP)
– Mestre e Doutorando em Administração (FEA-USP)
– Diretor da Gnosis – IT Knowledge Solutions
– Coordenador dos cursos de pós-graduação em 
Qualidade no Desenvolvimento de Software e 
Gerenciamento de Projetos do Senac-SP
– Fundador e Presidente do Conselho do SPIN-SP
– Membro do conselho do congresso Developers’ 
Meeting
• E vocês?
3www.gnosisbr.com.br
Sumário
• PSP, TSP e CMM: relacionamentos mútuos
• PSP
– O que é o PSP?
– Estrutura do PSP
• TSP
– O que é o TSP
– TSP e TSPi
– Conceitos e estrutura
– O Processo do TSPi
– Papéis
– Teamwork e teambuilding
PSP
5www.gnosisbr.com.br
Três Níveis
• CMM -> Capacitação 
Organizacional
• TSP -> Capacitação de 
Equipes
• PSP -> Capacitação de 
Indivíduos
6www.gnosisbr.com.br
Relacionamento
• O CMM diz “o que” deve ser feito
– Desenhado para ser amplo e duradouro
– Não entra em detalhes de técnicas 
específicas
• O PSP e o TSP dizem também “como”
– Sugerem técnicas e dão alternativas
7www.gnosisbr.com.br
Princípios do PSP
• A qualidade de um software é 
governada pela qualidade de seus 
piores componentes
• A qualidade de um componente de 
software é governada pelo indivíduo 
que o desenvolveu
– Conhecimento
– Disciplina
– Comprometimento
8www.gnosisbr.com.br
Princípios do PSP
• O profissional de software deve 
conhecer sua própria performance
– Medir, acompanhar e analisar seu trabalho
– Aprender das variações na performance
– Incorporar estas lições em suas práticas 
pessoais
9www.gnosisbr.com.br
O Processo Pessoal de 
Software (PSP)
• O PSP permite ao desenvolvedor
– Estimar e planejar o trabalho a ser feito
– Cumprir compromissos
– Resistir a pressões por compromissos 
irrealísticos
– Compreender sua habilidade
– Estar mais apto a melhorar sua forma de 
trabalho
10www.gnosisbr.com.br
O Processo Pessoal de 
Software (PSP)
• O PSP estabelece
– Uma base testada e comprovada para o 
desenvolvimento e uso de disciplinas 
pessoais de alcance industrial
– Uma disciplina que mostra como o 
processo pessoal pode ser melhorado
– Os dados necessários para a melhoria 
contínua da produtividade, qualidade e 
previsibilidade do trabalho do 
desenvolvedor
11www.gnosisbr.com.br
O Que é um PSP ?
• Um processo pessoal para o 
desenvolvimento de software
– Passos definidos
– Formulários
– Padrões
• Uma infra-estrutura de medição e 
análise para a caracterização deste 
processo
• Um procedimento definido para a 
melhoria da performance
12www.gnosisbr.com.br
Visão Geral do PSP
• O PSP é apresentado em 7 passos 
consecutivos e complementares
• Um ou dois programas são escritos a 
casa passo
• Dados sobre o trabalho são coletados 
e analisados
• Estes dados são então usados para a 
melhoria do trabalho
13www.gnosisbr.com.br
Visão Geral do PSP
• PSP0 - A performance atual é medida e 
estabelecida – Baseline
• PSP1 - São elaborados planos de tamanho, 
recursos e tempos gastos no trabalho –
Gerenciamento de Projetos
• PSP2 - É realizado o gerenciamento de 
defeitos e rendimento (Yield) –
Gerenciamento do Processo e da Qualidade
• PSP3 - Os métodos do PSP são ampliados 
para projetos maiores – Escalabilidade do 
Processo
14www.gnosisbr.com.br
Visão Geral do PSP
PSP0
Current process
Time recording
Defect recording
Defect type standard
PSP1
Size estimating
Test report
PSP2
Code reviews
Design reviews
PSP3
Cyclic development
PSP2.1
Design templates
PSP1.1
Task planning
Schedule planning
PSP0.1
Coding standard
Size measurement
Process improvement
proposal (PIP)
15www.gnosisbr.com.br
PSP e CMM
• O CMM fornece a infra-estrutura 
organizacional para a melhoria contínua dos 
processos de software
• O PSP aplica estes mesmos conceitos ao 
nível individual
• O CMM assume que os desenvolvedores 
utilizarão métodos pessoais disciplinados
• O PSP, por sua vez, assume que existe um 
gerenciamento efetivo do processo de 
software
16www.gnosisbr.com.br
PSP e CMM
Level 2
Software configuration management
Software quality assurance
Software subcontract management
Software project tracking and oversight*
Software project planning*
Requirements management
*PSP key practices
Level 3
Peer reviews*
Intergroup coordination
Software product engineering*
Integrated software management*
Training program
Organization process definition*
Organization process focus*
Level 4
Quality management*
Process measurement and analysis*
Level 5:
Process change management*
Technology innovation*
Defect prevention*
Level 11
2
3
4
5
17www.gnosisbr.com.br
Resultado
• Ao final do curso, o desenvolvedor
– terá praticado elementos chave de um 
processo de software Nível 5
– entenderá quais métodos funcionam 
melhor para ele
– fará um melhor trabalho
– terá objetivos de melhoria de longo prazo
18www.gnosisbr.com.br
Conclusão
• Mensagem a reter
– O PSP é um processo definido para ajudar 
o desenvolvedor a fazer melhor seu 
trabalho
– O PSP ensina e recomenda técnicas que 
podem ser utilizadas também no âmbito 
da equipe (TSP) e da organização (CMM)
TSP
20www.gnosisbr.com.br
O que é o TSP?
• O TSP (Team Software Process) é uma 
estrutura para a melhoria quantitativa 
de processo de software que ajuda 
equipes a desenvolver produtos de 
software de modo eficaz
• Baseia-se nos conceitos do CMM
• Supõe que os membros da equipe 
tenham sido treinados no PSP
21www.gnosisbr.com.br
Conceitos e Estrutura
• Equipes auto-gerenciadas
– A gerência provê orientação e suporte
– A equipe planeja o próprio trabalho, 
acompanha o progresso e gerencia as 
tarefas do dia-a-dia
• Cada membro da equipe tem papéis e 
responsabilidades definidos
• Todos os membros participam do 
planejamento do projeto e da tomada 
de decisões-chave
22www.gnosisbr.com.br
Conceitos e Estrutura
• A equipe é proprietária dos seus 
processos e pode mudá-los sempre 
que necessário
• Os processos da equipe são baseados 
em sua
– experiência
– conhecimento
– maturidade
• As equipes aplicam práticas do Nível 5 
do CMM
23www.gnosisbr.com.br
Conceitos e Estrutura
• O TSP provê um conjunto de 
– scripts de processos
– formulários
– métodos
– métricas
• Estes elementos guiam os desenvolvedores 
em
– criar equipes eficazes
– estabelecer metas e planos para a equipe
– acompanhar e reportar o trabalho
• TSPi
– Versão simplificada do TSP para equipes e 
projetos menores
24www.gnosisbr.com.br
O Design do TSPi
 Estrutura simples construída sobre o PSP
 Desenvolvimento incremental
 Métricas padronizadas de qualidade e 
performance
 Métricas precisas para equipes e indivíduos
 Uso de avaliações de papéis e de time
 Exigência de disciplina de processo
 Aconselhamento nos problemas do trabalho 
em equipe
O Processo do TSPi
Estrutura e Fluxo
Estratégia 2
Planejamento 2
Requisitos 2
Design 2
Implementação 2
Teste 2
Postmortem 2
Lançamento ciclo 2
Estratégia 1
Planejamento 1
Requisitos 1
Design 1
Implementação 1
Teste 1
Postmortem 1
Lançamento ciclo 1
Declaração de necessidades do produto
Estratégia 3
Planejamento 3
Requisitos 3
Design 3
Implementação 3
Teste 3
Postmortem 3
Lançamento ciclo 3
Produto acabado
Avaliação final
27www.gnosisbr.com.br
O Processo do TSPi
• Cada ciclo inclui as seguintes fases
– Lançamento (launch)
– Estratégia
– Planejamento
– Requisitos
– Design– Implementação
– Teste
– Postmortem
• O processo inclui
– Scripts
– Formulários
– Padrões
28www.gnosisbr.com.br
Para Quê o Launch?
• A construção de equipes não ocorre 
por acaso
• Um lançamento inicial permite
– Estabelecer as relações de trabalho
– Definir e distribuir os papéis pelos 
membros da equipe
– Chegar a um acordo sobre as metas da 
equipe
29www.gnosisbr.com.br
Planejar Antes
• Porquê planejar antes de conhecer o produto 
em detalhes?
– Porque é assim na vida real
– Porque ao desenvolver o plano a equipe adquire 
uma melhor compreensão comum do trabalho a ser 
feito
– Porque um plano é a base para acompanhar o 
trabalho
– Porque, sem um plano, a equipe acabará se 
comprometendo com o prazo imposto pela gerência 
ou o cliente, acredite ou não que será capaz de 
cumpri-lo
• Daí a necessidade de iniciar pela Estratégia
30www.gnosisbr.com.br
O Quê é uma Estratégia?
• A Estratégia define a ordem na qual as 
funções do produto serão definidas, 
desenhadas, implementadas e testadas
• O processo de desenvolvimento do TSPi é 
cíclico
– Cada ciclo produz uma versão operacional do 
produto
– Ciclos subseqüentes incrementam a funcionalidade 
do produto
– Este processo é também conhecido como “ciclo de 
vida incremental”
– A equipe decide o conteúdo de cada ciclo (no 
curso) ou negocia este conteúdo com o usuário / 
cliente, com base no prazo e recursos disponíveis
31www.gnosisbr.com.br
A Necessidade do 
Planejamento
• Com um plano
– Você trabalha com mais eficiência
– Você sabe o que fazer e quando
– Você faz as coisas numa ordem produtiva
– Você não esquece passos importantes
– Você tem maior chance de cumprir seus 
compromissos
– Você pode assumir compromissos realistas com 
seus colegas de equipe e com seu cliente
– Você faz um trabalho melhor, ao não pular, por 
exemplo, revisões e inspeções, o que levaria a mais 
tempo gasto em teste e a um produto de baixa 
qualidade
– Você sabe onde está ao longo do desenvolvimento
32www.gnosisbr.com.br
Planejamento
• Passos
– Liste os produtos a serem desenvolvidos 
no ciclo e estime seus tamanhos
– Produza a lista de tarefas
– Produza o cronograma
– Produza o plano de qualidade
– Produza os planos individuais dos 
desenvolvedores
– Realize o balanceamento da carga
– Produza e distribua o planos
33www.gnosisbr.com.br
Planos balanceados
• Com planos balanceados
– Todos os membros da equipe contribuem 
com esforço igual
– Não é necessário esperar pelos outros
– Os recursos são usados mais 
eficientemente
– Consegue-se o menor prazo possível
• O balanceamento deve ser feito pelos 
desenvolvedores
– São os únicos que podem planejar em 
detalhes
34www.gnosisbr.com.br
Fases do desenvolvimento
• Fases
– Requisitos
– Design
– Implementação 
– Teste
• Estratégias gerais
– É feito o gerenciamento de configuração de 
todos os artefatos
– Todos os artefatos são inspecionados
– Todos os planos de teste são feitos na fase de 
desenvolvimento correspondente
• Processo em “V”
35www.gnosisbr.com.br
Para Quê o Postmortem?
• Sem uma fase específica para analisar 
o trabalho feito, pouco se aprende e 
não se pode fazer melhoria contínua
– O Postmortem é uma forma estruturada 
de aprender e melhorar
– Compara-se o planejado com o que 
realmente aconteceu
– Procura-se oportunidades de melhoria
• Mudanças no processo para o próximo projeto 
ou ciclo
Papéis
37www.gnosisbr.com.br
Por Quê Papéis?
• Para distribuir a carga de trabalho associada 
ao desenvolvimento que vão além da 
construção do produto
• Para permitir o desenvolvimento de 
diferentes habilidades pelos desenvolvedores
• Para explicitar as responsabilidades pelas 
tarefas
• Para explicitar a necessidade de tarefas 
associadas ao desenvolvimento que 
normalmente são ignoradas pelas equipes
38www.gnosisbr.com.br
Escolha dos papéis
• Cada membro da equipe atua ao mesmo 
tempo como desenvolvedor e assume um dos 
papéis do TSPi
• Os papéis devem ser escolhidos / distribuídos
– Conforme o interesse dos membros da equipe
– De acordo com suas habilidades
• Convém haver rodízio de papéis a cada novo 
ciclo / projeto
• Cada pessoa deveria especializar-se em dois 
ou três papéis
39www.gnosisbr.com.br
Os Papéis do TSPi
• Líder da Equipe
• Gerente de Desenvolvimento
• Gerente de Planejamento
• Gerente de Qualidade / Processo
• Gerente de Suporte
Teamwork e Teambuilding
41www.gnosisbr.com.br
Por Que os Projetos Falham
• Os projetos falham, geralmente, por causa 
de problemas no trabalho em equipe 
(teamwork), e não por razões técnicas
• Um dos principais problemas é a dificuldade 
em lidar com a pressão
– Tomam-se “atalhos”
– Usam-se métodos ruins (ou nenhum)
– Aposta-se em novas linguagens, ferramentas 
ou técnicas
• O TSPi ajuda a lidar com a pressão através 
da definição da estratégia e do planejamento
– Permite saber o que é para fazer
– Permite resistir a cronogramas irrealistas
42www.gnosisbr.com.br
O Quê é uma Equipe?
(1)Ao menos duas pessoas
(2)Trabalhando por um objetivo comum
(3)Com cada pessoa assumindo papéis 
específicos ou funções a desempenhar
(4)O atingimento do objetivo requer 
alguma forma de dependência entre 
os membros do grupo
43www.gnosisbr.com.br
Problemas Comuns nas 
Equipes - 1
• Liderança ineficaz
– Abandono dos planos
– Abandono da disciplina pessoal
• Falta de compromisso ou cooperação
– Um ou mais membros não querem 
cooperar trabalhando em equipe
– Pressão dos pares normalmente resolve
– Mas podem ser necessárias ações mais 
drásticas
• Falta de participação
– Um ou mais membros podem não estar 
dando a contribuição necessária
44www.gnosisbr.com.br
Problemas Comuns nas 
Equipes - 2
• Procrastinação e falta de confiança própria
– Falha em definir objetivos e prazos
– Resultado de liderança inexperiente, falta de 
objetivos claros, ou falta de processo e 
planejamento
• Qualidade pobre
– Falta de documentação, revisões e inspeções, 
práticas de implementação pouco rigorosas
• Injeção de requisitos
– Usuários ou desenvolvedores acrescentando 
funcionalidade no meio do projeto
• Avaliação por pares ineficaz
– Relutância ou competição
45www.gnosisbr.com.br
A Equipe
• Tamanho da equipe
– De 4 a 8 pessoas
– Equipes muito grandes dificultam o 
estabelecimento de relações próximas, 
necessárias à sinergia do grupo
• A Equipe Coesa (“jelled” team)
– Produção da equipe é maior do que seria a 
soma das produções individuais
– As pessoas encontram uma satisfação 
maior do que a esperada dada a natureza 
da tarefa
46www.gnosisbr.com.br
Condições básicas para o 
Trabalho em Equipe
• O trabalho a ser feito é claro e distinto
– Definido explicitamente
– Faz sentido para a equipe
– A equipe sabe o que deve fazer
• A equipe está claramente definida
– Sabe-se quem está dentro e quem está fora
– Os membros se conhecem
– O trabalho de todos é visível
– Todos sabem os papéis de cada um
• A equipe tem controle sobre a tarefa
– A equipe controla o processo
– A equipe é capaz de fazer o trabalho
47www.gnosisbr.com.br
Construindo Equipes Eficazes
• Coesão da equipe
– A equipe age como uma unidade física e 
emocional
– Comunicação aberta e freqüente
– Respeito e apoio mútuos
• Objetivos desafiadores
– Específicos e mensuráveis
– Cada membro aceita os objetivos como 
próprios
• Feedback
– O progresso é acompanhado
• Framework de trabalho comum
– Processo, papéis etc.
48www.gnosisbr.com.br
Como as Equipes “Acontecem”
• Processo iterativo de convergência
1.Entendimento comum do produto a ser construído
2.Acordosobre os objetivos
3.Entendimento sobre a estratégia e o plano de 
desenvolvimento
4.Identificação do que é desconhecido e das 
discordâncias
5.Acordo sobre o modo de resolvê-las e resolução
6.Descida ao próximo nível de detalhe
• A cada passo, a equipe vai aumentando a 
coesão
49www.gnosisbr.com.br
Como o TSPi Constrói Times
• Propondo um conjunto de objetivos iniciais
– A cada ciclo, devem ser revistos e ajustados 
pela equipe
• Identificação antecipada de papéis pré-
definidos
– Distribuição de responsabilidades
• Processo definido para o planejamento
• Comunicação interna
– Reuniões periódicas
– Informação disponível (processos, planos, 
métricas) facilitam a comunicação precisa
• Comunicação externa
– Reporte periódico
50www.gnosisbr.com.br
Deveres no Trabalho em 
Equipe
• Os elementos de um trabalho em equipe 
efetivo são três
– Comunicação entre os membros
• Visibilidade
• Saber ouvir
• Negociação 
– Estabelecimento e cumprimento de compromissos
• O compromisso tem que ser livremente assumido
• O compromisso é público
• Para assumir responsavelmente um compromisso, é 
preciso preparação (planejamento)
– Participação nas atividades da equipe
• Obter a atenção da equipe
• Pedir e aceitar ajuda
51www.gnosisbr.com.br
Deveres na Construção da Equipe 
(teambuilding)
• Para a construção de equipes efetivas, 
é necessário
– Aceitar a responsabilidade por um papel e 
desempenhá-lo o melhor possível
– Participar no estabelecimento de metas e 
planos da equipe e esforçar-se por cumprir 
essas metas e seguir o plano
– Construir e manter uma equipe efetiva e 
cooperativa
52www.gnosisbr.com.br
Conclusão
• São quatro as lições do TSP
1. A maior parte do desenvolvimento de software é e será 
feita por equipes
2. Equipes com as habilidades apropriadas e em que todos 
os membros trabalham juntos cooperativamente e 
efetivamente podem produzir resultados extraordinários
3. Um trabalho em equipe efetivo requer oito coisas
1. Metas da equipe com que todos concordam
2. Papéis estabelecidos
3. Um ambiente de trabalho adequado
4. Um processo de trabalho comum
5. Um plano para o trabalho
6. O compromisso mútuo com as metas, papéis e o plano
7. Comunicação aberta entre todos os membros do time
8. Respeito mútuo e suporte de todos os membros do grupo
4. Quando times encontram essas condições, produzem um 
trabalho superior, são mais produtivos e apreciam o seu 
trabalho
53www.gnosisbr.com.br
Bibliografia e Referências
• Introduction to the Team Software 
Process – Watts. S. Humphrey –
Addison Wesley, 2000
• www.sei.cmu.edu
54www.gnosisbr.com.br
Gnosis
• Treinamento e Consultoria em 
Metodologias de Desenvolvimento de 
Sistemas, Engenharia de Software e 
Modelos SEI/CMM, PSP e TSP
• Fone: (011) 3062-6133
• e-mail: atila@gnosisbr.com.br