Come posso superare un modello di sviluppo software mal strutturato?


11

Sono entrato a far parte dell'azienda al momento sto lavorando come più fresco. A causa del numero limitato di persone qualificate nello sviluppo del software GIS, e poiché ero tra i primi, sono stato reclutato direttamente come Project Manager.

Ero abbastanza esperto di Java e GIS e ho svolto ricerche automotivate sui servizi basati sulla localizzazione, ma non con la gestione dei progetti e lo sviluppo strutturato del software. Fu un anno dopo la mia laurea in Geologia speciale e durante l'anno precedente lavoravo come accademico in un'università.

Grazie all'interesse che avevo al lavoro, si presentò un'opportunità e alla fine fui anche responsabile del dipartimento di Business Intelligence dell'azienda. La società ha creduto in me. Io stesso ho studiato il data warehousing e i concetti di BI e sono riuscito a combinare GIS e BI.

Inoltre sto attualmente lavorando con due sviluppatori sul nostro strumento BI in C # WPF, dove a volte ricopro anche il ruolo di sviluppatore (che mi piace).

Ho provato molto duramente ad adottare buone metodologie di sviluppo software con una gestione dei progetti agile, ma non ha avuto molto successo. Inoltre, anche se credo in un codice ben progettato per quanto riguarda un prodotto, a causa della mancanza di conoscenze tecniche del mio CEO (che è direttamente al di sopra di me), di solito non ottengo il tempo necessario per farlo. Il tempo impiegato è notevolmente migliorato dalla mancanza di esperienza che abbiamo anche nello specifico linguaggio di codifica nel suo insieme (ad esempio WPF al contrario di Java). Inoltre non esiste un sistema di controllo della versione.

Sono estremamente stufo di come vanno le cose perché non è strutturato e trovo la maggior parte del mio tempo a pensare piuttosto che a lavorare su come strutturare le cose. Spero che voi ragazzi con una buona esperienza professionale mi aiutiate a superare questa situazione.


4
Non sono sicuro che tu l'abbia già fatto, ma hai discusso della situazione con i tuoi colleghi immediati?
Fanatic23,

Risposte:


14

Abbiamo avuto un problema simile (senza i dettagli tecnici, ovviamente) nell'azienda che lavoro circa due anni fa.

Hai solo bisogno di farlo un passo alla volta. Non provare ad adottare lo sviluppo software agile in fretta. Ci sono molte cose da imparare e applicare. Non lasciare che la mancanza di competenza per abbatterti.

Costruisci lentamente (ma il più velocemente possibile: P), costantemente e sicuramente.

Consiglierei i prossimi passi (per fare questo, potresti passare dalla gestione allo sviluppo per un po ', ma dovrebbe andare bene)

  1. Impara un buon sistema di controllo della versione e imparalo bene. Personalmente consiglierei git o mercurial. C'è molta documentazione su entrambi.
  2. Costruire un solido nucleo su pratiche e modelli . Leggi libri, leggi blog, guarda screencast con i membri del team. Ciò darà una nuova aria allo sviluppo.
  3. Scopri TDD / BDD e prova ad applicarlo nel nuovo codice , così come nel vecchio codice che potresti toccare quando esegui una nuova funzionalità.
  4. Fare pair programming . Due teste pensano meglio di una, e anche 4 occhi sono meglio di 2 :).
  5. Trova gli strumenti usati più recenti e più comuni nella comunità della lingua che stai attualmente sviluppando. Informati su di loro e prova a includerne alcuni nel progetto. Guarda come sono stati costruiti e impara.
  6. Usa la mischia . Iterazioni, storie, punti della storia, impedimenti sono tutti concetti con cui dovresti familiarizzare. Per me, scrum ha dimostrato di essere il miglior flusso di lavoro per lo sviluppo e la gestione del software. Applicalo e impara dall'esperienza di ogni giorno.
  7. Insegna con l'esempio . La maggior parte degli sviluppatori principianti è desiderosa di apprendere nuove cose, ma anche alcuni di loro sono molto pigri. Ad ogni modo, mostra loro le nuove cose che hai imparato e applicato e, si spera, che solleticheranno il loro cervello.

Inoltre, se possibile, assumere un consulente solo in modo che possa controllare il processo e dare consigli migliori.

Non essere pigro o scoraggiato. Impara dai tuoi errori e prova approcci diversi. Questo è solo l'inizio!

