eXtreme Programming e dintorni in salsa Team Nimbus

lunedì 25 settembre 2017


Alla nascita, una piccola azienda IT è generalmente costituita da poche persone che, con a disposizione solo il tempo e un pochino di hardware, cercano di trasformare un'idea in un successo commerciale.
In quelle prime fasi i lavoratori-fondatori sono molto affiatati e interagiscono molto, e per questo è comodo che condividano lo spazio. L'ufficio ideale è quindi costituito da una stanza nella quale trovano posto scrivanie e sedie a sufficienza per tutti.

Se davvero l'idea era buona e il successo arriva, il numero di persone generalmente aumenta e con esso aumentano le interferenze, molto spesso di natura acustica.
Quante volte ci capita di vedere che il lavoro di qualcuno (es. elemento del customer care che parla al telefono con un cliente) è disturbato dal lavoro di qualcun altro (es. sviluppatori che discutono ad alta voce di un problema)? In questi casi è importante trovare una soluzione che consenta a tutti di lavorare nel modo più efficiente possibile.

La soluzione "tradizionale", se vogliamo la preferita dal manager vecchio stampo, è quella di separare i lavoratori in spazi singoli (uffici, se sono sufficientemente importanti, altrimenti cubicoli). Esistono addirittura dei comodi "schermi divisori per scrivania" che uniscono il bello dei cubicoli alla semplicità di riconfigurazione delle scrivanie.


Certamente si tratta di un approccio che risolve il problema originale. Si vengono tuttavia a creare nuovi problemi, che generalmente sono sottovalutati dal manager di cui sopra:
  • le persone risultano essere isolate anche dai collaboratori
  • si perde la possibilità di sentirsi "parte di un tutto"
Il primo problema è la madre di tutti i problemi aziendali: se le persone non si parlano, necessariamente si lavorerà male perché:
  • "non sapevo che si fosse deciso di fare così"
  • "non sapevo che per ottenere X si potesse fare Y, io ho sempre fatto Z e ci mettevo una vita"
  • "non avevo capito se ti serviva X o Y e non sapevo come fare per chiedertelo"
eccetera eccetera, ad nauseam.

Il secondo problema è forse anche peggiore. Se le persone non si sentono parte del gruppo ma solo ingranaggi dell'azienda, nessuno si impegnerà per migliorare le cose. Tutto tenderà a mantenersi allo status quo "per inerzia".
Ovviamente il manager, che la sa lunga, non è affatto contento di questo e spingerà affinché le persone lavorino di più. Altrettanto ovviamente questo non farà altro che affossare ulteriormente il morale e aumentare i problemi nelle relazioni interpersonali (perché gli obiettivi dei singoli non saranno mai compatibili tra loro, e si creeranno tensioni perché le priorità di chi ha bisogno delle cose non saranno priorità per chi deve farle), che a loro volta ridurranno la propensione delle persone a parlarsi. Di nuovo, ad nauseam.

Ok, lo ammetto, è facile parlar male dell'ipotetico manager. Però che alternative ci sono?

