Il tuo team funziona bene senza seguire una metodologia di lavoro (come la mischia)?

Ho lavorato in diverse piccole squadre negli ultimi 9 anni. Ognuno aveva le buone pratiche ovvie, come riunioni brevi, controllo delle revisioni, software di integrazione continua, rilevamento dei problemi e così via.

In questi 9 anni non ho mai sentito parlare molto delle metodologie di sviluppo; per esempio, non c'è mai stato un "stiamo facendo mischia" o "lasciamo agile", o qualcosa di più di un riferimento di passaggio. Sembrava che tutte le squadre funzionassero bene, senza seguire molti processi, eravamo solo in freeflow e naturalmente funzionava bene.

Qualcun altro ha progredito per lunghi periodi di tempo senza incontrare mischia / agile / ecc?

L'unica esposizione che ho avuto a questi è attraverso siti come questo. Ho letto domande come Sprint Meetings - Di cosa parlare ... e tutti i discorsi sembrano descrivere quasi robotici come persone che seguono una metodologia a stati finiti. È davvero (anche se esagerato) così? Mi chiedo se le persone che pubblicano su Internet solo sostenitori forti delle "migliori pratiche", con viste simili sui libri di testo, non riflettano realmente il modo in cui le persone lavorano ... O che ho incontrato alcuni team che hanno elaborato i loro processi in modo naturale.

Inoltre (sono nel Regno Unito, il che potrebbe essere rilevante) ... Penso che se una metodologia venisse introdotta in una delle squadre su cui lavorerei, la respingerebbero semplicemente come sciocca e inutile ... su. Vorrei essere d'accordo, seguire i processi sembra un po 'innaturale. È tipico o comune?

Oltre 20 anni di esperienza nello sviluppo qui, e non ho mai usato una metodologia formale. Non ne ho mai avuto bisogno e non ho intenzione di usarne uno in futuro. Le metodologie potrebbero andare bene per alcune persone, ma non sostituiscono i programmatori esperti che scrivono codice valido e testato.

Personalmente, penso che sarebbe opportuno che molte persone si preoccupassero meno di seguire la nuova metodologia più calda della giornata e si concentrassero maggiormente sulla qualità del codice.

Onestamente, se la tua piccola squadra ha lavorato senza incidenti rilevanti bene per tutti questi anni senza pensare al processo, probabilmente stavi facendo qualche forma di agilità. Tutto un processo agile significa che è conforme al "Manifesto Agile" http://agilemanifesto.org/ che ha poco da dire su iterativi, storyboard, ecc. Il primo inquilino di Agile è che preferisci "Individui e interazioni su processi e strumenti ". Qualsiasi team che lavora bene insieme non ha davvero bisogno di pensare molto al processo.

Le diverse marche di agili (come Scrum, ecc.) Sono molto utili se hai una squadra nuova di zecca che non è abituata a lavorare insieme. In un certo senso creano il quadro su come costruire un team coeso, che a sua volta costruirà un prodotto coeso.

Se quello che stai facendo funziona, continua a farlo. Se sei costantemente in ritardo con i risultati finali, devi fare regolarmente gli straordinari o devi correggere i bug maggiori dopo aver distribuito qualcosa, allora qualcosa non va. Questo è quando si apportano una serie di piccole modifiche per risolvere i problemi.

Se tutto va bene e va sempre bene, allora non ci sono problemi, quindi introdurre una nuova metodologia (i tuoi team avranno seguito una sorta di metodologia, formale o di altro tipo) sarebbe davvero una perdita di tempo.

Il punto in cui le metodologie sono di grande aiuto è quando il team incontra problemi o li pone da fonti esterne - una metodologia non solo introduce buone pratiche ma ti aiuta a proteggerle . È molto più facile mantenere le buone pratiche sotto stress quando le stai facendo consapevolmente, altrimenti possono essere rapidamente eliminate.

Non penso che tu abbia necessariamente bisogno di una metodologia formale, ma ogni squadra ha bisogno di una sorta di modello (non necessariamente ripetendo, potrebbe essere guidato dagli eventi) per il loro lavoro per essere efficace IMHO.

Se non hai problemi da risolvere, per fortuna.

Ho visto molti team (specialmente in aziende molto piccole) lavorare bene senza una metodologia definita.

Implementare una metodologia (o tecnica) perché è divertente o perché hai letto quel post sul blog su Internet è molto pericoloso.

Se stai bene, non cambiare nulla. Prova alcune ottimizzazioni quando puoi.

Esiste una vasta gamma di metodologie, alcune abbastanza sensate, altre al limite del folle. Sembrano tutti codificare il buon senso , dare loro un nome divertente, quindi vendere molti libri / seminari / ecc.

Ora, se il tuo management, o addirittura il tuo team, mancano di buon senso e non hanno organicamente le loro metodologie sensibili in atto (sia consapevolmente o non dette), allora potrebbero valere la pena studiare e quindi prendere in considerazione le parti della metodologia rilevante per le esperienze di quella squadra .

L'imposizione generalizzata delle ultime <insert-buzzword-here>pratiche di lavoro è suscettibile di causare più confusione di quanto non voglia risolvere. Ma in genere può fornire molte metriche della casella di controllo che un gestore di linea non codificante può spuntare con entusiasmo.

Forse non l'hai chiamato agile o mischia, ma ciò non significa che non avessi alcun processo e non lo stavi usando.

Proprio come lo sviluppo del software stesso. Probabilmente userete diversi modelli di design anche se non ci pensate esplicitamente con i loro nomi.