Software on Budget e in orario?

Sì, l'ho visto succedere.

Elementi chiave:

1) Requisiti ben definiti, chiaramente concordati, con un solido processo di controllo delle modifiche.
2) Gli sviluppatori coinvolti nelle stime, senza alcuna pressione su di loro per produrre stime che erano ciò che il cliente voleva sentire, solo quello che pensavano fosse necessario per completare correttamente il lavoro
3) Stime che hanno tenuto conto anche dei rischi e delle incertezze 4) Facilitare il feedback iniziale dal cliente - abbiamo fornito video, dimostrazioni (mani e mani a seconda della stabilità) il prima possibile
5) Una squadra stabile la cui disponibilità è stata realisticamente calcolata nel programma (ad esempio se trascorrono un giorno a settimana a fornire supporto e amministrazione, quindi ci si aspetta solo di completare 4 giorni a settimana di lavoro sul progetto)

Non è una scienza missilistica, ma rimuovere le pressioni commerciali e, in modo critico, chiarire i requisiti e controllarli è una sfida (e dove le cose normalmente cadono).

La prima volta che ho lavorato su un progetto agile come (Agile non era un termine usato allora). Abbiamo imparato che lavorare quotidianamente con il cliente e le idee di prototipazione (screenshot o flussi di lavoro aziendali) con cui gli utenti potevano effettivamente giocare ha tenuto il progetto focalizzato, divertente e alla fine consegnato esattamente ciò che il cliente voleva, in tempo e budget.

È stato utile che il cliente fosse davvero concentrato sulla sua visione e che io ero benedetto da un team di talento che ha lavorato duramente durante la giornata lavorativa e che è stato in grado di socializzare / legarsi anche in seguito.

L'ho fatto un paio di volte. Quello che era comune era che il cliente non sapeva davvero cosa volevano, così ho scritto le specifiche: -)

Beh, in effetti uno di questi era "abbiamo bisogno di qualcosa per gestire la nostra libreria di immagini", quindi sapevo che avevano bisogno di un DAM. solo alcune domande in più per ottenere il loro flusso di lavoro, e quindi ero libero di scriverne uno per adattarlo.

La seconda volta è stata dopo una prima versione rapida di un sistema in cui abbiamo ottenuto recensioni molto positive su tutto tranne una singola funzione che è stata dichiaratamente molto cruda (perché abbiamo dovuto consegnare rapidamente la prima versione). Ho appena chiuso la porta e ho promesso che la prossima versione avrebbe risolto il problema. Poiché sapevamo già che quella parte non era buona, avevamo pianificato la seconda versione e potevamo concentrarci su quella parte del codice, sapendo che il resto era (quasi) pronto per il miglioramento.

Puoi ottenere due delle tre da questo elenco corrette prima dell'avvio del lavoro:

1. Budget
2. Calendario
3. Feature Set

Per ottenere la var mancante, è necessario avviare il processo e misurare l'avanzamento in base ai dati mancanti.

Se vuoi essere in linea con il budget e in orario, devi lavorare sul presupposto che il set di caratteristiche deve essere flessibile. Le metodologie agili capita di fare lo stesso presupposto.

Ho avuto un solo cliente nella mia vita in cui tutti i progetti sono stati completati in tempo e il budget era stabile - È la mia università dove ho studiato e lavorato in un laboratorio informatico per la scienza. Per le attività, che la maggior parte delle aziende chiede di terminare in 1-2 mesi, nell'università abbiamo avuto un anno. Nelle aziende ti danno $ N all'ora, dopo un po 'dicono "Abbiamo perso alcuni clienti, i tizi fuori mi hanno rubato la borsa con il tuo stipendio, il capo ha divorziato con sua moglie e lei vuole metà del suo biz, ..." ecc. e la tua commissione diminuisce di $ K, poi di $ K di nuovo e di nuovo. Fino a quando pensi di dover pagare per quello che fai. Nell'università hanno un'offerta per $ XXX, XXX.XX divisi su: rettore, manager, supervisore, altre persone, i tuoi colleghi (principalmente altri studenti) e te.

Ovviamente questo è molto meno denaro di quello che puoi avere nelle aziende, ma per un rischio che dovresti pagare.

Sì, ho lavorato una volta in questo tipo di progetto. Non era una piccola applicazione web per la gestione di documenti, per un'azienda piuttosto grande, in cui i diversi documenti potevano essere classificati in nodi diversi, supportando meta-dati per documenti e nodi, diversi livelli di autorizzazione, ecc. i punti chiave per me erano:

• Requisiti chiari, concisi e ben definiti,
• La gestione si è concentrata sulla facilità con cui gli sviluppatori lavorano, non a guardare il loro lavoro, a controllarlo o a sollecitare gli sviluppatori. Di questo, nell'ultimo rush, il manager ha appena detto a tutti "ragazzi, dobbiamo consegnare la prossima settimana, proviamo ad arrivare in tempo", e tutti hanno fatto la nostra parte per raggiungere l'obiettivo. Fiducia è una parola chiave per me nella gestione del team.
• Trascorrere del tempo nella fase di modellazione del sistema, non è affatto uno spreco, ma un investimento. Un design dettagliato consente di risparmiare molte ore di sviluppo.
• E per ultimo, ma non meno importante, una buona relazione tra i membri del team e un ambiente amichevole fanno di più per la produttività di quanto siamo abituati a pensare.

Abbiamo creato un'applicazione di servizio per elenchi multipli basata sul web. Il primo ha richiesto più tempo, ma l'idea era di creare un'app solida che potesse essere clonata abbastanza facilmente. Mentre una buona dose di R & D è entrato nel primo, siamo stati in grado di spegnerli abbastanza rapidamente e abbiamo realizzato un profitto su ognuno di quelli venduti.

Non ci lavoro più ma è ancora una buona applicazione.

Applicazione Webfodder MLS