Modificare:

Ecco alcuni dei link e dei libri che ho letto / utilizzato di recente ...

Apprendimento git: Pro Git

Questi sono alcuni dei blog che consiglierei (la maggior parte di essi sono orientati a .NET):

Per i libri, puoi vedere l' elenco Buiding A Solid Programming Core su amazon. Vorrei anche raccomandare questi:


@Edgar, grazie mille. È bello e penso che quello che hai spiegato funzionerà bene per me. Dato che non vedo altro modo fammi sapere se è giusto prendere la tua risposta come corretta e attenerci ciecamente.
picmate

1
@picmate Certo amico, questa è la tua chiamata. Inoltre, quando fai un esempio, assicurati di elogiare qualsiasi progresso fatto dagli sviluppatori.
Edgar Gonzalez,

@Edgar, certo. Se conosci delle buone risorse che potrei usare, ti preghiamo di metterle anche per me contro ogni punto della tua risposta (se applicabile). Inoltre, è questo il modo in cui una buona società di sviluppo va avanti con lo sviluppo del suo software? (dal momento che non ho mai avuto la possibilità di essere in una buona compagnia di sviluppo)
picmate

1
@picmate innanzitutto, questi passaggi non devono essere applicati separatamente. Si sovrappongono, non sono in alcun ordine particolare (tranne il primo). Pubblicherò alcuni link più avanti nel corso della giornata
Edgar Gonzalez,

2
@picmate. Dal momento che il CEO non ha conoscenze tecniche su ciò che fai, puoi convincerlo attraverso ciò che sa. Ad esempio, puoi spiegare che se hai il controllo della versione in atto, puoi evitare la perdita di lavoro, e quindi prevenire finanziariamente la perdita di entrate nel ripristino del codice perso, o apprendendo le migliori pratiche di sviluppo, puoi aiutare l'azienda essendo efficiente, quindi riducendo i tempi di sviluppo di una funzionalità.
Onesimus Nessun impegno,

6

Come manager, è il tuo compito ottenere il tempo necessario per completare correttamente un progetto. Quando ti avvicini al CEO, assicurati di avere tutti i dati a supporto e i motivi per cui le stime sono lunghe quanto lo sono. E ' la tua responsabilità come manager per fare l'amministratore delegato a capire perché ci vuole n ore / giorni / settimane per completare un determinato compito. Questo a volte può essere difficile, ma non ho ancora incontrato un CEO che vuole che la sua azienda fallisca ancora e scommetto che se lo metti in quel tipo di termini (se tutto il resto fallisce), potrebbe cambiare la sua melodia.

Se il CEO non è disposto a concederti il ​​tempo necessario per completare le attività, allora IMHO, sii pronto per passare a un altro lavoro o prepararti per le continue marce a morte. Come ultima risorsa, spiega al CEO il burnout che verrà senza dubbio dalle aspettative non realistiche.

Detto questo, devi anche assicurarti che i tuoi sviluppatori ti stiano fornendo stime accurate (tremendamente difficile, quasi impossibile senza una corretta progettazione tecnica, che dovrebbe anche essere lì da qualche parte).

Agile non è buono in tutti i domini di sviluppo. Funziona per alcuni tipi di progetto, fallisce miseramente in altri. Potrebbe essere necessario provare alcune metodologie diverse prima di trovare quella che funzioni bene .

Ottieni il controllo della versione impostato . In realtà, ci vogliono 5-10 minuti per configurare Git, qualche altro minuto per far decadere le operazioni di base e un giorno o due di lettura per far decadere i concetti più avanzati.


1

Hmm, non sono sicuro di averti incontrato ad un evento Agile / XP a Toronto - sembra familiare

Sembra che tu abbia bisogno di una pausa. Concediti un lungo weekend, ubriacati se vuoi, e dimentica il lavoro per qualche giorno.

Rilassati. L'autodidatta è buona, e solo perché una metodologia non funziona con le personalità coinvolte, non significa che stai sbagliando, e non è un fallimento personale.

Esiste un sito (beta) pm.stackexchange.com, destinato alla gestione dei progetti, potresti ricevere qualche consiglio / supporto utile lì - ma in ogni caso, mantieni anche la domanda qui.

Passando al materiale tecnico:

non esiste un sistema di controllo della versione in atto

