Ora che ogni azienda è una società di software, le recenti discussioni con le persone intorno a me (comprese quelle non nel settore del software) mi hanno fatto riscoprire lo stato abissale in cui si trova la consegna del software, in molti luoghi.

Questo articolo condividerà alcune delle mie riflessioni su questo, oltre a permettermi di presentare alcuni consigli di alto livello non conclusivi che credo possano costituire una solida base attorno alla quale tali organizzazioni problematiche potrebbero essere ricablate in vere e proprie organizzazioni di software.

Si noti che quando scrivo di organizzazioni e aziende, non saranno quindi società tecnologiche puramente di gioco, ad esempio Meta, Google, Spotify o simili, piuttosto la lunga coda di organizzazioni (ovvero società legacy potenziate dall'IT) che sfortunatamente hanno dovuto adattarsi al software che fa parte del loro output e prodotto.

Da dove sto scrivendo questo

Prima un po' di contesto. Ho esperienza e apprendimenti da diversi "mondi", sia attualmente come Technical Standards Lead presso Polestar , essendo un produttore open source , essendo un avido lettore di tecnologia in generale, ed essendo il fondatore di una piccola startup tecnologica nuova di zecca . Infine, insieme a un mio vecchio collega, sto anche pianificando attivamente di istituire un servizio CTO frazionario locale gratuito per giovani organizzazioni orientate al valore.

Ho iniziato a codificare HTML e CSS nel 1997, da allora ho esplorato parecchie aree e, pur facendo molti tour e deviazioni nella vita, la mia rigorosa carriera professionale è iniziata nel 2016. Già la prima posizione era complessa e disordinata e io' Mi è piaciuto avere posizioni in cui devo bilanciare i lati duri e morbidi, su e giù dal livello C ad altri sviluppatori. Ho gestito due piccole imprese nel design e nella tecnologia, forse non con grande successo, ma ho esperienza con tutto ciò che comporta. La mia esperienza con i clienti va dalle super piccole alle più grandi aziende svedesi, dai beni di consumo di tutti i giorni ai servizi più di nicchia. Sono stato fortunato e molto felice di aiutare a innovare e creare una piattaforma su come la consegna del software può o almeno dovrebbe funzionare in molte organizzazioni, con varie esigenze e profondità di competenza nella tecnologia in molti domini. In chiusura, ci sono un sacco di frasi che iniziano con “I…”.

OK, quindi perché scrivo quanto sopra? Singolarmente perché voglio essere completamente trasparente in quanto ciò che attaccherò deriva dall'aver sperimentato il dolore e spesso "innaturalità" del software in molte organizzazioni - semplicemente non sembra gelare nella maggior parte dei posti! C'è una tonnellata metrica di letture - abbastanza bene da occupare la tua vita e oltre - se vuoi scavare in idee, concetti e filosofie del software, anche prima di arrivare al lato commerciale, come gestire le startup, come creare MVP , come avvicinarsi al software di qualità e così via. Per essere onesti, nessuno di noi ha il tempo di assorbire tutto e non sarebbe un'ottima gestione del tempo se non sfoltiamo in una certa misura le nostre fonti di ispirazione e l'assunzione di nuove idee.

Quindi, con questa narrazione fuori mano, scriverò di tre cose in particolare:

• Che abbiamo un problema con il software in organizzazioni non software.
• Perché gli stessi sviluppatori non possono trasformare la tua organizzazione in un'azienda di software.
• Come potrebbero apparire alcuni cambiamenti reali nella vita reale per far ricrescere le fondamenta.

Ingegneria del software, da una prospettiva orbitale

Siamo un'astronave aliena che si libra sopra la Terra, guardando dall'alto in basso tutte quelle aspiranti organizzazioni (cioè IT).

Alcuni fatti che i nostri strumenti hanno raccolto insieme alle riflessioni del nostro capo Scienziato Umano-Alieno:

• La tecnologia (in particolare la Big Tech) ha sovraccaricato . Lo scopo sembra essere, un po' cinicamente, non quello di far lavorare le persone, ma di rimuoverle dalla produzione produttiva di qualcun altro.
• Ciò porta alla naturale conseguenza di rendere più che possibile avere più lavori contemporaneamente . Ironico ma vero, visto che ora hai due stipendi per non fare il doppio di niente.
• A livello aziendale, come scrive Victor Ronin, " puoi licenziare l'80% degli ingegneri del software e l'azienda sopravviverà ". Non così strano dato che nessuno lavora in primo luogo, o che la tipica organizzazione IT tende a essere un pantano anche se ci provassero.
• L'esperienza lavorativa personale dice chiaramente che "l'inflazione del titolo" è grave (almeno in Svezia, ma sembra essere un fenomeno globale ) - non posso provarlo, ma se hai partecipato (o aiutato) al reclutamento o all'assunzione molto probabilmente lo avrai visto. In effetti, le persone vogliono più soldi per manodopera a volte meno qualificata .
• A livello nazionale, in Svezia, il grado di candidati qualificati nei programmi orientati all'IT/CS è in calo da tempo. Tuttavia, sembra che alcuni dei programmi di istruzione professionale non teorica raccolgano alcuni candidati. Ergo, il mercato non sembra aumentare nel tempo, ma in calo , almeno per quanto riguarda i giovani più qualificati.
• Possiamo generalizzare e dire "prima era più facile", poiché l'IT era un centro di costo ed essenzialmente in molte aziende relegato a vendere licenze per software commerciale (creato da qualcun altro) e garantire che la stampante e la posta elettronica funzionassero. Ora, un po', sfortunatamente, ogni azienda è una società di software . Questo non ha funzionato molto bene in realtà, poiché richiede ristrutturazione e ripensamento, molto probabilmente il dado più difficile da decifrare per le persone normali.
• L'IT è deprimentemente sovragestito e sottoqualificato. Molto probabilmente c'è una lunga storia (o molte di esse) alla base di questa affermazione, ma è abbastanza chiaro che l'IT sta attirando molti talenti e idee non qualificati, spesso (ma non solo) nelle parti di (cattiva) gestione. I ruoli di manager sembrano esplodere dalle viti del grande albero gerarchico, mentre in primo luogo c'è meno (buono) output da gestire effettivamente. Abbiamo bisogno di qualcosa che metta al primo posto il prodotto (e ovviamente le persone!), non la gestione o le idee archiviate sugli scaffali di "scalare" la gestione del prodotto che semplicemente non funziona .
• Il pensiero del prodotto, il pensiero laterale e le persone a forma di T sono difficili da trovare. Dovremmo assicurarci di disporre di meccanismi che rendano le nostre persone più forti di tali capacità, nell'immersione quotidiana così come con una formazione regolare e prevista . Ma non dovremmo accogliere coloro che mancano di tutti quelli in primo luogo.
• Il processo non è il nemico, contrariamente a quanto gli agili fanatici vorrebbero farti credere. Il processo è ottimo se mantiene significativamente i dipendenti efficienti e felici mantenendo l'output a un livello competitivo, sia in termini funzionali che interfunzionali. Il problema è che le organizzazioni tradizionali non stanno adattando i processi alla cadenza molto più elevata della consegna del software.
• Cosa sembra occupare tempo per gli ingegneri del software in molti luoghi? Sembra riguardare problemi di integrazione relativamente modesti, automazione dei processi e manutenzione del sistema. Quasi come un idraulico digitale ... interessante...

— Utente "denton-scratch"https://news.ycombinator.com/item?id=33961785

• Che fortuna per quelle povere anime manager che ci sia una sorta di risposta a quello scenario dell'idraulico digitale: No-code/low-code è un approccio che è preveggente in quanto riconosce che non ci sono abbastanza ingegneri del software competenti disponibili, sia in formazione o sul mercato. Ci sono alcuni fantastici prodotti come Zapier , Autocode , AppSheet , AirTable , Webflow , Retool e Carrd . Al diavolo, level.fyi è stato ridimensionato a milioni di utenti con solo Fogli Google come back-end ...
• …ma non è ancora maturo per tutte le aree di business e richiede ancora un po' di mentalità ingegneristica per lavorare bene . Quindi sembra che abbiamo ancora bisogno che quegli ingegneri/sviluppatori utilizzino lo strumento "nessun codice", quando la direzione e il resto sono inorriditi dal fatto che abbia ancora a che fare con il software.

La velocità dell'innovazione nel settore del software e dello sviluppo è incredibile in questo momento. Sto scrivendo questa dichiarazione in parte come scusa e in parte come lettera d'amore per affrontare quanto la tecnologia possa essere facile e "democratizzata" per le aziende e le organizzazioni, indipendentemente dalla loro maturità tecnica o competenza. Mi scuso perché nella mia realtà, in realtà è molto difficile portare le grandi aziende a raccogliere i frutti del nostro tempo , e lettera d'amore poiché conosco e apprezzo l'impatto che gli sviluppatori e gli uomini d'affari possono avere, se dato il contesto dell'organizzazione "giusta".

Per una nuova start-up, questo non è mai stato così vero come lo è oggi data la pletora di strumenti ben funzionanti e ben UX in grado di creare esperienze e applicazioni che, non molto tempo fa, erano solo di competenza dei maestri dell'arcano.

Sembra che non sia ancora sufficientemente approfondito in molte organizzazioni da dover definire (e stratificare di conseguenza) se sono un'organizzazione con miglioramenti IT o se sono un'azienda di software con la sua mentalità di prodotto a ciclo rapido di costruzione software front-and-center delle operazioni. Il culto del carico attorno al softwaree il modo in cui tutti pensano che sia fondamentale esserlo significa che abbiamo invitato lupi e ciarlatani in org con grandi visioni. Grandi visioni con leader inesperti e nervosi, in organizzazioni che non possono sempre soddisfare gli alti castelli nel cielo, dati i limiti e i vincoli intrinseci o radicati che potrebbero rendere fondamentalmente impossibile ristrutturare attorno al software, piuttosto che, ad esempio, automobili, spedizioni, cuscinetti a sfera , prodotti medici o altro...

La nostra fame di adeguarci ai tempi ha chiaramente portato, in molti casi, a prendere decisioni sbagliate ea condizioni di cattivo funzionamento che non riescono a fornire software di alta qualità, stabile e sicuro... Va bene essere un'azienda che non si occupa di software ! Essere un poser è molto peggio.

Promemoria : la sopravvivenza non è obbligatoria . Qualcuno dovrà sempre recitare il ruolo del dodo .

Un separatore chiave tra le organizzazioni tradizionali e le organizzazioni software è che il software è il prodotto . Ah. Detto questo, si presume che siamo anche giunti ad alcune intese:

• Software come estremamente malleabile (modificabile, adattabile);
• Il tasso di cambiamento nel software è significativamente più alto che nel mondo materiale;
• La concorrenza nel software è globale per impostazione predefinita e ultra-antagonista per natura;
• Il software viene continuamente migliorato, non è un artefatto consegnabile con una data stampata sopra.

Il problema è - inevitabilmente - da qualche parte, prima o poi, la tua fortuna finirà se non riesci a migliorare questa situazione. La tua concorrenza principale non proviene dai tuoi concorrenti legacy ben noti e mappati: proviene da un ragazzo o una ragazza che scrive il tuo necrologio in codice nel loro subaffitto in un paese completamente diverso. E non lo vedrai arrivare prima che sia troppo tardi.

Un'organizzazione incentrata sul software soddisfa, si adatta e ottimizza tali fatti, essendo interfunzionale, avendo cicli brevi nel ciclo di sviluppo del prodotto, comprendendo il resto del panorama digitale (dalla legislazione ai modelli degli utenti, ecc. ) e avere l'utente come parte interessata, non un sacco di denaro astratto e senza cervello nascosto alla vista. Una società di software non è protetta dalla realtà, dal mercato o da qualsiasi altra cosa, ma si adatta avvicinando i propri clienti, una forma di Oracle of Delphi alquanto inaffidabile.

Gli sviluppatori non salveranno una cattiva organizzazione

Sono noto per essere controverso, quindi vado avanti e lascio subito fuori quel pensiero satanico, così possiamo disimballarlo insieme... Probabilmente non dovresti avere altri (più) sviluppatori, perché :

1. Non è possibile esternalizzare il business e "conoscere il piano" agli ingegneri . Non perché siano stupidi, ma perché è un altro strumento nella grande orchestra. Dato che la tua attività non è profondamente radicata nello sviluppo, non è lì che troverai coloro che guidano gli affari. Inizia impostando il piano e la visione per la tua organizzazione e il (possibile) prodotto. Invita gli sviluppatori, però!
2. Il mistero e la magia intorno agli sviluppatori devono solo morire . Gli sviluppatori non sono supereroi, né sono tutti del mitico tipo 10x . Il valore ultimo nella creazione di qualsiasi cosa, nel contesto del business, è che supporta il valore percepito dal cliente. Gli sviluppatori non sono le persone ideali per comprendere appieno quale sia quel valore. Lo sviluppo è spesso guidato in modo reattivo e dopo il fatto , il che si traduce direttamente nel fatto che il codice è solo una misura della produzione piuttosto che una misura del valore . Se questo è ciò che stai facendo, allora no, più sviluppatori non è il modo giusto per fare affari.
3. Probabilmente stai facendo affidamento sulla convinzione che trasformare quel software in qualcosa di tangibile (inclusi tutti i processi non digitali ecc.) funzionerà bene nella tua gerarchia legacy . L'esperienza dice che non è quasi mai così e che LinkedIn è pieno di sciacalli che non dicono la verità. Oppure, quando leggi che una vittoria è stata "conquistata a fatica" (ad esempio la vittoria di Pirro ), chiediti se vuoi scoprire cosa significava veramente in realtà. Molte volte probabilmente si traduce in un progetto completamente ridotto a pezzi da marketing, design, sviluppo, affari e gestione che avevano idee completamente contrastanti su come procedere e su cosa si trattava. Inoltre, una grande organizzazione impiegherà il suo tempo per portare i pacchetti di lavoro dall'idea alla realtà, quindi questo accadrà solo una volta ogni tanto. E il resto del mondo forse sarà già andato avanti quando la luce del giorno brillerà su quel progetto a forma di fardello. A meno che il software non sia progettato e costruito come una fetta verticale che include tutte le persone ei processi richiesti, allora è quasi destinato a fallire oa funzionare male visti i costi e gli sforzi necessari.

So che può far male, ma in realtà sto cercando di essere tuo amico qui.

Grande organizzazione? Probabilmente grossi problemi. Se le persone sono il problema, qual è la soluzione? Logicamente la risposta è Meno di loro e meglio qualificati . Di conseguenza, l'organico è un modo davvero scadente di procedere e la scala probabilmente non è così importante come pensi. Invece, mira a un numero inferiore di sviluppatori altamente qualificati e motivati ​​impegnati in un'organizzazione che valorizza la trasparenza e le interazioni interfunzionali.

Crescita esplosiva di ciò che uno sviluppatore competente può fare con le offerte tecnologiche contemporanee

I miglioramenti tecnologici significano che gli individui competenti possono produrre molto di più rispetto agli sviluppatori privi di competenze all'avanguardia . Dai servizi individuali al cloud pubblico, ci sono innumerevoli storie di aziende che si basano sul lavoro di soli 1-5 sviluppatori, grazie al paradigma serverless e ai suoi predecessori.

Per le aziende più tecnologiche, sto vedendo (e ho visto) come uno o un piccolo numero di sviluppatori può creare cose impossibili da fare senza assumere il meglio che il mercato ha da offrire e pagare con i tuoi organi. Gran parte di ciò deriva dalla corsa agli armamenti tra le grandi nuvole, ma anche da quando altre aziende tecnologiche, spesso specializzate nel proprio campo, stanno versando benzina sul fuoco. In quanto "consumatori" dei servizi, siamo nettamente vincitori. Non sfruttare lo slancio lascerà la tua organizzazione molto indietro molto rapidamente.

Quando dovresti semplicemente non assumere affatto sviluppatori?

Se sei una piccola impresa o in un contesto poco influenzato dal digitale. Sto pensando a ristoranti e simili. Se i margini sono troppo bassi e hai un'idea abbastanza decente delle tue esigenze aziendali, allora potresti essere servito meglio da qualcosa come Carrd, Webflow, Retool o qualcos'altro low-code/no-code-oriented e nessuno può biasimarti per dato che hai un po' di abilità nel pensare in termini programmatici. Non saresti il ​​primo o l'unico a guidare con successo il business con questi strumenti disponibili in commercio e di facile utilizzo.

Migliore consegna del software ora

Abbiamo visto che il vero problema nelle organizzazioni IT riguarda meno la tecnologia e molto di più le persone ei processi. Pertanto, mentre alcuni dei seguenti riguarderanno la tecnologia , molti non lo sono.

Non per essere duro, ma questo è anche un motivo sufficiente per chiedersi: "Se non posso fare a meno di influenzare o modificare questi aspetti, quali sono le probabilità realistiche che la mia azienda sia brava a fornire software?". Scommetterei basso. Scusa, non scusa.

Andiamo al punto.

Attenzione al cliente/utente

Questo è senza dubbio il numero 1 nella tua lista.

Non ho mai lavorato in un'azienda (no, mai; non oggi, non prima) in cui l'azienda ha veramente a cuore il cliente o l'utente. Non essere così.

Senza la prospettiva del cliente, alla fine, ti sei fottuto tutto. È la verità.

È una regressione oltre la stupidità non fare in modo che la tua organizzazione di prodotto abbia un contatto diretto con gli utenti (come e quando appropriato). Assicurati che abbia tali capacità!

Etica

Leggi quanto segue, indipendentemente dalla tua posizione:

• Accelerate di Forsgren, Humble e Kim : la scienza del software snello e DevOps: creazione e scalabilità di organizzazioni tecnologiche ad alte prestazioni
• L'artigianato pulito di Robert C. Martin : discipline, standard ed etica
• La moderna ingegneria del software di Dave Farley : fare ciò che funziona per creare software migliore più velocemente

Sentiamo molto parlare di empowerment, come responsabilizzare i team con le responsabilità verticali in un ruolo DevOps, ma con la libertà arriva la responsabilità, anche dal resto dell'organizzazione verso i team di ingegneri. DevOps non funzionerà in una feature factory . In una nota correlata, leggi Product vs. Feature Team .

Il tuo obiettivo numero 2 dovrebbe aumentare l'efficienza organizzativa con cicli più brevi dall'idea all'implementazione. Ciò è ostacolato da grandi gruppi o strutture, procedure rigide che non aggiungono valore e non si affidano a gruppi più piccoli per svolgere il proprio lavoro in modo autonomo. Più breve e intenso è questo ciclo, meglio è.

Avere una visione chiara e comunicata per il tuo prodotto, servizio o qualunque cosa stia facendo la tua organizzazione . Metti in chiaro cosa possono fare tutti per arrivarci. "Vendite più alte" non conta come visione o guida di un adulto, ma è certamente buono nel contesto di un cartone animato di Paperoni.

Trasparenza negli obiettivi e vera proprietà e processo decisionale: senza visione, direzione e proprietà puoi avere tutti i DevOps a cui potresti mai agitare, ma sarà letteralmente inutile . Avere un interesse e una responsabilità significativi e concreti nel prodotto aumenta la soddisfazione sul lavoro, il senso dello scopo e molti altri fattori . Nel mondo dello sviluppo, questo sarebbe qualcosa di simile a DevOps ben oliato che funziona anche meglio in team più piccoli con ambiti più ristretti e più chiari .

Non creare, supportare, investire o finanziare un livello di gestione . Tutti devono avere una partecipazione nel prodotto. La direzione in genere non taglia tale requisito.

Avere un'idea chiara di come funzionano la responsabilità e la responsabilità . Sebbene in molti paesi sia comune essere duri con i lavoratori, in paesi come la Svezia è in realtà il contrario: può essere incredibilmente difficile esercitare una chiara pressione quando le aspettative non vengono soddisfatte. Non prendermi come dominatrice o sorvegliante qui, ma se capovolgi la sceneggiatura e ti lasci ispirare da uno qualsiasi dei numerosi libri di psicologia disponibili o dalle scoperte, ad esempio, di DORA , vedrai che investimenti elevati e custodia sono conseguenze naturali di un team ben funzionante che svolge solo il proprio lavoro quotidiano. Quindi paradossalmente — essendo trasparenti, chiari e lavorando insieme (piuttosto che solo come individui, cioè l'uno contro l'altro) — creerai le condizioni per team ad alte prestazionidove la responsabilità tende ad arrivare automaticamente.

Sii impegnato e investito nel lavoro. Consenti il ​​lavoro a distanza . Le persone non imbrogliano se sono ben selezionate, dedicate e orgogliose del proprio lavoro.

Primo: fiducia, aspettative e obiettivi elevati... poi arriva l'empowerment.

Assumere le persone giuste

Ottieni alcuni, ma molto entusiasti, sviluppatori con esperienza nella realizzazione dei propri progetti (o di altre società) nel cloud . Dai a questi nuovi ingegneri un'attività iniziale per migrare o sostituire la piattaforma di alcune applicazioni legacy che potresti avere. Non dovrebbe volerci troppo tempo prima che tu possa iniziare a utilizzare quelle clausole di uscita per qualsiasi membro del personale che non sia all'altezza.

Non assumere persone su LinkedIn con mandati poco chiari o titoli di scuola materna come "Relatore principale" o "Visionario".

Non assumere sviluppatori "di massa"/"di volume", indipendentemente dalle dimensioni della tua azienda.

Non assumere nessuno davanti a un caffè. Lascia che siano controllati a tutti i livelli : competenza tecnica, pensiero sul prodotto, capacità laterali di risoluzione dei problemi, intelligenza emotiva, lavoro dimostrato in precedenza e chiarezza dei propri obiettivi. Cosa guadagnate entrambi lavorando insieme? (non "per te"!) Lascia che incontrino le squadre e lavorino insieme per un'ora o due prima di premere il grilletto e impegnarsi.

Non gestire una scuola. Investi in persone con solide capacità di base o subiscine le conseguenze . Il ritardo concettuale è probabilmente uno dei motivi principali per cui i team e le organizzazioni non diventano mai "fantastici". Ad esempio, insegnare l'integrazione continua in un'organizzazione nel 2023 non la sta preparando per il successo: dovremmo aspettarci tale conoscenza come competenza di base di base. Lo stesso vale per le organizzazioni di innovazione, dove vale lo stesso, ma la novità dei concetti è radicalmente superiore. In breve, costruisci un'organizzazione da persone che sono già ben radicate nella base fondamentale delle tue operazioni, altrimenti è sicuramente condannata.

Mantienilo agile e snello

Vedi se questo risuona prima con te:

Ad ogni modo… Probabilmente non conosci davvero Agile , ma potresti avere molte opinioni al riguardo. Tutti sembrano avere! Per un certo riallineamento, consiglierei Clean Agile: Back to Basics di Robert C. Martin o almeno il video qui sotto con lui che presenta la storia dell'agile e lascia che questo affondi per primo.

Pianificazione? Vai avanti e usa qualcosa come i progetti GitHub ; tutto ciò che è vicino al codice. Evita che Jira e la gestione per il bene della gestione avvengano al di fuori dell'effettivo creatore di denaro: il codice.

Ridimensionamento? Agile non ha lo scopo di ridimensionare : è necessario ridimensionare il problema e renderlo più tangibile. Agile non è la risposta a tutto, ma se vai a un po' della letteratura di base e butti via qualsiasi roba SAFe che hai nello scaffale, almeno avrai un vero inizio. Inoltre, controlla la presentazione di Gojko Adzic su Descaling Agile . Decalcifica la tua organizzazione se necessario.

Non comprare in un quadro . Inizia letteralmente dal nulla: niente riunioni, niente cerimonie, niente di niente. Quindi aggiungere qualche spruzzata se necessario. Evita le cerimonie che non aggiungono nulla, ad esempio, forse tieni una breve conversazione mattutina di 10 minuti per mettere in ordine la giornata (o alla fine della giornata!). Elimina i consulenti SAFe se sei sfortunato ad averli in giro. Inoltre, guarda i modelli operativi che hanno più senso in un ambiente in rapido movimento, come Team Topologies .

Avere riunioni che "non sono riunioni" . Le riunioni devono essere orientate ai risultati e pertanto devono eseguire solo una delle seguenti operazioni, ma nient'altro:

• Decidere o pianificare : dobbiamo svolgere anche alcune meta attività. Finché sono utilizzabili e tutti hanno un contesto, vale la pena averli. Ma fai attenzione alle riunioni di pianificazione mal pianificate! :)
• Lavoro : Sì! Lavoro. La creazione di un blocco di lavoro ininterrotto coppia/mob per alcune ore è un ottimo modo per utilizzare un "meeting che non è un meeting".
• Imparare o condividere : Apprendimento tra pari, gruppi di competenze, retrospettiva...
• Socializza : spara al vento, incontra nuovi colleghi, aiuta le persone a trovare la loro strada...

