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

Ricorda che il motivo principale per cui i processi Agile sono stati creati era quello di far fronte ai mutevoli requisiti. Se i requisiti sono fissati nella pietra (i requisiti veramente fissi sono rari ma ti porto in parola qui!), Allora alcune delle migliori pratiche per affrontare i mutevoli requisiti - ad es. Storie negoziabili - diventano in qualche modo irrilevanti. Detto questo, seguire 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 al tuo cliente (e al team!).

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

Soprattutto, non esagerare nel cercare di forzare ogni situazione ad adattarsi ad un approccio altamente generalizzato. Agile dovrebbe funzionare per te, non il contrario!

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

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

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

Penso che alcune delle tue condizioni preliminari non siano corrette ed è lì che ti perdi.

I can't see how each story can be Negotiable - they are all required for a working compiler

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

Inoltre, fraintendi cosa significa "Negoziabile": non significa necessariamente "Opzionale" e non è richiesto che le storie siano opzionali in INVEST. Una storia è un obiettivo prezioso e la negoziazione è su come raggiungere quell'obiettivo. Sicuramente ci sarà molto più del modo di implementare il back-end di ogni caratteristica linguistica. C'è dove devi negoziare.

The stories are all of equal priority and it doesn't matter what order I deliver them.

Questo non è corretto, come dici sotto che alcune storie non sono "must have", quindi sicuramente alcune sono meno preziose. Ma anche nella categoria "must have": alcune caratteristiche linguistiche sono molto più fondamentali di altre e in modo misurabile.

Un modo per misurare questo è "quante più linee di codice possiamo compilare su una base di codice esistente" o "quanti più test passano" se hai una suite di test predefinita.

Ci sono anche altre opzioni. Se stavi compilando un linguaggio simile a C, in senso stretto hai solo bisogno di un if e goto loop per avere un linguaggio (appena) funzionale e puoi implementare while , for e repeat come macro. Supponendo che sia abbastanza facile scrivere un precompilatore, si può avere una soluzione economica per il problema (hey, stiamo negoziando?: -)

Per quanto riguarda l'adattabilità, il supporto di una lingua è un insieme di requisiti abbastanza statici, ma cambiano anche le lingue e anche la tua conoscenza delle tue esigenze . Hai bisogno di implementare tutto? Ci sono cose che non ti servono in particolare per i tuoi obiettivi? Uno degli inquilini di base dell'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 i tuoi requisiti sono immutabili? Nelle mie passate esperienze, "requisiti immodificabili" = > "proprietario del prodotto pigro": non una regola, ma vale la pena tenerla a mente.

TL; DR

Tutti i controlli di gestione dei progetti aggiungono un sovraccarico. Non aggiungere sovraccarico di cui non hai bisogno.

Scrum è il martello sbagliato qui (non essere un chiodo)

Scrum è una struttura di gestione del progetto piuttosto che un insieme di pratiche di sviluppo adatte per uno sviluppatore individuale. A meno che tu non stia facendo la gestione dei progetti, Scrum è probabilmente la scelta sbagliata.

Inoltre, quando dici:

The stories are all of equal priority and it doesn't matter what order I deliver them. I need to do them all.

stai implicando 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 usare un framework o una pratica progettata per dare priorità al lavoro per valore o 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 unitari e di accettazione.
2. Integrazione e refactoring spesso; non lasciarti con un gigantesco compito di integrazione alla fine del progetto.

Inoltre, anche se il tuo prodotto ha veramente valore zero a meno che tutte le storie siano finite, passerei un po 'di tempo a raggruppare le storie in temi che puoi trattare come pietre miliari completate. Essere in grado di dire "Ho completato la funzionalità foo" è spesso più utile di dire "Ho 23/117 storie a caso fatte". YMMV.

Capisco le tue preoccupazioni, ma credo che ci sia ancora un 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 di mischia fornirà meno valore.

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

Penso che ti piacerebbe anche conoscere la tua velocità . Dopo diversi sprint, puoi vedere quanti punti di sforzo il tuo team sta finendo ogni sprint. Questo ti dà una metrica obiettivo per aiutarti a determinare la data della tua nave.

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

(Si noti che non ho mai fatto scrum su un progetto di compilatore, segui il mio consiglio con un pizzico di sale.)

Sì, a condizione che tu ricordi che Scrum non è un insieme di regole severe da seguire. Puoi adattarlo al tuo progetto. Sprint, sostegni, scrums settimanali saranno comunque utili per favorire una migliore comunicazione tra i membri del team e per assicurarsi che il progetto prosegua nella direzione prevista.

Tutte le storie possono sembrare avere uguale priorità, ma è necessario tenere conto della relativa difficoltà di implementarle. Non vuoi mantenere i tuoi oggetti più difficili fino alla fine del progetto. Dovrai iniziare a lavorarci il prima possibile.