SCRUM

SCRUM

 
Pour rappel Scrum est une méthode agile dédiée à la « gestion de projet ». Cette méthode de gestion, ou plutôt ce Framework de management de projet, utilisé à Rintio dans l’intégration des applications mises en place et à pour objectif d’améliorer la productivité de son équipe. Le framework s’appuie sur le découpage d’un projet en boîtes de temps, nommées « sprints ». Les sprints peuvent durer entre quelques heures et un mois (avec une préférence pour deux semaines). Chaque sprint commence par une estimation suivie d’une planification opérationnelle. Le sprint se termine par une démonstration de ce qui a été achevé. Avant de démarrer un nouveau sprint, l’équipe réalise une rétrospective. Cette technique analyse le déroulement du sprint achevé, afin d’améliorer ses pratiques. Le flot de travail de l’équipe de développement est facilité par son auto-organisation, il n’y aura donc pas de gestionnaire de projet.

La création de frameworks de développement logiciel hybrides couplant Scrum et d’autres frameworks est commune puisque Scrum ne couvre pas le cycle de développement de produit. Par exemple, on pourra utiliser des pratiques issues de l’extreme programming, de la phase de construction structurée de la méthode RAD, ou un ensemble de pratiques de qualité du logiciel émergeant du vécu de l’équipe projet.

Caractéristiques

Le cadre de travail Scrum est fondé sur la conviction que le développement logiciel est une activité par nature non-déterministe et que l’ensemble des activités de réalisation d’un projet complexe ne peut être anticipé et planifié7. C’est en cela que Scrum s’oppose aux démarches prédictives telles que le cycle en V. Pour répondre à cette imprédictibilité, la méthode Scrum propose un modèle de contrôle de processus fondé sur l’empirisme, via l’adaptation continue aux conditions réelles de l’activité et une réaction rapide aux changements. L’analyse des conditions réelles d’activité lors des retrospectives de fin de sprint et le plan d’amélioration continue qui en découle sont réalisés à intervalles de temps réguliers, donnant lieu à un cycle de développement incrémental (Sprint).

Le cadre de travail Scrum a été conçu lors de projets de développement de logiciels. Il peut aussi être utilisé par des équipes de maintenance. Dans le cas de très grands projets, les équipes se multiplient et on parle alors de scrum à grande échelle (ex. : le scrum de scrums ou LESS). Le cadre de travail Scrum peut théoriquement s’appliquer à n’importe quel contexte ou à un groupe de personnes qui travaillent ensemble pour atteindre un but commun comme planifier un mariage, gérer des projets de recherche scientifique, des écoles et même des églises comme le précise le site de l’un des co-créateurs Jeff Sutherland.

Un principe fort des méthodes agiles est la participation active du client. Cela permet de choisir plus finement les fonctionnalités réalisées à chaque incrément. Avant le démarrage du sprint 1, les objectifs sont définis lors d’un sprint 0. La mêlée (scrum meeting) a lieu quotidiennement et des réunions spécifiques permettent de lever les obstacles bloquants. Le sprint a une durée variable (idéalement deux semaines). Après chaque sprint, une démonstration suivie d’une rétrospective ont lieu. Le propriétaire du produit peut à tout moment compléter ou modifier la liste des fonctionnalités à produire pour les prochains sprints. Sans modifier le but du sprint en cours, celui-ci peut être affiné et faire l’objet d’une renégociation entre le propriétaire du produit et l’équipe de développement à la suite de nouvelles connaissances. Si le but du sprint devient obsolète, le propriétaire du produit a la capacité d’annuler un sprint en cours.

Chaque sprint constitue donc un incrément, facilitant le pilotage du projet. La notion d’itération couvre l’adaptabilité au quotidien. Cette adaptabilité est limitée par le but immuable d’un sprint.

Les trois piliers de scrum

Scrum est un processus empirique : il se base sur l’expérience du terrain. Il s’appuie sur trois piliers.

Il suit également les principes de la culture agile.

Transparence

Scrum met l’accent sur le fait d’avoir un langage commun entre l’équipe et le management. Ce langage commun doit permettre à tout observateur d’obtenir rapidement une bonne compréhension du projet.

Inspection

À intervalle régulier, Scrum propose de faire le point sur les différents artéfacts produits, afin de détecter toute variation indésirable.

Ces inspections ne doivent pas être faites trop fréquemment, ou par un inspecteur mal formé : cela nuirait à l’avancement du projet.

Adaptation

Si une dérive est constatée pendant l’inspection, le processus doit alors être adapté. Scrum fournit des évènements, durant lesquels cette adaptation est possible. Il s’agit de la réunion de planification de sprint, de la mêlée quotidienne, de la revue de sprint ainsi que de la rétrospective de sprint.

 

Le « package » Scrum

Processus de la méthode Scrum

                                                    Processus Scrum

