2008-10-30 10 views
5

Che cos'è una buona metodologia di programmazione per applicazioni personalizzate che devono essere codificate molto velocemente e molto personalizzate? Mi rendo conto che la mancanza di requisiti è un problema, non importa quale. Inoltre, come convinci il management a cambiare le loro pratiche? La prossima domanda è come convincere la gente a smettere di scrivere programmi con 5000 file singoli di riga?La migliore metodologia di programmazione per tempi rapidi e requisiti minimi?

+0

Questo è un evento abbastanza comune quando si ha a che fare con clienti semi-informatici. – slashmais

+0

Poni 4 domande in una. Propongo di dividerle e probabilmente ottieni risposte specifiche. Inoltre puoi guadagnare più reputazione ;-) –

+0

Sì, spaccare questa domanda sarebbe una grande idea! – Yarik

risposta

3

C'è più di una domanda che chiedi.

  1. rapido sviluppo con le esigenze 'piccolo' => violazione al sistema utilizzando un linguaggio di scripting, supponendo che ci sono i requisiti di piccole o pochi, al contrario di non ci sono requisiti stabili o esplicite ancora, ma ci saranno tonnellate in futuro
  2. sviluppo veloce con tonnellate di requisiti instabili o impliciti => scrum, XP, ecc. Concentrarsi sulla prototipazione per ottenere il feedback dal cliente su ciò che vuole il prima possibile
  3. Ottenere la gestione per cambiare le loro pratiche => Lasciare il progetto in crash il più presto possibile ;-) Scherzi a parte, questo richiede che tu sia più specifico su ciò che vuoi cambiare. Il tuo chilometraggio dipende, naturalmente, da quanto è assurdo il tuo ambiente e da quanto sei cinico riguardo al raggiungimento dei tuoi obiettivi.
  4. Come smettere di scrivere programmi di linee 5K in un singolo file => Mostra in che modo è un problema per te, come sarebbe altrettanto facile scrivere programmi strutturati migliori, mostrare il vantaggio che potrebbero avere da esso pure, e cerca di concordare reciprocamente su una pratica migliore.
10

run ... come l'inferno

+0

Ha vorrei poterlo fare. – nportelli

7

Scrum è bene utilizzare su questi tipi di progetti. È fantastico fornire un modo per persuadere la gestione che puoi avere il progetto in tempo o puoi averlo con tutte le funzionalità che desideri, ma non puoi averle entrambe.

+0

"questi tipi di progetti"? Scrum è grandioso e lo raccomando vivamente, ma mi piacerebbe evitare di dire all'OP che qualsiasi metodologia agile farà del bene a questo progetto. A lungo termine, appanna il termine "agile". –

+0

Almeno con scrum è possibile che la gestione si impegni a rispettare una piccola serie di requisiti per sprint. E su questo puoi dire loro cosa si può fare nello sprint con una qualità decente. O lo accettano o ... corrono come un inferno. –

7

Utilizzare la forza.

Ma seriamente, questo suona come un Death March. Scappa.

0

Scrum sarebbe la mia ipotesi, ma tenete a mente che la mischia richiede membri del team molto disciplinati. Prendi l'abitudine di documentare quali requisiti ottieni e tenerli in un posto in modo che tutti, inclusa la gestione, possano accedervi. Infine, trova un modo ragionevole di eseguire le attività di previsione e tenerlo di fronte al management in modo che conoscano le priorità attuali di tutti i membri del team. Sono stato in un ambiente molto simile per l'ultimo anno e sfortunatamente non ho scoperto un proiettile magico.

Scrivere 5000 programmi di linea è un segno di pura pigrizia. Recentemente abbiamo lasciato andare un ragazzo, perché in primo luogo ha iniziato con 5000 classi Java linea, quindi ha utilizzato le istruzioni try/catch per inizializzare le variabili in un costruttore (non chiedere). Trova un modo per motivare il ragazzo a scrivere i 5000 programmi di linea con alcune critiche costruttive. Sembra che sia comunque un problema di gestione al centro di esso.

1

Il modo più rapido per fare qualsiasi cosa che assomigli a un ragionevole sviluppo personalizzato è con voi e il cliente che lo sviluppano insieme. Il feedback è istantaneo e possono vedere esattamente ciò che è coinvolto. Altrimenti, stai solo scambiando velocità per la loro più comoda attenzione. Inoltre, poiché hanno lavorato direttamente con te, potrebbero difenderti dalla tua gestione.

Tuttavia, senza ulteriore contesto, devo essere d'accordo con gli altri e dire che probabilmente non è la situazione che crea più carriera.

1

Se "mancanza di requisiti" è davvero il fatto, allora NON si dovrebbe nemmeno iniziare un progetto. Credo che quello che intendi sia "non chiaro o incerto sui requisiti". Se questo è il tuo caso, allora Processo Agile è ciò che dovresti prendere in considerazione. XP, Scrum o Crystal. Scrum è senza dubbio il processo agile più leggero.

