Tag Archives: scrum

18 Septembre – Sophia Antipolis – Méthodes Agiles

3 sept

de 14h00 à 17h30 aux Espaces Antipolis, 300 route des Crêtes

Apparues au début des années 2000, les Méthodes Agiles rencontrent aujourd’hui un réel succès et se positionnent comme des réponses opérationnelles. Cette conférence vous présentera les enjeux, les valeurs et les principales pratiques de l’offre Agile.

Les points clés de la conférence

               Agile 2Une nouvelle organisation du travail: De nouveaux leaders sur les projets : le client, le coach, l’équipe de développement.

               La démarche: Une démarche itérative et incrémentale. Une démarche transparente et participative.

               Comment formaliser les exigences ? Favoriser le point de vue de l’utilisateur. Apprécier la priorité et les valeurs métiers associées aux exigences. Un feedback constant pour le client et pour l’équipe. Une maîtrise du changement.

               Qualité du travail de l’équipe Agile: Un projet piloté par les tests.Une intégration en continue, une conception émergente.

               L’apprentissage: Favoriser la capitalisation. Des rétrospectives. Le rôle déterminant du coach (ScrumMaster). L’agile Dojo.

               La mise en œuvre: Du cadre agile à un processus détaillé adapté à l’entreprise et au projet. Intégrer la sous-traitance.

Cette conférence sera animée par Jean Hugues, directeur associé de la société de conseil DELF. Il mène conjointement des activités de production et de recherche sur les méthodes de conception et sur la conduite de projet. En plus d’animer des conférences et séminaires haut-de-gamme, il forme aux Méthodes Agiles. Il est également auteur d’ouvrages spécialisés.

s’inscrire

August 14 – Webinar – Dealing with Technical Debt: Avoiding Technical Bankruptcy

7 août

A free monthly webcast by Scrum.org Professional Scrum Trainers addressing common challenges faced by the software profession.

Scrum and Agile Webcasts

Scrum and Agile Webcasts

with Mark Noneman on August 14, 2014 10am-11am EST 16:00 CET/FRANCE

The phrase “technical debt” has become a commonly used phrase in software development.

technical debtTechnical debit is analogous to financial debt; build up too much and you’ll start paying more in “interest” and “principle” than you can invest in future value. This webinar will discuss what technical debt is, what causes it, and how to deal with it. Both management and engineering techniques in an agile development environment will be reviewed.

These sessions are broadcast live, completely free, and available to anyone around the world – though space in each session is limited!

SAVE MY SPOT

Réussir des "standup" efficaces autour du tableau Kanban (repost)

4 août

Effective Standups around Kanban Board

http://blog.brodzinski.com/2011/12/effective-standups.html par Pawel Brodzinski

stand-up meetingsVous pouvez entendre ici et là que Kanban s’adapte plutôt bien aux grandes tailles. En réalité, un des problèmes de Scrum auquel je pense on ne s’est pas soigneusement attaqué, est que faire dans les projets qui nécessitent davantage de personnes qu’une unique équipe Scrum puisse rassembler. L’un des problèmes qui émerge très rapidement quand l’équipe Scrum grandit est la réunion « standup ».

Comme vous passez à travers l’équipe qui grossit avec vos trois questions standards cela nécessite naturellement de plus en plus de temps. Bientôt cela peut devenir un problème que de tenir dans le bref temps imparti pour de telles réunions.

Quand l’équipe adopte Kanban, elle commence d’habitude avec un standup inchangé. Cependant cela signifie que, à un certain point, ils font face au même problème que les équipes Scrum :  15 minutes ne sont désormais plus suffisantes.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Récemment, Jorn Hunskaar a partagé une telle histoire sur son blog. Il m’a incité à combiner une suite d’idées en une seule réponse qui peut servir de un guide sur comment améliorer les standups autour du tableau Kanban.

Au lieu d’exécuter le typique tour de table avec des réponses sur ce qui s’est produit hier, ce qui va être réalisé aujourd’hui et quels sont les problèmes, vous pouvez essayer de reconcevoir le modèle que vous suivez pour le standup.

