In che modo la documentazione Agile influisce sul Contratto e sulla Dichiarazione di lavoro iniziale?

Agile insiste su cicli di feedback stretti. Nessuna specifica è agile se richiede che i dettagli di implementazione elaborati un anno fa siano seguiti fedelmente oggi, indipendentemente da come il mondo e la nostra comprensione di esso siano cambiati. Il feedback è qualcosa da cui si apprende.

La prima cosa che Joel ha messo in quel documento spec che hai collegato che lo rende agile è questo disclaimer:

“This spec is not complete”

Anche se PENSI che sia completo, continua a insistere con la tua copertura:

“This spec is complete, to the best of my knowledge, but if I forgot something, please tell me.”

Ciò significa che sei libero di aggiornarlo man mano che impari.

Puoi tentare di anticipare ciò che diranno che si aspettavano di non aver ottenuto con "nongoals". Ma mentre elencare i non-oggetti è una buona pratica, non è una buona difesa contro ciò che pensano di non aver fatto.

Ciò che è una buona difesa è una struttura di pagamento che interpreta tali richieste come richieste di nuovi lavori che dovranno anche essere pagati. Funziona bene fino a quando non rappresenti mai che la tua prima versione è probabilmente l'ultima. Informa il cliente che questo è un processo iterativo. Che continuerai a fare rilasci finché continueranno a trovare più cose che devono essere fatte. Questa situazione è di solito molto accettabile per i clienti quando il tempo tra le pubblicazioni è di settimane, non di mesi o anni.

I seguenti collegamenti forniscono le conoscenze necessarie su come devono essere preparati i contratti per progetti agili:

1. link .
2. link .

Sebbene non ci sia una risposta breve a questa domanda, suggerisco di leggere questi riferimenti. Il primo è il co-lavoro di un avvocato IT e due autori di libri di avvio. Il secondo contiene alcune pratiche del famoso Alistair Cockburn (metodologo e uno dei principali iniziatori del movimento agile).

but isn't that what you need from a contractual viewpoint?

No, non lo è. Il contratto può essere qualsiasi cosa, e l'idea che il contratto debba includere le specifiche complete è estremamente miope.

Ad esempio, invece di un contratto che dice "crea un software che fa X prima di Y e ottieni l'importo pagato Z", puoi creare un contratto "ogni qualche settimana, creare miglioramenti incrementali per l'applicazione concordati dai nostri stakeholder e ottenere pagato Z ".

Penso che creare contratti che consentano la piena agilità sia estremamente importante ed estremamente difficile. E che è ben lungi dall'essere discusso e studiato abbastanza.