Skip to content

Blogs de Développeurs: Aggrégateur de Blogs d'Informatique sur .NET, Java, PHP, Ruby, Agile, Gestion de Projet

Forum Logiciel

Forum Logiciel : diffusion de connaissance et d’informations sur toutes les activités liées au développement d’applications informatiques en entreprise.

Agrégateur de flux

[événement] Agile Games Night, ouverture de la billetterie !

Agile Nantes - jeu, 04/16/2015 - 07:59
La billetterie est ouverte !

La nuit dĂ©diĂ©e aux jeux agile se dĂ©roulera du vendredi soir 18h jusqu’Ă  1h du matin avec des temps collectifs et des temps pour jouer en sous-groupe. Sandwichs et boissons sont prĂ©vus !

Quand et oĂą ?

Où: la Cantine numérique de Nantes, 11 impasse Juton, Chaussée de la Madeleine

Quand: vendredi 29 mai, 18h-01h

Une participation de 15€ est demandée, inscription ici.

N’hésitez pas à transmettre l’information autour de vous.

Merci à la Cantine Numérique de Nantes qui nous accueille.

Catégories: Association

Une soirée boxe avec Brahim Asloum vue par 2 Ippon

Blog d’Ippon Technologies - mer, 04/15/2015 - 17:39

- Bonjour Jimmy, bonjour Grégoire, pouvez-vous vous présenter en quelques mots ?

Jimmy : Bonjour, je suis ingĂ©nieur Systèmes & RĂ©seau. Je suis dans l’Ă©quipe Ippon Hosting, je pratique le foot et le vĂ©lo.. J’ai fait quelques annĂ©es de Handball et de Basket Ă  Istres.

GrĂ©goire : Je suis passionnĂ© de nouvelles technologies et de sport. J’ai eu l’occasion de faire beaucoup de sports diffĂ©rents, du Judo (sport national de Ippon), du running, de la boxe, du tennis…

- Vous avez tous les deux participĂ© Ă  l’entraĂ®nement de boxe avec Brahim Asloum, Quelles ont Ă©tĂ© vos premières impressions quand vous l’avez rencontrĂ© ?

J : J’ai Ă©tĂ© agrĂ©ablement surpris par la gentillesse de Brahim Asloum, très cool et Ă  l’Ă©coute.

G : J’avais dĂ©jĂ  vu quelques combats de Brahim en vidĂ©o donc je savais dĂ©jĂ  Ă  quoi il ressemblait. Mais c’est toujours amusant de rĂ©aliser qu’un homme comme lui, plein de confiance en lui et avec un certain charisme, est champion du monde et peut me mettre K.O en une fraction de seconde !

Briefing de Brahim Asloum
- Vous aviez déjà fait de la boxe avant ?
J : Non pas du tout !

G : J’ai dĂ©jĂ  fait de la boxe avec Said Skouma (champion d’Europe il y a 30ans), mais j’avais du arrĂŞter quand j’ai commencĂ© Ă  travailler Ă  cause de mon nouvel emploi du temps.

- Racontez-nous comment s’est dĂ©roulĂ© l’entraĂ®nement.

J : Il y a eu diffĂ©rentes activitĂ©s et elles Ă©taient toutes sympas ! Le jeu des pinces Ă  linge : essayer de prendre celles attachĂ©es sur son adversaire, les sacs de boxes et d’autres exercices.

G : L’entraĂ®nement Ă  Ă©tĂ© très bien menĂ© et prĂ©parĂ©. Brahim savait très bien oĂą il allait. Nous avons eu un entraĂ®nement propre Ă  la boxe avec de la corde Ă  sauter, c’Ă©tait assez physique. Par la suite comme l’a mentionnĂ© Jimmy, nous avons fait un jeu très ludique dont le but Ă©tait de dĂ©crocher les pinces Ă  linge d’un adversaire. A la fin, les plus courageux retournaient avec Brahim pour se vider de leurs dernières forces en tapant vite et fort le plus longtemps possible sous les encouragements des autres.

Entrainement avec Brahim Asloum

- De quelle manière Brahim vous a encadré ? Vous a-t-il prodigué des conseils ?

J : Il a d’abord expliquĂ© globalement Ă  tout le monde et ensuite il est passĂ© nous voir un par un pour nous conseiller sur les bons gestes et la technique Ă  adopter.

G : Il a rĂ©ussi Ă  avoir un moment avec chacun des participants avec des pattes d’ours. Pendant ces quelques minutes il nous prodiguait des conseils et donnait des directives pour les autres qui tapaient au sac de frappe.

Brahim Asloum enseigne l'art du sac de frappe

- Qu’est ce que vous retiendrez de cet entraînement avec Brahim ?

J : Un très bon moment partagĂ© Ă  plusieurs et surtout l’esprit d’Ă©quipe et la joie d’ĂŞtre prĂ©sent – sentiment partagĂ© par l’ensemble des participants.

G : Je retiens quelques grosses courbatures et je devrais peut ĂŞtre reprendre la boxe ! La petite piqĂ»re de rappel sur l’importance d’ĂŞtre incisif n’Ă©tait pas de trop ! Je vais retenir la bonne ambiance dans laquelle s’est dĂ©roulĂ© l’entraĂ®nement avec les Ippon. Le parfait Ă©quilibre entre apprentissage, amusement et dĂ©pense physique!

- Pour finir, quelles sont les qualités du boxeur que vous pourriez réutiliser dans vos métiers ?

G : ĂŠtre bien stable sur ses bases. En informatique, si la base n’est pas solide, la puissance qui en dĂ©coulera ne sera pas au rendez vous ! Aussi, s’appliquer dans ses mouvements comme on devrait s’appliquer lorsque l’on programme quelque chose, par exemple, est une qualitĂ© commune Ă  la boxe et Ă  mon mĂ©tier.

La team Ippon aux côtés de Brahim Asloum

Un grand merci à Jimmy et Grégoire pour leur retour sur cette soirée.

Retrouvez toutes les photos de l’entraĂ®nement : https://plus.google.com/photos/106753560954832510210/albums/6137520244284253025

Catégories: Blog Société

CraftSwap avec 8th Light : retour sur une expérience exceptionnelle

Zenika - mer, 04/15/2015 - 14:38

"Dimanche je vais faire un Craftsman Swap avec 8th Light Chicago"

"Un quoi ?" diriez-vous.

En effet, cela mĂ©rite une explication : le principe est simple. Deux "software craftsmen" (artisan du code pour les francophiles) font un "swap" un Ă©change d'employĂ©s, entre deux entreprises pendant une semaine. J'ai eu l'honneur de reprĂ©senter Zenika lors de cet Ă©change. Du coĂ´Ă© 8th Light c'est Brian Pratt dĂ©veloppeur polyglotte originaire d'Oklahoma, qu’on a eu le plaisir d’accueillir dans nos locaux parisiens. (Retrouvez son interview Ă  la fin de l'article).

Ceci est mon retour sur cette semaine exceptionnelle passée aux cotés des meilleurs. 8th Light 8th Light est une société américaine basée principalement à Chicago avec un siège à Libertyville et un autre à Los Angeles. Elle a été fondée par Paul Pagel et Micah Martin qui sont également à l'origine du Manifesto Craftmanship. Les développeurs... Read CraftSwap avec 8th Light : retour sur une expérience exceptionnelle

Catégories: Blog Société

Jeudi 23 avril 2015 - Soirée MongoDB !

JUG Toulouse, Groupe d'utilisateur Java - mer, 04/15/2015 - 14:30

JHipster

Attention adresse différente: Epitech Toulouse 14 rue Claire Pauilhac (Inscrivez vous).

Le mouvement NoSQL offre des bases de données simplifiées et distribuables pour gérer plus facilement vos données semi-structurées et pour monter en charge horizontalement sur plusieurs machines. MongoDB est un moteur NoSQL solide et open source qui stocke les données en format JSON.

Il permet de gérer aisément de grands volumes de données et est devenu très populaire dans les communautés. Il est utilisé en production sur de nombreux sites tels que Foursquare, Bit.ly, SourceForge ou GitHub.

Tugdual Grall, Evangelist chez MongoDB, nous fera découvrir MongoDB et les applications possibles avec ce type de base de données. Voici le plan :

Première Partie : Presentation Générale de MongoDB

• Architecture

• Langage de requête et d’agrégation

• Haute disponibilité et montée en charge

• Management

• MongoDB 3.0 : quoi de neuf?

Deuxième Partie : Développez votre première application

• Les Drivers : Java, ... et autres

• Les frameworks et outils de mappings

• Bonnes et mauvaises pratiques

• Modélisation des données

Bio : Tugdual “Tug” Grall est technical Evangelist chez MongoDB, et un développeur passionné! Il travaille actuellement avec les communautés de développeurs en Europe pour faciliter l’adoption du NosQL/MongoDB. Avant de rejoindre MongoDB, Tug a travaillé chez Couchbase (Technical Evangelist) , eXo Platform (CTO) et Oracle (Product Manager/Developer OracleAS JavaEE).

Vous pouvez le suivre sur twitter @tgrall

Cette soirée est organisée en partenariat avec le Toulouse Data Science http://www.meetup.com/fr/Tlse-Data-Science/

L’entrée est libre à toutes les personnes

Attention les places sont limitées (50 pour le TDS, 50 pour le JUG), RSVP obligatoire.

Le programme de la soirée :

18:30 - Mot de bienvenue et présentation du TDS et Toulouse JUG

19:00 - Présentation par Tugdual

20:00 - Apéro Pizza + Boisson/Bière

Catégories: Association

Retour sur la conférence "Le management par la confiance" par J.F. Zobrist

Zenika - mer, 04/15/2015 - 14:02

