Octo a récemment participé à la réalisation de l’application iNomineo pour iPhone (cf  OCTO Technology accompagne Generali sur l’iPhone ) :

Pourquoi avons nous mis en place une usine de développement (UDD) suite à ce projet ? A première vue, cela soulève plusieurs questions :

• La mise en place d’une UDD relève d’une problématique d’industrialisation : comment rendre plus productif un process que l’on maîtrise. Alors qu’un projet iPhone évoque plutôt l’innovation : un langage peu connu, de nouveaux outils, une nouvelle plateforme.

• Une UDD a pour vocation de simplifier le travail d’intégration entre les différents développeurs : plus ceux-ci sont nombreux, plus l’UDD se révèle payante. Or nous n’étions que 3 développeurs sur ce projet, on aurait tendance à penser que l’on peut gérer cet effort d’intégration « à la main ».

• L’UDD a également pour rôle d’automatiser l’exécution des tests, or une des particularités d’une application iPhone c’est la prédominance de l’interface graphique (réputée couteuse et compliquée à tester), de plus quels outils peut-on utiliser ?

• Pour finir, l’iPhone souffre encore de l’image du jeune étudiant faisant fortune sur l’appstore : ce type de projet véhicule pour certains une image d’amateurisme, « c’est un travail à confier à un stagiaire ».

Pourtant l’expérience nous a montré qu’une UDD et la pratique des tests unitaires apportent des solutions à des problèmes récurrents sur le projet.

De plus, la mise en place d’une UDD avec une couverture de test conséquente et les métriques associées sont un moyen d’apporter un gage de qualité et de professionnalisme à un projet iPhone.

Dans cet article, nous couvrirons les raisons concrètes qui nous ont poussé à le faire, et comment nous y sommes parvenus.

Dans un prochain article, nous verrons quelles pratiques de test mettre en place sur un projet iPhone (les outils, les méthodes, les bonnes pratiques).

(Lire la suite…)

Voilà déjà dix minutes que Gus est coincé dans cet embouteillage… Il s’exaspère; il est en retard. Ca y est, problème identifié : une bête boite blanche qui trône au milieu de la file de droite. Ah non, ce n’est pas une boite, c’est un vieux micro-ondes ! Un coup de volant à gauche, et Gus est reparti. En route!

Bien sûr, Gus pourrait s’arrêter et descendre de voiture pour dégager ce débris sur le bas côté. Tout le monde en profiterait. Mais Gus est déjà très en retard. Après-tout, le problème est derrière lui maintenant. La voie est libre, il en profite.

C’est situation représente un anti-pattern caractérisque, appelé tragédie des biens communs, et qui s’énonce ainsi :

L’accès libre à une ressource limitée pour laquelle la demande est forte conduit à une surexploitation de cette ressource et à sa détériotation. (Lire la suite…)

Lors de la prochaine session du JUGL,  le jeudi 11 février (la semaine prochaine), j’aurai le plaisir de vous présenter le framework web Wicket.

Wicket est un framework web Java orienté composant (par opposition aux frameworks MVC)

Pouvez-vous inscrire pour nous aider à anticiper le nombre de places nécessaires ?

http://www.jugevents.org/jugevents/event/23397

Merci et à la semaine prochaine !

PS : un petit lien vers ce blog dont je me suis honteusement inspiré pour le jeu de mot

Communiqué de presse OCTO, 03/02/10

Dévoilée à l’occasion du salon Patrimonia 2009 (les 1er et 2 octobre 2009), la première application iPhone de Generali a rencontré un franc succès. Elle a été récemment publiée sur l’AppStore. Pour développer cette application inédite, Generali a fait appel aux équipes d’OCTO, qui sont intervenues pour apporter leurs compétences en gestion de projet agile et en développement iPhone. (Lire la suite…)

La conception est une étape clé de la réalisation d’une application iPhone. C’est à cette étape que l’on valide la disposition des écrans, les objets affichés, les enchainements, etc.

