La tua squadra funziona bene senza seguire una metodologia di lavoro (come la mischia)?

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

Personalmente, penso che a molte persone sia importato di attenersi alla metodologia più recente del giorno e concentrarsi maggiormente sulla qualità del codice.

Onestamente, se la tua piccola squadra ha lavorato senza incidenti importanti per tutti questi anni senza pensare al processo, probabilmente stavi facendo una qualche forma di agilità. Tutto un processo agile significa che è conforme al "Agile Manifesto" link che ha poco da dire su iterative, story board, ecc. Il primo inquilino dell'agile è che preferisci "Individui e interazioni su processi e strumenti". Qualsiasi team che funzioni bene insieme non ha davvero bisogno di riflettere sul processo.

I diversi marchi di agile (come Scrum, ecc.) sono molto utili se hai un team nuovo di zecca che non è abituato a lavorare l'uno con l'altro. In un certo senso stabiliscono il quadro per come costruire una squadra coesa, che a sua volta costruirà un prodotto coeso.

Se quello che stai facendo funziona, continua a farlo. Se si è costantemente in ritardo con i risultati finali, dovendo eseguire regolarmente il lavoro straordinario o dover correggere bug importanti dopo aver distribuito qualcosa, allora qualcosa non va. Questo è quando fai una serie di piccole modifiche per risolvere i problemi.

Se tutto va bene e va sempre bene, allora non c'è problema - quindi introdurre una nuova (i tuoi team seguiranno una sorta di metodologia - formale o di altro tipo) sarebbe davvero una perdita di tempo.

Dove le metodologie aiutano davvero è quando il team incontra problemi o ha problemi ad affrontarli da fonti esterne - una metodologia non introduce solo buone pratiche, ma ti aiuta a proteggerle . È molto più facile mantenere buone pratiche sotto stress quando le stai facendo coscientemente, altrimenti possono essere espulse rapidamente.

Non penso che tu abbia necessariamente bisogno di una metodologia formale - ma ogni squadra ha bisogno di un qualche tipo di schema (non necessariamente ripetendo, potrebbe essere guidato dagli eventi) al proprio lavoro per essere efficacemente IMHO.

Se non hai problemi da risolvere, sei fortunato.

Ho visto molti team (specialmente in aziende molto piccole) che lavorano bene senza alcuna metodologia definita.

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

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

Esiste una vasta gamma di metodologie, alcune delle quali molto sensate, alcune al limite della pazzia. Sembrano tutti codificare buon senso , dare loro un nome divertente, quindi vendere un sacco di libri / seminari / ecc.

Ora, se la tua direzione, o addirittura il tuo team, sono privi del buon senso e non hanno organicamente le proprie metodologie sensate (consapevolmente o non dette), allora potrebbero valere la pena studiarle e poi prendere in considerazione le parti della metodologia rilevante per le esperienze del gruppo .

L'imposizione generalizzata delle ultime pratiche di lavoro <insert-buzzword-here> può causare più confusione di quella che mira a risolvere. Ma in genere è in grado di fornire molte metriche di caselle di controllo che un gestore di linea non codificante può inserire con entusiasmo.

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

Proprio come lo sviluppo del software stesso. Probabilmente utilizzerai diversi schemi di progettazione anche se non li pensi esplicitamente con il loro nome.