Team Foundation Server - Che modello di processo è per me?

Question

Così finalmente sono stato in grado di completare l'installazione di TFS e ho iniziato la creazione del mio primo progetto di squadra che mi ha introdotto al modello di processo.

Dopo aver seguito il collegamento a Microsoft's site per informazioni sul modello di processo, sono stato sommerso da nuove informazioni da considerare. Quali modelli hanno tutti esperienza con questo o ha funzionato molto bene per te o sono stati più di un ostacolo al progetto? Quali sono stati i maggiori vantaggi e svantaggi che hai riscontrato?

Edit: Alcuni dati su mio progetto, io sono il capo sviluppatore per una piccola azienda e sarà utilizzando TFS/VSTS per creare un portale intranet per consolidare il giorno agli utenti finali di giorno e aumentare l'automazione per aumentare la produttività ecc. Si tratta di uno sviluppo completamente nuovo che sfrutta C#, ASP.NET e Sql Server 2008.

Idealmente mi piacerebbe sfruttare le funzionalità per migliorare la collaborazione con gli stakeholder per contribuire ad aggiungere funzionalità desiderate e tenere traccia dello stato di sviluppo e offerta di feedback ecc. Stavo anche cercando di sfruttare TeamCity di JetBrain per il mio TFS, quindi se qualche template/software specifico aggiunge davvero coesione tra TFS, TeamCity, Developers e Stakeholder che essere idealmente quello che mi interessa.

Answer 1

Stai già utilizzando un processo di sviluppo software come scrum? In caso affermativo, provare questo modello di processo di team su here.

Quanto è grande il team di progetto e il progetto? Microsoft ha pubblicato uno dei suoi Process Templates (MPT) interni su here. Puoi ottenere un po 'di guida e ispirazione da questo modello.

come tangurena menzionato. Le persone usano i modelli standard, cambiano un po 'il bug e memorizzano lì dei documenti. Vorrei raccomandare di mantenere il processo "leggero" pure.

Tuttavia il modello di processo non è tutto.

Ecco alcune idee che cosa avrei fatto (nel tuo caso):

• creare alcuni elementi di lavoro di ordine superiore (caratteristiche/stories) che stakeholdes possono creare (vincoli e TFS gruppi di utenti sono il tuo amico).Possono quindi accedere alle funzionalità richieste tramite l'accesso Web dell'oggetto di lavoro TFS. In questo modo non hai bisogno di una CAL per loro

• Creare alcuni rapporti che mostrano il lavoro pianificato per le versioni.

• Imposta l'automazione della build e crea Report (note di rilascio a.k.a.) dai tuoi workitems in base alle build.

Quali sono stati i maggiori vantaggi e gli svantaggi che hai incontrato?

Imho il più grande svantaggio è che si inizia a credere che il modello è il tuo proiettile d'argento. Non è, è il tuo punto di partenza. L'ecosistema TFS offre molte opportunità per creare i propri bit di software adatti alle proprie esigenze. Basta dare un'occhiata allo TFS API.

Answer 2

Ecco un altro bello agile-based template (originale è su SSW, ma è necessario aggirare un muro di accesso).

Questo modello aiuta a migliorare la coesione tra sviluppatori, manager e altre parti interessate includendo un supporto più solido per il processo del progetto (documentazione, recensioni, & c., & c.). Ad esempio, ci sono tipi integrati per elementi di processo come i piani di rilascio.

Answer 3

In termini generali, preferisco un processo di dimensioni ridotte. Più sono gli stati, più campi hai, più è probabile che le informazioni siano semplicemente sbagliate.

Stiamo utilizzando la nostra versione sul modello Agile. La maggior parte di ciò che abbiamo fatto è stata eliminare le cose.

È possibile utilizzare l'API TFS per registrare build nel database, che dovrebbe consentire di collegare TeamCity e TFS. Oltre a questo, probabilmente andrei solo con l'interfaccia web che viene fornita con TFS, non penso che tu abbia bisogno di software di terze parti per questo.

Answer 4

K.I.S.S.! Ho creato un oggetto di lavoro personalizzato basato su quello Agile. E questo è solo un oggetto di lavoro. Esiste una "Severità di sistema" che l'IT utilizza e una "Priorità aziendale" utilizzata dal cliente/cliente. C'è anche un "Tipo di richiesta". Con questi tre e l'Area e Iterazione integrate, l'intero team, compresi i clienti, può interrogare gli elementi di lavoro per ottenere solo gli oggetti a cui si preoccupano per il rilascio a cui sono interessati (o tutti, indipendentemente dal rilascio).

Non ho modificato molto la macchina di stato. Questo ci ha lasciato qualcosa di molto flessibile per tutti. Qui possono essere registrate tutte le richieste dal cielo blu ai contenuti banali/ai bug visivi.

Il client utilizza Accesso Web TFS (CAL illimitato) e gli sviluppatori (io e 1 altro) utilizzano VS. Nel mio ultimo lavoro ho creato la stessa configurazione, il team di sviluppo era una squadra di 5 persone e ha funzionato ancora meglio lì! Sono stato responsabile anche lì e PM tecnico.

Il più grande vantaggio era avere un sistema molto flessibile per tutti, quando si utilizzava 1 tipo di oggetto di lavoro per tutto. Lo svantaggio sarebbe una curva di apprendimento per il cliente, ma una volta sapevano come usarlo più piace. Un suggerimento sarebbe quello di esaminare strumenti meno costosi là fuori per un'implementazione simile, ma il nostro sconto .edu con la SM non può essere battuto.

Answer 5

Devo dire che è necessario identificare prima il sistema che si utilizzerà per l'SDLC della propria azienda. Il modello di processo è semplicemente uno strumento e senza una buona comprensione del processo sottostante non sarà di aiuto e può rendere le cose più difficili. L'adozione da parte dell'utente è fondamentale per il successo del modello SDLC e di processo.

Utilizziamo Scrum for Team System. Lo abbiamo scelto per la nostra esperienza con Scrum come metodologia SDLC. Ci sono diversi libri e articoli eccellenti sul web per aiutarti ad andare al massimo. Scrum legherà gli stakeholder aziendali nel processo.

Nel nostro sistema il Product Manager è in totale carico degli Articoli del Product Backlog e collabora con me e il CTO per dare la priorità a Sprint Backlog Items.

L'unica modifica apportata al modello di processo è stata l'aggiunta di uno stato "Test non riuscito" e il flusso di lavoro corrispondente.

Answer 6

Potrebbe non essere il modello migliore per te ma volevo ancora menzionarlo qui: XP for Team System.Si tratta essenzialmente di una versione semplificata di MSF per Agile Software Development:

[...] rimuove alcune delle attività di impostazione che un progetto XP probabilmente non vogliono intraprendere e cambia il nome elementi di lavoro Tipo Scenario di Storia.