Non ti fidi di me? Guarda la presentazione di Dave Farley su Agile e Kanban.

Sebbene esistano diversi modelli con variazioni rispetto a quanto sopra, alcuni fattori decisivi dovrebbero eliminare tutta la pula inutile.

Consegna continua

"La consegna continua migliora sia le prestazioni che la qualità della consegna e aiuta anche a migliorare la cultura e ridurre il burnout e il problema della distribuzione".

– Accelerare: la scienza del software snello e DevOps: creazione e scalabilità di organizzazioni tecnologiche ad alte prestazioni

Fornire continuamente software. Il modello “ minimo vitale ” per questo richiede:

• Sviluppo basato sul tronco
• Il lavoro si integra al tronco almeno giornalmente
• Il lavoro ha test automatizzati prima dell'unione al tronco
• Il lavoro viene testato automaticamente con altri lavori durante l'unione
• Tutte le funzioni si interrompono quando la build diventa rossa
• Il nuovo lavoro non interrompe il lavoro consegnato

E sì, usa lo sviluppo basato sul tronco : è la strategia di ramificazione più semplice di tutte, è direttamente legata alla consegna continua ed evita l'opinione insignificante sulla ramificazione. Se pensi di aver bisogno di ramificazioni complesse, il problema non è la tecnologia, è il modo in cui poni la situazione. Unisci l'inferno non è un vero problema durante l'integrazione continua.

