Come si crea un processo software per un progetto?

13

Come ho scritto in altre domande qui, il progetto a cui sto lavorando ora non ha alcun processo software. Ciò significa che nessuna documentazione (inclusi requisiti o specifiche della copia cartacea) , nessun controllo del codice sorgente , nessun database di bug , i bug sono "corretti" (si spera) e il nuovo codice viene aggiunto contemporaneamente e nessun tester formale - falliremmo con Joel Test così male, non è nemmeno divertente.

Ieri il mio manager mi ha chiesto di scrivere un documento su come iniziare a correggere queste carenze. Nota che sono solo uno stagista, qui per 6 mesi. Partirò per il Ringraziamento a novembre per tornare a scuola. Tuttavia, penso che forse potrò spostare questo progetto nella giusta direzione, ma non sono sicuro da dove cominciare. Attualmente sto usando CiteSeer e Wikipedia per tentare di trovare alcuni documenti e tali che descrivono i processi software e li implementano, ma qualsiasi consiglio, esperienza personale o link a blog, documenti, articoli wiki o qualsiasi altra cosa sarebbe molto apprezzato.

development-process specifications

— Thomas Owens
fonte

Processo buono-veloce-economico - quando un progetto si fa indietro, abbassa il processo.

— ChuckCottrill,

2

Come è andata a finire?

— Robert Harvey,

10

Suggerirei di esaminare la programmazione Agile.

Ci sono molte varianti, ma tendono ad avere alcune cose in comune:

Revisione periodica e ridefinizione delle priorità delle funzionalità.
Integrazione continua e test unitari automatizzati.
Concentrati sulla comunicazione sulla documentazione (in pratica questo significa documentazione in stile wiki mentre passi su enormi specifiche non flessibili scritte in anticipo).
Stime flessibili che danno luogo a grafici di burn-down e metriche di velocità.
Prototipi regolari che vengono esaminati su oltre 200 specifiche di pagina con firme.
Qualità alla fonte, o il più vicino possibile.
Revisione periodica delle parti interessate - un'estensione della comprensione dei clienti.
Portare il software sul mercato (e fare soldi) al più presto.
Comunicazione diretta il più possibile.

Un buon punto di partenza sarebbe MSF Agile o Scrum .

— Keith
fonte

7

Data la situazione, sei partito tra 6 mesi e il team non ha avviato alcun processo, limiterei l'ambito di ciò che introduci a una o due cose che possono essere ragionevolmente implementate e prendere piede nel tempo in cui sei lì. Se fossi in me darei un'occhiata a uno strumento di controllo del codice sorgente e un bug tracker.

Il motivo per cui vorrei iniziare lì è perché mettere in atto questi strumenti ti aiuterà a stabilire una base per le prestazioni attuali dei team e possibilmente identificare i problemi ricorrenti. Le modifiche al processo sono utili, ma si tratta di elementi di base di base che dovrebbero essere inseriti prima.

Sì, ho intenzione di limitare la portata di ciò che faccio, ma voglio anche lasciarli con una tabella di marcia in modo che non rimangano a chiedersi cosa fare dopo, soprattutto se le cose iniziano a migliorare.

— Thomas Owens

@Thomas Owens Penso che sia lodevole che tu voglia lasciare alla squadra una tabella di marcia per dopo che te ne sei andato. Tuttavia, è improbabile che qualcuno faccia riferimento a una tabella di marcia creata da uno stagista. Questa non è una riflessione sulle tue abilità e abilità. Stando così le cose, farei tutti gli sforzi possibili per mettere in atto i primi passi. Non sottovalutare lo sforzo necessario per modificare le abitudini e i processi di una squadra esistente. In effetti, cercare di ottenere sia il controllo del codice sorgente sia un bug tracker implementato in sei mesi può essere più di quanto si possa ragionevolmente fare.

Penso possa essere fatto. Questa è una squadra di 5 persone, escluso me. Due sono sviluppatori a tempo pieno, uno è uno sviluppatore part-time su questo progetto e part-time su altri progetti, uno è un manager e uno è un tipo di marketing. Entrambi gli sviluppatori a tempo pieno sono a bordo per un processo e il manager vuole vedere miglioramenti per le prestazioni del team. Non è come se fosse stato forzato contro la loro volontà.

— Thomas Owens

1

Usiamo Prince2 per i processi di project management e funziona molto bene. Suggerirei che sembrerebbe tortuoso per un'azienda senza una gestione del progetto in atto!

— ColinYounger
fonte

1

Abbiamo adattato la pipeline di sviluppo descritta in questo video alle nostre esigenze, utilizzando TeamCity come nostro server CI.

http://channel9.msdn.com/shows/ARCast.TV/ARCastTV-Tuning-The-Development-Process-at-Spot-Runner/

TC è l'unico sistema CI di cui sono a conoscenza che fa un repository-push anziché pull, il che significa (teoricamente) mai più build rotte!

1

Solo per riecheggiare i sentimenti di alcuni dei precedenti, quei team che non hanno una struttura si adatteranno meglio con una struttura agile. Ottieni il controllo del codice sorgente oggi basta iniziare a inserire le tue modifiche in SVN e mostrare ad alcuni dei tuoi sviluppatori una diff quando sei alla ricerca di bug. Inizia ad aggiungere registri di revisione. Se non riescono a vedere i vantaggi e la facilità d'uso di SVN, sono condannati.

— Johnno Nolan
fonte

0

Dai un'occhiata a questi articoli sull'integrazione continua per la programmazione .NET usando MSBuild, CruiseControl.NET, FxCop, NUnit, NCover e Subversion ...

Dalle trincee di sviluppo software

— Zack Peterson
fonte

1

@Zack: non utilizziamo la programmazione .NET. Sto cercando consigli generali che possano essere utilizzati su qualsiasi progetto utilizzando qualsiasi stack tecnologico. Cose come scegliere un modello, implementare quel modello e così via.

— Thomas Owens