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)

No related posts.

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.

Related posts:

1. iOS: Tecniche per non appesantire le App; sviluppare per iPad 3
2. Stimare il tempo di sviluppo software, come per App iOS, iPhone e iPad, & Android
3. MockApp: un tool per il design di app per iPhone

Ancora una volta la stampa pubblica frasi d’impatto per far credere che anche il sistema Apple sia stato infettato da un Virus.

Sicuramente un tipo di infezione c’e’ stata ma come già avevamo spiegato in un precedente articolo , i sistemi basati su unix molto difficilmente possono essere infettati da virus veri e propri.

Quel che sta succedendo in questi giorni è che un Malware, e non un virus, ha infettato alcuni mac i cui utenti hanno disgraziatamente istallato una falsa estensione per flash, che di norma non andrebbe istallata senza le dovute precauzioni.

Chi possiede un Mac sa benissimo che il proprio sistema funziona a dovere e che prima di istallare aggiornamenti al di fuori dei metodi automatici e tradizionali bisogna informarsi in quanto si può rischiare qualche sorpresa.

Spiegheremo ora come rimuovere questo malware denominato Flashback, ma prima di farlo vi proporrò ancora una volta la differenza tra Virus informatico  e malware.

Riprendendo un vecchio articolo di youtek.it (http://youtek.it/differenza-tra-virus-e-malware/)  cerchiamo di capire le differenze , che a volte sembrano dei veri e propri rompicapo dei tecnici;

Cos’è un virus?

E’ un frammento di software, che una volta avviato infetta file,cartelle, registro di sistema insomma tutto cio’ che trova sul nostro pc! Ovviamente piu’ e’ potente il virus piu’ danni causa.

Spesso quelli di alta’ pericolosita’ sono difficilmente rintracciabili dall’utente.

Cos’è un Malware?

E’ un qualsiasi software creato per danneggiare un computer o un sistema informatico. Dove esso puo’ causare vari danni di varie identita’. Non a caso il nome MALWARE che significa letteralmente “Programma Malvagio” o piu’ corretto chiamarlo Codice Maligno.

Cio’ che non mi piace è che molti autorevoli testate giornalistiche hanno aperto la sezione tecnologia con titoli e sottotitoli che inneggiavano al fatto che Apple avesse un virus, che avesse perso la verginità e che addirittura questo suddetto virus fosse pericolosissimo.

Risulta totalmente inutile cercare di capire il motivo di tanta superficialità, ignoranza e poca innocenza da parte di quei giornalisti che, senza pudore, scrivono di cose si cui non capiscono quasi nulla o peggio hanno solo voglia di confondere le idee , già peraltro confuse, dei tanti lettori che si definiscono non tecnici.

La verità e la decenza

Ovviamente la verità non è a disposizione di tutti ma cercherò comunque di definire l’argomento e di spiegare come rimuovere questo malware.

L’allarme infezione viene lanciato da Dr. Web, un’azienda russa di antivirus, e prontamente Apple ha già rilasciato il codice (patch) per evitare di incappare in questo pericolo poiché Flashback viene istallato nel sistema utilizzando una vulnerabilità Java dei browser internet Safari camuffandosi da estensione per Flash che viene chiesto di istallare.

Per evitare che il proprio mac sia esposto a rischi, è necessario installare quanto prima la patch Java proposta da Apple.

Queste le note di rilascio da Cupertino:

Java per Mac OS X 2012-001 fornisce una migliore compatibilità, sicurezza e affidabilità aggiornando Java SE 6 alla versione 1.6.0_31.

Chiudi tutti i browser e le applicazioni Java prima di installare questo aggiornamento.

Consulta: http://support.apple.com/kb/HT5055?viewlocale=it_IT  per ulteriori dettagli su questo aggiornamento.

Consulta: http://support.apple.com/kb/HT1222?viewlocale=it_IT  per informazioni sul contenuto di sicurezza di questo aggiornamento.

oppure

e’ stata rilasciata un’ applicazione  di terze parti che, vi permette in due fasi il controllo:

1. Scaricate FlashbackChecker – Download -
2. Decomprimere ed eseguire l’applicazione FlashbackChecker e cliccate sul pulsante “Check for Infection Flashback”

Se viene visualizzata la voce “No Signs of infection were found”(Nessuna infezione è stata trovata) significa che le probabilità che il vostro Mac sia infetto sono bassissime. Se invece appare un messaggio “Potential Issue found” (Trovato Potenziale problema) il vostro Mac potrebbe essere infetto.

Rimozione Manuale

Di seguito riportiamo rimozione del malware come redatta da F-Secure.

1 – Aprire il terminale e digitare “defaults read /Applications/Safari.app/Contents/Info LSEnvironment”
2 – Prendere nota dei codici DYLD_INSERT_LIBRARIES e premere nuovamente invio
3 – Se si riceve un messaggio d’errore simile a “The domain/default pair of (/Applications/Safari.app/Contents/Info, LSEnvironment) does not exist” non si è infetti.
4 – Se i file vengono effettivamente trovati, digitare “grep -a -o ‘__ldpath__[ -~]*’ %percorso_del_punto_2% ” e prendere nota del valore di fianco a “__ldpath__”
5 – Eseguire i comandi “sudo defaults delete /Applications/Safari.app/Contents/Info LSEnvironment” e “sudo chmod 644 /Applications/Safari.app/Contents/Info.plist”, cancellando poi i file trovati nel secondo punto e nel quarto.
6 – Eseguire il comando “defaults read ~/.MacOSX/environment DYLD_INSERT_LIBRARIES” e, se si riceve un messaggio come “The domain/default pair of (/Users/joe/.MacOSX/environment, DYLD_INSERT_LIBRARIES) does not exist” il trojan è stato correttamente rimosso. In caso contrario, eseguire nuovamente “grep -a -o ‘__ldpath__[ -~]*’ %percorso_del_punto 4% “, prendendo nota dei valori.
7 – Dopo aver eseguito “defaults delete ~/.MacOSX/environment DYLD_INSERT_LIBRARIES launchctl unsetenv DYLD_INSERT_LIBRARIES”, cancellare i file indicati nei punti precedenti.

Scheda del Malware 

Come riportato da F-Secure il malware viene definito come trojan (cavallo di troia)

Detection Names:Trojan-Downloader:OSX/Flashback.K

Category :Malware
Type:Trojan-Downloader
Platform:OSX

Related posts:

1. Downgrade di IOS: come far tornare il vostro iPhone e iPad aggiornato con iOS 5.0.1 a iOS 4.3.3 / 4.3.4 / 4.3.5 / 5.0.0
2. Virus per Mac Osx, le solite storie. Tsunami è un semplice trojan Pdf
3. Apple Store: no RSS applications?

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.

Related posts:

1. iOS: Tecniche per non appesantire le App; sviluppare per iPad 3
2. Progettare App: disegnare Mockapp direttamente con iPad
3. Disegnare per iPhone 4 Retina Display

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.

Related posts:

1. Stimare il tempo di sviluppo software, come per App iOS, iPhone e iPad, & Android
2. Riviste e Magazine: Tecniche di Page Rendering #parte 4 : pagine da immagini
3. Riviste e Magazine su iPad: Tecniche di Page Rendering #parte 1

• English

Sempre più spesso i nostri clienti e lettori inviano delle proposte per lo sviluppo App senza utilizzare uno standard documentale e senza utilizzare quelle terminologie che possano aiutare  a comprendere correttamente quanti e quali funzionalità l’app proposta dovrebbe possedere.

Se volete trasmettere un’idea che permetta di creare un’app per iPhone, iPad o Android  è necessario preparare un vero e proprio Mockapp e/o Documento Funzionale nel quale verranno dettagliate tutte le funzionalità della vostra app per iPhone o iPAd o Android unitamente ad un layout che faccia comprendere la User Interface e la User Experience.

Cooker App – Design, Mockup e Prototype Apps interfacce app su iPhone

Qualora vogliate utilizzare il vostro iPad come strumento per preparare il mockapp prototipale, vi segnalo App Cooker (sito web: http://www.appcooker.com/).

Segnaleremo invece nel prossimo articolo sull’argomento quale sono gli strumenti che potrete utilizzare  con il vostro Mac o Pc.

Molte persone hanno abbamdonato quasi del tutto l’uso del computer e si affidano all’iPad per inviare email, fruire dell’Internet e utilizzare strumenti di lavoro;

App Coocker è un’app per iPad e la consideriamo uno strumento utilissimo , se volete portare le vostre idee ad uno stadio di possibile realizzazione.

App Cooker, è attualmente  presente in App Store al prezzo di 15,99 € , che secondo alcuni rumors aumenterà a 24$ alla prossima versione;   l’applicazione (per iPad) è sviluppata da HotAppsFactory e , come abbiamo detto, serve  a progettare applicazioni per iPhone e iPad..

L’ App Board raccoglierà i vostri piani concettuali, mock-up, icone, Scheda Negozio App e la strategia dei prezzi.
Sarà la spina dorsale di ogni vostro progetto e permette di lavorare in modo organizzato e chiaro.

Di seguito il video in lingua inglese direttamente dal sito ufficiale:

Definire le idee

Iniziamo con un’idea, uno schizzo e utilizziamo questa l’App per organizzare e ispirare le idee.
L’idea è l’essenza stessa di una qualsiasi applicazione e richiede momenti si riflessione e di attenzione.
App Cooker fornisce uno strumento dedicato per questo, fornendo preziosi consigli raccolti da Apple e da altri professionisti del settore.

iOS Mockups

Il motore di mockup supporta l’orientamento , semplici link e unisce assime la  UI di Apple(interfaccia utente) con disegni bitmap, forme vettoriali, testo e immagini.
I prototipi possono prendere vita, senza una sola riga di codice.

L’ Icona marchio di fabbrica dell’App

L’icona è il volto della vostra applicazione. La creazione di grandi icone richiede sperimentazione e diversi tentativi fino a quando la soluzione ideale non sarà trovata. Utilizzando i tool a mano libera, con forme vettoriali o immagini potrete definire l’aspetto delle icone delle vostre idee e vedere i risultati nelle varie dimensioni e in poco tempo.

Strumento Prezzi
App Cooker consente di confrontare un gran numero di scenari di prezzo per trovare il  giusto modello per la vostra applicazione. Supporta sia gli acquisti app che la pubblicità, il che rende facile prevedere ricavi, costi e profitti.

Descrizioni App Store

La descrizione sul prodotto pagina di iTunes è un fattore decisivo per i potenziali acquirenti. App Cooker rende lo scrivere queste informazioni un compito semplice, e fornisce un luogo per localizzare in uno qualsiasi dei App Store di 18 lingue.

Mock-up prima dello sviluppo di codice

Progettare una buona applicazione è difficile. Si deve possedere  creatività, il talento, le risorse, la conoscenza, il tempo e un forte senso di autocritica; le app di successo sono sempre il risultato di un lungo processo di raffinazione.

Abbiamo speso tantissimo tempo, con i tanti clienti e le diverse aziende che ci contattano, per cercare di spiegare il modo migliore di progettare applicazioni per iPhone , iPad e Android.

Con il tempo prima o poi tutti scoprono che la progettazione di un applicazione è molto più che solo il design grafico.

Di seguito vi enuncio  i 10 Principi che ho raccolto dal sito di App cooker:

1) Definire l’idea con precisione

2) Soddisfare le esigenze degli utenti

