Mischia per un singolo programmatore? [chiuso]

Sono stato definito "esperto di Windows" nella mia piccolissima azienda, che consiste in me stesso, un ingegnere meccanico che svolge un ruolo di vendita e formazione e il presidente della società, che lavora in un ruolo di progettazione, sviluppo e supporto.

Il mio ruolo è altrettanto generale, ma principalmente progetto e realizzo qualsiasi programmazione sul nostro prodotto debba essere eseguita affinché le nostre cose possano essere eseguite su qualsiasi versione di Windows sia attuale.

Ho appena finito di guardare una panoramica di alto livello del paradigma Scrum, fornita in un webcast. La mia domanda è: vale la pena dedicare del tempo a saperne di più su questo approccio allo sviluppo del prodotto, dato che i miei lavori di sviluppo vengono generalmente forniti a un livello molto alto, come "internazionalizzare e localizzare il prodotto".

Se lo è, come suggeriresti di adattare Scrum per l'uso di un solo programmatore? Quali strumenti, basati su cloud o altro, sarebbero utili a tal fine?

In caso contrario, quale approccio suggeriresti a un singolo programmatore di organizzare i suoi sforzi di giorno in giorno? (Forse la domanda si riduce a quella semplice domanda.)

Impara Scrum: si. Se non altro per conoscerlo da aggiungere al tuo set di abilità generale. (ma un sapore di questo "Scrum-ban" è probabilmente quello che stai cercando ...)

Scrum è un bel framework, ma un principio fondamentale è "Le iterazioni (Sprint) devono essere di durata fissa" Non ho mai visto questo lavoro in team molto piccoli che sono più guidati dagli interrupt che no. Se puoi davvero iscriverti e impegnarti a lavorare in un intervallo di tempo fisso (1 settimana?), Scrum è un fantastico framework. Se non puoi ... allora Scrum è bello da imparare perché ha alcuni buoni concetti che si traducono bene in altre cose ... come ...

Backlog - Scrum o no, mantieni un elenco prioritario di cose che devi fare. Mi piace Excel (o Google Doc Spreadsheet ...) Potrebbe piacere qualcos'altro. Terrei uno strumento molto piccolo se sei una squadra molto piccola. (Foglio di calcolo >> Elaboratore di testi perché puoi ordinare facilmente.)

Separazione di pianificazione e impegno - Pianificare in una notazione astratta (punti) ed essere coerenti (8 punti è circa 2 volte una storia 4 volte e 4 volte una storia 2 punti) Quando è il momento di "fare il lavoro" riesaminare il problema e disegnarlo tra ore. Non cambiare i punti.

Impegno: sii visibile agli altri quando ti impegni e rispetta i tuoi impegni

Retrospettiva: dopo aver effettuato la consegna, rifletti su cosa avrebbe potuto essere fatto meglio.

ecc ecc.

Scrum è abbastanza facile da capire che potrebbe essere un buon punto di partenza. Se ti piace, prenderei in considerazione l'utilizzo della variante "Scrum-ban" - http://en.wikipedia.org/wiki/Scrum-ban#Scrum-ban . Nient'altro mi sembra "così ben documentato" con una comunità ragionevolmente attiva a sostenerlo.

