Watts Humphrey, presumivelmente o maior guru atual da qualidade de software, presenteou a comunidade de software com uma novidade, há muito prometida: o TSP, ou processo de software da equipe (Team Software Process).
Conhecido como o criador do CMM, Humphrey já havia fornecido modelos para a melhoria contínua dos processos de software tanto no nível individual (PSP - Personal Software Process) quanto no nível da organização como um todo (CMM - Capability Maturity Model). Faltava contudo uma peça: em quase todos os lugares, o desenvolvedor não desenvolve sozinho; ao contrário, está inserido no contexto de uma equipe de trabalho.
Assim sendo, a seqüência lógica de trabalhos foi criar um modelo em que desenvolvedores previamente treinados no PSP pudessem organizar-se em equipes auto-gerenciadas de alta performance. É isto que faz o TSP: prover condições de uma equipe de desenvolvimento de software definir e melhorar continuamente seu processo.
Segundo muita gente, incluindo o próprio Humphrey, o TSP pode vir a ser a solução para aquelas pequenas organizações de software que se consideram muito pequenas para enfrentar as complexidades do CMM. O objetivo do TSP é auxiliar na integração e melhoria da forma de trabalho das equipes de desenvolvimento de software, transformando as equipes em times.
Normalmente os projetos de software envolvem um custo considerável, em especial na alocação de profissionais, recursos e, infelizmente, problemas referentes à qualidade. Os testes de software são, na maioria das vezes, caros e demandam um esforço, tanto de tempo quanto de recursos, elevado, sendo que na maioria dos projetos de médio para grande porte, esse esforço é da ordem de meses até que o software possa ser entregue à área usuária.
E, mesmo assim, a
confiabilidade do software não é total. A proposta do TSP é fornecer métodos
para a utilização dos conceitos de time de desenvolvedores na produção de
software. Isto inclui a definição de metas, regras, riscos e produtos a serem
gerados pelo time de desenvolvedores, bem como a definição das referidas
ferramentas de medição dos mesmos . Notar que o TSP prega o conceito de time
ao invés de equipe.
A utilização do TSP é aberta a um time de desenvolvedores de software ou mesmo a um time que integre desenvolvedores de hardware e software. O número de profissionais que compõe o time varia de dois até vinte, o que caracteriza seu uso como recomendado para pequenos projetos, onde a utilização do CMM é por demais complexa, podendo, entretanto, ser extrapolada para projetos de maior complexidade.
Em realidade não existe um limite rígido que defina até onde utilizar o TSP e onde começar a utilizar o CMM. A complexidade do projeto é apenas um indicativo. Outro fator que deve ser levado em conta é o grau de maturidade do cliente. Por vezes, apenas a apresentação do conceito do CMM já é suficiente para "assustar" o cliente. Em casos assim, é recomendável a apresentação do TSP. Hierarquia dos três modelos: PSP para o indivíduo, TSP para o time, ou pequenos projetos e organizações e CMM para a organização inteira.