comment améliorer les standups autour du tableau Kanban

  • kanban boardD’abord, passez à travers tous les points bloquants (s’il y en a). Ceux-ci sont certainement vos points de douleur actuels. Cela signifie que vous voulez certainement investir une partie du précieux temps de standup sur ces points bloquants. Cela est évident.
  • Deuxièmement, discutez des items urgents ou à expédier (de nouveau, s’il y en a). C’est le travail prioritaire du point de vue de l’équipe toute entière. C’est quelque chose que vous devez vraiment faire sous peine de retarder d’autres taches. De nouveau, ceci est une chose dans laquelle cela vaut la peine d’investir de rares ressources.
  • Troisièmement, passez en revue les items qui n’ont pas progressé depuis le dernier standup. Ceux-ci sont les points qui peuvent être à risque. Peut-être ne devaient-ils pas progresser mais dans ce cas ce serait revu rapidement, peu de discussion nécessaire. Autrement, cela vaut la peine d’avoir une brève analyse ce qui a empêché ces points d’avancer. À propos, cela signifie que vous devriez avoir un mécanisme pour marquer visuellement les fiches qui ne se déplacent pas, ce qui est souvent délicat.
  • Quatrièmement, passez à travers tout le reste. Encore un conseil : Vous pouvez avoir discuté les sujets selon  leur classe de service par priorités. Autrement dit, vous commencez par la classe la plus hautement prioritaire de service (des bogues, des fonctionnalités critiques ou autre) et discutez tous les items de cette classe de service. Puis vous vous déplacez sur une autre. Bien, au moins cela peut fonctionner tant est que vous puissiez dire quelle classe de service est plus importante qu’une autre.

Encore une règle raisonnable : dans chacun de ces groupes, utilisez le tableau Kanban de la droite vers la gauche. Cela indique que plus un article est proche d’être fini plus vous voulez en discuter pour le compléter, apportant ainsi de la valeur à vos utilisateurs, clients et parties prenantes.

OK, jusqu’à ce point il y a en fait peu de différences : vous passez toujours en revue chaque item de travail qui est sur le tableau. Il y a un focus différent sur les problèmes et vous pouvez passer sur les items évidents de travail complété, mais tout de même, toujours beaucoup de contenu à revoir.

deadlineCependant, étant donné que vous venez de trier les sujets à discuter selon leur priorité, vous pouvez utiliser un truc simple et stopper la discussion quand le temps de la réunion s’est écoulé, peu importe si vous avez pu ou pas couvrir toutes les choses. Cela signifie que vous avez probablement couvert tous les items des trois premiers groupes et certainement tous ceux des deux premiers, indépendamment du reste qui exige une moindre part de discussion ou aucune discussion du tout.

Cela signifie aussi que, dans un bon jour, vous pouvez couvrir tous les points, ou davantage de choses, et c’est parfait. Ce dont vous avez essentiellement besoin est de vous assurer que la substance la plus importante ne va pas passer inaperçue.

Un pas de plus serait de sauter une discussion sur un groupe ou sous-groupe spécifique  d’items, comme par exemple une classe spécifique de service, quand vous voyez que cela n’ajoute pas vraiment de valeur. Si vous n’êtes pas certain,  essayez de les couvrir pendant les standups et voyez quel résultat vous obtenez.  Vous pourrez alors commencer à essayer d’autres choses avec l’agenda de la réunion.

Idéalement, après quelque temps, vous finirez par discuter seulement des choses importantes, disons, les points bloquants, les items à expédier et bloqués, et peut-être d’autres qui sont amenés par n’importe quel membre de l’équipe pour une raison importante et sortent du travail habituel qui n’a pas besoin de plus d’attention qu’une confirmation silencieuse que tout est parfaitement en ordre.

ne soyez pas un zombie de Scrum

15 juil

ZombieDon’t be a Scrum Zombie

http://www.pmhut.com/dont-be-a-scrum-zombie par Marc Löffler

Toute équipe de Scrum connait les 3 questions les plus célèbres posées chaque jour pendant le « Daily Scrum » :

  • Qu’avez-vous réalisé hier ?
  • Que ferez-vous aujourd’hui ?
  • Quels sont les obstacles ?

