Développer sur plusieurs plateformes mobiles

Les OS nomades

Si dans le marché de la mobilité les terminaux Android et iOS (iPod, iPhone, iPad) restent les vedettes incontestées, dans le domaine des smartphones, Windows phone de Microsoft n'est pas forcément à écarter, ni Blackberry même si on peut s'interroger sur la pérennité de ce dernier.

On retrouve à peu près les mêmes OS dans les tablettes tactiles et les smartphones, même si Microsoft propose deux OS différents : Windows 8 pour les tablettes et Windows phone pour les smartphones. Pourtant la frontière entre ces deux mondes est de plus en plus floue en particulier depuis l'arrivée des fablets (ou phablets), qui sont des smartphones avec une taille d'écran entre 5 et 7 pouces.

Certains OS sont dérivés d'Android, comme Amazon Fire OS, qui est une adaptation par Amazon pour ses tablettes et son smart phone (http://en.wikipedia.org/wiki/Fire_Phone). Sans aller aussi loin, les constructeurs qui utilisent Android ont aussi des spécificités qui peuvent aller  au delà de la taille et de la résolution de l'écran. Aussi, lorsque l'on envisage le test d'une application, on ne peut pas se contenter de faire les tests uniquement sur la plateforme de développement.

Selon l'OS retenu, la plateforme de développement n'est pas la même et les coûts non plus (licence développeur, matériel). Par exemple:

• Apple fournit X-Code qui ne fonctionne que sous MacOS. Il faut donc posséder un Mac et s'acquitter d'une licence d'au moins 99$ par an pour pouvoir tester sur iPod, iPhone ou iPad, et publier sur l'App store.
• Pour Android, Google fournit ADT qui est un environnement basé sur eclipse. Celui-ci n'est pas lié à un OS spécifique (Windows, Linux, ...). La licence est de 25$, pour pouvoir publier les applications sur Google Play.

Chaque plateforme a son ou ses langages de prédilection, par exemple Objective C pour iOS, Java pour Android, Java pour Blackberry, et pour Windows Phone VB.NET, C#,...

Notez qu'Android possède l'avantage de permettre à une même application d'adapter automatiquement son affichage au terminal avec la technologie des fragments. Avec iOS, il faut développer une interface spécifique pour chaque type de terminal ce qui a un coût supplémentaire.

Que choisir ?

Selon le marché ciblé, on peut être amené à choisir un OS particulier. Souvent on développe une application pour un OS, puis on développe l'équivalent pour un autre OS. Néanmoins, il est possible de faire un développement qui s'adaptera en grande partie aux différents OS et aux différents types de terminaux. C'est ce que permet notamment Apache Cordova (http://cordova.apache.org/).

Le principe est que l'on développe l'application cliente comme une application WEB, en utilisant les technologies similaires : HTML5, JavaScript, CSS3, le tout en intégrant vos librairies JavaScript favorites (jQuery, Mojo, ...). Puis on génère l'application pour l'OS cible. Il est même possible de faire du « responsive design » autrement dit d'avoir une application qui s'adapte à l'écran du terminal en termes de surface et de résolution.

Possibilités et limitations

Si utiliser Apache Cordova peut permettre de gagner du temps, il vaut mieux regarder de plus près les restrictions.

Tout d'abord on ne peut accéder à toutes les fonctionnalités de chaque OS. Par exemple la gestion de système de fichiers étant totalement différente sous Android et iOS, il ne sera pas possible de gérer des fichiers dans l'application à moins de faire des développements spécifiques ou d'opter pour un contournement, comme l'utilisation d'une base de donnée (SQLite dans les deux cas) pour stocker les données.

L'accès aux APIs spécifiques de chaque OS, se fait via des plugins. Néanmoins, il n'existe pas forcément un plugin pour chaque API dont on a besoin. Les applications doivent donc être assez simples.

Apache Cordova permet de développer des applications avec une interface de type WEB, donc assez passe-partout non spécifique à l'OS. Si vous voulez respecter l'ergonomie propre à chaque OS, il faudra faire des développements spécifiques.