Ripensiamo al problema originale. Il rumore che disturba è fortemente legato al fatto che persone che fanno lavori "incompatibili" lavorano le une vicino alle altre.
Ottimo. Allora allontaniamole. Prendiamo un ufficio bello grande (anche se magari un po' più in periferia), mettiamo le persone che parlano al telefono (customer care) da una parte e quelle che parlano tanto tra di loro (sviluppatori) dall'altra. Nel mezzo mettiamo le persone che non parlano al telefono né passano troppo tempo discutendo tra loro. Niente pareti, niente divisori.


Non basta? Chi parla al telefono può mettere le cuffiette col microfono, così mentre parla gode dell'isolamento necessario per la conversazione.
Certo, dal punto di vista dell'inquinamento acustico le stanze separate sono difficili da battere. Però la possibilità di parlare facilmente, senza barriere fisiche, con i colleghi crea condizioni di collaborazione migliori, che portano immancabilmente a risultati migliori.
Per i meeting è comunque bene avere a disposizione sale riunioni, tanto per non disturbare eccessivamente gli altri. Magari con porte a vetri, che lasciano passare tanta luce e ci consentono di scoprire in quale riunione è stato imprigionato quel collega del quale avevamo bisogno (e, di rimbalzo, consentono a lui di scoprire che lo stiamo cercando).

E se poi la gente si distrae e inizia a sparare ca**ate invece di lavorare?

La necessità di mantenere i dipendenti concentrati sembra essere uno dei grandi crucci del management. Mai come in questi casi tanto sforzo è stato impiegato con effetti tanto negativi.
Le persone non riescono a rimanere concentrate full time. Questo è un fatto e vale per tutti. Alcune pratiche dello sviluppo agile (tipo la tecnica del pomodoro) ne prendono atto al punto di introdurre momenti di pausa pianificati nel processo.
Una certa quantità di svago è assolutamente positiva, consente alle persone di riprendere il lavoro con rinnovate energie invece di costringerle a trascinarsi in stato catatonico fino all'ora di uscita. Inoltre la possibilità di parlare serenamente con persone che non lavorano direttamente con noi crea ottime opportunità di scoprire cosa stanno facendo gli altri e, in cascata, opportunità per creare sinergie e/o sfruttare meglio le risorse a disposizione (ad esempio evitando di rifare un lavoro che altri hanno già fatto in un altro contesto).

Non sappiamo quante aziende abbiano capito che le persone lavorano meglio se possono farlo da coese invece che da separate. Qui in 7Pixel l'apertura è da sempre parte dell'azienda, anche negli spazi: l'unico periodo nel quale ci sono state stanze separate (per interi reparti, non per singole persone) è stato quello in cui il numero di persone era salito al punto da eccedere la capienza della singola stanza, e la nuova sede non era ancora pronta. Quello è anche stato l'unico periodo nel quale si è sofferta la presenza di barriere nell'interazione con i colleghi.
Ora che la nuova sede è una realtà consolidata, i principi dell'open space sono stati incorporati persino nell'architettura: in entrambe le ali dell'edificio il piano superiore è più stretto di quello sottostante ed appare un po' come un balcone, consentendo alle persone su piani diversi di parlarsi direttamente a mo' di Romeo e Giulietta. Nei miei 8 anni di collaborazione con 7Pixel, l'open space è indubbiamente stato un fattore determinante nel successo dei progetti.

E voi, lavorate in un ambiente aperto e collaborativo o siete costretti a portare metaforici paraocchi come foste metaforici cavalli da tiro?




La nascita di un'idea

Ho già scritto un articolo riguardo a come i Nimbus hanno affrontato nel tempo il tema del continuous improvement e in generale della formazione/studio.
Oggi vi vorrei parlare di come 7Pixel ha pensato ad un modo alternativo per organizzare un evento formativo per tutti i suoi devs e di come io l'ho vissuto nel mio ruolo di organizzatore.
Il 7 Settembre 2017 si è svolta infatti la prima edizione dello Spartan Hackathon: una maratona di programmazione lunga 24 ore che ha visto sfidarsi 5 team di sviluppo.
In 7Pixel, grazie anche al nostro reparto "Qualità del lavoro" ci siamo fatti alcune domande:
  • come invogliare tutti gli sviluppatori a fare formazione?
  • come promuovere forme alternative di formazione che non siano "solo" corsi o conferenze?
  • come rendere il miglioramento continuo più stimolante, divertente?
  • come rompere la routine delle giornate lavorative con qualcosa di utile e spassoso?
Lo Spartan Hackathon è stata la risposta a queste domande.

Di che cosa si tratta

#spartanhackathon
Lo Spartan Hackathon altro non è che una epica sfida di programmazione: viene dato un problema e ogni team ha come obiettivo quello di realizzare il miglior software che risolva la sfida assegnata.
Tutti gli elaborati sono valutati da una giuria di esperti (gli Efori) che ne assegna i voti in base ai risultati ottenuti, alla creatività della soluzione trovata e alla presentazione del software stesso.

Le regole d'ingaggio

Ogni partecipante deve avere il proprio device su cui sviluppare. E' ammesso l'uso di librerie esterne e di un dataset che viene fornito dai saggi.
La battaglia dura 24 ore consecutive, ci si può riposare e rifocillare a piacimento.
Il software prodotto deve rispettare l'output richiesto ed ogni battaglione al termine dell'avventura deve fare una breve presentazione di quanto fatto.

I plotoni

Ogni plotone è composto da 4 soldati scelti in modo da separare gli elementi dei normali team di sviluppo aziendali e di avere seniority diverse all'interno del gruppo.
La scelta dei gruppi è stata una parte sicuramente divertente ma complessa in quanto abbiamo cercato il più possibile di fare squadre "equilibrate".

La  battaglia

Leonida e gli Efori
Il giorno dell'Hackathon è partito con note di folclore e ironia che scimmiottavano il tema spartano dell'evento.
Non sono mancate personalità in costume come l'annunciatore (io) e gli efori (i Product Owner dei vari prodotti aziendali).
Dopo la formazione dei plotoni (e la distribuzione di bellissime t-shirt e braccialetti con colori diversi per ogni team) e l'annuncio del tema della sfida, la battaglia ha avuto inizio.
Ogni team era in un'isola di scrivanie separata, dopo una prima fase d'analisi nella quale non sono mancate domande chiarificatrici del problema dato, si è passati al concept delle soluzioni e alla realizzazione vera e propria.
Lo stack tecnologico era libero per cui ogni battaglione ha, dopo aver trovato un accordo, incominciato a vomitare codice per raggiungere l'ambita meta. Si sono visti software in Java, C#, PHP e Ruby.

La notte

Il giorno è trascorso velocemente e nella notte si sono incominciati a vedere i primi segni di ironico squilibrio.
L'atmosfera era molto rilassata e giocosa anche se l'impegno nel realizzare il progetto era sempre presente. 
Fra un pisolo e l'altro non sono mancati divertenti siparietti e atti di pura follia :)

Il responso degli Efori

I plotoni presentano agli Efori
Le ultime ore della sfida si sono consumate nell'impacchettare qualcosa che fosse giudicabile dagli efori, i quali al termine della gara hanno assistito alle varie presentazioni dei team proponendo alcuni input particolari per poter giudicare gli output del software.
Con la consueta ilarità si è quindi arrivati alla proclamazione del team vincitore che ha ricevuto come premio, oltre alla gloria, anche delle bellissime medagliette a forma di elmo spartano :)
Dopo aver osannato i vincitori e deriso gli sconfitti abbiamo anche fatto una breve retrospettiva della giornata, a botte di post-it abbiamo trovato cos'è andato bene, cosa male e cosa si può migliorare.
I vincitori

