TSP (Times) e PSP (Pessoa)
Criando Equipes Nível 5
Prof. Guilherme Alexandre Monteiro Reinaldo
Recife
‹#›
Contatos

Prof. Guilherme Alexandre Monteiro Reinaldo

Apelido: Alexandre Cordel

E-mail/gtalk: [email protected]
[email protected]

Site: http://www.alexandrecordel.com.br/fbv

Celular: (81) 9801-1878
PSP
Processo Pessoal de Software
Três Níveis



CMM -> Capacitação
Organizacional
TSP -> Capacitação de
Equipes
PSP -> Capacitação de
Indivíduos
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
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
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
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
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
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
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
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
Visão Geral do PSP
PSP3
Cyclic development
PSP2
PSP2.1
Code reviews
Design reviews
Design templates
PSP1
Size estimating
Test report
PSP0
Current process
Time recording
Defect recording
Defect type standard
PSP1.1
Task planning
Schedule planning
PSP0.1
Coding standard
Size measurement
Process improvement
proposal (PIP)
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
PSP e CMM
5
4
3
2
1
Level 1
Level 5:
Process change management*
Technology innovation*
Defect prevention*
Level 4
Quality management*
Process measurement and analysis*
Level 3
Peer reviews*
Intergroup coordination
Software product engineering*
Integrated software management*
Training program
Organization process definition*
Organization process focus*
Level 2
Software configuration management
Software quality assurance
Software subcontract management
Software project tracking and oversight*
Software project planning*
Requirements management
*PSP key practices
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
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
Processo de Time de Software
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
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
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
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
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
Declaração de necessidades do produto
Lançamento ciclo 1
Lançamento ciclo 2
Lançamento ciclo 3
Estratégia 1
Planejamento 1
Estratégia 2
Requisitos 1
Planejamento 2
Design 1
Requisitos 2
Implementação 1
Design 2
Teste 1
Implementação 2
Postmortem 1
Teste 2
Postmortem 2
Estratégia 3
Planejamento 3
Requisitos 3
Design 3
Implementação 3
Teste 3
Postmortem 3
Produto acabado
Avaliação final
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
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
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
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
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
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
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
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”
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
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
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
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
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
O Quê é uma Equipe?
1.
Ao menos duas pessoas
2.
Trabalhando por um objetivo comum
3.
4.
Com cada pessoa assumindo papéis
específicos ou funções a desempenhar
O atingimento do objetivo requer alguma
forma de dependência entre os membros do
grupo
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
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
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
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
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.
Como as Equipes “Acontecem”

Processo iterativo de convergência
1.Entendimento comum do produto a ser construído
2.Acordo sobre 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
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
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
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
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
Bibliografia e Referências


Introduction to the Team Software Process – Watts. S.
Humphrey – Addison Wesley, 2000
www.sei.cmu.edu