Considérons React Native

Très rapidement, React est une librairie JavaScript créée par Facebook (utilisée notamment par Facebook, Instagram, Netflix, AirBnB, Deezer, eBay etc…) pour élaborer des interfaces utilisateur, et magnifique le meilleur mot pour la décrire… je vais à présent tâcher de vous en convaincre !

React / Component / Props



Actuellement la plupart des applications mobiles écrites en JavaScript utilisent Cordova, ou un framework basé dessus comme Ionic. Avec ce choix vous n’allez pas vous faciliter la tâche en faisant des appels à une API qui rend du JS et de l’HTML dans une Webview ! C’est un choix de vie…

Problématique : comment faire pour faire bénéficier à votre utilisateur, au travers d’une application hybride, de la même expérience que celle offerte par une application native ? scrolling acceleration, clavier, navigation fluide…

J’AI LA SOLUTION

« React Native c’est pas vraiment du natif. »

Un collègue apprécié (parti trop tôt…).

Bien que ce soit du JavaScript qu’on produise avec React Native, nos components seront rendus en tant que widgets natifs de la plateforme ; aussi si vous avez écrit des applications en Java ou en Objectif-C vous reconnaitrez immédiatement certains des components (écrits en Swift, Obj-C ou Java).

React a énormément changé l’approche dans la constructions d’interfaces utilisateur, par son ‘output of state’, et la facilité de débogage d’une application. Fini de penser à tous les chemins possiblement emprunté par un utilisateur : concentrez-vous sur les états de vos components. React Natif apporte ainsi un nouveau paradigme dans l’écriture d’applications.

Par exemple, au lieu d’utiliser une <div> comme en web, on va utiliser une <View> pour rappeler UIView et android.view. Aussi lorsque les données de votre component changent, React Natif calcule ce qui doit être modifié et effectue les appels nécessaires à tous les widgets d’UI native affichés. Et c’est rapide ! 60 fps ! Le JS est exécuté sur son propre thread, séparé du thread de l’UI principale, donc même si votre application propose une logique complexe, vous réussirez à proposer la meilleur des UX.

Un bon starter kit pour mesurer les capacités de la technologie et vous mettre dans le bain  : https://github.com/start-react/native-starter-kit

Conclusion

En conclusion (et toujours selon moi !) vous vous facilitez la vie en choisissant React Natif : réduction des coûts de développement, 1 app / 2 plateformes. Ensuite, qui propose cet éco-système autour d’un framework d’applications natives cross-platform ? Ajoutez y Redux (un conteneur d’état) et vous allez atteindre des sommets, et en plus vous pourrez profiter d’une communauté riche et réactive (sans mauvais jeu de mot) !

baba out

Posted in Non classé | Leave a comment

Introduction au framework ITIL

Le framework ITIL® est de plus en plus utilisé le monde de l’IT.
Vous en avez peut être déjà entendu parler.
Suite à une formation récemment suivie, j’ai souhaité vous faire une présentation des principes ITIL®.

Qu’est-ce qu’ITIL® ?

ITIL® signifie : IT Infrastructure Library.
Finalement ceci vous avance peu.
Avant d’aller plus loin faisons un peu d’histoire.

Dans les années 80, répondant à une dépendance croissante envers les Technologies de l’Information, le gouvernement britanique (sous l’impulsion de Mme. Thatcher) a élaboré un ensemble de recommandations.
ITIL® est donc un recueil de bonnes pratiques basées sur une approche par processus, destiné aux organisations informatiques qui délivrent des services complets à leurs clients.
ITIL® n’impose rien (non prescriptif), n’est pas orienté fournisseurs/outils et n’est pas un standard.

La finalité est d’organiser un référentiel de gestion de services informatiques rendus sur la base d’une infrastructure IT.
Cette gestion est également connue sous le nom de ITSM (« IT Service Management »).

Concrètement comment cela se présente ?

Actuellement nous sommes à la version 3 d’ITIL®.
Le noyau (core) de la documentation est composé de 5 livres qui représentent chacun une phase du cycle de vie de l’ITSM.
De la documentation additionnelle est disponible : publications complémentaires et supports web (glossaire, template)
Cette bibliothèque d’information décrit notamment 26 processus et 4 fonctions.

Quels sont les concepts de base ?

ITIL® est un framework orienté client, basé sur des concepts dont voici les principaux.

Le but d’un service IT est de créer de la valeur pour les clients.

  • ITIL® définit l’utilisateur comme celui qui utilise le service (ex : opérateur de saisie, agent de transfert).
  • Il peut être différent du client, celui qui définit le service et qui l’achète (ex : CEO).
  • Les deux types d’interlocuteurs parlent à un fournisseur de Service IT (IT Service Provider).
  • La valeur d’un service est composée de son utilité (fonctionnalités) et de sa garantie (niveaux de service : capacité, disponibilité, sécurité, continuité).

La notion de phases de cycle de vie de l’ITSM a été introduite précédemment.

Mais quelles sont ces phases ?

ITIL® décrit les 5 phases du cycle de vie suivantes :

  • Service Strategy :
    L’objectif de cette phase est de définir la stratégie des services à implémenter.
    C’est à dire, comprendre les besoins des clients et repérer les avantages concurrentiels de son entreprise afin d’adapter au mieux l’offre des services proposés dans le portefeuille de services.
  • Service Design :
    Gestion du catalogue de services (y compris leur spécifications techniques) correspondant à la stratégie définie dans la phase précédente.
    Le catalogue de services correspond uniquement à la partie opérationnelle du portefeuille des services.
    C’est à dire aux services que le client peut acheter/utiliser.
  • Service Transition :
    Développer et intégrer les nouveaux services (ou adaptation de services existants) dans l’environnement cible.
  • Service Operation :
    Maintenir les services dans les environnements supportés afin qu’ils continuent à fonctionner comme attendus (sans dégradation de performances).
    L’exploitation des services est la partie du cycle de vie où les services et la valeur sont effectivement livrés.
  • Continual Service Improvement :
    Mettre en œuvre des plans d’amélioration des services de manière incrémentale et continue.

 

Itil_Lidecycle

Représentation des 5 phases du cycle de vie

Quelles sont les différentes fonctions ?