Cosa ci ha lasciato

Ci vediamo alla prossima edizione
Sicuramente è stata un'esperienza nuova, diversa dagli altri Hackathon ai quali avevo partecipato.
Una vera sfida nella sfida in cui oltre a dover produrre un buon risultato, ci si deve anche scontrare con la stanchezza della notte, con un team con il quale non si è abituati a lavorare, con delle scelte che non sempre sono condivise e con un tema che non si conosce.
Personalmente credo che siano state 24 ore ben riuscite, in cui ogni partecipante e organizzatore si è portato a casa qualcosa,
Io come organizzatore ho compreso la difficoltà di trovare un tema adatto a partecipanti con competenze e skill diverse, ho capito che per organizzare un evento come questo l'ingrediente principale è l'entusiasmo, ho compreso che non è possibile accontentare tutti ma che è possibile comunque farli divertire e che per far in modo di avere un buon numero di partecipanti bisogna essere molto pazienti ed insistenti.

Il futuro

Speriamo che quella che si è consumata sia solo la prima di tante edizioni della Spartan Hackathon, ci auguriamo anche che questo evento possa essere, con i dovuti aggiustamenti, aperto anche all'esterno di 7Pixel coinvolgendo diverse community e aziende.
Vi terremo informati :)




lunedì 31 luglio 2017