Enfin les applications conçues avec Cordova seront moins rapides qu'un développement natif, qui lui, sera bien plus optimisé. Donc pas question de faire d'animation trop évoluée, de faire des jeux, ou d'utiliser intensivement les capteurs du terminal. Un accès simple à un CMS, par exemple, est plus adapté.
 

Le test des applications

Le test sur chaque plateforme cible est fortement conseillé car une même application ne se comporte pas totalement de la même façon selon l'OS mobile mais aussi selon la marque du mobile. Par exemple sous Android, les constructeurs peuvent ajoutent ou implémentent des couches qui leurs sont propres. Il peut donc y avoir des bugs et des comportements spécifiques à la version d'Android mais aussi au constructeur.

Si on automatise les tests, ce qui est aussi conseillé, il faut noter que les frameworks de tests proposent en général le support d'Android et d'iOS. Attention toutefois, car certains ne s'exécutent que dans le simulateur de terminal qui s’exécute sur la plateforme de développement... Hors ces tests qui tournent sur un PC ou un Mac même s'ils sont utiles, ne garantissent pas à 100% la bonne exécution et le bon rendu, sur les appareils cibles.

Conclusion

Un framework comme Apache Cordova qui permet de développer « une fois » pour plusieurs plateformes, peut s'avérer être un choix judicieux pour une application avec une interface de type WEB. Il convient de tenir compte du contenu fonctionnel de l'application à développer, des performances requises, et de l'ergonomie souhaitée.

Des développements spécifiques peuvent être nécessaires pour s'adapter correctement à chaque OS cible. Dès lors, si on gagne du temps en faisant des développements communs aux OS, il faudra quand même avoir des sous projets spécifiques à chacun et faire les tests correspondants.

La problématique se pose aussi en termes de compétences. Car Apache Cordova nécessite des compétences WEB et mobile. Hors en cas de développements spécifiques selon la plateforme, il faudra que les développeurs connaissent suffisamment chacun des OS et langages associés.

Une évaluation préalable est donc nécessaire pour déterminer l'intérêt d'un tel type de framework par rapport au projet de développement ainsi qu'à l'entreprise. On pourra ainsi choisir en connaissance de cause soit de faire autant de développements entièrement spécifiques à chaque OS cible, soit d'utiliser un framework comme Apache Cordova.

Quelques liens pour aller plus loin:

http://www.nextinpact.com/news/89231-android-ecrase-marche-smartphones-tire-par-succes-forks.htm

Les parts de marché des OS
http://www.zdnet.fr/actualites/chiffres-cles-les-os-pour-smartphones-39790245.htm

Responsive design / Responsiveness
http://www.wired.com/2013/11/responsive-html5-apps-write-once-run-anywhere-where-is-anywhere/
http://fr.wikipedia.org/wiki/Site_web_adaptatif

98% des applications Android tournent sur Blackberry:
http://www.blackberry-fr.com/blackberry-10-98-applications-android-compatibles/

2) Réécrire un logiciel de A à Z ou ne rien faire, où comment sortir du statu quo

Qui va le faire et comment ?

Est-ce le manager qui va décider de tout ? Comment va t-il obtenir les mesures attendues ? Qui est le plus pertinent pour indiquer une amélioration et son ROI ? Comment trouver le temps et l'argent pour mettre en place des améliorations ? Comment s'assurer qu'une amélioration a produit le bénéfice attendu ?

Pour avoir la liste des améliorations et mesures, appliquons un des principes du Lean : impliquons les personnes de l'entreprise qui subissent en premier lieu les conséquences de la non qualité. Ceci peut concerner toute la chaîne de production jusqu'au support et à l'exploitation.

On procédera ainsi par une phase d'initialisation pour dégager des axes d'améliorations avec une évaluation des ROIs. Pour réussir notre démarche, et obtenir une bonne adhésion des personnes, il est important de s'inscrire dans le temps. Une possibilité intéressante est de mettre en place des cercles de qualité.

