Strumenti e pratiche indispensabili per una start-up agile [chiusa]

Strumenti

Avrai sicuramente bisogno del controllo del codice sorgente . Preferibilmente uno che include un'interfaccia web in modo che ogni giorno puoi iniziare a vedere ciò che le persone hanno registrato di recente.

Avrai bisogno di uno spazio di squadra dove i tuoi sviluppatori, QA e proprietari di prodotti possono collaborare per fornire un prodotto.

Avrai bisogno di un server di integrazione continua in modo da eseguire costantemente test sul tuo software.

Avrai bisogno di un framework di automazione di qualche tipo, che ti permetta di scrivere facilmente test di accettazione automatici. Non deve essere elegante e potrebbe essere costruito sopra i vari framework * dell'unità, ma è necessario qualcosa .

Hai bisogno di una wiki del team . Molti sistemi di controllo del codice sorgente ne hanno uno. Hai bisogno di un modo semplice e veloce per creare documentazione interna.

Hai bisogno di un tracker dei problemi . Molti sistemi di controllo del codice sorgente includono anche uno di questi. Hai bisogno di un modo per tenere traccia dei difetti. Puoi usare note adesive su una lavagna se sei bravo a mantenere il numero di bug al minimo. Prendi in considerazione la possibilità di scegliere un wiki integrato, un tracker di problemi e un sistema di controllo del codice sorgente in uno.

Attrezzatura

Avrai bisogno delle lavagne bianche e delle note adesive . Ci sono molte opinioni su questo, ma nella mia esperienza niente funziona meglio delle schede fisiche e delle story card. È possibile utilizzare un tabellone elettronico, ovviamente, e in definitiva si riduce a ciò che funziona meglio per la tua squadra.

Procedure

Dovresti iniziare seguendo tutti i rituali di scrum . Questo non vuol dire che siano i migliori, ma prima di poter correre devi camminare. Inizia con due settimane di sprint, fai i tuoi standup ogni giorno, le tue retrospettive e le tue demo ogni due settimane. Sii religioso, finché arriva il momento in cui puoi decidere cosa funziona per la tua squadra e cosa no.

Devi costruire il tuo software sin dal primo giorno per essere costruibile in un unico passaggio ed essere in grado di essere automaticamente implementato . Non vuoi che il tuo team di sviluppo debba dedicare del tempo a costruire o installare manualmente il software in ogni momento. Queste caratteristiche sono quasi impossibili da aggiungere dopo il fatto, deve essere parte della cultura fin dal primo giorno.

Ruoli

Hai bisogno di un proprietario del prodotto . Questa è la persona che si trova a cavallo tra il cliente e il team di sviluppo. Dovrebbero essere abbastanza tecnici da avere conversazioni significative con il team di sviluppo, ma devono anche conoscere lo spazio del prodotto ed essere in grado di parlare in modo intelligente con i clienti.

Avrai bisogno degli sviluppatori . Idealmente questi saranno dedicati al 100% alla creazione del prodotto. Uno sviluppatore non dovrebbe anche essere un proprietario del prodotto, uno scrum master o un manager.

Avrai bisogno degli sviluppatori QA . Queste persone sono l'avvocato del cliente. Sono responsabili per guidare il team verso lo sviluppo di software di alta qualità. Non sono solo dei tester, lavorano con il team per capire cosa si sta sviluppando e aiutano il team a creare software testabile. Idealmente queste persone sono sviluppatori di software che hanno una passione per i test, dal momento che gran parte del ruolo dovrebbe includere la scrittura di test automatici e il mantenimento del framework di test.

Opzionalmente, sarebbe bello avere un master di misfatti dedicato . Il loro compito è quello di concentrarsi sulla produttività della squadra, piuttosto che sul prodotto in costruzione. Avere qualcuno in quel ruolo aiuterà la squadra a riunirsi e lavorare al massimo.

Cultura

Soprattutto, è necessario creare una cultura che comprenda che lo sviluppo del software riguarda esclusivamente il cliente . Nessuno acquisterà il tuo software perché desidera utilizzare il tuo software, a meno che tu non stia creando un gioco. Invece, usano il tuo software per svolgere qualche altra attività. Il tuo compito è consegnare un software che faciliti il completamento di questi compiti.

Devi promuovere una cultura della comunicazione e una in cui la qualità del software ha la massima priorità. Ciò significa che ogni storia è completamente testata prima di passare a quella successiva. L'idea di provare qualcosa in uno sprint finale deve semplicemente essere inaccettabile per tutti i membri del team.

Infine, hai bisogno di una cultura che valuti una settimana lavorativa di 40 ore . Mentre un atteggiamento positivo è importante, e le persone devono essere disposte a rimboccarsi le maniche e lavorare di più in alcune occasioni, quelle ore extra devono essere l'eccezione piuttosto che la regola. Lo sviluppo del software è in gran parte un compito creativo e non puoi essere creativo quando sei sovraccarico di lavoro. I membri del team felici sono membri del team produttivo.

Anche se non discuterò con nessuno dei suggerimenti che @BryanOakley ha già esposto, vorrei sottolineare che alla fine gli strumenti non contano davvero. Ciò che conta sono le persone che hai lavorato al progetto.

Ogni membro del team ha bisogno, prima di tutto, di essere un buon comunicatore. Devono essere in grado di parlare con i clienti - e l'altro - e per capire cosa si deve fare e consentire agli altri di capire cosa si sta facendo. Se la comunicazione è lì, sei l'80% del modo per essere agile.

L'altro 20% è che ogni membro della squadra deve essere in grado di raccogliere qualunque palla atterra di fronte a loro e correre con essa. Se qualcuno ha "tempi di inattività", dovrebbe cercare automaticamente di vedere come possono aiutare gli altri membri.

Alistair Cockburn definisce lo sviluppo agile del software "il gioco cooperativo" per una ragione - si tratta di persone che collaborano per ottenere qualcosa di grande. "Individui e interazioni su processi e strumenti" è il primo valore dello sviluppo Agile.

Penso che non ci sia una risposta chiara ma qui ci sono alcuni pensieri:

• Processo: All'inizio, molto probabilmente la dimensione del team è così piccola (< = 3 sviluppatori) che non è necessario un processo ben calibrato come SCRUM. Diventerà più importante se avrai successo e crescerai, ma all'inizio non lo considererei fondamentale.

• Strumenti: dipende dal desiderio che vuoi fare e dalle tue esperienze. Le startup non hanno codice legacy, quindi in genere possono utilizzare tecnologie più recenti. (Chissà cosa succederà nel prossimo anno. Una volta che era Rails, ora sembra essere NodeJS.)

  Quando si parla di linguaggi di programmazione, l'unica raccomandazione sicura è valutare la produttività rispetto alle prestazioni (ad es. Ruby, Python, Javascript / coffescript invece di Java o C ++).

• Esercitazioni: dovresti cercare di ottenere la massima automazione possibile. Ne avrai comunque bisogno in seguito e ti aiuterà fin dall'inizio. I test automatici sono un must e la configurazione e la distribuzione dell'applicativo dovrebbero essere facili. Metti i tuoi file di configurazione sotto controllo di versione, non solo il tuo codice sorgente. Strumenti di gestione della configurazione possono anche aiutare (ad esempio, Puppet , Chef ).