Vantaggi di Scrum per gli sviluppatori stessi? [chiuso]

Scrum offrirà molta più visibilità su ciò che sta succedendo . Cattiva gestione, cambiamenti dell'ultimo minuto, pressioni e tutti i tipi di cose che uno sviluppatore di solito affronta.

Tuttavia, porterà anche molta visibilità su procrastinatori, sviluppatori in malafede, individualisti folle, ... in altre parole, sviluppatori cattivi.

Scrum is a double edged sword

Scrum ti offrirà l'opportunità di risolvere questi problemi. Ecco perché è così potente.

Rompere il grande obiettivo ("portare a termine il software") in parti più piccole - storie - e decidere quale di loro fare nello sprint attuale migliora la produttività e riduce lo stress. Quando sai esattamente cosa dovresti fare ora , c'è poco da sottolineare, e puoi concentrarti a fare il pezzettino invece di sentirti sopraffatto dal complesso.

I ranghi di stack / il backlog mantengono i traguardi milestone dalle marce della morte

Come sviluppatore, il "modello distruttivo" che vedo di più nello sviluppo del software è quando alcuni "controller esterni" (ad es. project management, executive management) si entusiasmano molto del fatto che la "feature preferita" non sta andando a fare sulla "data del calendario" e ordina una marcia della morte.

Scrum, perché classifica le "caratteristiche importanti" in una lista di backlog aiuta gli sviluppatori a gestire questa tensione in modo proattivo in due modi. Innanzitutto, puoi classificare la "caratteristica preferita" in alto nel backlog in modo che sia più probabile che lui / lei sia felice. In secondo luogo, fornisce una risposta molto visiva e concreta a "dal momento che abbiamo spostato 'widget lampeggianti' al livello 1, è molto probabile che non riusciremo a" rimbalzare coniglietti "in questo sprint poiché ora è di livello 7. Sono ti senti a tuo agio con questo compromesso? "

Ho anche scoperto che con sprint brevi, i "controllori esterni" sono meno preoccupati per il posticipo del lavoro. Se "i widget lampeggianti" non diventano "milestone 1" e "milestone 2" non si concludono prima di 9 mesi, lo sponsor dei "widget lampeggianti" è molto turbato. Ma se "lampeggianti widget" è uno stack classificato 7 invece di 1 perché ci sono davvero 6 cose più importanti che devono essere fatte prima, questo significa che probabilmente lo otterremo in sprint + 1 o nel peggiore sprint + 2 che significa apparirà tra le 12 e le 18 settimane (utilizzando 6 settimane di sprint). Nella mia esperienza, aspettare 3 mesi è "accettabile" per gli impazienti - oltre a tornare nel modello "cascata" di pietre miliari di più di 3 mesi, in attesa che i prossimi due sprint terminino sia lo stesso calendario che l'attesa fino alla fine della pietra miliare attuale .

Infine, se stiamo raggiungendo la fine dello sprint e le cose hanno richiesto più tempo del previsto, è molto bello poter spingere gli elementi del backlog 5-6-7 allo sprint successivo e assicurarci di aver completato 1- 2-3-4 con alta qualità e senza settimane 70 ore. Dopotutto, saremo sicuri di arrivare al 5-6-7 dello sprint successivo. Di nuovo, visti i tempi più brevi coinvolti nel posticipo, i "controllori esterni" sono generalmente più a loro agio con questo e non insistono sul fatto che trasciniamo il traguardo due settimane e ordiniamo cene ogni notte "per spingerlo".

Le persone in un team di Scrum decidono molte cose da sole: cosa verrà fatto durante il prossimo sprint, come si interrompe questa storia nei compiti, chi lavora su cosa, ecc. Ciò li potenzia, ed è quasi l'esatto contrariamente alla microgestione.

Il fatto che i requisiti cambino viene preso in considerazione sin dall'inizio. Gli sviluppatori non hanno bisogno di creare specifiche dettagliate con stime precise e quindi passare settimane a sviluppare una funzionalità solo per rendersi conto che il cliente cambia idea non appena vede il risultato ...

Per me, è possibile assegnare autonomamente compiti dal backlog è il più grande punto vendita dal punto di vista degli sviluppatori. Inoltre, l'intimità con il cliente / proprietario del prodotto aiuta a comprendere lo schema di cose più ampio.

Un paio di cose:

• Basandosi sul punto di Xavier requisiti che cambiano dal inizio - un'atmosfera meno politica si sviluppa quando tutti accettano fin dall'inizio che alcune cose non saranno come il cliente si aspetta. Presto consegna e revisione significano questo il costo delle comunicazioni errate è basso, e invece di dare la colpa gioco, gli sviluppatori possono solo cambiare le cose in modo che funzionino come il cliente si aspetta.

• Punti di storia! Quale sviluppatore no come ottenere punti per fare cose!!?! Seriamente, è meglio di ottenere badge in SC2 o Stack Overflow.

Ci sono diverse cose che io come sviluppatore mi piace della mischia.

Gli sviluppatori tendono a ricevere più informazioni in anticipo. Il proprietario del prodotto deve spiegare tutto il lavoro che verrà svolto durante lo sprint successivo in modo sufficientemente dettagliato da consentire stime attendibili.

Una stima tempestiva significa che le stime sono ragionevolmente accurate. Tutti di solito hanno una ragionevole idea di cosa sarà finito in uno sprint. Ciò fornisce ai programmatori e ai project manager gli strumenti per respingere le richieste irragionevoli.

È bello fare un passo indietro ogni tre o quattro settimane e prendere un respiro e almeno avere un cambio di passo.

I team di auto-organizzazione, sembrano dare un po 'più di varietà nel lavoro.

In teoria, almeno, durante lo sprint ci sono meno interruzioni e "emergenze".

Il confronto quotidiano costringe i programmatori a dire diverse parole ogni giorno.

È più facile vedere i progressi compiuti poiché le storie vengono esplicitamente completate e riviste alla fine di ogni sprint.

I grafici di masterizzazione sono un mezzo leggero ed efficace per monitorare i progressi.

Il vantaggio per lo sviluppatore è il feedback iniziale (da cliente, tester, proprietario del prodotto ecc.)

Anche come sviluppatore, sono sempre interessato a fare le cose passo dopo passo senza distrazioni. Scrum fornisce questo.

PS: scrum non è una metodologia è un framework.