Dans un second temps, les cercles mettrons en place des améliorations conformément aux objectifs fixés, en procédant pas à pas et en mesurant l'efficacité des mesures prises. Ceci contribuera à sécuriser les investissements, à rassurer le management en donnant de la visibilité, ... et à initier une culture de l'amélioration continue.  

Le cercle de qualité

Un cercle de qualité est un petit groupe de 3 à 10 employés, qui se réunit régulièrement afin de chercher et de trouver les moyens d'améliorer qualitativement et quantitativement la production, ainsi que les conditions de travail. Ces personnes peuvent appartenir à une même équipe, au même service ou simplement avoir des préoccupations professionnelles commune.

Voici quelques caractéristiques du cercle de qualité:

• Le cercle est constitué sur la base du volontariat!
• Le cercle a un responsable et animateur comme dans toute réunion. C'est lui qui fixe les objectifs.
• La réunion est limitée dans le temps et se fait de façon périodique, par exemple, une heure tous les 15 jours.
• Le cercle travaille sur des problèmes rencontrés par ses membres ou par d'autres acteurs ou équipes.

Les problèmes doivent être circonscrits et concrets. On essaye un nombre très restreint d'améliorations à la fois. Cela permet d'en mesurer les bénéfices isolément avec le minimum de perturbations.
Afin de valider les améliorations, plusieurs méthodes sont possibles, dont:

• Le PDCA (où roue de Deming) : Chaque fois que l'on décide d'une amélioration (Plan), on la met en place (Do), on mesure si celle-ci apporte le bénéfice attendu (Check) et on valide l'amélioration ou au besoin on décide d'actions correctrices (Adjust / Act).
• Le PDSA: quasi identique au PDCA à ceci prêt qu'il est adapté aux cas où il est difficile de prévoir les effets de l'amélioration. Ici le « S » correspond au terme Study : on étudie l'impact de l'amélioration sur la chaîne de production.

Il y a donc une réelle autonomie de fonctionnement qui ne doit pas faire oublier de donner de la visibilité sur les actions menées, en particulier si on pratique le PDSA.

Les bénéfices sur le plan humain sont nombreux : meilleure communication, satisfaction de contribuer à l'amélioration et d'en constater les fruits, amélioration des compétences, cohésion des équipes, motivation... Ceci ne peut que rejaillir positivement sur l'efficacité de l'équipe.

La mesure du gain

En même temps que le choix de l'amélioration est fait, on définit les caractéristiques de l'échantillon, c'est à dire l'unité de mesure, la façon dont on va mesurer, et l'endroit où on va mesurer. On peut définir aussi la façon dont on va convertir la mesure en coût si on souhaite en avoir un.

Il est important d'envisager les outils à utiliser pour fiabiliser et faciliter la mesure. Cette tâche peut être rébarbative ou astreignante. Par exemple, mesurer le temps que prends une tâche peut être difficile en soi, parce que d'habitude on ne le fait pas. Les oublis, les mauvaises mesures peuvent être courants. Dans ce cas, il vaut mieux disposer d'un décompte automatique du temps passé voire d'une sauvegarde de ces résultats.

D'autres mesures sont plus complexes: si on supprime des documentations obsolètes, et qu'on centralise les documentations d'un même produit alors qu'elles étaient jusqu'ici dispersées à de nombreux endroits, on devine qu'il va y avoir un bénéfice, mais comment le mesurer ? On peut lister les cas où du temps a été perdu parce que la documentation était obsolète ou qu'elle était difficile à trouver et tenter de l'évaluer. La mesure en tout état de cause risque d'être imprécise car liée à la mémoire des personnes. La récurrence du problème sera un critère important.

Conclusion

Refaire entièrement un produit ou ne rien faire? Souvent le choix ne semble se limiter qu'à cette alternative. Pourtant il est possible de sortir de cette logique par la mise en place d'une véritable stratégie d'amélioration continue qui tient compte du contexte du projet et des objectifs de l'entreprise. Cela suppose que l'on a évalué les enjeux humains, techniques, commerciaux,... et que l'on est prêt à faire un minimum d'investissements en cohérence avec ces enjeux.

