Come essere Agile quando un nuovo lavoro continua a influire sul lavoro completato?

2

Il progetto a cui sto lavorando è per ridisegnare un sito web esistente. La funzionalità rimarrà la stessa, sono solo gli stili che stanno cambiando. In altre parole, non sto modificando l'HTML, solo i file CSS.

Il sito è piuttosto complesso, con dozzine di pagine. Gli utenti connessi possono avere un numero di ruoli diversi e, a seconda del loro ruolo, il contenuto della pagina e le pagine che possono vedere variano.

Utilizziamo Git e Github.

Sto provando a scrivere CSS che funziona come componenti, quindi quando gli stessi elementi, intestazioni, ecc. compaiono su più pagine, sono coerenti. La maggior parte del tempo funziona bene.

Purtroppo, i nomi di formato e classe nell'HTML sono a volte disordinati e imprevedibili. Quando aggiusto qualcosa su una pagina, ne può rompere un altro. Il lavoro è anche più difficile in quanto nessuno conosce esattamente tutte le variazioni possibili a causa dei ruoli degli utenti; in quanto tale, trovo continuamente nuove varianti mentre procedo.

Sto facendo progressi inserendo molti commenti nel mio CSS. Se devo rimuovere una regola CSS, la commenterò in modo che possa ancora vederla con gli strumenti di sviluppo di Chrome e inserirò un commento nel CSS dicendo perché l'ho rimosso e per quale pagina è stata eseguita.

Questo significa che se in un'altra pagina sto per aggiungere una regola per risolvere un problema diverso, c'è una possibilità migliore che vedrò come si romperà la prima pagina. Questo mi consente di trovare una soluzione diversa che funzioni per entrambe le pagine o di rendere la pagina di sovrascrittura specifica.

Questo ha funzionato abbastanza bene per me. Se avessi il regno libero e l'unico obiettivo fosse finire il progetto entro la scadenza, allora questo metodo andrebbe bene. Tuttavia, il mio manager sta cercando di mitigare i rischi interrompendo il lavoro in aree da completare per sprint. Ciò è contrario a come mi sono avvicinato alle cose come qualcosa di simile al mio stile tipografico che interesserà tutte le altre pagine del sito.

L'altro problema è che le diverse parti interessate vogliono sottoscrivere ogni sezione mentre procedo. Il problema è che una volta terminata una sezione potrebbe cambiare se cambio il CSS che lo influenza insieme alla nuova sezione su cui sto lavorando. Ho chiesto che le parti interessate abbiano una rapida segnalazione non ufficiale a tappe (ad esempio per sprint) e abbiano l'approvazione ufficiale definitiva alla fine del progetto, ma questo incontra resistenza. Capisco perché sarebbe più rischioso farlo, ma l'unico modo per garantire che una sezione firmata non cambierà è rendere TUTTE le future modifiche specifiche della pagina.

In aggiunta a questo mi viene detto che tutto il lavoro che spingo al repository Git dovrebbe essere pronto per essere pubblicato, e come tale non dovrebbe contenere commenti di codice. Questo è rischioso per me poiché non lo saprò fino a quando non avrò finito il sito se mai trarrò beneficio da questi commenti o meno.

Qualcun altro si è trovato in una situazione simile e è riuscito a trovare un compromesso che ha funzionato per il mio approccio di sviluppo e anche i desideri del management e delle parti interessate di avere un approccio più agile? Un flusso di lavoro più agile funziona alla grande quando è possibile suddividere il lavoro in componenti e sapere che una volta che qualcosa è stato fatto non sarà influenzato dal lavoro futuro. Tuttavia, la natura di questo progetto lo rende difficile da raggiungere.

    
posta Evans 05.06.2014 - 17:22
fonte

2 risposte

6

Suggerimenti

  1. Sembra che il test non sia eseguito correttamente dal tuo team. Quello che ci si aspetta che faccia il tuo team è di avere test automatici che assicurino che le modifiche a HTML e CSS non infrangano nulla. pdiff sarebbe particolarmente utile per questo.

  2. Considerate HTML come "disordinato e imprevedibile". Ne hai parlato con il tuo team, e specialmente con le persone che scrivono il codice HTML? Perché i tuoi colleghi dovrebbero creare codice che consideri essere disordinato e imprevedibile? Sembra che la tua squadra dovrebbe concentrarsi su questo.

    Le revisioni del codice possono aiutare. Se è impossibile fare recensioni di codice, prova a discutere personalmente i problemi che trovi in HTML con il collega che ha scritto il codice (o la parte del codice lato server che genera questo codice HTML).

    Prova anche a restringere il problema. Forse c'è solo una persona nella tua squadra che scrive codice "disordinato e imprevedibile". Forse questo codice HTML è generato da un singolo componente.

    L'introduzione di standard di codice può anche essere una soluzione, a seconda della tua influenza sul team.

  3. Se hai problemi nel mantenere il codice coerente, perché non usi un preprocessore CSS come LESS o Sass ? È quindi possibile ottenere un migliore riutilizzo del codice e una maggiore coerenza.