Scrum est considéré comme un cadre ou « framework » de gestion de projet. Ce cadre est constitué d’une définition des rôles, de réunions et d’artefacts.

Scrum définit 3 rôles :​

  • – Le « Product Owner » qui porte la vision du produit à réaliser (représentant généralement le client).
  • – Le « Scrum Master » garant de l’application de la méthodologie Scrum.
  • – L’équipe de développement qui réalise le produit.

La vie d’un projet Scrum est rythmée par un ensemble de réunions clairement définies et strictement limitées dans le temps (timeboxing):

  • Planification du Sprint (Sprint = itération) : au cours de cette réunion, l’équipe de développement sélectionne les éléments prioritaires du « Product Backlog » (liste ordonnancée des exigences fonctionnelles et non fonctionnelles du projet) qu’elle pense pouvoir réaliser au cours du sprint (en accord avec le « Product Owner »).
  • Revue de Sprint : au cours de cette réunion qui a lieu à la fin du sprint, l’équipe de développement présente les fonctionnalités terminées au cours du sprint et recueille les feedbacks du Product Owner et des utilisateurs finaux. C’est également le moment d’anticiper le périmètre des prochains sprints et d’ajuster au besoin la planification de release (nombre de sprints restants).
  • Rétrospective de Sprint : la rétrospective qui a généralement lieu après la revue de sprint est l’occasion de s’améliorer (productivité, qualité, efficacité, conditions de travail, etc) à la lueur du « vécu » sur le sprint écoulé (principe d’amélioration continue).
  • Mêlée quotidienne : il s’agit d’une réunion de synchronisation de l’équipe de développement qui se fait debout (elle est aussi appelée « stand up meeting ») en 15 minutes maximum au cours de laquelle chacun répond principalement à 3 questions : « Qu’est ce que j’ai terminé depuis la dernière mêlée ? Qu’est ce que j’aurai terminé d’ici la prochaine mêlée ? Quels obstacles me retardent ? »

Fonctionnement des méthodes agiles

Les méthodes agiles partent du principe que spécifier et planifier dans les détails l’intégralité d’un produit avant de le développer (approche prédictive) est contre productif. Cela revient à planifier dans les détails un trajet « Paris – Narbonne » en voiture par les petites routes. Spécifiant chaque villes et villages traversés, l’heure de passage associée, chaque rue empruntée dans les agglomérations, litres d’essence consommés, kilomètres parcourus, etc. Les imprévus ne manqueront pas d’arriver : embouteillages, déviations, travaux, sens de circulation inversés, voire la panne, etc.

L’idée consiste à se fixer un premier objectif à courts termes (une grande ville par exemple) et se lancer sur la route sans tarder. Une fois ce premier objectif atteint, on marque une courte pause et on adapte son itinéraire en fonction de la situation du moment. Et ainsi de suite jusqu’à atteindre la destination finale. On parle donc d’une approche empirique. Dans le cadre d’un projet de développement logiciel, le client élabore sa vision du produit à réaliser et liste les fonctionnalités ou exigences de ce dernier. Il soumet cette liste à l’équipe de développement, communique directement avec elle (plutôt que par papier) qui estime le coût de chaque élément de la liste. On peut ainsi se faire une idée approximative du budget global.

L’équipe sélectionne ensuite une portion des exigences à réaliser dans une portion de temps courte appelée itération. Chaque itération inclut des travaux de conception, de spécification fonctionnelle et technique quand c’est nécessaire, de développement et de test. A la fin de chacune de ces itérations, le produit partiel mais utilisable est montré au client. Ce dernier peut alors se rendre compte par lui même très tôt du travail réalisé, de l’alignement sur le besoin. L’utilisateur final quant à lui peut se projeter dans l’usage du produit et émettre des feedbacks précieux pour les futures itérations. La visibilité ainsi offerte est clef. Cette transparence peut également apporter davantage de confiance et de collaboration dans la relation client/fournisseur. Les risques quant à eux sont levés très tôt.

Si le client a priorisé avec soin son besoin, il peut saisir l’opportunité d’accélérer le « time to market » si il estime que le produit en l’état (partiel) peut aller en production. Économisant ainsi son budget et récoltant un premier retour sur investissement. Il a aussi la possibilité de changer en cours de route la priorité des fonctionnalités qui n’ont pas encore été développées (prévues pour les itérations futures). Afin de retarder une fonctionnalité dont le besoin n’est pas mûr, ajouter une nouvelle fonctionnalité cruciale en échange du retrait d’une autre (respectant ainsi budget et délais), etc.

Cette souplesse ainsi offerte est donc un véritable atout pour le client.

La contractualisation agile

