Scrum per un singolo programmatore? [chiuso]

Impara Scrum: sì. Se solo per imparare su di esso per aggiungere al tuo set di abilità generale. (ma un sapore di questo "Scrum-ban" è probabilmente quello che stai cercando ...)

Scrum è un buon framework, ma un principio base è "Iterations (Sprint) deve avere una durata fissa" Non ho mai visto questo lavoro in team molto piccoli che sono più guidati da interrupt. Se puoi davvero iscriverti e impegnarti a lavorare in un intervallo di tempo prefissato (1 settimana?), Allora Scrum è una struttura interessante. Se non puoi ... allora Scrum è bello da imparare perché ha dei buoni concetti che si traducono bene in altre cose ... come ....

Backlog - Scrum o no, mantieni un elenco di cose prioritarie che devi fare. Mi piace Excel (o un foglio di calcolo di Google Documenti ...) Potrebbe piacerti qualcos'altro. Manterrei uno strumento molto piccolo se sei una squadra molto piccola. (Spreadsheet > > Processore di testi perché puoi ordinare facilmente.)

Separazione della pianificazione e dell'impegno - Pianifica in una notazione astratta (punti) ed essere coerenti (8pts è circa 2x a 4 pt story e 4x a 2 punti story) Quando il tempo di "fare il lavoro" rivedere il problema e disegnalo in ore. Non cambiare i punti.

Impegno: essere visibili agli altri quando si impegnano e rispettare i propri impegni

Retrospettiva: dopo che hai consegnato, rifletti su cosa avrebbe potuto essere fatto meglio.

etc etc.

Scrum è abbastanza facile da capire che potrebbe essere un buon punto di partenza. Se ti piace, prenderei in considerazione l'uso della variante "Scrum-ban" - link . Nient'altro mi sembra "così ben documentato" con una comunità abbastanza attiva da sostenerlo.

