Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Donnez le pouvoir de build à votre PO

Donnez le pouvoir de build à votre PO

Mathieu Hausherr

June 18, 2013
Tweet

More Decks by Mathieu Hausherr

Other Decks in Technology

Transcript

  1. 1 Tél : +33 (0)1 58 56 10 00 Fax

    : +33 (0)1 58 56 10 01 www.octo.com © OCTO 2012 50, avenue des Champs-Elysées 75008 Paris - FRANCE 18/06/2013 Donnez le pouvoir de build à votre PO Droidcon Paris 2013
  2. 3 Retour d’expérience sur un projet d’entreprise !  7000 téléphones

    Android !   Jusqu’à 17 développeurs !  5 versions majeures de l’application en 1 an
  3. 4 ! Répondre aux vrais besoins utilisateurs !   Rencontre

    directe avec les utilisateurs finaux ! Des besoins qui évoluent rapidement !   Répondre aux changements ! Applications métier utilisées quotidiennement par des professionnels !   Haut niveau de qualité requis ! Emprunte à plusieurs méthodes : ! Extreme programming (TDD, pair programming, revue de code, refactoring) !   SCRUM (rôles, rituels, scrumboard, …) Pourquoi l’agilité?
  4. 5 Qui est le Product Owner? ! Il porte la

    vision du produit ! Il priorise et re-priorise son backlog ! Il connait son client ! Il est un acteur dans la rédaction des spécifications ! Il peut refuser une fonctionnalité !   C’est lui qui décide que c'est bien DONE ! Il fait partie de l’équipe
  5. 6 ! La proximité et la confiance ne font pas

    tout ! Pour valider les fonctionnalités développées, le PO doit pouvoir tester les applications quand il le souhaite !   Délicat de solliciter l’équipe à chaque fois Nos Douleurs Désolé de te déranger pour la 11e fois ce matin, tu peux me refaire un APK stp…?
  6. 7 ! Être certain de vos commits !   Tous

    les commits compilent ! Ne pas faire de régression !   Tester sur de vrais devices avant de commiter ! Tester automatiquement !   Test unitaires ! Robolectric !   Test d’interfaces !   On a testé Robotium Les prérequis
  7. 8 Monter une Usine de Développement ! Standard du monde

    Java ! Utilisation de Jenkins !   Script de compilation en ANT plutôt que Maven ou Gradle ! Comment aller plus loin? !   Tout le monde sur le projet utilise cet outil
  8. 11 Besoin ! Interagir avec un environnement serveur complexe !

    Dev / Qualif / Preprod / Prod !   Formation des utilisateurs Solution ! Fichier de config dans res/raw généré par Ant Config Serveur / Mode formation
  9. 14 Besoin ! Simplifier au maximum la distribution !  

    On le faisait déjà à la main Solution ! APK en pièce jointe d’un email ! Keep It Simple and Stupid Envoi par Mail
  10. 18 Besoin ! Reconstruire la version livrée: !   Aux

    métiers !   Aux utilisateurs !   Pilotes !   Tout le monde Solution ! Se baser sur les tags SVN Version du code
  11. 20 ! Possibilité pour le PO de builder seul et

    à n’importe quel moment !   Libère du temps à l’équipe de dev !   Moins dérangés, plus concentrés !   Qualité du code développé augmente !   Plus grande réactivité pour valider les User Stories développées !   Les anomalies sont détectées/corrigées au fur et à mesure !   Qualité du produit augmente ! Paramètres de build donnent du confort (envoi de mail, choix de l’environnement, ….) !   Gain de temps pour le PO ! Réactivité face au client, livraisons fréquentes et tracées !   Améliore la relation métier / DSI ~500 Builds depuis un an Résultats
  12. 26 ! En un clic l’utilisateur a sa nouvelle version

    sur son téléphone ! Interconnexion avec le store d’entreprise ! … Mais on n’est pas encore prêt !   Le test manuel reste rassurant et indispensable Et si on allait jusqu’au job de livraison?
  13. 27 ! Chaque commit est envoyé en prod ! Les

    géants du web le font ! Github !   Facebook ! On n’en est pas là … !   Sur mobile c’est plus compliqué !   Besoin de validation Métier ! Même dans une grande structure institutionnelle on arrive à s’en approcher Ou même au Continuous delivery?
  14. 28