La contractualisation d’un projet agile n’est pas la partie la plus facile étant donné que le périmètre est par définition variable. La régie ferait bien l’affaire mais difficile de rassurer le client avec un tel contrat. En France et ailleurs, le contrat au forfait domine; surtout sur les gros projets. Malheureusement pour le fournisseur – dans le cadre d’un forfait classique – tous les risques sont pour lui (aussi bien sur un projet agile que sur un projet traditionnel). On peut limiter ces risques en prenant quelques précautions, mais on limite également la souplesse offerte par une approche Agile.

Cela ne veut pas dire qu’il n’existe pas de solutions. La forfaitisation de chaque itération avec la possibilité pour le client d’arrêter le contrat à la fin de chaque itération est assez intéressante. Ainsi que le principe de troc d’exigence : réalisation d’une exigence imprévue en échange du retrait d’une autre moins importante, de priorité faible et de même coût.

DevOps

DevOps

 

DevOps est un ensemble de pratiques qui automatisent les processus entre les équipes de développement et IT afin de leur permettre de développer, tester et livrer des logiciels plus rapidement et avec plus de fiabilité. Le concept de DevOps repose sur la mise en place d’une culture de la collaboration entre les équipes qui étaient, historiquement, cloisonnées. Parmi les avantages assurés, le gain de confiance, l’accélération des livraisons, la capacité à résoudre les tickets plus rapidement ou encore la gestion plus efficace des tâches non planifiées.

 

À la base, DevOps est une culture, un courant de pensée, une philosophie.

C’est une poignée de main ferme entre les équipes de développement et opérationnelles. L’accent est mis sur le changement de mentalité, la collaboration accrue et l’intégration plus poussée. DevOps associe la méthodologie Agile, l’automatisation, la livraison continue et bien plus encore pour aider les équipes de développement et opérationnelles à gagner en efficacité, à innover plus rapidement et à offrir plus de valeur ajoutée aux business et aux clients. Rintio utilise cette technologie pour le développement et l’intégration de ses applications, ce qui permet à ses développeurs de gagner en temps et en gestion efficace des tâches a exécutées.

L’histoire de DevOps

Le mouvement DevOps a commencé à s’unifier entre 2007 et 2008, lorsque les équipes opérationnelles et de développement ont clairement exprimé ce qu’elles qualifiaient de dysfonctionnement majeur dans le secteur.

Elles ont pesté contre le modèle de développement traditionnel, qui appelait un cloisonnement organisationnel et fonctionnel entre les programmeurs, les équipes de déploiement et le support.

Les développeurs et les experts de l’IT/des opérations avaient des objectifs distincts (et souvent opposés), leur propre leadership, des indicateurs clés de performance différents au moyen desquels ils étaient évalués et, bien souvent, ils travaillaient à des étages voire dans des bâtiments séparés. Résultat : les équipes étaient cloisonnées, elles ne se préoccupaient que de leur propre fief, faisaient des heures supplémentaires, bâclaient les livraisons, et les clients étaient mécontents.

Il devait y avoir une méthode plus efficace. Les deux communautés se sont donc réunies et ont commencé à échanger. Des experts tels que Patrick Dubois, Gene Kim ou encore John Willis étaient aux commandes.

Ce qui a commencé par des forums en ligne et des réunions locales s’est désormais popularisé dans l’univers du développement. C’est d’ailleurs probablement ce qui vous a amené ici ! Votre équipe et vous-même éprouvez des difficultés en raison de silos et d’un manque de communication au sein de votre entreprise.

Vous utilisez les méthodologies Agile pour la planification et le développement, mais vous cherchez encore à livrer du code sans catastrophe. Vous avez entendu parler de DevOps et de son effet apparemment magique sur les équipes, et vous pensez que vous aimeriez profiter, vous aussi, de cette magie.

La mauvaise nouvelle ? DevOps n’est pas la panacée, et les transformations ne s’opèrent pas en une nuit. La bonne nouvelle ? Inutile d’attendre que les cadres supérieurs mettent en place une initiative à grande échelle. Si elle comprend la valeur ajoutée de DevOps et qu’elle apporte de petits changements incrémentiels, votre équipe peut débuter son parcours DevOps dès maintenant. Voyons maintenant chacun de ces avantages plus en détail

Avantages…

« DevOps nous a aidés à Rintio d’ accélérer les livraisons et nous a donné un avantage en termes de délai de commercialisation. Nous sommes maintenant capables de livrer chaque jour, contre une fois tous les 6 mois, et de pusher les correctifs vers nos clients en l’espace de quelques heures. »

Collaboration et confiance

La culture est le principal facteur de réussite d’une initiative DevOps. Instaurer une culture de la responsabilité partagée, de la transparence et du feedback accéléré est incontournable pour chaque équipe DevOps ultra performante.

