È agile? Mischia? Come migliorare l'agilità?

Sembra che tu abbia preso alcuni elementi fantasiosi dallo sviluppo agile, li hai messi in cascata e ora lo chiami agile.

The product is developed for a customer who will re-sell it while paying us royalty.

Questo è OK.

The team does not get to talk directly to the end user. Only to the reseller.

Questo è OK. Il proprietario del prodotto parla con il rivenditore e raccoglie i requisiti.

A product requirements document was created before starting development.

Questo non è OK. Non ho visto il progetto in cui è possibile definire anticipatamente determinati requisiti. Cambia il tuo documento sui requisiti del prodotto in visione del prodotto (breve) con alcune serie iniziali di requisiti che sono soggetti a modifiche.

The requirements are rigid and do not change.

Questo non è OK e in futuro vedrai che non è vero.

A delivery schedule was agreed on with milestones such as "alpha", "beta" etc. and features/times attached to those milestones.

Questo non è OK. Il vero programma sarà visibile dai progressi del team. È possibile fare delle pietre miliari generali, ma non è agile assegnare un insieme esatto di caratteristiche che saranno implementate in queste pietre miliari. Questo può cambiare durante lo sviluppo.

All developers on the Scrum team report to the product owner, a software manager.

Questo non è OK. Non direi che gli sviluppatori segnalino al proprietario del prodotto. Il processo Scrum mantiene la visibilità del processo ma gli sviluppatori non riportano nulla se non le riunioni periodiche. È responsabilità del proprietario del prodotto essere in contatto con una squadra e, in qualità di partecipante attivo, vedere lo stato di avanzamento.

Testers on the team report to a QA manager.

Questo non è OK. I tester dovrebbero far parte del team di sviluppo perché la storia dell'utente non viene eseguita finché non viene testata (ci dovrebbe essere un test automatico per convalidare i criteri di accettazione). Può esserci un QA separato ma è un livello aggiuntivo di test complessi e solitamente viene fatto dal lato del cliente (ma non deve essere) per convalidare che SW fa ciò che il cliente si aspetta e il feedback viene raccolto come nuovi elementi di backlog o bug per elementi di backlog completati esistenti.

Separare il QA completo al di fuori del team di sviluppo porta a rompere l'intero scopo della definizione di fatto. Alcuni QA devono far parte del team e quella parte non è correlata a nessun responsabile QA - quella parte è impegnata con il team di sviluppo.

The product owner has directed the team towards certain high risk technical tasks. The output of those tasks is not usable by the end user but rather some technology/code that will eventually be used in the product.

Questo accade in ogni progetto, ma dovrebbe essere parte di un elemento di backlog di prodotto destinato all'utente finale. Può essere incluso direttamente nell'elemento backlog implementato nell'iterazione corrente o può essere incluso come spike (proof-of-concept) per chiarire la complessità di alcuni elementi del backlog che dovrebbero essere implementati in futuro.

The product owner has created a backlog based on the requirements.

Questo è un must.

The product owner is unable to answer some questions regarding the product. He refers to others or to the documented requirements.

Questo non è OK. È compito del proprietario del prodotto sapere le risposte. Ha una responsabilità e deve prendere decisioni. Se non conosce la risposta, deve trovarla al più presto.

The team goes through the motions of Scrum. Daily Scrum, Sprint Planning, Retrospective etc. There is a ScrumMaster.

Questo è OK ma ciò non significa che il team stia facendo Scrum.

Every sprint the product owner and management decide what backlog items the team works on.

Questo non è assolutamente OK. Il proprietario e la gestione del prodotto possono fare delle priorità, ma l'impegno (selezione degli articoli più prioritari) è responsabilità dei team.

There is a burndown chart. Scrum board with stories and tasks. The estimates on those come from the team.

Questo è OK.

The team sits in an open floor "bull pen" shared with other teams, all visible and audible. There is cross-team noise and there is foot traffic around the team area.

È responsabilità del master Scrum porre fine a questo se il team ritiene di ridurre la propria produttività.

The team may be required to attend various meetings not directly related to the goals of the sprint.

Va bene, il tempo perso in questi incontri si tradurrà in un impegno minore (la squadra farà meno lavoro reale). Spetta a Scrum master / management ridurre questi incontri per aumentare la velocità della squadra.

There are pressures to select certain technical solutions. Some tools and processes are mandated.

Questo è parzialmente OK. Ci possono essere requisiti non funzionali per strumenti e architettura e ci possono essere processi definiti, ma l'implementazione finale spetta al team.

Sembra un approccio mini-cascata piuttosto che completamente agile

Potrebbe essere una scomposizione dei capelli

