Come supportare un prodotto costruito con uno sviluppo agile?

6

Due delle funzioni che la nostra azienda offre ai nostri clienti sono:

  • Il nostro team di sviluppo di ~ 10 dipendenti crea prodotti software per le aziende in un particolare settore. Il software è utilizzato su centinaia di computer dei nostri clienti. Sebbene il prodotto sia, per la maggior parte dei clienti, off-the-shell, i clienti più grandi guidano il suo sviluppo, quindi è da qualche parte tra il software shrinkwrap e il software personalizzato.

  • Il nostro team di supporto di ~ 25 dipendenti fornisce supporto tecnico per il nostro software e alcuni altri prodotti software per i quali siamo il fornitore.

Il nostro team di sviluppo è passato di recente a Scrum per la sua metodologia di sviluppo e, mentre sostengo questo cambiamento, temo che il nostro team di supporto abbia più problemi in futuro. Con un ciclo di rilascio più rapido, i nostri clienti avranno caratteristiche e prodotti in produzione di cui l'assistenza non è a conoscenza fino a quando il cliente non chiama. Non siamo mai stati particolarmente bravi nell'ottenere la documentazione e le informazioni dallo sviluppo al supporto, ma temo che Scrum possa solo esacerbare il problema.

Quali sono buoni riferimenti su come le aziende riconciliano il desiderio di sviluppo di rilasciare frequentemente con il desiderio di Support di avere documentazione completa e informazioni di supporto prima che i clienti vedano il prodotto? In che modo un'azienda deve strutturare la propria versione e modificare la gestione quando utilizzano metodi agili?

EDIT: Quello che mi interessa sono le specifiche su come le aziende si strutturano per affrontare questi problemi. Il team di Scrum distribuisce i rilasci ai clienti? Il software deve passare attraverso un team di gestione della modifica / rilascio che non distribuirà fino a quando la documentazione di supporto non sarà stata fornita e aggiornata? Come si ottengono rapidamente i comunicati ai clienti, ma tutti tengono informati su modifiche e nuove funzionalità?

    
posta Stephen Jennings 26.11.2010 - 02:00
fonte

5 risposte

4

La prima cosa da sapere è che alla fine dell'iterazione, non devi rilasciare . L'obiettivo è avere un incremento potenzialmente del software, non necessariamente per rilasciarlo. Il proprietario del prodotto dovrebbe decidere quando rilasciare.

Aumenta collaborazione

Quando decidi di rilasciare, è abbastanza ovvio che il supporto viene informato e / o addestrato con le nuove modifiche. Il supporto dovrebbe essere coinvolto nel processo. Dovrebbero anche essere informati su quale bug è stato corretto in modo che possano informare i clienti nel ticket di supporto.

A seconda della situazione, potrebbe essere una buona idea invitare uno o più membri del team di supporto alla riunione Spring planning . È anche una buona idea invitarli alla riunione sprint review . Provalo per vedere se funziona per te.

Scrivi una definizione di fatto

Ogni funzione sviluppata dai tuoi sviluppatori deve essere conforme a Definizione di fatto scrivi e mantieni che corrisponde alla tua organizzazione & specificità del prodotto. Ecco un esempio di DoD :

  • Creazione del codice, impegnata nel repository
  • Copertura del test unitario 80%
  • Documentazione tecnica completata (appena sufficiente)
  • La documentazione per l'utente finale è stata completata (appena sufficiente)
  • Recensito e amp; approvato da un altro sviluppatore
  • Completamente testato
  • Il nuovo file aggiornato

Il concetto di Definizione di Fatto da solo è una tecnica anti-procrastinazione aziendale strong. Ti costringe ad avanzare, ... a spedire.

Una volta che una funzionalità è "completata", hai tutto da rilasciare già. Compreso ciò che è necessario per il tuo team di supporto.

Il supporto è utile per gli sviluppatori

Personalmente supporto amoroso . È la migliore fonte di informazioni strategiche per il tuo software. È meglio di qualsiasi studio di mercato. Questo è il motivo per cui penso che avere sviluppatori nel supporto ti aiuti a costruire sulla qualità. Ricorda l'espressione Gettala sul muro ?

Penso anche che il proprietario del prodotto dovrebbe essere coinvolto.

    
risposta data 26.11.2010 - 09:20
fonte
2

I tuoi ragazzi di supporto devono essere coinvolti nella fase di pianificazione dell'iterazione e del rilascio in modo che sappiano cosa sta succedendo in una versione il prima possibile. Così mentre gli sviluppatori stanno costruendo il software, i ragazzi di supporto possono prepararsi per questo. Una cosa buona di Scrum è che una volta iniziata l'iterazione puoi essere sicuro di ciò che uscirà dall'altra parte.

    
risposta data 26.11.2010 - 03:25
fonte
0

Potresti già avere i dati disponibili per aiutare a comunicare con il tuo team di supporto.

Se hai un sistema di ticketing per tenere traccia di bug e richieste di funzionalità, puoi facilmente fornire report automatici quando i ticket sono risolti.

Analogamente, il tuo sistema di controllo del codice sorgente può essere usato per consegnare un log delle modifiche per ogni versione con ogni controllo atomico ("es .: Bug # 12345 corretto").

Se non hai nessuno dei sistemi sopra riportati, hai altri problemi che attendono di succedere.

Durante la fase di test del prodotto (dopo che il codice è stato modificato, prima che venga rilasciato), questo è il momento ideale per produrre changelog e comunicare con il personale di supporto. Durante questo periodo non bombardarli con elenchi enormi, basta dare loro un elenco dettagliato di funzionalità e bug che sono stati risolti e fornire collegamenti ai sistemi appropriati.

Se non hai tester dedicati, prenderei in considerazione il ruolo di uno dei tuoi sostenitori a lungo termine in questo ruolo: ti aiuteranno a rilasciare codice meno buggato e ad assicurarti che qualcuno sia responsabile della messa insieme documentazione per il team di supporto.

Solo alcuni pensieri:)

    
risposta data 26.11.2010 - 07:32
fonte
0

Se conduci una dimostrazione di storie completate nello sprint, porta il tuo team di supporto in queste sessioni. Più interattiva è la dimostrazione, meglio è.

    
risposta data 26.11.2010 - 11:41
fonte
0

Coinvolgi il rappresentante del team di supporto nelle chiamate client settimanali (vale a dire quando passi al tuo cliente) in modo che anche il rappresentante del team di supporto possa conoscere meglio il prodotto prima di rilasciarlo al cliente

    
risposta data 26.11.2010 - 12:52
fonte

Leggi altre domande sui tag