Mi piacerebbe anche raccomandare le metodologie Crystal di Alistair Cockburn (http://alistair.cockburn.us/Crystal+methodologies+main+foyer e link ), ma richiede molto più lettura e scavo.

Cose come XP forniscono maggiori dettagli su pratiche specifiche, quindi direi anche di leggere il libro: link

Consigli per la lettura finale: purché tu accetti il manifesto di Agile e segui i principi: link dovresti essere in posizione decente forma.

Raccomandazione personale:     Adottare TDD (non negoziabile, IMHO)     Mantenere un arretrato (come da Scrum)         Tenerlo sempre dimensionato e ordinato in base alla priorità         Decompone le cose "troppo grandi per fare tra le interruzioni" int pezzi più piccoli         Chiedi a qualcun altro di impostare / rivedere la priorità (non ci sono mai due elementi che hanno sempre la stessa priorità.)     Rendi il tuo ambiente di sviluppo in grado di creare / test / distribuire (in lab env) in 5-10 minuti     Mostra ai tuoi clienti (interni ed esterni) i risultati di una storia         La storia non è fatta fino a quando il tuo cliente non è d'accordo.     Tirare Storie dalla cima della pila e lavorarci sopra mentre completi la storia attuale     Non tenere aperte più di 2 cose alla volta.         Finisci una distrazione prima di iniziarne un'altra.     Sii orgoglioso del tuo lavoro e una volta al mese mostra al team / azienda tutti i prodotti / funzioni che hai completato.

spero che questo aiuti

Puoi usare alcune pratiche usate in Scrum come backlog di prodotto, prioritizzazione, stima relativa, consegna incrementale ma usare l'intero Scrum come un processo per gestire lo sviluppo del prodotto da parte di un team di membri funzionali incrociati auto-organizzati non è probabilmente un modo per one man show.

La domanda è se sei in grado di suddividere i tuoi articoli di lavoro in piccoli pezzi che possono essere consegnati in modo incrementale? Se non si utilizza la maggior parte delle pratiche non ha senso. Scrum riguarda anche l'elevata collaborazione con il proprietario / cliente del prodotto. Non dovrebbe essere come: "Qui hai un compito e torna indietro una volta fatto".

Mentre non dirò nulla a favore o contro Srum di 1 uomo, dirò che un sistema di tiro Kanban a 1 uomo funziona molto bene. Il kanban combinato con i test unitari automatizzati mi ha reso molto più produttivo e "documentato". Anche se nessuno dei due è davvero una metodologia, ma più strumenti (e molto diversi), entrambi mi costringono a scomporre grandi progetti da solista in pezzi di piccole dimensioni, oltre a darmi una sorta di rituale per incoraggiarmi a fare più cose ogni giorno. Non c'è nulla di così soddisfacente come fare clic su "Esegui tutti i test" e vedere ogni oggetto diventare verde ... tranne che prendere una carta dalla colonna "In corso" sulla mia scheda Kanban su "In test" (o completamente fuori bordo) .

Penso che il vero problema con il lavoro da solista sia che hai scelto e scelto tra più metodologie, che sono davvero pensate per gruppi di sviluppatori, e le personalizziamo per adattarti al meglio. L'obiettivo finale è in realtà solo per renderti responsabile, produttivo e felice. Chi lo sa fare meglio di te stesso (con un po 'tirato da qui e un po' da lì).

Ho provato questo quando stavo lavorando da solo a un certo punto. Le cose che hanno funzionato bene sono state:

1. Avere tutti gli elementi di lavoro su una lavagna. Potevo vedere molto rapidamente quale eccezionale lavoro ci fosse; dove erano dipendenze e blocchi. Inoltre, un sacco di persone si fermavano dal mio forum e lo leggevano - e avremmo parlato di questo. Penso che li abbia aiutati a capire cosa "il geek" stava facendo tutto il giorno; -)
2. Anche il grafico di burn-down è stato ottimo. Ho appena usato Excel per questo. Mi ha permesso di migliorare le stime in quell'ambiente. Mi ha dato una grande panoramica di dove stavo andando con l'iterazione. Anche il mio manager, che non era una persona tecnica, amava questo dato che vedeva tutte le diverse cose coinvolte in una funzione e dove si trovavano.
3. Costumi giornalieri. Bene come meglio potrei. Ogni mattina aggiornavo tutti gli oggetti di lavoro e il grafico di burn-down e prendevo nota di tutti gli impedimenti che dovevano essere risolti.
4. Test automatizzati e integrazione continua (MSTest / TFS), preferibilmente TDD, aiuteranno qualsiasi team di sviluppo, utilizzando qualsiasi metodologia, ma vale la pena menzionarlo qui.
5. Le iterazioni brevi (1 settimana) mi hanno davvero aiutato a concentrarmi sulla consegna di qualcosa.
6. Il mantenimento di un arretrato è stato ottimo, in quanto quando mi è stato dato un nuovo lavoro, sono riuscito a inserirlo nel contesto di tutti gli altri lavori e a dare la priorità al proprietario del prodotto.

Ciò che non ha funzionato è stato:

1. Lavorando da solo, non si ottiene mai la spinta dalla collaborazione con persone che la pensano come te; o quel senso di competizione e attenzione che viene da una squadra con un morale e una cultura davvero fantastici. Non ci sono altri cervelli da afferrare quando rimani bloccato, quindi blocchi di questo tipo non possono essere eliminati da uno scrum master nella situazione quotidiana.
2. Non esiste un supervisore di mischia, quindi non c'è nessuno che interrompa le interruzioni. Ho avuto molti problemi con le persone che facevano continuamente domande su altre cose e rompevano il mio flusso. Sotto un buon controllore, cose del genere vengono intercettate e tu puoi andare avanti. Non ho mai voluto essere scortese con le persone (forse sono tenero) quindi è stato un problema. Inoltre, senza uno Scrum Master puoi tranquillamente allontanarti facilmente dal processo.

È stato un esercizio interessante, ma ho smesso di farlo dopo un po '. Penso che i benefici di Scrum dovrebbero essere visti in contrasto con i tradizionali team di cascata. Ma entrambi sono in qualche modo discutibili quando sei da solo. Non ci sono problemi di comunicazione o collaborazione: ti limiti a svolgere il lavoro impostato e hai finito.

Penso che tutti dovrebbero tenere un backlog e fare TDD però.

