Come diventare un ingegnere del software? [duplicare]

Ho uno sfondo di avvio. Quello che stai vivendo è molto tipico, e nonostante ciò che molti dicono - se stai facendo abbastanza soldi per sopravvivere, lo stai facendo bene ... per ora. La tua domanda è molto valida, molto pertinente e (assumendo che lo start-up abbia circa 2-3 anni, in base a quanto tempo ci sei stato) molto tempestivo.

Il tempo di fallimento più comune per un'azienda è quello in cui ti trovi ora - a circa 2-4 anni, devi passare a una piccola azienda dall'inizio. Per evitare fallimenti a questo punto, una fase che viene in mente è "Investimento speculativo" Leggi su di esso, capiscilo e capisci quando lo fai. (Spendere più tempo per la codifica del necessario per portare a termine il lavoro è un investimento speculativo.) Non sto dicendo di non farlo, sto dicendo di capire quando lo fai e prendi una decisione consapevole che è appropriato (o meno) per oggi. Aggiungere test unitari è un ottimo esempio.

La transizione richiederà alcune modifiche, tuttavia quelle modifiche non devono compromettere le finanze. Non ha senso portare un BA, un PM e "Manager del software" e tutti i tipi di processi improduttivi se ti spaccano. Tutto ciò che fai deve essere fatto nel contesto "Come possiamo farlo accadere oggi, ed essere ancora in affari domani"

Uno start up ho lavorato per il team ha scritto il software per un prodotto. Quattro anni dopo fu descritto come una palla di fango / pila di S ..., il peggior codice che avesse mai visto ecc., Che non avrebbe mai dovuto essere rilasciato da una nuova recluta. Gli feci notare che gli azionisti avevano appena venduto la società e ne avevano messo in tasca 50 milioni di dollari. Gli ho chiesto come intendeva fare 50Mil in 4 anni, e come "farlo bene" avrebbe aiutato - In effetti, farlo correttamente ci avrebbe portato 8 mesi, non 8 settimane, le riserve di cassa sarebbero durate 3 mesi, i concorrenti sarebbero stati immessi sul mercato e la società avrebbe chiuso. Me ne andai e lui divenne un caposquadra. Hanno riscritto il codice da zero usando "best practice" bla bla bla, l'azienda ora ha meno del 5% della quota di mercato, in calo di circa il 75% ... ricavi da $ 250 milioni a circa $ 40 milioni .....

Quindi ecco i miei suggerimenti

• continua a "hackingare" palle di fango.
• Introduci Agile / SCRUM - ma non lasciarti rallentare - fai corsi su questo se non altro.
• Considera TDD e test delle unità. Ti aiuterà a rimanere in cima a quelle palle di fango - attento - non spendere troppo tempo su di esso o non sarai in affari per raccogliere i frutti
• Esegui i 6 cappelli di DeBono alla fine di ogni progetto.

Mentre cresci, fai attenzione - stai molto attento - a chi ti porti dentro. Hai bisogno di persone che hanno già attraversato la transizione. NON reclutare grandi tipi di società.

leggi questo - Mi piace particolarmente "E c'è un altro fattore coinvolto, che è che puoi dividere il nostro settore in due tipi di persone: quelli che vogliono andare a lavorare in un'azienda per avere successo e quelli che vogliono andare a lavorare per un'azienda di successo. I primi successi e la rapida crescita di Netscape ci hanno costretto a smettere di prendere il primo e iniziare a farlo . "

Quando ho lavorato con aziende che erano molto ad hoc nella metodologia, abbiamo esaminato i due o tre principali problemi di processo o infrastruttura che contavano "in questo momento" e abbiamo iniziato a investire in essi insieme ai normali impegni.

Non penso che la tradizionale "ingegneria del software" sia necessariamente il modello giusto per un piccolo team che si occupa di esigenze aziendali che cambiano frequentemente; l'ingegneria del software è più importante per gestire più fornitori e situazioni in cui il cambiamento è molto costoso e richiede cancelli di rischio e qualità. Se stai costruendo software per parti o automobili dello space shuttle, l'approccio dell'ingegneria del software potrebbe avere senso.