Mi piacerebbe anche consigliare le metodologie Crystal di Alistair Cockburn (http://alistair.cockburn.us/Crystal+methodologies+main+foyer e http://www.amazon.com/Crystal-Clear-Human-Powered-Methodology- Piccolo / dp / 0201699478 / ref = ntt_at_ep_dpt_3 ), ma comporta molta più lettura e scavo.

Cose come XP forniscono maggiori dettagli su pratiche specifiche, quindi direi anche di leggere il libro: http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/ref=sr_1_1?s= libri & ie = UTF8 & qid = 1.304.359,834 mila & sr = 1-1

Consiglio di lettura finale: fintanto che accetti il ​​manifesto Agile e segui i principi: http://agilemanifesto.org/principles.html dovresti essere in buona forma.

Raccomandazione personale: Adotta TDD (non negoziabile, IMHO) Mantieni un backlog (come da Scrum) Mantienilo sempre in ordine e ordinato in base alla priorità Decomponi le cose "troppo grandi da fare tra interruzioni" in blocchi più piccoli Chiedi a qualcun altro di impostare / rivedere la priorità (no due elementi hanno la stessa priorità. mai.) Rendi il tuo ambiente di costruzione in grado di costruire / testare / distribuire (in laboratorio) in 5-10 minuti Mostra ai tuoi clienti (interni ed esterni) i risultati del completamento di una storia La storia non è finita fino a il tuo cliente è d'accordo. Estrai le storie dalla cima della pila e lavoraci su mentre completi la storia attuale Non tenere aperte più di 2 cose contemporaneamente. Termina una distrazione prima di iniziarne un'altra.

spero che sia di aiuto

È possibile utilizzare alcune pratiche utilizzate in Scrum come backlog del prodotto, definizione delle priorità, stima relativa, consegna incrementale, ma l'utilizzo di Scrum intero come processo per la gestione dello sviluppo del prodotto da parte di un team di membri interfunzionali auto organizzati non è probabilmente il modo di andare per uno spettacolo personale .

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

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

Penso che il vero problema con lavorare da soli, sia che tu scelga e scegli tra più metodologie, che sono pensate per gruppi di sviluppatori, e lo adattano al meglio per te. L'obiettivo finale è proprio quello di renderti responsabile, produttivo e felice. Chissà come farlo meglio di te (con un po 'tirato da qui e un po' da lì).

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

1. Avere tutti gli oggetti di lavoro su una lavagna. Ho potuto vedere molto rapidamente che lavoro eccezionale c'era; dove dipendenze e blocchi erano. Inoltre, molte persone si fermano vicino alla mia bacheca e lo leggono - e ne faremmo una chiacchierata. Penso che li abbia aiutati a capire cosa facesse "il geek" tutto il giorno ;-)
2. Anche il grafico del burn-down è stato ottimo. Ho appena usato Excel per questo. Mi ha permesso di migliorare nel fare stime in quell'ambiente. Mi ha dato un'ottima panoramica di dove stavo andando con l'iterazione. Anche la mia manager, che non era una persona tecnica, ha adorato questo in quanto ha potuto vedere tutte le diverse cose coinvolte in una funzione e dove si trovavano.
3. Stand up giornalieri. Bene come ho potuto. Ogni mattina ho aggiornato tutti gli elementi di lavoro e la tabella di burn-down e ho preso nota di tutti gli impedimenti che dovevano essere risolti.
4. I test automatizzati e l'integrazione continua (MSTest / TFS), preferibilmente TDD, aiuteranno qualsiasi team di sviluppo, utilizzando qualsiasi metodologia - ma vale la pena menzionare qui.
5. Brevi iterazioni (1 settimana) mi hanno davvero aiutato a concentrarmi sulla consegna di qualcosa.
6. Mantenere un backlog è stato grandioso poiché quando mi è stato dato un nuovo lavoro sono stato in grado di inserirlo nel contesto di tutti gli altri lavori e di dare la priorità al proprietario del prodotto.

Ciò che non ha funzionato è stato:

1. Lavorando da soli, non si ottiene mai quella spinta dalla collaborazione con persone affini; o quel senso di competizione e concentrazione che proviene da una squadra con un morale e una cultura davvero grandiosi. Non ci sono altri cervelli da scegliere quando rimani bloccato, quindi blocchi come quello non possono essere eliminati da uno scrum master in piedi ogni giorno.
2. Non c'è scrum master - quindi non c'è nessuno che possa fermare le interruzioni. Ho avuto molti problemi con le persone che facevano costantemente domande su altre cose e interrompevano il mio flusso. Sotto un buon maestro di mischia, cose del genere vengono intercettate e puoi andare avanti. Non ho mai voluto essere scortese con le persone (forse sono morbido) quindi era un problema. Inoltre, senza uno Scrum Master puoi facilmente abbandonare il processo.

È stato un esercizio interessante, ma dopo un po 'ho smesso di farlo. Penso che i benefici di Scrum dovrebbero essere visti in contrasto con le tradizionali squadre a cascata. Ma entrambi sono un po 'discutibili quando sei da solo. Non ci sono problemi di comunicazione o collaborazione: ti basta analizzare il lavoro impostato e il gioco è fatto.

Penso che tutti dovrebbero tenere un registro, e comunque fare TDD.

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

1. Avere una bacheca su cui organizzare le storie utente / gli oggetti backlog attivi, su schede, come kanban.

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

   • Dammi il tempo di lavorare senza cambiare le mie priorità su di me o il microgestione (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 (vengo bloccato), e vengo da te, e non puoi ordinarlo per me, allora lo sprint potrebbe dover essere annullato in modo anomalo. (Ciò significa solo che abbiamo bisogno di un nuovo piano.)

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

   • la comunicazione tra le persone che sono parti interessate può avvenire durante le normali riunioni di stand-up giornaliere, che comunicano la maggior parte delle stesse cose di una normale mischia, compresi i risultati degli sviluppatori per la giornata. In sostanza, puoi segnalare cose che hanno richiesto più tempo del previsto o sono andate bene e tutte le modifiche che stai apportando ai tuoi piani di implementazione. (Ho trovato quattro nuovi bug e li ho registrati, penso che siano più importanti di questa funzione opzionale, e quindi sto pensando che passerò il tempo, li aggiusterò e distribuirò questa funzione opzionale.)

Ho lavorato molto come singolo sviluppatore e posso dire con certezza che la chiave tra le chiavi, non una metodologia, è la fiducia tra il singolo sviluppatore e i suoi supervisori / capi non sviluppatori e una buona comunicazione. 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: http://www.21apps.com/agile/doing-agile-in-a-team-of-one/

Seconda parte: http://www.21apps.com/agile/doing-agile-in-a-team-of-one-day2/

Potresti trovare qualche informazione in più su questo blog.

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

Sì. E tieni presente che Scrum non deve coinvolgere strumenti fantasiosi, può essere solo una semplice riunione di 15 minuti in cui tutti parlano di ciò su cui stanno lavorando. Il vantaggio di Scrum è che tutti sanno cosa sta succedendo e ciò rende più semplice risolvere i problemi prima che si presentino e anticiparli.

Molte di queste risposte mancano di un punto importante.

Una squadra di mischia non deve necessariamente essere composta da programmatori.

Uno dei tuoi colleghi fa "progettazione" / "sviluppo" e uno "vendite".

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

Il design e lo sviluppo dell'altro collega mi sembrano davvero delle discipline del team di mischia. Lo sviluppo della mischia non è graduale ma verticale (appianare i requisiti, progettare e implementare in uno sprint).

Potresti fare il processo di mischia con voi tre.

Cosa ci vuole per fare 'questo'? Le riunioni di pianificazione dello sprint di Scrum si concentrano sulla domanda che cos'è questo. Cosa si aspetta il proprietario del prodotto di vederlo considerato fatto?

Durante una riunione di pianificazione dello sprint è possibile fornire agli altri colleghi un contesto sul perché "internazionalizzare e localizzare il prodotto" potrebbe essere tecnicamente difficile da implementare.

Tante ragioni per usare scrum imho.

Suggerirei di provare Kanban e di iniziare con le basi: visualizzazione e limitazione del work-in-progress (WIP).

Anche se lo interrompi in un secondo momento, 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) supera gli altri strumenti di processo quando si ha una situazione con lo sviluppo di nuove funzionalità e la manutenzione.

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

Per il tuo contesto ho alcuni pensieri:

• visibilità è la chiave, quindi preferisci usare una lavagna fisica piuttosto che uno strumento digitale se non riesci a mostrarla permanentemente su uno schermo (grande) (se ti trovi in ​​una posizione condivisa)
• iniziare con il processo attuale
• inizia solo con la tua sfera di influenza, comprese le fasi di hand-off downstream e downstrean (diventando una coda per te, ad es. funzionalità progettate pronte per gli sviluppatori o una coda da te, ad es. funzionalità finite, pronte per la vendita)
• se i tuoi colleghi sono interessati ad espandere la visualizzazione a monte o a valle, tanto meglio. Forse finirai per visualizzare l'intero flusso di valori (o rete) per la tua azienda, cioè come il valore fluisce dal concetto al denaro
• minimizzare il multitasking (!) limitando il WIP. Se il flusso di lavoro è visibile ai tuoi colleghi, dovrebbero capire il 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 esigenze diverse: f.ex. bug, criticità, lavoro con scadenze rigide, lavoro senza scadenze
• osserva come scorre il tuo lavoro, ad esempio, se hai qualche strozzatura da qualche parte, o se il lavoro è bloccato o sei "affamato" per lavorare in schemi piuttosto prevedibili. Questo è più facile a lungo termine se usi uno strumento digitale, fai riferimento ad alcune delle mie ultime diapositive.
• migliorare il flusso di lavoro passo dopo passo

Se vuoi provare qualcosa adesso, oggi, mentre prendi la tua decisione, ti consiglio di provare un kanban personale sul muro o sulla finestra o sull'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:

Usa processi o tecniche o metodi in uso per IMPARARE qualcosa che ti aiuterà a fare meglio il tuo lavoro.

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

Potrebbe voler dire elaborare il backlog.

Potrebbe significare riferire i progressi - al tuo capo (anche se non gli interessa ... farlo è una buona cosa permetterti mentalmente di fare il punto della tua posizione).

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

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

A meno che non si disponga di quanto segue

• Mezzi per organizzare e dare priorità ai requisiti in entrata.

• Per stimare con precisione lo sforzo che verrà fatto in modo da sapere cosa puoi impegnare in una iterazione

• Iterazioni e miglioramento continuo - Il concetto di iterazioni in cui si è continuamente ispezionati e adattati è inestimabile. Questa pratica incoraggia la sperimentazione e si basa sull'apprendimento continuo. Scrum in Church, pagina 4

• Bene, non puoi fare una riunione quotidiana di mischia, ma almeno puoi ricordare a te stesso il compito che ti impegnerai oggi. La riunione di mischia giornaliera viene utilizzata in modo che i team possano sincronizzarsi tra loro su ciò che stanno facendo.

• Riflessione dopo uno sprint: nella mischia si chiama Sprint Retrospective, alla fine di ogni iterazione, puoi riflettere su ciò che accade dopo l'iterazione e pensare a cosa è andato storto e come puoi migliorarlo, quali sono le migliori pratiche per mantenerli fare

Suggerirei di adottare un approccio minimalista e, attraverso il miglioramento continuo, puoi avere una mischia che si adatta bene alle tue esigenze.

Scrum non è mischia se non puoi adattarlo alle tue esigenze e adattarti alla tua situazione attuale.