mardi 3 janvier 2017
mercredi 5 octobre 2016
Modern Agile
Etant parti pédaler tout l'été, j'avais manqué un événement important, mais heureusement twitter m'a permis de rattraper mon retard et de contribuer un tout petit peu à faire connaître Modern Agile !
Modern Agile est une très bonne nouvelle, qui m'enthousiasme et me fait même écrire un article dans mon blog, ce que je n'avais pas fait depuis très longtemps...
A l'heure où tout le monde se dit agile (il y a même des offres d'emploi de "chef de projet agile" !!!), il était temps de remettre les pendules à l'heure et de re-préciser ce qui compte vraiment. C'est chose faite avec Modern Agile. Alors, modernisons-nous et laissons tomber les pratiques, organisations et comportements d'un autre âge...
Dans le même esprit, il y a 3 ans, je déplorais que l'agilité soit dénaturée, que beaucoup "fassent de l'agile" (LA méthode agile) au lieu d'essayer de devenir agile.
J'ai donc découvert avec plaisir cette synthèse faite par Claude Aubry : Anars vs neocons.
Modern Agile est une très bonne nouvelle, qui m'enthousiasme et me fait même écrire un article dans mon blog, ce que je n'avais pas fait depuis très longtemps...
A l'heure où tout le monde se dit agile (il y a même des offres d'emploi de "chef de projet agile" !!!), il était temps de remettre les pendules à l'heure et de re-préciser ce qui compte vraiment. C'est chose faite avec Modern Agile. Alors, modernisons-nous et laissons tomber les pratiques, organisations et comportements d'un autre âge...
Dans le même esprit, il y a 3 ans, je déplorais que l'agilité soit dénaturée, que beaucoup "fassent de l'agile" (LA méthode agile) au lieu d'essayer de devenir agile.
J'ai donc découvert avec plaisir cette synthèse faite par Claude Aubry : Anars vs neocons.
jeudi 16 avril 2015
Informatique et montagne
Les p'tits gars (et les filles) de fantasticode ont bien bossé !
Ils proposent cet été, en partenariat avec Montagnes de la Terre, des stages pour apprendre aux enfants à programmer.
"Montagnes de la Terre, c'est le Club Alpin Français, quel rapport avec le code ?" C'est que ces stages - une première - mêlent programmation et montagne !
Tout est là : www.fantasticode.fr/stages.html
"Vertical Code" : coder le matin, et grimper l'après midi.
"les Aventuriers du code" : explorer le monde de l'informatique et celui de la nature.
Pourquoi mêler les deux ?
"Mens sana in corpore sano", un esprit sain dans un corps sain...
Mais aussi parce qu'apprendre à programmer c'est aussi apprendre à partager et à collaborer.
C'est être curieux et aimer découvrir, c'est apprendre de ses pairs, en pratiquant et en s'amusant.
Et en montagne, toutes ces notions ont un sens, non ?
Vos enfants ne sont pas encore inscrits ?
jeudi 26 mars 2015
Vive les fantasticodeuses et fantasticodeurs !
Un projet passionnant est en train de voir le jour par chez nous, dans les montagnes : un réseau de développeurs et d'animateurs (et aussi d'autres sortes de passionnés, je vous raconterai ça une autre fois) qui ont décidé d'apprendre aux enfants à programmer.
Ca s'appelle fantasticode et ça va prendre plein de formes différentes... Suspense...
Pourquoi apprendre à coder aux enfants ? Pour en faire des développeurs promis à une super carrière en SSII ;-) Euh... non pas du tout.
On apprend pas l'histoire à l'école pour devenir historien. Alors pourquoi ?
Nous avons organisé notre premier fantasticoding-goûter mercredi dernier à la locomotive, et c'était chouette !
Au menu : cookies, jus de pomme made in hautes-alpes, javascript, processing, et "Train your robot" de Dr Techniko.
Et ça ne fait que commencer...
Ca s'appelle fantasticode et ça va prendre plein de formes différentes... Suspense...
Pourquoi apprendre à coder aux enfants ? Pour en faire des développeurs promis à une super carrière en SSII ;-) Euh... non pas du tout.
On apprend pas l'histoire à l'école pour devenir historien. Alors pourquoi ?
Nous avons organisé notre premier fantasticoding-goûter mercredi dernier à la locomotive, et c'était chouette !
Au menu : cookies, jus de pomme made in hautes-alpes, javascript, processing, et "Train your robot" de Dr Techniko.
Et ça ne fait que commencer...
mardi 16 décembre 2014
Simple (épisode 3)
Si vous avez le temps, relisez mes 2 articles sur le sujet : Simple et Simple (épisode 2). Ils datent de 2013, mais rien n'a changé.
Cette fois je vais vous parler d'un article écrit par Jacob Nielsen : User Expertise Stagnates at Low Levels
Résumé : Learning is hard work, and users don't want to do it; they don't explore the user interface and don't know about most features.
Autrement dit, les utilisateurs se servent de ce qui est immédiatement accessible et visible, et ignorent l'existence du reste.
Il semble que - même s'ils utilisent fréquemment une application - ils n'explorent pas ses possibilités, sauf éventuellement au début.
Ca vous parle ? De temps en temps vous "explorez" un peu les applications que vous utilisez quotidiennement, vous ?
Dans les études citées, les utilisateurs ne savent rien des fonctions qui sont juste un brin à l'extérieur du cas d'utilisation minimaliste.
Les solutions proposées :
- moins de fonctionnalités
- des fonctionnalités plus visibles (pas cachées derrière un scroll ou un swipe)
- "visible signifiants" (je n'ai pas trouvé de traduction courte, sorry, mais en gros : si on peut cliquer quelque part, faites que ça se voit...)
- donner des éléments de doc de temps en temps, au bon endroit / moment (astuces, etc.)
- "essayabilité" : pardonnez les erreurs, donnez l'occasion d'explorer sans risques (ceci est aussi valable en dehors d'une application, dans la "vraie vie"...). Mieux : donner un aperçu de ce qui va se passer si vous utilisez telle ou telle fonction.
Si vraiment vous ne savez pas quoi faire de cette journée, essayez d'acheter quelque chose sur le site www.arngren.net ;-)
Cette fois je vais vous parler d'un article écrit par Jacob Nielsen : User Expertise Stagnates at Low Levels
Résumé : Learning is hard work, and users don't want to do it; they don't explore the user interface and don't know about most features.
Autrement dit, les utilisateurs se servent de ce qui est immédiatement accessible et visible, et ignorent l'existence du reste.
Il semble que - même s'ils utilisent fréquemment une application - ils n'explorent pas ses possibilités, sauf éventuellement au début.
Ca vous parle ? De temps en temps vous "explorez" un peu les applications que vous utilisez quotidiennement, vous ?
Dans les études citées, les utilisateurs ne savent rien des fonctions qui sont juste un brin à l'extérieur du cas d'utilisation minimaliste.
Les solutions proposées :
- moins de fonctionnalités
- des fonctionnalités plus visibles (pas cachées derrière un scroll ou un swipe)
- "visible signifiants" (je n'ai pas trouvé de traduction courte, sorry, mais en gros : si on peut cliquer quelque part, faites que ça se voit...)
- donner des éléments de doc de temps en temps, au bon endroit / moment (astuces, etc.)
- "essayabilité" : pardonnez les erreurs, donnez l'occasion d'explorer sans risques (ceci est aussi valable en dehors d'une application, dans la "vraie vie"...). Mieux : donner un aperçu de ce qui va se passer si vous utilisez telle ou telle fonction.
Si vraiment vous ne savez pas quoi faire de cette journée, essayez d'acheter quelque chose sur le site www.arngren.net ;-)
dimanche 23 novembre 2014
Quelques idées et livres ramenés d'Agile Grenoble 2014
Comme à chaque fois, je reviens d'Agile Grenoble rempli d'énergie (positive, ça va de soi !).
J'ai fait le plein d'idées, des petites choses concrètes à mettre en oeuvre tout de suite (une rétro en mode "appreciative inquiry", par exemple) aux grands concepts.
Rien de super-nouveau, mais des rappels bien sympa.
Un grand grand bravo et merci à Alexandre Gérard (Chronoflex / InovOn) pour sa keynote brillante et inspirante !
J'ai bien aimé la session de Thierry Conter : "Comment donner un souffle d'énergie positive à vos rétrospectives grâce à l'Appreciative Inquiry". Du concret, utilisable tout de suite (déjà utilisé,pour tout vous dire...)
Et je repars d'Agile Grenoble avec deux livres à acheter :
Vivement l'année prochaine !
vendredi 15 novembre 2013
Concours Open PACA
[Mode Auto-satisfaction = on]
Taratata !!! Nous avons gagné le prix co-production citoyenne au concours Open PACA !
Nous, c'est une équipe de 4 coworkers (Sophie, Céline, Yohan et moi) de La Locomotive, l'espace de coworking de Gap lancé depuis 1 an.
"Joue avec ta ville", c'est un concept de jeux basés sur les données ouvertes fournies par une collectivité.
J'aurai certainement l'occasion de vous en dire un peu plus sur le contenu du projet, mais ce qui me semble important, c'est de parler de l'équipe.
Philippe Mussi, le conseiller régional qui nous a remis le prix, l'a mentionné : un projet original et une équipe intéressante avec notamment - pour une fois - a t-il dit - un spécialiste du domaine du jeu pour créer des jeux. En effet, Yohan est ludothécaire et grand joueur, bref un expert "métier" pour ce projet.
Beaucoup de choses me tiennent à coeur dans cette aventure :
- une équipe qui gagne parce qu'elle est pluridisciplinaire et complémentaire
- des rencontres et des échanges intéressants,
- une équipe efficace et qui ne se pose pas de questions inutiles, alors que nous n'avions jamais travaillé ensemble (certains ne s'étaient jamais rencontrés avant ce projet)
- le coworking et la sérendipité qui va avec, ce ne sont pas que des mots
- l'Open Data : comme beaucoup d'autres, je pense que l'ouverture des données est un enjeu important, tant d'un point de vue économique que démocratique
- et surtout : des personnes qui travaillent ensemble sur un projet, sans y être obligées, avec comme seuls objectifs de réfléchir à quelque chose de "chouette" et de se faire plaisir... ça marche !
Taratata !!! Nous avons gagné le prix co-production citoyenne au concours Open PACA !
Nous, c'est une équipe de 4 coworkers (Sophie, Céline, Yohan et moi) de La Locomotive, l'espace de coworking de Gap lancé depuis 1 an.
"Joue avec ta ville", c'est un concept de jeux basés sur les données ouvertes fournies par une collectivité.
J'aurai certainement l'occasion de vous en dire un peu plus sur le contenu du projet, mais ce qui me semble important, c'est de parler de l'équipe.
Philippe Mussi, le conseiller régional qui nous a remis le prix, l'a mentionné : un projet original et une équipe intéressante avec notamment - pour une fois - a t-il dit - un spécialiste du domaine du jeu pour créer des jeux. En effet, Yohan est ludothécaire et grand joueur, bref un expert "métier" pour ce projet.
Beaucoup de choses me tiennent à coeur dans cette aventure :
- une équipe qui gagne parce qu'elle est pluridisciplinaire et complémentaire
- des rencontres et des échanges intéressants,
- une équipe efficace et qui ne se pose pas de questions inutiles, alors que nous n'avions jamais travaillé ensemble (certains ne s'étaient jamais rencontrés avant ce projet)
- le coworking et la sérendipité qui va avec, ce ne sont pas que des mots
- l'Open Data : comme beaucoup d'autres, je pense que l'ouverture des données est un enjeu important, tant d'un point de vue économique que démocratique
- et surtout : des personnes qui travaillent ensemble sur un projet, sans y être obligées, avec comme seuls objectifs de réfléchir à quelque chose de "chouette" et de se faire plaisir... ça marche !
dimanche 8 septembre 2013
Etre agile
La session que j'avais proposé à l'Agile Tour Marseille "Dis monsieur, c'est quoi être agile ?" a été retenue. J'ai animé cet atelier l'année dernière à Agile Grenoble avec Laurence Hanot et je suis très heureux de le refaire.
L'occasion de revenir sur "être agile" vs "faire de l'agile".
Ce sujet me semble plus que jamais d'actualité, à l'heure où tout le monde se dit agile.
Tout le monde ? Non, pas vraiment. Mais - sans revenir sur le sujet de "Agile has cross the chasm or not?" - de très nombreuses entreprises se déclarent agiles.
Le dessin ci-dessous date de 2009 :
et depuis, l'agilité semble avoir continué de s'étendre, regardez par exemple l'évolution du nombre de jobs liés à Scrum :
Les primo-adoptants, les visionnaires et les pragmatiques ont adopté les méthodes agiles, et certains conservateurs aussi (si si je connais des entreprises on ne peut plus conservatrices qui se sont lancées dans l'aventure). Voir cet article d'Agile Focus, début 2011.
Mais qu'en est-il vraiment ? Je suis tout à fait d'accord avec l'article d'Agile Focus, "I think there is a vast army of supposedly Agile teams and companies that have adopted the look and the lingo while totally missing the point."
Ce n'est pas en saucissonnant le planning du projet en soi-disant itérations (à la fin de laquelle rien n'est livrable), ni en nommant le chef de projet Scrum Master, ni en collant des post-its partout que l'on est agile...
Etre agile, je pense que c'est avoir intégré un certain état d'esprit (humilité, simplicité, pragmatisme, amélioration continue par exemple) et avoir adopté certaines pratiques. Quand je dis intégré et adopté, je veux dire qu'il n'y a plus besoin d'y penser, cela se fait naturellement, c'est devenu votre façon de penser et de travailler.
L'occasion de revenir sur "être agile" vs "faire de l'agile".
Ce sujet me semble plus que jamais d'actualité, à l'heure où tout le monde se dit agile.
Tout le monde ? Non, pas vraiment. Mais - sans revenir sur le sujet de "Agile has cross the chasm or not?" - de très nombreuses entreprises se déclarent agiles.
Le dessin ci-dessous date de 2009 :
Source : www.agilemodeling.com Scott Ambler
et depuis, l'agilité semble avoir continué de s'étendre, regardez par exemple l'évolution du nombre de jobs liés à Scrum :
Les primo-adoptants, les visionnaires et les pragmatiques ont adopté les méthodes agiles, et certains conservateurs aussi (si si je connais des entreprises on ne peut plus conservatrices qui se sont lancées dans l'aventure). Voir cet article d'Agile Focus, début 2011.
Mais qu'en est-il vraiment ? Je suis tout à fait d'accord avec l'article d'Agile Focus, "I think there is a vast army of supposedly Agile teams and companies that have adopted the look and the lingo while totally missing the point."
Ce n'est pas en saucissonnant le planning du projet en soi-disant itérations (à la fin de laquelle rien n'est livrable), ni en nommant le chef de projet Scrum Master, ni en collant des post-its partout que l'on est agile...
Etre agile, je pense que c'est avoir intégré un certain état d'esprit (humilité, simplicité, pragmatisme, amélioration continue par exemple) et avoir adopté certaines pratiques. Quand je dis intégré et adopté, je veux dire qu'il n'y a plus besoin d'y penser, cela se fait naturellement, c'est devenu votre façon de penser et de travailler.
mardi 27 août 2013
Simple (épisode 2)
Il y a quelques mois, j'ai écrit quelques lignes sur la simplicité en matière de logiciel : Simple : le premier épisode, dans lequel je m'interrogeais alors sur les raisons qui nous poussent à faire plus compliqué que nécessaire.
Mais essayons désormais de voir comment "faire simple".
Lisez "Simplicité et complexité", de Marc Halévy. Quelques extraits (mais lisez l'article en entier !) :
- "Assumer - et magnifier - intégralement la complexité du réel dans la simplicité de l'acte"
- "Simple ? Minimal. Econome. Frugal. Non pas faire le plus, mais faire le mieux (complexité) avec le moins (simplicité)."
- "Simplicité. Processus intégratif et non pas concaténation additive"
Intégrer et non pas ajouter. Le secret de la simplicité semble être là.
Un produit ne doit pas être une addition, un empilement de fonctionnalités qui utilisées conjointement permettent (ou espèrent permettre) à son utilisateur de réaliser ce qu'il veut faire. Mais le produit doit avoir intégré la compréhension de cette tâche.
Si je crée un produit ayant les fonctions suivantes :
- orienter une roue
- faire tourner une roue à l'aide de pédales
- permettre de s'asseoir
- avertir à l'aide d'une sonnette
ça n'en fait pas pour autant un vélo... (et pour peu que l'accent ait été mis sur "avertir à l'aide d'une sonnette", on est loin du compte).
Créer un vélo nécessite la compréhension de ce qu'est l'activité. Comme le dit très bien Marc Halévy, on ne peut pas apprendre à faire du vélo sans... en faire :
"La complexité/simplicité, c'est comme l'art de rouler à vélo. Lorsqu'on sait, c'est facile. Mais c'est extrêmement compliqué - voire impossible - à exprimer. On n'apprend pas à rouler à vélo dans les livres, mais bien dans le vécu, dans l'expérientiel. On peut décrire ou expliquer le roulage à vélo, sans savoir soi-même rouler, et ce sera très compliqué. Mais rouler vraiment à vélo, comprendre réellement le roulage à vélo, passent nécessairement par la complexité/simplicité de l'apprentissage direct, par soi-même, au-delà des échecs, des chutes et de éraflures."
Vous ne pouvez donc pas réaliser un produit (simple a fortiori) sans comprendre profondément (ressentir, expérimenter, vivre !) ce que l'utilisateur veut faire avec. Comment ? En s'asseyant à coté de lui, par exemple.
Et préparez vous à ne pas y arriver du premier coup.
Mais essayons désormais de voir comment "faire simple".
Lisez "Simplicité et complexité", de Marc Halévy. Quelques extraits (mais lisez l'article en entier !) :
- "Assumer - et magnifier - intégralement la complexité du réel dans la simplicité de l'acte"
- "Simple ? Minimal. Econome. Frugal. Non pas faire le plus, mais faire le mieux (complexité) avec le moins (simplicité)."
- "Simplicité. Processus intégratif et non pas concaténation additive"
Intégrer et non pas ajouter. Le secret de la simplicité semble être là.
Un produit ne doit pas être une addition, un empilement de fonctionnalités qui utilisées conjointement permettent (ou espèrent permettre) à son utilisateur de réaliser ce qu'il veut faire. Mais le produit doit avoir intégré la compréhension de cette tâche.
Si je crée un produit ayant les fonctions suivantes :
- orienter une roue
- faire tourner une roue à l'aide de pédales
- permettre de s'asseoir
- avertir à l'aide d'une sonnette
ça n'en fait pas pour autant un vélo... (et pour peu que l'accent ait été mis sur "avertir à l'aide d'une sonnette", on est loin du compte).
Créer un vélo nécessite la compréhension de ce qu'est l'activité. Comme le dit très bien Marc Halévy, on ne peut pas apprendre à faire du vélo sans... en faire :
"La complexité/simplicité, c'est comme l'art de rouler à vélo. Lorsqu'on sait, c'est facile. Mais c'est extrêmement compliqué - voire impossible - à exprimer. On n'apprend pas à rouler à vélo dans les livres, mais bien dans le vécu, dans l'expérientiel. On peut décrire ou expliquer le roulage à vélo, sans savoir soi-même rouler, et ce sera très compliqué. Mais rouler vraiment à vélo, comprendre réellement le roulage à vélo, passent nécessairement par la complexité/simplicité de l'apprentissage direct, par soi-même, au-delà des échecs, des chutes et de éraflures."
Vous ne pouvez donc pas réaliser un produit (simple a fortiori) sans comprendre profondément (ressentir, expérimenter, vivre !) ce que l'utilisateur veut faire avec. Comment ? En s'asseyant à coté de lui, par exemple.
Et préparez vous à ne pas y arriver du premier coup.
jeudi 11 avril 2013
Lean startup, pas pour moi ?
La semaine prochaine, je dispenserai ma première formation Lean startup.
Comment moi, plutôt orienté développement et management, en suis-je venu à m'intéresser à ce point à ce qui est présenté comme la méthode miracle par les marketers de la Silicon Valley ?
Le moins qu'on puisse dire, c'est que la création de startups et le marketing, ça n'est pas vraiment ce qui m'a occupé ces 20 dernières années...
Lean startup = "Customer Development" de Steve Blank + les méthodes agiles.
Le second point, pas de souci. Mais le premier, ça fait un peu plus peur. "Inbound marketing, early adopters, customer lifetime value, etc."
Mais en y regardant d'un peu plus près, sur Wikipedia, par exemple, on trouve cette définition :
"The concept details a scientific approach that can be applied by startups and entrepreneurs to improve their products success by developing a better understanding of their consumers. Primary to the concept is a balanced relationship between developing a product and understanding the customer."
Améliorer les produits et mieux comprendre les clients, en résumé. Donc Lean startup, c'est faire le produit adapté au client en utilisant les méthodes agiles...
Et un développeur pourrait ignorer ça ? Non.
Lean startup favorise la simplicité et la rapidité - voir mon article "Vite un produit" écrit suite à Agile Grenoble 2011 - mais surtout, je crois que cette méthode a beaucoup à nous apprendre sur la façon de faire découvrir aux utilisateurs leurs besoins et le produit qu'il leur faut. Et pas seulement dans le monde du numérique.
Bref, la semaine prochaine, je dispense ma première formation Lean startup.
A cette occasion, j'ai traduit en français le Lean Canvas, merci à Ash Maurya de m'avoir autorisé à le faire. Et si vous avez une meilleure traduction à proposer, je suis preneur !
Si vous souhaitez un modèle "vierge" de Lean Canvas en français, contactez moi (cf. www.36tribus.com).
Comment moi, plutôt orienté développement et management, en suis-je venu à m'intéresser à ce point à ce qui est présenté comme la méthode miracle par les marketers de la Silicon Valley ?
Le moins qu'on puisse dire, c'est que la création de startups et le marketing, ça n'est pas vraiment ce qui m'a occupé ces 20 dernières années...
Lean startup = "Customer Development" de Steve Blank + les méthodes agiles.
Le second point, pas de souci. Mais le premier, ça fait un peu plus peur. "Inbound marketing, early adopters, customer lifetime value, etc."
Mais en y regardant d'un peu plus près, sur Wikipedia, par exemple, on trouve cette définition :
"The concept details a scientific approach that can be applied by startups and entrepreneurs to improve their products success by developing a better understanding of their consumers. Primary to the concept is a balanced relationship between developing a product and understanding the customer."
Améliorer les produits et mieux comprendre les clients, en résumé. Donc Lean startup, c'est faire le produit adapté au client en utilisant les méthodes agiles...
Et un développeur pourrait ignorer ça ? Non.
Lean startup favorise la simplicité et la rapidité - voir mon article "Vite un produit" écrit suite à Agile Grenoble 2011 - mais surtout, je crois que cette méthode a beaucoup à nous apprendre sur la façon de faire découvrir aux utilisateurs leurs besoins et le produit qu'il leur faut. Et pas seulement dans le monde du numérique.
Bref, la semaine prochaine, je dispense ma première formation Lean startup.
A cette occasion, j'ai traduit en français le Lean Canvas, merci à Ash Maurya de m'avoir autorisé à le faire. Et si vous avez une meilleure traduction à proposer, je suis preneur !
Si vous souhaitez un modèle "vierge" de Lean Canvas en français, contactez moi (cf. www.36tribus.com).
Inscription à :
Articles (Atom)