L'informatica è un mondo vasto e periglioso, e può capitare che gli eventi ci portino a dover gestire un sistema difficile, che nelle prossime righe sarà inteso come "un blob informe di codice che non conosce nessuno e porta avanti logiche complesse che non si devono rompere perché siamo online e abbiamo utilizzatori che non vogliamo scontentare". Whew.

In un mondo ideale la soluzione è semplice: riscriviamolo. D'altra parte i vecchi sviluppatori erano notoriamente dei fricchettoni buoni a nulla, e sicuramente il meglio che sono riusciti a fare è niente rispetto a quello che possiamo riuscire a fare noi. Certo, ci vorrà un po' di tempo, ma che problema c'è?

Di solito quando il Developer di turno discute la cosa col Business le cose vanno più o meno così:

D: Dobbiamo riscrivere X
B: Perché?
D: Perché funziona male ed è difficile da far evolvere, ci perdiamo sempre un sacco di tempo e metà delle volte che andiamo online rompiamo qualcosa
B: Scrivere X è costato un mucchio di soldi e funziona. Voi quanto ci mettereste a rifarlo?
D: Circa 6 mesi
B: Non possiamo tener fermo lo sviluppo così a lungo. Continuate a lavorare su X, se andate un po' più piano non importa.

E così va in fumo il sogno di un X 2.0 più facile e veloce da sviluppare.

Ma noi non siamo certo gente che si arrende, e visto che lavoriamo in un'azienda agile siamo anche liberi di inventarci soluzioni creative a problemi difficili. Si tratta solo di trovare una soluzione che:
  • consenta di sostituire il codice vecchio con codice nuovo
  • consenta di proseguire nello sviluppo senza (eccessivi) rallentamenti
La strategia che finora ci ha dato la massima soddisfazione può essere descritta come "sostituzione di un pezzo alla volta". In pratica l'idea è quella di cercare delle "linee" nel sistema legacy in modo da poterlo "tagliare" e sostituire un pezzettino alla volta. Il tempo speso in questa attività, così come il tempo speso nel refactoring, è "spalmato" sullo sviluppo delle varie funzionalità chieste dal Business.

Facile. Ma come si fa a tagliare un sistema?
Se si ha a che fare con un'applicazione web, una linea che generalmente si presta bene è quella che separa frontend e backend. L'idea è quella di sostituire tutto il frontend vecchio con uno nuovo fiammante, lasciando il backend al suo triste destino.
La sostituzione del frontend a sua volta sarà generalmente fatta un pezzo alla volta. Ad esempio, un modo che si presta bene consiste nel sostituire una rotta ("pagina") alla volta, usando un load balancer di livello 7 (tipo haproxy) per smistare le richieste. Via via che si è completata nel nuovo sistema una pagina che deve sostituirne una vecchia, si modifica il load balancer dicendogli che quella rotta ora deve essere servita dal nuovo sistema.
E' importante procedere per passi. Il primo è senza dubbio quello di preparare il balancer in modo che tutte le richieste vadano al vecchio sistema. Il passo successivo è quello di inventarsi una rotta non di produzione e configurare il balancer in modo che richieste per quella rotta vadano non più al vecchio sistema ma da qualche altra parte.
A questo punto si può dire che il meccanismo per la sostituzione progressiva del frontend è pronto, e si può procedere a scrivere la nuova implementazione.

