• Italiano

Translate original post with Google Translate

Di norma gli sviluppatori non sono guru del Photoshop e del design in generale e certamente odiano rifare il proprio lavoro per venir incontro alle esigenze degli esperti.
Così abbiamo deciso di segnalarvi una guida infographic pensata per i progettisti che intendono fare App per  iOS  e aiutarli spedire file corretti per lo sviluppatore.

Lo stile di infographic e’ quello di spiegare tutto con un’immagine, che vo proponiamo di seguito:

Innanzi tutto come vediamo nell’immagine e’ necessario ricordare le dimensioni dei differendi device di Apple.

Iphone e ipod touch fino alla terza generazione: 320 x 480 px / 163 PPI
Iphone4 e ipod tpuch di ultima generazione: 640 x 960 px / 326 PPI
iPad & iPad2 : 1024 x 768 px / 132 PPI
iPad 3 : 2048 x 1536 px / 264 PPI

Apple raccomanda di utilizare icone:

44×44 px per i bottoni di controllo

Un’altro suggerimento e’ quello di preparare le icone partendo da dimensioni 512 x 512 px e 1024×1024 px nel caso di iPad con retina display, facendo sempre attenzione a visonare il design quando queste vengono rimpicciolite.

Il resto dei suggerimenti sono molto piu’ chiari se leggete con attenzione cio’ che e’ segnalato nell’immagine postata sopra.

