Team mjukvaruprocess
| Del av en serie om |
| mjukvaruutveckling |
|---|
I kombination med den personliga mjukvaruprocessen (PSP) tillhandahåller teamprogramvaruprocessen ( TSP ) ett definierat operativt processramverk som är utformat för att hjälpa team av chefer och ingenjörer att organisera projekt och producera mjukvara för produkter som sträcker sig i storlek från små projekt med flera tusen rader kod (KLOC) till mycket stora projekt större än en halv miljon rader kod. TSP är avsett att förbättra nivåerna av kvalitet och produktivitet i ett teams programvaruutvecklingsprojekt, för att hjälpa dem att bättre klara kostnaderna och schemalägga åtaganden för att utveckla ett mjukvarusystem.
Den första versionen av TSP utvecklades och testades av Watts Humphrey i slutet av 1990-talet och den tekniska rapporten för TSP sponsrad av det amerikanska försvarsdepartementet publicerades i november 2000. Boken av Watts Humphrey, Introduction to the Team Software Process , presenterar en vy av TSP avsedd för användning i akademiska miljöer, som fokuserar på processen att bygga ett programvaruproduktionsteam, fastställa teammål, fördela teamroller och andra lagarbetesrelaterade aktiviteter.
Introduktion till TSP
Det primära målet med TSP är att skapa en teammiljö för att etablera och underhålla ett självstyrt team och stödja disciplinerat individuellt arbete som bas i PSP-ramverket. Självstyrt team innebär att teamet sköter sig själv, planerar och spårar sitt arbete, hanterar kvaliteten på sitt arbete och arbetar proaktivt för att nå teamets mål. TSP har två huvudkomponenter: teambuilding och team-working. Teambuilding är en process som definierar roller för varje gruppmedlem och sätter upp lagarbete genom TSP-lansering och periodisk nylansering. Lagarbete är en process som handlar om tekniska processer och praxis som används av teamet. TSP, kort sagt, ger ingenjörer och chefer ett sätt som etablerar och hanterar sitt team för att producera högkvalitativ mjukvara enligt schema och budget.
Hur TSP fungerar
Innan ingenjörer kan delta i TSP, krävs det att de redan har lärt sig om PSP, så att TSP kan fungera effektivt. Utbildning krävs även för övriga teammedlemmar, teamledaren och ledningen. TSP-programvaruutvecklingscykeln börjar med en planeringsprocess som kallas lanseringen, ledd av en tränare som är specialutbildad och antingen certifierad eller provisorisk. Lanseringen är utformad för att påbörja teambuildingprocessen, och under denna tid sätter team och chefer upp mål, definierar teamroller, bedömer risker, uppskattar insatser, fördelar uppgifter och tar fram en teamplan. Under en exekveringsfas spårar utvecklare planerade och faktiska ansträngningar, scheman och defekter som träffas regelbundet (vanligtvis varje vecka) för att rapportera status och revidera planer. En utvecklingscykel avslutas med en post mortem för att bedöma prestanda, revidera planeringsparametrar och fånga lärdomar för processförbättringar.
Coachrollen fokuserar på att stödja teamet och individerna i teamet som processexpert samtidigt som den är oberoende av direkt projektledningsansvar. Teamledarrollen skiljer sig från coachrollen genom att lagledare är ansvariga inför ledningen för produkter och projektresultat medan coachen ansvarar för att utveckla individuella och teamprestationer.
Senaste utvecklingen
TSP har anpassats för att fungera med andra typer av kunskapsarbete , inklusive systemteknik och tjänster.
Kartläggning av TSP till CMMI-metoder (Capability Maturity Model Integrated) dokumenterades 2010 och testades som en alternativ väg för att implementera CMMI-processförbättringar. En kunskapssamling (BOK) gavs ut 2010. Guideboken för coachmentorprogrammet släpptes 2010.
Enligt en studie av Capers Jones är TSP en av de mest framgångsrika utvecklingsmetoderna vad gäller schema, kvalitet och budget (TCO)
Publikationer
- TSP: Leder ett utvecklingsteam 2005
- TSP: Coaching Development Teams 2005