Les bénéfices seront d'autant plus grands que l'on considérera non pas une équipe isolée mais l'ensemble de la chaîne de production. Les améliorations toucheront à l'humain, à l'organisation, à la technique et par ricochet d'autres projets. Le tout se fera avec des investissements raisonnables, étalés dans le temps. Le calcul du ROI permet de justifier les améliorations envisagées en vue de  déclencher les investissements. Son usage à posteriori sert à en faire le bilan.

Il est indispensable de disposer d'un outil adéquat afin de conduire cette démarche. L'utilisation des cercles de qualités en est un, excellent. Toutefois cela demande un changement de mentalité, car on passe à un management participatif.

Ainsi en partant des seuls enjeux d'un produit, on peut arriver à sortir du statu quo, et progressivement à s'inscrire dans un cercle vertueux dont les bénéfices dépasseront largement le cadre initial.

1) Réécrire un logiciel de A à Z ou ne rien faire, où comment sortir du statu quo

Introduction

Vous avez peut être déjà été confrontés au choix de ré-implémenter un logiciel de taille conséquente soit de zéro, soit de le faire évoluer. La facilité ou la difficulté de faire évoluer un logiciel dépend de plusieurs critères :

• l'architecture plus ou moins pertinente et sa complexité,
• la façon dont le code est écrit, documenté,
• les librairies utilisées qui peuvent être obsolètes et plus supportées,
• la couverture de tests (idéalement automatisés),
• les diverses documentations du logiciel (installation, exploitation, guide utilisateur...).

Une évolution sur un logiciel ancien peut s'apparenter à un jeu de mikado, où régressions et instabilités peuvent surgir parfois assez facilement. 

Quels sont les enjeux ?

Si le produit est vraiment en fin de vie, et que l'on prépare son successeur dans une autre équipe pourquoi ne pas le laisser tel quel ? Cela peut se justifier si les technologies sont très différentes (passage de .NET à Java par exemple), mais attention toutefois à la phase de transition et de migration pour les clients, qui risque d'être longue, voire de ne jamais se faire pour certains !

Si le produit logiciel est sur un marché à potentiel intéressant, le ré-implémenter de A à Z peut conduire à une perte de marché. En effet, pendant une période significative, le nouveau produit ne sera pas disponible. L'ajout de nouvelles fonctionnalités augmentera d'autant les délais. Hors plus la sortie du produit sera tardive, et plus il est probable qu'il y ait des pressions pour intégrer des évolutions retardant encore la sortie du produit. Le risque est donc sérieux pour l'entreprise.

Pour chaque équipe, le coût de la non qualité se traduit par une moindre capacité à produire. Opter pour le statu quo c'est laisser le projet aller à la dérive. Qui plus est, faire travailler des personnes sur un vieux projet avec des technologies anciennes, et sans possibilité pour elles de contribuer à l'amélioration de la situation peut être démotivant et source de turnover.

Il y a donc 3 enjeux assez interdépendants:

1. Avoir les moyens de développer l'activité, et pour cela retrouver / maintenir un avantage concurrentiel,
2. Réduire les coûts et les délais pour améliorer la rentabilité du projet,
3. Avoir des équipes motivées, impliquées.

Que décider ?

Dans certaines entreprises, on peut rester pendant des mois voire des années sans prise de décision sur un produit. J'y vois plusieurs raison possibles :

• On a peur des conséquences pour l'entreprise (et pour soi!) si on prend une décision audacieuse et donc risquée. 
• On préfère opter pour des améliorations générales non spécifiques au produit.
• On se sent coincé et donc on se montre fataliste en reportant la responsabilité sur le produit ou sur les objectifs à court terme.
• Les objectifs mêmes de l'entreprise peuvent contribuer à ne pas prendre de décision, par exemple si le focus est mis sur d'autres produits.