Pour certaines équipes cette réunion est juste un devoir ennuyeux et à cause de cela on répond à ces questions sans passion. Une chose que j’ai observée dans les dernières semaines et mois est combien ces questions ont des poids différents. On répond à la première question sur le dernier jour de travail en grand détail tandis que la réponse à la deuxième question est très courte et si on répond la troisième question c’est seulement pour déclarer qu’il n’y a actuellement aucun problème. Donc la plus grande partie de la réunion est une discussion sur le passé. L’avenir et les obstacles sont tout simplement ignorés. A mon humble avis, ceci est un gros problème qui devrait être évité.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Qu’avez-vous réalisé hier ?

Image courtesy of Stuart Miles / FreeDigitalPhotos.net

Image courtesy of Stuart Miles / FreeDigitalPhotos.net

La réponse à cette question ne doit pas être une liste détaillée de toutes les tâches vous avez fait hier. De plus, il ne s’agit de découvrir qui a fini le grand nombre de tâches et était apparemment le membre de l’équipe le plus travailleur. Le point n’est pas de créer un rapport pour le ScrumMaster, le Propriétaire de Produit ou une partie prenante.

Au lieu de cela la réponse devrait seulement contenir les informations qui sont utiles à tous les membres de l’équipe et importantes pour le reste du sprint. De cette façon les informations sont intéressantes et de valeur pour tous les membres de l’équipe, tout le monde écoute et en bénéficie.

Que ferez-vous aujourd’hui ?

Today is a good daySouvent on répond cette question avec un simple "je continuerai à travailler sur …". Ceci n’a aucun rapport avec une approche tactique. Chaque membre de l’équipe devrait attentivement observer la réunion et considérer quelle est l’étape suivante raisonnable pour supporter l’équipe dans l’atteinte du but du sprint. En particulier, les membres de nouvelles équipes de Scrum ont tendance à penser à leurs propres tâches au lieu de penser et travailler comme une équipe.

Il n’est pas important de commencer à travailler sur toutes les tâches de l’Arriéré de Sprint, mais bosser ensemble sur les tâches une par une. Au mieux deux membres de l’équipe travaillent simultanément sur une tâche en utilisant des techniques comme la programmation de pairs. C’est pourquoi le Daily Scrum est aussi l’endroit parfait pour décider qui s’appariera avec qui. Le Daily Scrum est une petite réunion de planification et c’est pourquoi vous devriez l’utiliser comme tel.

Quels sont les obstacles ?

Cheval, ObstacleDe façon intéressante, ceci est la question la plus sans réponse des trois. À la fin, tous les problèmes cachés surgissent dans la Rétrospective de Sprint bien qu’ils auraient pu être résolus pendant le sprint. Mais pour pouvoir les résoudre quelqu’un doit les mentionner.

Les raisons de ce comportement sont variées. Quelques membres de l’équipe croient que leur ScrumMaster n’est pas capable de résoudre leur problème. Les autres membres de l’équipe sont habitués à résoudre leurs problèmes tout seuls. Mais ces problèmes et obstacles cachés sont souvent ceux qui sont la cause d’un but de sprint manqué. C’est seulement si tout le monde connaît tous les obstacles que l’équipe peut les balayer du chemin vers le but de sprint.

Ne vous comportez donc pas comme un zombie de Scrum. Le Daily Scrum Quotidien n’est pas un devoir ennuyeux, mais une chance de réussir la prochaine étape vers le but du sprint.
Partenaire de DantotsuPM

Partenaire de DantotsuPM

 

May 6 – Webinar (PMI) – Project Management: An Essential Ingredient for Innovation

30 avr

12 May • 6pm CET

"Project Management: An Essential Ingredient for Innovation"

Presenters: Winnie Liem, PMP and Dr. Bill Brantley

Innovation Road Sign with dramatic clouds and sky.Project management is an essential ingredient to innovation. It is only with great project management that you can bring an innovative idea to action. However, innovation requires a different type of project management than the standard multi-year government project.