Le prime pagine sostituite possono essere quelle più semplici e statiche (tipo le pagine "Chi siamo", "Termini e condizioni", ...) che ci consentono di impratichirci e di andare online (è fondamentale andare online con le nuove pagine più frequentemente possibile) per ricevere prezioso feedback dalla produzione. Non va trascurato questo aspetto: molti problemi importanti che potrebbero condurre il progetto al fallimento (es. con la tecnologia che abbiamo scelto le pagine sono troppo lente/pesanti) possono essere individuati presto, e prima si individuano meno lavoro si butta.

Le pagine dinamiche sono più complesse, perché è più difficile trovare le informazioni per riempirle.
La buona notizia è che generalmente i dati sono all'esterno anche dell'applicazione vecchia, e vivono sereni su un DB di qualche genere (relazionale o no poco importa). Questo significa che possiamo scrivere delle API nuove di zecca interrogando direttamente le basi di dati e ignorando la vecchia applicazione. Certo, in questo modo ci accoppiamo alla base dati e quindi diventerà difficile migliorarla, però guardiamo in faccia la realtà: se il DB è così messo male da non poterlo nemmeno sopportare durante la migrazione dal vecchio sistema al nuovo, allora non ci sono molte speranze di successo.

I casi nei quali i dati non dobbiamo solo mostrarli, ma anche cambiarli, possono presentare qualche insidia in più.
Se l'applicazione vecchia non usa cache, cambiarli direttamente su DB non pone particolari problemi. Il vero divertimento si ha quando l'applicazione vecchia usa cache, e quindi modificare i dati su DB crea disallineamenti di dati destinati a creare problemi difficili da gestire.
Un modo abbastanza semplice per gestire questa situazione consiste nell'implementare nel vecchio sistema una chiamata tipo "drop caches" che svuoti tutte le cache, così da forzarlo a ricaricare i dati da DB mantenendo così la consistenza. Secondo la linea della semplicità sarebbe bello avere una sola chiamata che svuoti tutte le cache, ma se ciò non fosse possibile per questioni di performance è anche possibile rendere l'API un po' più complessa per consentire l'eliminazione solo di una parte della cache. La granularità va decisa caso per caso, tenendo conto che per evitare errori difficili da diagnosticare è meglio sacrificare un po' di velocità e avere un'API più semplice.
Se il vecchio sistema è anche parte di un cluster, ricordarsi di fare in modo che tutti i nodi cancellino la cache, e non solo quello che ha avuto la ventura di essere destinatario della chiamata. In caso contrario si vedranno effetti strani (tipo pagine che cambiano in modo incomprensibile quando vengono ricaricate perché la richiesta è stata servita da nodi diversi). Come fare a propagare la richiesta è nuovamente dipendente dal caso, però c'è da aspettarsi che se un sistema ha cache e vive in cluster allora ci sarà già un qualche meccanismo di questo genere.

Ultimo caso interessante è quello della sessione utente, che dovendo essere condivisa tra i due sistemi pone nuovi interessanti problemi.
E' possibile che la sessione viva su DB come un qualsiasi altro dato, nel qual caso si tratta solo di scrivere una nuova implementazione e interfacciarla come descritto sopra. Il fatto è che spesso le applicazioni usano svariati framework e a volte una singola sessione utente è in realtà costituita dall'unione delle sessioni gestite dai vari layer che le compongono.
In questo caso una "pezza" consiste nello scrivere API nella vecchia applicazione che si aspettino di essere invocate dall'utente, e chiamarle server-to-server copiando nella richiesta tutti i cookie dell'utente. In questo modo l'onere di identificare l'utente resta alla vecchia applicazione per il tempo necessario alla migrazione di tutte le pagine. Una volta migrate tutte sarà possibile reimplementare la gestione della sessione e staccarsi da quella vecchia.

