Diserbo da vera agile da buzzword agile in un'intervista [chiuso]

Comincio sempre ponendo questa domanda:

What's the duration of your iterations?

Vota la loro risposta:

1 settimana è fantastica, 2 settimane sono fantastiche, 3 sono ok e 4 mediocri. Più di quello indica che stanno lottando e più di 8 settimane è solo strano. Se la risposta è dipende , sai che non hanno alcun indizio.

Follow-up con:

How often do you release?

Questo serve per verificare la prima domanda. La risposta corretta è ogni giorno o fine di ogni sprint . Un agilista saprebbe che non ci dovrebbero essere differenze tecniche tra un rilascio interno ed esterno.

Chiedi loro di difendere metodologie agili. E poi chiedi loro di smentire delineando le sue debolezze. Punti bonus se possono navigare in questo corso senza sporcarlo con parole chiave prive di significato.

Chiedi loro perché lo usano .

Lo saprai immediatamente.

Chiederei loro di descrivere il ciclo di vita dello sviluppo del software quando si utilizza la metodologia Agile. Se hanno familiarità con esso dovrebbero essere in grado di descrivere accuratamente ogni fase nell'SDLC.

EDIT : mi sono appena reso conto che stavi chiedendo dal punto di vista dell'intervistato, non dell'intervistatore. In tal caso, probabilmente chiederei loro il loro SDLC e vedere se i passaggi che dicono prendono corrispondenze con ciò che è realmente Agile.

L'approccio che ho in pratica ha poco a che fare con le parole d'ordine agili, ma ha a che fare con pratiche agili. Una delle caratteristiche comuni in tutti i team agili è la breve iterazione, la maggior parte delle persone ottiene quella parte (è uno dei 12 principi dietro agile su il link sito). Lo scopo della breve iterazione è di ottenere un feedback in anticipo sulla qualità del software sviluppato. Questo è dove comincio.

1. Chiedi dei test unitari. Stranamente la risposta che ho ricevuto è stata "uh, abbiamo tagliato fuori perché non avevamo abbastanza tempo" (nota: prime 2 bandiere di avviso - nessun tempo e nessun test di unità)
2. Chiedi quando il software è stato testato e con quale frequenza. Le risposte possono essere creative qui. Soprattutto se la squadra usa "Agile" come scusa per mettere da parte tutti i processi. Se la risposta è verso la fine del progetto, o qualcosa di diverso da ogni iterazione, non sanno cosa sia l'agile.

Finora, non ho dovuto andare oltre questo per sapere che la persona non sa cosa sia agile. Sono anche stato in una sola intervista con un'azienda che aveva già implementato processi agili ben consolidati.

C'è più di un modo di fare agile, e mi interessa più dei principi di agilità di qualsiasi marca o parola d'ordine in particolare.

Ci sono molte cose che separano coloro che stanno "facendo" agilmente da quelli che sono agili:

• Chiedere informazioni sull'integrazione continua se non stanno utilizzando la detrazione di un punto. Aggiungi un punto se lo sono. Punti extra:
  1. Aggiungi 1 se usano due commit di fase (il codice deve essere compilato correttamente prima che lo sviluppatore possa effettuare il check in).
  2. Aggiungi 1 se lo script di build include l'esecuzione di una suite di test
  3. Aggiungi 1 se la compilazione fallisce se la copertura del codice scende al di sotto di una certa soglia
  4. Aggiungi 2 se è possibile distribuire l'applicazione in modo che sia pronta per essere eseguita in un clic