In this webinar, you will learn:

  • How innovative project management differs from traditional project management
  • Tools to leverage agile project management and human centered design
  • How to treat change as a variable and learn from the scrums
  • Concrete tips and tricks from those doing it right and bringing innovation to their agency.

5 des meilleures techniques à piquer au management de projet

16 avr

5 of the Best Project Management Techniques to Steal

http://pmtips.net/5-project-management-techniques-steal par Stefan

Comme Stephen P. MacMillan, ex-PDG de Stryker et membre du conseil de MDSave le remarquait: "Les sociétés peuvent libérer de la valeur en changeant comment elles interagissent."

Cette citation est également applicable à votre petite équipe projet qu’elle l’est dans les Grandes sociétés que dirige MacMillan. Changer comment vous interagissez peut avoir des effets spectaculaires sur votre capacité à terminer des projets. Appliquer un nouvel outil de conduite de projet, comme Scrum, Kanban, ou GTD, libère souvent votre équipe pour qu’elle se concentre sur les tâches à réaliser et vous aide à mieux gérer votre flux de travail.

Le problème est que ces certifications officielles sont souvent onéreuses. Une formation de "ScrumMaster Certifié", par exemple, coûte de €1,000-2,000 et un unique séminaire « Getting Things Done » approche les €500. Avant de vous inscrire pour ces cours, faites une revue rapide de chaque technique de management de projet et subtilisez les meilleures pratiques.

Empruntez le "une chose à la fois" de Kanban

kanban boardVous n’avez pas besoin d’être un expert Kanban pour comprendre la valeur d’un tableau Kanban. Simplement dit: un tableau Kanban mène un projet de l’idée au développement puis à l’exécution, selon la théorie qu’une personne peut vraiment faire une seule chose à un moment donné. Des Post-it™ sont utilisés pour déplacer les composants du projet à travers les étapes de développement et c’est une façon visuelle de voir exactement ce sur quoi vos équipes travaillent à n’importe quel moment donné.

Regardez les graphiques et descriptions sur “Kanban Development Oversimplified” (Kanban Développement un peu trop simplifié) et créez un rapide Graphique Kanban pour votre situation.

Les chances sont grandes que vous puissiez immédiatement voir où en estv otre projet, quelles tâches peuvent légitimement être entamées tout de suite et lesquelles doivent attendre dans la file d’attente jusqu’à ce que d’autres tâches soient finies.

Volez à Scrum le principe des réunions courtes

stand-up meetingsVous n’avez pas à emprunter le langage des poulets et cochons pour parler Scrum. En fait, tout que vous devez vraiment faire est de subtiliser une bonne pratique de Scrum : les réunions courtes, debout qui sont tenues chaque matin.

Rappelez-vous les règles : les réunions sont Courtes. Tout le monde doit être debout. Ce n’est pas le moment de discuter; c’est un simple temps de mises à jour des statuts des tâches pour le projet.

Tout le monde présente 3 choses :
  1. Le Statut de sa tâche Projet
  2. Ce que la personne espère compléter aujourd’hui
  3. Ce qui pourrait l’empêcher de finir aujourd’hui

Puis, vos équipes vont travailler. C’est tout. Aucun cours de Scrum n’est nécessaire pour faire ceci.

Faire les choses avec capture-et-revue

David Allen « Getting Things Done » est un excellent système pour suivre et manager des tâches, mais ses nombreuses règles peuvent intimider les personnes les plus cartésiennes. Résolvez le problème en ne prenant que la meilleure façon de faire faire des choses : capturez chacun des engagements en un unique emplacement et passez en revue tous ces engagements chaque semaine.

getting things done

Le livre

Oui, ceci est un peu plus difficile qu’il n’y paraît, mais il est assez facile d’emmener partout votre bloc note ou votre smart phone.

Chaque fois que vous êtes à une réunion et que quelqu’un vous demande de faire des recherches sur quelque chose, ou que vous êtes à votre bureau et recevez un courrier électronique vous demandant de contribuer à une présentation, ajoutez-le à votre Liste Unique. Puis, une fois par semaine, passez la liste en revue. Tant que vous capturez et passez tout en revue, vous n’oublierez pas de tâche. Enseignez cette méthode à vos équipes et ils n’oublieront rien non plus.

