Esempio di Termini di servizio per la contrattazione Agile?

I clienti che vogliono che tu sia agile sembra più un cliente che vuole semplicemente cambiare idea (che va bene).

Sembra invece di:

1. Ottieni i requisiti
2. Firma il contratto con Julien per consegnare X per $ Y.
3. Julien consegna X
4. Julien viene pagato Y

Vogliono:

1. Ottieni requisiti molto, molto vaghi
2. Firma il contratto con julien per consegnare tutto ciò che desidera (X? Y? X + Y? Z ??), che è indeterminato, e paga Julien $ Y.
3. Julien lavora per requisiti in continua evoluzione.
4. I requisiti non vengono mai soddisfatti.
5. Julien non viene mai pagato perché non è mai soddisfatto.

In questo caso, addebito semplicemente per ora.

Non preoccuparti del prezzo fisso o di un contratto "agile". Se provi a contrattare per ogni cambiamento, alla fine diventerà più doloroso di quanto valga. La tua migliore scommessa qui sarebbe quella di avere un addebito per ora, e farli firmare sui timesheet che fornisci su una settimana o su una base simile. In questo modo tu e loro potete essere agili quanto necessario mentre avete una migliore garanzia di essere pagati. Fai solo un ottimo lavoro e ogni buon cliente vedrà il tuo valore. In caso contrario, è meglio passare solo il cliente particolare se ne hai l'opportunità.

Per un approccio più agile ..

Potresti, in sostanza, avere un iterazione del contratto di stima più breve. Ogni iterazione di due settimane (o qualsiasi altra volta) che si pianifica ha un contratto / emendamento più breve che delinea i requisiti e le stime solo per tale iterazione. Lascia che il cliente cambi i requisiti, ma dai loro quel lusso alla fine di ogni iterazione quando pianifichi la prossima iterazione.

Agile Team & Contratto a prezzo fisso: link

Fixed price contracts are evil - this is what can often be heard from agilists. On the other hand those contracts are reality which many agile teams have to face. But what if we try to tame it instead of fighting against it? How can a company execute this kind of contract using agile practices to achieve better results with lower risk? This article will try to answer those questions.

In una precedente azienda per cui lavoravo, ci siamo imbattuti in questo problema durante la distribuzione di siti Web con molte funzionalità personalizzate. Mi sembra che tu stia soffrendo di creep del client basato su client.

Per gestire questo problema, abbiamo iniziato ad allineare il nostro benchmark di sviluppo personale con benchmark di esempio per garantire che il cliente fosse soddisfatto del modo in cui le cose stavano procedendo. Inoltre, come Chris menziona nel suo post, i contratti / documenti T.O.S sono stati redatti e firmati di persona che hanno esplicitamente dichiarato ciò che era incluso in ciascun progetto e diviso in una base per benchmark. Ogni elemento è stato elencato con ciò che ha e non fa, al meglio delle nostre capacità senza essere chiaroveggente.

Siate sinceri sulle vostre spese e fategli sapere quale sarebbe una stima iniziale (che è una vostra responsabilità), ma date loro anche la "tariffa aggiuntiva", indipendentemente dal fatto che si tratti di aggiunte orarie o contrattuali. Quando iniziano a insinuarsi nel campo di applicazione, puoi ricorrere al contratto iniziale che ha quello previsto e indicare semplicemente la tua nuova stima.

Riassumendo: tutte le funzionalità descritte nel contratto, forniscono campioni di benchmark quando applicabili e ottengono segnalazioni anche su quelle, sono in anticipo sulle tariffe aggiuntive per gli elementi di creep dell'ambito.