Pourtant, entre tout réécrire et ne rien faire, il y a une troisième possibilité qui peut permettre d'aller vers un mieux en limitant les risques, mais cela nécessite un minimum d'investissements, et de courage. Nous allons voir dans la suite de cet article, qu'il est possible :

• d'agir sur l'environnement,
• d'agir sur le produit lui même,
• et de gérer le risque humain.

2) Sortir la tête de l'eau avec kanban

Nous allons partir de l'existant pour le faire évoluer pas à pas. Cela passe par une bonne connaissance des processus de l'équipe et de sa vélocité afin de pouvoir dire ce qu'elle peut traiter.

Éléments de travail et capacité

L'équipe effectue des tâches, implémente des fonctionnalités, fait des corrections de bugs, améliore la performance du produit... Chaque demande faite en entrée correspond à un ou plusieurs éléments de travail qui seront traités par une ou plusieurs personnes de l'équipe.

Il faudra s'accorder sur ce qu'un élément de travail signifie notamment avec les équipes en amont. On peut affiner en évaluant les éléments de travail en nombre de points selon la complexité, comme dans Scrum. L'essentiel est d'arriver à avoir un langage commun et pertinent.

La vélocité de l'équipe correspond au nombre d'éléments de travail livrés à l'issue d'un cycle de production. Lorsque nous aurons mesuré la vélocité sur plusieurs cycles, nous serons capables de donner la capacité, c'est à dire la vélocité moyenne attendue dans un sprint. Il est à noter que plus l'équipe a d'éléments de travail à réaliser et plus, à partir d'un certain seuil, sa performance va se dégrader. On va donc déterminer progressivement la capacité optimale de l'équipe.

Connaître ses processus

Pour identifier les améliorations possibles dans le fonctionnement de l'équipe et ce qui peut la perturber, on va dessiner la façon dont un élément de travail va traverser l'équipe avec une information sur les temps d'écoulement. On appelle ça le Value Stream Mapping (VSM). Il s'agit de repérer la façon dont un élément de travail est reçu, par qui, et les étapes de son traitement (analyse, spécifications, implémentation, tests, …) .

Cela va permettre de s'interroger sur la façon dont l'équipe fonctionne, notamment de voir s'il y a du gaspillage, si la façon dont les demandes arrivent,et  l'endroit où elles interviennent dans le processus est pertinent ou pas.

Utiliser le management visuel

On peut déduire du VSM les étapes de traitement d'un élément de travail, et ainsi on va dessiner un tableau Kanban avec diverses colonnes comme : « À faire », « En cours », « En test », « En intégration », « Fini ». Dans chaque colonne on mettra des post-its, chacun correspondant à un élément de travail. Les éléments de travail qui arrivent en entrée sont mis dans la colonne « À faire ». Lors de la réunion quotidienne kanban, qui est faite avec tous les membres de l'équipe, on fait le point sur les éléments de travail. Chacun dit où il en est, les obstacles qu'il rencontre. En fonction de l'avancement, on déplace les post-its dans les colonnes correspondantes. Il est essentiel que ce tableau soit visible de toute l'équipe.

Ce tableau va permettre de voir, outre l'avancée des éléments de travail, les goulots d’étranglements, les situations de famines (colonnes sans aucun post-it). Il va donc aider l'équipe à fluidifier son travail, à améliorer ses estimations de charges et à mesurer sa vélocité. La participation de chacun, la visibilité sur le déroulement du projet, sont des sources de motivation supplémentaire.

Bilan

Je ne détaille évidemment pas toute la méthode Kanban. Cela dit on voit bien que ces outils en permettant une meilleure connaissance de l'existant, vont donner des éléments importants pour négocier ce que l'équipe pourra accepter en entrée. Le pilotage du cycle de production est plus fin et plus réactif. Enfin la motivation des membres de l'équipe est améliorée, car on leur a donné de la visibilité sur les tâches, et on a favorisé leur implication.

1) Sortir la tête de l'eau avec Kanban