Tutto ciò, com'è facile intuire, non è una passeggiata. C'è un sacco di lavoro da fare, e visto che non ci si può lavorare a tempo piano ci vorrà anche molto tempo. Ne vale la pena?
Noi pensiamo di . Nella nostra azienda abbiamo almeno 3 sistemi già in produzione che sono nati come sostituti di omologhi vecchi, e un quarto è in fase di transizione. I benefici di poter progressivamente essere veloci sulle parti sostituite possono essere grandi, e c'è anche da tenere in considerazione che il morale tende a essere più alto se la quotidianità del lavoro non è solo spaccarsi la testa su un sistema orribile ma anche trovare soluzioni creative per allontanarsene.

Buona riscrittura incrementale a tutti!

I fortunelli

Siamo dei privilegiati, l'azienda ci consente di studiare un'ora al giorno per migliorare noi stessi, il nostro team, i processi che utilizziamo e per fornire più valore all'azienda.
Bello, molto bello, bellissimo... ma lo riusciamo a sfruttare e capitalizzare appieno?

L'entusiasmo iniziale

Quando è stata istituita l'ora di studio avevamo grande entusiasmo e nei primi tempi eravamo delle vere e proprie macchine da studio. Con costanza ogni giorno ci fermavamo per un'oretta (appena dopo pranzo) e ci mettevamo a studiare.
Avevamo un piano di studio ben organizzato, tutto il team partiva dallo stesso argomento e una volta che tutti lo avevamo finito presentavamo le nostre mind-map e ci confrontavamo sul tema.
Tutto era moderato da un coach che ci seguiva durante le presentazioni e a volte ci "interrogava" su alcune sfumature.

Proseguiamo in autonomia

Lo studio costante è proseguito per molto tempo ed anche una volta rimasti senza coach e con un piano di studi esaurito, ci siamo adoperati nel trovare nuovi argomenti che potessero avere un valore per i progetti che stavamo seguendo in quel momento.

I tecnoscettici

Non ci siamo mai scontrati con argomenti tecnologici ma più che altro ci confrontavamo con tematiche riguardanti il processo di sviluppo o il miglioramento dell'architettura dei sistemi. Non abbiamo mai avuto esigenze particolari nell'apprendere nuove tecnologie e non abbiamo mai avuto modo di vedere dei silver bullet che ci spingessero ad approfondirne alcune.
Riguardo a questo ritengo che il team abbia sempre avuto una forma di pigrizia tecnologica, siamo molto forti su alcune tecnologie, sappiamo che possiamo consegnare più velocemente utilizzandole e quindi ci siamo un po' appiattiti a coccolare il nostro C# frameworkless.

Azz

"Poi venne la crisi, sparirono i sorrisi, le frasi col vicino divennero scortesi: nervi troppo tesi, tasse tutti i mesi, i soldi peggio spesi, i soldi sempre attesi." - Frankie Hi-nrg

Eravamo arrivati ad esaurire nuovamente il nuovo piano di studi e lì venne l'inizio della fine...
Inchiodati in un punto in cui non avevamo un argomento appassionante, avevamo definito alcuni spunti ma nessuno di questi ci stimolava a studiare.
Mi vergogno un po' nel dire che a un certo punto trovavamo giustificazioni, anche un po' pretestuose, per saltare o rimandare lo studio.

Il progetto

E' andata avanti così per un discreto lasso di tempo in cui lo studio era frammentario e discontinuo. Siamo rimasti a guardare o abbiamo fatto qualcosa?
Che domande...certo che abbiamo fatto qualcosa: abbiamo provato a concentrare lo studio in un'unica mezza giornata cercando di portare avanti un progetto con tecnologie nuove con la speranza di riuscire a farlo andare in produzione in un remoto futuro.
Ma la tecnologia ci ha fregato! Il progetto era una applicazione Android ma dopo un po' di sviluppo si è palesata la banalità della tecnologia (non ce ne vogliano gli sviluppatori Android) e il nostro interesse si è sciolto come un ghiacciolo sotto il sole d'Agosto.

