Quali sono gli errori comuni in "approcci Scrum su misura"? [chiuso]

Spostato dai commenti ...

Hai pensato di provarlo e vedere come funziona prima di fare pressioni contro di esso? Finché sono aperti ad adeguare la struttura nel tempo, non vedo difetti fatali in questo piano se non che non segue il dogma Agile alla lettera.

Un'altra cosa da considerare è che si desidera incorporare nell'approccio un numero sufficiente di idee del business leader in modo che si sentano a proprio agio nell'adozione di Agile. Se lo faranno, saranno incaricati di assicurarsi che riescano invece di denigrarlo (perché il loro approccio sarebbe stato migliore) se le cose si fossero fatte di traverso. E inevitabilmente andrà di traverso, soprattutto all'inizio. Le persone di solito sono resistenti ai cambiamenti e sono spesso goffi per un po 'quando sono costrette ad adottare un nuovo modo di fare le cose.

Rendi la gestione un partner nel processo, non un avversario.

Il Responsabile dello sviluppo e in una certa misura lo ScrumMaster sono variazioni del ruolo tradizionale del lead tecnologico. Non vedo che il gestore dello sviluppo abbia necessariamente più o meno comando e controllo come lo metti di un tipico lead tecnologico.

Lo Scrum Master è un po 'più speciale di quello però. Il Responsabile dello Sviluppo non dovrebbe essere anche lo Scrum Master, ma non vi è alcun motivo per cui lo Scrum Master non possa essere solo il PM in ogni caso, dal momento che ha più interesse per i timesheet. Il tempo di tracciamento su una pianificazione del progetto non è disgiunto dal concetto di User Story, Points e Burndown Charts.

Si ha un certo punto sul ruolo dell'agente Product Owner. Non vedo una persona in quel ruolo che abbia una chiara e unica responsabilità oltre ad essere un collegamento aggiuntivo nella catena di comando.

Il Product Owner è tuttavia ridicolmente importante. Lui possiede il prodotto. Non ho intenzione di spiegarne l'importanza, ma se hai mai lavorato a un progetto in cui non esisteva un chiaro proprietario del prodotto perché i middle manager erano troppo polli - $$$$ per prendere la proprietà della direzione e le decisioni del PRODOTTO in merito al PRODUCT quindi vedrai come sabota completamente tutti i progetti prima ancora di iniziare.

Hai bisogno di loro per differenziare il modo in cui è strutturata la società e come sono strutturate le persone in un processo di sviluppo di mischia. Questo va bene per un organigramma.

Per un progetto ERP di grandi dimensioni, potresti avere una sezione quasi separata che ha i proprietari dei propri prodotti. Possono riferire a qualcuno, ma dal punto di vista di Scrum, ci deve essere un proprietario del prodotto che lavora con il gruppo assegnato a quella parte del progetto.

Il gestore dello sviluppo è più la persona che può fare le valutazioni, organizzando i giorni di riposo e altri compiti di gestione che non hanno nulla a che fare con lo sviluppo.

Mostra loro come si separano i due. Non c'è motivo per cui piccoli gruppi di scrum non possano esistere in una grande azienda. Devi sapere dove si trovano le persone in entrambi i mondi.

In realtà non è così lontano. Dipende da quali sono i ruoli di certe persone.

• Ci può essere più di una persona in un team che riempie il ruolo di Product Owner (come nell'entità decisionale responsabile della generazione, della prioritizzazione e dell'accettazione dei requisiti). Su grandi progetti una persona semplicemente non può fare tutto. Ciò che è importante è che esiste un unico percorso di comunicazione da e verso il proprietario del prodotto, a cui sono rivolte le domande e da cui provengono le direttive sui requisiti, tuttavia molte persone sono dietro di loro (o addirittura di fronte a loro) che assistono il processo. In breve, dovrebbe esserci sempre un ragazzo che puoi chiamare con una domanda, non importa con chi parla, per ottenere la risposta o con chi comunica la risposta. Quindi, se l'agente è semplicemente qualcuno appartenente alla "squadra" di proprietà del prodotto che partecipa come un pollo agli IPM e alle alzate quotidiane e riporta all'OP, ciò va bene; il PO non può essere ovunque. Se si tratta di una persona in grado di prendere decisioni indipendentemente da altri agenti o dal proprietario del prodotto o che è stata progettata per limitare l'accesso all'OP, ciò può costituire un problema.

• Development Manager suona come "Project Manager" o "Team Lead" per me. Potrebbe anche essere "Architetto", che è il responsabile del mantenimento di una buona struttura di progettazione e della decisione dei modelli a livello aziendale da seguire nello sviluppo di determinate aree. Di solito c'è un solo Architetto, come se ci fosse un solo Product Owner, quindi se questo ragazzo è un ruolo "Project Manager" o "Architect" dovrebbe essere un lavoro inter-team, non uno per.

• Non vedo BA in questo grafico. Durante il mio ultimo lavoro Agile, i BA hanno ricevuto e rivisto le storie non elaborate, dipendenze determinate che avrebbero creato conflitti di pianificazione e un "percorso critico", e in genere anche un certo QA. Erano anche quelli al telefono il più con il PO. Ciò ha permesso ai team di codifica di fare ciò che sanno fare meglio: la codifica head-down.

L'idea di timesheet a differenza di un burndown per tracciare i progressi sembra strana. Sembra che il contratto sia stato negoziato per tempo e materiali, e vogliono il TEMPO, non una stima del tempo basata sulla complessità dei punti. Va bene, fino a un certo punto, ma il punto di Agile è che i tuoi clienti preferiscono pagare per punto anziché per ora; un punto è un'unità di lavoro calibrabile, e quando è fatto si ha un prodotto reale che dovrebbe valere la stessa quantità di una frazione dell'intero progetto.

Non penso che sia ovvio che le cose fallirebbero.

There are product owner agents (an obvious WTF), who report to the product owner: causing dilution of decision making capability

Supponendo che qualcuno debba rappresentare cliente (nel caso in cui il cliente reale sia assente) questo non è un problema. Tuttavia, i criteri di successo sono la visualizzazione delle reali esigenze dei clienti.

There is a role that looks similar to a manager in the traditional approach - development manager: an obvious attempt at command-and-control model

Questo di solito accade dove un tipo tecnico tradizionale non è abbastanza anziano (o noto per essere abbastanza bravo da fare project manager ma conosce la maggior parte delle cose tecnologiche meglio della maggior parte) (a meno che non sia un altro modo) La vera differenza viene in base a ciò che effettivamente fanno.