Dans l'exemple précédent (Faires des économies en investissant) nous avions une équipe de développement qui était littéralement la tête sous l'eau et qui courait après le planning.

Comment est-il possible de sortir d'une telle situation? Pour retrouver une certaine maîtrise du planning on va chercher à connaître :

• Le fonctionnement et les limites de l'équipe: le(s) processus suivi(s), les compétences, la disponibilité de ses membres sur le projet,
• Les limites du produit en terme d'architecture et de bugs au regard des demandes faites,
• Les dysfonctionnements s'il y en a,
• Les interlocuteurs avec lesquels l'équipe interagit: leur rôle, leur compétence.

Il y aura probablement des actions à réaliser au sein de l'équipe, mais aussi vis à vis de l'extérieur. En effet on peut distinguer différents flux dans cette équipe : des flux entrants – les demandes et les retours sur le produit [suite aux livraisons], et des flux sortants – ce que l'équipe produit.

Ici tout se passe comme si l'équipe était un barrage avec un lac de rétention. S'il pleut (donc s'il y a des sollicitations), le niveau du lac de rétention a tendance à monter. Hors plus il pleut plus le niveau monte vite et plus il y a de débris, de troncs d'arbres qui vont boucher les entrées du barrage et l'empêcher de délivrer la même quantité d'eau. Autrement dit plus les flux entrants sont nombreux et impactants et plus la performance de l'équipe va en pâtir.

S'il est possible d'améliorer le fonctionnement en interne, cela demandera un investissement pour un résultat à moyen terme, donc une baisse de performance dans un premier temps. L'équipe fonctionnant dans un écosystème, il faudra le faire accepter. En outre cet investissement ne suffira pas la plupart du temps.

L'enjeu pour l'équipe est donc aussi de réguler les flux entrants – les sollicitations, afin d'être en mesure d'atteindre une performance optimale. Pour cela elle doit aussi être capable de dire à quelle cadence elle peut travailler, et donc à quelle cadence elle peut livrer. Mais livrer quoi ? Les livrables n'auront pas tous la même taille, le nombre de fonctions, de bugs corrigés varie.

Nous allons utiliser une démarche Kanban afin de mieux définir ces notions. Cela va nous aider aussi à opérer un renversement de la perspective : plutôt que de ne travailler qu'en fonction des sollicitations – « en flux poussé », on va fonctionner en fonction de ce que l'on peut livrer – « en flux tiré ».

Suite au prochain article.

Faire des économies en investissant

Vous avez peut être déjà rencontré ce genre de situation :

• D'un côté le commercial est insatisfait de l'équipe de développement, car ils ne livrent pas dans les délais et de façon satisfaisante. Il est tenté de les croire inefficaces voire incompétents. Pour rattraper les affaires non rentables, il facture au prix fort certaines prestations.
  

• D'un autre côté, l'équipe de développement (R&D) râle après le commercial, car il vend des affaires qui ne leur conviennent pas en terme de contenu technologique (car ils en maîtrisent mal certaines), de charges, de délais.

On voit bien que cette situation a des effets pervers, notamment:

• L'image de l'entreprise vis à vis des clients est dégradée, car elle ne tient pas souvent ses engagements, et certains services sont surfacturés.
• Les relations sont tendues, et un climat de défiance et de frustration règne, ce qui favorise le turn over et la baisse d'efficacité des personnes.
• L'équipe de développement sont mis dans une logique d'échec.
• Le commercial de son côté n'est pas forcément plus à l'aise car sa confiance dans les équipes de développement est faible. Lui aussi est entraîné dans cette logique d'échec. Il doit faire face au mécontentement des clients et a l'impression de se débattre relativement seul

Quelles actions pourraient permettre de sortir de cette spirale ? Est-il possible d'obtenir une amélioration substantielle sans investissement important ou sans générer une dérive des coûts et du retard sur les projets ?

Comme il y a plusieurs problèmes à régler, il va falloir procéder par étapes. Voilà pourquoi une réponse possible passe par l'utilisation d'outils issus du Lean. On va donc:

1. Faire un bilan des projets sur une durée significative.
2. Se donner des objectifs
3. Dégager les améliorations les plus prioritaires.

Faire un bilan des projets sur une durée significative

Le bilan des n derniers projets permet de voir ceux qui ont été rentables, ceux qui ne l'ont pas été et de combien. Difficile de rentrer dans les détails à posteriori; cela dit on peut déjà avoir une idée du sérieux de la situation notamment en terme de coût et d'image auprès des clients. Un bilan de chaque projet fait au fur et à mesure apporterait certainement bien plus d'informations. Ceci va permettre de justifier l'investissement fait en améliorations, car il est illusoire d'espérer une amélioration si on ne fait rien.

Se donner des objectifs

Il s'agit de savoir où l'on veut être dans 6 mois, 1 an et ce qu'on est prêt à investir. La question se pose en priorité à la hiérarchie, car de son implication et de son approbation dépend le succès. 

Revenir à une rentabilité correcte demande du temps, surtout si les équipes sont noyées sous les tâches à réaliser. On peut fixer des règles d'emblée (respecter l'évaluation des équipes de développement, valider le contenu technologique d'une offre), mais il faudra assumer les conséquences immédiates. Hors on n'est peut être pas prêt à de tels changements.

Dégager les améliorations les plus prioritaires

On constitue avec toutes les parties prenantes une liste des objectifs principaux à atteindre. On en déduit des points d'améliorations, qui permettrons d'atteindre progressivement ces objectifs. Un médiateur (le consultant?!) aidera à faire ces listes de façon non personnelles afin de sortir du conflit, mais aussi de sorte à ce que les points d'améliorations soient suffisamment réalistes, précis et simples. On affinera par la suite au fur et à mesure les points retenus et au besoin on les découpera en plusieurs points d'améliorations.

Une fois les objectifs principaux fixé, on ordonne les points d'améliorations par priorité. On doit s'accorder sur la mesure et le critère de réussite de chaque point d'amélioration, et ce au fur et à mesure qu'ils seront retenus.

En fait on procède par itération:

• Avant chaque itération, on nettoie la liste des points d'amélioration, on la met à jour par priorité et on affine les points susceptibles d'être pris lors de la prochaine itération.
• Lors de la réunion de fin d'itération on fait le bilan du ou des points d'améliorations. On peut en dégager d'autres points d'amélioration, ou décider d'en découper un qui s'avère trop gros.
• Lors de la réunion de début d'itération on choisit les prochains à mettre en œuvre pour l'itération suivante et on fixe la date du prochain point.

Attention à ne pas vouloir trop en faire: il vaut mieux se limiter par exemple à un ou deux points d'amélioration par équipe par itération. Sinon on risque de se disperser, de trop impacter les projets en cours, et de ne pas améliorer grand chose dans les temps fixés.

Conclusion

Cette démarche présente plusieurs intérêts :

• Elle implique toutes les parties prenantes,
• Elle leur ouvre les yeux sur les besoins et la complexité du métier des autres parties,
• Elle va permettre d'avoir des signes encourageants assez rapidement, ce qui aura un effet positif sur le moral et la motivation.
• Elle permet de mesurer le progrès réalisé notamment sur un plan financier,
• Elle contribue à rétablir la confiance et de s'inscrire dans une logique de réussite! 

Elle est conforme au Kaizen, un outil du lean qui signifie « amélioration continue » en Japonais. On la retrouve dans certaines méthodes comme Scrum (méthode agile de gestion de projet). D'ailleurs ce projet d'amélioration est pleinement compatible avec cette méthode.

Big Data: 2) Applications et enjeux

