Applicare gli standard organizzativi per il software in Scrum

Il luogo tipico in cui vengono applicati tali standard di qualità è nella "definizione di fatto" utilizzata dal team. La "definizione di fatto" è essenzialmente una lista di controllo che controlli per vedere se tutto il lavoro necessario sulla storia è stato completato ed è stato fatto per gli standard di qualità che il team ha accettato di mantenere.

Se i team hanno già esperienza nell'applicare tali standard al loro lavoro, allora non dovrebbe causare alcun onere richiedere che il software sia conforme a tutti quegli standard in modo verificabile alla fine di uno sprint.

Se il team non ha esperienza nell'applicare quegli standard, potresti volerli introdurre uno o due alla volta.

In sostanza, quando si utilizza Scrum, l'intera squadra diventa responsabile dell'applicazione di tali standard. Gli attuali lead in quelle aree otterrebbero più un ruolo di consulente e revisore, consigliando i team su come applicare lo standard e verificare che sia stato eseguito correttamente.

Il vantaggio è lì per guidare, non dettare o imporre. Se è fidato e rispettato dai suoi colleghi sviluppatori perché non lo dovrebbero ascoltarlo? E se il lead non può fidarsi dei suoi colleghi sviluppatori, allora c'è un problema più profondo.

Questi team dovrebbero avere accordi di lavoro e una definizione concordata di fatto . Queste sono le cose che aiutano a rafforzare la qualità e il processo all'interno del team.

Immagina una mischia / un ambiente agile in cui qualcuno potrebbe semplicemente entrare e dire: "Questo è come lo voglio fare! Fallo in questo modo!". Ora, non sto dicendo che questo non accada, ma non dovrebbe . Questo è il motivo per cui la guida indica ciò che fa.

La guida non toglie nulla alla guida e promuove infatti un ambiente migliore basato sul lavoro di squadra. La capacità del lead di " far rispettare " è basata sulla fiducia e il rispetto dei suoi compagni di squadra. Altrimenti, a che serve?

Scrum non è solo un duro insieme di regole; YMMV.