Invece, sostengo un approccio di "artigianalità del software" per la maggior parte delle organizzazioni. Ma l'ingegneria del software ha creato strumenti e ha scoperto processi che funzionano per molti tipi di team, quindi non sto dicendo che dovresti ignorare quelle lezioni, solo che dovresti lavorare da una prospettiva diversa che riguarda il miglioramento continuo, affrontare l'ambiguità e il cambiamento e impiega un paio di ore al mese per fare retrospettive su ciò che funziona bene e cosa non funziona bene con i tuoi processi di sviluppo e di business.

Nei tuoi panni, direi che probabilmente non ti preoccuperai di UML per ora; è necessario concentrarsi su come ottenere un sistema di controllo delle versioni leggero. Inizia con Git o Mercurial e iscriviti a repository privati con un fornitore di terze parti per inviare i repository a (Bitbucket, Github) o configurare un server locale su cui eseguire il push.

Quindi preoccupati di configurare un sistema di generazione continua (come Jenkins).

I team di piccole dimensioni potrebbero non essere in grado di permettersi i tester a tempo pieno, ma possono iniziare a creare una copertura di test unitaria automatizzata; anche l'avvio di questa pratica senza aderire religiosamente a un particolare dogma metodologico può aiutarti a scrivere nuovo codice in uno stato più gestibile, perché ti irriterai abbastanza per qualsiasi prova di scrittura che vorresti correggere il codice o dare test. Se hai le altre cose a posto e inizi a ottenere il minimo valore dai test, probabilmente preferirai correggere il tuo codice piuttosto che abbandonare i test.

Puoi farlo da solo investendo del tempo in esso. Può valere la pena assumere una persona per lavorare sui problemi dell'infrastruttura o del processo, ma i tre elementi sopra riportati sono in genere a bassa portata di frutta che mostreranno rendimenti immediati e richiedono investimenti relativamente minimi.

Per quanto riguarda i libri, leggi Pragmatic Programmer, Software Craftsmanship: The New Imperative e tutti i libri disponibili sul controllo della versione distribuita e sull'integrazione continua. Dovresti valutare Extreme Programming, Scrum e Kanban per vedere cosa pensi che funzioni meglio per la tua squadra. Per migliorare al processo, partecipare a riunioni o eventi locali con altri piccoli negozi di software e parlare di ciò che funziona e non funziona per te, e ottenere idee migliori dai tuoi colleghi su come far fronte ad alta velocità con piccoli team. L'ingegneria del software non si basa sul mantenimento della velocità, ma sul mantenimento del controllo delle cose che interagiscono con il tuo prodotto.

Una volta che hai un team di 5 persone, tuttavia, una sorta di guida per la gestione dei processi ha un senso finanziario per la maggior parte delle organizzazioni. Assumere un program manager o ScrumMaster o qualcosa del genere avrà qualche valore per i tuoi fondatori se ti aiuterà a fornire un lavoro più coerente e prevedibile.

The result is usually a clunk of hardly-maintainable yet working code.

La correlazione non implica causalità. Hai un codice goffo e difficile da gestire perché scrivi un codice duro e difficile da mantenere. Penso che il miglior strumento per migliorare questo sono le revisioni del codice. Un project manager non ti aiuterà a scrivere codice migliore. Assumere uno sviluppatore più esperto può essere d'aiuto, ma spetta davvero a tutti migliorare.

Despite everything we are literally flourishing with many successful apps on all platforms and bigger clients each project.

Quindi devi fare qualcosa giusto. Qualunque cosa tu faccia, assicurati di continuare a fare le parti giuste. Procedi con cautela e assicurati che le modifiche al processo da te adottate siano mirate a correggere alcuni specifici problemi che identificherai.

It's not that we are unaware that stuff like requirements analysis, UML, design patterns, source code control, testing, development methodologies... etc. exist, we just simply don't use them, and I mean like never.

Concordo con @JasonTrue che il controllo della versione di origine dovrebbe essere la tua prima priorità. In questo giorno ed età è imperdonabile non usare il controllo del codice sorgente. Gli strumenti sono disponibili gratuitamente (git, mercurial, subversion), sono facili da installare e utilizzare e il ritorno sull'investimento è praticamente immediato. Suggerirei di iniziare a fare alcune revisioni del codice e alcune revisioni del design, non più di qualche ora alla settimana. Prendersi un po 'di tempo per vedere cosa stai facendo, condividere le tue esperienze e prendere in considerazione modi migliori di fare può essere un grande aiuto. I praticanti agili chiameranno questa una retrospettiva.

