Cosa posso usare per tenere traccia dello stato di 60 programmi, alcuni dei quali sono obsoleti? [chiuso]

7

Ho assunto un ruolo di sviluppo software in una società di ingegneria (tutto il software sviluppato è solo per uso interno). La compagnia ha circa 60 programmi individuali di sviluppatori passati. Il problema è che tutti gli sviluppatori passati se ne sono andati e nessuno sa perché è stata costruita circa la metà del software, chi la usa o persino cosa fa. Usiamo SVN, ma nessun sviluppatore passato ha scritto commenti o ha fatto alcun tipo di documentazione.

Supponendo di capire tutto questo, c'è qualche programma / sistema / metodo che potrebbe essere usato per tenere traccia di tutte queste informazioni? La società si sta orientando verso Excel, presumo ci sia qualcosa di meglio. Sarebbe semplicemente meglio scrivere la documentazione in un documento di Word e trasferirla in svn, quindi è proprio accanto al codice?

    
posta Brandon 24.05.2013 - 15:22
fonte

8 risposte

14

Uso i file di testo all'interno del progetto per quel genere di cose. Sono facili da mantenere, facili da trovare e difficili da perdere. Word o Excel probabilmente funzionerebbero altrettanto bene se hai bisogno di condividere ma avrai bisogno di più disciplina per scrivere in una sorta di formato di log in modo da poter facilmente dire cosa è cambiato quando.

In una nota a margine, tenterei aggressivamente di ritirare il maggior numero possibile di progetti: è molto più facile gestire 20 progetti di 60.

    
risposta data 24.05.2013 - 15:34
fonte
6

Da ciò che stai descrivendo, è inevitabile che si debba fare del lavoro per avere una buona idea di cosa hai a che fare qui.

SVN è solo il repository. È pensato per archiviare il tuo lavoro in un modo che ti permetta di commettere errori senza che ciò porti a grossi problemi. Non dovrebbe essere usato per occuparsi della gestione del progetto!

Se riesci a ottenere qualche tipo di fondi per un server economico che esegue un software di gestione del software di sviluppo software / ALM, potrebbe aiutarti in termini di sviluppo di tracciamento e query utente, tutti collegati al tuo repository! Sono un grande fan dell'utilizzo del software ALM. Può aiutarti a comunicare e pianificare il tuo sviluppo in un modo che rende il collegamento umano meno dipendente. Se usato correttamente, può davvero aiutarti a strutturare il tuo processo. (Richiede una certa disciplina)

Se disponi dei fondi per eseguire un server Windows, vai a TFS. Sembra una buona idea di ciò che stai descrivendo, ma costa più denaro rispetto agli strumenti FOSS. D'altra parte, è un insieme di strumenti molto ben integrati, quindi ti permetterà di gestire i tuoi progetti in un ambiente ben integrato con una curva di apprendimento poco profonda. (Supponendo che tu non voglia niente di speciale, TFS è altamente configurabile, ma una PITA da configurare se non hai lavorato con i tecnici coinvolti prima.)

Alternative FOSS che mi piacciono: trac, redmine o chilliproject. Tranne per il redmine, li ho usati solo come utenti, quindi non posso davvero dirti quanto sia facile configurarli.

