Dans nos accompagnements techniques, nous observons régulièrement des problèmes de Legacy Code aussi appelé Code Patrimonial. Notamment lorsque des équipes font un virage agile et on leur demande soudainement de faire des tests unitaires automatisés. Pas si facile que cela.
Dans cette présentation, nous verrons les points suivants:
- Description de quelques techniques pour nous aider à tester le Legacy Code
- Comment avoir le droit de travailler sur du code pour le rendre plus facile à travailler
- Quelques pratiques et outils afin de s'en prémunir autant que possible au jour le jour.
Cette présentation a été donnée aux dates suivantes:
- 10 Novembre 2016 - Beer And Learn (Québec)
- 16 Novembre 2016 - Agile Tour Montréal
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013Xavier NOPRE
Diaporama de ma présentation "Agilistes : n'oubliez pas la technique" le 25/04/2013 à Mix-IT 2013. N'hésitez pas à me faire des retours et me contacter !
Une usine logicielle est un ensemble d’outils pré-configurés, de frameworks, de conventions, de processus, de documentations et de modèles de projets qui structurent les développeurs et leurs développements.
L’objectif est d’automatiser au maximum la production et la maintenance des applications afin d’améliorer leur qualité et le « time to market ».
La présentation a pour but d'expliquer comment les concepts de Clean Architecture et de l'architecture en oignon ont été utilisés dans un projet phare de iA Groupe Financier pour permettre de travailler en mode agile en réutilisant du code patrimonial.
Karol Deland
Dans nos accompagnements techniques, nous observons régulièrement des problèmes de Legacy Code aussi appelé Code Patrimonial. Notamment lorsque des équipes font un virage agile et on leur demande soudainement de faire des tests unitaires automatisés. Pas si facile que cela.
Dans cette présentation, nous verrons les points suivants:
- Description de quelques techniques pour nous aider à tester le Legacy Code
- Comment avoir le droit de travailler sur du code pour le rendre plus facile à travailler
- Quelques pratiques et outils afin de s'en prémunir autant que possible au jour le jour.
Cette présentation a été donnée aux dates suivantes:
- 10 Novembre 2016 - Beer And Learn (Québec)
- 16 Novembre 2016 - Agile Tour Montréal
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013Xavier NOPRE
Diaporama de ma présentation "Agilistes : n'oubliez pas la technique" le 25/04/2013 à Mix-IT 2013. N'hésitez pas à me faire des retours et me contacter !
Une usine logicielle est un ensemble d’outils pré-configurés, de frameworks, de conventions, de processus, de documentations et de modèles de projets qui structurent les développeurs et leurs développements.
L’objectif est d’automatiser au maximum la production et la maintenance des applications afin d’améliorer leur qualité et le « time to market ».
La présentation a pour but d'expliquer comment les concepts de Clean Architecture et de l'architecture en oignon ont été utilisés dans un projet phare de iA Groupe Financier pour permettre de travailler en mode agile en réutilisant du code patrimonial.
Karol Deland
Ciel, mes développeurs PHP parlent chinois!Damien Seguy
Quand on partage la passion de PHP, le fossé culturel et la barrière de 3 langues ne font peur à personne. Comment appliquer des méthodes de qualité à des développeurs 2 continents plus loin ? Et apprendre de leur approche a aller plus loin ? Dans ce conte chinois, nous aborderons les moyens de mieux se comprendre, et les outils et méthodes pour mettre la qualité au premier plan.
Résumé
Pour la modification du code, nous utilisons tous des outils électroniques (IDEs, Git, Cucumber). Pour notre management visuel, nous avons encore des réticences : trop rigides, trop simpliste ou trop compliqués, ..ou encore difficile à intégrer ensemble. Et bien, je pense que ce sont des préjugés.
Fan d'outils, je vais vous aider à trouver votre ou vos outils Kanban.
Je présenterai intégration des outils Kanban entre eux et aussi vers d'autres outils de la chaine de Continuuous Delivery.
Description
Les freins à l'utilisation des outils électroniques et surtout leur intégration qui peut devenir un vrai casse tête.
Les nouvelles solutions qui méritent au moins de se reposer cette question d'utiliser des outils électroniques pour Kanban.
La flexibilité apporter par les API. Notamment la facilité d'étendre les fonctionnalités avec d'autres outils kanban/agiles préférés.
La possibilité de les adapter facilement pour accompagner les changements souhaités par l'équipe.
Déroulement
les étapes de la session : (à ce jour)
- Paradoxe de la multitude outils pour Kanban et des freins à leur adoption
- Des outils simples et qui vous guident dans leur utilisation, ca existe déjà
- Le choix épineux du bon outil : Matrice fonctionnalités, calcul ROI, ..
- On oublie parfois .. qu'il doit avant tout être agile (facile à adapter/changer/etendre/intégrer)
- L'intégration des outils c'est super simple ! Zapier, IFTTT
- Tellement simple que l'on peut même monter rapidement une usine à gaz
- Et si on essayait les faire eux aussi travailler en flux tiré ?
Quelle boite à outils pour une équipe qui veut travailler efficacement en suivant les principes agiles et DevOps.
Quels outils et pratiques utiliser et mettre en place.
Formation "Initiation Scrum" (sur 1 ou 2 jours)
- comprendre les principes agile
- découverte de SCRUM (les rôles, les livrables, les évènements)
- expérimenter par la pratique
L'adhésion grandissante à l'approche DevOps est un atout pour l’Agilité et s’impose comme une évolution logique à la transformation Agile. Un des facteurs clés du succès de cette approche est l’automatisation des processus de développement, et donc par le fait même, des tests.
Toutefois, si des tests sont automatisés, ils sont souvent loin des « user stories » qui sont pourtant la cible des Sprints pour livrer la valeur d'affaire. Les équipes prennent généralement en charge l’automatisation des tests unitaires et fonctionnels mais rarement celle des tests intégrés.
Afin de livrer une valeur d’affaire rapidement, il est nécessaire de tester les «user stories », donc d'effectuer des tests de bout-en-bout (end-to-end testing).
Voyez comment adapter vos stratégies de tests automatisé afin de garantir une amélioration continue de la qualité à travers votre organisation.
François Bonetto
Mise en place de bonnes pratiques (Scrum et php) au sein de projets existantsNicolas De Boose
Retour d'expérience technique et organisationnelle . Au menu :
- Passage à scrum: Les difficultés et solutions
- Code legacy: Du néan à l'industrialisation
Client complex, très ractif au marché, évolution constante des specs.
Incertitude certaine !
Presentation du socle technique Java open source Scub FoundationStéphane Traumat
Scub Foundation est un ensemble de frameworks, de conventions, d'outils et de procédures qui structurent les développeurs et leurs développements. Pour simplifier, c'est une plateforme qui permet l'industrialisation des projets de développement informatique.
Plus d'informations à http://www.scub-foundation.org
Objectifs du socle
- Ne pas réinventer la roue ! (Intégration d'Eclipse et des frameworks populaires comme hibernate, spring, gwt, JUnit…).
- Avoir des modèles de projets pour chaque type de projet mais avec des structures identiques.
- Avoir des tâches automatisées pour l'ensemble du cycle de vie du projet (compilation, packaging, test…).
- Développement SOA (intégration de la notion de noyau et du découplage Interface/implémentation).
- Gestion automatique des dépendances / librairies.
- Gérer les différents environnements (Test / Développement / Pré production / Production…).
Concrètement, notre socle technique offre au développeur un environnement de développement intégrant les meilleurs éléments Open Source (Eclipse, Maven, Spring, GWT…) ainsi que des modèles de projet.
Introduction aux spécifications exécutables (dit aussi atdd, bdd)Jean-Pierre Lambert
Comment s'assurer que tout le monde parle la même langue dans l'équipe ? Et ainsi éviter les retours de recette ?
Utiliser des spécifications exécutables, ou ses cousins le ATDD (Acceptance Test Driven Development) et le BDD (Behavior Driven Development), est un élément de réponse particulièrement pertinent. Cette méthode est également un point d'entrée puissant vers une stratégie d'automatisation des tests.
Dans cette présentation vous découvrirez les tenants et les aboutissants de cette méthode, et repartirez les poches remplies de conseils de mise en place.
Que faire si:
Votre transformation Agile a négligé les pratiques techniques.
Vous n'êtes pas alignés avec la livraison en continu pour DevOps.
Vous désirez établir une culture de code et d'expérimentation.
Comment faire adopter toutes ces pratiques ?
Pour répondre à ces questionnements, nous discuterons de leadership technique, de l'attitude et des responsabilités d'un tel leader en mode agile.
Karl Métivier
Agilité à budget fixe en phase d'avant-vente. Que proposer ?Frantz Degrigny
Je veux de l'agilité, mais un budget fixe ! Que proposer en phase d'avant-vente ?
Un retour d'expérience sous forme de "Lightning talk" présenté à l'Agile Tour Nantes 2016 :
- Introduire du BDD dans un projet pour un ministère, c'est possible ?
- Externaliser une équipe de réalisation en nearshore pour une grande banque, comment faire ?
- Réaliser une soutenance sur un format participatif et innovant, ça se fait ?
Nous parcourrons les différents principes suivants lors de nos retours d'expérience :
- Éduquer le client sur les principes, enjeux et contraintes des méthodes agiles
- Expliquer les impacts de l'agilité sur le déroulement et le prix du projet
- Comment adapter un contrat forfaitaire (Forfait simple, forfait au sprint, forfait au MVP, etc) ?
- Comment adapter les méthodes agiles (Un mélange de SCRUM, XP, franciser la méthodologie, etc ) ?
Finalement, nous terminerons sur les feedbacks de ces principales expériences, et particulièrement côté clients.
Ciel, mes développeurs PHP parlent chinois!Damien Seguy
Quand on partage la passion de PHP, le fossé culturel et la barrière de 3 langues ne font peur à personne. Comment appliquer des méthodes de qualité à des développeurs 2 continents plus loin ? Et apprendre de leur approche a aller plus loin ? Dans ce conte chinois, nous aborderons les moyens de mieux se comprendre, et les outils et méthodes pour mettre la qualité au premier plan.
Résumé
Pour la modification du code, nous utilisons tous des outils électroniques (IDEs, Git, Cucumber). Pour notre management visuel, nous avons encore des réticences : trop rigides, trop simpliste ou trop compliqués, ..ou encore difficile à intégrer ensemble. Et bien, je pense que ce sont des préjugés.
Fan d'outils, je vais vous aider à trouver votre ou vos outils Kanban.
Je présenterai intégration des outils Kanban entre eux et aussi vers d'autres outils de la chaine de Continuuous Delivery.
Description
Les freins à l'utilisation des outils électroniques et surtout leur intégration qui peut devenir un vrai casse tête.
Les nouvelles solutions qui méritent au moins de se reposer cette question d'utiliser des outils électroniques pour Kanban.
La flexibilité apporter par les API. Notamment la facilité d'étendre les fonctionnalités avec d'autres outils kanban/agiles préférés.
La possibilité de les adapter facilement pour accompagner les changements souhaités par l'équipe.
Déroulement
les étapes de la session : (à ce jour)
- Paradoxe de la multitude outils pour Kanban et des freins à leur adoption
- Des outils simples et qui vous guident dans leur utilisation, ca existe déjà
- Le choix épineux du bon outil : Matrice fonctionnalités, calcul ROI, ..
- On oublie parfois .. qu'il doit avant tout être agile (facile à adapter/changer/etendre/intégrer)
- L'intégration des outils c'est super simple ! Zapier, IFTTT
- Tellement simple que l'on peut même monter rapidement une usine à gaz
- Et si on essayait les faire eux aussi travailler en flux tiré ?
Quelle boite à outils pour une équipe qui veut travailler efficacement en suivant les principes agiles et DevOps.
Quels outils et pratiques utiliser et mettre en place.
Formation "Initiation Scrum" (sur 1 ou 2 jours)
- comprendre les principes agile
- découverte de SCRUM (les rôles, les livrables, les évènements)
- expérimenter par la pratique
L'adhésion grandissante à l'approche DevOps est un atout pour l’Agilité et s’impose comme une évolution logique à la transformation Agile. Un des facteurs clés du succès de cette approche est l’automatisation des processus de développement, et donc par le fait même, des tests.
Toutefois, si des tests sont automatisés, ils sont souvent loin des « user stories » qui sont pourtant la cible des Sprints pour livrer la valeur d'affaire. Les équipes prennent généralement en charge l’automatisation des tests unitaires et fonctionnels mais rarement celle des tests intégrés.
Afin de livrer une valeur d’affaire rapidement, il est nécessaire de tester les «user stories », donc d'effectuer des tests de bout-en-bout (end-to-end testing).
Voyez comment adapter vos stratégies de tests automatisé afin de garantir une amélioration continue de la qualité à travers votre organisation.
François Bonetto
Mise en place de bonnes pratiques (Scrum et php) au sein de projets existantsNicolas De Boose
Retour d'expérience technique et organisationnelle . Au menu :
- Passage à scrum: Les difficultés et solutions
- Code legacy: Du néan à l'industrialisation
Client complex, très ractif au marché, évolution constante des specs.
Incertitude certaine !
Presentation du socle technique Java open source Scub FoundationStéphane Traumat
Scub Foundation est un ensemble de frameworks, de conventions, d'outils et de procédures qui structurent les développeurs et leurs développements. Pour simplifier, c'est une plateforme qui permet l'industrialisation des projets de développement informatique.
Plus d'informations à http://www.scub-foundation.org
Objectifs du socle
- Ne pas réinventer la roue ! (Intégration d'Eclipse et des frameworks populaires comme hibernate, spring, gwt, JUnit…).
- Avoir des modèles de projets pour chaque type de projet mais avec des structures identiques.
- Avoir des tâches automatisées pour l'ensemble du cycle de vie du projet (compilation, packaging, test…).
- Développement SOA (intégration de la notion de noyau et du découplage Interface/implémentation).
- Gestion automatique des dépendances / librairies.
- Gérer les différents environnements (Test / Développement / Pré production / Production…).
Concrètement, notre socle technique offre au développeur un environnement de développement intégrant les meilleurs éléments Open Source (Eclipse, Maven, Spring, GWT…) ainsi que des modèles de projet.
Introduction aux spécifications exécutables (dit aussi atdd, bdd)Jean-Pierre Lambert
Comment s'assurer que tout le monde parle la même langue dans l'équipe ? Et ainsi éviter les retours de recette ?
Utiliser des spécifications exécutables, ou ses cousins le ATDD (Acceptance Test Driven Development) et le BDD (Behavior Driven Development), est un élément de réponse particulièrement pertinent. Cette méthode est également un point d'entrée puissant vers une stratégie d'automatisation des tests.
Dans cette présentation vous découvrirez les tenants et les aboutissants de cette méthode, et repartirez les poches remplies de conseils de mise en place.
Que faire si:
Votre transformation Agile a négligé les pratiques techniques.
Vous n'êtes pas alignés avec la livraison en continu pour DevOps.
Vous désirez établir une culture de code et d'expérimentation.
Comment faire adopter toutes ces pratiques ?
Pour répondre à ces questionnements, nous discuterons de leadership technique, de l'attitude et des responsabilités d'un tel leader en mode agile.
Karl Métivier
Agilité à budget fixe en phase d'avant-vente. Que proposer ?Frantz Degrigny
Je veux de l'agilité, mais un budget fixe ! Que proposer en phase d'avant-vente ?
Un retour d'expérience sous forme de "Lightning talk" présenté à l'Agile Tour Nantes 2016 :
- Introduire du BDD dans un projet pour un ministère, c'est possible ?
- Externaliser une équipe de réalisation en nearshore pour une grande banque, comment faire ?
- Réaliser une soutenance sur un format participatif et innovant, ça se fait ?
Nous parcourrons les différents principes suivants lors de nos retours d'expérience :
- Éduquer le client sur les principes, enjeux et contraintes des méthodes agiles
- Expliquer les impacts de l'agilité sur le déroulement et le prix du projet
- Comment adapter un contrat forfaitaire (Forfait simple, forfait au sprint, forfait au MVP, etc) ?
- Comment adapter les méthodes agiles (Un mélange de SCRUM, XP, franciser la méthodologie, etc ) ?
Finalement, nous terminerons sur les feedbacks de ces principales expériences, et particulièrement côté clients.
Cette présentation, importée de Prezi (d'où les coupures involontaires d'images durant la conversion), illustre le storyboard de mon parcours sur les réseaux sociaux en 2011 et énonce des règles d'or pour démarrer du point pied.
Présentation effectuée par Charles-André Bouchard, dans le cadre du cours LOG3000 conduit par Mathieu Lavallée, à Polytechnique, mardi le 22 novembre 2016.
Présentation donnée lors du Global Azure Bootcamp Paris 2018 sur la mise en place de solutions afin d'intégrer les projets data (bases de données, etl, BI...) à une chaine d'intégration et de déploiement continue.
A travers cette formation nous apprenons la gestion des projets digitaux de façon général avec un accent particulier sur la méthodologie en cascade.
Elle est destiné à toute personnes intéressée par le monde du numérique. Toute personne susceptible de commander un logiciel ( site internet, application mobile etc..) ou de donner une prestation.
GAB 2018 PARIS - Mettez un peu de CI/CD dans vos projets data! par Guillaume...AZUG FR
Intégration continue et déploiement continu ne sont pas réservés uniquement aux projets de développement.
Il est tout à fait possible d'appliquer ces principes aux projets data tel que vos bases de données, vos pipelines data factory ou vos modèles analysis services ; c'est ce que nous vous proposons de venir découvrir lors de cette session.
Il est loin le temps des wireframes et des kilomètres de spécifications fonctionnelles.
Inspiré des méthodes de Lean UX, nous avons souhaité tester et vérifier la faisabilité de la méthode du Rapid Prototyping pour une application tablette avec un de nos clients du milieu bancaire français.
Il s'agira de présenter la méthodologie employée et de partager un retour d'expérience concret sur ce qui nous a permit de réussir à concevoir et à développer, en 10 jours chez le client, un prototype cliquable d'application tablette avec une petite équipe constituée d'une UX, d'une UI designer, de développeurs front et d'un scrum master.
Nous verrons également la manière dont l'équipe a été constituée et ferons un état des lieux de ce qui a fonctionné ou non sur le projet.
La revue de code : agile, lean, indispensable !Lucian Precup
Présentation faite à Agile France en 2010 :
La revue de code : agile, lean, indispensable !
Alors que l’intégration continue ou les tests unitaires commencent à rentrer dans les "standards", la revue de code est souvent considérée comme optionnelle. Pourtant, les avantages d’une revue de code systématique sont multiples : détection des anomalies très tôt dans le cycle de développement, formation des membres de l’équipe, partage de la connaissance, meilleures solutions techniques par la conjonction des perspectives développeur/examinateur.
Cette présentation mettra en évidence les avantages de la revue du code en répondant aux idées reçues comme "la revue du code augmente la durée des développements", ou "nos développeurs sont très bons, ils n’ont pas besoin de revue de code" ou encore "il n’y a personne dans l’équipe qui puisse examiner mon code car je suis le seul à connaître Bash et Ant". En évoquant la revue de code dans l’univers open source, les différents moyens de la mettre en œuvre, ses compléments, les différents outils ; et terminant par une démonstration concrète en utilisant Eclipse, Bugzilla et Mylyn, cette présentation vous convaincra de mettre en place la revue de code systématique dans votre équipe sans attendre.
Déroulement :
1/ Avantages
2/ Idées reçues
3/ La revue de code dans l’univers open-source : de la revue du patch par le committeur aux procédures très élaborées comme celles de Mozilla Developer Center.
4/ Moyens de mise en œuvre : à partir de quelle taille des projets, par qui, comment, avant l’intégration ou après, ...
5/ Les compléments de la revue du code : analyse de la qualité du code, scripts pour les normes internes, ...
6/ Comparaison avec d’autres techniques : pair programming, ...
7/ Outils et intégration avec les autres outils de développement ou de gestion du cycle de vie (intégration continue, gestion des anomalies, ...)
8/ Démonstration des avantages sur un exemple concret en utilisant Eclipse, Bugzilla et Mylyn comme outils.
9/ Conclusion : comment la revue de code supporte une démarche agile et lean
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie TrudelAgile Montréal
Plusieurs s'engagent dans un projet DevOps avec espoir de voir la vélocité augmenter au fil du temps, remplissant la promesse légendaire de Scrum. La réalité est souvent tout autre, car opérer un système en production apporte son lot de surprises, et si l'on y ajoute de la dette technique et quelques années de vie utile, alors on peut facilement se retrouver dans une tempête parfaite. Voyons ensemble ces éléments qui viennent affecter notre précieuse vélocité.
Scrumday 2014 - Stratégie pour le projet de développement du nouveau produit ...French Scrum User Group
Reposant initialement sur un cocktail explosif, avec un Time To Market de 9 mois
seulement, un premier chiffrage de plus de 1000 jours et un manque de disponibilité
des métiers pour la rédaction du cahier des charges, le lancement du projet «
nouvelle GED » pour docapost DPS paraissait de plus en plus difficile à mettre en
oeuvre.
Un engagement fort du prestataire inscrit dans une démarche agile (Scrum/XP), nous a
permis de rendre possible la mise en oeuvre de la refonte en se concentrant sur le
produit et d’éviter les dérives contractuelles classiques du cycle en V .
Les difficultés rencontrées lors du déroulement du projet sont abordées, ainsi
que les succès rencontrés, notamment :
- Du pilotage par les risques
- De l’intérêt du proxy product owner
- De la manière dont le backlog a été constitué puis suivi
- Doubler la taille d’une équipe sans dégrader la productivité
- Equipe de développement focalisée sur les tâches de développement, les tâches
d’intégration, tests de charge et de sécurité étant réalisées par les
équipes de Docapost
- Les bienfaits du sprint 0, notamment pour qu’il soit porté à la connaissance du
sponsor des informations et définir la meilleure stratégie produit
La relecture de code : avant tout des pratiquesEric SIBER
Quelle est l'utilité de la relecture de code ? Bonnes pratiques, mauvaises pratiques, comment s'y prendre pour mener cette tâche à bien malgré les obstacles organisationnels ?
Cette session vise à sensibiliser les participants à la problématique de relecture de code. Souvent ce sont les outils qui font le buzz, reléguant les pratiques et leur adoption au second plan. Loin des effets whaou de la démo d'un outil, je souhaite vous sensibiliser au pourquoi et comment, tout en illustrant par des pratiques : de la plus élémentaire à la plus tendance. Des pistes seront données à l'audience pour mettre en place ou renforcer la démarche qualité sur le terrain, ainsi que les références aux outils qui s'inscrirons dans ces pratiques.
A l'image du premier principe du manifeste agile (Les individus et leurs interactions plus que les processus et les outils), la présentation sera donc largement tournée sur l'humain, le relationnel, elle ne détaille ni ne fait la promotion d'un processus ou d'un outil donné de relecture de code (qui seront néanmoins mentionnés).
Mockito - Design + tests par Brice DuteilNormandy JUG
rice Dutheil est indépendant, membre du groupe des Zindeps. Comiteur sur Mockito.Son blog est le “TheCoffeeWorkshop“. Son Twitter est @BriceDutheil.
Le design par le test
Le TDD est aujourd’hui une pratique reconnue pour permettre la production de code avec peu d’anomalies. Mais ce n’est pas le seul interet du TDD ; le design du code peut en etre le grand gagnant. Ces quelques slides vont essayer de donner un apercu des opportunites à saisir et des pieges à eviter ; Mockito inside.
Similaire à Agile Tour 2010 - Mise en place d'un projet agile (20)
1. Mise en place d'un projet agile
Laurent Deséchalliers
27 Octobre 2010
2. Plan
• Présentation Laurent Deséchalliers
• Pourquoi développer un logiciel ?
• Maquette, Logiciel et Produit
• Relation Client/Équipe de dév.
• Production et usine logicielle
3. But de cette conférence
Retour d'expérience sur mise en place d'un
projet selon l'esprit agile
structure naissante et de petite taille
• Pas une conférence sur les différentes
méthodologies agiles
4. Pourquoi les méthodologies agiles
• Constat sur les projets logiciels « classiques »
o Projets échouent
o Planning dérapent
o Logiciels livrés sont inadaptés
➔
Trouver une méthode corrigeant ces problèmes
5. Pourquoi les méthodologies agiles
ButStopper le
« tir au canon »
Stopper le
« tir au canon »
Éviter le
« but idéalisé »
Ne pas dépenser
une énergie folle
Management
Technique
6. Pourquoi les méthodologies agiles
• Les valeurs du manifeste agile
o L’interaction avec les personnes
• plutôt que les processus et les outils.
o Un produit opérationnel
• plutôt qu’une documentation pléthorique.
o La collaboration avec le client
• plutôt que la négociation de contrat.
o La réactivité face au changement
• plutôt que le suivi d'un plan.
7. Pourquoi les méthodologies agiles
• Les valeurs du manifeste agile
o Répondre aux besoins (changeants) du client en
produisant - en continu - un logiciel de qualité.
• Adapté aux :
o Start-up
o Produits innovants
o Concurrence forte
9. Laurent Deséchalliers
• Mise en place, en partant de zéro
o méthodologies (agiles)
o Infrastructure hardware/logiciel de dev.
• Forge, Poste travail, réseau...
o recrutement équipe
➔
Vision, dès leur naissance, de toutes les étapes
de projets
11. Maquette, Logiciel, Produit
• Logiciel : lourdeur synchro ressources pour
livrable..
o Forge : Build, repo,TAG svn, chanlog...
o Test : Build, recette...
o MAJ Doc. : tech, commercial, mkt, site web, dossier
presse...
o MAJ : Packaging, logo, codes barres...
o ...
12. Maquette, Logiciel, Produit
• Logiciel pas forcément adapté aux
démonstrations commerciales
o Lourdeur initialisation
• Configuration par défaut
o Lourdeur remise à zéro
• Remise à zéro en quelques secondes
o Lourdeur infrastructure
• Serveur, AP wifi, routeur, SGBD
• Lourdeur synchro ressources pour livrable...
13. Maquette, Logiciel, Produit
• Pensez une démo (maquette, adaptation du
logiciel) dès le départ
o Ré-initialisable vite et simplement
o Transportable (laptop) simplement
o Gérant plusieurs configurations (clients)
• Machines virtuelles par exemple
14. Maquette, Logiciel, Produit
• Cycle logiciel/maquette
Logiciel
Logiciel Maquette
N
N+1
N+2
FeedBack
- Interne
- prospects
D
é
m
o
C
o
n
t
i
n
u
e
15. Maquette, Logiciel, Produit
• Produit
o Logiciel
• War java
• ServeurWeb Java
• Database
• ...
o Infra
• Serveur
• APWifi
• Câbles à gogo
• ...
16. Maquette, Logiciel, Produit
• Maquette
o Full JavaScript
o DataBase : fichier Json
o Multi-configuration client
• Opposé du logiciel
o « Resetable » à volonté
o Juste l'appareil
18. Relation Client/Équipe de dév
• La guerre/isolation management/tekos
o Réalité dans de nombreuses entreprises
o Communiquer en permanence
o S'opposer à la « politique des tranchées » :
• Chacun dans son coin
o A l'opposé, s'opposer aux réunions « marathon » qui
ne servent à rien
o
19. Relation Client/Équipe de dév
• La guerre/isolation management/tekos
o Réunion tous les matins pour les techniques
o Ce que j'ai fais hier
o Les problèmes rencontrés
o Ce que je vais faire aujourd'hui
• Début journée,
• Heure fixe,
• Pas plus de 10 minutes
20. Relation Client/Équipe de dév
Source : http://runningagile.files.wordpress.com/2008/01/scrum_board.jpg?w=500
21. Relation Client/Équipe de dév
• La guerre/isolation management/tekos
o Réunion toute les semaines
techniques/management
o Avancement des techniques
o Question du management aux techniques pour les
livrables futurs
• Management reste à disposition des techniques, à tout
moment, pour questions sur le développement actuel
• Le management n'interrompt pas les techniques à
longueur de journée
o réunion hebdomadaire
22. Relation Client/Équipe de dév
• La guerre/isolation management/tekos
o Réunion à chaque livrable (2 4 semaines)→
• Présentation du livrable par technique
• Véritable test du livrable par management
o Validation
• Clôture
o Départ nouveau livrable
23. Relation Client/Équipe de dév
• Les spécifications
o L'équipe de développement ne peut « deviner » les
besoins du client
o Le client doit spécifier ses besoins
• Éviter les incompréhensions
24. Relation Client/Équipe de dév
• Les spécifications
o Le management
• « Je sais pas faire de cahier des charges »
• « Je suis pas spécialiste du logiciel »
o L'équipe technique
• « Je ne connais pas le métier du client »
• « Je peux pas me substituer au client pour les choix
métiers »
25. Relation Client/Équipe de dév
• Les spécifications
o Trouver une méthodologie
• Souple mais formelle
• Rapide
• Ne figeant pas les spécifications dans le marbre
• Conciliant management et technique
26. Relation Client/Équipe de dév
• Les spécifications
o MockUp
• Rapide
• « Accessible » au
management
• Convivial
o Technique ET
management
(Image source OctoTechnologie)
28. Relation Client/Équipe de dév
• Les spécifications
o Scénarii
• Description avec des :
o Mots : Si/alors/oui/non/OK:KO...
o Puces indentées
Très « wikisable »
29. Relation Client/Équipe de dév
• Les spécifications
o Scénarii
• Management oublie souvent (pour un scénario)
o Les cas KO
o Les acteurs « non vendeur »
Pensent au Front office car ce qu'ils « vendent »→
Oublient BackOffice
Solution passer tous les acteurs sur un scénario→
31. Production et usine logicielle
• Pourquoi une forge ?
• Quelle forge minimaliste ?
• Le poste de travail
• Comment gérer la montée en puissance ?
32. Production et usine logicielle
• Pourquoi une forge ?
o Démultiplier sa productivité (et sa qualité) par le biais
d'outils
o Penser son métier au lieu de le subir
➔
Agilité : penser son métier et non le subir
➔
Outil est un démultiplicateur
33. Production et usine logicielle
• Quelle forge minimaliste ?
o Bugtrack
• Un logiciel possède forcément des bugs
• évite de prendre de mauvaises habitudes
• presque impossible à imposer si on habitue le
management au report à l'arrache et sans rigueur
• L'agilité, c'est aussi une certaine rigueur
34. Production et usine logicielle
• Quelle forge minimaliste ?
o Gestionnaire de version
• Mémoire » de l'évolution du logiciel
• Mémoire des livrable
• Test de régression aisée
• ....
➔
L'outil indispensable pour un projet (agile ou non)
35. Production et usine logicielle
• Quelle forge minimaliste ?
o Wiki
• Souplesse de documentation
o Système « rugueux »
Evite le « blabla »
Se concentre sur l'essence du besoin
• Traçabilité totale sans effort
• Moteur de recherche intégré
• Suivi, sans efforts, des évolutions des documents
36. Production et usine logicielle
• Quelle forge minimaliste ?
o Outil de déploiement
• Tester en permanence en environnement de pré-prod
• Gain de temps
o Projet actuel
Déploiement automatisé : 22 sec
Déploiement manuel : 10 minutes + fatigue intellectuelle +
erreur possible
37. Production et usine logicielle
• Le poste de travail
« Do you use the best tools
money can buy? »
Joel on software test
38. Production et usine logicielle
• Le poste de
travail
• Outil de
productivité
et de qualité
39. Production et usine logicielle
• Le poste de travail
o Investir temps dans le poste de travail
• Parfois avec des outils très simples
o Gain productivité / aisance au travail immédiat
40. Production et usine logicielle
• Le poste de travail
o Investir temps dans le poste de travail
PC dev
Forge
(repo)
Apliance
(cible)
Pilotage
Reporting
42. Conclusion
• Commencer son projet avec des bases solides
• Penser son projet comme un produit à vendre
• Faire communiquer management et techniques
• Aimer son métier et faire preuve de courage