Le but est de voir en temps réel sur une carte les déplacements d'une flotte de véhicules à partir d'un navigateur Web.
L'intégralité de l'article est à lire ici (en anglais).
Dans le cadre d'un projet pour un client, j'ai réalisé un prototype basé sur Play 2.0 pour le framework web, Twitter Bootstrap intégré avec LessCss pour l'IHM, du Websocket pour la partie Web temps réel, Akka pour la scalabilité et OpenLayers pour le rendu de la carte.
Le but est de voir en temps réel sur une carte les déplacements d'une flotte de véhicules à partir d'un navigateur Web.
L'intégralité de l'article est à lire ici (en anglais).
Le but est de voir en temps réel sur une carte les déplacements d'une flotte de véhicules à partir d'un navigateur Web.
L'intégralité de l'article est à lire ici (en anglais).
Voici une brêve présentation de l’Agilité, utilisée pour faire une introduction sur l’Agilité et Scrum.
L'agilité en quelques slides
View more presentations from Nicolas DEVERGE
Avec @Chipeau, nous nous sommes battus pour réparer une table InnoDB de Mysql vraiment très mal en point.
Ce récit palpitant est à lire ici : http://www.ekito.fr/portail/repairing-a-badly-hurt-mysql-database?lang=en
Ce récit palpitant est à lire ici : http://www.ekito.fr/portail/repairing-a-badly-hurt-mysql-database?lang=en
Jeudi dernier, avec mon compère Bert, nous avons animé un retour d'expérience au JUG de Toulouse.
Il était question de Flex, de Spring, d'Hibernate et de chats.
Nous avons été très bien accueillis par l'équipe du JUG, et nous avons également pu assister à une présentation très intéressante de HTML5 par Florent.
Je vous laisse découvrir notre présentation.
Il était question de Flex, de Spring, d'Hibernate et de chats.
Nous avons été très bien accueillis par l'équipe du JUG, et nous avons également pu assister à une présentation très intéressante de HTML5 par Florent.
Je vous laisse découvrir notre présentation.
Par "client", j'entends le client dans le sens péjoratif du terme. A savoir, "le client est roi" et il faut le satisfaire quelque soit ses demandes.
Dans un projet Agile, le Product Owner est souvent (et c'est conseillé) représenté par un utilisateur final, et il peut donc être facile de le considérer comme un "client" de l'application.
Hors, au client, on associe souvent un fournisseur, à savoir, dans le cadre d'un projet Agile, l'équipe de développement (ScrumMaster + membres de l'équipe). Du coup, le risque est d'entrer dans une relation client/fournisseur, ce qui n'est pas Agile.
En effet, le Product Owner doit faire partie intégrante de l'équipe, il a des obligations vis à vis de l'équipe (gestion du backlog, définition des tests d'acceptance, validation...), il doit aussi lui rendre des comptes; par exemple, c'est mieux si le Product Owner participe également aux DailyScrum et qu'il soit interrogé comme les autres membres de l'équipe.
Comme pour le ScrumMaster, il ne doit pas s'établir de hiérarchie opérationnelle entre le Product Owner et un membre de l'équipe.
Un bon Product Owner doit aussi être ouvert à la critique, et l'équipe doit toujours remettre dans le contexte et challenger ce qui est demandé par le Product Owner; tout le monde communique avec tout le monde, de manière ouverte, transparente et sans arrière pensée.
Une méthode simple pour vérifier si votre Product Owner est un "client" : si ce n'est pas lui qui présente la démo à la revue, c'est que votre ProductOwner n'est pas assez impliqué dans le projet...
Et vous, votre Product Owner fait-il partie intégrante de votre équipe Agile ?
Dans un projet Agile, le Product Owner est souvent (et c'est conseillé) représenté par un utilisateur final, et il peut donc être facile de le considérer comme un "client" de l'application.
Hors, au client, on associe souvent un fournisseur, à savoir, dans le cadre d'un projet Agile, l'équipe de développement (ScrumMaster + membres de l'équipe). Du coup, le risque est d'entrer dans une relation client/fournisseur, ce qui n'est pas Agile.
En effet, le Product Owner doit faire partie intégrante de l'équipe, il a des obligations vis à vis de l'équipe (gestion du backlog, définition des tests d'acceptance, validation...), il doit aussi lui rendre des comptes; par exemple, c'est mieux si le Product Owner participe également aux DailyScrum et qu'il soit interrogé comme les autres membres de l'équipe.
Comme pour le ScrumMaster, il ne doit pas s'établir de hiérarchie opérationnelle entre le Product Owner et un membre de l'équipe.
Un bon Product Owner doit aussi être ouvert à la critique, et l'équipe doit toujours remettre dans le contexte et challenger ce qui est demandé par le Product Owner; tout le monde communique avec tout le monde, de manière ouverte, transparente et sans arrière pensée.
Une méthode simple pour vérifier si votre Product Owner est un "client" : si ce n'est pas lui qui présente la démo à la revue, c'est que votre ProductOwner n'est pas assez impliqué dans le projet...
Et vous, votre Product Owner fait-il partie intégrante de votre équipe Agile ?
Une des quatre valeurs de XP est la valeur “courage”.
Le courage d'admettre aux parties prenantes qu'il est pratiquement impossible d'évaluer la charge (et donc le coût) en début de projet.
Le courage de laisser sa porte ouverte pour que le client puisse venir quand il le souhaite.
Le courage de montrer aux parties prenantes des burndown charts qui montent.
Le courage de montrer aux parties prenantes des burnup charts qui descendent.
Le courage de créer un nouveau post-it car on a une étude technique à mener.
Le courage de déranger le Product Owner même s’il semble très occupé.
Le courage d’admettre qu'on n'a pas compris une User Story et donc qu’il faut revoir le nombre de points d’effort.
Le courage de jeter du code s’il n’est pas utilisé.
Le courage de proposer une phase de refactoring pour diminuer la dette technique.
(J’en oublie sans doute… )
Mais si vous arrivez à mettre en œuvre ces différents éléments, c'est que vous avez réussi à être transparent au niveau de votre organisation, et petit à petit vous gagnerez la confiance de votre client et ça, ça n'a pas de prix !!
Et vous, dans vos projets, qu’est-ce qui vous demande le plus de courage ?
Je veux bien sûr parler de l’Agilité dans le domaine de l’ingénierie logicielle…
“Agility” (Wikipedia)
Lors de mes différentes présentations des méthodes agiles, je constate à chaque fois que beaucoup de pratiques agiles semblent complètement naturelles pour les gens.
Ceci est d'autant plus vrai avec les clients qui ne sont pas dans le métier de l'ingénierie logicielle ou qui sont dans des petites organisations (PME, startup).
En effet, certains utilisent certaines pratiques de manière naturelle, comme surtout :
Vous trouverez ci dessous mon classement des éléments qui séduisent vraiment mes padawans agiles et qui les encouragent à mettre en pratique les méthodes agiles.
De plus, l’agilité encourage le développement de la communication entre les différentes parties prenantes des projets (équipe de développement, support, utilisateurs finaux, management), via les invitations aux revues par exemple.
Et vous, quelle est la pratique agile qui vous semble la plus importante ?
“Agility” (Wikipedia)Lors de mes différentes présentations des méthodes agiles, je constate à chaque fois que beaucoup de pratiques agiles semblent complètement naturelles pour les gens.
Ceci est d'autant plus vrai avec les clients qui ne sont pas dans le métier de l'ingénierie logicielle ou qui sont dans des petites organisations (PME, startup).
En effet, certains utilisent certaines pratiques de manière naturelle, comme surtout :
- la priorisation : rien de révolutionnaire au niveau de l'agilité, si ce n'est que la méthode impose de prioriser les besoins
- le fini : certaines personnes pratiquent déjà naturellement le "fini", en ne s'attachant qu'à faire une seule chose à la fois
- le découpage en tâches avec un cycle de vie (“A faire”, “En cours”, “Terminé”…)
- le partage d’une vision : le but et les objectifs du projet
Vous trouverez ci dessous mon classement des éléments qui séduisent vraiment mes padawans agiles et qui les encouragent à mettre en pratique les méthodes agiles.
La simplicité
Les concepts et pratiques agiles sont très simples à expliquer et à comprendre, et donc très faciles à mettre en œuvre. On peut également démarrer de manière progressive en n’utilisant que quelques pratiques au début.La visibilité et la transparence
Il est important de montrer l’avancement tout au long du projet, et surtout en toute transparence. Les gens acceptent plus facilement un retard s’il est détecté plus tôt, ça leur permet de s’organiser plus facilement.Le droit au changement
Cette pratique est plus particulièrement appréciée par le management, mais beaucoup moins par l’équipe de réalisation… Il est donc très important d’expliquer à l’équipe que le changement doit être vu comme une bonne chose et non pas comme une sanction.Les métriques
Ce qui séduit, c’est de pouvoir mesurer ce qui a été fait, pour pouvoir prédire l’avenir, grâce notamment aux différents burndown charts (de sprint, de release).Le pilotage par la valeur métier
L’équipe produit en priorité ce qui apporte le plus de valeur aux utilisateurs, et on peut arrêter si on estime qu’on a atteint un niveau de maturité du produit suffisant.L’amélioration continue
Les clients apprécient beaucoup le fait que rien n’est acquis dès le début, et que l’équipe prend un peu de temps pour se remettre en question en terme d’organisation.L’aspect social
La plupart des gens sont très sensibles à la responsabilisation individuelle qui est mise en avant par les méthodes agiles (premier élément du Manifeste Agile : “Davantage l’interaction avec les personnes que les processus et les outils”). Par exemple, j’ai déjà rencontré un développeur qui avait plutôt tendance à rester dans son coin, mais qui est sorti de sa coquille grâce à l’espace d’expression qui lui était donné par les pratiques agiles (il se sentait écouté lors des Scrum meetings).De plus, l’agilité encourage le développement de la communication entre les différentes parties prenantes des projets (équipe de développement, support, utilisateurs finaux, management), via les invitations aux revues par exemple.
Et vous, quelle est la pratique agile qui vous semble la plus importante ?
Inscription à :
Messages (Atom)