ITIL® définit une fonction comme une unité d’une organisation (entreprise) qui est spécialisée pour exécuter certains types de travail.
ITIL® décrit 4 fonctions au sein du fournisseur de service IT :

  • Service Desk :
    Le Service Desk a un rôle de centralisateur. C’est le Single Point Of Contact pour les utilisateurs (SPOC).
    Il est en charge de gérer toutes les demandes clients, qu’il devra catégoriser et prioriser afin de déclencher le processus adéquat.
  • Application Management :
    Est garante du savoir et de l’expertise concernant les applications.
    En cas de besoin d’expertise concernant le software (lors d’une escalation) c’est vers cette fonction qu’il faudra se diriger.
  • IT Operational Management :
    Est garante de la stabilité de l’environnement et de la livraison des services.
    Par exemple le monitoring des KPI est notamment pris en charge (sous-fonction IT Operational Control) ainsi que la gestion des infrastructures (Datacentre…) (sous-fonction Facilities)
  • Technical Management :
    Est garante du savoir et de l’expertise concernant les équipements matériels.
    En cas de besoin d’expertise concernant le hardware (lors d’une escalation) c’est vers cette fonction qu’il faudra se diriger.

Que représentent les processus ?

ITIL® indique qu’un processus a caractéristiques :

  • Il répond à un évènement spécifique
  • Il génère un résultat attendu
  • Ce résultat est délivré à un client
  • Le processus est mesurable (en coût, en qualité…)

ITIL® décrit 26 processus nécessaires à l’ITSM.
Rassurez-vous nous n’allons pas décrire (ni lister) les 26 processus.
L’ensemble des processus est réparti sur les différentes phases du cycle de vie de l’ITSM.
Certains sont donc plus liés à la stratégie et d’autre plus orientés opérationnels.
Voici quelques exemples :

  • La gestion des évènements (phase Service Operation)
  • La gestion des incidents (phase Service Operation)
  • La gestion des problèmes (phase Service Operation)
  • La gestion des accès (phase Service Operation)
  • La gestion de changement (phase Service Transition)
  • La gestion du portefeuille de services (phase Service Strategy)
  • La gestion de la capacité (phase Service Design)

Comment implémenter ces best practices ?

ITIL n’étant pas prédictif rien n’est imposé.
Dans la mesure où le spectre d’application est large (puisqu’il couvre l’ensemble des cycles de la livraison de services informatiques), c’est un atout !

En effet, vouloir implémenter directement l’ensemble des 26 processus est beaucoup trop long et risqué.

Il est plus efficace de trouver quelques processus qui permettront des Quick Win que l’on peut implémenter rapidement et de réitérer ensuite l’opération.
Généralement ce sont les processus opérationnels qui sont implémentés en premiers.

On peut penser notamment aux processus suivants :

  • Request Fulfilment :
    Ce processus est lié aux demandes des utilisteurs (réinitialisation de password, création d’un nouvel utilisateur, installation d’un logiciel…)
  • Incident Management :
    Un incident dans ITIL® décrit toute perturbation (actuelle ou future) impactant la livraison totale ou partielle du service.
    L’objectif de ce processus est de restaurer aussi rapidement que possible la livraison du service au niveau attendu.
  • Problem Management :
    ITIL® défini un problème par la cause, inconnue, sous-jacente d’un ou de plusieurs incidents.
    L’objectif de ce processus est de trouver l’origine est de proposer une solution définitive (qui devra être évaluée par le processus de changement Change Management)

Ensuite on sélectionne à nouveau quelques processus et on recommence l’implémentation.

Pourquoi ne pas oublier la Gestion de la connaissance ?

Toutes ces fonctions et processus interagissent entre eux.
Afin d’être le plus efficace possible, les différentes informations (spécifications techniques, configurations, erreurs connues…) doivent être stockées dans des bases de données et accessibles par les autres fonctions/processus.
L’ensemble de ces bases de données forme le Service Knowledge Management System (SKMS).

Pour être plus concret, prenons comme exemple les processus de gestion d’incidents et de gestion des problèmes (qui ont été décrits précédemment) :
Le responsable de la Gestion des Problèmes renseigne les erreurs connues dans une base de données (Known Error DB) appartenant au SKMS.
ITIL® définit une erreur connue comme un problème qui a une cause sous-jacente connue et pour laquelle un workaround existe. Le tout étant documenté.
Ces informations, renseignées dans le SMKS, permettront au responsable du processus de la Gestion des Incidents de répondre au plus vite à l’utilisateur avec la réponse adéquate.

Quels sont les gains apportés par ITIL® ?

L’adoption des bonnes pratiques de l’ITIL® par une entreprise permet d’assurer à ses clients (internes comme externes) un service répondant à de hautes normes de qualité.
ITIL® permet, grâce à une approche par processus clairement définie et contrôlée, d’améliorer la qualité des SI et de l’assistance aux utilisateurs en créant notamment la fonction Service Desk.
ITIL® est finalement une sorte de « règlement intérieur » du département informatique des entreprises qui l’adoptent.

Les bénéfices pour l’entreprise sont une meilleure traçabilité de l’ensemble des actions du département informatique.
Ce suivi amélioré permet d’optimiser en permanence les processus des services pour atteindre un niveau de qualité maximum de satisfaction des clients.

En conclusion

En se basant sur le concept Adopt and Adapt, les bonnes pratiques ITIL® sont applicables aussi bien par les petites structures que par les grandes entreprises.
Elles permettent de mieux gérer la livraison de services informatiques en contrôlant le niveau de service fournit et en proposant des améliorations en continu.
Le framework ITIL® est compatible avec des normes (norme ISO 20000) et autres standards mais également avec des méthodologies (Prince2 ou Agile).

Bien évidemment cet article n’est qu’une brève introduction à ITIL®.
Toutes les notions et concepts n’ont pas été présentés (rôles, configuration item, Cycle de Deming…).

Si vous êtes prêt à rentrer dans ce nouveau monde, n’hésitez pas à cliquer sur ces liens qui vous seront ITIL :
http://www.itilfrance.com/
https://www.axelos.com/best-practice-solutions/itil

Sources
https://ced421.files.wordpress.com/2013/06/itil1.jpg

Posted in Non classé | Tagged , , | Leave a comment

Retour sur DevOps REX

Le 28 novembre dernier se tenait la conférence DevOps REX au Grand Rex à Paris. Digne héritière des précédents DevOpsDays Paris 2013 & 2015, cette édition était centrée autour de Retours d’Expériences. DevOps REX en quelques chiffres c’était :

  • 400 Participants ;
  • 16 Sponsors ;
  • 9 Conférences ;
  • 1 Lieu d’échange : l’espace social.
devopsRex

Une journée complète consacrée à des REX francophones : un pari osé !

 

DevOps : un seul mot, des définitions différentes mais une vision partagée

DevOps est certainement l’un des termes les plus en vogue dans notre métier ces dernières années. Pour certains il s’agit de pratiques réservées au monde des startups, des géants du Web. Pour d’autres, ce n’est qu’une tendance passagère ou un ensemble d’outils. Malheureusement, il reste encore beaucoup de mythes autour de DevOps. Cette conférence n’a pas pour but de démystifier tout ça. D’autres l’ont fait avant et il existe désormais une bibliographie assez complète autour du sujet.

