Che cosa rende un buon flusso di lavoro JIRA con un team di sviluppo software? [chiuso]

Naviga le tue risposte
3

Sto migrando la mia squadra da un ringhio di documenti di excel gestiti male, liste di controllo individuali ed e-mail personali per gestire i nostri problemi applicativi e attività di sviluppo in un nuovo progetto JIRA. Il mio team e io siamo nuovi a JIRA (e rilasciamo software di tracciamento in generale). La mia squadra è al massimo scettica sulla transizione, quindi sto anche cercando di non spaventarli introducendo qualcosa di troppo complesso all'inizio.

Capisco uno dei punti di forza di JIRA per essere i flussi di lavoro personalizzati che possono essere creati per un progetto. Ho esaminato la documentazione di JIRA e una serie di tutorial, e sono a mio agio con il modo in cui creo i flussi di lavoro, ma ho bisogno di alcuni elementi contestuali. Che cosa fare con esso.

  • Che cosa fa funzionare un particolare flusso di lavoro?
  • Che aspetto ha un flusso di lavoro progettato male?
  • Quali sono i vantaggi / gli svantaggi di un flusso di lavoro rigoroso con stati e transizioni molto specifici in un flusso di lavoro più flessibile, con meno stati e transizioni definiti più ampi
posta Hari Seldon 02.10.2012 - 22:19
fonte

2 risposte

1

Vorrei iniziare con tre passaggi. Da fare, in corso, in produzione. Lascia che gli altri stati e le transizioni si evolvano secondo necessità.

Questa tecnica è conosciuta come "spianare la strada della mucca" piuttosto che determinare in anticipo l'approccio più ottimale per un nuovo processo. ..il processo evolve in modo naturale.

Per dare un esempio di alcuni passaggi che potresti seguire nel tuo processo lungo la strada, In Progress to In Production sono tratti molto ampi. Potresti voler identificare i passaggi tra i due come: In QA, In UAT e Pronto per la distribuzione.

In sostanza, ti sto spingendo verso Kanban , il libro di David Anderson è un'ottima risorsa per imparare e sfruttare nella tua organizzazione.

    
risposta data 02.10.2012 - 22:34
fonte
4

Usiamo Jira con un flusso di lavoro eccessivamente complesso / personalizzato che dovrebbe essere buono per un piccolo gioco iOS one man fino alla successiva distribuzione dello space shuttle. Anche come leader di una squadra non posso fare cose senza coinvolgere un amministratore. Ad esempio, non riesco ad arrotolare un difetto contrassegnato come "fisso" indietro di un passo su "in azione", quindi se io (o un membro del team) "risolvo" un difetto e poi lo vedo non è corretto, si passa a un amministratore per far riparare Jira. Non farlo - la tua squadra sarà giustificata con lo scetticismo.

..... Non è colpa di Jira .....

Cose da tenere a mente. Jira è uno strumento che consente alle persone di portare a termine il proprio lavoro. Appena smette di funzionare, non sta facendo quello che dovrebbe.

Jira ha potenti funzionalità di reporting: usale piuttosto che flusso di lavoro che impedisce di portare a termine il lavoro.

Normalmente le persone vogliono fare la cosa giusta, rendendola facile. Le persone a volte devono fare la cosa sbagliata - rendere ciò possibile. Utilizzare il reporting e la revisione piuttosto che il comando e il controllo. per esempio. "Non dovresti essere in grado di chiudere un difetto senza che sia stato verificato dal reparto test, ma il cliente e il CEO hanno deciso che la soluzione deve uscire oggi." - Lo sviluppatore chiude il difetto e inserisce i commenti "Per ordine del CEO"

Soprattutto - BACIO, non è scienza missilistica. Non tutti i casi limite hanno bisogno di un modo personalizzato per affrontarlo - non farlo - i casi limite sono trattati meglio con commenti e flusso di lavoro flessibile.

    
risposta data 03.10.2012 - 00:50
fonte

Leggi altre domande sui tag

convenzioni per i metodi di amicizia in Perl Strategia di ramificazione per lo sviluppo parallelo che non sarà nella stessa versione?