Dove iniziano le "specifiche del documento" e la "proprietà del ruolo"?

In un processo agile, la linea tra i due è sfocata. Uno degli aspetti più sfaccettati dell'agile è lo sviluppatore che collabora strettamente con lo sceneggiatore delle specifiche, fa domande, ottiene feedback, ascolta le richieste e fornisce feedback. I requisiti, in qualsiasi forma entrino, dovrebbero cambiare. Gli sviluppatori devono essere abbastanza agili per gestire tali cambiamenti. Devi pagare queste persone per ora invece che per lavoro per ovvi motivi.

If business doesn't ask for it, they won't build it.

Questa è una mancanza di comunicazione. Vogliono qualcosa di più come un metodo a cascata in cui hanno effettivamente i requisiti che possono soddisfare. Se non conoscono abbastanza il ... modello di business, la tecnologia, i casi d'uso, gli utenti (e così via), allora non ne sapranno abbastanza per iniziare la conversazione o addirittura pensare se ... cosa è stato? "se i dati possono essere persi"?

Non dire "bloccato nella mentalità della cascata" come se fosse una sorta di insulto. Ci sono molti casi in cui una cascata è superiore a un processo agile. Il tuo potrebbe o potrebbe non esserlo. (Inoltre, si tratta di una scala mobile tra i due: anche per i grandi contratti difficili, a volte spostano un po 'l'intero fiume). Se esiste una sorta di ethos aziendale o di piano di sviluppo software in cui si afferma che si sta seguendo una filosofia agile, affidarsi a questo e chiedergli di essere un po 'più impegnato e di far fronte a requisiti in continua evoluzione.

Where I come from, we call those people "code monkeys".

Beh, certamente non portare con quello. Non c'è bisogno di essere un asino.