La gestione può avere una mente diversa dagli ingegneri, ma non si può dire che la gestione sia sbagliata e le loro pratiche dovrebbero essere cambiate. Basta comunicare di più per migliorare la comprensione e affrontare i conflitti.

Per impedire alle persone di scrivere codice illeggibile, il modo migliore per addestrare le persone a scrivere codice in modo conciso. La combinazione di programmazione e revisione continua del codice potrebbe essere una buona soluzione.

5

Come regola generale si hanno tre componenti di un progetto, Tempo, Qualità e denaro.

Sembra che il tuo cliente/capo voglia controllare il Tempo ... e che dovrebbe controllarne uno di più, l'altro il controllo.

Quindi, se vuole controllare il Tempo e la Qualità, ha bisogno di pagare a te e/o alla tua squadra più denaro per tutto il tempo extra che stai per mettere. Se vuole controllare Tempo e Soldi, devi controllare la qualità, che in questo caso sarà bassa.

Quello che diciamo sempre ai nostri clienti è che possono averlo diritto o possono averlo Ora, ma non possono averlo in questo momento!

Non penso che la metodologia contenga molto ... il vero problema è il tempismo.

+0

Il problema con scarsa qualità è che torna sempre a morderti. – nportelli

+0

Sono assolutamente d'accordo ... ma ancora una volta, il cliente non può aspettarsi di crunch la timeline, mantenere la stessa scala di paga e mettere fuori un prodotto di qualità. – mattruma

5

Niente di nuovo qui!

Quello che ho trovato funziona molto bene è una tecnica RAD chiamata Evolutionary Prototyping.

L'approccio migliore è quello di implementare la tua idea di ciò che il cliente vuole, quindi presentarlo a lui, ottenere i suoi commenti e adattare la vostra implementazione di conseguenza. Quando il cliente è alla fine soddisfatto, il tuo impianto è terminato. Ora arriva la parte divertente: documentalo!

0

Scrum o XP funziona abbastanza bene in queste circostanze; Se riesci a superare alcuni requisiti minimi per un sistema "di base" e crearne uno, puoi essere reattivo al fatto che anche quando vengono forniti i requisiti iniziali, sono quasi sempre sbagliati.

Le persone che scrivono 5000 programmi di file singoli sono programmatori indisciplinati e cattivi. Dal momento che sia XP che Scrum richiedono la disciplina per creare un sistema che possa essere mantenuto e costruito, non sono sicuro di come procedere se è quello con cui devi lavorare. Il mio indovina vorrebbe almeno tentare di convincerli dell'errore dei loro modi.

3

Non voglio essere sfacciato ma sembra che la maggior parte delle persone si sia confusa con la risposta che si cerca. La maggior parte delle risposte sembra essere basata su metodologie di gestione del progetto piuttosto che su metodi di programmazione.

Data la situazione, penso che i metodi SCRUM e di tipo agile (come Open UP) funzionerebbero bene dall'approccio di gestione del progetto. In effetti, rimango con SCRUM in quanto non sembra che ci sia molto nel modo di strutturare il tuo progetto. Manterrà le cose belle e snelle e dovrebbe concentrare l'attenzione sui compiti a portata di mano. Devi solo assicurarti di seguire alcune regole di base di SCRUM che sono identificare i tuoi compiti, stimare le tue attività, descrivere i tuoi compiti, pianificare le tue iterazioni e se possibile eseguire una retrospettiva di sprint. Se sei davvero puntuale, sono sicuro che potresti lasciar perdere.

Per rispondere alla tua domanda effettiva (come la vedo io comunque), vorrei suggerire di adottare un approccio di dominio guidato utilizzando CRC (C lass R esponsibiltiy C ollaborator) carte come il meccanismo di progettazione. Presumo che la tua applicazione abbia un dominio limitato in cui esiste, cioè contabilità, gestione delle scorte, ecc. Prova a scomporre il tuo dominio negli oggetti esistenti nel dominio, ad es. Gli oggetti del mondo reale come "articolo", "fattura" , "consegna" ecc. Quindi, per ciascuno di questi oggetti, creare una carta CRC in cui si definisce il nome, le responsabilità e le altre classi con cui collabora per eseguire le proprie responsabilità. Quindi scrivi le classi reali per rappresentare queste carte CRC nella tua applicazione.

Evitare di creare classi con suffisso Manager, o cooridinator o qualcosa del genere.Quello che dovresti ottenere è un insieme di oggetti che rappresentano il dominio che puoi facilmente modificare senza bisogno di un grande refactoring per eseguire qualsiasi tipo di attività che avvenga in quel dominio. È possibile adattare facilmente una soluzione creata in questo modo cambiando i requisiti in quanto gli oggetti di dominio dovrebbero rimanere statici, a meno che non si aggiungano più oggetti o il dominio si allarghi.

Spero che questo sia utile.

0

Ok Scrum sembra interessante ... può essere implementato quando gli uffici si trovano in luoghi diversi?

Problemi correlati