Scrum ha senso quando si implementa un nuovo backend del compilatore?

Ho una lingua esistente che devo portare su una nuova piattaforma. Probabilmente ci proverò cambiando il backend del compilatore esistente.

È una notevole quantità di lavoro riscrivere il backend. Non riesco a vedere un modo per scomporlo in storie sensate senza violare i criteri di INVEST.

Non riesco a vedere come ogni storia possa essere negoziabile - sono tutti necessari per un compilatore funzionante. Le storie hanno tutte la stessa priorità e non importa quale ordine le consegno. Ho bisogno di farli tutti.

Ci sono alcune parti del software che sto implementando che hanno una priorità inferiore rispetto ad altre e posso vedere che possiamo fornirlo in modo incrementale. Tuttavia, esiste un nucleo significativo che deve avere .

Ho intenzione di provare a seguire Scrum, ma sto solo esaminando i movimenti?

Esistono pratiche consigliate per questo tipo di progetto?

Tenere presente che il motivo principale per cui sono stati creati i processi Agile è stato quello di far fronte ai requisiti di spostamento. Se i requisiti sono fissati nella pietra (i requisiti veramente fissi sono rari ma ti porterò alla tua parola qui!), Allora alcune delle migliori pratiche per gestire i requisiti in evoluzione - ad esempio storie negoziabili - diventano in qualche modo irrilevanti. Detto questo, a seguito di un flusso di lavoro Scrum ha ancora molto valore potenziale in termini di pianificazione e fornitura di risultati. Anche se i tuoi risultati non costituiranno un prodotto completamente utilizzabile per un po ', c'è ancora qualcosa da dire per essere in grado di dimostrare progressi ai tuoi clienti (e al team!).

Considera che tutte quelle storie "indispensabili" comprendono un'unica epica: "Essere in grado di compilare sulla piattaforma X". In questo caso l'intera epopea deve essere completata prima che qualsiasi valore venga consegnato all'utente, ma questo è spesso il caso all'inizio di grandi progetti. Inizia con una storia per compilare il programma più semplice possibile, quindi crea altre storie per supportare sempre più funzioni linguistiche.

Soprattutto, non ti arrabbiare troppo nel cercare di forzare ogni situazione a adattarsi a un approccio altamente generalizzato. Agile dovrebbe funzionare per te, non viceversa!

Naturalmente Scrum è utile. È una metodologia che fa due cose per te:

1. Permette al tuo progetto di adattarsi al cambiamento e
2. Ti consente di tenere traccia dei progressi e avere un'idea di quando sarà finita

Quindi, c'è un certo valore nell'usarlo.

Penso che alcuni dei tuoi presupposti non siano corretti ed è qui che ti stai perdendo.

Non riesco a vedere come ogni storia possa essere negoziabile - sono tutti necessari per un compilatore funzionante

Questo non è vero. Puoi supportare un sottoinsieme della lingua e avere comunque un compilatore che funziona a determinate condizioni. Sicuramente meno prezioso di un compilatore completo, ma comunque prezioso.

Inoltre, fraintendete il significato di "negoziabile": non significa necessariamente "opzionale" e non è necessario che le storie siano facoltative in INVEST. Una storia è un obiettivo prezioso e la negoziazione è su come raggiungere tale obiettivo. Sicuramente ci sarà molto più che un modo per implementare il backend di ogni funzionalità linguistica. Ecco dove hai bisogno di negoziazione.

Le storie hanno tutte la stessa priorità e non importa quale ordine le consegno.

Questo non è corretto, come dici di seguito che alcune storie non sono "indispensabili", quindi alcune hanno meno valore. Ma anche nella categoria "must have": alcune caratteristiche del linguaggio sono molto più fondamentali di altre, e misurabili.

Un modo per misurare questo è "quante più righe di codice possiamo compilare su una base di codice esistente" o "quanti più test superano" se si dispone di una suite predefinita di test.

Ci sono anche altre opzioni. Se stavi compilando un C-come il linguaggio, a rigor di termini è necessario solo un ife gotociclo per avere un (a malapena) linguaggio funzionale ed è possibile implementare while, fore repeatcome macro. Supponendo che sia abbastanza facile scrivere un uso un precompilatore, puoi avere una soluzione di stopgap economica (ehi, stiamo negoziando? :-)