Jeudi 2 avril avait lieu une confĂ©rence Ă  l'AIA de L'ENSAM Ă  Paris sur le management par la confiance. "Le management par la confiance : a-t-on le choix ?" Cette confĂ©rence Ă©tait donnĂ©e par J.F. Zobrist .

J.F Zobrist, est l'ancien patron de FAVI entre 1983 et 2009, dans laquelle il a mis en place ce type de management alternatif avec des résultats remarquables.

Le Management par la confiance Cette petite entreprise de fonderie est passée de 70 à près de 500 personnes. Elle a été pionnière dans la mise en place de démarches qualité en France et en Europe. Elle s'est complètement renouvelée en terme de produits et de clients. Est devenue leader dans le domaine des fourchettes de boîte de vitesse en... Read Retour sur la conférence "Le management par la confiance" par J.F. Zobrist

Catégories: Blog Société

Conférence APC – Paris 2015

Architecture Forum France (Open Group) - mer, 04/15/2015 - 12:04

Paris, France
17 juin

Cet article ConfĂ©rence APC – Paris 2015 est apparu en premier sur The Open Group France.

Catégories: Association

Devoxx France 2015 : OptaPlanner ou comment optimiser les itinéraires, les plannings et bien plus encore

  Vous souvenez-vous, durant vos folles annĂ©es d’Ă©tudiant, avoir Ă©tĂ© confrontĂ©s, lors d’un cours d’algorithme, au problème du voyageur de commerce ? (Rappelez-vous, Il s’agit pour un voyageur de commerce, de trouver le plus court chemin passant par un ensemble de villes...
Catégories: Blog Société

ScrumDay 2015 – Retour sur la conférence : Immunothérapie pour le changement

logo-scrumday-2015-01.pngLa confĂ©rence ImmunothĂ©rapie pour le changement Ă©tait tenue par Tremeur Balbous, il s’agissait en fait d’une prĂ©sentation d’un outil de dĂ©veloppement personnel dĂ©veloppĂ© par Robert Kegan et Lisa Lahey, professeurs Ă  Harvard. Cet outil Immunity to Change™ fait aussi l’oeuvre d’un livre publiĂ© en 2009 et intitulĂ© Immunity to Change: How to Overcome It and Unlock the Potential in Yourself and Your Organization. Tremeur Balbous nous prĂ©sentait ici son expĂ©rience de l’outil Ă  travers son propre exemple (bravo au passage pour ce partage!). Il organise par ailleurs des formations d’une journĂ©e sur ce sujet.

Pour ĂŞtre honnĂŞte, je suis un peu perplexe sur l’intĂ©rĂŞt d’une formation d’une journĂ©e et si j’ai aimĂ© cette prĂ©sentation, je me suis demandĂ© si mĂŞme la durĂ©e de la session n’Ă©tait pas un peu trop longue pour un outil qui m’a semblĂ© finalement assez simple.

De quoi s’agit-il?

Ce que nous expliquent Robert Kegan et Lisa Lahey, c’est que face au changement (et plus particulièrement Ă  celui qui implique une Ă©volution de comportement) nous avons tendance Ă  rĂ©agir comme le ferait un système immunitaire en essayant de nous en protĂ©ger. Ce comportement peut avoir son sens, car il permet de nous protĂ©ger du trauma psychologique que peut engendrer un changement brutal et rapide. Dans bien des cas, nous avons aussi dĂ©veloppĂ© des façons d’agir qui servent Ă  nous prĂ©munir de situations dĂ©sagrĂ©ables (par exemple ĂŞtre un workaholic pour compenser un manque de confiance en soi). Pour autant, c’est aussi un frein important qui nous empĂŞche d’adopter de « bons » changements. Pour illustrer cela, on cite souvent ce rĂ©sultat d’Ă©tude qui dit que lorsque les docteurs expliquent Ă  un patient qu’il va mourir s’il ne change pas ses habitudes, seulement un patient sur sept sera capable d’effectuer ce changement avec succès.

Comment prendre conscience?

Pour nous aider Ă  mieux mettre en place cette dĂ©marche de changement Robert Kegan et Lisa Lahey postulent que nos rĂ©sistances sont le plus souvent inconscientes et qu’il faut donc les rendre conscientes. Pour rĂ©ussir cela, ils nous proposent de mapper ces rĂ©sistances sur une carte proposĂ©e en tĂ©lĂ©chargement et qu’ils appellent une Immunity Map. Cette carte nous permet de faire un travail d’introspection Ă  travers le remplissage de quatre zones qui suivent une progression dans l’analyse. Ces quatre zones sont:

  1. DĂ©finir son objectif d’amĂ©lioration (le but)
  2. Lister les comportements en opposition (ce qu’on fait et qui nous empĂŞche de l’atteindre)
  3. Révéler nos engagements contradictoires (pourquoi on le fait, éléments en concurrence)
  4. Identifier les suppositions sous-jacentes (grandes hypothèses sur lesquelles on a battit nos comportements)
1Ă©re Ă©tape –  DĂ©finir son objectif

Dans cette colonne, il s’agit de dĂ©finir l’objectif Ă  atteindre et pour lequel nous voudrions nous engager. Une fois l’objectif dĂ©fini, il s’agit de lister les actions que l’on pourrait entreprendre pour l’atteindre.

Par exemple: Je voudrais passer plus de temps avec mes enfants, pour cela je pourrais ne plus travailler Ă  la maison les soirs et week-end.

2ème Ă©tape – Lister les comportements en opposition

Dans cette Ă©tape, on liste ce qu’on fait ou ne fait pas et qui nous empĂŞche d’atteindre notre objectif. Une fois ces Ă©lĂ©ments identifiĂ©s, il serait tentant de vouloir simplement remĂ©dier au problème en changeant ces comportements. Ce serait pourtant une erreur, car Ă  ce stade nous n’en avons pas encore analysĂ© les raisons d’ĂŞtres. Tremeur Balbous nous rappelle d’ailleurs la diffĂ©rence entre dĂ©cider et agir en nous posant la question suivante:

Six grenouilles sont sur une feuille de nĂ©nuphar. L’une d’entre elles dĂ©cide de sauter. Combien de grenouilles reste-t-il sur la feuille?

RĂ©ponse: Six, car dĂ©cider n’est pas agir.

Par exemple: Je suis perfectionniste et passe beaucoup de temps sur mon travail. J’accepte toutes les missions et je suis surchargĂ©. Je dĂ©lègue peu.

3ème Ă©tape – RĂ©vĂ©ler nos engagements contradictoires

C’est lĂ  que l’introspection commence, avec la colonne suivante, il s’agit des Ă©tapes les plus compliquĂ©es Ă  dĂ©finir et sur lesquelles il s’agit de passer le plus de temps. Ici on cherche Ă  rĂ©vĂ©ler les engagements, pas toujours conscients que nous avons pris et qui peuvent nous empĂŞcher d’attendre notre objectif. Une bonne façon de les rĂ©vĂ©ler est de se demander quelle serait notre plus grande crainte si nous devions adopter l’opposĂ© de nos comportements en opposition listĂ©s en colonne 2.

Par exemple: En passant moins de temps sur mon travail, je pourrais fournir un travail de moindre qualitĂ©. En refusant des missions, je montre que je suis dĂ©bordĂ©. En dĂ©lĂ©guant je prends le risque qu’une erreur soit faite.

4ème Ă©tape – Identifier les suppositions sous-jacentes

C’est l’Ă©tape la plus difficile, il s’agit d’examiner chacun de nos engagements contradictoires pour comprendre la raison sous-jacente qui nous pousse Ă  les tenir. On peut alors rĂ©ellement se poser la question de la validitĂ© de celles-ci et commencer Ă  changer. Ainsi en quoi est-ce que le fait que nos craintes se rĂ©alisent peut-il ĂŞtre un problème?

Par exemple: Si je fournis un travail de moindre qualitĂ© alors je ne serai plus reconnu pour mon intelligence. Si je suis dĂ©bordĂ© alors les autres penseront que je ne sais pas m’organiser. Si une erreur est faite alors j’en suis responsable et je peux ĂŞtre licenciĂ©.

Et après, comment agir?

Une fois ce travail rĂ©alisĂ©, on peut commencer Ă  tester nos comportements en opposition Ă  notre objectif afin de vĂ©rifier si ce qui les hypothèses qui en sont sous-jacentes sont valables (ou toujours valables). Pour ce faire, il vaut mieux commencer par celui de nos comportements que nous pouvons identifier comme Ă©tant le plus en opposition Ă  notre objectif. On tentera alors d’expĂ©rimenter une nouvelle approche qui soit SMART c’est Ă  dire:

  • Safe (Il y a toujours une part de risque Ă  tester de nouvelles façons de faire, mais la prise de risque doit ĂŞtre mesurĂ©e)
  • Modest (Il vaut mieux commencer petit afin d’obtenir des premiers succès et Ă©largir l’expĂ©rience au fur et Ă  mesure)
  • Actionable (Il faut que l’expĂ©rimentation soit rĂ©alisable, pas quelque chose que nous ne pouvons qu’imaginer)
  • Research-based (On cherche Ă  obtenir de l’information, pas Ă  prouver quelque chose ou Ă  changer immĂ©diatement un comportement)
  • Test efficient (Il s’agit de faire un test qui nous permette rĂ©ellement d’avoir une meilleure vision de la vĂ©racitĂ© de nos croyances et de leur utilitĂ© ou non)
En conclusion

Ainsi, Ă  l’aide de cette approche, on peut petit Ă  petit faire Ă©voluer nos comportements et tenter de changer en meilleure connaissance de cause. L’outil est simple, mais pour autant sa mise en oeuvre ne l’est pas. Les colonnes 2, 3 et 4 de l’Immunity Map on tendance Ă  se mĂ©langer et il n’est pas aisĂ© de faire une analyse pertinente. C’est clairement une approche pour laquelle un coaching individuel peut ĂŞtre nĂ©cessaire (c’est d’ailleurs ainsi que cela a commencĂ© pour Tremeur Balbous).

Une petite mise en garde d’ailleurs avant que vous ne vous essayez Ă  cette exercice: l’introspection n’est pas toujours agrĂ©able, car elle nous confronte Ă  certaines vĂ©ritĂ©s que nous prĂ©fĂ©rerions peut-ĂŞtre ignorer. Au final changer c’est aussi faire preuve d’une bonne dose de courage!

 

Ci-dessous, le scribing réalisé en live lors de la conférence.

Immunothérapie_150dpi.jpg

 

Catégories: Blog Société

Comment rater vos revues de code ? – Épisode 1

Dans le précédent article, nous avons présenté la pratique de la revue de code ainsi que deux formats que nous utilisons sur nos projets.

Mais introduire une nouvelle pratique avec succès n’est pas une chose aisée. C’est un peu comme mettre une barque à la mer : une fois dans l’eau, les premiers mètres sont assez chaotiques. Il y a beaucoup de vagues, on commence à se demander si c’était une bonne idée. Ne serait-il pas plus sage de retourner au rivage ? Mais en persévérant, on arrive finalement au large, où la mer est plus calme : il suffisait de s’accrocher.

Nous avons rencontré dans nos expériences de revue de code plusieurs écueils qui nuisent aux bénéfices attendus et qui peuvent mettre en péril la pratique dans l’équipe.

Voyons au travers de quelques anecdotes vécues* pourquoi vos premières revues de code risquent d’être difficiles et quels sont les fondamentaux nécessaires à des revues de code réussies.

Cet article fait partie de la série :

* Toute ressemblance avec des personnes existantes ou ayant existé n’est peut être pas fortuite. Si vous vous y reconnaissez, nous pouvons peut être vous aider.

Mon Ă©quipe ne progresse pas

Au sein d’une équipe que je venais de rejoindre, j’entends un jour Bob râler devant son poste :

“Mais il n’est pas possible Martin, combien de fois a-t-on dit qu’on ne construisait plus les requêtes SQL avec des Strings mais avec des Criteria Hibernate !”

Je suis allé voir Bob pour comprendre ce qu’il se passait. Il m’explique alors qu’il a revu du code écrit par Martin et qu’il a encore dû corriger une requête SQL qui ne répondait pas aux standards.

Moi : “Mais, ils sont écrits quelque part vos standards ?”

Bob : “Non… mais on les connaît, Martin est le seul à ne pas les respecter. Bon en même temps il est arrivé récemment.”

Moi : “Effectivement… Mais j’ai une autre question : tu as dit que tu as dû corriger le code toi même ?”

Bob : “Oui, on fait comme ça, je préfère corriger moi même pour être sûr. Et je ne vais pas aller l’interrompre pour ça.”

Moi : “Et si on allait lui en parler ?”

La revue n’occasionne pas d’échange

Dans cette conversation, pourquoi Martin n’a-t-il pas intégré le standard ?

Relire le code de quelqu’un, c’est l’occasion de lui donner un feedback sur son code, et de l’aider à améliorer ses pratiques. Sans échange avec l’auteur du code, le relecteur a beau détecter les défauts, ceux-ci réapparaîtront inlassablement dans le code futur car l’auteur n’a pas obtenu de retour dessus.

La revue de code doit ĂŞtre prĂ©parĂ©e par le relecteur, au moyen d’une première relecture pour relever des dĂ©fauts ou des questions Ă  poser. Ceci permet d’en effectuer une partie en asynchrone, mais le risque est qu’elle se termine sans occasionner cet indispensable Ă©change, idĂ©alement verbal.

L’auteur ne corrige pas les défauts

L’exemple précédent montre aussi un manque de confiance de la part du relecteur envers l’auteur du code. C’est dommage car le meilleur moyen de progresser, d’apprendre et intégrer un standard est de l’appliquer soi même.

Si la revue de code est l’occasion de transmettre du savoir, c’est aussi le cas de l’étape de correction des défauts :

  • il est donc important que ce soit l’auteur qui corrige les dĂ©fauts relevĂ©s.
  • plutĂ´t que le relecteur corrige les dĂ©fauts par manque de confiance, on peut dĂ©marrer une sĂ©ance de Pair Programming et construire la correction Ă  deux.

Il s’agit aussi de responsabiliser l’auteur du code : corriger les dĂ©fauts d’un autre dĂ©veloppeur peut l’infantiliser, alors que l’aider Ă  les corriger lui mĂŞme le responsabilise.

Des standards non partagés

L’utilisation de standards de code est une autre pratique essentielle pour parvenir à des revues efficaces. Ces standards sont construits collectivement par l’équipe, et écrits par exemple dans un wiki.

S’ils ne sont pas écrits, on va forcément les oublier ou les réinterpréter, et donc ne pas les assimiler. Ces standards, on les initie dès le début d’un projet, et on les fait évoluer dès que nécessaire, par exemple lors d’une “heure tech” récurrente.

Mes revues se transforment en débats sans fin et autres “trolls”

Pendant la première revue de code collective organisée au sein de l’équipe :

Kent : dis voir Becky, à la ligne 984, ton accolade n’est pas à la ligne, et en plus ta variable $moneyList ne respecte pas la casse standard : ici on utilise du snake_case !

Becky : alors, d’une part il n’y a pas de “casse standard”, je ne suis pas d’accord. Et de toute façon c’est has been ! Si on suivait la norme, on serait en PSR 42 et il n’y aurait pas de question à se poser !

Kent : Mouais il y a des choses bien dedans, mais je ne suis pas d’accord avec leurs règles de nommage !

La discussion dure encore un bon moment, arrĂŞtons-nous ici.

Qu’elles soient au format collectif ou en binôme, les premières revues de code organisées au sein d’une équipe sont souvent “polluées” des débats interminables, généralement sur des points censés être simples.

Afin de couper court à ces débats, il est indispensable d’établir au plus tôt des standards écrits, comme on l’a vu auparavant. Et ceci surtout pour des choses pouvant paraître anodines comme le nommage (quelle norme PSR utilise-t-on en PHP ?) ou des particularités controversées du langage (faut-il utiliser var en C# ?).

Il est peu probable que toute l’équipe soit parfaitement alignée sur ces points. Chez OCTO non plus nous ne sommes pas d’accord sur tout. L’essentiel est de trouver un compromis, et de l’écrire dans les standards.

Malgré cela, on rencontre aussi des aspects non traités par les standards, ou des points plus compliqués qui nécessitent une discussion avant de décider d’une correction.

C’est pour cela que, pour conserver une revue efficace :

  • Quel que soit le format, toute discussion ne concernant pas la dĂ©tection d’un dĂ©faut est reportĂ©e après la revue.
  • En revue collective, on ne passe pas plus d’une minute de discussion par dĂ©faut trouvĂ©. Un modĂ©rateur et un gardien du temps y veillent.

Si un point fait dĂ©bat, on le note dans une liste « Ă  dĂ©cider, non standard » : le tout est que le dĂ©bat n’ait pas lieu au cours de la revue.

Alors, comment réussir vos revues ?

Au travers de ces deux retours d’expĂ©riences, nous vous avons dĂ©jĂ  donnĂ© quelques pistes, mais s’il n’y en avait qu’une Ă  retenir la voici : soyez vigilants en organisant vos premières sessions de revue.

Si elles se passent mal dès le début et que vous ne résolvez pas rapidement les problèmes, vous vous tirez une balle dans le pied. La pratique risque alors d’être abandonnée ou déformée.

Voici les points clés que nous vous proposons :

  • Si votre Ă©quipe est novice avec la revue de code, commencez par vous former et privilĂ©giez des sessions collectives, au moins dans un premier temps.
  • Formalisez votre processus de revue de code et veillez Ă  bien le respecter : comment doit-elle se dĂ©rouler ? quand ? avec quels supports ?
  • Faites Ă©voluer votre pratique de la revue au cours de vos rĂ©trospectives.
  • Appuyez-vous sur des standards que vous faites Ă©voluer et constituez des checklists.

La semaine prochaine, nous vous proposerons un nouvel épisode riche en rebondissements : Malgré la mise en place des revues, on croule toujours sous les bugs.

En attendant, n’hésitez pas à partager vos retours d’expérience via les commentaires, qu’ils se soient bien ou mal passés !

Merci aux OCTOs de la tribu Software Craftsmanship pour leurs précieuses contributions.

Articles suggested :

  1. Comment rater vos revues de code ? – Épisode 2
  2. Comment rater vos revues de code ? – Épisode 3
  3. Ecrire du code propre – Le nommage

Catégories: Blog Société

Codez, progressez et partagez : relevez le défi de CodinGame !

Zenika - mar, 04/14/2015 - 15:19

En tant que partenaire de la plateforme CodinGame, Zenika vous propose de relever son nouveau défi “There is no spoon” qui commence le 25 avril prochain à partir de 18h.

CodinGame

Les inscriptions à ce challenge de programmation en ligne sont ouvertes ! Principe : 3 heures de challenge 2 défis de programmation à résoudre 20+ langages de programmation Le code de tout le monde passe en open-source après le contest De nombreux lots ! $1,000 pour la 1ère place, $400 pour la 2ème, $100 pour la 3ème et plein de tee-shirts Des... Read Codez, progressez et partagez : relevez le défi de CodinGame !

Catégories: Blog Société

Vidéo de l’Ippevent Rust

Blog d’Ippon Technologies - mar, 04/14/2015 - 13:14

Présentation de Rust, le langage le plus excitant depuis l’arrivée de Scala

Rust est un nouveau langage qui a tout pour intéresser les développeurs de tout bord :

  • multi-paradigme : il supporte les modèles impĂ©ratif, fonctionnel, et parallèle.
  • industriel : dĂ©veloppĂ© par la fondation Mozilla, l’objectif est d’offrir une alternative viable Ă  C++ pour le dĂ©veloppement du navigateur.
  • innovant : le modèle inĂ©dit de gestion mĂ©moire amène au mĂŞme niveau de sĂ©curitĂ© que les environnements Ă  GC, sans overhead par rapport au C.
  • natif : Rust se compile nativement, Ă©ventuellement sans runtime.

 

Catégories: Blog Société

Le monitoring de flux par l’exemple

Après avoir décrit le monitoring de flux et les bonnes pratiques pour le mettre en place, passons à un cas pratique. Nous allons détailler un exemple complet et documenté de monitoring d’un mini-système d’information combinant appels de services et envois de messages, avec des modèles de code.

Les composants applicatifs présentés dans cet article ont des noms génériques (frontend, middleend et backend) afin que chacun puisse facilement les adapter à son propre contexte. Nous aurions pu, par exemple, imaginer le frontend comme une application mobile ou une application web monopage javascript, le middle-end comme une couche de services REST (API), et enfin le backend comme un système de persistance ou encore d’analyse des transactions.

Ă€ propos du code

Le code proposé dans cet article a été écrit dans un but illustratif. Il est donc le plus simple possible et ne comprend par exemple ni gestion des erreurs ni optimisation. À vous de vous en inspirer et de l’adapter (il est sous licence open source Apache) mais surtout ne le réutilisez pas tel quel.

Les étapes permettant de tester le code vous-même sont décrites dans la documentation du projet.

Pour que l’article ne soit pas trop long, nous avons utilisé des liens plutôt que du code source inclus dans le texte.

Si des portions du code vous semblent peu claires ou que vous avez des suggestions, merci de créer un ticket ; si vous avez des idées d’améliorations les pull requests sont les bienvenues.

Le système

Le premier article expliquait que les services métier ont deux caractéristiques:

  • ils peuvent combiner plusieurs appels de services et/ou d’envois de messages
  • ils peuvent combiner des technologies hĂ©tĂ©rogènes.

Un système d’information qui combine ces deux aspects nécessite d’avoir des outils de monitoring flexibles et qui reposent sur des technologies interopérables.

L’architecture applicative présentée ici prend en compte ces éléments:

Architecture

Côté métier :

  • Un serveur frontend qui expose un service et un site web avec un formulaire qui l’utilise.
  • Un serveur middle-end expose deux services pour le frontend.
  • Un serveur backend traite de manière asynchrone des messages publiĂ©s par le middle-end sur un bus.

Côté monitoring :

  • un module de monitoring dans chaque brique applicative;
  • un bus dĂ©diĂ© recevant des messages de chacun de ces modules;
  • un serveur de CEP traitant ces messages pour lever des alertes et produire des KPIs;
  • une base de donnĂ©e indexant les messages et les informations gĂ©nĂ©rĂ©es par le CEP;
  • un outil de dashboarding pour prĂ©senter les informations de monitoring.
Format des messages de monitoring

Il est important de bien définir le format des messages de monitoring, même si le système de traitement doit être conçu pour pouvoir s’adapter facilement à différents cas. L’utilisation d’un gabarit commun permet de simplifier l’exploitation des messages dans le CEP et les dashboard.

Dans notre cas, nous avons choisi d’utiliser des messages au format JSON:

{
    "correlation_id": "octo.local_MonitoringBase_24389_2015-01-30 11:05:29 UTC_36cddd01-7bcd-4ced-8024-919ff1dbe6ca",  // l'id de correlation
    "timestamp": "2015-01-30T12:05:29.230+01:00", // horodatage du message

    "module_type": "FrontendApp", // nom du module qui envoie le message
    "module_id": "FrontendApp_octo.local_001", // identifiant du module qui envoie le message
    "endpoint": "GET /messages", // nom du service
    "message_type": "Send message to backend", // type de message

    "begin_timestamp": "2015-02-19T22:11:15.939+01:00", // optionnel: horodatage du début de l'action en cours
    "end_timestamp": "2015-02-19T22:11:15.959+01:00", // optionnel: horodatage de la fin de l'action en cours
    "elapsed_time": 0.020169, // optionnel: temps mis pour l'action en cours

    "service_params": {
        // optionnel: paramètres d'appel du service
    },

    "headers": {
        // optionnel: en-tĂŞtes d'appel du service (en-tĂŞtes http par exemple)
    }

    "result": {
        // optionnel: résultat de l'appel du service
    }
}
DĂ©tail de chaque composant

Technologies

Ă€ propos du monitoring

Pour fournir les données nécessaires, chaque brique embarque du code permettant de récupérer les informations utiles et de les poster dans un bus. Pour pénaliser au minimum les performances du code applicatif, l’envoi des messages s’effectue systématiquement dans un thread dédié, et une gestion d’exception isole le code de monitoring du code métier.

Conformément aux recommandations du premier article, c’est un bus ZeroMQ qui a été choisi pour ses très bonnes performances.

Frontend

Le serveur frontend est en Ruby et utilise le framework web Sinatra qui est parfait pour comme ici exposer facilement des services web.

Frontend

  • app_base paramètre le socle de l’application, et fournit une mĂ©thode pour appeler des services du serveur middle-end.
  • le rĂ©pertoire static contient le site web
  • frontend_app expose le service mĂ©tier qu’appelle le site web et appelle deux services du middle-end l’un après l’autre.
Monitoring

Le code de monitoring est situé dans la classe monitoring_base.rb

Le framework Sinatra fournit les points d’entrées nécessaires pour le monitoring sous forme de méthodes before et after où toutes les informations de la requête en cours sont accessibles. Pour pouvoir stocker des informations pendant l’exécution de la requête, comme l’heure du début de son exécution, un champ est ajouté à la classe Request.

La méthode permettant d’appeler des services est surchargée pour faire deux choses :

  • envoyer des copies de l’appel au système de monitoring;
  • ajouter des en-tĂŞtes http dans l’appel de service pour propager l’identifiant de corrĂ©lation ainsi que l’heure de l’appel

Les données sont postées dans une queue et consommées dans un thread séparé.

Middle-end

Le serveur middle-end utilisé Spring, Spring Boot permet de configurer facilement une application et Spring MVC d’exposer des services REST.

  • MiddleEndController contient le controller qui expose les deux services exposĂ©s.
  • RedisProvider fournit l’accès au bus pour envoyer des messages au backend.
Monitoring

Du fait du choix de la technologie Spring, la mise en place de monitoring demande quelques acrobaties :

  • Un HandlerInterceptor fournit un point d’entrĂ©e au dĂ©but et Ă  la fin de l’exĂ©cution de chaque requĂŞte http qui permet de crĂ©er les messages qui seront envoyĂ©s au monitoring.
  • Il est nĂ©cessaire de sous-classer le HttpServletRequest pour pouvoir stocker des informations pendant l’exĂ©cution de la requĂŞte, comme l’heure du dĂ©but de son exĂ©cution.
  • Finalement HttpServletRequest qui reprĂ©sente la requĂŞte et HttpServletResponse la rĂ©ponse ne donnent pas d’accès au contenu de la requĂŞte ou de la rĂ©ponse car leur envoi est streamĂ©. Il est donc nĂ©cessaire de wrapper les deux classes pour enregistrer les contenus pendant la tranmission, et pouvoir ainsi les relire ensuite.

Le résultat se trouve réparti dans 5 classes :

Le code en charge de l’envoi des messages est situé dans un projet partagé car il est utilisé par le middle-end et le backend. L’essentiel du code est situé dans le MonitoringMessageSender qui utilise un thread dédié à l’envoi des messages et alimenté par une queue.

RedisProvider a été modifié pour transmettre l’identifiant de correlation dans les messages envoyés au backend.

Le bus applicatif

Il s’agit d’un serveur Redis : il est principalement utilisé comme un cache clé-valeur mais son API lui permet également de servir de bus de messages.
Ses principaux avantages sont sa facilité de mise en œuvre et sa vitesse de traitement.

Le backend

Nous avons simulé une application de traitement de messages à l’aide d’un pool de threads :

  • ApplicationBase fournit le socle applicatif qui consomme les messages depuis Redis et les fait traiter par un pool de thread Java.
  • Backend traite les messages.
Monitoring

Comme le code de réception est spécifique à l’application, le monitoring est complètement intégré au socle applicatif. Pour l’envoi des messages, il s’appuie sur le même projet partagé que le middle-end.

Le Complex Event Processing Principes

Le composant de Complex Event Processing dépile les messages en provenance des différents modules (frondend, middle-end, backend). Il réalise alors en parallèle l’insertion dans la base de données et la mise à jour d’un état en mémoire. L’évolution de cet état peut générer des alertes qui seront à leur tour persistées dans la base.

Il est implémenté en Java à l’aide du framework d’intégration Apache Camel et se présente comme une application autonome.

  • Les messages sont dĂ©pilĂ©s depuis ZeroMQ Ă  l’aide d’un Connecteur qu’il nous a Ă©tĂ© nĂ©cessaire de rĂ©Ă©crire en utilisant la librairie jeroMQ.
    Le composant existant fonctionnait en effet avec des bindings scala non applicables.
  • L’état en mĂ©moire ainsi que le dĂ©clenchement d’alertes sont implĂ©mentĂ©s en utilisant le framework Esper.
    Camel fournit le connecteur qui permet de s’y interfacer.
    Les règles sont écrites avec le DSL interne nommé EPL (Event Processing Language) dans le fichier de configuration Camel.
  • Les messages et alertes sont persistĂ©s dans un cluster Elasticsearch Ă  l’aide d’un connecteur maison utilisant la bibliothèque Jest (il n’est donc pas conçu pour monter en charge). Le connecteur par dĂ©faut s’enregistre comme un nĹ“ud du cluster Elasticsearch et cela rendait les tests locaux plus compliquĂ©s.

CEP

Interprétation des évènements

Le flux d’évènements est interprété pour construire des indicateurs en temps réels grâce au language d’analyse Esper Process Language (EPL). Ces statuts sont requêtés à intervalles réguliers afin de détecter des comportements anormaux comme des dépassements de seuils.

Nous avons cherché ici à remonter trois types d’alerte :

  • Un temps de traitement trop important pour l’un des composants Ă  l’aide de l’attribut elapsed_time des messages.
  • Un temps de traitement trop important pour un flux sur l’ensemble de la chaĂ®ne, en utilisant l’identifiant de correlation.
  • Throttling : Un nombre d’appels supĂ©rieur Ă  un seuil fixĂ© dans une unitĂ© de temps fixe (ici une moyenne de plus de 3 appels sur 10 secondes).

Traitements CEP

La base de donnée du monitoring

Il s’agit d’une base Elasticsearch qui indexe automatiquement les données à leur insertion.
Pour que les données soient indexées au mieux, il suffit de créer un index à l’avance pour que les champs soient indexés de la bonne manière.

Le dashboard

Avec les données déjà structurées et stockées dans Elasticsearch, Kibana est la solution naturelle pour les dashboard : des assistants permettent de facilement créer les différents graphiques en fonctions des données présentes dans la base.

Voici par exemple un dashboard des percentiles des appels sur les différents serveurs (la configuration de ce dashboard est disponible dans les sources) :

Kibana

Les composants difficiles Ă  monitorer

Les cas prĂ©sentĂ©s ici sont favorables car les composants ne sont pas trop compliquĂ©s Ă  monitorer, mĂŞme si le middle-end demande un peu de gymnastique. Malheureusement dans tout SI d’une certaine taille, il existe toujours au moins une brique « boite noire », type portail ou plateforme e-commerce, qu’il est difficile d’outiller convenablement. Pour ces composants deux choix sont gĂ©nĂ©ralement possibles :

Utiliser les points d’extensions fournis par l’outil

Cette solution est la plus conforme. Cependant ces API sont souvent d’une qualité inférieure au reste et avant de vous lancer il y a trois choses à vérifier :

  • La documentation est-elle suffisamment dĂ©taillĂ©e, particulièrement quand des objets internes au composant sont exposĂ©s ?
  • Les API sont elles stables ? Comme ces API sont assez proches du moteur des outils, elles sont plus susceptibles de ne pas ĂŞtre compatibles d’une version Ă  l’autre.
  • Toutes les informations dont vous avez besoin sont-elles exposĂ©es ?

En fonction des réponses à ces trois questions, la deuxième solution sera peut-être préférable.

Utiliser un proxy

Si les échanges avec le composant se font par http, l’autre solution est de mettre en place un proxy comme nginx pour générer les messages de monitoring. En configurant les logs vous devriez pouvoir obtenir les informations dont vous avez besoin, et un composant custom est nécessaire pour les pousser vers le serveur de CEP.

Cette solution a le désavantage d’ajouter une couche supplémentaire d’infrastructure, mais évite d’avoir à développer du code trop spécifique à un outil.

Articles suggested :

  1. Guicy : un cocktail de Groovy et de Google Guice
  2. Intégration continue performante (Part #1)
  3. Spring Roo

Catégories: Blog Société

PerfUG : Programmation Lock-Free, les techniques des pros

La scalabilité des applications est une préoccupation importante. Beaucoup de pertes en scalabilité proviennent de code contenant des locks qui produisent une importante contention en cas de forte charge.

Dans cette prĂ©sentation nous allons aborder diffĂ©rentes techniques (striping, copy-on-write, ring buffer, spinning, …) qui vont nous permettre de rĂ©duire cette contention ou d’obtenir un code sans lock. Nous expliquerons aussi les concepts de Compare-And-Swap et de barrières mĂ©moires.

 

Jean-Philippe BEMPEL travaille depuis plus de 6 ans en tant qu’architecte performance sur des applications de trading requĂ©rant une très faible latence. De l’optimisation du code java jusqu’au rĂ©glage très fin du système d’exploitation et du matĂ©riel, toute la chaĂ®ne d’exĂ©cution de l’application est pris en compte pour grappiller des micro-secondes sur le traitement des ordres.

 

La session aura lieu le 23 avril dans les locaux d’OCTO Technology.
Inscriptions et informations sur Meetup. Cette session sera suivie d’un pot dans les locaux d’Octo.

Articles suggested :

  1. Compte-rendu du Performance User Group #3
  2. PerfUG : Hadoop et HDFS : Stockage, RequĂŞtage et Performances
  3. PerfUG : DynaTrace pour monitorer tous vos problèmes de performance

Catégories: Blog Société

Extreme Programming : Le commencement !

Ces dernières annĂ©es ont vu une incroyable transformation des mĂ©thodes de dĂ©veloppement, notamment avec l’adoption progressive de l’extrĂŞme Programming et plus gĂ©nĂ©ralement de l’agilitĂ©. Nous allons, au travers d’une sĂ©rie d’articles, vous donner les clĂ©s pour vous accompagner dans la mise en place de cette pratique, presque obligatoire aujourd’hui pour attirer les talents dans votre entreprise.

 Commençons par un simple rappel d’Extreme Programming

Extreme Programming (XP) est un ensemble de pratiques définies par Kent Beck, Ward Cunningham et Ron Jeffries en 1996 alors qu’ils intervenaient sur un projet de gestion de paie chez Chrysler. En 1999, Kent Beck publie Extreme Programming Explained, livre qui marque la naissance d’XP pour le grand public.

XP est une méthode qui repose sur des pratiques mais surtout sur des valeurs qui sont :

  • La communication. Il faut avoir Ă  l’esprit que les Ă©quipes XP/agiles sont des environnements effervescents : la communication y est continuelle, que ce soit entre la voix du mĂ©tier et les dĂ©veloppeurs ou bien les dĂ©veloppeurs eux-mĂŞmes. C’est particulièrement vrai durant les rituels ou le pair programming, moments riches d’échanges.
  • La simplicitĂ©. Les Ă©quipiers XP utilisent souvent des acronymes barbares pour vĂ©hiculer ces idĂ©es : KISS (Keep It Simple Stupid) et YAGNI (You Aren’t Gonna Need It) traduisent cet Ă©tat d’esprit. Les meilleures solutions sont gĂ©nĂ©ralement les plus simples. C’est aussi valable pour le code. Concevoir la solution la plus rapide qui rĂ©pond au besoin, garanti le juste investissement en temps et en maintenabilitĂ©.
  • Le feedback. Il intervient sur diffĂ©rentes Ă©chelles de temps :
    • quasi instantanĂ©ment pour le dĂ©veloppeur, par le biais de l’intĂ©gration continue et du harnais de tests automatisĂ©s,
    • lors des dĂ©monstrations de fin d’itĂ©rations, volontairement courtes, les Ă©quipiers reçoivent le feedback du client sur site,
    • grâce aux rĂ©trospectives, le feedback est rĂ©coltĂ© sur la manière de travailler de l’équipe.
  • Le courage. Parce qu’il est nĂ©cessaire pour constamment remettre en cause le travail fourni par l’équipe. Il faut accepter l’idĂ©e qu’un code qui semble bon aujourd’hui pourrait ĂŞtre profondĂ©ment remaniĂ© dans un futur proche, pour le bien du logiciel.
  • Le respect. Cette valeur n’était pas initialement mise en avant et n’est apparue qu’en 2004 dans la seconde Ă©dition du livre rĂ©fĂ©rence. XP, et les autres mĂ©thodes agiles, ont des sources d’inspiration « humanistes ». Tout le monde a le droit de ne pas savoir. Le dĂ©veloppement de toute nouvelle fonctionnalitĂ© peut ainsi ĂŞtre vu comme une opportunitĂ© pour une personne d’apprendre Ă  manipuler un nouveau framework, un design pattern pas totalement maĂ®trisĂ©, etc. C’est dans ces moments que le respect entre en Ĺ“uvre.

XP est un ensemble de pratiques qui a été naturellement source d’inspiration pour l’ensemble des méthodes agiles de développement les plus populaires du moment et qui donnent la part belle à la technique. Il permet de remplir un objectif principal fort : la base d’une bonne application informatique est de ne faire aucune concession sur la qualité du logiciel.

Dans les articles qui suivront, nous nous attacherons à vous présenter une démarche pour mettre en place un ensemble de pratiques XP bénéfiques pour la plupart des projets IT.

Catégories: Blog Société

LCC 122 - Devoxx France 2015 la philo sans les poufs

L’épisode en direct de Devoxx France dans une superbe salle de 400 personnes. On y discute vous, du monde d’il y a 20 ans, de l’équipe Devoxx, de Fred Simon et de philosophie. Un grand merci à JFrog pour les bières et la TV offerte aux code castés de Devoxx.

Enregistré le 10 avril 2015

Téléchargement de l’épisode LesCastCodeurs-Episode–122.mp3

Devoxx France: table ronde

Présentation à suivre sur Slideshare

Objectif

Faire du bruit: c’est un podcast audio
Apprécier sa bière: c’est une podcast en direct
Un format différent: c’est un podcast innovant

Qui ĂŞtes-vous ?

40 ans de carrière
30 ans de carrière
20 ans de carrière
15 ans de carrière
10 ans de carrière
5 ans de carrière
0 ans de carrière

Il y a 20 ans Les films

Star Wars I
Pulp Fiction
Matrix (je me suis trompé c’était 199 en fait)
Titanic

La technologie

Pentium Pro
Windows 95
Rue Mongallet

Et la connectivité ?

Bi-Bop

Mais pour vous c’était

Le minitel
Le modem US Robotics

Souvenez vous 1995

Perl 5.001 13/03/1995
Iomega Jaz drive
Visual Basic 4.0 08/1995
Ruby
Windows 95 24/08/1995: 1 million de copies en 4 jours
Internet Explorer 1.0 16/08/1995
Le premier Wiki est créé (WikiWikiWeb sur http://c2.com)
HTML 2.0 le 24/11/1995
Deep Blue 5/12/1995
Toy Story 22/11/1995

Charles -> Movies -> Devoxx

RxJava

Observable observable = ...
observable
    .flatmap( charles -> Observable.just( new Movie(),… ) )
    .filter( movie -> moviesFromCharles.contains(movie) )
    .timeout(2, MINUTES)
    .count()
    .filter( count -> count == 10 )
    .flatmap( Observable.just( new PlaceForDevoxx(2015) );
L’équipe Devoxx

Devoxx4Kids
Ecole 42

Tu prends ta bière ta TV et tu t’en vas

Merci Ă  JFrog
Artifactory
Bintray

SĂ©ance divan avec Fred Simon

Abstract enum
Jigsaw
Parleys

Phi {low|lol} zoo Phi

Quand les développeurs parlent de philosophie avec des philosophes.
Les trois Ă©critures chez Gallimard

Et vous Devoxx c’était quoi?

“On écoute toujours le mec qui a un mégaphone en haut des escaliers”
Stephan Tual

Nous contacter

Contactez-nous via twitter http://twitter.com/lescastcodeurs
sur le groupe Google http://groups.google.com/group/lescastcodeurs
ou sur le site web http://lescastcodeurs.com/
Flattr-ez nous (dons) sur http://lescastcodeurs.com/
En savoir plus sur le sponsoring? sponsors@lescastcodeurs.com

Catégories: Blog Individuel

Faites communiquer entre eux les outils en ligne que vous utilisez. Automagiquement !

ekito people - lun, 04/13/2015 - 15:29

Voici comment j’ai fait communiquer de manière automatique les différents outils en ligne que nous utilisons pour gérer la vente des tickets et la communication de la conférence FailCon.

J’ai mis ça en place en quelques minutes et sans coder, en utilisant Zapier. Une alternative  Ă  Zapier est IFTTT.

L’avantage principal : très facile et rapide à mettre en place.

J’organise pas de confĂ©rence, quel intĂ©rĂŞt pour moi ?

Il y a sûrement des cas que vous gérez manuellement (ou par manque de temps… pas du tout !) que vous pourriez automatiser dans votre société ou startup ?

  • Peut-ĂŞtre que chaque nouveau client peut automatiquement recevoir un mail de bienvenue ?
  • Ou peut-ĂŞtre qu’à chaque fois que vous livrez sa commande Ă  un client, vous voulez mettre Ă  jour un fichier dans votre Dropbox ?
  • Ou que vous voulez ĂŞtre notifiĂ© sur votre mobile de chaque nouvel abonnĂ© Ă  votre newsletter ?
  • Ou Ă  chaque fois qu’un client abandonne son panier sur votre plateforme de vente en ligne, vous voulez avoir l’opportunitĂ© de le recontacter et vous voulez vous en rappeler 3 jours plus tard ?
Voici ce que nous avons automatisé :

Voici la liste des actions automatiques que j’ai mises en place.

Zapier actions

Suppression d’une adresse email dans une mailing list :

Le premier me permet quand quelqu’un achète un billet pour la FailCon de le supprimer de la liste des gens intéressés par la FailCon.

Unsubscribe MailChimp

Ca évite de continuer à lui envoyer des mails pour l’inciter à prendre son billet alors qu’il l’a déjà fait !

Notification sur outil de chat interne :

Le deuxième poste un message sur Slack, notre outil de messagerie interne.

Post to Slack

Ca fait toujours du bien de savoir que quelqu’un trouve ce qu’on organise intéressant au point d’y acheter un billet et réserver sa journée.

On peut évidemment configurer le channel dans lequel le message sera posté, et le texte :

Config EventBrite to Slack

Cela donne ça :

Notification in slack

Et c’est très apprĂ©ciable de recevoir les notifications en temps rĂ©el :

Notification on mobile

Inscription Ă  une mailing liste dĂ©diĂ©e Ă  l’Ă©vĂ©nement :

Et enfin, on demande à Zapier d’ajouter automatiquement tout nouvel inscrit à la liste dans MailChimp des gens présents à la FailCon :

EventBrite to MailChimp

Cela permet que cette liste reste toujours à jour et que tous les inscrits reçoivent les infos qu’on communique sans risque d’oubli.

Voici nos idées ; les seules limites sont votre imagination. Maintenant à vous de jouer !

The post Faites communiquer entre eux les outils en ligne que vous utilisez. Automagiquement ! appeared first on ekito people.

Catégories: Blog Société

[ScrumDay 2015] Le plus petit pas, comment accélérer votre transformation en passant de 1000 à 1 personne

Le thème prĂ©pondĂ©rant de cette Ă©dition 2015 est Ă  n’en pas douter la mise Ă  l’Ă©chelle de l’agilitĂ©. Au-delĂ  des bonnes pratiques Ă  l’Ă©chelle d’une Ă©quipe de dĂ©veloppement, plus loin que la gestion de plusieurs Ă©quipes agiles, c’est vraiment une...
Catégories: Blog Société

NSConference 7

3 jours, 2 Développeurs, 1 Conférence : notre CR de la NSConference

Pendant 3 jours, nous (Mathieu « MHA » et Guillaume « GUL ») avons eu la chance d’assister Ă  la NSConference, la confĂ©rence de la communautĂ© de dĂ©veloppeurs iOS / MAC OS.

La confĂ©rence est construite autour de 2 formats: les sessions classiques d’une demie-heure, et des sessions courtes de 10 minutes, appelĂ©s « Blitz Talk ».
Petit tour d’horizon des sessions qui nous ont particulièrement marquĂ©s, que ce soit sur le contenu technique, le message ou simplement l’approche.

Code Somewhere between Tomorrowland and Frontierland

Daniel Steinberg (@dimsumthinking) a fait pour nous LA présentation de la conférence. En faisant un parallèle très habile entre un parcours à Disneyland et la programmation, il nous a montré comment traiter un problème simple de géométrie de 3 manières différentes:

  • la mĂ©thode naĂŻve orientĂ©e objet
  • la programmation fonctionnelle
  • la programmation orientĂ©e objet s’inspirant de la structure du code fonctionnel.

Nous avons enfin vu la force de Swift qui permet d’allier les 2 types de programmation.

La vidĂ©o de sa prĂ©sentation n’est pas encore disponible mais nous l’attendons avec impatience.

An architecture for content-driven interfaces

Cathy Shive (@catshive) dĂ©veloppe des applications iOS avec des Ă©crans prĂ©sentant des donnĂ©es de type très diffĂ©rents. Pour afficher un contenu complexe dans une collection View, il est intĂ©ressant d’Ă©tablir un modèle de rendu plutĂ´t qu’un modèle mĂ©tier. Par exemple dans l’Ă©cran suivant :

Content Driven Interfaces

 

Le serveur pourrait envoyer le json suivant :

[
    { "type" : "profile_picture", "src" : "http://..." },
    { "type" : "text_attribute", "title" : "Nom", "value" : "XXX" },
    { "type" : "text_attribute", "title" : "Prénom", "value" : "XXX" },
    { "type" : "text_attribute", "title" : "Age", "value" : "XXX" },
    { "type" : "image_gallery", "images" : ["http://..", "http://..." ] },
    { "type" : "text_attribute", "title" : "Profession", "value" : "XXX" }
]

plutĂ´t que celui-ci plus classique :

{
    "profile_picture" : "http://...",
    "gallery_pictures" : ["http://..", "http://..." ],
    "last_name" : "XXX",
    "first_name" : "XXX",
    "age" : "XXX",
    "profession" : "XXX"
}

Imaginez alors ce que pourrait afficher la mĂŞme application recevant ce json :

[
    { "type" : "image_gallery", "images" : ["http://..", "http://..." ] },
    { "type" : "text_attribute", "title" : "Prénom", "value" : "XXX" },
    { "type" : "text_attribute", "title" : "Nom", "value" : "XXX" },
    { "type" : "profile_picture", "src" : "http://..." },
    { "type" : "text_attribute", "title" : "Profession", "value" : "XXX" },
    { "type" : "text_attribute", "title" : "Age", "value" : "XXX" }
]

Les bĂ©nĂ©fices ? Une complexitĂ© portĂ©e par le serveur, un A/B testing facilitĂ© et actionnable simplement, un framework de vue qui se construit au fur et Ă  mesure des Ă©volutions des Ă©crans de nos applications. De plus les objets mĂ©tiers restent les mĂŞmes, du serveur, Ă  l’affichage, en passant par Core Data.

Replacing Photoshop with NSString

Charles Parnot (@cparnot) a créé une catégorie sur UIImage et NSImage qui permet de dessiner des ressources directement en ASCII Art, et dans tous les formats iOS (1x, 2x, 3x).

Exemple d'usage

return [self imageWithASCIIRepresentation:asciiRep
                                    color:[UIColor blackColor]
                          shouldAntialias:NO];

Le code source de la catégorie est disponible sur son Github: https://github.com/cparnot/ASCIImage

The modern password and you

Joel Parsons (@jackslash) nous prĂ©sente les bonnes pratiques pour gĂ©rer les mots de passe dans votre application iOS, en utilisant l’extension 1password ou le trousseau de iOS et ses nouvelles fonctionnalitĂ©s.

Avec le trousseau iOS, on peut maintenant entre autre :

  • PrĂ©remplir un formulaire de login avec les informations du trousseau mĂŞme saisies depuis le Mac.
  • Sauvegarder un nouveau mots de passe dans le trousseau et ainsi le retrouver sur les autres terminaux connectĂ©s iPhone, iPad ou Mac.
  • Demander au trousseau de gĂ©nĂ©rer un nouveau mot de passe. Cette fonctionnalitĂ© est bien Ă©videmment plus utile si on sauvegarde le mot de passe gĂ©nĂ©rĂ© dans le trousseau.

Nous n’avons donc plus d’excuses pour ne pas proposer sur nos applications une expĂ©rience aussi agrĂ©able que sous Safari sur le Mac. Nos utilisateurs en profiteront pour ne pas utiliser le mĂŞme mot de passe sur toutes leurs applications.

Plus d’infos dans la doc Apple mĂŞme si celle-ci est loin d’ĂŞtre simple.

Mais aussi :

SceneKit, le framework 3D d’Apple, peut s’avĂ©rer utile pour concevoir des effets et des vues. Matias Piipari (@mz2) nous montre comment avec cet exemple disponible sur GitHub: https://github.com/mpapp/MPSheetView. (SceneKit for fun and profit)

Mark Danks (@defragged) nous montre comment dĂ©compiler et pirater une application avec des outils disponibles simplement (Hopper Disassembler et HexFiend). En quelques slides, il nous montre comment se protĂ©ger efficacement contre ce type de piratage, notamment en interdisant l’attachement de dĂ©bugger ou la validation des certifcats Apple. Si vous voulez plus de dĂ©tails sur comment le mettre en oeuvre sur iOS, voici un article parlant sur le blog obj.io. (Cracking Apps Gromit!)

Martin Winter (@martinwinter) va au plus profond de l’unicode pour nous mettre en garde sur le stockage, la manipulation et le traitement des caractères « spĂ©ciaux ». Le clavier iOS permet de saisir des emoji, vos webservices et bases de donnĂ©es sont-ils prĂŞts Ă  les prendre en compte. (Practical Unicode)

Tim Mecking (@sptim) a relevĂ© les mauvaises pratiques les plus courantes des tutoriels et autres screencasts disponibles sur le net. Cela donne un très joli github. Son conseil le plus fort est qu’il faut ĂŞtre irrĂ©prochable dans les ressources que l’on met Ă  disposition sur le net. (Flaws in Tutorials, Screencasts, and Samplecode)

Taylan Pince (@taylanpince), nous présente une libriairie permettant de commander des arduino (et un robot) avec un iPhone ou un MAC via le BLE. Une libriaire a retrouver sur github: https://github.com/Hipo. (Cocoa & Robots)

Enfin Pieter Omvlee (@pieteromvlee) a créé un framework de génération https://github.com/BohemianCoding/coma. (Moving Goalposts: Adapting Existing Code For Future Needs)

Outils Fully automate the release process of iOS apps

Felix Krause (@krausefx) a pris Ă  bras le corps une des tâches les plus pĂ©nibles du monde iOS: en dĂ©veloppant Fastlane, il offre une solution simple pour automatiser le dĂ©ploiement des applications, des tests unitaires Ă  la soumission sur l’Appstore.
Fastlane se dĂ©compose en huit modules indĂ©pendants, s’intĂ©grant dans une UDD (Jenkins notamment):

  • Deliver : envoi des metadata, des screenshots et de l’application sur l’appstore.
  • Snapshot : prend des screenshots localisĂ©s
  • Frameit : place les screenshots dans un cadre (iPad / iPhone)
  • PEM : gĂ©nère et renouvelle les certificats de Push
  • Sigh : gère les provisioning profiles (oui !)
  • Produce : crĂ©e une nouvelle application sur l’AppStore
  • Cert : gère les certificats
  • Codes : gère les codes promo

Tout est disponible sur http://fastlane.tools.

Practical code injection

Miguel Angel Quinones (@miguelquinon) nous montre les bienfaits de l’injection de code au runtime pour rendre le dĂ©veloppement plus fluide. Par exemple, faire du pixel perfect en supperposant la crĂ©a de rĂ©fĂ©rence et le simulateur (en utilisant uberlayer), optimiser les localizable.strings et faire des changements de logique.

Tout est disponible sur son GitHub: https://github.com/dyci/dyci-main.

Attention aux cycles de vie des objets: par exemple, les singleton ou les viewcontrollers déjà chargés en mémoire ne seront pas rechargés.

Produit Out-Heart the Competition

Daniel Jalkut (@danielpunkass) nous explique que le dĂ©veloppement d’applications mobiles n’est pas dans un marchĂ© Ă  somme nulle et nous avons donc tout intĂ©rĂŞt Ă  ĂŞtre bienveillant avec nos concurrents pour faire grossir le marchĂ© global. Pour sa part, il n’hĂ©site pas Ă  renvoyer vers ses concurrents si il ne propose pas une fonctionnalitĂ© demandĂ©e par ses utilisateurs, ni Ă  saluer l’arrivĂ©e de nouveaux acteurs, les promotions et succès de ses concurrents.

Mais aussi :

Le Lean Startup buzz plus que l’Apple Watch Ă  la NSConference. Pas moins de 4 sessions (quatre !) en parlent :

  • Feedback Driven Development par Paul Kafasis (@pbones)
  • Validate your product before you build it par Paul Muston (@pmuston)
  • Mobile is a Systems Problem par Cate Huston (@catehstn)
  • Building habits: keeping your users engaged par Sally Shepard (@mostgood)
Conclusion

Cette NSConference sera la dernière, Steve « Scotty » Scott (@macdevnet) n’a plus l’envie de porter cet Ă©vènement et considère que l’offre de confĂ©rence en Europe sur les technologies Apple est dĂ©sormais satisfaisante.

Après trois jours de partages et de rencontres autour de notre passion commune nous rentrons avec beaucoup de choses Ă  tester avant de vivre de prochaines aventures … en Swift peut ĂŞtre ?

Catégories: Blog Société

ScrumDay 2015 – Retour sur l’atelier « Reinventing Organizations For Entreprise Agility »

logo-scrumday-2015-01.pngCe billet est un retour sur l’atelier Reinventing Organisation for Entreprise Agility, animĂ© par Michael Sahota et Olaf Lewitz lors du ScrumDay 2015 qui a eu lieu les 2 et 3 avril derniers au centre des congrès de Disneyland.

Cet atelier me laisse un sentiment mitigĂ©. MitigĂ©, car ce qui Ă©tait prĂ©sentĂ© comme un atelier n’en Ă©tait pas rĂ©ellement un. Il s’agissait en fait d’une confĂ©rence de 2 heures, la partie atelier se limitant Ă  questionner l’audience sur la façon dont ils se noteraient sur des critères d’entreprise libĂ©rĂ©e. MitigĂ© donc, car cette confĂ©rence prĂ©sentait l’excellent livre de FrĂ©dĂ©ric Laloux  « Reinventing Organizations« , mais n’apportait rien de plus que ce que l’on peut dĂ©couvrir en lisant le livre. Du coup ceux qui Ă  travers un atelier en attendaient plus en sont certainement sortis déçus. MitigĂ©, parce que malgrĂ© cela, il s’agissait d’un sujet intĂ©ressant, qui mĂ©ritait d’ĂŞtre traitĂ© et que pour qui n’a pas eu l’occasion de lire le livre, il y avait lĂ  de nombreux concepts Ă  mettre dans ses valises.

Mais au fait, de quoi s’agit-il ? Quel est ce livre dont on parle de plus en plus au sein de la communautĂ© Agile ?

Le Livre

Le livre de FrĂ©dĂ©ric Laloux est un travail sur la thĂ©orie des organisations qui s’inscrit dans une dĂ©marche historique (Ă©volution des organisations Ă  travers le temps) et pratique (quelles sont les caractĂ©ristiques et recettes de ces organisations). Il y dĂ©crit 5 types d’organisations qu’il catĂ©gorise Ă  travers 5 couleurs : Red, Amber, Orange, Green, Teal. Ces diffĂ©rentes organisations reprĂ©sentent Ă  la fois des Ă©volutions de structure Ă  travers le temps et des Ă©volutions de mode de fonctionnement (type de hiĂ©rarchie, prise de dĂ©cision, rĂ©solution de conflit, autonomie, etc.).

Si la communautĂ© Agile en parle, c’est que l’organisation de type Teal, celle qui reprĂ©sente le sujet principal d’Ă©tude du livre est une organisation de type entreprise libĂ©rĂ©e (concept popularisĂ© par Isaac Getz dans son livre Liberté & Cie). Alors que jusqu’Ă  prĂ©sent on avait peu ou pas de modèles pour ce genre d’entreprise (et peu d’exemples d’entreprises ayant adoptĂ© ce mode de fonctionnement), Laloux nous en propose ici une première thĂ©orisation qu’il accompagne de beaucoup d’exemples de sociĂ©tĂ©s qu’il a pu interviewer. C’est aussi un sujet d’intĂ©rĂŞt pour l’AgilitĂ©, car on constate, Ă  la lecture du livre, que si l’agilitĂ© n’est pas ou peu mentionnĂ©e dans le livre les caractĂ©ristiques de ces entreprises libĂ©rĂ©es sont Ă©minemment Agiles. Alors qu’on cherche Ă  dĂ©velopper l’AgilitĂ© Ă  grande Ă©chelle, on a lĂ  un modèle d’organisation Agile diffĂ©rent de SAFe, diffĂ©rent de Spotify, qui fonctionne Ă  des Ă©chelles surprenantes (jusqu’Ă  plus de 60.000 personnes) et dans des contextes variĂ©s (Ă©cole, santĂ©, industrie, alimentaire, conseil…).

L’entreprise libĂ©rĂ©e c’est donc un peu la diffĂ©rence entre « Doing Agile » et « Being Agile ». Une entreprise libĂ©rĂ©e n’applique pas nĂ©cessairement une ou des pratiques agiles (bien qu’il n’y ait pas d’incompatibilitĂ©), mais est naturellement Agile. C’est un Ă©tat d’esprit de l’entreprise et de ses collaborateurs qui permet d’ĂŞtre Agile. Une entreprise libĂ©rĂ©e est naturellement au plus près de ses clients, rĂ©active au changement, capable d’Ă©mergence en plus de favoriser un certain dĂ©veloppement personnel et un certain bonheur.

Ce qui est intĂ©ressant aussi c’est la manière dont nous avons Ă©voluĂ© pour aujourd’hui assister Ă  l’apparition de ces modèles d’entreprises. FrĂ©dĂ©ric Laloux explique ainsi que d’une certaine manière on ne peut pas accĂ©der aux Ă©tats de dĂ©veloppement supĂ©rieurs sans avoir connu les infĂ©rieurs. Qu’une organisation de type Red, basĂ©e sur une hiĂ©rarchie absolue, la loi de la force, la rĂ©pression et la terreur (pensez Ă  la mafia) nous semble primitive c’est parce que nous avons Ă©voluĂ© Ă  un stade de conscience qui nous permet d’en voir les limites. S’il y a une progression de Red, Amber, Orange, Green vers Teal, une entreprise ne peut pas dĂ©cider soudainement de devenir de type Teal. Une certaine Ă©volution de l’organisation et de ses leaders est nĂ©cessaire.

Quelles sont donc ces organisations ?

Red: C’est la Mafia, une organisation basĂ©e sur la force. Il n’y a pas d’autonomie, pas de dĂ©lĂ©gation de pouvoir. C’est une organisation qui vit dans l’affrontement perpĂ©tuel, sans stabilitĂ© et pĂ©rennitĂ©. C’est le culte d’un individu (le parrain).

Amber: C’est une organisation fortement hiĂ©rarchique comme l’armĂ©e ou la religion. Au service d’un idĂ©al, mais lĂ  aussi avec une chaĂ®ne de commande forte. On a la stabilitĂ©, mais pas de dĂ©veloppement autre que celui imposĂ©.

Orange: C’est la majoritĂ© des organisations actuelles, hiĂ©rarchiques et au service du business. Les guerres et affrontements sont en fait des alliances pour mieux se dĂ©velopper. On est dans le culte de la mĂ©ritocratie. On y postule que les plus mĂ©ritants seront promus et que les meilleurs rĂ©ussiront (la rĂ©alitĂ© est plus nuancĂ©e). On y valorise l’innovation et la responsabilitĂ© (accountable en anglais).

Green: C’est l’organisation au service de tous et c’est aussi une organisation qui a un sens (une mission). On y retrouve beaucoup d’ONG mais aussi certaines entreprises Ă©coresponsables. Le pouvoir est dĂ©centralisĂ© et on recherche le consensus. L’organisation est centrĂ©e sur le bien-ĂŞtre de ses employĂ©s, peut-ĂŞtre plus que vers l’extĂ©rieur. C’est dĂ©jĂ  une organisation qui prĂ©sente certaines caractĂ©ristiques agiles (avec de l’auto-organisation) mais qui a parfois du mal Ă  prendre des dĂ©cisions lorsqu’il s’agit d’aligner tout le monde.

Teal: C’est l’entreprise libĂ©rĂ©e, sans hiĂ©rarchie, ou chacun est autonome et responsable. Le pouvoir y est dĂ©centralisĂ©. C’est aussi une entreprise tournĂ©e vers l’extĂ©rieur et le client. C’est l’entreprise Agile par excellence, ou l’amĂ©lioration continue peut ĂŞtre portĂ©e par tous au plus près du besoin. C’est une organisation qui permet l’Ă©mergence.

Alors, comment aller vers cette organisation Agile / Teal?

Il n’y a pas rĂ©ellement de recette mais quelques pistes. Sur ce sujet, l’un des apports de la confĂ©rence Ă©tait peut-ĂŞtre cette idĂ©e du WholeAgile, c’est-Ă -dire l’AgilitĂ© au sein des hommes, des pratiques et des organisations, soit l’intĂ©gralitĂ© de l’entreprise:

Capture-d’écran-2015-04-02-à-15.42.49.png

Ce lien avec l’AgilitĂ© n’est pas directement fait dans le livre de Laloux, mĂŞme si les idĂ©es de culture, l’importance des hommes et des relations y sont abordĂ©es.

Mais pour avancer vers l’organisation Teal, il faut bien aborder le problème dans son ensemble et pas simplement par l’un des aspects. Il faut donc dĂ©velopper une forme de culture, entière, sans masque (sans diffĂ©rence dehors/dedans) qui permette de rĂ©aliser la transition.

Cela passe par le développement de plusieurs éléments nécessaires à la transformation aux niveaux individuel et organisationnel.

Au niveau individuel:

  • DĂ©velopper la confiance (un prĂ©requis nĂ©cessaire Ă  la dĂ©lĂ©gation).
  • Faire grandir le sentiment de sĂ©curitĂ© (chacun peut s’exprimer et les opinions de tous sont entendues, y compris lorsqu’elles sont critiques)
  • Faire preuve d’ouverture (on ne parle pas seulement d’ouverture vers les autres et leurs idĂ©es mais aussi vers la mise en place de nouvelles façons de faire).
  • Valoriser l’entièretĂ© de l’individu (wholeness) qui ne devrait pas ĂŞtre diffĂ©rent en dehors du travail d’en dedans (« L’homme est bon » si l’on en croit Zobrist).
  • Permettre les connexions entre personnes, avec des fonctionnement en Ă©quipes de taille raisonnable.

Au niveau organisationnel:

  • Organiser une distribution rĂ©elle du pouvoir et du leadership (il ne s’agit pas de faire marche arrière au premier Ă©cueil au risque de casser la confiance).
  • Rendre l’information transparente et accessible Ă  tous de manière Ă  ce qu’on ne puisse plus se cacher derrière, pour rendre visible les Ă©checs et les rĂ©ussites et pour permettre une prise de dĂ©cision au plus juste du contexte.
  • Favoriser l’Ă©mergence, c’est-Ă -dire la proposition notamment d’Ă©lĂ©ments d’amĂ©lioration ou d’innovation depuis n’importe quelle source.
  • Permettre une forme de performance distribuĂ©e (Ă©viter le fonctionnement en mode hĂ©ros oĂą une personne prend tout Ă  sa charge pour, au contraire, favoriser le pouvoir du collectif)
  • RĂ©Ă©tudier les systèmes de compensation pour une plus grande clartĂ©, simplicitĂ© et pour favoriser l’initiative et l’amĂ©lioration continue.

Dans ce contexte, l’entreprise Teal va ainsi dĂ©velopper des caractĂ©ristiques « antifragile » et de rĂ©silience, assurant sa pĂ©rennitĂ© et sa performance mĂŞme lorsque les leaders originaux seront partis (on peut penser Ă  l’exemple de FAVI qui continue Ă  fonctionner en entreprise libĂ©rĂ©e malgrĂ© le dĂ©part de Jean-François Zobrist – cf aussi notre retour sur la confĂ©rence de Jean-François Zobrist sur l’entreprise libĂ©rĂ©e – , mais aussi Ă  l’USS Santa Fe, le sous-marin nuclĂ©aire libĂ©rĂ© par le commandant Marquet dont vous pouvez lire l’histoire dans « Turn the Ship Around« ).

Bref, s’engager sur ce chemin s’est aussi prendre une route passionnante qui ne s’arrĂŞte pas Ă  la mise en place d’une nouvelle organisation, mais qui se construit et « apprend en allant » (comme dirait Zobrist).

Au final, on peut donc regretter de ne pas avoir eu l’occasion au ScrumDay de voir l’auteur original de « Reinventing Organizations », mais pour qui dĂ©couvrait ces concepts pour la première fois, il y avait lĂ  une matière intĂ©ressante.

Ci-dessous, scribing rĂ©alisĂ© en live lors de l’atelier :

Reinventing_Org_150dpi.jpgReinventing_org

Et voici le lien vers les slides de Michael Sahota et Olaf Levitz : « Reinventing Organisation for Entreprise Agility »

Catégories: Blog Société

Films_a_trouver

Paris Java User Group - dim, 04/12/2015 - 20:50

Bonjour,

Je vous pris de m'excuser de n'avoir pas été présent aux castcodeurs vendredi comme prévu, mais il manquait du matériel pour l'organisation de Devoxx4kids et j'ai du faire un choix. Vous comprendrez donc, je l'espère, que j'ai privilégié les enfants et les bénévoles de Devoxx4kids.

Pour ceux qui voulaient avoir la solution des films cachés dans mon discourt :

Catégories: Association

Partagez la connaissance

Partagez BlogsdeDeveloppeurs.com sur les réseaux sociaux