Elementi di Agile / Scrum / Kanban che penso abbiano un senso in un unico mondo di sviluppatori:

1. Avere una bacheca su cui organizzi il tuo utente stories / active-backlog-items, on schede, come kanban.

2. Ottieni il buy-in dai non sviluppatori sul valore di questi principi:

   • Concedimi il tempo di lavorare senza modificare le mie priorità su di me o il micromanaging (il punto degli sprint). Dammi tempo e proverò a capire in anticipo esattamente quanto posso fare, e farò del mio meglio per fare così tanto.

   • Se ho bisogno di qualcosa (mi blocco), e vengo da te, e non puoi ordinarlo per me, allora lo sprint potrebbe dover essere annullato in modo anomalo. (Questo significa che abbiamo bisogno di un nuovo piano.)

   • Nessuno cambia nulla nel mezzo dello sprint. Oppure, se lo facciamo, cancelliamo semplicemente lo sprint e ne creiamo uno nuovo. se questo accade molto, la produttività diminuisce.

   • la comunicazione tra persone che sono portatori di interesse può avvenire durante regolari riunioni di stand-up quotidiane, che comunicano la maggior parte delle stesse cose di una normale mischia, compresi i risultati degli sviluppatori per quel giorno. In sostanza, puoi segnalare le cose che hanno richiesto più tempo di quanto pensavi, o sono andate bene, e qualsiasi aggiustamento che stai apportando ai tuoi piani di implementazione. (Ho trovato quattro nuovi bug e li ho registrati, penso che siano più importanti di questa caratteristica opzionale, e quindi penso che passerò il tempo e li sistemerò e spingerò fuori questa funzionalità opzionale.)

Ho lavorato molto come singolo sviluppatore, e posso dire con certezza che la fiducia tra il singolo sviluppatore e i suoi supervisori / capi non sviluppatori e una buona comunicazione sono le chiavi, non una metodologia. Ma puoi sempre essere più efficace se segui i buoni principi.

Ho letto alcuni blog su questo e penso che possa aiutarti con la tua domanda.

Prima parte: link

Seconda parte: link

Potresti trovare ulteriori informazioni su questo blog.

Non sono collegato in alcun modo; solo qualcosa che avevo tra i miei preferiti. Spero che possa aiutarti.

Sì. E tieni presente che lo Scrum non deve coinvolgere strumenti di fantasia, può essere solo una semplice riunione stand-up di 15 minuti in cui tutti parlano di ciò su cui stanno lavorando. Il vantaggio di Scrum è che tutti sanno cosa sta succedendo e questo rende più facile risolvere i problemi prima che si presentino e anticipare i problemi lungo la strada.

Molte di queste risposte mancano di un punto importante.

Un team di mischia non ha bisogno di consistere esclusivamente di programmatori.

Uno dei tuoi colleghi "progetta" / "sviluppa" e uno "vendita".

Forse il tuo collega "di vendita" può essere il proprietario di un prodotto (proxy). Quali sono le aspettative del cliente?

Il design e lo sviluppo dell'altro collega mi sembrano davvero delle discipline per la squadra di scrum. Lo sviluppo della mischia non è graduale ma verticale (elimina i requisiti, progetta e implementa in uno sprint).

Potresti fare il processo di mischia con tutti e tre.

Che cosa serve per ottenere questo? Le riunioni di pianificazione dello sprint di Scrum ingrandiscono la domanda su che cos'è questo. Cosa si aspetta di vedere dal proprietario del prodotto perché venga considerato eseguito?

Durante una riunione di pianificazione dello sprint, puoi dare al tuo contesto di altri colleghi il motivo per cui "internazionalizzare e localizzare il prodotto" potrebbe essere tecnicamente difficile da implementare.

Tantissime ragioni per usare scrum imho.

Suggerirei di provare Kanban e partire dalle basi: visualizzazione e limitazione del work-in-progress (WIP).

Anche se lo interrompi più tardi, diventerai più agile nel processo. E mentre Kanban è buono per lo sviluppo di software "normale", Kanban + un processo basato sul flusso (al contrario delle iterazioni) mette in ombra altri strumenti di processo quando si ha una situazione con lo sviluppo di nuove funzionalità e manutenzione.