3) Descrivere un’ importante Interfaccia Utente e Esperienza Utente

4) Utilizzare Grafica sofisticata

5) Iterare per raggiungere la perfezione

6) Essere semplici ma eleganti

7) Un  Icona pulita e “chiara”

Parlare a tono basso ma chiaramente

9) Stabilire un prezzo onestamente

10) Pensare Mobile e Tattile

Per concludere,

App Cooker si configura come una applicazione professionale, in quanto permette di progettare tutti gli elementi di una applicazione compatibile con tutti i dispositivi Apple iOS.

Rivolgendosi a tutti coloro i quali hanno intenzione di far sviluppare una propria applicazione,  innanzitutto si dovrà mettere in chiaro l’idea iniziale, la compatibilità con i vari dispositivi e le varie funzionalità, successivamente bisognerà creare i vari elementi grafici del mockup, l’icona, la localizzazione sull’App Store e le prospettive di diffusione e di guadagno.

Related posts:

1. Come pubblicare una rivista o magazine per iPad con HTML5
2. made in Modena: Camera di Commercio con i3Factory su App Store
3. MockApp: un tool per il design di app per iPhone

Pentiti dell'aggiornamento IOS5, downgrade di iPhone e iPad al sistema precedente

Questa procedura è dedicata a tutti gli utilizzatori sui iPhone 4 e 3GS, iPad 1 e 2 e iPod Touch che hanno aggiornato il proprio sistema operativo e che, per diversi motivi, vogliono tornare indietro.