what if the dev team is not open to negotiate where this line is (because they're too busy coding)?

Allora hai conflitti tra partiti ed è letteralmente compito della direzione gestirlo. Dovrebbero chiarire qual è il processo e chi è responsabile di cosa. O hai bisogno di scrivere una specifica migliore o il team di sviluppo deve essere più impegnato, avere più riunioni, fare più domande e conoscere meglio i casi d'uso in modo che possano interrogarti per una migliore spec. Ma questa è una decisione per il capo. C'è una ragione per cui vengono pagati, gli fanno guadagnare.

Il modo in cui lo scrivi fa sembrare che lo sviluppo sia un po 'pignolo. MA!

Un design UX che ha più elementi sulla pagina di quanto necessario per la storia si sta spostando verso un processo a cascata.

Dovresti essere in grado di rilasciare il prodotto una volta completata la storia.

Diciamo che completi la storia e metti i bottoni extra. Ora hai pulsanti non funzionali. Non puoi rilasciare il prodotto.

Se si lasciano i pulsanti che non sono nella storia, per prima cosa si sta facendo una chiamata di giudizio e si lascia la cosa sbagliata e in secondo luogo si potrebbe avere la storia segnata incompleta perché il risultato finale non corrisponde al design.

Più comunemente, sebbene l'implementazione forzerà i cambiamenti nel design. Quindi vorrà includere tali modifiche nel design per la storia successiva.

Con la funzionalità non specificata, sembra un esempio di pernikity, ma di solito è necessario specificare ciò che si desidera.

L'idea è di muoversi rapidamente e produrre ciò che l'azienda vuole, non ciò che lo sviluppatore pensa sia bello.

Potrebbero facilmente uscire, spendere migliaia di sterline su server e licenze SQL e un paio di sprint che salvano la funzionalità solo per il business, oh questo non è importante per la prima fase. Vogliamo solo una demo.

Sembra che il tuo lead dev sia abituato a lavorare in un ambiente ad alta pressione dove vengono pagati per abbinare le specifiche il più rapidamente possibile. Piuttosto che uno in cui agli sviluppatori viene data una vaga idea imprenditoriale e lasciata a correre con essa.

Dici di volere lo stile successivo, in cui ti aspetti che lo sviluppatore riempia gli spazi vuoti, ma dici anche che stai facendo in modo che il ragazzo UX disegni in anticipo per interi gruppi di storie. Che dà il messaggio opposto.

Ti raccomando di ritagliarti in maniera massiccia sulle specifiche e prima di tutto fai una dimostrazione pratica del concetto. dimentica UX. Basta dare agli sviluppatori le vane storie di base e lasciare che funzionino.

Una volta che funziona e sei soddisfatto della funzionalità costruiscila in modo incrementale. Ciò consentirà a tutti una struttura di base da cui partire quando si specificano le funzionalità.

Qualcosa da tenere a mente dall'aspetto del team, alcune forme di "retrospettiva / correzione del percorso" continueranno a verificarsi indipendentemente dalla metodologia o dal tipo di squadra in cui la squadra cerca di essere più gelificata. Il concetto di avere una retrospettiva alla fine di uno sprint / time box è pensato per rivedere il processo con domande come quello che stai chiedendo qui. Come squadra, sarebbe una discussione / revisione di ciò che è stato fatto "bene" e di ciò che è stato fatto "male". Fare qualcosa "bene" o "male" è principalmente soggettivo in base al punto di vista della squadra nel suo insieme.

Per lo scenario che hai, un pezzo che ha diretto il Dev, dove concordo sul fatto che se un'epica / storia è stata trascinata in uno sprint, allora i nuovi requisiti non dovrebbero essere aggiunti alla storia nel mezzo del sprint. Per quanto riguarda la storia, se è stato chiarito il requisito per affermare che mentre un utente sta attraversando un'applicazione, la seguente schermata, scheda, pagina o qualsiasi cosa si basa sulle informazioni della sezione precedente e i dati devono persistere, allora il requisito non è "nuovo" ma una definizione più chiara. Ottenere chiarimenti non è l'atto di ottenere nuovi requisiti, ma l'atto di confermare / definire chiaramente i requisiti forniti.

Per quanto riguarda i wireframe, l'intento è quello di dimostrare con il cliente / proprietario del prodotto per determinare l'aspetto / layout e il flusso potenziale (s) che può accadere come una bozza di massima (flusso che indica una sequenza di eventi). I wireframe hanno sempre il potenziale per essere modificati e i wireframe non definiscono completamente tutte le aree di funzionalità. Se un wireframe definisse tutte le funzionalità, sarebbe come fare tutto il lavoro in anticipo solo per passarlo a qualcun altro da ripetere / copiare.

Tieni presente che potrebbe esserci qualche tipo di politica, a livello di team o di azienda, che impone che tutte queste informazioni siano nel wireframe prima di aggiungere qualsiasi funzionalità nuova / aggiornata nella base di codici, ma che sarebbe una discussione completamente diversa con le persone all'interno di quella squadra / azienda.

Per riassumere tutto, la linea viene generalmente definita in base all'intento del requisito. Se è stato chiarito che l'intento di un requisito include X, allora questa è la responsabilità del Dev Team. Se il dato requisito non ha alcuna influenza sulla storia / funzionalità, allora questo taglia la linea di distanza dal team di sviluppo (non accettando di aggiungere il requisito alla trama).

Un esempio di un requisito senza alcun rapporto con la storia / funzionalità:

Dato un po 'di pagina, I (Utente) deve essere in grado di aggiungere informazioni sulla pianificazione per i dipendenti, e l'invio dovrebbe fallire se c'è un conflitto. Dal wireframe, tutti i campi sono definiti e come è stato deciso il messaggio di notifica / errore.

Durante lo sprint, il cliente dice che la pagina deve avere una tabella che mostra le attuali tabelle dei dipendenti, in modo che gli utenti possano fare riferimento alla tabella invece di tentativi ed errori o utilizzare qualche altro strumento in cui desiderano consolidare il processo.

Sebbene questo requisito possa aiutare il cliente a utilizzare meglio la pagina, non ha alcuna influenza sul fatto che la storia, come deliverable, sarà accettata o rifiutata, e richiederebbe che ogni passaggio da UXD a Dev team sia eseguito di nuovo.