Non eseguire richieste pull a meno che non siano logicamente significative : esegui invece l'accoppiamento o il mobbing, quando possibile. Le revisioni asincrone interrompono il flusso e si basano sulla sfiducia. Assicurati che le persone lavorino insieme e costruiscano le cose giuste.

Usa una piattaforma CI/CD valida e versatile come GitHub, GitLab, Harness o Azure DevOps. Non eseguire la tua configurazione Jenkins o reinventare questa particolare ruota. Non riesco davvero a pensare a niente di più inutile per passare il tuo tempo a costruire.

Sii iterativo. Costruisci qualcosa che fornisci in qualche modo o forma oggi. Si spera molte volte oggi, molte volte domani.

Usa un unico ambiente di produzione e solo ambienti di test effimeri e di breve durata (se mai ne avrai bisogno!). Non rendere le cose troppo complicate come le hai imparate nella tua precedente carriera.

Utilizza la tecnologia serverless come impostazione predefinita e utilizza anche le opzioni SaaS come impostazione predefinita: non investire eccessivamente in ciò che è già disponibile prontamente ed economicamente. È più sicuro, più economico e più facile se hai persone che conoscono il cloud. Troppi non lo fanno e si lamenteranno che il serverless è un male. Non fidarti di loro. Invece, trova persone che conoscono il cloud.