C’est également à cette étape que l’on va éventuellement revenir sur des fonctionnalités ou en ajouter de nouvelles. Pourquoi ? Parce que l’écran est trop petit, que tel bouton n’est pas assez gros, que telle fonctionnalité n’est accessible qu’après 4 écrans en bref pour rattraper les erreurs et valider le reste … (Lire la suite…)

Il est tout chaud, il est tout beau et il sort du four: voici le nouveau livre blanc OCTO sur l’usabilité et les Interfaces Homme Machine!

Soyons franc, c’est une beta mais appliquons à nous-mêmes ce que nous conseillons à nos clients : livrer vite, obtenir du feedback et s’améliorer. Nous allons donc reprendre un mode de fonctionnement inauguré par l’Informatique Conviviale et publier chaque semaine une (ou plusieurs) parties de ce livre blanc en mode beta (c’est-à-dire avec du contenu quasi-finalisé) pour vous permettre de réagir dessus et nous permettre d’affiner nos messages et idées. Pour les amoureux du PDF, rassurez-vous: une version packagée et finalisée sera disponible sur le site OCTO (comme pour les autres livres blancs OCTO).

(Lire la suite…)

Depuis plus d’une dizaine d’années, l’administration a lancé un ensemble de chantiers lui permettant d’entrer dans l’ère numérique. A leur rythme, nos différents ministères, collectivités et organismes d’état ont informatisé leurs procédures : renouvellement de papiers, création d’entreprise, déclarations fiscales … ces télé-procédures ont répliqué les processus existants, en les dématérialisant. Utilisées par la moitié des français , elles se heurtent aujourd’hui aux mêmes limites que les entreprises privées avec leur informatique : faire plus de la même chose ne créera que peu de valeur supplémentaire. Nous pouvons optimiser le système de télé-déclaration fiscale, mais cela ne résoudra pas les aberrations et parfois les dysfonctionnements liés à l’organisation des circuits de traitement de la chaîne fiscale, qui va du calcul au recouvrement de l’impôt. De même pour nos systèmes électroniques de santé, qui peinent à faire mieux collaborer médecine de ville, hôpitaux, ou pharmacies.

Alors au fond quel est le problème ? Il me semble que deux contraintes majeures pèsent sur l’émergence de systèmes d’information qui transforment les services publics au plus grand bénéfice des usagers et des personnels administratifs.

La première est l’approche « tout ou rien », qui impose de délivrer dès le départ un service uniforme sur tout le territoire. Cette volonté « égalitaire » nuit aux nécessaires expérimentations de systèmes qui engagent le plus souvent de difficiles réformes d’organisation. Cette approche « nous devons tout prévoir du premier coup » est relayée par le code des marchés publics, et la lenteur des cycles qu’il impose. Impossible dans ce contexte d’embaucher une équipe stable pour lui faire délivrer un système qui se construit peu à peu avec ses premiers utilisateurs … Ce sont pourtant les méthodes qui permettent d’innover de la manière la plus fluide.

La seconde relève de notre peur du « grand fichier », de la nécessaire protection de la vie privée. Pour avoir participé à de nombreux échanges sur service-public.fr, la posture « tout est interdit, tout est cloisonné » s’oppose aux nouveaux usages communautaires engageant à plus de partage et d’interopérabilité. Après avoir dépensé des sommes colossales pour un système d’authentification ultra-complexe à base de certificat, le ministère des Finances a finalement rebasculé vers un procédé plus classique, identique à Facebook, ma banque ou à l’Intranet de mon entreprise. Mais au-delà de l’authentification, ce sont toutes les données manipulées qui subissent interdiction et cloisonnement. Vous pouvez voir ma photo sur LinkedIn, mais pour l’administration, c’est encore un secret d’état.