Ho scritto questa breve guida dopo aver aggiornato il mio vecchio iPad 1 con la versione 5 di IOS. Dopo questa operazione l’iPad 1 sembra essere molto piu’ lento di prima e la batteria sembra anche durare meno, per cui ho deciso di ritornare alla versione 4.x dato che un “vecchio” dispositivo funziona sicuramente meglio con un “vecchio” sistema operativo.

Tutto questo vi sembrerà assurdo, dato che ho definito vecchio un dispositivo che  ho acquistato un anno fa; a questo proposito Vi consiglio un documentario che fa capire cosa e’ esattamente la “obsolescenza programmata” e che potete visionare su questo blog: http://energiasi.com/obsolescenza-programmata/

Avete Aggiornato il firmware del vostro iPhone, iPad o iPod touch?

Qualora abbiate aggiornato il vostro device Apple ad iOS 5.0.1 ma volete tornare indietro siete ancora in tempo per effettuare il cosidetto downgrade di sistema operativo.
Limitazione: se siete dei developer e i vostro dispositivo è stato aggiornato alla versione di iOS 5.1 (disponibile per il momento solo per gli sviluppatori iscritti al Developer Program) non potete effettuare il downgrade dato che  questo tipo di operazione è stata direttamente bloccata da Apple.

Prima di tutto
Se non avete salvato i certificati SHSH del vostro dispositivo non potrete andare avanti.