FONTE:   un post infographic, ovvero Tutto riassunto da un’immagine,   inserito nel blog FSM (http://www.funkyspacemonkey.com/ios-app-designers-guide-infographic)

• Italiano

Translate original post with Google Translate

Quando si decide di progettare un’App è sempre necessario seguire i principi di base della progettazione industriale.
Molte persone  pensano di commissionare un’app, ma quando si trovano a dover descrivere l’applicazione e quindi come la loro idea possa essere tradotta nell’esperienza dall’utente e nell’interfacia grafica (User Experience & User Interface),  si trovano impreparati e si nascondono molto spesso dietro frasi del tipo “non saprei questo è un lavoro per tecnici, pensateci voi tecnici!”.
Inutile aggiungere che quando poi i cosidetti “Tecnici” si mettono al lavoro queste persone, che non hanno vuluto delegare il concept, inizieranno a chiedere modifiche sostanziali dispensando consigli e ragguagli di ogni genere e quasi sempre solo dopo che l’app e’ arrivata alla fase finale del suo sviluppo.
E’ ben noto il concetto secondo il quale i “tecnici”, e gli ingenieri, prima costruiscono il cuore dell’applicazione e poi ci adattano il design e fanno il contrario, loro malgrado, solo se il commitment e’ valido e convincente e, sopratutto, quando questo è deciso fin dall’inzio delle fasi di progettazione.
Di norma con l’approccio “fate voi che poi vediamo” , voluto dai professionisti distratti e poco preparati,  il risultato estetico finale può risultare quantomai scadente dato che ogni ingeniere sa bene che, prima di mettersi a scrivere codice, bisogna aver chiari i principi dell’interfaccia utente unitamente alla descrizione delle funzionalità legate all’esperienza dell’utente stesso.

Alcuni sofisti mi potranno criticare per l’uso della parola “utente”, che a volte risulta poco accattivante se si pensa che alla fine gli utenti non sono altro che persone, ovvero individui utilizzatori. Questa differenza di significato delle parole mi è molto chiara, ma per semplicità comunicativa e sopratutto per necessità di traduzione preferisco usare la parola “utente” o “utilizzatore” al posto dell’ “individuo“.

10 principi per un buon design di un’app e di un prodotto

Inanzi tutto,  per citare Steve Jobs,  propongo  una delle definizioni di design che più mi ha convinto:
“Il design è l’anima che si trova al cuore di un oggetto creato dall’uomo e che gradualmente si estrinseca ai piani esteriori.”

Di certo lo stesso Jobs si ispirava ai principi di Dieter Rams, ex-designer della Braun, che ha enumerato i suoi 10 principi per un  buon design di un prodotto:

Dieter Rams e i suoi prodotti di design

• Un buon design deve essere innovativo.
• Un buon design deve rendere il prodotto utile.
• Un buon design deve essere dotato di estetica.
• Un buon design deve aiutare a capire il prodotto.
• Un buon design non deve essere invasivo, mancare di riservatezza.
• Un buon design deve essere onesto.
• Un buon design deve essere durevole.
• Un buon design è la conseguenza dell’ultimo dettaglio.
• Un buon design si deve preoccupare dell’ambiente.
• Un buon design deve contenere il minor design possibile.

Naturalmente è facile capire che questi principi si adattano sia al design dei prodotti industriali, ma anche per il design delle Applicazioni, sopratutto se queste verranno utilizzate sui prodotti che sono stati costruiti proprio secondo i buoni principi del design industriale, come lo sono tutti i prodotti Apple.

Progettare meglio, lavorare meno

Dieter Rams, creatore dei 10 principi, ha sempre espresso il suo approccio al design con la frase: “Weniger, aber besser” , ovvero “Meno, ma meglio” .
Il minimalismo , oltre ad essere molto elegante, è sicuramente il modo migliore per permettere a tutti gli utenti-utilizzatori di comprendere d’istinto il prodotto e le sue funzionalità e rende il prodotto stesso, o l’App,  amichevole all’uso (user friendly) e “puro”.

Di seguito riporto i commenti , tradotti dall’inglese, dello stesso Rams sui principi da lui stesso enunciati:

1.  Le possibilità d’innovazione non sono esaurite. Lo sviluppo tecnologico offre sempre nuove opportunità per il design innovativo. Ma il design innovativo si sviluppa sempre assieme alla tecnologia innovativa, e non può mai essere fine a se stesso.
   (The possibilities for innovation are not, by any means, exhausted. Technological development is always offering new opportunities for innovative design. But innovative design always develops in tandem with innovative technology, and can never be an end in itself )
2. Un prodotto viene acquistato per essere utilizzato. Esso deve soddisfare determinati criteri, non solo funzionali, ma anche psicologici ed estetici. Un buon design sottolinea l’utilità di un prodotto, mentre trascura tuuto ciò che potrebbe sminuirla.
   (A product is bought to be used. It has to satisfy certain criteria, not only functional, but also psychological and aesthetic. Good design emphasises the usefulness of a product whilst disregarding anything that could possibly detract from it. )
3. La qualità estetica di un prodotto è parte integrante della sua utilità, perché i prodotti che utilizziamo ogni giorno influiscono sulla nostra persona e il nostro benessere. Ma solo gli oggetti ben costruiti possono essere belli.
   (The aesthetic quality of a product is integral to its usefulness because products we use every day affect our person and our well-being. But only well-executed objects can be beautiful.)
4. Chiarifica la struttura del prodotto. Meglio ancora, si può far parlare il prodotto. Meglio se esso è auto-esplicativo.
   (It clarifies the product’s structure. Better still, it can make the product talk. At best, it is self-explanatory.)
5. I prodotti che soddisfano un fine sono come strumenti. Non sono né oggetti decorativi, né opere d’arte. Il loro Design dovrebbe quindi essere sia neutrale che sobrio, per lasciare spazio all’auto-espressione dell’utilizzatore.
   (Products fulfilling a purpose are like tools. They are neither decorative objects nor works of art. Their design should therefore be both neutral and restrained, to leave room for the user’s self-expression.)
6. Non costruire il prodotto in modo da farlo apparire più innovativo, potente o importante di quanto sia realmente. E non tentare di manipolare il consumatore con promesse che non possono essere mantenute.
   (It does not make a product more innovative, powerful or valuable than it really is. It does not attempt to manipulate the consumer with promises that cannot be kept.)
7. Evita di seguire la moda ma non appare mai antiquato. A differenza del design “alla moda”, il prodotto deve durare per molti anni – anche nella società dell’usa e getta di oggi.
   (It avoids being fashionable and therefore never appears antiquated. Unlike fashionable design, it lasts many years – even in today’s throwaway society.)
8. Nulla deve essere arbitrario o lasciato al caso. La cura e la precisione, nel processo di progettazione, mostrano il rispetto nei confronti dei consumatori.
   (Nothing must be arbitrary or left to chance. Care and accuracy in the design process show respect towards the consumer.)
9. Il Design offre un importante contributo alla salvaguardia dell’ambiente. Esso conserva le risorse e riduce al minimo l’inquinamento fisico e visivo durante tutto il ciclo di vita del prodotto.
   (Design makes an important contribution to the preservation of the environment. It conserves resources and minimises physical and visual pollution throughout the lifecycle of the product.)
10. Meno, ma meglio – questo perchè ci si concentra sugli aspetti essenziali, e i prodotti non sono appesantiti da elementi non essenziali. Torna alla purezza, torna alla semplicità.
    (Less, but better – because it concentrates on the essential aspects, and the products are not burdened with non-essentials.Back to purity, back to simplicity.)

Valutazione Euristica

A questo punto non mi resta che descrivere anche la cosidetta valutazione euristica.
La Valutazione Euristica è un metodo ispettivo che viene effettuato esclusivamente dagli esperti di usabilità  e consente di valutare se una serie di principi generali di progettazione sono stati applicati correttamente nell’interfaccia utente.
Le linee guida (“Ten Usability Heuristics”) su cui si basa questo tipo do valutazione sono state sviluppate negli anni 1990 da Jakob Nielsen e Rolf Molich e sono state pensate per i desktop software , ma anche in questo caso questi principi sono ancora validi per le applicazioni studiate per touchscreen, come le App iOS per iPhone e iPad ,  per le  app Android e Window Mobile.

• Italiano

Translate original post with Google Translate

Progettare indipendentemente dalla risoluzione dell’interfaccia utente è difficile, soprattutto se si deve programmare il codice del disegno.
Per semplificare questo processo di sviluppo è utile un’ applicazione di disegno vettoriale che genera istantaneamente codice Objective-C.
In questo modo è possibile progettare il design dei bottoni o di tutti quei componenti che possono essere visualizzati da iOS o OSX attraverso il codice; in questo modo l’app sarà di certo molto performante e avrà la qualità del design indipendente dalla risoluzione grafica del dispositivo, sia esso iPad3, iPhone4, iPad 2 o qualsiasi altro dospositivo apple.

Abbiamo utilizzato l’app PaintCode con iMac e la abbiamo scaricata dal mac app store. Il prezzo non è tra i più bassi ed è di 80 dollari, ma l’acquisto di questa app permette al programmatore di smettere di scrivere il codice di disegno e al designer piu’ avanzato di non lavorare direttamente su files grafici.

PaintCode è una semplice applicazione di disegno vettoriale che genera codice per Mac OS X e iOS.

Non è più necessario ricompilare il codice, più e più volte, per ottenere il risultato desiderato. Con app di questo tipo anche un graphic designer senza esperienza di programmazione può disegnare controlli, icone e altri elementi propri della UI.

Interfaccia utente resolution-independent

Con questo stumento è possibile utilizzare forme vettoriali built-in (rettangoli, rettangoli arrotondati, ovali, testi, Béziers, stelle e poligoni) per disegnare i pulsanti, cursori, icone e altri elementi dell’interfaccia utente, allineandoli alla griglia a pixel nei posti giusti.
È anche possibile aggiungere gradienti e ombre per rendere l’interfacia più realistica.

Generare il codice per OS X e iOS

È possibile scegliere tra OS X o iOS codice. PaintCode genera Objective-C che utilizza Cocoa, Quartz e Core Graphics API. È anche possibile spostare l’origine e generare un codice di disegno per NSViews capovolte!

Preparatevi per i display Retina

Per aiutarvi a preparare il mondo ad alta risoluzione, con display ad alta densità, PaintCode consente di attivare la modalità Retina. Questo raddoppia la risoluzione del disegno. Quando si è in modalità Retina, si può immediatamente vedere il disegno in modo molto simile a iPhone 4, iPhone 4S, il nuovo iPad 3 e altri dispositivi retina-display  che possono essere aggiunti in futuro.

• Italiano

Translate original post with Google Translate

Con il rilascio della prossima generazione dell’ iPad (iPad 3)  si aprirà una nuova stagione per la progettazione grafica ad altissima risoluzione.Le nuove App dedicate ad iPad , sopratutto quelle universali , dovranno valorizzare il nuovo Retina display, che raggiunge l’incredibile risoluzione  di 2048×1536 pixel.

L'iPad 3 possiede uno schermo di dimensione superiore anche alla risoluzione full HD del blu Ray (1920*1080 px).

La distribuzione di massa di un iPad con uno schermo così dettagliato e di risoluzione grafica così elevata rappresenta una sfida per tutti gli sviluppatori che vogliono mantenere i loro App Bundle al di sotto del limite di 20 MB.
20 Mega Byte è attualmente il limite imposto  dall’Apple Store per  effettuare  il download delle App attraverso la rete Umts , 3G o edge; sapendo che Apple limita il download di App da rete cellulare dobbiamo tener presente che se compiliamo App “Grasse” – Fat Binary superiori ai 20 mb – è necessario che il nostro cliente sia collegato in modalità Wifi.

Di seguito  suggerisco alcune tecniche che gli sviluppatori possono utilizzare per mantenere le loro App  nella fascia ” magra”.

Vi mostrerò interessanti tecniche  suggerite in un post di David Smith (http://david-smith.org/blog/2012/03/05/techniques-for-shrinking-app-bundle-size/) , un developer di app quale ad es. My Recipe Book.

Rimuovere il codice inutilizzato

Il primo passo per il taglio  di spazio è quello di trovare il codice non utilizzato nel progetto. Il candidato più probabile sarebbe da trovare in tutte le librerie di terze parti (3rd party library) che vengono fornite con il progetto, ma che non verranno attivamente utilizzate.

Inoltre, bisogna sincerarsi di controllare anche  l’intero contenuto di una libreria ; se si ha solo bisogno di alcuni file, si possono eliminare quelli non utilizzati.

Rimuovere risorse non utilizzate

Il secondo passo è quello di assicurarsi che non siano comprese le risorse che non vengono utilizzate nel nostro progetto. Spesso trovo che la nostre app  comprendono  immagini, icone, suoni che appatengono a versioni precedenti a cui non si fa più riferimento.

Fare auditing del vostro progetto per questi casi è spesso difficile,  e per questo David ci consiglia un ottimo strumento chiamato Slender che elimina una parte del lavoro analizzando il progetto per i file inutilizzati e permette di rimuoverli. Questo strumento analizza vari tipi di file e oltre a indicare quali di questi non vengono referenziati all’interno del progetto, individua anche alcuni problemi, come ad esempio la mancanza della versione @2x (utilizzata per il Retina Display), la dimensioni delle artwork grafiche di sistema (icona, Default image, ecc.) più una serie di controlli apparentemente minori ma che servono a fare pulizia del progetto. Inoltre questa applicazione ad ogni modifica effettua una copia di backup affinché eventuali file incorrettamente rimossi possano essere facilmente ripristinati.

Caricare le risorse On-Demand

Se il progetto comprende risorse come video tutorial o immagini che sono utilizzati  e necessari solo raramente, è possibile spostare questi su un web-server e richiamarli on-demand.  Amazon S3 o di un piccolo servizio di VPS  Linode sono ottime soluzioni possibili.  E’ necessaria discrezione con questa tecnica se si vuole evitare di frustrare l’utente con una serie download dopo l’installazione.
Personalmente trovo utile ciò che ha fatto David per i video tutorial  nella sua App My Recipe Book, questi Video infatti sono richiamati solo in schermate secondarie dell’app e non fanno parte della cosidetta user’s initial experience.
Nell’eventualità che questi file siano necessari per l’utilizzo primario dell’app, potete sempre offrire la possibilità di una visione online a quella di poter scaricare il file localmente. Tenderei ad evitare il fastidioso requisito di scaricare i file una volta scaricata l’app, dato che spesso l’utente non si avvede immediatamente di questa necessità e nel momento stesso in cui se ne accorgerà questo accadrà troppo tardi, ormai lontano da ogni connessione Wi-Fi.

Utilizzare immagini Patterned

Seguendo la definizione di Wikipedia:
<<”Nell’ingegneria del software, un design pattern (schema di progettazione) può essere definito come : una soluzione progettuale generale a un problema ricorrente. Esso non è una libreria o un componente di software riusabile, quanto piuttosto una descrizione o un modello da applicare per risolvere un problema che può presentarsi in diverse situazioni durante la progettazione e lo sviluppo del software (NB: nel nostro caso e’ un’immagine).
….
La differenza tra un algoritmo e un design pattern è che il primo risolve problemi computazionali, mentre il secondo è legato agli aspetti progettuali del software.”>>

Nel nostro caso, un Pattern è una sorta di trama grafica (una sorta tegola) che viene ripetuta e sata come riempimento per un’immagine.

UIColor include una funzione fantastica per ridurre la necessità di includere le immagini di grandi dimensioni strutturate all’interno del progetto.

Ad esempio le dimensioni medie di un’immagine per dispositivo Apple sono le seguenti:

• iPad 3 (@2x) = 2048*1536 px = 1,2 Mb = 1200 Kb
• iPad 1 e 2 = 102*768 px = 0,73 Mb = 730 Kb
• iPhone 4 (@2x) = 960*640 px = 0,63 Mb = 630 Kb
• iPhone 3 = 480*320 = 0,34 Mb = 340 kb

TOTAL = 2900 Kb

• Single Pattern Tile = 300 kb

Vi segnalo uno dei tanti video che vi insegnerà (tutorial) a creare Pattern:

Un uso utile del Patterned image è quando volete fornire alla vostra applicazione uno sfondo stilizzato, anche se questa tecnica si applica altrettanto bene a piccole aree in cui si desidera aggiungere texture a un controllo dell’interfaccia utente.

Basta impostare il colore di sfondo della vista desiderata per un colore fantasia come questo:

view.backgroundColor = [UIColor colorWithPatternImage: [UIImage imageNamed: @ "pattern_image.png"]];

La view  avrà così uno sfondo con texture che viene scalato e regolato secondo le dimensione della vista stessa.
David ci segnala che una buona fonte per le tile texture (texture tegola) è il progetto Subtle Patterns.

Utilizzare Stretched UI Image

UIImage include un metodo performante per creare immagini che vengono scalate o bilanciate dinamicamente in relazione  alla dimensione (size). L’immagine è configurata in modo che la sezione centrale si allunga mantenendo invariati i bordi. Questo è spesso usato per oggetti, come i pulsanti, dove si ha uno stile per gli angoli e per i lati, ma il corpo del pulsante è semplice.
Funziona bene anche per la creazione di un effetto”inciso” (etched) in una table view (vista tabella).

Quindi, piuttosto che la creare un’immagine 320×48 che rappresenta lo sfondo della cella si crea una piccola immagine 1×3 con il top desiderato, il corpo e i colori di sfondo. Questo viene poi assegnata come backgroundView;

UIImage* template = [UIImage imageName:@"template.png"]; UIImage* stretched = [template resizableImageWithCapInsets:UIEdgeInsetsMake(1, 0, 1, 0)]; cell.backgroundView = [[UIImageView alloc] initWithImage:stretched]; 

Disegnare elementi dell’interfaccia utente (UI Elements) in Quartz

Essenzialmente quando si realizzano degli elementi dell’interfaccia (UI Elements) utente geometrici  è spesso possibile evitare l’utilizzo di un’immagine PNG per raggiungere l’obiettivo dato dalla progettazione.
Piuttosto che pre-generare gli elementi in Photoshop e poi bundle con l’applicazione, è sufficiente rendere lo stile desiderato in fase di runtime. Questo può essere semplice come creare uno stile pulsanti quadri:

UIButton SquareButton * = [UIButton buttonWithType: UIButtonTypeCustom];
 [squareButton.layer setBorderColor: [[UIColor blackColor] CGColor]];
 [squareButton.layer setBorderWidth: 1,0];
 [SquareButton setTitleColor: [UIColor blackColor] forState: UIControlStateNormal];
 squareButton.backgroundColor = [UIColor whiteColor];

Oppure, più complicato come il progetto Gradient Buttons dell’ottimo Jeff LaMarche. Per quest’ultimo ricordiamo che i file presenti nel repository non sono compatibili con ARC e quindi vanno modificati (le modifiche richieste sono poche ma necessarie per non avere errori di compilazione).

L’obiettivo è quello di rendere quello che ti serve attraverso il codice, piuttosto che fare il bundling con decine di mini vedute di background con la tua applicazione.

Utilizzare file PDF

Ultimamente è stata avanzata dal noto sviluppatore inglese Matt Gemmell, nel suo articolo Using PDF Images in iOS apps, la proposta di utilizzare il PDF come elemento portante di immagini vettoriali. Ricordiamo che le immagini vettoriali permettono di raggiungere, per loro natura, delle definizioni molto elevate, per esempio le due immagini del “close button” (entrambe tratte dall’articolo di Gemmell), sono la rappresentazione in scala diversa dello stesso oggetto vettoriale: . Utilizzando Photoshop è possibile ottenere un file PDF sufficientemente compresso (il PDF è un ottimo “vettore” di file vettoriali) che potrà essere in seguito manipolato con del codice Objective-C per ottenere le immagini delle dimensioni desiderate. In tal caso si richiede allo sviluppatore la capacità di spacchettare queste immagini nel momento opportuno senza anche qui bloccare l’applicazione all’inizio. Un buon esempio di tale codice è reperibile nel progetto UIImage+PDF category su GitHub.

 Conclusioni

L’uso ponderato di queste tecniche può aiutare a ridurre drasticamente le dimensioni del bundle delle vostre applicazioni, aiuta quindi a pubblicare un’app sotto il limite di download per 3G.

Tuttavia, è necessario fare attenzione e non esagerare; non fatevi prendere la mano e a volte è meglio frenare il vostro desiderio di ottimizzazione se c’e’ il rischio di ottienere una soluzione che sia lontana dal buon gusto di progettare un user experience di gusto e design.

• Italiano

Increasingly, our customers and readers submit proposals for developing an app without using standard documents and without using those terminologies that may help to understand properly how many and which features should have given the app.

If you want to convey an idea that allows you to create an app for iPhone, iPad or Android is necessary to prepare a clear Mockapp and / or Functional Document which will contain all the detailed features of the app for your iPhone or iPad or Android together with a layout that makes understanding the User Interface and User Experience.

Cooker App – Design, Mockup e Prototype Apps interfacce app in iOS

If you want to use your iPad as a tool to prepare the mockapp prototype, we mark App Cooker (website: http://www.appcooker.com/).

We will report instead of in the next article on what are the tools that you can use with your Mac or PC.

Many people have abandoned almost entirely the use of computers and rely on the iPad to send emails, take advantage of the Internet and use tools;

App Coocker  is an app for iPad and consider it a great tool if you want to bring your ideas to a stage of possible realization.

App Cooker, is present in the App Store at a price of € 15.99, which according to some rumors will increase to $ 24 the next version, the application (IPAD) is developed by HotAppsFactory and, as we have said, used to design applications iPhone and iPad ..

The ‘App Board will collect your conceptual plans, mock-ups, icons, App Store and pricing strategy.
It will be the backbone of your project and lets you work in an organized and clear.

Below is a video in English directly from the official site:

Define the ideas

We start with an idea, a sketch and use this app to organize the ideas and inspire.
The idea is the essence of any application and it requires time and careful consideration.
App Cooker provides a dedicated tool for this, providing valuable advice set out by Apple and other industry professionals.

iOS MockupiOS Mockups

The engine mockup supports orientation, simple links and unites assim the UI of Apple (UI) design with bitmaps, vector shapes, text and images.
Prototypes can come to life, without a single line of code.

The ‘trademark icon of the app

The icon is the face of your application. The creation of large icons requires experimentation and several attempts until the solution will not be found. Using the freehand tool, or images with vector shapes you can define the look of the icons of your ideas and see the results in various sizes and in no time.

Prices tool
App Cooker allows you to compare a large number of price scenarios to find the right model for your application. Supports both purchases app that advertising, which makes it easy to predict revenues, costs and profits.s

Descriptions App Store

Descriptions App Store

The description on the product page of iTunes is a deciding factor for potential buyers. App Cooker makes writing this information a simple task, and provides a place to locate in any of the App Store in 18 languages​​.

Mockapp before to the development of code

Designing a good application is difficult. You must have creativity, talent, resources, knowledge, time and a strong sense of self-criticism; the app to succeed are the result of a long process of refining.

We spent a long time, with many different clients and companies who contact us, to try to explain the best way to design applications for iPhone, iPad and Android.

With all the time, sooner or later discover that the design of an application is much more than just graphic design.

Below we enunciate the 10 principles that I have collected from the site of the App cooker:

In conclusion,

Cooker app is configured as a professional application, since it allows to design all the elements of an application compatible with all Apple devices IOS.

Addressing all those who intend to develop their own application, you must first make clear the initial idea, compatibility with various devices and various functions, then we must create the various graphic elements of the mockup, the icon , location on the App Store and deployment prospects and earnings.

Below we enunciate the 10 principles that I have collected from the site of the App cooker:

• Italiano

Translate original post with Google Translate

Con questo articolo cerco di rispondere ad alcune domande.

• L’azienda vuole evolvere il proprio know-how?

• Che cosa sta uccidendo molte aziende che si occupano di sviluppo?

I problemi delle grandi aziende IT è spesso ricercato nel settore sviluppo, tanto che più è grande l’azienda e piu’ si cerca di esternalizzare proprio lo sviluppo. In alcuni casi si cerca di manterenere il controllo sul know-how internalizzando i settori funzionali a scapito del development.
Detto questo non penso lontanamente che ci possa essere un problema nell’IT a causa dell’assenza di capacità professionali d’eccellenza all’interno dell’azienda, piuttosto sono convinto che il settore sviluppo sia proprio quello che concentra più cervelli interessanti; chi si dedica allo sviluppo lo fa quasi sempre per la passione nell’approfondire la conoscenza.
Per questo motivo vedo il problema dello sviluppo incentrato su come gli sviluppatori vengono messi assieme in azienda, come vengono gestiti e per quale motivo vengono assunti e con quale criterio gli vengono affidati i ruoli.

Nella  esperienza avuta ho potuto vedere risultati d’eccellenza e di qualità internazionale solo in brevi momenti  , solo in determate “isole felici” che il mercato era pronto ad assorbire. Questi gruppi di sviluppo sono evaporati nel tempo in molte delle aziende che ho conosciuto.

Le ipotesi che stanno dietro il recruiting di sviluppatori.

Per spiegare questa situazione ho intenzione di rendere espliciti alcuni dei presupposti taciti che spesso in una grande azienda sono alla base del recruiting di un team del settore sviluppo. Questo è un punto cruciale poichè, nella gran parte delle organizzazioni, chi influenza queste decisioni il più delle volte non potrà mai essere ritenuto responsabile.

Basandomi sulle idee di Ash Moran, i presupposti dell’organizzazione in questione sembrano essere i seguenti:

1. Gli sviluppatori sono fungibili
2. La produttività è proporzionale alle ore di  sviluppo
3.  I requisiti sono tutti necessari

1. Gli sviluppatori sono fungibili

Tom de Marco, nel suo “Slack – manuale per manager, imprenditori e Ceo“,  definisce “Il mito della risorsa fungibile“. Molti posti di lavoro in fabbrica e in magazzino sono ampiamente fungibili, nel senso che il tempo di portare qualcuno fino alla piena produttività è pressoché irrilevante (ore o giorni). Questo non è vero quando si parla di sviluppo, dove anche se un neo assunto conosce il linguaggio di programmazione, dato il contesto, ci vorrà  molto tempo per  l’apprendimento del codice di base e delle metodologie aziendali.

Non credo che gli sviluppatori  siano fungibili (almeno nella stragrande maggioranza dei casi), ma ho partecipato a innumerevoli meeting in cui i decision maker si comportavano come se questa ipotesi fosse valida. Ogni volta , stime alla mano, la stragrande maggioranza dei managers agisce come se un nuovo sviluppatore possa immediatamente aumentare la produttività del team.
Questa assunzione è in contraddizione con ciò che gli sviluppatori pensano espressamente in merito alla natura del proprio lavoro.

2. La produttività è proporzionale alle ore di sviluppo

Ci sono due forme degenerative di pensiero per questa ipotesi:

1) L’idea che uno sviluppatore che lavora 10 ore al giorno sarà il 25% più produttivo di uno sviluppatore di lavoro di 8 ore al dì

2) La convinzione che un team di 10 sviluppatori è del 25% più produttivo di un team di 8.

Ho parlato di degenerazione in quanto sono convinto, come Ash, che la natura dello sviluppo del software sia la creazione di nuova conoscenza, concetto che ho descrito in un precedente articolo.
Dobbiamo pensare agli svilppatori come figure che affrontano un compito creativo. Un lavoro che coinvolge costantemente il programmatore, chiamato sempre più spesso a prendere decisioni logiche.

L’ipotesi produttività-tempo si basa sull’idea che la produttività sia rappresentabile come una bilancia a squadra lineare. Questo non è vero nello sviluppo, per la semplice ragione che la complessità nella gestione di un team non è per forza relativa al numero di persone coinvolte, ma è funzione della natura del coinvolgimento e della quantità di comunicazione necessaria per svolgere un determinato compito.
Basta pensare che a volte è più semplice far svolgere un compito a molte persone, piuttosto che cercare di mettere daccordo 4 persone sulla scelta di quale film andare a vedere dopo cena.
Ovviamente dipende dal compito, così come alcuni importanti progetti informatici si possono svolgere meglio con una piccola squadra di lavoro.

La disattenzione è la causa principale di importanti bug.

Vi segnalo un interessante articolo: Do You Suffer From Decision Fatigue? ; il cervello umano ha una capacità limitata di fare scelte, e una volta stanchi, ci trova spesso a ricercare scorciatoie.

3. I requisiti sono tutti necessari

Nella maggior parte delle grandi aziende informatiche, i requisiti funzionali  vengono definiti al di fuori del team di sviluppo. A meno che il team di sviluppo non stia scrivendo software esclusivamente per se stesso, il cosidetto “Settore Funzionale” (Functionals) sarà coinvolto nel redigere un documento in cui è descritto il lavoro che deve essere svolto dal settore sviluppo. In seguito a volte accade che il 30% delle funzionalità nel software non saranno mai usate o non necessarie, quindi almeno il 30% del tempo di sviluppo diventa puro spreco.  Tuttavia, molte squadre sono contrattualmente obbligate a fornire una specifica (documento funzionale) senza un riferimento al valore delle caratteristiche della specifica stessa, questo può essere una fonte di bugs difficile da sanare.

• Italiano

Translate original post with Google Translate

Metodo Agile

Questo articolo nasce dopo una lunga “navigazione” tra moltissime pagine web che ho letto al fine di documentarmi meglio sulle metodologie che istintivamente ho sempre messo in essere quando ho avuto modo di gestire uno o più progetti.

Nel febbraio 2001, in una stazione scistica nel Wasatch Mountains dello Utah, diciassette persone si sono incontrate per parlare, sciare, rilassarsi, e cercare di trovare qualcosa in comune. Ciò che è emerso è stato il Manifesto Agile Software Development. I rappresentanti di Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, e altri si trovavano di fronte alla necessità di un’alternativa alla documentazione che guida il processo, e alle pesanti metodologie di sviluppo software.

Quanto è emerso da questo incontro è stata la stesura simbolica di un Manifesto per il Software Agile Development firmato da tutti i partecipanti che si autonominarono “L’Alleanza Agile“. Questo gruppo di pensatori indipendenti sullo sviluppo software, a volte concorrenti tra loro, hanno convenuto sul Manifesto for Agile Software Development visualizzato sul  sito web  agilemanifesto.org/.

Propongo di seguito la traduzione fatta da Jacopo Romei aul suo sito web.

Manifesto per lo Sviluppo Agile di Software

Stiamo ricercando modi migliori di sviluppare software facendolo e aiutando gli altri a farlo.

Grazie a questa attività siamo arrivati a considerare importanti:

• Gli individui e le interazioni più dei processi e degli strumenti
• Il software funzionante più che la documentazione esaustiva
• La collaborazione col cliente più che la negoziazione del contratto
• Rispondere al cambiamento più che seguire i piani

Ovvero, fermo restando il valore delle entità a destra, consideriamo più importanti le entità a sinistra.

I Dodici Principi del Software Agile
Vedi i firmatari (via agilemanifesto.org)
Riguardo gli autori (via agilemanifesto.org)
Riguardo il Manifesto (via agilemanifesto.org)
Riguardo questa traduzione

Processo Agile

Agile non è un processo specifico, ma piuttosto un termine generico per un gruppo di metodologie e di approcci che hanno una base simile. Questi approcci, tra cui Extreme Programming, Dynamic System Development Method, Scrum, Crystal e Lean tra gli altri, si basano sulla realizzazione di alta qualità, lavorando software presto e spesso, e la creazione di soddisfazione del cliente.

Sebbene ciascuno dei metodi che formano la famiglia dei processi agili ha un obiettivo simile, si raggiunge questo obiettivo attraverso pratiche diverse.

In questo articolo ho preso le migliori pratiche che abbiamo visto e fatto il lavoro di elencare tutti i processi e metterli insieme.

Immaginiamo una  figura a cerchi (come l’immagine dell’articolo)  come una rappresentazione di base di queste  pratiche agili che abbiamo distillato;
il cerchio più al centro  indica le pratiche che un paio di programmatori usano in quotidiano. Il successivo cerchio esterno  mostra le pratiche che vengono utilizzati da un team di sviluppatori. Il cerchio più esterno ci dà pratiche utilizzate da tutte le persone coinvolte in un progetto come “I clienti, sviluppatori, tester, analisti aziendali, ecc

Ciascuna delle pratiche nei cerchi si riferisce direttamente ai valori fondamentali della filosofia Agile mostrati ai quattro angoli: Comunicazione, Feedback, Coraggio e Semplicità. Cioè, ogni pratica ci dà un modo concreto per seguire i valori Agile e renderli parte del processo.

Elenchiamo le metodologie del modello “Agile”.

Agile Unified Process

Si tratta di una versione semplificata dell’IBM Rational Unified Process (RUP). Descrive un approccio semplice per lo sviluppo di software applicativo utilizzando tecniche agili e concetti propri del RUP.

Dynamic System Development Process

Si tratta di un metodo basato sul Rapid Application Development, un approccio iterativo e incrementale che enfatizza il continuo coinvolgimento di utenti e cliente.

Studiato per progetti di sviluppo di sistemi informativi caratterizzati da schedulazioni e budget ridotti e indirizza le più comuni cause di fallimento di un progetto, come il superamento del budget, il mancato rispetto delle date di consegna, il mancato coinvolgimento degli utenti finali e del top management.

Il suo obiettivo è di consegnare progetti nei tempi e costi previsti, adattando le modifiche ai requisiti in corso d’opera.

XTreme Programming

Extreme Programming (XP) è una disciplina che organizza i gruppi di lavoro verso la produzione di software di alta qualità in modo più produttivo che con metodi tradizionali. XP cerca di ridurre i costi delle modifiche ai requisiti decomponendo le attività di sviluppo in molti cicli brevi piuttosto che in un unico lungo ciclo.

Feature Driven Development

Un processo di sviluppo software iterativo ed incrementale che miscela una serie di buone pratiche in un insieme coeso. Queste pratiche sono orientate allo sviluppo di funzionalità nel rispetto delle esigenze del cliente, suddividendo l’attività di sviluppo in singole componenti (Feature) che procedono parallelamente.

Scrum

Un framework iterativo e incrementale per la gestione di progetti. Si basa su tre semplici punti: Sprint, Backlog e Scrum Meeting.
Molto simile ad Extreme Programming prevede di dividere il progetto in blocchi rapidi di lavoro (Sprint) alla fine dei quali consegnare una versione al cliente, indica come definire i dettagli del lavoro da fare nell’immediato futuro (Backlog) per averne una definizione estesa, organizza riunioni giornaliere del team di sviluppo (Scrum Meeting) per verificare cosa si è fatto e cosa si farà.

 Le sette pratiche centrali di lavoro Agile

Il lavoro Agile  si compone di 7 pratiche di base. Queste pratiche costituiscono un solido punto di partenza per qualsiasi persona, gruppo o comunità che voglia seguire la via Agile.

Self-Organizing Team

Qualsiasi gruppo di persone che desiderano essere un Team Agile ha bisogno di prendere l’iniziativa e di decidere autonomamente su come sta andando il lavoro (processo) e su come ha intenzione di fare il lavoro (prodotto). Il termine “squadra” si applica in generale a qualsiasi gruppo formato di persone che stanno lavorando insieme verso un obiettivo comune.

Il risultato più importante del team di sviluppo è lo stesso team, e non le specifiche competenze e capacità che gli individui imparano.

Se la squadra è parte di un’organizzazione più ampia, l’organizzazione deve dare alla squadra lo spazio, l’autorità e la sicurezza per riuscire ad essere auto-organizzati. Riguardo alla leadership, l’organizzazione è responsabile per la determinazione del “perché?”, Alcuni vincoli sul “come?”, Lasciando poi al team di rispondere alla necessità nel miglior modo possibile.

Questa pratica è Conosciuta anche come: Team totale (Extreme Programming), Cross-Functional Team (gestione aziendale).

Deliver Frequently

Agile utilizza brevi periodi di tempo per monitorare il processo di erogazione di valore. Ognuna di queste iterazioni o timeboxes è strutturata in modo tale, in realtà, che la squadra o il gruppo quando finisce un pezzo di lavoro lo consegna ai soggetti interessati.
Prima che i prodotti  possano essere consegnati, il valore maggiore puo’ essere ottenuto da questi prodotti. Questo valore aggiunto è derivato da opportunità quali le vendite precedenti, vantaggio competitivo, feedback , e riduzione dei rischi.

C’è un compromesso: più breve è il tempo di consegna, minore è valore che sarà dato a quel pezzo.

Conosciuto anche come: Sprint (Scrum), iterazione (Extreme Programming), timeboxing (generico), valore temporale del denaro (contabilità).

Plan to Learn

Ogni tipo di lavoro è disciplinato da un orizzonte di prevedibilità. Qualsiasi piano che si estende al di là di questo orizzonte di prevedibilità è destinato a fallire. Agile  utilizza un ciclo di apprendimento legato alla pianificazione dei lavori e accoglie questo come inevitabile.

Innanzitutto, è richiesto un obiettivo. Questo obiettivo può essere a lungo termine. Team che utilizzano lavoro Agile creano una coda di task di lavoro per raggiungere questo obiettivo. Per ogni iterazione, alcuni di questi elementi sono selezionati, finiti e quindi la coda viene regolata. I cambiamenti nella coda di lavoro si basano su fattori esterni, e che la squadra conosce.

Uno dei metodi più efficaci per la squadra per conoscere lo stato del suo lavoro è la retrospettiva. Dopo ogni consegna dei risultati, il team tiene una retrospettiva per esaminare come si può migliorare.

Conosciuto anche come: Controllare e Adattare (Scrum), Kaizen (Lean), Adaptive Planning (generico).

Communicate Powerfully

Una squadra ha bisogno di disporre di mezzi efficaci per comunicare, sia tra i membri del team e anche per le parti interessate. Per “Comunicare Potentemente” , una squadra ha bisogno di preferire la comunicazione di persona attraverso la comunicazione distribuita. Sincrono sulla comunicazione asincrona. Elevata larghezza di banda e più bassa larghezza di banda di comunicazione. Comunicazione multi-mode  su singola modalità di comunicazione.

Il risultato di non riuscire a comunicare con forza include il tempo sprecato per l’attesa, le incomprensioni che portano a difetti o re-lavoro, abbassamento della fiducia, difficoltà nel team-building, e in definitiva un fallimento.

Il mezzo più efficace per comunicare con forza, è quello di mettere tutta la squadra insieme in una stanza dove può fare il loro lavoro, ogni giorno per la maggior parte del tempo di lavoro.

Alcuni tipi di lavoro non si prestano a questo approccio (ad esempio la creazione di un video documentario), ma ogni sforzo dovrebbe essere fatto per migliorare la comunicazione.

Conosciuto anche come: Visibilità (Scrum), Team e Team intero Camera (Extreme Programming), War Room (gestione aziendale).

Test Everything

Testando tutto, guidando tutto il lavoro di un team, creando casi di test per verificare il lavoro, una squadra può raggiungere livelli qualitativi estremamente elevati. Questa capacità di prevenire i difetti è così importante che solo una decisione di livello esecutivo deve essere considerata sufficiente per consentire i difetti in un processo di lavoro. La qualità non è negoziabile.

Nel lavoro Agile, la rimozione di un difetto è l’unico tipo di lavoro che ha priorità su tutte le nuove caratteristiche / funzionalità. Se il risultato finale desiderato è quello di massimizzare il valore, rimuovendo difetti si raggiunge più facilmente un tal fine.

Ogni squadra ha un dovere etico di scoprire nuovi modi per testare efficacemente il proprio lavoro. Questo può avvenire attraverso l’uso di strumenti, meccanismi di feedback, automazione, e il buona vecchia capacità di problem solving.

Conosciuto anche come: canarino nella miniera di carbone (Scrum), Test-Driven Development (Extreme Programming), difetti per Opportunità (Six-Sigma).

Misura del valore (Measure Value)

Dal momento che la realtà è percepita, è importante per un team Agile, e per l’organizzazione, avere un metodo chiaro per descrivere e percepire ciò che è importante per l’organizzazione. Misurare il valore è un metodo critico per descrivere e percepire ciò che è importante.

Una metrica singola può essere usata per guidare tutte la misure e la definizione degli obiettivi e le ricompense di un’organizzazione. Tutte le altre misure sono secondarie e devono essere trattate come tali: limitate e temporanee.

Ci sono molte cose più facilmente misurabili rispetto al valore. Spesso è facile misurare i costi, e le ore lavorate, oppure i difetti riscontrati, o la stima ore effettive … ecc, tuttavia, tutte queste altre misure implicitamente o esplicitamente non fanno altro che portare ad un comportamento sub-ottimale.

Conosciuto anche come: Risultati di misura (Scrum), ROI (gestione aziendale), Driver economico (Good to Great), Running Caratteristiche testate (Extreme Programming).

Clear the Path (Cancellare il Percorso)

Tutti coloro i quali, in un’organizzazione, utilizzano lavoro Agile si assumono la responsabilità per la pulizia del percorso, rimuovendo (cancellando!) gli ostacoli che impediscono il lavoro venga svolto in modo efficace. Cancellare il percorso non significa solo trovare espedienti e soluzioni rapide ai problemi, ma piuttosto avere il tempo di guardare un ostacolo e fare il meglio possibile per rimuovelo in modo permanente.

Nel metodo di lavoro Agile, il Facilitatore del processo è la persona che è responsabile per tracciare gli ostacoli e garantire che il “percorso venga cancellato”. Per fare questo, il facilitatore di processo mantiene un record sugli ostacoli.

La cancellazione del percorso è  a volte un doloroso lavoro che ci espone a cose che preferiremmo non affrontare. Di conseguenza, è fondamentale che le persone costruiscano la loro capacità di veridicità e lavorino per accrescere la fiducia tra di loro. Costruire una capacità di veridicità non è qualcosa che può essere fatto usando un processo esplicito.

Conosciuto anche come: eliminazione degli ostacoli (Scrum), fermare la linea (Lean).

E l’Acqua Calda?

Tutte le pratiche e le metodologie Agile sono destinate ad aumentare la produttività dei team che le adottano. In un certo senso si può pensare ad essa come “team + pratica  = migliore”, ciò che andreamo ad esplorare è la natura di “+”.

Se si vuole fare un piatto di pasta, mettiamo l’acqua a bollire in pentola e, la nostra acqua, inizialmente sarà fredda. Facciamo un intervento per correggere questo stato indesiderabile: accendiamo il fuoco. Mettiamo la pasta a mollo? Voglio dire, adesso? A meno che non vogliate mangiare della pasta scotta, che farà rabbrividire un italiano, la risposta è no: l’acqua deve ancora bollire. C’è un ritardo tra il momento in cui accendiamo il fuoco sotto la pentola e la bollitura dell’acqua, più o meno di 15 minuti. Ciò è significativo: significa che abbiamo il tempo andare a sfogliare un magazine su iPad. Ciò significa anche che, se l’acqua (gia salata?) non è ancora in ebollizione dopo mezz’ora, c’è qualcosa di sbagliato. Forse arriva poco gas, o non abbiamo girato bene la manopola. Qualunque cosa accada, intuitivamente sappiamo come utilizzare questo ritardo per gestire “pentola + manopola gas  in esecuzione = ….”.

La stessa idea è altrettanto – se non più – importante all’interno di un team di sviluppo software. Senza un senso del ritardo tra lo stato originale e lo stato desiderato dato un certo intervento, è facile sotto o sovrastimare.

Durante il riscaldamento della vostra acqua per la pasta, non c’è bisogno di aspettare fino alla fine per vedere se è in bollitura: controllando di tanto in tanto, si può vedere se i tempi vanno come previsto. Si può essere in grado di vedere se l’acqua ha iniziato il processo di ebollizione ed è quasi tutta evaporata, oppure si riscalda lentamente e ti rendi conto che la manopola del gas è al minimo. Questo feedback aggiuntivo consente di gestire in modo più efficace. Ma se l’acqua bolle dopo 15 minuti in condizioni ideali, e siete a soli 10 minuti, non aspettatevi che sia eveporata.

Conclusioni

Ancora una volta, non spegnere il gas e  esclamare: “L’acqua non bolle! Non abbiamo bisogno di mangiare dopo tutto! “.

• Italiano

Translate original post with Google Translate

Stimare i costi e definire il processo di un'app è come rivedere Tempi Moderni

Perché gli sviluppatori non riescono a stimare di stimare il tempo di produzione?

Questa, come altre domande, sono lo spunto per scrivere un articolo che mi è stato ispirato dopo la lettura di un post di  Ash Moran mentre navigavo per il Patch Space Blog.

Introduzione
In passato, mentre ero dirigente (settore di Sviluppo) di grandi gruppi italiani, ho cercato molte volte di comunicare al vertice aziendale che determinare su un documento (Plan) le esatte tempistche delle diverse fasi di lavoro dello sviluppo di un software è un attività abbastanza inutile e che, semmai, serve solo a far lievitare drammaticamente i costi.
Con questo non voglio affermare che le pianificazioni, e i diversi report che ci impongono le grandi aziende, sono  inutili; questi report servono a fornire date di scadenza e di rilasco delle componenti in relazione ad un budget definito.
Il problema nasce quando ti capita come capo la classica persona (top-manager?) che non avendo mai neppure sviluppato un “hello world!” si ostina a cercare di voler capire cosa esattamente farai con la tua squadra e ti imporrà dei lunghi meeting in cui sarai costretto a dire numerose baggianate perchè le domande che ti faranno saranno talmente idiote da non poter far altro che costringerti a dettagliare le varie fasi del processo che tanto non comprenderanno del tutto.

Cercare di spiegare e dettagliare in anticipo le fasi di uno sviluppo software, come definire i tempi di  tutte queste singole fasi (o task) a un “Manager” che si ostina a voler capire come poter fare/controllare/comprendere il tuo lavoro è come chiedere ad un compositore musicista di spiegargli come farà a comporre una canzone e quando e come arriverà alla prima , alla seconda o alla terza strofa…
Sappiamo con certezza che ad un compositore si puo’ affidare la scrittura di un’opera e l’artista al massimo potrà dirci quando ce la consegnerà ma di certo nessuno con la testa sulle spalle potrà pensare di chiedergli esattamente cosa farà , quando lo farà e di fornirgli una data esatta in cui sarà arrivato all’ ennesima nota sullo spartito.

A questo punto uno dei tanti miei ex colleghi, che casualmente leggerà questo articolo, si dirà: “bhe ma in azienda a noi non servono grandi artisti come Mozart, ma solo mediocri esecutori che devono fare esattamente quel che diciamo”.
La mediocrità è ovviamente una componente essenziale di molti cosidetti “managers” della grande o media azienda italiana, quella mediocrità che ha portato un paese di artisti e navigatori ai margini dell’impero economico e culturale.
E’ quindi abbastanza facile intuire che il mio pensierò ha basi culturali completamente diverse, poichè lo sviluppo è a mio parere sinonimo di creatività e solo la creatività applicata, unitamente alla genialità, può portare risultati duraturi e tenere alti quei fattori che fanno di un’azienda un motore economico-sociale che non si arresta neppure con le crisi.
Semmai, per parafrasare Einsten, è solo con la crisi che si sviluppa la genialità.

Stimare il tempo o il rilascio?

Non possiamo stimare il tempo per ogni singola attività nello sviluppo di software in quanto la natura del lavoro è la creazione di nuova conoscenza.

L’obiettivo di sviluppo del software è quello di automatizzare i processi. Una volta che un processo è automatizzato, esso può essere eseguito ripetutamente, e nella maggioranza dei casi, in un tempo prevedibile.

Il codice sorgente è come un progetto di produzione, il computer è come una vera e a se stante azienda, gli ingressi (dati) sono come materie prime, e le uscite (dati o programmi) sono come prodotti finiti. Quindi la chiave di volta sta nella progettazione del processo, che è un compito complesso e costoso. Una volta che il processo è stato definito e reso efficente non c’è più bisogno di riscoprire questo processo, basta acquisire il modello.

Non è in realtà sempre un problema il fatto che i tempi di sviluppo sono in parte  imprevedibili, perché il rovescio della medaglia è che così è il valore restituito sarà maggiore; un software di successo può creare o salvare molto più del suo costo. Tom DeMarco, sempre citato da Ash,  sostiene la necessità di concentrarsi sui progetti di alto valore proprio per questo motivo. Si noti che questo approccio ha valore come generazione di un nuova mentalità, che porterà a superare l’attuale  prevalente mentalità basata quasi esclusivamente sul controllo dei costi . Questa è una questione tutt’altro che banale.

Una delle migliori spiegazioni della variabilità, e come sfruttarla per creare valore, è  nei “Principi del flusso di prodotto per lo sviluppo” di Don Reinertsen.

Regola generale: prendere le stime di uno sviluppatore, raddoppiare e aggiungere un po’

Il doppio-and-add-a-bit è una regola interessante. Quando i manager fanno questo, spesso  le attività vengono completate in tempo.

Voglio precisare che la pratica di stimare ogni task, o building block (come lo chiamano alcuni consulenti) puo’ portare alla richiesta di budget di gran lunga piu’ elevati del necessario; a questo proposito voglio fare un’esempio su un fatto che mi è accaduto realmente:
Qualche anno fa un grandissimo gruppo industriale mi chiese di dirigere un progetto per un portale intranet, che sarebbe stato utile ai dipendenti. Dopo le prime stime sull’utilità di un nuovo portale intranet e sopratutto dopo l’analisi degli eventuali costi risparmiati dal Gruppo con l’introduzione del self-service per i dipendenti, si cerco’ di stimare tempi e costi dello sviluppo.
Consegnai un breve rapporto, basato sulla forte esperienza pratica sul campo, in cui stimavo a spanne un budget di X euro e il rilascio graduale dei servizi entro un anno. Mi chiesero allora di dettagliare uno per uno i task , fino al singola piccola applet, e di definirne per ognuno tempi di rilascio e costi per task . Facendo questo mi ero accorto, seguendo il loro modello di stima, che in ogni singola pagina web potevano essere presenti anche una trentina di building blocks (…). Evidentemnte ho cercato di fargli capire che questa era una pratica del tutto superflua e che bastava proiettare delle medie rispetto alle esperienze pregresse e sopratutto in base al materiale disponibile e alle caratteristiche professionali del team di sviluppo.
Sono stato costretto a lasciare l’incarico quando un gruppetto di giovani consulenti d’azienda , che mai nella loro vita avevano neppure lavorato su un sisterma di sviluppo, hanno presentato un piano ben dettagliato in un mastodontico file power point (ppt) con bella grafica e in cui si definivano tutti i piccoli building block, uno per uno e si proiettavano scadenze e costo per ognuno di essi: risultato un budget da 7X euro in tre anni. Decisi di lasciare l’incarico sopratutto dopo che il mio sguardo si era soffermato su una decina di slides dedicate al servizio “calcolatrice” il cui costo era di alcuni giorni di lavoro. Ogni sviluppatore degno di questo nome sa che un building block “calcolatrice” lo si ottiene gratis e neppure si deve mostrare in un piano del genere… e questo non era neppure il fatto piu’ eclatante.
Inutile proseguire , poiche’ evidentemente il mio approccio non era piaciuto e mi sarei dovuto adattare a quello dei consulenti che hanno lasciato l’azienda qualche anno dopo, in fallimento, e con nessun portale intranet funzionante… dopo 4 anni la stessa azienda ha dovuto riaccendere il sistema precedente , e questo dopo aver speso piu’ del previsto e senza risparmiare alcun costo.
Questo racconto è importante per far capire ai decision maker che un software , come un’app per iPhone o un sito web è frutto di esperienza sul campo e questa non potrà essere mai sostituita da stime dettagliate e del tutto astratte , che spesso costringono al rispetto stretto dei tempi intermedi non curando il senso del progetto stesso.
A mio parere è proprio l’insistenza  ,da parte dei top manager, ad adottare modelli di stima basati sul modello finanziario e fondato sul controllo del prodotto che hanno portato l’industria informatica italiana ad una crisi cosi’ profonda che oramai parlare di industria informatica italiana non ha neppure piu’ senso…

Non sono solo agli sviluppatori a far male le stime.

Tutti prima o poi inprovviseranno perché gli sarà affidato un compito che non hanno mai fatto prima e non saranno in grado di effettuare con successo una vera stima fino a quando non hanno acquisito esperienza.
Se non sappiamo, non sappiamo, e dobbiamo dirlo. I clienti o i capi che vedono i progressi compiuti e sono stati messi al corrente  del rischio dei task (e hanno scelto di investire ) hanno molto di più fiducia nel proprio team ripetto ai clienti o ai capi che basano il loro controllo su stime.

La stima è una abilità molto importante e dovrebbe essere insegnata sopratutto a figure “junior”

Ciò che dobbiamo fare è insegnare a tutti gli sviluppatori junior il significato della parola “fatto” o “terminato”. Se un cliente o un capo viene a scoprire nel futuro, a un certo punto imprecisato,  che qualcosa è stato consegnato incompiuto (possibilmente in fretta per venire incontro alla stima) cio’ non solo rende la stima controproducente, ma rende inaffidabile tutto il calendario di lavoro con l’attuale processo. Questo problema è molto comune, e può causare una significativa perdita della capacità di un team di sviluppo.

Agile Developing

Nessuna grande e consolidata azienda ha avuto risultati straordinari come quelli avuti dalle società create da adolescenti o giovani imprenditori che non avevano, fortunatamente, alcuna idea dei modelli di lavoro , e di pensiero, che erano imposti dall’establishment e dall’economia finanziaria. Pensiamo a Mark Zuckerberg | Facebook, a Larry Page e Sergey Brin | Google, Sean Parker | Napster, Plaxo, Causes e Facebook.. pensiamo a Jeff Bezos, Bill Gates o a Steve Jobs e tanti altri.
Tutti questi personaggi hanno creato il nostro futuro e,  con tutta probabilità, non si sono mai adattati (per fortuna!) ai modelli aziendali e alla moda.

Negli ultimi anni , probabilmente a causa degli enormi Flop,  tutte le grandi aziende  hanno tentato di cavalcare l’onda della new economy e ora si ritrovano a terra, parlano molto di “Agile Developing“.
Il nome “Agile” ci arriva dall’ingegneria del software che differenzia i metodi e i modelli di sviluppo in:  Metodologie pesanti per i vecchi metodi basati sul Modello a cascata,  Metodologie iterative per i metodi basati sul Modello a spirale e  Metodologie agili per i metodi basati sui principi definiti nell’Agile Manifesto.
Leggendo Wikipedia si scopre che il termine “Metodologie Agili” fu coniato nel 2001 proprio quando il Manifesto Agile è stato formulato e che:
” La gran parte dei metodi agili tentano di ridurre il rischio di fallimento sviluppando il software in finestre di tempo limitate chiamate iterazioni che, in genere, durano qualche settimana. Ogni iterazione è un piccolo progetto a sé stante e deve contenere tutto ciò che è necessario per rilasciare un piccolo incremento nelle funzionalità del software: pianificazione (planning), analisi dei requisiti, progetto, implementazione, test e documentazione.
Anche se il risultato di ogni singola iterazione non ha sufficienti funzionalità da essere considerato completo deve essere rilasciato e, nel susseguirsi delle iterazioni, deve avvicinarsi sempre di più alle richieste del cliente. Alla fine di ogni iterazione il team deve rivalutare le priorità di progetto”.

Se si utilizza l’approccio agile si dovrà comunicare sempre in tempo reale, preferibilmente faccia a faccia, puttosto che fare report o documenti. Componenti di un team agile sono solo le persone necessarie per portare a termine il progetto.

Mi aspetto che qualcuno mi dirà: bella scoperta , quella dell’acqua calda…

Molto probabilmente parleremo nei prossimi articoli di questo metodo che molte aziende stanno implementando , anche perche’ importato da molte società di consulenza.

• Italiano

According to various rumors and mainly based on the statements of Richard Shim (DisplaySearch), the leading provider of display and LG, Samsung and Sharp would started production of Retinal Display for iPad3 with twice the resolution of 2048 × 1536 pixels. The screen will appear the same size as the iPad, 10-inch LCD (not AMOLED) with aspect ratio of 4:3.
Apple could  start the commercialization of iPad 3 new generation in the first quarter of , 2012.

We usually advise designers to create graphics for applications with very high resolution so its can, in future, be easily adapted to all IOS devices. For example, if the design of an icon or a splash page, what I continue to report to the graphics is that developers should never from low-resolution icons, which may be grainy on devices with higher resolution.
Experience teaches us about Apple aims high-quality graphics and is therefore expected that in future models screens are installed at more high density of pixels (dpi). But often the graphics and agencies prefer not to hand over files with these features in order to minimize the workload, a practice that will never be in line with the philosophy of i3Factory whose guidelines on the development are always trying to predict the next market moves.

As we know the images used for applications for the Apple devices are distinguished by a convention on the same file names of images, which provides that all images intended for Retinal Display your name must end with the characters @2x.
This agreement indicates just an image file to double the resolution, which in the case dell’iPhone4 is 960 x 640 pixels, while in the case of the iPad3 will be 2048 x 1536 pixels.
We note, for example, the file “image.png” iPad will have a canvas in any size 1024 x 768 pixels while the same file for retina display “image@2x.png”, for iPad 3 will have a canvas of resolution 2048 x 1536 pixels.

Taking up an article of melabog they discover that among the files of the new app iBooks  2 (Presented during the Apple event on January 19, 2012) have been found some graphics designed for a resolution of 2048 x 1536 pixels, as in the previous version of iBooks .

One of the reasons why some were already long on the production of a device with iPad Retinal Display it was the discovery of these high-resolution images already in the first version of iBooks, and also the same as Apple recommends developers to work with images high resolution, we can be sure that the following images unearthed by melabog in iBooks 2 as a confirmation of the presence of Retinal Display for iPad-3.

• Italiano

HTML(5) Approach
The final technique is something that is emerging now, especially thanks to the great improvements in term of stability and speed introduced by the latest version of iOS for the in-app web views. A couple of good examples of this approach are the Ars Technica app (link) and the Bloomberg Businessweek+ magazine (link).

The concept is quite simple: html and css are common and powerful techniques to layout a page on screen: why not leverage the skills developed by many web designers to make a magazine that perfectly fits with the iPad?
The core block at the base of this approach is the UIWebView Cocoa Touch object: with this view we can load any kind of html document, loaded locally or remotely, and layout it in the page at an adequate speed (but not the fastest) and without surprises. Besides we can get rid of the overlay
technique, as the web view is capable of displaying images, playing movies and of course execute javascript based widgets. Also this component provides a two way interaction between the javascript world and the objective-c runtime (and in fact this justifies the existence of extension languages
such as Objective-J, provided with the Cappuccino framework: http://cappuccino.org/). Finally the web view is highly respondent to user interactions, and some features like text selection and dictionary lookup come for free.
The open-source world is highly active in this area: projects like Baker (www.bakerframework.com), Siteless (www.siteless.org), Laker (www.lakercompendium.com) and pugpig (pugpig.com) make publicly available this kind of solution.

Sincerely we don’t know if this will be the final solution for everybody. Of course a publisher that already invested in setting up a web site (but not in Flash!), and this is quite common between newspapers, will be able to port most of the layout and contents to the iPad, and sometimes this can
be achieved with an adaption of the CMS output views to provide files that can be easily fed to the app.

Careful must be given to don’t push this behavior at its extremes: don’t forget in fact that web page rendering requires an inner engine and at the end any intermediate layer will require resources and extra time. Sometimes, and this is particularly evident with the first generation of the iPad, content
updates following user interaction are not very reactive. So it is not recommended to transform every single aspect of the magazine app into web based content: clearly in this way you’re helping all javascript developers not skilled with objective-c, but
a performance penalty will be visible.

As an example, the toolbar typical of all magazine apps used to access extra features (sharing, table of contents, home page, etc.) should always be done using the native Cocoa Touch component and not an html+css solution.

However if the publisher accepts to convert his design flow to a web based one and you, as developer, prefer to base your work on consolidated and easy to manipulate methodologies, this one should be your first choice to be taken in consideration.

Conclusions
We hope this article gives a good overview of the major techniques used to render pages in a magazine, newspaper or e-book. It could be we have not mentioned some technique we’re not aware of, in such case dear reader any feedback from you is welcome!

About the author: Carlo Vigiani
He is an electronics engineer and software developer, located in Italy. He is CTO and co-founder of new startup i3Factory.com, active in the development of iOS, Android and Win Mobile apps, with special focus on publishing, tourist and music apps.

Source: www.icodermag.com

01/2012