Share
Sviluppo agile o agile: sentiamo queste parole più spesso in questi giorni. Ma sappiamo davvero di cosa si tratta? Come può aiutarci a diventare più efficaci, mentre ci divertiamo molto nello sviluppo di software? Come possiamo usarlo per comunicare con gli uomini d'affari e rendere questa comunicazione facile e costruttiva per entrambe le parti?
C'erano un gruppo di ragazzi molto talentuosi ed esperti che sviluppavano software serio. Questi sviluppatori hanno osservato altre società e team di sviluppo e in che modo i loro processi hanno facilitato il loro lavoro. Hanno compilato le loro osservazioni per creare il Manifesto Agile. E hanno detto:
Stiamo scoprendo i modi migliori per sviluppare software facendolo e aiutando gli altri a farlo. Attraverso questo lavoro siamo arrivati a valutare:
Cioè, mentre c'è valore negli articoli a destra, valutiamo di più gli articoli a sinistra.
In questo articolo, presenterò dodici teorie e tecniche di sviluppo agile. Questo è solo il primo passo verso il nuovo mondo del processo di sviluppo del software.
La nostra massima priorità è soddisfare il cliente attraverso la consegna anticipata e continua di software prezioso, ma non completo. Ciò significa che stiamo sviluppando software e aggiungendo almeno una funzionalità, per iterazione.
Immaginiamo che vogliamo creare un motore per blog; potremmo farlo utilizzando il seguente processo:
È un approccio semplice, ma il cliente vede il vero progresso del suo software e ti dà un feedback immediato su ogni nuova funzionalità. Può essere perfetto o richiedere modifiche, ma è possibile rispondere rapidamente ai cambiamenti: una situazione vantaggiosa per tutti.
Anche in ritardo nel ciclo di sviluppo, i processi Agile ti consentono di accogliere le modifiche per il vantaggio competitivo del cliente.
Il cliente desidera che il progetto sia terminato rapidamente e il più vicino possibile al disegno disegnato nella loro mente. Ciò è facilmente ottenibile semplicemente ascoltando il loro input ed essendo pronti per le modifiche. Se siamo in grado di reagire rapidamente alle mutevoli esigenze, siamo probabilmente la scelta migliore che il nostro cliente abbia mai fatto. Agile è tutto basato sulla comunicazione e sui cambiamenti. Facciamo le cose come ci viene chiesto di fare loro, rendendo il processo di sviluppo del software più veloce. Questo si ottiene perché sviluppiamo piccoli pezzi di software, e un cambiamento nei requisiti non influisce veramente su di noi.
Dovremmo consegnare aggiornamenti da un paio di settimane a un paio di mesi; più breve è il tempo, meglio è.
i clienti si sentono più fiduciosi in noi e il nostro prodotto non appena viene aggiornato
Dalle mie esperienze, i clienti si sentono più fiduciosi in noi e il nostro prodotto man mano che viene aggiornato, il che è vitale per il nostro rapporto con loro. Un altro vantaggio è il feedback del nostro cliente; permettendoci di reagire cambiando classi, caratteristiche, moduli o persino l'architettura. Non ci sveglieremo dopo giorni o mesi di lavoro, solo per vedere che tutto sta andando nella spazzatura. Consideriamo una situazione ipotetica:
Ti è stato chiesto di creare un modulo che visualizzi del testo semplice in un gestore di contenuti. All'improvviso, i requisiti cambiano e devi aggiungere un modulo che dovrebbe inviare una email a un indirizzo configurato. Inoltre, il modulo dovrebbe essere personalizzabile in modo che l'utente possa aggiungere nuovi campi e definire i validatori. Quindi, in pratica, devi dimenticare il requisito del testo semplice originale. Quanto tempo vorresti sapere su questo cambiamento?
Se lavori su un progetto con il tuo cliente e lo fai frequentemente, conoscerai queste modifiche più velocemente e modifiche come questa diventeranno più facili per entrambi.
Questo può rivelarsi il principio più difficile a cui ci si abitua, se hai sviluppato software nel vecchio stile a cascata. Tu, come sviluppatore, di solito non parli la stessa lingua del tuo cliente, ma puoi trovare i modi per mantenere una comunicazione significativa con loro. Uno dei modi migliori, a mio parere, è di descrivere tutto con una semplice storia che ci dice, lo sviluppatore, per chi è la caratteristica, quale è la sua responsabilità e perché ne abbiamo bisogno. Certo, questo diventa più facile più lavoriamo con il nostro cliente. Un altro approccio utile è Behavior Driven Development (BDD), ma questo è un argomento per un altro articolo.
Dai alle persone che lavori con l'ambiente e il supporto di cui hanno bisogno e, soprattutto, fidati di loro per portare a termine il lavoro.
È importante fornire un'atmosfera coinvolgente e tutti gli strumenti necessari per creare un buon software. Le aziende perdono i loro migliori lavoratori soprattutto perché non si preoccupano veramente di loro. La convinzione che gli sviluppatori possano scrivere, testare e distribuire software su alcuni server usando un client FTP e modificando i file di produzione live è andata persa da qualche parte. Se non hai condannato quelle vecchie abitudini scolastiche, faresti meglio a farlo ora.
Mantenere i dipendenti è solo un vantaggio; puoi anche sviluppare software migliori e più grandi a un ritmo più veloce. Pensaci: scrivere codice riutilizzabile, test automatici e distribuzione automatizzata su qualsiasi server (tra le altre cose) può influire positivamente sui tempi di sviluppo. Di solito pensiamo di rallentare un progetto perché dobbiamo imparare come usare strumenti utili, come Jenkins, GIT, SVN, Gerrit, Behat, ecc. Francamente, lo facciamo, ma possiamo quindi riutilizzare questi strumenti e concetti in progetti futuri.
È il metodo più efficiente ed efficace per trasmettere informazioni ai nostri clienti e al team di sviluppo.
Chi non è stato sopraffatto e / o arrabbiato vedendo 6,255,384 e-mail nella tua casella di posta, perché la tua azienda richiede che tutte le conversazioni siano "sulla carta"? L'ho visto personalmente alcune volte nella mia vita e non consiglio di lavorare in un'azienda con tali abitudini. Le conversazioni faccia a faccia rendono la comunicazione più semplice e agevole e ci consentono di fornire maggiori informazioni. Possiamo usare i modi di comunicazione verbali e non verbali per mostrare ai nostri compagni di squadra ciò che stiamo pensando. Ovviamente è più veloce che mandare email l'un l'altro.
Ma soprattutto, dobbiamo fidarci l'uno dell'altro; la fiducia è facilmente acquisita in un ambiente che incoraggia la comunicazione faccia a faccia.
Questa è una delle mie regole preferite; ci lascia lavorare liberamente secondo i nostri processi. Gli sviluppatori di software sono diversi dagli altri dipendenti; così naturalmente, dovrebbero essere trattati come tali. Dalla mia esperienza personale, ho imparato a non giudicare nessuno dal team di sviluppo finché il lavoro è finito. Gli sviluppatori non vogliono creare software scadente e sono meno propensi a farlo se permettiamo loro di lavorare secondo le proprie preferenze. Dopotutto, il cliente è felice finché il lavoro che ha commissionato viene eseguito correttamente; a loro non importa come è stato fatto.
I processi agili promuovono lo sviluppo sostenibile, consentendo di mantenere un ritmo costante a tempo indeterminato.
I vantaggi più noti di Agile (come l'accettazione di requisiti mutevoli, la reazione rapida al feedback, ecc.) Sono ampiamente apprezzati, ma il miglior vantaggio, a mio avviso, è la capacità di determinare con precisione la quantità di tempo che un progetto o funzione avrà consumare. Dopo alcune consegne, il team di sviluppo produrrà il numero di business più prezioso: la capacità. La capacità è la quantità di lavoro che il team può svolgere in un'unica iterazione. Il numero di capacità è stabile dopo alcune iterazioni e possiamo evitare le ridicole scadenze e le stime di tempo "tirate fuori da un cappello" mentre presentiamo l'offerta della nostra azienda al cliente.
Molte persone dicono che è impossibile e la pianificazione dimostra di essere più accurata. Non sono d'accordo; il programma presuppone che non ci saranno errori o ritardi inevitabili.
È un piano perfetto per una squadra perfetta, e questo non esiste.
La continua attenzione al nostro settore aumenta l'agilità.
Ci aspettiamo di evolvere e progredire. Dobbiamo continuare a imparare ogni giorno, perché l'industria si muove a un ritmo così veloce. Dato che sia l'hardware che il software migliorano, dobbiamo tenerci aggiornati; altrimenti, ci ritroveremo persi nel "mare del nuovo" e sarà difficile tornare in pista.
Il refactoring è la soluzione alla maggior parte dei problemi. Rifondando costantemente (quando necessario), possiamo facilmente applicare nuove tecniche e migliorare la nostra architettura software.
Bill Gates ha detto una volta:
Se ho qualche lavoro complicato da fare, lo darò alla persona più pigra che ho, perché troveranno il modo più semplice per farlo.
La semplicità è la regola d'oro. Questo non significa che devi essere pigro, ma significa che gli sviluppatori complicano il proprio lavoro la maggior parte delle volte. Se si esegue solo il lavoro che il cliente desidera, senza funzionalità e miglioramenti aggiuntivi, il carico di lavoro si alleggerirà e raggiungerete i vostri obiettivi. Alla fine, questo è tutto ciò di cui il cliente si preoccupa.
Le migliori architetture, requisiti e progetti emergono da team auto-organizzanti.
Siamo solo umani; non possiamo predire tutto.
Ti sei mai trovato in una situazione in cui hai sviluppato un'applicazione lunga e dispendiosa, e dopo aver passato innumerevoli ore davanti allo schermo a scrivere migliaia di righe di codice e leggere articoli, tutorial e libri, ti sei seduto a guardare qualcosa di brutto (ma lavoro) codice pensato, "Ora so come scriverlo meglio"? Penso che tutti abbiamo avuto questi momenti.
È qui che entra in gioco l'undicesima regola. Abbiamo un team di sviluppatori in grado di seguire i principi del Test Driven Development (TDD), in cui il refactoring è una parte del processo. In qualche modo magico, il nostro software è utile, bello, ben scritto, testato e creato rapidamente. Siamo solo umani; non possiamo predire tutto.
Tutto nasce dall'idea di un team auto-organizzante, in cui ogni membro ha un ruolo - non dato o forzato - ma che è emerso dopo un po 'di tempo di lavoro insieme. Questa è la bellezza del lavoro di squadra.
A intervalli regolari, il tuo team di sviluppo deve riflettere su come diventare più efficace e adattare il suo comportamento di conseguenza.
Questo potrebbe richiedere alcuni cicli di sviluppo, ma il team lavorerà in perfetta armonia. Anche l'aggiunta di nuove persone a questo team non sarebbe dannosa. Un team di sviluppo Agile punta a portare a termine il lavoro. Se lavorano in un ambiente amichevole, troveranno la "melodia del lavoro" e vedrai quanto può essere veloce lo sviluppo del software.
Esistono alcune metodologie derivate e basate su principi Agile. Non li descriverò tutti perché ogni metodologia può essere trattata nel suo stesso articolo. Tuttavia, illustrerò alcuni degli approcci Agile più noti. Una cosa da ricordare è che non esiste una metodologia per dominarli tutti. Scegli quello più adatto alle tue esigenze e persino "configuralo" per soddisfare le tue esigenze specifiche.
Creato da Ken Schwaber e Jeff Sutherland, SCRUM è un framework business-oriented per la gestione dei processi di sviluppo del software. Esistono molti tipi diversi di SCRUM; ricorda che l'obiettivo principale è lavorare in modo efficace, efficiente e non attenersi alle regole.
Creato da Kent Back, XP è un elenco di best practice che gli sviluppatori dovrebbero seguire durante la creazione del software. Viene spesso chiamato "l'estensione di SCRUM". Questa metodologia di regole orientate allo sviluppo è nata, perché SCRUM è piuttosto orientato al business.
Due dei principi principali di Lean sono: DALAP (Decide As Late As Possible) e DAFAP (Deliver As Fast As possible). Personalmente raccomando di leggere di più su questa metodologia, in quanto può essere molto utile.
Ci sono più metodologie nella famiglia Agile; Ho semplicemente fatto riferimento alle opzioni più popolari. Se decidi di utilizzare Agile nel tuo processo di sviluppo, devi sapere quali sono queste metodologie, al fine di scegliere quella giusta per te.
Le tecniche Agile funzionano davvero?
Le tecniche Agile funzionano davvero e le metodologie sono davvero magiche come dicono tutti? Non sempre.
Il problema che ho incontrato nelle aziende, in cui i metodi Agile non fornivano risultati (o addirittura peggioravano le cose), era una metodologia male scelta e la mancanza di convinzione tra i suoi utenti (membri aziendali, il team di sviluppo, ecc.). Ecco perché, a parere di chi scrive, è necessario essere sicuri che tutti gli attori coinvolti nel processo comprendano le regole e sanno "di cosa si tratta".
Grazie per aver letto!
Accentsconagua