PSP e TSP Criando Equipes Nvel 5 Atila

  • Slides: 54
Download presentation
PSP e TSP Criando Equipes Nível 5 Atila Belloquim Gnosis

PSP e TSP Criando Equipes Nível 5 Atila Belloquim Gnosis

Apresentação • Atila Belloquim – – Bacharel em Ciência da Computação (IME-USP) Mestre e

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? www. gnosisbr. com. br 2

Sumário • PSP, TSP e CMM: relacionamentos mútuos • PSP – O que é

Sumário • PSP, TSP e CMM: relacionamentos mútuos • PSP – O que é o PSP? – Estrutura do PSP • TSP – – – O que é o TSP e TSPi Conceitos e estrutura O Processo do TSPi Papéis Teamwork e teambuilding www. gnosisbr. com. br 3

PSP

PSP

Três Níveis • CMM -> Capacitação Organizacional • TSP -> Capacitação de Equipes •

Três Níveis • CMM -> Capacitação Organizacional • TSP -> Capacitação de Equipes • PSP -> Capacitação de Indivíduos www. gnosisbr. com. br 5

Relacionamento • O CMM diz “o que” deve ser feito – Desenhado para ser

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 www. gnosisbr. com. br 6

Princípios do PSP • A qualidade de um software é governada pela qualidade de

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 www. gnosisbr. com. br 7

Princípios do PSP • O profissional de software deve conhecer sua própria performance –

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 www. gnosisbr. com. br 8

O Processo Pessoal de Software (PSP) • O PSP permite ao desenvolvedor – Estimar

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 www. gnosisbr. com. br 9

O Processo Pessoal de Software (PSP) • O PSP estabelece – Uma base testada

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 www. gnosisbr. com. br 10

O Que é um PSP ? • Um processo pessoal para o desenvolvimento de

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 www. gnosisbr. com. br 11

Visão Geral do PSP • O PSP é apresentado em 7 passos consecutivos e

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 www. gnosisbr. com. br 12

Visão Geral do PSP • PSP 0 - A performance atual é medida e

Visão Geral do PSP • PSP 0 - A performance atual é medida e estabelecida – Baseline • PSP 1 - São elaborados planos de tamanho, recursos e tempos gastos no trabalho – Gerenciamento de Projetos • PSP 2 - É realizado o gerenciamento de defeitos e rendimento (Yield) – Gerenciamento do Processo e da Qualidade • PSP 3 - Os métodos do PSP são ampliados para projetos maiores – Escalabilidade do Processo www. gnosisbr. com. br 13

Visão Geral do PSP 3 Cyclic development PSP 2 Code reviews Design reviews PSP

Visão Geral do PSP 3 Cyclic development PSP 2 Code reviews Design reviews PSP 1 Size estimating Test report PSP 0 Current process Time recording Defect type standard PSP 2. 1 Design templates PSP 1. 1 Task planning Schedule planning PSP 0. 1 Coding standard Size measurement Process improvement proposal (PIP) www. gnosisbr. com. br 14

PSP e CMM • O CMM fornece a infra-estrutura organizacional para a melhoria contínua

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 www. gnosisbr. com. br 15

PSP e CMM 5 4 3 2 1 Level 5: Process change management* Technology

PSP e CMM 5 4 3 2 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 www. gnosisbr. com. br 16

Resultado • Ao final do curso, o desenvolvedor – terá praticado elementos chave de

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 www. gnosisbr. com. br 17

Conclusão • Mensagem a reter – O PSP é um processo definido para ajudar

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) www. gnosisbr. com. br 18

TSP

TSP

O que é o TSP? • O TSP (Team Software Process) é uma estrutura

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 www. gnosisbr. com. br 20

Conceitos e Estrutura • Equipes auto-gerenciadas – A gerência provê orientação e suporte –

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 www. gnosisbr. com. br 21

Conceitos e Estrutura • A equipe é proprietária dos seus processos e pode mudá-los

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 www. gnosisbr. com. br 22

Conceitos e Estrutura • O TSP provê um conjunto de – – scripts de

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 www. gnosisbr. com. br 23

O Design do TSPi l Estrutura simples construída sobre o PSP l Desenvolvimento incremental

