Così ho iniziato a lavorare per un grande corp., Uno di quelli con 3 lettere nel nome, e stanno cercando di diventare Agile, ma hanno tonnellate di processi, che non credo siano Agili.
Quella che mi ha colpito di più sono le revisioni del codice. Il mio ultimo lavoro è stato con una startup che direi sia il team di sviluppo più agile che abbia mai visto, fatto parte e / o di cui non ho mai sentito parlare.
Comunque, la mia argomentazione è che le Recensioni di Codice sono una perdita di tempo nello sviluppo iterativo o Agile in cui la UX / UI è estrema / intensa (pensate alla perfezione di Apple / Steve Jobs). Forse qualcuno qui può aiutare a capire prima che mi licenzino?
Ecco il mio processo di sviluppo e quello al mio ultimo avvio ... molto Agile.
Facciamo il primo lavoro di funzionalità per ordinare le attività di sviluppo / todos. Vorremmo deridere un paio di versioni e presentarle agli utenti, al team e al marketing per ottenere feedback. Facciamo quindi un'altra ripetizione del modello per ottenere un round dagli stessi stakeholder sopra. Quindi dividiamo il lavoro e iniziamo. Abbiamo pietre miliari e appuntamenti da rispettare, ma continuiamo a collegarci. Non abbiamo recensioni di codice durante tutto questo. Diverse volte durante le settimane del nostro sviluppo teniamo di nuovo delle discussioni con le parti interessate per vedere se sono ancora d'accordo che caratteristiche / funzioni / UX / UI siano ancora in linea con l'obiettivo.
Mentre ci avviciniamo alla fine del ciclo di iterazione di 8 settimane, il QA inizia a testare, quindi va agli utenti alfa e infine agli utenti beta. Ma durante l'alfa e la beta gli sviluppatori stanno esaminando le nuove funzionalità e le funzionalità precedenti apportando modifiche iterative giornaliere o orarie all'interfaccia utente per migliorare la UX. Quindi una funzionalità che è stata sviluppata in questa versione, potrebbe finire per essere cambiata altre 3 volte nelle ultime quattro settimane per migliorarla e perfezionarla o aggiungere alcune piccole funzionalità (ad esempio rendere il componente un po 'più fluido o più intelligente). A volte le modifiche possono essere superficiali, il che significa che nessuna operazione CRUD viene cambiata o modificata, ma cambia solo tutta l'interfaccia utente.
Quindi, con questo tipo di processo di sviluppo, estremamente Agile, le recensioni dei codici non sarebbero una perdita di tempo? Significa che se avessi avuto un altro sviluppatore o due a rivedere il mio codice, ma poi quel codice cambia altre 3 volte prima che esca dalla porta, a causa di tutti i miglioramenti dell'interfaccia utente / UX, non stiamo sprecando il nostro tempo per le prime 3 volte che lo hanno esaminato codice come tale codice / componente / UI è stato eliminato?
Non abbiamo mai avuto molti problemi di qualità con questo processo e sì se uno sviluppatore ha lasciato tutte le conoscenze usciti dalla porta, ma abbiamo sempre trovato sviluppatori intelligenti che lo hanno raccolto e acquisito.
E sì, abbiamo molti tester perché potrebbero dover ripetere il test 3 o 4 volte. Inoltre, ti preghiamo di non rimanere impiccato nel chiedere perché tutte le UI / UX cambiano ... ecco come sono fatte le cose ... stato quindi ecco perché l'app vince tonnellate di premi per UI / UX e gli utenti uccideranno per il app. Il processo di pensiero è se riesco a fare anche un miglioramento del 2% in qualcosa perché ho un'ora in più, quindi lo faccio. Gli utenti saranno più felici, il che significa più $ o utenti. E sì, i nostri utenti sono d'accordo con l'app che cambia continuamente perché è così che è stato fatto dal primo giorno in modo da non vederlo come negativo o negativo.
Spero che questo post non venga fuori come pomposo, ma non riesco proprio a vedere come le Code Code non siano dispendiose. Forse il 2% di tutto il nostro codice nel codice esaminato presenta bug. Ogni versione potrebbe trovare 3 bug tramite revisione del codice. Quindi finisce per essere 40 ore di revisione del codice per sviluppatore per versione (4 x 40 = 160 ore) per trovare da 3 a 5 bug? Le probabilità sono del 50% che da 3 a 5 bug sarebbero stati rilevati dal QA comunque. Non sarebbe meglio passare quelle 40 ore per sviluppatore aggiungendo una nuova funzionalità o migliorando quelle esistenti?