Abbiamo provato a sfruttare anche le ore di studio per fare attività "di straforo" che il business non riteneva fondamentali ma che per noi devs invece erano molto importanti, in particolare ci siamo messi a riscrivere parte di un sistema.
Problema: era scritto talmente bene che l'abbiamo buttato in produzione, faceva il suo lavoro, ci faceva produrre più velocemente del vecchio e quindi non poteva più essere relegato allo studio ma è entrato a far parte del nostro lavoro quotidiano.

La fase di down

Ancora niente spunti, niente voglia, poco entusiasmo e quindi poco tempo dedicato allo studio.

L'unconference e retrospettiva

Pochi mesi fa l'azienda ha organizzato un unconference con tutti gli sviluppatori (circa una cinquantina), una delle sessioni era dedicata allo studio. Quella è stata una svolta...sentire altri colleghi ancora entusiasti nello studiare, rubare qualche idea e provare a elaborarne altre ci ha dato nuovi spunti e nuova verve.
Tutto è stato suggellato in un'azione scaturita da una retrospettiva: torniamo a essere costanti nello studio e proviamo a percorrere 3 strade:

  1. scriviamo un blog nel quale ci facciamo conoscere al mondo... FATTO!
  2. contribuiamo o facciamo progetti open source
  3. presentiamo qualche tema ad eventi e conferenze

E quindi?

Molte aziende non danno la possibilità di strutturare un piano per il continuous learning. Gli sviluppatori più fortunati tuttavia non sempre sanno mettere a frutto le opportunità che hanno e in alcuni momenti non riescono a vederne tutto il valore.
Come combattere l'apatia da studio?
  • Fare un piano
  • Confrontarsi con altri sviluppatori
  • Condividere le esperienze/competenze
  • Trovare nuovi stimoli
Non basta il tempo per riuscire ad implementare il continuous learning, sono necessarie motivazione, voglia, costanza e disciplina.
Speriamo di averne per ancora molto tempo!!

Studiate, studiate, studiate!!

, , ,

Ci apriamo al mondo

Benvenuti,
oggi vogliamo presentarci al mondo: "Piacere, siamo il Team Nimbus".

Nasciamo come team di sviluppo nel Dicembre del 2011 in 7Pixel. Quel mese fu il big bang del reparto sviluppo in azienda, una massa informe di oltre 20 sviluppatori si sgretolava in team più piccoli, tendenzialmente di 4 persone, per cercare di dare una svolta alla produttività nella produzione di software.
Siamo quindi stati partoriti da un team più grande che chiamavamo TimOne.

Cosa facciamo? Beh cerchiamo di fare in modo che i nostri clienti abbiano il sorriso sulle labbra :) sviluppando del software di qualità e contribuendo a migliorarne il processo di produzione.
Come lo facciamo? Siamo partiti studiando e applicando eXtreme Programmig che abbiamo poi adattato per fare in modo che si sposasse al meglio con la nostra realtà di team e aziendale. Partiamo dai valori di XP e li integriamo con:

  • Automatizzazione
  • Pulizia
  • Adattamento
  • Cost-effectiveness
Ora "ci siamo montati la testa" e abbiamo deciso che il Team Nimbus può essere conosciuto anche al di fuori di 7Pixel. Ci apriamo ufficialmente al mondo!!
Crediamo che la condivisione sia importante e pertanto vogliamo portare un po' della nostra esperienza anche ad altri devs magari per far nascere discussioni o ricevere pareri.

Ma esattamente di cosa tratteremo in questo Blog? Parleremo delle soluzioni tecniche con cui ci siamo trovati meglio e sicuramente di metodologie Agili e come le abbiamo adattate alle nostre esigenze.
Pensiamo che oltre a dare uno spunto ad altri programmatori sia un ottimo modo per poter imparare noi stessi qualcosa di nuovo, per razionalizzare alcune nostre idee all'interno di un articolo e per capire se qualcuno ci può dare dei suggerimenti per migliorarci.

Quindi benvenuti nel nostro blog, speriamo possa esservi utile!!

Cerca nel blog

Blog Archive

Popular Posts