I certificati SHSH sono indispensabili per le procedure di downgrade ad un firmware meno recente.Consigliamo dunque a tutti gli utenti interessati  di salvare i propri certificati SHSH con il software TinyUmbrella, che potete scaricare da questa pagina.

TinyUmbrella, è un’ utility sviluppata da Notcom che permetterà di salvare i certificati SHSH sul computer.
Disponibile sia in vesione Mac che Win necessita di  Java installato sul proprio pc.

Procedura per salavare i dcertificati SHSH

• Avviare TinyUmbrella

• Collegare il dispositivo iPhone o iPad o iPod al computer
• Cliccare su Save SHSH. Il software salverà  i certificati SHSH sul vostro disco.

Solo ora possiamo procedere ad effettuare il  downgrade.

Downgrade di firmaware iOS

Mettete il Vostro iPhone, iPod Touch o iPad  in modalità DFU:

• Spegnere il dispositivo

• Riaccendere tenendo premuto contemporaneamente gli unici 2 tasti ( Power + Home) per circa 10 secondi,quindi  rilasciare il tasto Power e continuare a tenere premuto il tasto Home per altri 10 secondi

•     A questo punto non vi resta che collegare l’iPhone, o l’iPad, al  computer:

Su Windows o Mac, andiamo ad aprire il file hosts  (ad esempio, il percorso potrebbe essere su windows  Sistema -> Driver -> Etc. -> Hosts mentre su Mac per modificare il file host su Mac Os x dovete seguire questi passi:

1. Clicca su Finder
2. Clicca su Applicazioni
3. Entra nella cartella Utility
4. Clicca due volte su Terminale
5. Copia e Incolla la seguente stringa nel terminale:  sudo /Applications/TextEdit.app/Contents/MacOS/TextEdit /etc/hosts
6. A questo punto inserisci la password di sistema e premete invio
7. Il file Hosts verrà aperto in textEdit dove potrai editarlo e successivamente salvarlo

NB: Effettuiamo un copia di questo file per sicurezza, poi apriamolo con un qualsiasi editor di testo

•     Con il file aperto alla fine del testo, incolliamo questo codice :
  74.208.105.171    gs.apple.com
•    Salviamo il file

•     Apriamo iTunes e procediamo con il Restore del nostro device premendo il tasto Shift (Windows) o Alt (Mac)

•     Verrà richiesto di scegliere un nuovo firmware da caricare: quindi precedentemente dobbiamo aver scaricato la versione di iOS che vogliamo sul nostro device (possiamo scegliere iOS 4.3.3, 4.3.4, 4.3.5, …).

In questo modo, abbiamo effettuato il downgrade di iOS!

NB: Qualora comparisse un messaggio d’ errore dopo aver selezionato il firmware dovrete aprire TinyUmbrella e cliccare sull’ opzione Exit Recovery.

Allego un Video tra i tanti presenti su youtube, in lingua inglese:

Related posts:

1. Costo App iPhone & iPad, fare un’app per iOS richiede un sacco di lavoro!
2. Pubblicare riviste, giornali, magazine su iPad con i3Factory Editorial
3. Le dimensioni delle ICONE per iOS (iPhone, iPad, osX)

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.

Related posts:

1. Metodologia “Agile” per il project manager
2. Stimare il tempo di sviluppo software, come per App iOS, iPhone e iPad, & Android
3. Suggerimenti per la creazione di Icone e Artworks per il Retina Display

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! “.

Related posts:

1. Stimare il tempo di sviluppo software, come per App iOS, iPhone e iPad, & Android
2. K-Team presenta i Corsi i3Factory a DIDAMATICA 2011 (AICA, Politecnico di Torino)

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.

Related posts:

1. Costo App iPhone & iPad, fare un’app per iOS richiede un sacco di lavoro!
2. TestFlight, come testare le nostre app iOS beta testing on the fly
3. MockApp: un tool per il design di app per iPhone