Mais au fait qu'est ce que le Big Data ?
Quand on parle de Big Data on parle souvent des 3 V qui le caractérisent :

• Volume : de grandes quantités de données,
• Variété : des données de nature [très] différentes,
• Vélocité : une capacité à traiter de gros volumes de données en peu de temps.

Certains rajoutent aussi:

• Véracité : est-ce que ces données sont fiables?
• Visibilité : les données doivent être interprétables « facilement » par un être humain.

Au cours de ces 2 dernières années on considère que 90 % des données existantes d'aujourd'hui, ont été créées. Il y a donc une croissance exponentielle du volume de données, et ça n'est que le début.

La plupart des données ne sont pas structurées, c'est à dire qu'elles ne sont pas stockées dans des bases de données relationnelles. Ces données sont par exemple dans les pages des sites internet, dans des fichiers de logs, de son, des images, des courriels,... Les formats sont donc de nature très diverse. Environ 80 % des données d'une entreprise ne sont pas structurée. Il faut donc des outils spécifiques pour gérer ces données, notamment des systèmes de gestion de bases de données NoSQL.

Avec le Big Data, on peut mesurer l'impact d'une publicité sur Twitter en fonction des messages échangés. On peut même détecter des tendances de fond en analysant les échanges des internautes sur les réseaux sociaux. IBM appelle ça le « social sentiment index » qu'on traduit par « indice d'opinion sur les réseaux sociaux». C'est ainsi qu'IBM a annoncé cette année que le steampunk deviendrait très tendance en 2014-2015 (http://www.slate.fr/lien/67421/steampunk-tendance-majeure-ibm). De cela découlera une offre marchande liée à cette thématique.

Si on peut détecter des tendances de marché, on peut aussi sonder de façon discrète une population. C'est ainsi que l'équipe du président Obama a utilisé le Big Data pendant sa campagne présidentielle. Elle a mesuré l'impact de ses interventions, des publicités sur la télévision, pour déterminer les actions à mener, comme aller faire une réunion publique dans une ville donnée.

On connaît déjà le ciblage de l'offre par des publicités sur Internet, en fonction des articles, des sujets que vous avez recherchés. On sera à l'avenir encore plus précis. Par exemple, vous dites sur les réseaux sociaux que vous vous intéressez à un produit. Et voilà qu'en passant devant un magasin vous recevez un SMS qui vous propose une promotion sur cet article chez ce commerçant.

Aujourd'hui les données peuvent se revendre une fois rendues anonymes, ou être mises à disposition gratuitement (open data). Elles peuvent aussi être mises à disposition d'un tiers, dans une certaine mesure, si vous avez donné votre accord.

On analyse de plus en plus de façon automatique ce qui se passe dans les centres d'appels dont les conversations. On peut même analyser les émotions pour détecter la satisfaction du client. Une des prochaines étapes sera l'analyse de la vidéo en temps réel pour mesurer le comportement des personnes. Par exemple dans un supermarché pour valider l'efficacité d'une disposition sur une gondole, ou encore pour envoyer un SMS à une personne qui entrerait dans une zone dangereuse.

Faut-il sombrer pour autant dans la paranoïa? Big Brother et Big Data sont ils synonymes? Si certains organismes comme la CNIL sont là pour garantir nos droits, il peut néanmoins y avoir des dérives. Rappelons nous quand même que nous étions déjà surveillé (vous vous souvenez d'Echelon et de l'analyse automatique des courriels sur gmail?). En fait la question qui est posée est aussi celle de l'intention.

Les possibilités d'applications du Big Data sont donc très nombreuses et beaucoup restent à inventer. Elles sont à la fois enthousiasmantes, et parfois un peu effrayantes quant aux multiples dérives possibles. Une chose est sûre, dans les années à venir on aura de plus en plus besoin de compétences dans ce domaine.

Quelques liens intéressants pour aller plus loin :
http://www.conseilwebsocial.com/index.php/2013/reseau-social-et-big-data/

http://www.informationweek.com/government/cloud-saas/6-ways-amazon-cloud-helped-obama-win/240142268

La prévision d'IBM sur le steampunk: http://www-03.ibm.com/press/us/en/pressrelease/40120.wss

Je suis allé à la conférence Big Data de l'école de commerce de Grenoble. Très intéressant! Il y a même des vidéos de la conférence:
http://entreprisedigitale.wordpress.com/