Atteignez votre but en identifiant les goulots d’étranglement

Eli Goldratt - The Goal

Voir le livre

Vous rappelez-vous du livre de M. Goldratt « The Goal » ? Comme David Allen, la théorie des contraintes de Goldratt comporte beaucoup de règles, donc nous nous concentrerons seulement sur la plus importante règle de toutes : mettez des ressources sur les goulots d’étranglement.Oui, en effet, si vous avez une grande tâche qui ralentit votre équipe, ou une zone de faiblesse, qui empêche d’autres tâches du projet de progresser, jetez tout ce que vous avez sur ce goulot d’étranglement jusqu’à ce que les choses commencent de nouveau à fonctionner sans à-coups. Il y a des calculs, dans ce livre, qui prouvent que se concentrer sur des goulots d’étranglement est la façon la plus rapide de compléter un projet.

Regardez par exemple cette vidéo de Christian Hohmann sur la la synchronisation des flux par la Théorie des Contraintes avec "Drum Buffer Rope".

Kaizen ? Faites un peu mieux la prochaine fois

kaizenChaque fois vous achevez un projet, exécutez une revue rapide. Qu’est-ce qui a bien marché? Qu’est-ce qui a moins bien marché ? Quels blocages et autres dangers les membres de l’équipe auront-ils besoin d’éviter dans de futurs projets ?
Pendant que vous y êtes, exécutez une revue de votre management de projet lui-même. Avez-vous réellement capturé et passé en revue chaque tâche, ou en avez-vous oublié certaines ? Avez-vous utilisé votre Tableau Kanban chaque jour, ou l’avez-vous négligé pendant les périodes critiques et perdu du temps à cause de cela ? Avez-vous efficacement isolé les bons goulots d’étranglement?
Kaizen signifie simplement amélioration continue: C’est tout ce que vous avez à faire !

Quelles sont les techniques que vous aimeriez voir ajouter à cette liste?

Partenaire de DantotsuPM

Partenaire de DantotsuPM

 

1 Avril – Paris – vers l’entreprise Agile

28 mar

Petit-déjeuner Octo du mardi 1 avril 2014, Paris VIIIème à 9:00

octo AgileUne fois passées les premières expérimentations sur les méthodes agiles, une question s’impose de façon récurrente : comment changer d’échelle et devenir une entreprise Agile ?

Bien sûr, il ne s’agit pas de savoir lancer un énième projet en Scrum mais plutôt de répondre aux questions suivantes :

  • Qu’est ce qu’une entreprise Agile ?
  • L’entreprise Agile chez moi, est-ce que cela fait sens ? Jusqu’où dois-je ou puis-je aller ?
  • Comment assurer un pilotage de mon portefeuille projets et de mes budgets ?
  • Comment engager cette transformation? Quels sont les écueils à éviter ?

En répondant à ces questions, OCTO vous propose un chemin.

Les intervenants ne parleront pas directement de Scrum, Software Craftsmanship, Lean Startup, ou autre Devops, mais bien de la manière de créer une alchimie réunissant ces ingrédients au travers de la gouvernance, de l’organisation, des pratiques de management et de la culture d’entreprise.

Au delà du partage des bonnes pratiques et des Frameworks d’entreprise, ce petit déjeuner sera l’occasion confronter les retours d’expérience chez nos clients dans différents domaines (banque, eCommerce, télécoms, pure players du web).

La deuxième partie de ce petit déjeuner réunira  des acteurs de la transformation agile chez Société Générale et Viadeo autour d’une table ronde.

Avec ce petit déjeuner, Octo a l’ambition de vous fournir une base de réflexion et d’action pour transformer votre organisation en entreprise apprenante.

Inscriptions

Ce séminaire s’adresse à tous ceux qui ont envie d’aller plus loin sur l’agilité : marketing, chefs de produits, architectes, geeks, managers ou responsables DSI.