O Design do TSPi l Estrutura simples construída sobre o PSP l Desenvolvimento incremental l Métricas padronizadas de qualidade e performance l Métricas precisas para equipes e indivíduos l Uso de avaliações de papéis e de time l Exigência de disciplina de processo l Aconselhamento nos problemas do trabalho em equipe www. gnosisbr. com. br 24

O Processo do TSPi

O Processo do TSPi

Estrutura e Fluxo Declaração de necessidades do produto Lançamento ciclo 1 Lançamento ciclo 2

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 – – –

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 www. gnosisbr. com. br 27

Para Quê o Launch? • A construção de equipes não ocorre por acaso •

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 www. gnosisbr. com. br 28

Planejar Antes • Porquê planejar antes de conhecer o produto em detalhes? – Porque

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 www. gnosisbr. com. br 29

O Quê é uma Estratégia? • A Estratégia define a ordem na qual as

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 www. gnosisbr. com. br 30

A Necessidade do Planejamento • Com um plano – – – Você trabalha com

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 www. gnosisbr. com. br 31

Planejamento • Passos – Liste os produtos a serem desenvolvidos no ciclo e estime

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 www. gnosisbr. com. br 32

Planos balanceados • Com planos balanceados – Todos os membros da equipe contribuem com

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 www. gnosisbr. com. br 33

Fases do desenvolvimento • Fases – – Requisitos Design Implementação Teste • Estratégias gerais

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” www. gnosisbr. com. br 34

Para Quê o Postmortem? • Sem uma fase específica para analisar o trabalho feito,

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 www. gnosisbr. com. br 35

Papéis

Papéis

Por Quê Papéis? • Para distribuir a carga de trabalho associada ao desenvolvimento que

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 www. gnosisbr. com. br 37

Escolha dos papéis • Cada membro da equipe atua ao mesmo tempo como desenvolvedor

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 www. gnosisbr. com. br 38

Os Papéis do TSPi • • • Líder da Gerente Equipe de Desenvolvimento de

Os Papéis do TSPi • • • Líder da Gerente Equipe de Desenvolvimento de Planejamento de Qualidade / Processo de Suporte www. gnosisbr. com. br 39

Teamwork e Teambuilding

Teamwork e Teambuilding

Por Que os Projetos Falham • Os projetos falham, geralmente, por causa de problemas

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 www. gnosisbr. com. br 41

O Quê é uma Equipe? (1)Ao menos duas pessoas (2)Trabalhando por um objetivo comum

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 www. gnosisbr. com. br 42

Problemas Comuns nas Equipes - 1 • Liderança ineficaz – Abandono dos planos –

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 www. gnosisbr. com. br 43

Problemas Comuns nas Equipes - 2 • Procrastinação e falta de confiança própria –

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 www. gnosisbr. com. br 44

A Equipe • Tamanho da equipe – De 4 a 8 pessoas – Equipes

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 www. gnosisbr. com. br 45

Condições básicas para o Trabalho em Equipe • O trabalho a ser feito é

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 www. gnosisbr. com. br 46

Construindo Equipes Eficazes • Coesão da equipe – A equipe age como uma unidade

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. www. gnosisbr. com. br 47

Como as Equipes “Acontecem” • Processo iterativo de convergência 1. Entendimento comum do produto

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 www. gnosisbr. com. br 48

Como o TSPi Constrói Times • Propondo um conjunto de objetivos iniciais – A

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 www. gnosisbr. com. br 49

Deveres no Trabalho em Equipe • Os elementos de um trabalho em equipe efetivo

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 www. gnosisbr. com. br 50

Deveres na Construção da Equipe (teambuilding) • Para a construção de equipes efetivas, é

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 www. gnosisbr. com. br 51

Conclusão • São quatro as lições do TSP 1. A maior parte do desenvolvimento

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 www. gnosisbr. com. br 52

Bibliografia e Referências • Introduction to the Team Software Process – Watts. S. Humphrey

Bibliografia e Referências • Introduction to the Team Software Process – Watts. S. Humphrey – Addison Wesley, 2000 • www. sei. cmu. edu www. gnosisbr. com. br 53

Gnosis • Treinamento e Consultoria em Metodologias de Desenvolvimento de Sistemas, Engenharia de Software

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 www. gnosisbr. com. br 54