Per quanto riguarda l'adattabilità, il supporto di una lingua è un insieme abbastanza statico di requisiti, ma anche le lingue cambiano e anche la tua conoscenza delle tue esigenze cambia. Devi implementare tutto? Ci sono cose che non ti servono specificamente per i tuoi obiettivi? Uno degli inquilini di base di Agile è la conoscenza di avere una conoscenza incompleta, puoi sfruttarla?

In conclusione, per rispondere alla tua domanda più direttamente: hai bisogno di processi agili quando le tue esigenze sono immutabili? Sicuramente no! Sono utilizzabili? Probabilmente sì! Valgono il tuo tempo? Probabilmente no - ma le tue esigenze sono immutabili? Nelle mie esperienze passate, "requisiti immutabili" => "proprietario del prodotto pigro" - non una regola, ma vale la pena ricordare.

TL; DR

Tutti i controlli di gestione del progetto aggiungono sovraccarico. Non aggiungere spese generali non necessarie.

Scrum is the Wrong Hammer Here (Don't Be a Nail)

Scrum è un framework di gestione del progetto piuttosto che un insieme di pratiche di sviluppo adatte a un singolo sviluppatore. A meno che tu non stia facendo la gestione del progetto, Scrum è probabilmente la scelta sbagliata.

Inoltre, quando dici:

Le storie hanno tutte la stessa priorità e non importa quale ordine le consegno. Ho bisogno di farli tutti.

stai insinuando un paio di cose:

1. Il progetto ha valore zero a meno che tutte le storie non siano complete al 100%.
2. Le storie non dipendono l'una dall'altra.

Se entrambe queste affermazioni sono vere, allora non ha davvero senso utilizzare un framework o una pratica progettata per dare priorità al lavoro in base al valore o all'ordine di dipendenza.

Alternative suggerite

Qualsiasi progetto di sviluppo potrebbe potenzialmente beneficiare di alcune pratiche agili. In particolare, nel tuo caso specifico, consiglierei:

1. Assicurati che tutte le tue storie abbiano una "definizione di fatto" che includa test di unità e accettazione.
2. Integrare e refactor spesso; non lasciarti con un compito di integrazione gigante alla fine del progetto.

Inoltre, anche se il tuo prodotto ha davvero un valore pari a zero, a meno che tutte le storie non siano state realizzate, passerei un po 'di tempo a raggruppare le storie in temi che puoi considerare come pietre miliari completate. Essere in grado di dire "Ho completato la funzione foo" è spesso più utile che dire "Ho fatto storie a caso 23/117". YMMV.

Comprendo le tue preoccupazioni, ma credo che ci sia ancora valore per te nell'uso della mischia.

Certo, le storie degli utenti sono molto più fisse che in un'applicazione rivolta al consumatore. Quindi quell'aspetto della mischia fornirà meno valore.

Dove penso che otterrai valore è dalle versioni iterative e frequenti . Avere un prodotto potenzialmente rilasciabile alla fine di ogni sprint ti obbliga a mantenere alta la qualità del codice e basso il debito tecnico. È anche un ottimo modo per trovare i difetti in anticipo.

Penso che trarrai beneficio anche dal conoscere la tua velocità . Dopo diversi sprint, puoi vedere quanti punti di sforzo la tua squadra sta finendo ogni sprint. Questo ti dà una metrica obiettiva per aiutarti a determinare la data della tua spedizione.

Soprattutto, ricorda che l' agile è aggettivo . Alla fine di ogni sprint, dovresti tenere una riunione retrospettiva e quindi adattare il tuo processo alle tue esigenze. Se c'è una parte del processo di Scrum che non si applica allo sviluppo del compilatore, rimuovilo. Se c'è qualche altro elemento di processo che potrebbe essere utile, aggiungilo. La parte più importante di Agile secondo me è essere consapevole del tuo processo e migliorare costantemente per la tua situazione specifica.

(Nota, non ho mai fatto scrum su un progetto di compilatore; segui il mio consiglio con un granello di sale.)

Sì, purché ti ricordi che Scrum non è un insieme di regole rigide da seguire. Puoi adattarlo al tuo progetto. Sprint, standup, scrum settimanali saranno comunque utili al fine di favorire una migliore comunicazione tra i membri del team e per assicurarsi che il progetto continui nella direzione prevista.

Sembra che tutte le storie abbiano la stessa priorità, ma è necessario tenere conto della relativa difficoltà di attuarle. Non vuoi conservare i tuoi oggetti più difficili fino alla fine del progetto. Ti consigliamo di iniziare a lavorarci il prima possibile.