10 et 11 Avril – Paris – Scrum Day 2014 – la Culture Produit

27 fév

L’événement annuel des professionnels du pilotage de projets en mode agile avec Scrum.

Cette année, le thème de l’événement est la Culture Produit

Logo-Scrum-Day-2014-small-HD1Pour la quatrième édition: 2 jours de conférences  à Disneyland Paris.

Le premier jour sera orienté présentations et ateliers, le second jour forum ouvert vous permettant d’aborder les sujets que vous souhaitez approfondir.

Le ScrumDay est un évènement annuel organisé par l’association French Scrum User Group qui en a fait un rendez‐vous incontournable pour tous les professionnels de l’Agilité.

Les chiffres du ScrumDay 2013

Les chiffres du ScrumDay 2013

L’objectif de cet évènement est triple:

  1. rassembler en un même lieu pendant une journée des personnes qui découvrent l’Agilité ou qui souhaitent monter en compétences, ainsi que des spécialistes
  2. diffuser les bonnes pratiques et les dernières techniques reconnues par les experts
  3. favoriser les rencontres professionnelles et les échanges inter-­entreprises.

Résolument interactif, l’événement revêt différents formats, comme des keynotes, des conférences, des ateliers, des open spaces et des retours d’expériences, au cours desquels les participants apprendront et échangeront dans une ambiance conviviale.

Pour information :

29 Janvier – Marseille – Agile Play Ground

22 jan

2ème session Agile Play Ground (Agile Game) à Supinfo Marseille !

L’édition APG Marseille #2 se déroulera le mercredi 29 Janvier 2014, à la Technopole Château-Gombert à Marseille et en français !!!

agile gamePratiquant les approches Agile depuis de nombreuses années (innovation, NTIC, informatique, etc.) nous sommes convaincus des bienfaits et de l’efficacité de l’apprentissage par les jeux (serious game, agile game, innovation game). Tellement convaincus que nous utilisons fréquemment les jeux agiles pour enseigner la conduite de projet dans différentes établissements et entreprises, quelque soit le secteur d’activité.

Venez donc partager votre passion des jeux Agile lors de cette 2ème édition de l’Agile PlayGround à Marseille le mercredi 29 janvier 2014 de 18h30 à 21h45.

  • agile game 2Que vous soyez dans l’informatique, la communication, les RH, le commercial, la production, l’organisation, le management de projets, l’enseignement, la gestion d’équipes, etc.
  • Que vous soyez DSI, directeur de projet, chef de projet, DRH, enseignant, formateur, commercial, étudiant, etc.
  • Que vous soyez à la recherche d’une démarche moderne, conviviale, opérationnelle et efficace pour organiser et gérer vos projets.

Pour cette 2ème édition, une session de jeux Agile permettra de découvrir et essayer la méthode Scrum, pouvant être appliquée dans tout type de projet nécessitant la maîtriser d’une production planifiée.

Animateurs :

Frédéric Rodriguez – Conseil et Formation en Management Par Projets (PMP)
Thierry Secquevillewww.BoostezVosProjets.com

Agile PlaygroundDéja membre Meetup : Agile Play Ground Marseille #2 du 29 janv 2014 ( http://www.meetup.com/Agile-Play-Ground/events/… )

Nouveau membre Meetup : L’inscription se fait sur MeetUp via le groupe Agile Play Ground ( www.meetup.com/Agile-Play-Ground/ )

Se créer un compte sur www.meetup.com puis Rejoindre le groupe Agile Play Ground sur www.meetup.com/Agile-Play-Ground/ et
S’inscrire sur Agile Play Ground Marseille #2 du 29 janv 2014 ( http://www.meetup.com/Agile-Play-Ground/events/… )

4 avantages de la nature itérative de Scrum

13 jan

4 Benefits of the Iterative Nature of the Scrum Methodology

http://www.projectmanager.com/4-benefits-of-the-iterative-nature-of-the-scrum-methodology 

