Team Software Process (TSP)
TSP é um processo de desenvolvimento de software, que fornece uma estrutura de processo operacional definida que é projetada para ajudar equipes de gerentes e engenheiros a organizar projetos e produzir software cujos princípios variam em tamanho desde pequenos projetos de milhares de linhas de código (KLOC) para projetos muito grandes com mais de meio milhão de linhas de código. Projetado para ser utilizado por engenheiros de software para a elaboração de projetos em time. O TSP foi desenvolvido por Watts Humphrey e está descrito no seu livro "A Discipline for Software Engineering" (Uma disciplina para Engenharia de Software) de 1995. O TSP foi desenvolvido para orientar o planejamento e desenvolvimento de módulos de software ou pequenos programas, mas pode ser adaptado para outras tarefas.
O TSP tem como objetivo melhorar os níveis de qualidade e produtividade do projeto de desenvolvimento de software de uma equipe, a fim de ajudá-los a melhor atender os custos e programar os compromissos de desenvolvimento de um sistema de software.
Objetivos[editar | editar código-fonte]
Antes que os engenheiros possam participar do TSP, é necessário que eles já tenham aprendido sobre o PSP, para que o TSP possa funcionar efetivamente. O treinamento também é necessário para outros membros da equipe, o líder da equipe e o gerenciamento. O ciclo de desenvolvimento de software do TSP começa com um processo de planejamento chamado lançamento, conduzido por um coach especialmente treinado e certificado ou provisório.[1] O lançamento foi projetado para iniciar o processo de formação de equipe e, durante esse tempo, as equipes e os gerentes estabelecem metas, definem funções da equipe, avaliam riscos, estimam o esforço, alocam tarefas e produzem um plano de equipe. Durante uma fase de execução, os desenvolvedores rastreiam o esforço planejado e real, a programação e os defeitos que se reúnem regularmente (geralmente semanalmente) para relatar o status e revisar os planos. Um ciclo de desenvolvimento termina com um Post Mortem para avaliar o desempenho, revisar os parâmetros de planejamento e capturar as lições aprendidas para a melhoria do processo.
O papel do coach concentra-se em apoiar a equipe e os indivíduos da equipe como especialistas em processos, sendo independente da responsabilidade direta do gerenciamento de projetos.[2][3] O papel de líder de equipe é diferente do papel de treinador, os líderes de equipe são responsáveis pela gestão de produtos e resultados do projeto, enquanto o treinador é responsável pelo desenvolvimento individual e de equipe.[2][3]
Como o TSP funciona[editar | editar código-fonte]
Antes que os engenheiros possam participar do TSP, é necessário que eles já tenham aprendido sobre o PSP, para que o TSP possa funcionar efetivamente. O treinamento também é necessário para outros membros da equipe, o líder da equipe e o gerenciamento. O ciclo de desenvolvimento de software do TSP começa com um processo de planejamento chamado lançamento, conduzido por um coach especialmente treinado e certificado ou provisório.[1][2] O lançamento foi projetado para iniciar o processo de formação de equipe e, durante esse tempo, as equipes e os gerentes estabelecem metas, definem funções da equipe, avaliam riscos, estimam o esforço, alocam tarefas e produzem um plano de equipe. Durante uma fase de execução, os desenvolvedores rastreiam o esforço planejado e real, a programação e os defeitos que se reúnem regularmente (geralmente semanalmente) para relatar o status e revisar os planos. Um ciclo de desenvolvimento termina com um Post Mortem para avaliar o desempenho, revisar os parâmetros de planejamento e capturar as lições aprendidas para a melhoria do processo.
O papel do coach concentra-se em apoiar a equipe e os indivíduos da equipe como especialistas em processos, sendo independente da responsabilidade direta do gerenciamento de projetos.[2][3] O papel de líder de equipe é diferente do papel de treinador, os líderes de equipe são responsáveis pela gestão de produtos e resultados do projeto, enquanto o treinador é responsável pelo desenvolvimento individual e de equipe.[2][3]
Últimos desenvolvimentos[editar | editar código-fonte]
O TSP foi adaptado para trabalhar com outros tipos de trabalho de conhecimento , incluindo engenharia de sistemas [4] e serviços.[5]
Mapeamento TSP para práticas CMMI foi documentado em 2010,[6] e pilotado como um caminho alternativo para implementar a melhoria do processo CMMI.[7][8] Um corpo de conhecimento (BOK) foi lançado em 2010. [2] O guia do programa de orientação de mentores foi lançado em 2010.[1]
De acordo com um estudo realizado pela Capers Jones, a TSP é uma das metodologias de desenvolvimento mais bem sucedidas em termos de calendário, qualidade e orçamento (TCO) [9]
Publicações[editar | editar código-fonte]
- TSP: Leading a Development Team 2005
- TSP: Coaching Development Teams 2005
Ver também[editar | editar código-fonte]
Referências
- ↑ a b c Chick, Timothy. «Team Software Process (TSP) Coach Mentoring Program Guidebook Version 1.1». Software Engineering Institute
- ↑ a b c d e f Humphrey, Watts. «The Team Software Process Body of Knowledge». Software Engineering Institute
- ↑ a b c d Humphrey, Watts (2005). TSP: Coaching Development Teams. [S.l.]: Addison Wesley
- ↑ Carleton, Anita. «Extending Team Software Process (TSP) to Systems Engineering: A NAVAIR Experience Report» (PDF). Software Engineering Institute
- ↑ Battle, Ed. «Leading & Learning – Using TSP at the MSG Level» (PDF). Naval Oceanographic Office
- ↑ James McHale, Timothy A. Chick and Eugene Miluk (dezembro de 2010). «Implementation Guidance for the Accelerated Improvement Method (AIM)» (PDF). Software Engineering Institute. Consultado em 11 de outubro de 2016
- ↑ Webb, David (abril de 2007). «CMMI Level 5 and the Team Software Process» (PDF). Cross Talk
- ↑ Mondragon, Oscar. «AIM Case Study» (PDF). Software Engineering Excellence Center
- ↑ Jones, Capers (2013). «Evaluating ten software development methodologies». Arquivado do original em 29 de junho de 2013