Se la gestione non andrà oltre Excel, sei sfortunato. In questo caso è giù per buonsenso. Suggerirei di avere una sorta di foglio di panoramica e una cartella di lavoro per progetto con una pagina per il tracciamento dei bug, una pagina per la pianificazione del rilascio e una pagina per la documentazione delle versioni. (L'hai appena inventato, ma sembra un inizio se non riesci a procurarti strumenti adeguati per fare il tuo lavoro)

In termini di chi sta usando quel softare? Questa è la supposizione di chiunque. L'unico modo per dirlo è il polling di potenziali utenti, a meno che non abbiano connessioni attraverso la rete che è possibile cercare con l'aiuto di un / l'amministratore di rete. Per quanto riguarda il software, devi analizzarlo se non ci sono documenti disponibili e nessuno è in grado di fornirti tali informazioni. Il modo rapido ma impreciso sarebbe quello di eseguirlo in una sorta di sandbox e dare un'occhiata. Il modo lento ma completo sarebbe quello di rivedere il codice. (Forse esegui il reverse engineering con l'aiuto di uno strumento UML con capacità di round trip per una rapida panoramica della struttura)

Per quanto riguarda la parte senza documentazione. Questo sembra un buon momento per sottolineare la necessità della documentazione. I documenti hanno due lati: il codice di commenti e la creazione di documenti di panoramica / utilizzo.

    
risposta data 24.05.2013 - 15:43
fonte
4

Ovviamente dovrai documentare il più possibile ogni progetto, ma avrai anche bisogno di un "luogo" centralizzato dove hai il tuo catalogo di servizi / prodotti, descrivendo i "metadati" del progetto come hai sottolineato: dipartimento lo sta usando? Chi è responsabile di mantenerlo? A cosa serve? Quali dipendenze con altri progetti ci sono?

Quel "luogo" può essere qualsiasi cosa che funzioni per te e la tua azienda, come un documento o un foglio Excel. Ma ovviamente puoi usare più strumenti o prodotti "complessi" come un wiki, un sistema di gestione dei documenti o prodotti specializzati in materia.

Ti consiglio di dare un'occhiata a ITIL, dove definiscono ciò che chiamano il catalogo dei servizi ITIL: link , solo per avere un'idea.

    
risposta data 24.05.2013 - 15:54
fonte
3

Come fa notare Dan, avere un readme.txt nel progetto è fondamentale - non ha bisogno di essere spesso, ma dovrebbe coprire abbastanza per far sì che una persona formata costruisca e esegua il debug del codice. Le cose fondamentali da considerare sono le configurazioni esterne e le dipendenze e altre tipologie di mine.

Vorrei anche consigliare l'utilizzo di uno strumento di monitoraggio del progetto con integrazione SCM. Personalmente sono parziale al redmine in questi giorni. Se utilizzati correttamente, tendono a essere buoni, facili e auto-alimentando la documentazione nel tempo. Trovo che il nostro redmine sia particolarmente prezioso per le occasioni in cui ci si deve immergere in un progetto che è rimasto dormiente a lungo poiché ci sono cose che si possono imparare da Redmine che non si possono imparare da altri strumenti di progetto.

    
risposta data 24.05.2013 - 16:14
fonte
3

Invece di un semplice foglio di calcolo o file di testo, suggerirei qualcosa come TiddlyWiki . È un wiki semplice che gira interamente all'interno di un browser, quindi non c'è niente da installare o configurare. Attaccalo in un luogo pubblico e periodicamente esegui il backup (basta impegnare il file in un repository Subversion). Fornirà un po 'di struttura senza (si spera) essendo troppo limitante. Se hai bisogno di qualcosa di più, Liferay offre uno strumento di "gestione della collaborazione" open source basato sul portale. L'ho usato su un paio di progetti, ma probabilmente è eccessivo per quello che stai cercando di fare.

    
risposta data 24.05.2013 - 21:09
fonte
2

Ciò a cui ti riferisci per gestire un "portfolio" di applicazioni è Project Portfolio Management (PPM) e / o Application Lifecycle Management (ALM). Esistono numerosi strumenti dalla gestione semplice a basso costo alla gestione di fascia alta.

Fai del bene a te stesso e alla tua organizzazione NON tentando di mettere un cerotto sul problema con le soluzioni basate su file. Alcuni strumenti PPM che ho implementato per i client includono:

AtTask - Livello basso, SaaS disponibile, configurazione semplice e limitata

Planview - Alto livello, SaaS disponibile, ultima configurabilità

Chiarezza - Livello intermedio, SaaS sconosciuta, configurabilità limitata

    
risposta data 30.05.2013 - 13:51
fonte
0

Redmine .

Crea un progetto per ciascuno dei tuoi progetti, associa ciascuno alla sezione SVN che contiene il codice e vai da lì. Ogni progetto acquisirà un bugtracker e una wiki e un modo per tenere traccia delle modifiche e delle informazioni su ciascun progetto mentre si determinano le informazioni. Inoltre, puoi vedere il codice che comprende i progetti e legarlo a bug o documenti.

Il secondo bonus è un ottimo strumento per la gestione dei progetti gratuito.

    
risposta data 30.05.2013 - 14:25
fonte
0

Redmine consente di configurare una gerarchia di progetti e ogni progetto ha una propria wiki separata. La formattazione wiki è molto semplice, quindi non devi impazzire. La maggior parte dei wiki che creiamo sono solo una singola pagina, con collegamenti a riferimenti esterni, alcuni paragrafi che piagnucolano sul codice scadente e poi alcune note su% importante%.

Supporta anche l'integrazione del codice sorgente, e c'è una sintassi per il collegamento diretto al codice dal wiki, fornito da un plugin.

    
risposta data 30.05.2013 - 15:34
fonte

Leggi altre domande sui tag