Nous sommes tout familiers des sorties de logiciel majeures. Prenez votre machine à remonter le temps et pensez à l’environnement Windows. Il y a eu Windows 3.0, Windows 95, Windows 98, Windows 2000, Windows XP, Windows Vista et Windows 8.

Chacune de ces sorties majeures a été conçue avec de nouvelles fonctionnalités et des améliorations technologiques par rapport aux précédentes.

Une sortie de version majeure est la super nouvelle version d’un produit logiciel ou d’une application Web qui contient tout ce que tout le monde a demandé depuis la dernière grande version. C’est la solution à tous les problèmes et c’est la litanie qui est répétée quand on pose la question de pourquoi le logiciel ne fonctionne pas actuellement d’une certaine façon. La réponse est une longue répétition de "dans la prochaine version 9.0…9.0 ….9.0 …".

Ceci peut être bel et bon, mais il y a des problèmes associés à cette Approche de sortie de version majeure qui essaie de tout mettre dans la prochaine version. Nous discuterons certains de ces défis avec la méthode de Conduite de projet agile, comme le développement Scrum, qui peut rendre ces sorties plus itératives, plus petites et plus fréquentes.

Les Défis avec les Versions Majeures

Il y a un certain nombre de défis qui existent avec cette méthode de développement logiciel qui suit le chemin de méthodologies de développement plus rigides comme la méthode dites en Cascade.

Ci-dessous sont quelques-uns de ces défis :

Les versions sont éloignées l’une de l’autre

futureDes versions majeures sortent typiquement éloignées l’une de l’autre. Bien sûr, il peut y avoir des versions mineures en chemin (comme 9.1 ou 9.05 selon la taille de la version), mais celles-ci sont d’habitude reléguées aux corrections de bogue et corrections de fonctionnalité existante.

Le contenu vraiment nouveau et passionnant nécessite d’habitude 4 à 6 mois et dans ce monde exigeant de satisfactions instantanées, ceci peut sembler une éternité. De plus, ceci nous mène aux conversations répétées avec des clients et des utilisateurs finaux que ce qu’ils veulent vraiment que le logiciel fasse se trouve à un certain point dans un avenir éloigné.

De surcroît, comme les dates approchent, il y a typiquement un certain type de débordement de périmètre qui a été introduit en chemin et la fonction ne marche pas comme prévue, ce qui repousse la date de livraison encore plus loin.

Tout est entassé dans la prochaine version

embouteillageDes idées feront surface pendant le développement de la version majeure. Elles sont de si excellentes idées et feraient une si grande différence pour l’utilisateur final qu’il serait déraisonnable d’attendre la version majeure suivante qui pourrait être 8 à 12 mois plus tard.

Que se passe-t-il ?

Ces grandes idées forcent leur passage dans un espace qui est déjà encombré de fonctionnalités. De plus, il n’y a d’habitude pas assez de personnes disponibles pour implémenter le premier cercle de fonctionnalités sans parler du périmètre supplémentaire qui a été introduit. Ceci contribue en partie aux raisons des retards potentiels mentionnés ci-dessus.

Devient plus grande que l’océan et peu aisée à manœuvrer

gouvernanceMaintenant il y a ce poids lourd de la version majeure qui hante couloirs et bureaux. Elle prend sur une vie à part et commence à bousculer les gens quand ses besoins ne sont pas respectés.

Ses besoins se sont étendus pour inclure des tests supplémentaires, davantage de documentation et la conduite de plus de groupes de discussion pour voir si la nouvelle fonctionnalité est facile de comprendre et utiliser. Ceci exige beaucoup de management pour mener cette version monstrueuse à l’achèvement et éviter qu’elle ne nous échappe.

Grand changement dans l’interface utilisateur (UI)

Un changement substantiel à l’UI est typiquement associé à une version majeure. Ceci exige une courbe d’apprentissage de la part de l’utilisateur final comme tout le monde appréhende la nouvelle interface.

Rappelez-vous des changements dans la navigation que Microsoft a pas fait il n’y a pas si longtemps dans la navigation basée sur le Menu que tout le monde connaissait depuis des années vers l’approche de Ruban qui a agrégé des fonctions liées en un même endroit. Nous y sommes habitués maintenant mais cela a pris du temps de s’adapter à la nouvelle façon de faire les choses.

