Voici de mon côté, une liste en vrac de questions qui me serviront : Quelles sont les dates pour les projets gérés cités en bas ? Quelle a été l’historique de la R&D W4 vis-à-vis des méthodes de gestion de projet ? Dev classique en V avec faible capacité à rédiger des specs : car au fur et à mesure. Produit technique pour d’autres dév. 2005 : pb qualité, des spécialistes, mode XP pour transferts de compétences. Promesses XP : multidisciplinarité. Recrutement Laurent BOSSAVIC : connu pour XP en France. Implication forte, sans concession XP va plus loin : pratiques d’engineering. 13 règles. Pb : coût pour une société petite taille : deux personnes à temps plein … Scrum : bonnes pratiques mais avec liberté. Indicateurs de suivi. Idem pour les produis qui tournent sur nos produits. Ce qu’on a maintenu : Sur le moteur : dev puis test. On peut mettre des individus nouveaux. Mode Test Driven Dev. Pondération. Pas sur les IHM … Plus de pair programming même pour le moteur. Avec Scrum : mode d orga permet de produire rapidement. XP convaincu methodes agile et Scrum : gestion plus légère pour prendre en compte de manière agile les fonctionnalités qui émergent. On respecte 11 regles. Quelles sont les méthodes ou référentiels au sens large utilisée par W4 ? (gestion de projet, de risques …) Risque : sur XP trois niveau de risque (1 à 3). 3 = high risk. Sur Scrum : pondération complexité Suite de Fibonacci. Pourquoi Scrum ? Origine du choix, cheminement, réflexion qui a abouti à Scrum ? Pour les projets de définition du CdCharges. Confiance etc … Pvr décisonnaire. Avocat chez le client. Sinon méthode V : Ex : Appel d’offre Différence et complémentarité avec méthode XP ? Difficultés rencontrées avec Scrum ? Éléments implémentés naturellement ? Pour des gens qui souhaitent évoluer pour gérer une équipe : CdP par exemple … Points négatifs / Scrum ? Apports principaux et secondaires ? Forte présence client. Itération peut modifier les US. Prix du cahier des charges dispersé tout le long du projet. Le dialogue avec le client va permettre de comprendre ce qui est faisable, couteux et réalisable. Difficultés : éducation client. Veut un CdP qui ne soit pas eux. Risque méthode agile : équipe collectivement responsable c pas moi c lui ! Gestion d equipe du Scrum master. Equipe equilibrée. Motivation et équipe accepte de le monter en compétence. Equipe Agile 1 à 6 personnes. Emergence des fonctionalités : ca arrive petit à petit. Tu donnes une vision car le détail c au fur et à mesure. Éléments remis en cause ? RAS Quelle est la taille des projets dans le scope de Scrum ? Pages Jaunes : 1 an sur 5 dev, 24 sprints. Spécificités de l’implémentation Scrum chez W4 ? Valoriser le client : le product owner. Methode tradi : le cdp n existe pas dans Scrum. Non agile : tu te plantes un an plus tard et les dégats sont énormes. Alors qu’avec Scrum au bout de 2 ou 3 itérations ils décidera si ok ou nok. Meilleure maitrise du risque. La méthode Agile et outil BF : combinaison gagnante La valeur métier visuelle doit être produite rapidement. Contrairement à du Java on utilise des modèles. Avocat de la méthode Agile.
W4 est une société qui a plus de 15 ans d’expérience dans le domaine de l’édition logicielle, D’envergure internationale, W4 propose en particulier une solution de développement agile BUSINESS FIRST. L’équipe R&D, le cœur même de l’entreprise, a du se structurer afin de répondre avec efficacité aux défis, nombreux, qui jalonnent les voies du développement logiciel. 30% du CA consacré c’est bien, mieux même que la moyenne dans le domaine de l’édition logiciel (en France) mais encore faut-il savoir comment optimiser cet investissement. L’un des axes majeur est évidemment la méthode employée pour gérer ces projets R&D : gestion de projet classique ? méthodes Agiles ? Quelle méthode Agile ? L’efficacité rime avec pragmatisme dans de nombreux domaines … y compris le nôtre. Notre choix s’est porté sur Scrum … Réf. web « Scrum doesn’t prescribe any engineering practices; XP does. I love the XP engineering practices, particularly things like test-driven development, the focus on automated testing, pair programming, simple design, refactoring, and so on »
C’est au nom de ce pragmatisme que le besoin d’homogénéité s’est exprimé rapidement : « Nous développons de manière Agile, un outil Agile, sur une plateforme Agile »
Le manifeste agile commence ainsi : nous avons trouvé une voie améliorant le développement logiciel en réalisant ce travail et en aidant les autres à le faire. De ce fait nous avons déduit des valeurs communes
Il existe des outils mais vraiment pas pratiques. Le msproject des methodes agiles n’existent pas -> difficultés d’utilisation
Léger: Facilement installable sans surcout de techno (dispo aussi dans le cloud) Accessible: L’utilisateur ne doit pas lire 50 bouquins pour pouvoir l’utiliser (même si nous pourrions l’aider cf.pages jaunes) En BF: pour légitimer encore plus notre engagement dans cette pratique mais aussi pour valider l’adaptation de notre techno
Il y a des tas de mécanismes à mettre en ouevre pour y arriver, cela sera demontré au fur est a mesure des itérations
Il y a des tas de mécanismes à mettre en ouevre pour y arriver, cela sera demontré au fur est a mesure des itérations
burnup.png : suivi du projet grâce aux burnups creation_us.png : tous les éléments définis par scrum pour créer une US sont là distribution.png : si tu veux l'utiliser : pour avoir un aperçu de l'organisation des us du projet stand_up.png : Fenêtre permettant de faire le stand_up chaque matin summary_sprint.png : résumé de la composition du sprint vue_en_arbre.png : vue pratique pour voir comment est constitué le backlog
burnup.png : suivi du projet grâce aux burnups creation_us.png : tous les éléments définis par scrum pour créer une US sont là distribution.png : si tu veux l'utiliser : pour avoir un aperçu de l'organisation des us du projet stand_up.png : Fenêtre permettant de faire le stand_up chaque matin summary_sprint.png : résumé de la composition du sprint vue_en_arbre.png : vue pratique pour voir comment est constitué le backlog
burnup.png : suivi du projet grâce aux burnups creation_us.png : tous les éléments définis par scrum pour créer une US sont là distribution.png : si tu veux l'utiliser : pour avoir un aperçu de l'organisation des us du projet stand_up.png : Fenêtre permettant de faire le stand_up chaque matin summary_sprint.png : résumé de la composition du sprint vue_en_arbre.png : vue pratique pour voir comment est constitué le backlog
burnup.png : suivi du projet grâce aux burnups creation_us.png : tous les éléments définis par scrum pour créer une US sont là distribution.png : si tu veux l'utiliser : pour avoir un aperçu de l'organisation des us du projet stand_up.png : Fenêtre permettant de faire le stand_up chaque matin summary_sprint.png : résumé de la composition du sprint vue_en_arbre.png : vue pratique pour voir comment est constitué le backlog
burnup.png : suivi du projet grâce aux burnups creation_us.png : tous les éléments définis par scrum pour créer une US sont là distribution.png : si tu veux l'utiliser : pour avoir un aperçu de l'organisation des us du projet stand_up.png : Fenêtre permettant de faire le stand_up chaque matin summary_sprint.png : résumé de la composition du sprint vue_en_arbre.png : vue pratique pour voir comment est constitué le backlog
Les Métiers vont penser rapide, facilement modifiable, bref tout ce que montre les av-ventes Les développeurs vont penser application sur modèle (generation ou non de code) avec nombreux connecteurs etc Les experts SI/ partenaires / chef de projet vont associer ce mot à Méthode agile : D’autant plus vrai que nos présentations sont subtilement truffées de tous ces concepts: Exemple slides apres