Mettine uno come priorità assoluta. Preferisco sistemi centralizzati come SVN (Subversion) rispetto a git / mercurial, perché un laptop rubato non avrà tanta storia a livello locale. Particolarmente importante se qualcosa di super-segreto (come password e ssh-key) è stato verificato per errore. Ma è una questione di gusti. Niente perde più tempo dei bug del "controllo manuale della versione", ad esempio riportando il codice a quello che pensi fosse.

In bocca al lupo


Ciao, grazie per la risposta e probabilmente non sono stato io che hai incontrato a Toronto. Sono in questa posizione per quasi un anno e mezzo. Pensi che sto perdendo tempo senza successo?
picmate

0

Sembra che tu abbia diversi problemi: 1. Comunicare con alti dirigenti non tecnici in modo che possano supportare il tuo programma di miglioramento; e 2. Promuovere il programma di miglioramento per il successo.

La parte più difficile del numero 1 è semplicemente ricordare che il senior management spesso non sarà interessato ai dettagli di ciò su cui stai lavorando. (Se lo fossero, lo farebbero da soli invece di consegnartelo!) Sembra che il grande ostacolo sia il "perché" e potresti voler esaminare CMM 1.1 per una descrizione dei vantaggi aziendali di un miglioramento del processo programma. Sia che utilizzi la CMM o qualcos'altro per migliorare effettivamente il tuo processo, non importerà a questa discussione, solo i dati dello studio Carnegie-Mellon che mostra che le organizzazioni più mature consegnano i progetti più velocemente con meno variazioni nei tempi di consegna.

Ci sono molte strade per il successo nel miglioramento dei processi, tutte tendono ad essere molto lunghe. L'esperienza con CMM mostra che possono passare da 8 a 10 anni per passare dal livello 1 a 5. L'esperienza con 6 sigma mostra che ogni iterazione fornisce alcuni miglioramenti ma ha bisogno di più iterazioni per rimuovere la maggior parte dei potenziali problemi e, al momento in cui si arriva a 6 sigmi di qualità, il lavoro viene svolto in modo completamente diverso senza dover correre il rischio di provare a sostituire tutto in una volta.

Se esiste un approccio di miglioramento della qualità comunemente usato nel tuo settore, prenditi il ​​tempo per provare a vedere come si applica al software e utilizzarlo in modo che il resto dell'azienda ascolti qualcosa di cui già conosce e supporta. Possiamo parlare per ore di strumenti e pratiche software specifici, ma i CEO non software lo sintonizzeranno rapidamente. Parla delle pratiche standard del settore e lui si rianimerà perché stai parlando la sua lingua. Parla del software nei termini comuni del settore e inizierà a porre domande pertinenti per comprendere meglio le tue sfide e i tuoi piani per migliorare i risultati delle aziende.

Non vincerai tutte le richieste di supporto in questo modo, probabilmente avrai molti meno look vuoti e più vittorie!

Buona fortuna signore!


0

Tutti i tuoi suggerimenti sono davvero sensati e sono la strada da percorrere in molte aziende. Ma non sono universali, specialmente con squadre che non sono così esperte. Il motivo per cui non lo sono è che richiedono una certa quantità di lavoro per l'installazione e la manutenzione, anche il controllo della versione, che molti presumono essere la posta in gioco per qualsiasi progetto software. Poiché richiedono un po 'di lavoro, devono anche fornire alcuni benefici. E potrebbe accadere che nella tua situazione particolare non lo facciano! O almeno le persone incaricate di prendere le decisioni non ne vedono i benefici!

Come altri hanno sottolineato, è necessario:

  • Prova ad adottare le pratiche a turno. Non provarli tutti in una volta perché sopraffanno le persone.
  • Devi trovare un buon ordine per questo. Vorrei iniziare con il controllo della versione. Vai quindi anche con quelli più facili. Una volta che le persone iniziano a fidarsi di prendere buone decisioni e vedono i benefici, avranno maggiori probabilità di adottare cambiamenti più rischiosi.
  • Crea un solido caso per cui qualcosa deve essere implementato. Con 2-3 sviluppatori che rendono costantemente visibili i progressi agli utenti finali, ad esempio, è difficile giustificare l'adozione di una metodologia di sviluppo più elaborata. Sarai visto come focalizzato sul processo piuttosto che focalizzato sui risultati.
  • Pensa a chi devi convincere. Gli sviluppatori? L'amministratore delegato?
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.