• Chiedi informazioni su TDD (sviluppo basato su test) sottrai 2 punti se non usano TDD add 1 se lo fanno.
• Chiedi informazioni sulle iterazioni, per quanto tempo sono (sottrai 2 punti se non eseguono lo sviluppo iterativo, sottrai 1 se l'iterazione è più lunga di un mese o meno di due settimane, aggiungi 1 se è 2 settimane)
• Chiedi come viene eseguita la stima aggiungi 1 se usano punti storia, aggiungi 2 se pianificano il poker o qualcosa di simile, sottrai uno se usano stime assolute del tempo, sottrai 2 se gli sviluppatori non sono coinvolti nel processo di stima.
• Chiedi come vengono create le funzionalità aggiungi 1 se uno sviluppatore è responsabile della funzione dall'alto verso il basso (sezione verticale) sottrai 1 se gli sviluppatori sono responsabili di un livello specifico (sezione orizzontale)

Ci sono una serie di altri indicatori, ma quelli da soli dovrebbero darti una buona immagine se il team è effettivamente agile. Una squadra con 5 punti o più si qualifica. Qualsiasi altra cosa significa che stanno "facendo" agilmente. Agile non riguarda solo le iterazioni, ma consente di adattarsi al cambiamento con facilità. Se stai scrivendo iterativamente codice non testato e confuso, scritto sotto pressioni esterne, beh, stai solo scrivendo codice criptato in iterazioni. Si noti che è possibile ottenere molti punti solo dal bullet di integrazione continua. Ma questo da solo non è sufficiente per portarti oltre 5 se non stai seguendo le altre pratiche.

Come per tutte queste cose, chiedi esempi del mondo reale dai progetti su cui hanno lavorato , non la teoria. Accettare le risposte teoriche è il modo più semplice per farsi ingannare da qualcuno che non è mai stato lì.

Quindi chiedi di parlare con gli sviluppatori reali e di chiedere cose come:

• Quindi parlami del tuo progetto attuale. Qual è stato l'obiettivo finale iniziale? Cosa conteneva il primo sprint e cosa poteva fare il software alla fine di esso?
• Puoi darmi esempi di funzionalità o design sul tuo ultimo progetto che ritieni abbia funzionato in modo diverso rispetto a come l'avevi fatto in un progetto a cascata?
• Fammi un esempio di come una grande funzionalità è stata suddivisa su più sprint? Quali inefficienze / rilavorazioni hanno portato a questo? E quali miglioramenti o cambiamenti rispetto a quanto inizialmente previsto.
• Quando hai iniziato a lavorare con agile, quali cose stavi facendo durante i primi sprint hai cambiato durante gli sprint (o i progetti) successivi man mano che avevi familiarità con la metodologia?

Continua a riportarli ai progetti reali : cosa stavano cercando di ottenere, esempi di ciò che era in ogni sprint, esempi dei tipi di cose che emergevano nelle riunioni, esempi di interazioni con gli utenti.

Non accettare la teoria, non accettare i progetti di altre persone, solo le cose su cui loro stessi hanno lavorato e possono parlare di esperienze di prima mano.

Dovrebbero essere dei bugiardi incredibilmente bravi per poter fare 10-15 minuti di roba che ti passeranno accanto se conosci la tua roba.

Se non vuoi renderli sulla difensiva, ho trovato che la seguente domanda avvierà una conversazione che ti dirà tutto ciò che devi sapere sul fatto che effettivamente stanno usando un approccio Agile o semplicemente lo stanno pagando:

Who is responsible for writing requirements/specifications for your software projects?

Ho visto numerose aziende che si sono dichiarate agili e hanno persino desiderato che una certificazione Scrum Master descriva un classico processo di progettazione all'avanguardia quando chiedi del loro processo di raccolta dei requisiti.

La cosa che mi distingue è che stai cercando uno stage, il che mi porta a chiedermi quale sia il tuo scopo nel porre queste domande. Stai cercando di porre una domanda sull'agile per far andare bene l'intervista o rifiuteresti effettivamente un'offerta da una società che usa la parola d'ordine agile? Se sei veramente alla ricerca di un ambiente agile, scegli una domanda (perché usi agile, a che ora sono i tuoi standup, per quanto tempo sono iterazioni, qualunque cosa), e chiedilo al telefono o via email senza perdere tempo in un colloquio. Se stai cercando un reddito, attendi l'intervista e poni domande che mostrano le tue conoscenze / entusiasmo sulle metodologie agili (dimmi del tuo ciclo di sviluppo del software) senza imbarazzare l'intervistatore se stanno usando un abominio semi-agile.

Chiedo loro di descrivere una richiesta tipica, dall'inizio alla consegna finale al cliente.

Chiedo anche se in genere gestiscono il supporto a lungo termine per il prodotto che forniscono al cliente (perché le squadre che lo fanno generalmente costruiscono un prodotto migliore, sapendo che saranno loro a ripararlo all'1AM di domenica durante il Labor Day week-end).

Chiedo anche come la direzione vede il suo ruolo durante il processo. È abbastanza facile vedere se hanno un atteggiamento ignifugo (noi lanciamo, voli, chiediamo se colpisci il bersaglio) o l'atteggiamento "ti aiutiamo a remare su per la barca sul fiume".

Questi ti mostreranno in genere come fanno davvero le cose, non come dovrebbero fare loro o come si pretendono di farle.

Il modo migliore che ho trovato per vedere se qualcuno sa che cosa stanno facendo da una prospettiva SDLC è chiedergli dove si sono rovinati in passato, e come lo farebbero in modo diverso. Persone che hanno attraversato il processo un paio di volte e ammetteranno pienamente dove hanno fatto casino, e in generale sono abbastanza dettagliate. L'apertura a discuterne mostra un livello di fiducia, perché ammettono che non sono perfetti. Evitando la domanda dicendo "Praticamente fanno tutto bene sempre", è un vero segnale di avvertimento.

Quanto spesso vengono rilasciati in produzione. Più lungo è il tempo in cui sono meno agili. Quante volte hanno laboratori di riflessione. Se sanno di cosa stai parlando, allora bene. Quante volte hanno riunioni di "catchup" di squadra. Il quotidiano è grande, il mensile è cattivo. Hanno un server di integrazione continuo. Questo non è un must ma ti darà un'idea del loro utilizzo degli strumenti. Quanto spesso gli utenti finali siedono con gli sviluppatori. Non significa mai che non siano Agili.

• Dai una situazione e chiedi loro di risolverlo in modo agile;
• Chiedete loro delle loro pratiche agili preferite (pianificazione del poker, programmazione della coppia, bdd / tdd, kanban);
• Chiedi loro perché non hanno scelto o spostato dalle altre metodologie (cascata, rup, ecc.)
• Quali sono le persone più conosciute nel mondo della metodologia agile, che hanno coniato il termine e quali sono i libri più popolari scritti su di esso.

Se stanno usando Scrum, potresti chiedere se puoi guardare il prossimo stand-up. Se non li hanno, allora chiedi perché no, perché di solito fanno parte della metodologia.

Ci sono alcuni aspetti di Agile che potrebbero anche essere degni di nota. Chiedi di vedere lo storyboard, quanto è grande il back log, o quali sono stati alcuni dei momenti salienti dell'ultima retrospettiva, per alcune altre idee. La chiave qui è quella di arrivare a qualcosa di tangibile che mostri ciò che sta accadendo rispetto alle parole soffici che in realtà non significano molto.

Chiedi loro come gestiscono il design. Se ti dicono che non c'è design in agile, non lo capiscono.

Chiedi loro come gestiscono i mutevoli requisiti. Se sembra che cambiare i requisiti abbia il proprio processo, probabilmente non lo capiranno.

Se stanno sostenendo di usare Scrum, guarda per vedere come lo scrivono. I negozi che fanno bene Scrum tendono a sapere abbastanza bene come scriverlo. Suggerimento: non è SCRUM.

Può sembrare pedanteria, ma sono fermamente convinto che per applicare con successo un modello di processo come Scrum, RUP, XP o qualsiasi altra cosa, è necessario comprendere la filosofia e il "perché" in modo da sapere come adattare il "cosa" alla tua organizzazione. In Scrum, la maggior parte delle persone che stanno facendo i compiti a casa si imbatteranno in quel po 'di informazioni. La gente che cerca ricette di libri di cucina per la gestione dei progetti di solito mancherà a quei dettagli.

Per me è sensato chiedergli di descrivere come gestiscono parte del processo Agile. In questo momento il mio preferito è l'inizio di un'iterazione, ma potresti sviluppare il tuo preferito.

Chiedi: "data una pila di biglietti all'inizio dello sprint, descrivi il tuo flusso di lavoro da qui"

Punti chiave da ascoltare qui:

• Gli sviluppatori stimano i biglietti?
• Tieni traccia della velocità?
• Cosa succede quando le tue stime arrivano a qualcosa di più della tua velocità?
• Cosa succede quando le tue stime arrivano a qualcosa di più della tua velocità quando hai una scadenza? (attenzione per lo spin qui: riducono la complessità, o ridefiniscono la priorità, o solo il deathmarch del team di sviluppo?)

Nessuno di questi è da solo, ma se le loro risposte a una di queste domande ti fanno meraviglia, allora forse sono interessati a rituali agili, non a uno sviluppo .