Anche se in superficie sembra un approccio agile, credo che possa avere più in comune con "mini-cascata". I progetti di mini-cascata presuppongono che tutti (o la maggior parte) requisiti possano essere compresi prima che i progetti possano essere creati e che la codifica segua ogni iterazione o "fase".

Ciò richiede un alto grado di certezza riguardo ai requisiti. Agile presuppone che tutti i requisiti non siano conoscibili fino a quando non viene creata una versione funzionante del sistema.

Tempo di boxing e correzione delle feature

Agile tende ad essere "time boxed" (usando la metafora del triangolo di ferro di tempo / caratteristiche / costo). La cascata tende ad essere più "funzione risolta".

Problemi con la consegna di mini-cascata

Il problema con la consegna di "mini-cascata" al client è che generalmente non ottengono ciò che vogliono. Dopo aver dato un'occhiata al software di lavoro, si rendono conto solo troppo tardi che ciò che hanno detto di aver inserito nel documento dei requisiti non era quello che intendevano dire.

Il cliente può cambiare i requisiti dopo aver visto il software di lavoro

Succede sempre, sii preparato a fare cambiamenti nelle tue fasi successive per far fronte ai cambiamenti nei requisiti. Questo potrebbe cambiare il modo in cui ti avvicini alla progettazione del tuo framework se ti stai aspettando cambiamenti nei tuoi requisiti.

Alcuni consigli per renderlo più agile

• link

If you want to stop thinking mini-waterfall and start thinking Agile…

stop thinking about building software serially, and start thinking about doing it in parallel. Stop thinking in terms of:

* Step 1: Get the requirements
* Step 2: Design the solution
* Step 3: Develop the solution
* Step 4: Test

Start thinking in terms of:

* Step 1: Figure out the first thing the user wants
* Step 2: Build a small piece, making sure it is right
* Step 3: Check with the user to see how to make it better
* Step 4: Continue until user is happy

Un documento sui requisiti del prodotto è stato creato prima di iniziare lo sviluppo. E poi costruisci il progetto usando Scrum e Sprint.

È uno sviluppo iterativo e incrementale e non proprio agile.

Molti dei cosiddetti progetti scrum hanno un documento sui requisiti (PRD) scritto per primi e anche un design dell'interfaccia utente fatto in anticipo, sebbene non abbiano requisiti rigidi.

Almeno per Agile, oltre a quello che stai facendo, nella demo di sprint end Il proprietario del prodotto, i clienti e il team dovrebbero fornire feedback e l'OP dovrebbe avere la possibilità di modificare i requisiti in base a tale feedback. Inoltre, la squadra dovrebbe organizzarsi da sola.

No. Questo non è Scrum, né è agile. In particolare:

The requirements are rigid and do not change.

Scrum è progettato per facilitare la modifica dei requisiti. Potresti avere un progetto Scrum in cui i requisiti rimangono invariati, ma non puoi entrare in un progetto Scrum con la restrizione che non possono cambiare.

A delivery schedule was agreed on with milestones such as "alpha", "beta" etc. and features/times attached to those milestones.

Questo non sarebbe possibile in un vero progetto Scrum.

All developers on the Scrum team report to the product owner, a software manager. Testers on the team report to a QA manager.

Questo è un problema se il problema di "chi gestisce chi" intralcia la sinergia della squadra. Il fatto che sia menzionato qui è probabilmente un'indicazione che ciò sta accadendo.

The product owner has created a backlog based on the requirements.

Una delle regole fondamentali di Scrum è che chiunque può aggiungere qualsiasi cosa al backlog in qualsiasi momento. L'arretrato è una cosa vivente e fluida che rappresenta la conoscenza in evoluzione delle persone coinvolte nel progetto.

The product owner is unable to answer some questions regarding the product. He refers to others or to the documented requirements.

Questa è una massiccia bandiera rossa che non è Scrum. L'OP è l'unica persona nell'organizzazione con PROPRIETÀ del prodotto. Può prendere tutte le decisioni sui risultati del progetto. Se non può, allora hai la persona sbagliata nel ruolo PO.

Every sprint the product owner and management decide what backlog items the team works on.

Questo è il problema più grande. In Scrum, l'OP deve decidere quali sono le priorità relative degli articoli nel backlog, il team ha l'unico diritto a fornire stime e decidere quanti oggetti verranno lavorati in ogni Sprint. Nessuno è autorizzato a dire al Team quanti oggetti saranno inclusi nello Sprint.

Questo sembra uno sviluppo incrementale, ma non è iterativo. Iterativo implica che rivaluti il progetto, il set di caratteristiche, i requisiti, il design e il programma di consegna all'inizio di ogni iterazione, mettendolo davanti al cliente e lavorando a ciò che hai appreso nel progetto.