Come scrivere una dichiarazione di lavoro per un progetto di sviluppo software agile

Credo di essere per lo più d'accordo con la risposta di Todd. Ma potrei avere un punto di vista diverso su come andare a scriverlo.

Se una dichiarazione di lavoro è un accordo tra due parti sul lavoro che una (un fornitore di servizi) sta facendo per l'altra (il cliente), allora deve definire quali sono i deliverable. Non possiamo dare per scontato che l'unico deliverable sia un software funzionante, poiché ci possono essere altri deliverable (documentazione, rapporti di stato, ecc.) che il cliente richiede.

Un documento di lavoro ben scritto fornisce una definizione misurabile di fatto, o criteri di accettazione per ogni deliverable.

Un documento di lavoro può anche definire qualsiasi responsabilità "condivisa". In particolare, definisce qualsiasi dipendenza dei deliverable del fornitore di servizi dal lavoro di cui non è responsabile. Se il cliente è responsabile, o qualche altro fornitore di servizi, questo è molto importante. Questo può includere cose semplici come stabilire l'accesso ai sistemi per il personale del fornitore di servizi, o elementi logistici come scrivanie e computer nella sede del cliente.

Quindi, mentre uno statement of work fornisce criteri di accettazione, non è probabile che sia basato sulle user stories. Specialmente se il metodo di consegna è agile, perché le user stories non sono un artefatto statico che è "conosciuto" all'inizio quando il servizio viene contrattato.

Il software in funzione ha la sua propria definizione di fatto, che in un contesto agile è solitamente definita dal team. Il deployment del software, o il test attraverso un insieme di dimensioni di qualità (ad esempio funzionale, integrazione, performance, ecc.) e la correzione dei difetti potrebbero essere inclusi.

Perché una dichiarazione di lavoro "trascenda" il processo agile, dovrebbe riguardare gli obiettivi di business del software; cioè perché lo stiamo scrivendo o modificando. La difficoltà qui, è che gli obiettivi di business non sono raggiunti dalla scrittura del codice. Sono raggiunti solo dall'adozione del software da parte degli utenti finali. Questo significa che la misurazione dei risultati di business non è possibile entro il termine del SOW, a meno che non ci siano più distribuzioni o deliverable programmati in serie. Quindi una dichiarazione di lavoro ragionevole, avrebbe bisogno di qualche misura precedente, una misura principale che rifletta l'opinione del cliente che il fornitore di servizi sta producendo caratteristiche adottabili.

Quindi, una dichiarazione di lavoro dovrebbe includere una serie di caratteristiche (con descrizioni funzionali), una definizione di fatto che spieghi quale misura iniziale di adozione sarà usata, e qualsiasi altro deliverable nello scopo del fornitore di servizi (per esempio la documentazione, ecc.). Può opzionalmente identificare il lavoro richiesto da cui il fornitore di servizi dipende, che ha un impatto sui risultati del fornitore di servizi.

In un contesto agile, l'opinione del cliente su ciò che significa adottabile può cambiare man mano che le caratteristiche vengono consegnate. Poiché una dichiarazione di lavoro è un contratto basato sulla consegna (non un contratto di tempo e materiali), cambiare questa opinione può risultare in una modifica del contratto.