Usa le funzionalità di commutazione una volta che inizi a dover separare i set di funzionalità, ad esempio per funzionalità non completate, gruppi di utenti, beta tester ... Come scrive Charity Majors, " Le distribuzioni sono il modo sbagliato per cambiare l'esperienza utente ".

Qualità

La mia tesi è questa, se un approccio ingegneristico allo sviluppo del software non ci aiuta a creare software migliore più velocemente, allora è sbagliato e non si qualifica come "Ingegneria".

— Blog di Dave Farley, Cos'è l'ingegneria del software moderna?

Scrivi test, tutti quanti , concentrandoti su test unitari e test di integrazione. Va bene non avere una copertura del 100% il primo giorno, ma non lasciare che il debito si insinui per troppi giorni.

Non assumere ingegneri QA, tester o simili. Aspettatevi che i vostri ingegneri siano in grado di quantificare la loro qualità con i test e assicuratevi che abbiano il tempo per farlo.

Impara a utilizzare il cloud pubblico. Non assumere nessuno che non abbia esperienza nel cloud.

Imposta attività per ogni minimo debito tecnico.

Non dimenticare i requisiti legali, di sicurezza e altri requisiti interfunzionali. Dovrebbero aiutare a informare il tuo SDLC oi criteri interni minimi per la definizione di fatto.

In chiusura

Il mio tentativo qui, inutile o no, è stato quello di essere il più franco possibile sui problemi che tu, in quanto organizzazione tradizionale che fa leva sull'IT, hai quando cerchi di diventare un'azienda più incentrata sul software. In nessun modo viene detta o scritta l'ultima parola, ma spero che tu abbia un'idea di dove consiglierei di apportare alcune modifiche, che aspetto hanno e quali sono alcune delle differenze culturali tra un'organizzazione IT e un vero software Attività commerciale.