Ancora una volta concordo con @JasonTrue che crea automazione e l'automazione dei test sono i prossimi passi naturali.

Una volta che hai il controllo della versione, le build automatizzate, stai facendo alcune revisioni del codice e retrospettive e semplici e semplici test automatizzati le cose andranno molto meglio. Basta aggiungere la quantità desiderata di caos in cima a quella: -)

Oh, e sicuramente leggi i libri: link

Il mio più grande consiglio: non provare a risolvere tutto in una volta, o cambiare troppo in una volta!

Il modo in cui procederai da qui dipenderà da alcune cose: quanto è impegnata la tua squadra, come tutti sono d'accordo con l'idea che anche le cose debbano essere migliorate, ecc.

Se le persone hanno bisogno di essere convincenti, probabilmente dovrai fare un sacco di lavoro da te all'inizio. Identifica alcune aree chiave che ritieni debbano essere migliorate, elabora una bella "soluzione facile" per ciascuna (puoi sempre migliorare di nuovo da lì), raccogli alcune stime su quanto a lungo dovrebbero essere prese e poi porta queste informazioni ai tuoi colleghi per vedere se è possibile ottenere un po 'di slancio.

Se tutti sono già a bordo, ma non sai da dove iniziare, collabora con loro per identificare le aree chiave e alcune potenziali soluzioni e le stime per eseguirle. Probabilmente aiuterà a pensare a questo da una prospettiva what-problems-are-we-experi piuttosto che a una prospettiva what-do-we-think-we-em> dovrebbe -to-essere-fare. Scoprirai che è più facile identificare soluzioni a problemi noti piuttosto che individuare azioni specifiche da una lista di desideri vaga.

Una volta che hai la tua lista, la priorità è comunque più adatta al tuo gruppo. Dal momento che sembra che le cose siano solo un po 'caotiche piuttosto che totalmente disfunzionali, suggerirei di andare con un approccio' meno sconvolgente prima '. Vai per il frutto a bassa attaccatura per iniziare a buttare via la roba dalla lista, lascerà che tutti si abituino ai cambiamenti in corso e affinano la tua strategia per gestire i cambiamenti più grandi.

Il controllo della versione è probabilmente il cambiamento che ti darà il più grande successo. Fatti un repo di prova con cui esercitarti per un po ', abituati al flusso di lavoro, quindi dimostralo ai tuoi colleghi e utilizzalo a pieno regime.

Un buon test ridurrà in modo significativo il tuo caos riducendo le brutte sorprese. I miei suggerimenti sarebbero:

• Quando correggi un bug, scrivi un test che puoi usare per controllare le regressioni nelle versioni future.
• Raccogli insieme un set di test di funzionalità di base da eseguire per ogni build e configura i rapporti se uno di essi non riesce, in modo che possa essere risolto al più presto.
• Crea e mantieni una mappatura di quali test coprono quali requisiti / funzionalità / bug

In termini di codice in sé, prova ad andare per un miglioramento incrementale. Ogni volta che tu (il team) aggiorni un metodo, controlla che sia correttamente commentato. Imposta recensioni di codice per modifiche importanti / importanti. Raramente è una buona idea provare a cambiare la progettazione del codice esistente, ma per i nuovi progetti, tenere una revisione del progetto all'inizio del ciclo di vita in cui si considera quanto sarebbe facile aggiornarlo, adattarlo, estenderlo o riutilizzarlo (è sufficiente modulare? è strettamente accoppiato?)

Soprattutto, continua a scheggiare! Se stai andando lentamente perché sei occupato, non preoccuparti troppo. Torna alla lista quando hai tempo.

In realtà sei nella giusta direzione per vedere all the shortcomings of the software development process seguito nella tua azienda. Riparare questo software e diventare più affidabile, verificabile e manutenibile non accadrà durante la notte. Puoi ottenerlo gradualmente, passo dopo passo.

Puoi iniziare a discuterne con le università about what can be improved attraverso l'introduzione di SDLC e ways how to gradually achieve it . Di sicuro, ci vorrà tempo e volontà per farlo accadere. Tuttavia, prima si inizia meglio da soli:)