Les équipes cloisonnées n’adhèrent souvent pas à la « pensée systémique » de DevOps. Penser de façon systémique signifie être sensible à l’impact de vos actions sur votre équipe, mais aussi sur toutes les autres équipes impliquées dans le processus de livraison. Le manque de visibilité et les objectifs partagés impliquent un manque de planification des dépendances, un mauvais alignement des priorités, une mentalité où les autres sont pointés du doigt et où l’on affirme que ce n’est pas notre problème. La vélocité et la qualité sont alors affectées. DevOps impose un changement d’état d’esprit, qui vise à observer le processus de développement de façon holistique et à éliminer les cloisons entre les équipes de développement et opérationnelles.

Livrez plus rapidement et travaillez plus intelligemment

Tout est question de vitesse. Les équipes qui adoptent DevOps livrent plus souvent, avec plus de qualité et de stabilité.

L’absence de tests automatisés et de cycles de revue bloque la mise en production, et les temps de réponse aux incidents médiocres sont l’ennemi de la vélocité et de la confiance. Les outils et processus disparates augmentent les OpEx, imposent un changement de contexte et cassent la dynamique. Grâce à l’automatisation ainsi qu’aux outils et processus standardisés, les équipes peuvent accroître la productivité et livrer plus souvent, avec moins d’à-coups.

Réduisez la durée de résolution

L’équipe dont la boucle de feedback est la plus rapide prospère. Grâce à la transparence totale et à la communication fluide, les équipes DevOps peuvent réduire les temps d’arrêt et résoudre les tickets plus rapidement que jamais.

Si les tickets critiques ne sont pas résolus rapidement, la satisfaction des clients chute. Les tickets importants passent au travers des mailles du filet en l’absence de communication ouverte. En conséquence, la tension et la frustration augmentent au sein des équipes. Les équipes de développement et opérationnelles « swarment » sur les tickets, résolvent les incidents et débloquent plus rapidement le pipeline de livraison grâce à la communication ouverte.

Gérez plus efficacement les tâches non planifiées

Chaque équipe est confrontée à des tâches non planifiées, une réalité qui se répercute bien souvent sur la productivité. Grâce aux processus établis et à la priorisation claire des tâches, les équipes de développement et opérationnelles peuvent mieux gérer les tâches non planifiées, tout en se concentrant sur celles qui le sont.

Le transfert et la priorisation des tâches non planifiées entre les différents systèmes et équipes s’avèrent inefficaces et détournent l’attention des employés du travail à faire. Cependant, les équipes peuvent mieux anticiper et partager les tâches non planifiées grâce à la visibilité accrue et à la rétrospection proactive.

Qui adopte DevOps

Des dizaines de milliers de développeurs utilisent Chef pour tester, automatiser et gérer les infrastructures. À l’avant-garde du mouvement DevOps, la société  livre des produits  et proposer de nouvelles méthodes de développement et de livraison de logiciels et d’applications.

Les équipes qui adoptent DevOps déploient 30 fois plus souvent, déplorent 60 fois moins de défaillances et constatent des délais de récupération 160 fois plus rapides: Nos développeurs  à Rintio l’ont essayés puis adoptés  et nous en sommes satisfait.

Programme cinq mille codeurs

Programme cinq mille codeurs

 

Ce programme initié par Rintio Institue en 2017 vise à former et renforcer les capacités d’environs 5000 jeunes en Afrique à l’horizon 2028.

Rintio BIG DATA Bootcamp est un camp international de formation  gratuit accélérée dédié aux applications BIG DATA pour entreprises qui s’est déroulé du 02 au 30 juin 2018 à Grand-popo. Grâce aux Big Data,les entreprises disposent désormais  de nombreuses ressources pour proposer des contenus personnalisés à leur client et les diffuser au bon endroit, au bon moment.

La mission de ce bootcamp international etait de former une jeunesse hautement qualifiée aux métiers porteurs de l’informatique actuel. Avec plusieurs avantages tels que:

–  l’apprentissage par la pratique sur des projets réels.

–  la création des applications innovantes avec les technologies du Big Data

–  offrir aux entreprises la possibilité de faire implémenter leurs projets par les jeunes en apprentissage

–  permettre aux entreprises de faire former leurs personnels aux technologies Big Data directement sur place.

A l’issu de ce bootcamp, les jeunes ont eu la chance et le privilège d’être entrenus par des expers béninois, de la sous région et de l’international puis maîtriser  les outils utilisés dans le domaine du BiG Data: Hadoop et son écosystème, spark, machine learning, dataviz, scraping,crawling des données.

Hello world!

Welcome to WordPress. This is your first post. Edit or delete it, then start writing!

Future design concept

Ut enim ad minima veniam, quis nostrum exercitationem ullam et suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur.

Stand out venues

Ut enim ad minima veniam, quis nostrum exercitationem ullam et suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur.

Technology upgraded

Ut enim ad minima veniam, quis nostrum exercitationem ullam et suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur.