1 tsp (times) e psp (pessoa) criando equipes nível 5 prof. guilherme alexandre monteiro reinaldo...

1

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: alexandrecordel@gmail.com

greinaldo@fbv.edu.br 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

PSP0Current processTime recording

Defect recordingDefect type standard

PSP1Size estimating

Test report

PSP2Code reviews

Design reviews

PSP3Cyclic development

PSP2.1Design templates

PSP1.1Task planning

Schedule planning

PSP0.1Coding standard

Size measurementProcess 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

Level 2Software configuration managementSoftware quality assuranceSoftware subcontract managementSoftware project tracking and oversight*Software project planning*Requirements management

*PSP key practices

Level 3Peer reviews*Intergroup coordinationSoftware product engineering*Integrated software management*Training programOrganization process definition*Organization process focus*

Level 4Quality management*Process measurement and analysis*

Level 5:Process change management*Technology innovation*Defect prevention*

Level 11

2

3

4

5

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

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 acabadoAvaliaçã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 pessoas2. Trabalhando por um objetivo comum3. Com cada pessoa assumindo papéis

específicos ou funções a desempenhar4. 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ído2.Acordo sobre os objetivos3.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ção6.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 coisas1. Metas da equipe com que todos concordam2. Papéis estabelecidos3. Um ambiente de trabalho adequado4. Um processo de trabalho comum5. Um plano para o trabalho6. O compromisso mútuo com as metas, papéis e o plano7. Comunicação aberta entre todos os membros do time8. 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