
da un po’ di tempo a questa parte gestiamo la priorità dei nostri task attraverso l’utilizzo di una kanban board. ma che cos’è una kanban board ? vi rimandiamo alla breve ma efficace definizione del nostro coach, che può anche vantare il merito di aver introdotto questo strumento nella nostra azienda.
il kanban, lo scrivo brevemente a beneficio dei neofiti, è sostanzialmente una lavagna dove viene tracciato secondo poche ma ben determinate regole lo stato dei diversi task, abilitando il team ad una modalità di lavoro
- concorrente, dove sono ridotti al minimo gli stati di attesa per svolgere il proprio lavoro
- pull, dove si annulla la necessità di una figura responsabile dell’erogazione del lavoro da svolgere
- trasparente, dove ognuno sa e può sapere cosa sta facendo l’azienda nel suo insieme in un dato momento.
abbattimento della burocrazia, trasferimento del controllo verso il basso e tracciamento di tutte le attività sono il cuore di questa soluzione. (continua…)

photo credits: nelson felix g
sabato 5 marzo abbiamo assistito al codemotion, interessati principalmente alla track “mobile” della manifestazione ed alle opportunità che uno sviluppatore web potrebbe cogliere in questo settore sfruttando i linguaggi che già conosce, al secolo Javascript, HTML e CSS.
ma veniamo al dunque, come funziona un’applicazione mobile ? e come può un web developer diventare attore nel palco di questo settore ?
innanzitutto dobbiamo fare una distinzione tra il tipo di applicazioni che è possibile sviluppare:
una web app non è altro che un sito ottimizzato per la navigazione mobile: ha una sua URL ed è accessibile al pubblico, non è installata sul telefono e non è nello store online. una native app, invece, è un’applicazione vera e propria, può essere acquistabile nello store, ed accedere a tutte le funzionalità hardware del device. (continua…)
nemmeno un anno fa parlavamo degli ambienti di sviluppo e della continuous integration. oggi riaffrontiamo questi temi in modo trasversale per discutere di phing.
phing è un’applicazione di build project o build tool basato su apache. è molto flessibile e può essere usato per molte funzionalità, con PHPunit e simpletest, trasformazioni di file, operazioni su file system, esecuzioni SQL, operazioni CVS/SVN, strumenti per creare pacchetti pear e altro ancora. qui potete trovare altre informazioni su phing.
il nostro utilizzo di questa applicazione è quello di snellire alcune procedure standard che effettuiamo durante le nostre operazioni con il repository. principalmente (per ora) questa applicazione, grazie ad un file build.xml che accompagna ogni progetto, esegue operazioni sul database permettendoci di aggiornarlo automaticamente dopo ogni update, o esportarlo (in struttura e dati) in modo rapido per essere “committato” in modo da aggiornare il repository. (continua…)

da più di un anno abbiamo adottato il manifesto agile all’interno di e-xtrategy. dopo l’esperienza del #fagg.it09, abbiamo iniziato ad imparare e sperimentare le metodologie agili sempre guidati dal nostro coach jacopo romei. inoltre da quasi un anno partecipiamo attivamente a XPug marche, avendo l’occasione di metterci in discussione e confrontare le nostre esperienze con altri professionisti.
proprio grazie a XPug marche, abbiamo potuto partecipare a questa esperienza che ha preso vita qualche settimana fa, un campo scuola di tre giorni in full immersion nelle pratiche del manifesto agile in una cornice rilassata dell’entroterra marchigiano in cui undici professionisti dalle diverse specializzazioni guidati dal coach jacopo romei hanno simulano la realizzazione di un progetto software attraverso l’utilizzo di extreme programming. (continua…)

che cos’è la continuous integration ?
martin fowler nel suo articolo spiega:
continuous integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.
da queste poche righe si apre la finestra verso un mondo: fowler non parla di strumenti o tecnologie, bensì di pratica.
il problema dell’integrazione non è banale: quando due o più sviluppatori lavorano contemporaneamente sullo stesso progetto non è raro che, al momento di mettere tutto insieme, si presentino problemi come conflitti o incompatibilità. troppo spesso si assiste allo scenario in cui la data di consegna al cliente è vicina ed il software è più o meno pronto: << manca solo l’integrazione finale e gli ultimi fix >>, si direbbe, così facendo però solitamente ci si imbuca in un tunnel dentro il quale difficilmente si farà un bel viaggio, ma soprattutto sarà impossibile conoscerne a priori la lunghezza. (continua…)