Commento

I'm being told that all work that I push to the Git repo should be ready to go live

Esattamente. Questo è chiamato deployment / delivery / deployment continuo.

  • L'integrazione continua è quando ogni commit è seguito da una build e un'esecuzione di test automatici. Aiuta a localizzare potenziali regressioni.

  • La consegna continua è l'integrazione continua seguita (se i test hanno esito positivo) da un ulteriore passaggio: la costruzione di un pacchetto che può essere distribuito manualmente nella produzione.

  • La distribuzione continua è una consegna continua in cui il pacchetto viene effettivamente distribuito automaticamente.

In tutti e tre i casi, ci si aspetta che ti impegni a scrivere codice che funzioni. Non puoi impegnare ad esempio un gruppo di test unitari che al momento non riescono, aspettando che il codice sia implementato, o un pezzo di codice che aggiunge informazioni di debug in tutta l'interfaccia.

Ci sono molti vantaggi in questo approccio.

  • Hai un prodotto funzionante ad ogni commit. In confronto, ci sono progetti in cui il prodotto funziona effettivamente solo due volte all'anno, quando viene effettivamente confezionato e distribuito. Ciò aumenta il rischio di non spedire mai il prodotto.

  • Tu (così come le parti interessate e altre persone interessate) hai una migliore visibilità sul progetto.

  • Ci sono meno possibilità di rimanere a al 90% fatto per mesi.

If I need to remove a CSS rule, I'll comment it out

  • Invece di commentare il codice, rimuovilo. Il codice commentato è particolarmente dannoso per la base di codice, perché in sei mesi, nessuno sa perché questo codice è qui, perché è stato commentato e cosa fare con esso. I commenti hanno lo scopo di chiarire l'intenzione dell'autore originale; il codice commentato non ha questo scopo.

    Non mantenere il codice commentato solo per poterlo ripristinare in un secondo momento. Utilizzi già un controllo di versione, quindi tornare a una versione precedente o esaminare ciò che è stato modificato non dovrebbe essere un problema.

  • Non capisco perché ti venga detto che il codice di produzione non dovrebbe contenere commenti, e soprattutto perché tu dovresti rimuovere quei commenti dal tuo codice . Sembra che manchi un passaggio importante nel flusso di lavoro: la minificazione. Il codice JavaScript CSS e lato client deve essere limitato automaticamente, quindi spostato in produzione. Non dovrebbe essere tuo compito rimuovere i commenti dal codice che scrivi e, se fatto manualmente, può essere una fonte di errori umani.

risposta data 05.06.2014 - 17:58
fonte
0

C'è un grande libro là fuori chiamato "equilibrio tra agilità e disciplina". Non è tanto che la risposta sia nel libro, è che non esiste un modo giusto per fare Agile. È solo che il libro insegna che ogni azienda, ogni progetto ha persino bisogno di trovare il modo migliore di fare le cose. In questo caso, sembra che l'HTML non sia scritto in modo tale da poter cambiare il CSS con successo e avere scatti validi di due settimane. Le scelte sembrano essere di cambiare l'HTML o cambiare il metodo Agile.

In tutta onestà, la maggior parte di noi che scrive HTML non ha mai veramente provato a fare ciò che si sta facendo senza modificare l'HTML, quindi non abbiamo alcuna esperienza reale su cosa sia l'HTML buono e quale sia l'HTML errato. Non possiamo "annusare" qualcosa di sbagliato.

La domanda più difficile, onestamente, è come cambiare il metodo Agile per funzionare. Sembra che tu abbia qualche idea sull'argomento e ti stai chiedendo se è un percorso valido. Direi che dovresti sicuramente chiedere modifiche ai metodi Agile su cui stai lavorando per raggiungere meglio i tuoi obiettivi.

Oh, e dovresti assolutamente lasciare commenti nel tuo CSS. Il processo di compilazione dovrebbe rimuoverli. Quando il progetto è finito, dovresti rivederli e rimuovere o costruire su di loro per la prossima persona che deve fare la stessa cosa, alcuni anni lungo la strada.

    
risposta data 06.06.2014 - 01:56
fonte

Leggi altre domande sui tag