Mais pendant ce temps, des acteurs privés, essentiellement américains, se lancent sans ces deux contraintes, dans des systèmes permettant aux citoyens et aux agents administratifs de partager, échanger et collaborer dans des réseaux sociaux de « service public ». San Francisco ouvrant ces données (datasf.org) ou Google Health offrant un Dossier Médical Personnalisé pour mieux le partager en toute sécurité avec ses proches et ses soignants, nous montrent une voie inédite, qui nous permettrait peut-être de « percer le plafond » avec nos Technologies de l’Information.

L’administration est donc à un tournant : soit elle décide qu’il est important qu’elle possède et gère ses systèmes électroniques, et elle devra alors faire sauter les deux contraintes qui l’empêchent de les délivrer, en revisitant notamment sa politique de construction et de sécurisation. Soit elle décide d’utiliser ces fournisseurs comme facteurs externes de modernisation, mais en l’assumant et en l’encourageant.

Et vous, que choisiriez-vous ?

En tant que consultant, il m’est arrivé d’intervenir au sein de plusieurs équipes de développement pour les aider à devenir Agiles. Alors que ce type de méthode trouve une certaine popularité au sein du monde informatique, j’ai eu l’occasion d’observer quelques comportements assez différents dans la manière dont l’agilité s’installe dans ces équipes.

On peut dire que c’est le contexte, mais on peut aussi allez plus loin. Jean-François Helie vous avait présenté les différentes phases de développement d’une équipe en mars derniers, je vous propose à mon tour de creuser un autre modèle avec celui de Bruce Tuckman.
(Lire la suite…)

Développer ou déployer sur le Cloud ?

Avant toute chose, il convient de faire la différence entre développer pour le Cloud et déployer sur le Cloud. Pour simplifier, avec les plateformes IaaS comme celle d’Amazon, on déploie sur le Cloud des machines virtuelles qui embarquent une architecture d’entreprise classique. Il n’est donc pas nécessaire d’intégrer des pratiques de développement propres au Cloud.

Par contre, lorsqu’on adresse des plateformes PaaS, comme Google Apps Engine, Force.com ou Azure, il est nécessaire d’adapter ses développements. En effet, les PaaS proposent des architectures spécifiques et contraintes : en particulier sur les modes de persistance, les temps d’exécution. Et chaque PaaS a ses propres contraintes. Avec les PaaS, on parle véritablement de développement pour le Cloud.

(Lire la suite…)

« Le Blackberry c’est pour les entreprises et l’iPhone c’est pour les particuliers ! »

Les préjugés ont la vie dure et particulièrement concernant l’iPhone. Depuis 2 ans et demi Apple a su rendre son téléphone attractif pour les entreprises (support d’Exchange et Active Directory, push mail, outils de déploiement, …) et l’avènement de l’AppStore et ses applications directement disponibles pour les entreprises (Oracle, Salesforce, WebEx, …) a renforcé cette position.

La marché des applications mobiles a généré 4,2 milliards de dollars en 2009 et devrait s’établir à 6,2 milliards en 2010. 99,4% des applications achetées en 2009 l’étaient pour l’iPhone. (source Gartner)

L’iPhone et son AppStore n’est pas un effet de mode mais une tendance de fond que les entreprises ne peuvent plus ignorer. Sortons des sentiers battus et répondez aux questions que vous vous posez :

• Comment équiper son entreprise d’iPhone ? Est-ce sécurisé ? Est-ce compatible avec mon existant ?
• Comment concevoir une application iPhone ? Quelles sont les spécificités à connaître ?
• Comment développer ? Avec quels outils ? Comment s’intégrer au SI ? Comment sécuriser ses applications ?
• Comment déployer ? Sur l’AppStore ? Autrement ?
• Pour quels retours ?

Generali viendra également partager son retour d’expérience sur les développements iPhone et la m-assurance.

C’est dans ce but que nous organisons un petit déjeuner sur le thème « iPhone as a business platform » le 9 Février 2010 à l’Atelier BNP Paribas.

Plus d’informations et inscriptions : Petit déjeuner iPhone as a business platform