Non penso che il tuo problema sia strano. È molto comune ed è una delle molte cause di fallimento fino al 95% delle start-up delle aziende (e anche molte non-start). Hai detto che ti sei laureato due anni fa ma non hai identificato la laurea. Se fosse informatica, alcune persone direbbero che sei un ingegnere del software.

Il Software Engineering Institute (SEI), con finanziamenti del Dipartimento della Difesa degli Stati Uniti, ha creato una scala e batterie di valutazioni chiamate il Capability Maturity Model (CMM) per misurare il livello di preparazione per avere successo nei contratti di sviluppo del software da parte del governo e altri . Caratterizzano la maturità per livello, dove il livello 1 è chiamato iniziale o caotico perché lo sviluppo del software non è documentato, ad-hoc, incontrollato e reattivo. L'abilità cruda di qualcuno coinvolto nel progetto è la cosa principale che tiene insieme le cose per creare un deliverable per il cliente. Molti di noi hanno partecipato a molti progetti di livello 1 in cui il duro lavoro e le persone intelligenti hanno salvato (o quasi salvato) il giorno.

La CMM originale raccomandava di avanzare di livello in sequenza. Il livello 2 chiamato ripetibile riguardava i processi relativi alla gestione. Il livello 3 definito definito riguardava le pratiche di gruppo definite dal management per gli sviluppatori. C'erano cinque livelli (4 è gestito, 5 è in ottimizzazione) e la diffusione tra gli strati era rappresentata da molte aree di processo chiave (KPA) che le organizzazioni avrebbero dovuto apprendere e praticare.

Un modello rivisto, CMMi (integrazione CMM), identifica livelli simili e discute le aree principali del processo. Ha lo stesso tipo di progressione orientata al livello chiamata in scena e una progressione orientata alla road map chiamata continuous. Con il continuo, è possibile selezionare i processi principali che sono più preziosi per l'organizzazione e per enfatizzarli con l'esclusione di altri processi.

La certificazione per CMMi è un'attività costosa e la documentazione è enorme e scoraggiante. Comprendere alcuni dei suoi concetti può essere utile, ma soprattutto in risposta alla tua domanda "Come essere un ingegnere del software?"

L'altra domanda su come risolvere tecnicamente la società è correlata, ma richiede suggerimenti più concreti.

• Comprendere i concetti che stanno alla base dei modelli del ciclo di vita del software (cascata, spirale, orientato alle funzionalità e, soprattutto, iterativo / incrementale). Da qualche parte durante lo sviluppo dovresti fare non solo codice, ma anche analisi, progettazione e test. Per essere agili, questo può essere la creazione di story card o casi d'uso con flussi alternativi, creazione di unit test e scrittura di codice, spesso una funzione alla volta.
• Assicurati che ogni progetto abbia un ambito di dimensioni ragionevoli per il tuo team (gestione dei requisiti).
• Crea piani e monitora i progressi con uno strumento flessibile come Atlira Jira o qualcosa di simile che creerà un database di compiti tra il team (pianificazione e tracciamento integrati).
• Avere una strategia di garanzia della qualità che copre l'intera durata del progetto. Test Driven Development (TDD) può fornire molti di questi requisiti, ma dovresti anche leggere il V-Model.
• Il codice che scrivi dovrebbe seguire alcune regole, quindi dovresti creare o adottare standard di codifica appropriati per il tuo linguaggio di sviluppo. Avere queste regole aumenterà la qualità del codice e fornirà una guida per la revisione tra pari del codice.
• Utilizzare una sorta di revisione tra pari in cui i membri del team si guardano gli uni con gli altri per i difetti e raccomandano correzioni e miglioramenti. Questa è un'opportunità chiave per l'insegnamento e l'apprendimento, quindi non ignorarla come troppo costosa.
• Le risorse del codice e della documentazione del progetto devono essere controllate da fonti, numerate dalla versione e descritte dai log delle modifiche e dalle note di rilascio.

Questo è certamente un elenco parziale, e altri suggeriranno altre aggiunte molto utili. Tutti i membri del team devono essere istruiti a fondo per comprendere e utilizzare ciascuno di questi, ma si possono vedere dei benefici mentre si progredisce. Il supporto degli strumenti open source è disponibile per la maggior parte, quindi se la prima opzione in una categoria è troppo costosa, guardati intorno e chiedi in giro per alcune opzioni che ti stanno meglio.