Blog entries by Sylvain Thenault [3]
  • Exemple de "contrat agile" mis en place entre Logilab et ses clients

    2015/06/18 by Sylvain Thenault

    Dans la mesure du possible, nous essayons de travailler avec nos clients en mode agile. Bon, c'est pas toujours évident, ça ne s'applique pas à tout le monde, mais ce n'est pas le sujet de ce billet. Supposons donc que vous ayez un client déjà initié au sujet et souhaitant fonctionner de cette manière avec vous (si si ça peut arriver !).

    Même dans ce cas, il reste à préciser un certain nombre de points qui vont définir plus précisément les processus et interactions, comme par exemple la durée des itérations, le ou les environnements de test / production et autres manières d'utiliser les outils de suivis. C'est précisément l'objet de ce qu'on appelle le contrat agile, dont voici un exemple qu'il me semble utile de partager avec vous (miroir sur slideshare).

    https://www.logilab.org/file/294043/raw/handshake.jpg

    (photo by Julia Taylor licence CC BY-NC-ND )

    Cet exemple a été légèrement anonymisé. Il rappelle quelques éléments d'agilité et définit :

    • le cycle de développement (itération, recette, etc)
    • les livrables et environnements
    • le mode de fonctionnement avec notre extranet de suivi (une variante de cette forge)

    Il vous faudra donc de fait l'adapter à votre projet, en collaboration avec votre client. Et évidemment, dans un esprit agile, le faire évoluer au fur et à mesure du temps (dans l'exemple avec notre client, nous en sommes à la 3eme version).

    Les sources sont du HTML qui utilise showr et je n'ai aucun problème à les partager pour ceux qui ça intéresse.

    Enfin merci de me faire part de vos remarques et retours sur ce contrat !


  • De retour du raid agile

    2015/03/17 by Sylvain Thenault
    https://www.logilab.org/file/288474?vid=download

    J'ai eu la semaine dernière la chance de participer au raid agile organisé par Pablo et Claudio. Je dis bien une chance car, de mon point de vue, cette formation atypique donne vraiment l'occasion de passer quelques jours loin du quotidienn dans un cadre idyllique et une ambiance sympathique, à réfléchir aux fondements des méthodes agiles. En plus d'y (re)découvrir un tas d'outils et de jeux agiles, c'est l'occasion d'échanger avec tous les participants et de remettre en cause ses pratiques. Bref, une bonne remise à zéro des compteurs. Je ne vous révélerais pas plus l'emploi du temps minuté-mais-aéré des trois jours (vous en saurez plus sur le site), je ne saurais que vous recommander de sauter sur l'occasion de partiper à une prochaine édition du raid !

    Ceci étant dit, revenons-en à l'objet principal de ce billet : ce que j'ai ramené dans ma petite tête pour améliorer nos pratiques à Logilab. Ou en tout cas celle que j'essaie de mettre en place avec mon équipe à Toulouse.

    Une de mes principales problématiques est la suivante : comment adapter une méthode comme Scrum ou un outil comme le kanban dans le cadre d'une petite société de service, où nous avons majoritairement des petits projets, plusieurs en parallèle, développés par une à deux personnes maximum ? La littérature sur le sujet applique systématiquement (à ma connaissance) la méthode à des équipes de développement "produit" avec des phases souvent gérées par des personnes différentes (développeurs, testeurs, intégrateurs, etc.). Ça fait un moment que je tâtonne sur le sujet, d'une manière parfois satisfaisante, parfois frustrante, mais certainement améliorable. Sans prétendre avoir répondu à toutes mes interrogations, une réflexion de Claude m'a donné envie d'améliorer un point en particulier : travailler en équipe, plutôt qu'être une somme d'individus dans un même espace. Le principal changement à conduire consistera donc à faire travailler tous les membres de l'équipe sur tous les projets. Il y aura bien sûr un coût non-négligeable dans la mise en place de chacun sur chaque projet, mais j'espère que cela sera contrebalancé par :

    • la montée en compétence de l'ensemble de l'équipe ("essaimage")
    • moins de spécialisation individuelle, plus de souplesse dans la gestion des projets
    • un renforcement de l'esprit d'équipe

    Pour moi, ça vaut donc le coup de tenter ! Et le compagnon de ce changement sera un autre point qui me pose souvent question : le découpage des besoins du client en user stories (voir features ou epics) et tâches, leur relation avec le kanban qu'on essaie de mettre en place (principalement pour visualiser les tâches de chacun jusqu'ici) et notre extranet de gestion de projet. Jusqu'ici, nous dupliquions plus ou moins l'information, sans vraiment faire ressortir la notion de tâche autrement que dans les discussions informelles. Pour maintenir un rapport coût de gestion / besoin de collaboration et d'indicateurs, on va maintenant essayer de maintenir les histoires dans l'extranet, avec leur estimation, les discussions avec le client et autres (dépendance, relation aux features, etc.), tout en ayant sur le kanban les tâches qui en découlent. Ceci devrait notamment permettre de mieux échanger sur les implémentations des différentes histoires en amont, voire de permettre à plusieurs personnes de travailler sur la même histoire. Et ainsi de rendre le kanban plus au centre de notre gestion quotidienne en diminuant sa granularité.

    Ces deux points sont les gros morceaux qu'il va falloir digérer dans les prochains mois. Parmi les autres points abordés ou évoqués pendant la formation et ramenés en stock, il y a :

    • faire un delegation board avec l'équipe à Toulouse et peut-être aussi à l'échelle de Logilab entre les équipes de direction et de développement, voire au sein de l'équipe de direction ;
    • ne pas oublier de faire fixer l'heure sur l'horloge de Cohn à nos clients qui jouent le jeu de l'agilité (ils ne seront jamais assez nombreux) ;
    • faire plus de rétrospectives, sans hésiter à en essayer différentes formes ;
    • à l'occasion, réessayer un impact mapping, l'exercice le plus délicat que nous ayons abordé ;
    • rappeler que si on fait des journées "compactes" à Toulouse, il ne faut pas oublier de maintenir un rythme soutenable. Voir acheter un canapé ou un siège confortable pour les amateurs de power nap (merci Pierre-Jean dont la pratique décomplexée est rafraichissante !) ;
    • enfin creuser les core protocols et le business value game dès que possible, voire réfléchir au #noSlides pour nos formations techniques.

    Voilà, y a encore d'autres restes parmi les outils et idées discutés, mais je pense avoir cité ici l'essentiel et ça promet déja des impacts non négligeables. J'accueillerais avec plaisir vos remarques ou idées sur les points ci-dessus. Et avec un peu de chance j'aurais même le courage de faire un billet pour raconter ces différentes expériences ! En tout cas, encore un grand merci à Pablo et Claudio ainsi qu'à tous les participants de ce raid du changement.


  • Sprint PyLint @ PyConFr 2012

    2012/08/20 by Sylvain Thenault

    Un sprint PyLint est organisé dans le cadre de la conférence PyConFR, les 13 et 14 septembre à Paris. Si vous voulez améliorer PyLint, c'est l'occasion : venez avec vos bugs et repartez sans !

    Les débutants sont bienvenus, une introduction au code de Pylint sera réalisée en début de sprint. Une expérience avec le module ast de la librairie standard est un plus.

    Croissants et café offerts par l'organisation, merci de vous inscrire pour faciliter la logistique. Voir avec Boris pour plus d'informations (merci à lui !)


  • Mêlée numérique 2012: État de l'art Big Data

    2012/05/03 by Sylvain Thenault
    http://www.logilab.org/file/92705?vid=download

    J'ai passé ce jeudi 26 avril à la Mêlée numérique à Toulouse.

    Après une mini-conf d'une heure sur l'état de l'art de l'Open Data, j'ai suivi l'après midi "état de l'art Big Data" au même format.

    Big Data vu par SGI

    Ma première surprise a été d'apprendre où était caché SGI (vous vous rappelez peut-être les postes Indigo qu'on trouvait pour faire du graphisme et de l'animation...) depuis tout ce temps : et bien non, ils ne sont pas morts mais montent des calculateurs pour des grands comptes. Le premier intervenant était donc M. Carsalade, responsable infrastructure chez SGI, qui a pris quelques exemples d'applications et d'infrastructures "Big Data" (petabytes de données) menées par SGI.

    Parmi les applications citées : calculateurs chez NOAA (sorte de Météo France aux US) ou Total (analyse des sols), Cosmos Project (15 tera de ram...), génomiques

    SGI déploie par ex. :

    • 500 000 serveurs SGI chez Amazon pour S3/eC2, site web, AWS...
    • 300 000 serveurs SGI chez Microsoft pour Live Search (Bing, Exchange, MSN, etc.)

    La technologie est souvent basée sur HADOOP, qui permet la recherche en parallèle sur un cloud, basée sur le principe map / reduce initiée par Google.

    On note l'évolution des technologies dans le temps et par volume croissant:

    • OLTP (données structurées),
    • data warehouse (données essentiellement structurées),
    • Big Data (données essentiellement non structurées)

    Il conclut que Big Data, c'est :

    • la capacité de stockage de données, et celle de l'agrandir au fur et à mesure du besoin,
    • travailler sur ces données (HADOOP), les analyser et les visualiser,
    • mais aussi archiver ces données, problématique souvent ignorée au premier abord mais pourtant nécessaire.

    Big Data vu par une PME spécialisée

    La présentation suivante de M.Royer (Datasio) est un peu plus technique.

    Pour commencer, une liste des sources de données problématiques potentielles (i.e. la production ne s'arrête pas) :

    • production par des réseaux d'observation autonome (capteurs météo, GPS, RFID, balises Argos...),
    • données dépendantes d'une communauté d'utilisateurs et d'individus instrumentés,
    • données produites plus vite qu'on ne les traite,
    • "on verra le traitement plus tard".

    Synthèse de ces problèmes : les "3 V" du Big Data: Volume / Variété / Vélocité.

    Les techniques autour de Big Data promettent de :

    • faciliter la collecte et l'aggrégation (mesurer les opérations, acquérir tous les flux possibles, stocker les mesures brutes)
    • valoriser le capital de données (découvrir après coup des opportunités inexploitées, outils de fouille adaptés aux gros volumes, extraire et distiller l'information)

    Il revient sur HADOOP en quelques mots :

    • solution Open Source, issu de la fondation Apache,
    • à l'initiative de Yahoo via un essaimage Hortonworks
    • c'est un projet en maturation, avec une communauté active, mais des branches de code variées,
    • constitué d'un système de fichier distribué avec redondance (parallélisation des données) et possibilité map / reduce (parallélisation des tâches à effectuer sur les données)

    Si Big Data est un nouveau terme pour une problématique qui n'est pas nouvelle, une différence liée à la technique map / reduce les traitements sont effectués sur les serveurs qui hébergent les données au lieu de pousser les données vers un calculateur. Attention au fait cependant que pour fonctionner, les algorithmes doivent fonctionner de manière indépendante sur un sous-ensemble indéterminé de données (donc finalement indépendamment sur chaque "donnée"). Enfin, on se concentre sur l'efficience de la création et de la lecture des données, à l'inverse des bases de données traditionnelles qui se concentrent également sur la mise à jour et la suppression.

    Je ne sais pas s'il y avait une conclusion, la présentation a été abrégée faute de temps.

    Big Data vu par Météo France

    La dernière présentation était celle de M.Beuraud de Météo France dont la problématique, pas simple mais à laquelle nous sommes tous sensibles, est la prévision numérique du temps.

    Il note tout d'abord que la qualité des prévisions a augmenté : la qualité d'une prévison à 48h aujourd'hui vaut prévision à 24h il y a 15 ans en lien avec l'augmentation des performances du centre de calcul HPC de Météo France à Toulouse (évolution matérielle tous les 3 ans) :

    • 2 GFlops en 1991 (date de l'ouverture du centre), basé sur des machines Cray 2,
    • 100 TFlops en 2009, basé sur des machines NEC SX9

    Le volume de données étudiées est maintenant beaucoup plus important, principalement du fait de la constellation de satellites qui s'est développée et qui produit un volume beaucoup plus important que les mesures conventionnelles (au sol). On a vu un "déluge de données" satellitaires depuis 2010. D'un point de vue stockage, le site est passé de 20Go en 1991 à plusieurs pétaoctets aujourd'hui.

    De par les différentes contraintes extérieures (données à fournir aux clients), une prévision à 24h doit être faite en 25 minutes. De plus, la puissance de calcul nécessaire augmente sans cesse notamment à cause des facteurs suivants (en plus du volume de données à analyser qui augmente) :

    • maille de plus en plus petite,
    • couplage de modèles de plus en plus nombreux,
    • prévision ensembliste : on lance X fois le même modèle avec des entrées différentes pour voir la stabilité de la prédiction.

    A noter qu'ici, on n'est pas dans des technos de type HADOOP.

    Il conclut que le volume de données à traiter va continuer à grandir, et que la gestion des données est l'enjeu majeur de la décennie qui s'ouvre.

    Conclusion

    J'ai été surpris de voir l'angle d'approche pour la présentation d'une thématique Big Data, qui était pour moi (novice je l'avoue) plus liée aux technologies Web. J'ai finalement trouvé que c'était intéressant de remettre ça avec cette perspective, et ainsi de replacer ce que recouvrent finalement les mots Big Data. Encore un grand mot qui veut tout et rien dire quoi :p


  • Mélée numérique 2012: État de l'art Open Data

    2012/04/27 by Sylvain Thenault
    http://www.logilab.org/file/92705?vid=download

    J'ai passé ce jeudi 26 avril à la Mélée numérique à Toulouse.

    J'y ai assisté à une mini-conf d'une heure sur l'état de l'art de l'Open Data. Comme d'habitude, je conseillerais plutôt, lors des salons de ce type, d'aller voir les conférences sur des thèmes qui vous sont inconnus, sous peine de ne pas apprendre grand chose. C'est resté pas trop mal, et voici ce que j'ai retiré de cette présentation conjointe de Bluenove, et Inno3.

    Data, c'est quoi exactement ?

    Dans le cadre de l'Open Data la donnée est le matériaux brute. C'est une valeur, une observation. Ce n'est pas une information, qui recoupe et interprète plusieurs données.

    Le recoupement de données permet de créer des informations de valeurs. Cependant certaines données n'ont pas vocation à être ouvertes (ex. données stratégiques, personnelles, défense).

    Qui sont les acteurs de l'Open Data ?

    On distingue :

    Qui a ouvert ses données ?

    En France : Étalab, 16 ministères, 5 administrations publiques, 2 régions, 5 départements, 11 métropoles, 7 municipalités, 3 grandes entreprises (réseau férré, sncf, la poste), 4 initiatives culturels, PS...

    Dans le monde: 28 pays, environ 120 localités de toutes tailles. On voit se former des initiatives continentales,

    Pour quels résultats ?

    • Un nouveau type d'information (NR issu d'une collaboration journaliste/développeur/graphiste), plus ou moins couvert sous le terme "Data viz" (eg OWNI)
    • Des applications diverses, parfois issues de concours (eg application téléphone Tourisme 71)

    Quels sont les freins et incitations ?

    Il y a une incitation/obligation venant de l'Europe (2003) et de l'état (2006) pour les acteurs publics, les acteurs privés délégataires d'un service public ou monopolistiques. On peut ajouter les modèles économiques basés sur la société de l'information (eg http://www.openstreetmap.org/ qui crée des données ouvertes collaborativement depuis 2006)

    Les freins viennent :

    • des données non diffusables,
    • d'une cohabitation parfois difficile avec Loi informatique et liberté / CNIL (le recoupement de plusieur sources peut finir par redonner des données "personnelles").

    De plus cette incitation à la transparence crée nouveaux rapport entre secteur public et privé (je ne m'en plaindrai pas personnellement :p ).

    Quels droits / quelles licences sur les données ?

    Rappel : la propriété intellectuelle recrée une notion similaire à la propriété matérielle mais sur des oeuvres. Les données ne sont pas soumise à la propriété intellectuelle. Les données originelles, ainsi qu'une base de données à forte valeur ajoutée, ou encore les signes distinctifs (marque, nom de domaine, logo, etc) sont considérés ou considérables comme des oeuvres.

    Il faut donc une gestion stratégique des différents droits de propriété intellectuelle. Que faut-il partager ou retenir ? Quel est l'encadrement souhaité ? Copyleft (eg GPL) ou non ? Compatibilité entre jeux de données ?

    Aujourd'hui on a comme licenses pour les données :

    • les licences basées sur le droit d'auteur (CC)
    • les licences basées sur la loi de 1978 (droit public en france, uniquement pour collectivité, pas de propriété intellectuelle) (LIP et APIE)
    • les licences spécialisées (ODBL, PDDL, ODC-By créées par Open knowledge foundation)
    • les licences dédiées (Licence Ouverte)

    En France (dans l'administration publique ?) l'ODBL et la Licence Ouverte sont principalement utilisées.

    En Europe et à l'étranger, on trouve plutôt l'ODBL, CC-0 et autres licences dédiées.

    Et l'Open Data dans l'entreprise ?

    Bluenove a mené une enquête auprès de grands groupes. Quelques résultats (l'intégralité est publiée dans un petit livre blanc dont j'ai un exemplaire) :

    • les bénéfices attendus de l'ouverture et de la réutilisation sont avant tout d'améliorer la satisfaction des clients, et en dernier lieu de se différencier de ses concurrents
    • les obstacles ressentis : le besoin de contrôler la réutilisation de ses données, la peur de donner l'accés à ses données aux concurents ou encore la frilosité à la réutilisation de données des autres (problème potentiel de fraicheur et/ou qualité des données)

    43 % des entreprises sondées disent qu'une réfléxion autour de l'Open Data est en cours évolution.

    Conclusion

    Aujourd'hui, les licences sont matures et ne posent plus vraiment problème. On peut espérer avoir rapidement plus de données et d'acteurs dans l'Open Data. Cependant dans le public comme dans le privé une difficulté est d'encadrer la production : motiver la production de données, accueillir les résultats et gérer la diffusion (qui a dit CubicWeb ? En toute objectivité :p ).

    NR: On notera l'absence de discussion autour des formats de publication de données notamment. Pour conclure, j'aurais plutôt appelé ça état les lieux que état de l'art, même si ça reste un effort de synthèse appréciable.