Seguo la raccomandazione del libro Kanban di David Anderson, e puoi anche dare un'occhiata alle mie diapositive da un meetup locale su perché e come iniziare con il semplice Kanban , o crisp.se/kanban per una breve introduzione.

Per il tuo contesto ho qualche idea:

• visibilità è la chiave, quindi usa una lavagna fisica piuttosto che uno strumento digitale se non è possibile visualizzarlo su uno schermo (grande) in modo permanente (se sei collocato)
• inizia con il tuo processo attuale
• inizia solo con la tua sfera di influenza, incluse le fasi di handoff offstream e downstrean (diventando coda per te, ad esempio, funzioni progettate pronte per lo sviluppo o coda da te, ad esempio, funzioni finite, pronte per la vendita)
• se i tuoi colleghi sono interessati ad espandere la visualizzazione a monte oa valle, tanto meglio. Forse finirai per visualizzare l'intero flusso di valore (o rete) per la tua azienda, cioè come il valore passa dal concetto al denaro
• minimizza il multitasking (!) limitando il WIP. Se il flusso di lavoro è visibile ai tuoi colleghi, dovrebbero capire perché e vedere facilmente cosa c'è nel tuo piatto
• forse sarà utile separare il lavoro in 3 o 4 tipi di lavoro (classi di servizio), che hanno diverse esigenze su di loro: f.ex. bug, problemi critici, lavoro con scadenze rigide, lavoro senza scadenze
• osserva come fluisce il tuo lavoro, ad es. se tieni i colli di bottiglia da qualche parte, o il lavoro è bloccato o sei "affamato" per lavorare in modelli alquanto prevedibili. Questo è più facile a lungo termine se si utilizza uno strumento digitale, ref alcune delle mie ultime diapositive.
• migliorare il flusso del lavoro passo dopo passo

Se vuoi provare qualcosa in questo momento, oggi, mentre prendi la tua decisione, ti consiglio di provare un kanban personale sul muro o sulla finestra o armadio accanto a te, come ho fatto la scorsa settimana ...

Dopo aver letto tutte le altre risposte qui, penso che la semplice risposta pragmatica sia:

Utilizza processi o tecniche o metodi che sono in uso per APPRENDERE qualcosa che ti aiuterà a fare meglio il tuo lavoro.

Ora questo potrebbe significare dare priorità ai tuoi compiti - ogni giorno - religiosamente.

Potrebbe significare elaborare il backlog.

Potrebbe significare riportare progressi - al tuo capo (anche se non gliene importa ... farlo è una buona cosa permettere mentalmente a TE di fare il punto su dove ti trovi).

Potresti usare tutti i tipi di metodi o tecniche perché alla fine ti consentono di lavorare meglio, che = dormire meglio di notte.

Fai cose che funzionano (per te, nelle circostanze attuali), scarta cose che non lo sono.

A meno che tu non abbia il seguente posto

• Strumenti per organizzare e stabilire la priorità dei requisiti in arrivo.

• Per stimare con precisione lo sforzo che verrà intrapreso in modo che tu sappia cosa puoi impegnare in una iterazione

• Iterazioni e miglioramento continuo - Il concetto di iterazioni in cui si effettuano continue ispezioni e adattamenti è inestimabile. Questa pratica incoraggia la sperimentazione e si sviluppa in un apprendimento continuo. Scrum in Church, pagina 4

• Bene, non puoi fare una riunione giornaliera di scrum, ma almeno puoi ricordarti dell'attività che ti impegni oggi. Il daily scrum meeting viene utilizzato in modo che le squadre possano sincronizzarsi reciprocamente su quello che stanno facendo.

• Riflessione dopo uno sprint - in scrum si chiama Sprint Retrospective, alla fine di ogni iterazione, puoi riflettere su cosa succede dopo l'iterazione, e pensare a cosa è andato storto e come puoi migliorarlo, cosa sono la migliore pratica per mantenerli facendo

Suggerirei di adottare un approccio minimalista e, migliorando continuamente, puoi avere una mischia che si adatta bene alle tue esigenze.

Mischia non è mischia se non la si adatta alle tue esigenze e si adatta alla tua situazione attuale.