Nous entendons beaucoup de success-stories liées à DevOps. Nous souhaitons tous tirer les bénéfices d’une telle approche sans savoir réellement ce que c’est ni vraiment par où commencer. DevOps REX se consacre aux témoignages et met en avant des exemples concrets de mise en place au sein de grandes structures comme Microsoft, Orange et la Société Générale. Grâce à leurs retours, les speakers nous ouvrent la voie en partageant à la fois leurs succès et leurs échecs.

Comment définir DevOps ?

Grâce à l’acronyme mettant en lumière ses valeurs fondamentales :

C A (L) M S

pour Culture, Automation, Measurement, Sharing et bien entendu le dernier arrivé : Lean.

DevOps est un mouvement visant à aligner le SI sur les besoins de l’entreprise. Autrement dit, l’objectif premier est de délivrer de la valeur. Durant cette journée deux sujets ont été soulignés à plusieurs reprises et ont retenu mon attention. Vous les retrouverez ci-dessous.

Une approche Top-Down & Bottom-Up

L’attente est souvent forte du côté des développeurs vis à vis de DevOps et une certaine frustration peut naitre dans les équipes lorsqu’elle ne fait pas écho dans le reste de l’organisation.

Une telle transformation nécessite avant tout un engagement de la direction. Cela démarre par une prise de conscience sur les besoins et les raisons d’une telle démarche. Elle doit ensuite être accompagnée d’un sponsoring fort puis matérialisée par une prise de décision de manière formelle et présente à tous les niveaux.

Une approche « bottom-up » sans soutien du management ne suffit pas et une approche « top-down » sans réalité du terrain non plus. Il est nécessaire d’avoir les deux. Cette double pression maximisera les chances de réussites.

L’importance de la mesure

Le monitoring classique revient souvent à prendre le pouls d’une application pour connaitre son état au présent ou rapporter ce qu’il s’est passé jusqu’ici (regard vers le passé). Ce n’est pas seulement de reporting dont nous avons besoin mais de feedback rapide : comprendre ce qu’il se passe pour anticiper le futur et piloter ! Il faut donc :

  1. Récolter un maximum d’informations car toutes les problématiques ne sont pas connues à l’avance ;
  2. Diffuser l’accès à ces informations et notamment à ceux qui en ont besoin pour prendre des décisions ;
  3. Penser mesure et métrologie dès la conception.

Il est nécessaire d’intégrer au plus tôt ces besoins dans l’écriture des User Stories en mettant dans la boucle tous les acteurs concernés. Par exemple : les équipes de support sauront mieux que personne indiquer les indicateurs dont elles ont besoin pour assurer le support d’une fonctionnalité.

Pour garantir un certain niveau de qualité, il faut mettre en place les outils et les mesures adéquates. Ces métriques permettent de définir les pistes d’amélioration et interviennent à différents niveaux :

  • L’organisation : pour définir sa stratégie (Lead-time, WIP, fréquence des livraisons, …)
  • La chaîne de production logicielle : pour évaluer la vélocité des développements, la dette technique.
  • La qualité du service (disponibilité, performance, fiabilité, …)
  • L’usage des outils  : pour mesurer l’adéquation entre le produit et les attentes des utilisateurs

Pour conclure, DevOps est surtout un état d’esprit plutôt qu’une suite d’outils.

Envie d’en savoir plus ? Je vous invite à (re)voir les conférences sur la chaine youtube de DevOps Rex ! 😉

Posted in conférence | Tagged | Leave a comment

Développer des applications mobiles avec Ionic 2

Ionic logo

Qu’est ce que Ionic ?

Ionic est un framework de développement d’applications mobiles hybrides. Il s’est entouré de précieux alliés, tels que Apache Cordova (ex Phonegap) et AngularJS.

Pour pouvoir développer ses applications mobiles, Ionic se base donc sur Cordova, ce qui veut dire que tous les plugins Cordova permettant d’accéder aux fonctionnalités natives des mobiles peuvent être utilisés dans un projet Ionic. Avec Cordova, il est également possible de packager son application HTML et de la déployer sur les smartphones Android, iOS ou Windows Phone.
Mais il y rajoute une surcouche, et y joint notamment AngularJS, permettant l’ajout du MVC, ainsi que le CSS permettant de se rapprocher au mieux du style des applications natives (Android et iOS).

cordova-ng-ionic

Ionic c’est également une plate-forme offrant tout un panel d’outils destiné à faciliter la tache au développeur (plus de détails ci-dessous).

Applications mobiles : développement natif ou hybride ?

Lorsque l’on veut développer une application mobile, cette question est souvent l’une des premières que l’on se pose.

Une application mobile native permettra de mieux intégrer toutes les fonctionnalités du smartphone (GPS, appareil photo, …), et permettra également de mieux gérer la mémoire de l’appareil. Le développement natif est la solution qui offrira de meilleurs résultats en ce qui concerne la performance en terme de fonctionnalités.

Cependant, cela pose des soucis en terme de développement et de déploiement. En effet, aujourd’hui les applications sont le plus souvent destinées aux personnes possédant des appareils iOS et Android (voire Windows Phone). Le développement natif impliquera de doubler (voire tripler) le code source des applications, et il faudra également maintenir ces trois applications différentes (tout ça induit un coût supplémentaire).

Une application hybride est une application développée en HTML5/CSS3, qui s’exécute ensuite sur les smartphones dans une Webview. Cela permet d’avoir une application déployable sur tous les appareils, téléchargeable sur les différents stores (Google Play, App Store) et permettant d’utiliser les fonctionnalités du téléphone.
De plus, avec des frameworks comme Cordova, il est possible d’accéder aux APIs natives des smartphones pour utiliser appareil photo, notifications push,…
Cela permet d’avoir un seul code source pour toutes les plateformes mobiles (réduction du coût de développement et du coût de maintenance).

Mais il reste tout de même des freins à ce type de développement. En effet,il n’existe pas de composants UI standardisés, c’est-à-dire qu’il est possible de faire des applications pas (ou peu) adaptées à l’écran des smartphones. Et comme il n’y a non plus pas de standardisation dans la manière de développer, il faut également faire attention au contenu que l’on met dans nos pages HTML, en prenant en compte le fait qu’un smartphone n’a pas la même puissance qu’un ordinateur (même si aujourd’hui ils le sont de plus en plus). C’est moins de performance que les applications natives.

La solution Ionic

Ionic se base sur Cordova. Il va donc intégrer les outils permettant de builder l’application HTML en exécutable (pour Android, iOS ou Windows Phone). Il est également possible d’utiliser tous les plugins Cordova existant et d’accéder aux fonctions natives des smartphones.

A tout ça, on ajoute les fonctionnalités d’AngularJS : le modèle Vue/Contrôleur, ainsi que les différentes directives permettant de faciliter le développement.

Ionic propose ses propres outils en plus de Cordova et AngularJS.
En effet, avec Ionic, nous avons la standardisation des applications hybrides qu’il nous manquait. Ionic propose des styles CSS propres à chaque plateforme, permettant de développer des application au design très ressemblant à celui des applications natives. Ces styles CSS sont très facilement personnalisables, car la technologie utilisée est SASS (Syntactically Awesome Stylesheets, plus d’info ici: http://sass-lang.com/). Un système de variables Sass a été mis en place afin de pouvoir très facilement personnaliser le style de composants précis.
Par exemple, pour modifier la couleur de fond de l’application, il suffira de modifier la valeur de la variable: $background-color
Si vous voulez modifier la couleur seulement pour l’application iOS: $background-ios-color
Avec Sass, vous pouvez également ajouter très facilement vos propres feuilles de styles.
Et tout ce système est indépendant du code source javascript/HTML de votre application !

Ionic propose également des composants UI déjà tous faits, prêts à être utilisés, et dont le style est adapté en fonction de la plateforme sur laquelle sera déployée l’application. Cela permet un gain de temps dans le développement des interfaces.

Les outils Ionic mis à la dispotion du développeur

Ionic a mis au point son CLI (Command Line Interface), permettant d’utiliser plusieurs outils capables de faciliter la vie aux développeurs. Voici une liste non exhaustive de ces outils :

$ ionic start myApp [template]

Cette commande permet de démarrer très vite une application Ionic. Elle vous construira une application en fonction d’un template (celui par défaut, ou bien celui de votre choix parmi les templates proposés). Vous aurez très vite une application fonctionnelle avec laquelle démarrer.

$ ionic serve

Cette commande vous permet de lancer votre application sur votre localhost. Elle sera accessible dans le navigateur de votre ordinateur, mais elle pourra également l’être sur le navigateur de votre Smartphone si celui-ci est connecté au même réseau. Cela permet de tester très rapidement les développements faits.

$ ionic serve –lab

Cette commande fait la même chose que celle décrite ci-dessus, mais en plus elle vous ouvre une page “Lab” dans votre navigateur, à partir de laquelle vous aurez l’aperçu du rendu de votre application mobile sur les 3 plateformes : iOS, Android et Windows Phone.

Capture d’écran 2016-10-10 à 21.42.53

$ ionic build ios/android
Permet de construire le fichier exécutable pour les plateformes iOS ou Android

$ ionic emulate ios/android
Permet de lancer un émulateur afin de tester votre application.

$ ionic run ios/android
Permet de lancer votre application sur un vrai appareil. Si aucun n’est disponible, cela lancera un émulateur.

Pour plus d’informations, c’est par ici : https://ionicframework.com/docs/v2/cli/

Bilan

Ionic est un framework permettant de réaliser de manière très rapide et avec un résultat plus que satisfaisant des applications mobiles hybrides.
Il pourra vous convenir si vous avez besoin de lancer une application mobile très vite sur tous les stores, ou si l’application que vous souhaitez développer ne comprend pas de fonctionnalités très évoluées devant utiliser avec précision les composants natifs des smartphones (c’est-à-dire, si votre application reste une simple application de consultation de données par exemple).

Pour exemple, l’application InTech Mobile a été réalisée avec Ionic 2:
Play Store
App Store

Camille Thomassin, Pierrick Bena et Laurine Schuster

Sources

http://ionicframework.com/
http://ionicframework.com/present-ionic/slides/#/
https://adamdbradley.github.io/building-with-ionic2/#/
http://www.latreebu.com/blog/application-mobile-native-ou-web-3-solutions/

Posted in Non classé | Tagged , , , , | Leave a comment

La vague Modern Agile

L’origine de la vague

Courant 2016 lors d’une keynote à l’Agile Conference d’Atlanta, Joshua Kerievsky, CEO de Industrial Logic (société californienne de conseil en agilité) a fait découvrir à la communauté sa définition d’une agilité plus « moderne »…une agilité qui promet d’inscrire les résultats dans la durée.

Qu’est-ce que c’est ?

Modern Agile se dit «  ultra light » : ni rôle, ni responsabilité, ni pratique particulière. Joshua Kerievsky fait évoluer le Manifeste originel en  4 principes directeurs traduits littéralement et officiellement comme suit:

Modern Agile Wheel

Joshua Kerievsky indique que ces principes sont déjà utilisés par bon nombre d’entreprises internationales (AirBnB, Amazon, Google, Etsy…) mais qu’il n’est pas nécessaire d’être une entreprise de marque pour tirer profit de la « sagesse » du mouvement.

Que se cache-t-il derrière ces 4 principes ?

Principe 1 : Rendre les gens fantastiques

Icon - Make People Awesome« Rendre les gens fantastiques » est la traduction officielle de « Make people awesome »,  et consiste à concevoir et réaliser des applications dans le but explicite d’y impliquer les utilisateurs. La société de développement devrait ainsi transformer ses activités sur base de ce principe.

Amazon, par exemple, suivait un concept similaire nommé « Customer Obsession » démarré en 1997. Et de son côté, Steve Jobs avait l’habitude de demander à ses collaborateurs : « Quels incroyables bénéfices pouvons-nous offrir à nos clients ? Où pouvons-nous emmener nos clients ? ».

« Rendre les gens fantastiques » suggère que nous nous efforcions à rendre tout le monde  « fantastique » dans notre écosystème, c’est-à-dire d’impliquer tous les acteurs  y compris ceux qui créent, réalisent, utilisent, achètent, vendent ou même financent nos produits ou nos services.  L’objectif est d’obtenir un cercle vertueux de gens fantastiques ;o)

Principe 2 : Faire de la sécurité un prérequis

Icon - Make Safety a PrerequisiteJoshua Kerievsky enchaîne sur le deuxième principe en indiquant que « Rendre les gens fantastiques » n’est pas possible tant que  ceux-ci ne sont pas en sécurité. Il indique que, par nature, la sécurité est un besoin humain fondamental, une clé vers la performance.  Ainsi, selon Modern Agile, « Faire de la sécurité un prérequis » met en avant les questions de qualité et de sécurité comme un «ingrédient fondamental de succès».

« Faire de la sécurité un prérequis » signifie d’une part établir la sécurité avant de s’engager dans un travail potentiellement risqué. Pa exemple, dans l’industrie, si la sécurité n’est pas améliorée après chaque accident ou presqu’accident, l’excellence est plus difficile à atteindre.

Joshua Kerievsky adresse également la notion de peur et de blâme à cette réflexion sur la sécurité. Il rappelle que très souvent dans les organisations classiques, la peur de l’échec et surtout du blâme tend à étouffer l’efficacité des équipes. Sous le principe Modern Agile, tout le monde travaille ensemble pour résoudre des problèmes en équipe et cet environnement plus « sûr » conduit à un niveau de qualité globalement supérieur dans la livraison de logiciels.

« Faire de la sécurité une condition préalable » exige que nos collaborateurs, nos produits et nos services soient sécuritaires. Finalement, dans tous nos projets, ne nous efforçons-nous pas de protéger le temps, l’argent, la santé, l’information et les relations humaines ?

Dans un contexte de management, ce principe pourrait également se traduire par « Installer de la confiance et de la bienveillance ».

Principe 3 : Expérimenter et apprendre rapidement

Icon - Experiment and Learn Rapidly« Echouer rapidement et en toute sécurité » a fait partie intégrante du succès de Paul MacCready, père du Gossamer Condor (premier avion à énergie musculaire) et considéré aujourd’hui comme l’un des plus grands ingénieurs du 20ème siècle. Expérimenter et apprendre rapidement est un principe directeur du Modern Agile car il nous protège du gaspillage de temps et nous aide à découvrir le succès plus rapidement. Le concept est de rendre nos expériences « sûres à l’échec » et de cette manière de ne pas avoir peur d’en conduire plus.

« Expérimenter et apprendre rapidement » transforme ainsi l’élimination de la peur de l’échec en un système où l’expérimentation et l’apprentissage sont mis en avant. Cela est particulièrement important compte tenu du rythme rapide de changement dans le monde d’aujourd’hui et de demain. La vitesse est l’essence même de l’expérimentation. Si une expérience ne fonctionne pas, le développeur passe simplement à une autre idée.

Principe 4 : Délivrer de la valeur en continu

Icon - Deliver Value ContinuouslyEn Modern Agile, nous allons nous demander : « Comment pouvons-nous livrer les bonnes fonctionnalités plus rapidement ? ». Pour ce faire, l’approche consiste à mettre en évidence des incréments plus petits pouvant être déployés quasi-instantanément  en toute sécurité.

En effet, livrer de la valeur en continu est un bon moyen pour expérimenter et apprendre rapidement (Principe 3). Dans le développement logiciel, le processus de déploiement sûr et continu permet d’atténuer le stress en rendant la livraison plus simple, presque ennuyeuse et quasi-automatisée. Bien sûr la sécurité complète n’est possible que lorsque vous pouvez effectuer rapidement et simplement des livraisons et des roll-backs.

« Délivrer de la valeur en continu » est ainsi très pertinent pour les entreprises disposant d’un programme de livraison continue. L’accent est alors mis sur la valeur qui est mise à disposition du client aussi rapidement que possible. Et les trois autres principes Modern Agile se combinent pour rendre ce principe final possible.

Conclusion

Pour Joshua Kerievsky, ces 4 principes ont pour but de clarifier nos objectifs et nous guider vers une meilleure gestion des risques, une plus grande efficacité,  une empathie accrue et une réduction du travail pour atteindre un résultat durable.

Une autre interprétation pourrait être la suivante : « Modern Agile a pour objectif de faire grandir les gens. Pour cela, il faut installer confiance et bienveillance, on peut alors expérimenter régulièrement et apprendre vite afin d’apporter de la valeur en continu. » (Eric Siber, dans son article proposant de nouvelles déclinaisons francophones)

Modern Agile reste un concept nouveau et les opinions de la communauté sont variées. Certains pensent qu’il s’agit d’un nouveau buzz word et d’autres l’accueillent comme une bouffée d’oxygène venant booster le mouvement AGILE global.

De mon côté, je constate que les quatre principes énoncés ne sont pas si novateurs. Ils existent et sont approchés le plus souvent de manière isolés. Le fait de les mettre côte à côte permet de mieux comprendre leurs liens et la force que leur mise en œuvre conjointe peut apporter.

Modern Agile, comme Holocracy, Management 3.0 et les autres vagues, décline plus ou moins profondément le Manifeste Agile et ses principes, et tente d’apporter de nouvelles touches à adapter au contexte de chacun. À chaque organisation d’en tirer le meilleur et de garder en mémoire qu’au-delà du « doing Agile » et du nom de la dernière vague, c’est le « being Agile » – l’état d’esprit qui est le plus important !

Posted in Non classé | Leave a comment

Blockchain et gouvernance. Pourquoi un Smart Contract n’est pas un Contrat.

« Code is Law » est l’un des slogans les plus connus pour expliquer le fait qu’une transaction, une fois qu’elle a été exécutée sur une blockchain, ne peut plus être modifiée ni altérée par quiconque et ceci sans le contrôle d’un organe central. Le parallèle est tentant : les programmes écrits pour une blockchain font office de loi car ils s’appliquent automatiquement et les comportements qui y sont décrits sont respectés par construction.

Cette caractéristique des Smart Contracts est en fait vraie pour tout programme informatique : l’ordinateur exécute aveuglément le code en respectant exactement les instructions qu’on lui donne. La propriété supplémentaire des blockchains est que la base de données étant inaltérable, on ne peut pas modifier son état et notamment les « soldes » des comptes en monnaie virtuelle sans l’accord des propriétaires des adresses. C’est cette dernière propriété qui fait qu’en réalité, « Code is Law » est une affirmation fausse du point de vue de la loi telle qu’elle existe dans le droit et qu’un Smart Contract n’est en réalité pas un contrat au sens juridique.

En effet, un Smart Contract est écrit par un développeur (un être humain, en tous cas pour le moment) et exécuté par des machines (l’ensemble des nœuds de la blockchain). Si l’exécution du contrat est infaillible car exactement conforme à ses termes (le code), sa rédaction ne l’est pas. L’aventure de TheDAO cet été en est un exemple flagrant. Le contrat passé entre les investisseurs au sein de TheDAO et les futurs projets comportait au moins une clause dont l’application stricte a conduit au transfert d’environ 40 millions de dollars selon une modalité qui, si elle était possible sur le contrat (sinon elle n’aurait pas pu s’exécuter), n’avait pas été anticipée par les contractants, ni même par les rédacteurs du contrat.

L’article 1128 du code civil français consacre le principe de la volonté des parties concernant la formation du contrat :

  • Les parties ont-elles voulu s’engager ? Il faut vérifier leur consentement.
  • Étaient-elles aptes à le vouloir ? C’est le problème de leur capacité.
  • Qu’ont-elles voulu ? Il faut un objet à leur engagement (art. 1163 du code civil).

Ainsi, avons-nous tous réellement la capacité à contracter un engagement rédigé dans un Smart Contract ? La réponse est évidemment non. Il était possible à tout un chacun de se rendre compte de la faille qui résidait dans le Smart Contract de TheDAO et de voir que cette clause du contrat n’était pas conforme à l’objet de l’engagement, mais une seule personne l’a vue et en a profité.

Le second problème concerne la réversibilité et la possibilité de rompre l’engagement. Une fois le transfert prévu par le Smart Contract mais pas prévu par les contractants effectué, il a été impossible de revenir simplement à la situation antérieure sans contrevenir aux principes fondamentaux de la blockchain. Dans le cas d’un contrat classique, quand il est avéré que l’une des parties n’était pas en capacité de contracter, le contrat est annulé par un tribunal et ses effets annulés également. Le tribunal force la partie qui a tiré profit de la situation à rembourser la partie lésée, par un moyen de saisie si nécessaire. Ceci est impossible sur une blockchain si cela n’a pas été prévu dès la création des « contrats ». Une seconde raison pour laquelle un Smart Contract n’est pas un contrat.

Quelles sont les solutions ?

A court terme, pour qu’un Smart Contract se rapproche d’un contrat, il est nécessaire, d’une part de le faire rédiger, auditer et valider par une personne en capacité de le faire, et d’autre part de permettre la réversibilité des actions exécutées suite à la signature de ce contrat si un organisme autorisé (un tribunal par exemple) en décide ainsi.

Dans le langage des développeurs, nous parlons de « Patterns » à propos de programmes informatiques développés en respectant certains principes définis à l’avance, ou de « Frameworks » quand ces programmes réutilisent du code existant et s’exécutent au sein d’un environnement prédéfini, en en respectant les principes de fonctionnement. Il est nécessaire aujourd’hui que des développeurs et des juristes travaillent main dans la main pour créer des patterns de smart contracts et des frameworks dont la structure et les caractéristiques respectent le droit de la juridiction dans laquelle ils s’appliquent.

Posted in Non classé | Leave a comment

Soyez sans limite grâce à l’IA

Être un super héros de la connaissance

Vous rappelez-vous de cette scène du film Matrix où Néo apprenait le Kung-Fu en quelques minutes ? Réalité ou Science-Fiction ?

neo kung fu

C’est à minima un mythe intéressant. Pouvoir devenir expert en tout et sur tout ! Apprendre toutes les disciplines de votre choix, en un temps record. Et si on vous offrait cette possibilité, que choisiriez-vous ?
Vous vous projetteriez en expert du secteur financier, qui anticipe avec précision les évolutions des marchés à la simple lecture des indicateurs disponibles ? Ou en polyglotte parfait, traduisant à la volée une vingtaine de langues ? Peut-être que votre désir profond est de sauver des vies, comme par exemple le soignant qui détectera précocement tout début de cancer chez ses patients ?

Et si je vous disais que vous pourriez être tous ces champions, à la fois.

Demander conseil à un personne de confiance

L’humanité pratique la mise en commun des connaissances depuis son commencement. C’est ce principe même de regroupement d’individus intégrant une culture commune qui amena le concept de groupes sociaux, de villes et même de civilisations.  Une conséquence importante de ce regroupement est qu’il n’est pas nécessaire de tout connaître personnellement, mais de diviser les connaissances sur plusieurs personnes, chacune se spécialisant dans un domaine particulier. Afin de résoudre une problématique, demander à son réseau permet de récupérer une partie de cette connaissance et de cette expérience, et donc de résoudre le problème comme si nous la possédions nous-même.

La confiance joue un rôle très important dans ce processus. C’est sur base de la confiance que nous choisissons la personne à qui nous allons nous adresser. Mais comment juger de la pertinence de la connaissance d’une personne ? Un expert gagne ainsi souvent sa réputation grâce à la qualité de son travail passé.

Se pose la question suivante : si un ami arrive à prédire la valeur du cours de la bourse du lendemain, sans jamais se tromper, mais que vous ne puissiez pas comprendre son raisonnement, le considéreriez-vous comme quelqu’un digne de confiance ?

Et si cette personne de confiance n’était pas une personne mais reposait sur l’Intelligence Artificielle ? Les évolutions récentes en capacité de calcul, dans les algorithmes de Machine and Deep Learning permettent dès maintenant d’accéder à la connaissance dans de nombreux domaines.

L’aire de l’expertise artificielle

L’intelligence artificielle (IA) est un vaste domaine dont un en particulier ne cesse de battre des records ces derniers temps, celui de « l’Apprentissage Automatisé » ou « Machine Learning ». Les avancées scientifiques et technologiques sont désormais telles qu’on devine l’arrivée d’une singularité technologique, et d’un bouleversement dans l’usage de nos outils informatiques.

Prenons quelques exemples permettant de se rendre compte de ces avancées et des possibilités apportées par l’IA. Intéressons-nous à des applications liées à la médecine, la compréhension du langage, et l’art. Ces domaines sont pourtant, à priori, réservé aux meilleurs experts humains. Ils demandent un croisement de compétences, d’expérience et de capacités cognitives que seuls les humains peuvent détenir.

Domaine médical

Oui, il est désormais possible de détecter les signes de cancer, avec un gain clair en fiabilité de la détection, en utilisant l’Intelligence Artificielle. Le croyez-vous ?

pathAI
Taux de détection de métastase dans les ganglions lymphatiques. PathAI

Un algorithme intelligent permet donc, dès aujourd’hui, de fournir des indices suffisamment fiables du développement de métastases. Une telle conclusion doit cependant être remise en perspective, puisqu’il s’agit uniquement d’un type de cancer précis dans une zone précise du corps. Et si l’IA seule est déjà efficace, le fait de travailler conjointement avec une équipe médicale permet d’atteindre des records de fiabilité. La démarche est ici importante. Ces chercheurs n’ont pas tenté de remplacer l’humain, mais d’intégrer l’IA comme un expert à part entière associé au personnel médical, finalement comme une personne digne de confiance.

PathAI se base sur une technologie appelée « réseaux de neurones convolutionnels » et dont il est quasiment impossible de tirer un raisonnement compréhensible par un humain. Mais les résultats sont là et la technologie digne de confiance, puisqu’elle aura prouvé sa capacité de compréhension sur des milliers de cas passés. De la même manière qu’un expert devenu crédible grâce à la reconnaissance de la qualité de son travail.

Une difficulté intellectuelle intervient alors. Comment faire confiance à ce réseau de neurones dont nous ne pouvons pas appréhender la logique ? Cela reste un raisonnement logique mais qui ne s’apparente plus à la logique humaine.

Domaine linguistique

Nous parlions aussi de devenir un expert linguiste. Microsoft a récemment annoncé la nouvelle suivante sur son blog : «Historic Achievement: Microsoft researchers reach human parity in conversational speech recognition ».

Les réseaux de neurones sont donc désormais capables de retranscrire une information auditive de façon tout aussi fiable qu’un humain. Ils dépassent même très légèrement l’humain. Traduction simultanée, retranscription parfaite, sous-titrage en temps réel pour malentendants, autant de possibilités ouvertes dès aujourd’hui.

Domaine artistique

Comme dans bien d’autres domaines, l’art commence à se révéler comme un des terrains où les machines peuvent nous accompagner. Les machines ne sont pas encore capables de générer de l’art à proprement parler, mais d’autres approches existent.

neural transfer

Exemple de transfert de style basé sur Van Gogh

Soyons franc, un amateur pourrait se laisser berner et penser qu’il s’agit là d’une œuvre originale de Van Gogh. Ceci prouve que l’IA peut désormais comprendre des phénomènes dépassant la simple analyse de données, pour accéder à ce qui paraissait réservé pour de longues années à l’esprit humain.

Le paradigme de l’IA

L’IA amène donc un changement de paradigme. Deux objectifs sont à distinguer.

  1. Chercher à répondre à une problématique sans nécessiter de redéfinir l’état de l’art (donc sans aller plus loin dans la compréhension même des propriétés),
  1. Chercher à créer un nouveau produit ou service qui nécessite une amélioration de l’état de l’art (donc en approfondissant notre perception des propriétés).

Dans le premier cas, concevoir une architecture basée sur des modèles d’IA existants sera souvent bien plus rapide que d’acquérir une véritable expertise dans le domaine et les propriétés qui le caractérise. Un exemple concret réside dans le domaine de la vision par ordinateur (appelé aussi « computer vision ») où concevoir un réseau de neurones permet en quelques jours d’atteindre l’état de l’art des algorithmes classiques. Et pourtant ces algorithmes classiques nécessitent de maitriser parfaitement de nombreux aspects du traitement d’images puis de les implémenter.

Dans le second cas, l’exemple de PathAI est flagrant. Une équipe de deux personnes, dont une n’ayant pas de connaissance dans le domaine médical, a repoussé les limites de la médecine. Microsoft et les géants de l’Internet (Google, Amazon, Facebook…) possèdent également ces capacités et ces technologies promettant une intelligence supérieure à l’humain dans certains domaines de prédilection de l’Homme, comme la communication.

Sommes-nous prêts ?

L’Intelligence Artificielle devient donc cet expert polyvalent, présent à nos côtés comme une capacité latente, prête à vous aider dans vos problèmes quotidiens. Un expert qui s’entraîne et s’améliore grâce à la masse de données s’accumulant dans l’hyper cloud depuis ces 10 dernières années. Un expert qui nous permettra également de deviner, de définir des opportunités nouvelles.

Vous pouvez donc devenir un expert dans le domaine de votre choix. Par quoi commenceriez-vous ?
A moins que la question essentielle soit : êtes-vous prêt à accepter ce nouveau paradigme ?

Posted in Non classé | Leave a comment

Lectures d’Homo InTechus #2 : The Art Of Business Value

À l’heure où nous parlons d’Agilité ou de DevOps pour délivrer au mieux de la valeur, savons-nous vraiment identifier cette valeur que nous souhaitons maximiser ? C’est la question à laquelle tente de répondre Mark Schwartz dans son livre The Art of Business Value.

TABV-cover

La notion de «Business Value» est au cœur de l’Agilité. Elle est même si centrale que sa définition en est oubliée. Le postulat est souvent le même : nous attendons qu’une personne du métier détermine cette valeur pour qu’elle puisse ensuite être découpée en fonctionnalités qui seront livrées selon les priorités fixées.

Malheureusement, la valeur n’est pas une simple formule détenue par le métier mais plutôt quelque chose de propre à chaque organisation et qui doit être découvert. Est-ce alors le rôle du métier ? d’un product owner ? des équipes de développement ? d’un comité X ou Y ?

Nous croyons à tort que le rôle d’un service IT se limite à traiter passivement les demandes du métier. Dans ce contexte, même avec la mise en place de méthodes Agiles comme Scrum, créer de la valeur reste difficile. Si nous souhaitons qu’une équipe agile crée de la valeur, elle doit être impliquée dans son processus de découverte et non se limiter à traiter uniquement de simples demandes.

La bureaucratie : réel obstacle à l’Agilité ?

La littérature Agile désigne souvent le fonctionnement traditionnel d’une organisation comme un obstacle à l’Agilité. La bureaucratie et ses règles sont perçues comme des « impediments » qui empêchent une adoption des principes Agiles. En effet pour fonctionner l’adoption doit être globale à l’organisation. Il s’agit là d’un changement profond à opérer. Et évidemment un tel bouleversement culturel ne se fait pas sans douleur. 

Mais ces obstacles peuvent également apporter des éléments utiles pour identifier la valeur dans l’organisation ; des éléments qu’une équipe Agile ne perçoit pas toujours. Plutôt que d’engager un changement par une approche dite « big-bang », il est préférable d’avancer pas à pas de manière à comprendre réellement l’organisation et ses besoins pour diriger au mieux ce changement.

Une approche Agile pour une adoption de l’Agilité.

Bien qu’elle désavoue les règles, la communauté Agile en est remplie. Les règles sont un moyen d’apporter de bonnes pratiques dans notre travail quotidien. Est-ce que ces règles font de l’Agilité une véritable bureaucratie ? Le problème de la bureaucratie est que les règles ont souvent vocation à ne pas être changées. Elles restent gravées dans la pierre tandis que les bonnes pratiques, elles, évoluent.

L’IT au centre de la valeur

L’IT est souvent réduit au rôle de « service provider » d’une organisation. Le métier formule ses besoins, l’IT élabore un plan et s’il est accepté alors un projet est lancé pour aboutir à un produit final. Ensuite le métier le réceptionne et essaie d’en tirer une valeur ajoutée. C’est une approche très contractuelle qui au final ne permet pas de garantir une création optimale de la valeur. Ici le métier joue le rôle de client et l’IT se charge de traiter la « commande ». Cette isolation des parties les empêchent de réellement collaborer et d’atteindre un but commun.

C’est un piège de considérer le métier comme un client du service IT.  L’IT doit surpasser ce modèle pour devenir aussi bien un interprète de la valeur qu’un fournisseur d’expertises techniques. Son interprétation doit peser sur la stratégie globale de l’organisation tout comme n’importe quel autre département. L’IT doit accompagner l’organisation dans la recherche et la production de Valeur.

Un pipeline pour délivrer de la valeur en continu

Lorsque nous adoptons une démarche Agile pour maximiser la valeur, c’est pour que ce processus soit rapide, transparent et source de feedbacks. Et le meilleur moyen que nous connaissons aujourd’hui  pour y arriver se nomme DevOps : une approche visant à briser les silos et réduire les conflits pour construire une véritable chaîne de production automatisée autour d’équipes unifiées.

En s’installant dans les processus organisationnels, en automatisant les bonnes pratiques qui évoluent et en mesurant les résultats, DevOps permet la mise en place d’un véritable flux de création de valeurs. Les contraintes sont absorbées par le pipeline à la manière d’une boîte noire pour ne réduire les inputs qu’aux besoins métiers et fournir en sortie non pas une simple fonctionnalité mais une fonctionnalité déployée en production. Une nouvelle boucle de feedback se crée permettant à l’organisation de réellement mesurer la valeur produite.


Pour conclure, Mark Schwartz apporte tout un tas d’éléments basés sur son expérience de CIO pour permettre au lecteur de découvrir et mesurer sa « Business Value ». Ne cherchez pas de formule magique dans ce livre car elle n’existe pas, sa définition reste avant tout un voyage. À vous de le découvrir.

« But understand that there is no magic formula for business value that only the business people know. Ultimately, it turns out that business value is what the business values, and that is that. », Mark Schwartz.

Posted in lecture | Tagged , , | Leave a comment

Lectures d’Homo InTechus #1 : Mastery

Quoi de mieux qu’un bon livre pour vous accompagner en cette période estivale.

Mastery

Que ce soit pour un art, un sport ou une compétence particulière, la maîtrise d’un domaine n’est pas uniquement réservée à des gens hyper-talentueux mais bien accessible à tous. C’est ainsi que George Leonard démarre son livre  Mastery: the keys to success and long-term fulfillment.

La maîtrise n’est pas un but mais une longue phase d’apprentissage que l’auteur illustre sous la forme suivante : une succession de plats à chaque fois un peu plus élevés que les précédents appelée The Mastery Curve.

mastery-curve

The Mastery Curve

La progression se fait par légers bonds espacés de phases plus ou moins longues appelées plateaux. Celui en quête de maîtrise doit s’attendre à passer une grande partie de son temps sur un plateau : ce fameux moment qui semble interminable où nous avons le sentiment de ne plus progresser ; celui où la tentation d’abandonner est la plus grande.

Alors pourquoi passer autant de temps sur un plateau ? Continuer à s’exercer sans relâche, échouer puis recommencer est la clé pour atteindre son objectif. Cette étape est nécessaire pour atteindre le plateau suivant. Accepter le plateau sur lequel nous sommes c’est tout simplement suivre sa passion.

La maîtrise n’est pas une destination mais un chemin qu’il faut apprécier. Dans son œuvre, l’auteur nous donne les clés qui aideront à passer du statut d’apprenti à celui de maître.

For the master, surrender means there are no experts. There are only learners.

Pourquoi un tel livre ?

Mastery ne traite absolument pas de notre métier et tant mieux ! La vision portée par l’auteur est beaucoup plus large et parlera à toutes celles et ceux en quête d’amélioration dans leurs domaines de prédilection.

Ce que j’ai aimé :

Il met en avant des notions au cœur du Software Craftsmanship (pratiquer et s’améliorer) et de l’Amélioration Continue. Si l’un de ces deux termes vous est familier, ce livre est alors pour vous ! Bonne lecture 😉

Posted in lecture | Tagged , | Leave a comment

Plus d’agilité dans nos stages

Les stages 2016 chez InTech c’est 13 stagiaires issus de 6 cursus universitaires différents qui nous ont rejoint depuis ce printemps pour 6 mois soit un potentiel de plus 1500 j/h répartis sur 8 sujets/projets dont 4 en partenariat avec nos clients et partenaires.

C’est également plus de 20 collaborateurs InTech concernés de près ou de loin par les stages: tuteurs, experts, management et direction.

seminaire-agile-2016Nous avons initié, cette année, le programme collectif Stage AGILE qui vient compléter les actions déjà menées depuis quelques années pour la partie purement technique.

Le stage AGILE, Pourquoi ?

L’objectif de cette démarche est double :

  • d’une part, elle donne aux stagiaires l’occasion d’appréhender l’agilité dès son stage, lui apportant une première expérience Agile au plus proche du terrain.
  • d’autre part, le stage permet aux tuteurs de stages d’expérimenter l’agilité au travers de nouveaux rôles et de nouvelles pratiques. En introduisant l’agilité dans le stage, le tuteur a l’occasion de prendre des rôles divers comme Product Owner, Facilitateur, Expert technique ou fonctionnel voire selon son expérience Coach. Il est intégré à l’équipe Agile avec le(s) stagiaire(s) encadré(s).

Ainsi le Stage AGILE permet à chacun des acteurs de progresser et d’expérimenter des facettes de l’agilité.

Le stage AGILE, Comment ?

Nous avons découpé la démarche en 3 grandes étapes : pre-games, game, feedback !

Etape 1 : les pre-games

connaissanceEn parallèle de l’intégration du stagiaire dans l’entreprise, de la découverte plus en profondeur de son sujet de stage et de la formation technique dispensée par nos Experts Techniques, nous avons initialisé la démarche AGILE en proposant une étape d’initiation aux tuteurs et aux stagiaires:

Tout d’abord nous avons organisé une demi-journée de sensibilisation pour les tuteurs de stage qui n’étaient pas encore à l’aise avec l’agilité.

Puis nous avons mené un séminaire agile pour l’ensemble des stagiaires. Au-delà de la formation théorique, cela a été l’occasion de proposer des Serious Games, des Icebreakers, des Workshops…. A l’issue de ce séminaire, chaque stagiaire a pu avoir une réflexion concrète sur la mise en place de l’agilité dans le contexte de son stage et ainsi rédiger un engagement en conséquence.

Etape 2 : le game

gameTout au long du stage, cette étape permettra aux acteurs de mettre en exergue les principes et bonnes pratiques échangées pendant les différents workshops. Un accompagnement sera proposé par les coachs pendant toute cette phase ainsi qu’une formation de sensibilisation à la qualité logicielle.

Etape 3 : le feedback

feedbackCette étape finale sera l’occasion pour chaque stagiaire de clôturer son activité : finalisation, livraisons, rédaction du rapport de stage. Pendant cette période (août-septembre), nous recueillerons le feedback de chacun en s’interrogeant sur la suite à donner en 2017.

 

Le programme est ambitieux et doit être nourri par la participation de chacun des acteurs impliqués. Il reste également ouvert aux questions, aux idées et autres améliorations, alors n’hésitez pas à prendre contact avec nous.

Peggy Tarillon et Julien Ledoux

Posted in Non classé | Tagged , | Leave a comment