Les problèmes sont plus difficiles à cerner

problèmePuisqu’il y a tant de personnes impliquées dans une sortie de version majeure de dimensions Herculéennes, il devient dur d’identifier précisément et de résoudre les problèmes. Les problèmes pourraient apparaître dans une zone qui impacte négativement une autre zone.

Par exemple, une application Web peut prendre excessivement longtemps à se charger. Rien de changé côté code et tout le monde dans les autres services jure que rien n’a changé non plus.

"Attendez, euh…," dit timidement le service informatique "nous avons vraiment récemment fait un changement mineur dans le réseau qui pourrait limiter le débit".

Bien sûr, ce dont on pensait que cela n’avait aucun rapport avec la cause du problème finit par être le coupable.

Les avantages de la méthodologie Scrum

Il y a eu un changement vers des méthodologies de conduite de projet plus agiles ces dernières années. Ceci a ouvert la porte pour des versions logicielles plus itératives et a réduit la durée entre chaque sortie majeure suivante. Voici certains des avantages de la méthodologie Scrum.

  • De plus fréquentes versions
scrum methodologie agile

Voici le diagramme du Modèle Scrum

Les phases de la méthodologie Scrum se concentrent sur des sorties fréquentes avec moins de fonctionnalités. Initialement, ceci peut donner l’impression d’être négatif. Qui voudrait moins de fonctionnalité ? Eh bien, plutôt qu’attendre 4 à 6 mois pour avoir toute la fonctionnalité, la méthodologie Scrum permet aux versions d’être accélérées. Dans la plupart des cas, une version peut être sortie toutes les 4 à 6 semaines! Le cycle de développement est appelé un Sprint, qui en dit long sur la nature abrégée de la méthodologie Scrum.

  • Focus sur un Jeu limité de Fonctionnalités, Facilité d’utilisation et Valeur pour l’Utilisateur final

prioriser1La nature itérative de la méthodologie Scrum se prête à une concentration au laser sur quelques fonctionnalités, la facilité d’utilisation et la valeur pour l’utilisateur final. Chaque version doit donner de la valeur à l’utilisateur final. À un certain niveau, cela pourrait être vu comme une approche par phase de versions majeures. Plutôt que d’attendre que tout soit fait en même temps, les fonctionnalités sortent comme elles sont produites et mises en ligne.

  • L’approche Itérative permet changements et améliorations

Des méthodologies de conduite de projet agiles comme la méthodologie Scrum embrassent le changement. La méthode en cascade qui est si commune pour des versions majeures est typiquement résistante au changement. Il y a des formulaires, des réunions, des approbations et autres contrôles mis en place dans le but d’empêcher le changement avec les méthodologies conventionnelles. La nature itérative de la méthodologie Scrum cherche un retour d’information continu et ajuste ensuite le plan et les jeux de fonctionnalités en conséquence.

  • Se prête au Software as a Service (SaaS)

Plus de demandes se déplacent vers le Modèle du Logiciel comme un Service (SaaS). Ceci est quand l’application en ligne est vivante, une entité qui respire et à laquelle les gens adhèrent selon leurs besoins. Une partie des attentes autour du modèle SaaS est qu’il y aura des changements et des améliorations continus au logiciel. Ceci encourage des abonnés à la demande à continuer à renouveler mois après mois. La méthodologie Scrum facilite ceci.

Le temps où attendre 4-6 mois entre des versions majeures est révolu. Les gens n’ont plus ce type de patience et il y a des alternatives pour ne pas avoir à attendre si longtemps. Même si vous n’adoptez pas la méthodologie Scrum en entier, il y a de certains principes que vous pouvez utiliser qui permettront à vos projets d’avancer plus rapidement.

ProjectManager.com croit en la livraison fréquente de super fonctionnalités à ses utilisateurs finaux.

Campana & Schott

Partenaire de DantotsuPM

Suivre

Recevez les nouvelles publications par mail.

Rejoignez 1 110 autres abonnés

%d bloggers like this: