Ci sono dei sondaggi su come gli sviluppatori piacciono o odiano scrum? [chiuso]

Scrum è molto impegnativo ...

.. specialmente quando è pervertito dalla gestione.

Quindi non ho dubbi che molti sviluppatori odiano Scrum.

Un modo per pervertire Scrum che ho visto in una grande azienda era dividere la velocità dagli sviluppatori. E, naturalmente, renderlo molto visibile nella situazione quotidiana. Indovina cosa è successo a breve termine?

Ho trovato che Scrum di solito non è adatto in alcune organizzazioni, in particolare le aziende pubbliche e amp; governi.

Dopo 5 anni di Scrum intensivo di pratica, insegnamento e amp; coaching, sia in società di grandi dimensioni che in società molto piccole, sono giunto alla conclusione che Scrum è solo un'altra tecnica come Java è un'altra lingua rispetto a C # e che ciò che fa la differenza sono gli individui che usano non è la tecnica stessa.

Meta-commento: Sarebbe bello avere domande sui sondaggi sui programmatori.

Dato che lo Scrum varia molto tra squadre diverse e organizzazioni diverse, questa domanda sarà molto difficile da rispondere. Scrum dovrebbe essere circa che consente al team di fornire un ottimo software e gli sviluppatori dovrebbero così.

Dove va male? La risposta è nella mia dichiarazione di cui sopra. Il team non è abilitato o non viene fornito un ottimo software.

Ci sono così tante modalità di errore, eccone alcune:

• Il proprietario del prodotto non comprende il cliente o l'azienda.
• Il team non comprende il cliente o l'azienda.
• I problemi organizzativi impediscono al team di raggiungere i propri obiettivi.
• Scrum si trasforma in una microgestione quotidiana.

Talvolta sono noti come scrum-buts .

Scrum IMO ha più probabilità di essere apprezzato / riuscito se:

• Il team ha preso la decisione di adottare Scrum perché riteneva che fosse appropriato per il prodotto / progetto.
• C'è un feedback strong / continuo da parte del cliente attraverso il proprietario del prodotto.
• Spedisci dopo ogni sprint.
• Il team ha autonomia, auto-organizzazione e pieno affidamento / supporto da parte dell'organizzazione.
• Un'ampia percentuale di elementi nel backlog proviene dal team.

Un altro commento è che in Scrum i programmatori "pigri" sono responsabili solo verso il team in modo che preferiscano che siano responsabili nei confronti del loro capo. In ogni caso, non penso che questo sia un fattore.

Un problema che vedo con Scrum è il problema dell'uovo e della gallina. Se sei già agile potresti non aver bisogno di Scrum. Se sei intrinsecamente poco agile, Scrum probabilmente non lo cambierà, potrebbe addirittura peggiorare le cose perché porterà qualsiasi agilità sulla superficie e renderla così visibile che le forze anti-agili possono schiacciarla :-)

Un'organizzazione non agile può diventare semplicemente agile? Non lo so. Penso che Scrum voglia farlo ma non sono sicuro che sia in grado.

Per la mia esperienza, Gli sviluppatori / architetti odiano molto la scrum. Potrebbe essere a causa dei seguenti motivi

1. Molte organizzazioni di prodotti considerano la consegna aziendale come obiettivo primario e collegano ogni storia di sprint a esigenze aziendali. Quindi hanno dirottato / compromesso i motivi dell'architettura, della piattaforma, del design pulito, della qualità del codice in diverse occasioni. A volte non considerano le grida degli sviluppatori. Questo è ciò che sentono gli sviluppatori professionisti che non sono pigri.

2. Agile / scrum dà il predominio, i proprietari di prodotti di lenience / product manager molto sul non dare dettagli completi riguardo ai requisiti e all'invent che si aspettano che gli sviluppatori immaginino / assumano la necessità di procedere con lo sviluppo. Ciò comporta differenze nell'implementazione, troppi difetti, enorme dolore per gli sviluppatori bruciando il loro olio di mezzanotte in molte occasioni.

3. In molti casi i proprietari dei prodotti compromettono i requisiti tecnici con gli obiettivi aziendali spesso ignorano gli sviluppatori, le opinioni degli architetti sul prodotto, gli obiettivi a lungo termine dell'architettura e ci risolvono con soluzioni a breve termine che non sono una scelta giusta per qualsiasi prodotto

4. Alla fine ti ritroverai con un prodotto che presenta difetti, difetti di progettazione, a volte rollback di produzione, valutazioni di insoddisfazione da parte dell'utente, problemi di prestazioni, base di codice orribile per lo sviluppatore.

Non considero la mischia / agile come una metodologia migliore in molte occasioni.

Lo odio. E la maggior parte degli sviluppatori che conosco lo odio pure.

È piuttosto difficile fare un lavoro cerebrale e creativo come lo sviluppo di un software al microscopio.