Qu’est-ce que l’approche Agile ?

L’approche Agile, parfois aussi appelée « méthode Agile », est un ensemble de valeurs et de principes qui remonte à la fin des années 1990. Ce qui était alors éparpillé dans quelques textes ou manifestes encore peu suivis s’est imposé comme une véritable norme dans le monde du développement software. Aujourd’hui, en Scandinavie, l’approche Agile est considérée comme l’approche normale et non plus comme une alternative, à tel point que presque aucune compagnie n’y suit d’approche entièrement séquentielle.

Beaucoup d’organisations et de méthodes d’implémentations se revendiquent Agile, même quand leur façon de travailler n’est pas tout à fait en phase avec les principes au cœur de cette approche. Qu’est-ce qui est Agile ? Cette session vous donnera une ébauche de réponse, que nous avons constituée suivant notre propre expérience en consulting IT. Restez avec nous pour découvrir les principes d’Agile et comment on développe un software avec eux.

Implémenter de nouvelles méthodes de travail peut s’avérer difficile. On y échoue souvent. Cependant, l’expérience des années et l’expérimentation au cas par cas changent tout. Ici, au Right People Group, nous avons passé plus de dix ans à échanger avec des experts et sommes venus en aide à plusieurs centaines de clients. Cela nous a laissé le temps de remarquer qu’une transition réussie vers les principes Agile rendent les employés plus satisfaits et conduisent à un développement software plus efficace.

La vidéo ci-dessous décrit les principes et les croyances de base du développement Agile :

Scrum, la variante Agile la plus utilisée

Scrum est une méthodologie de développement software ou de produits complexes en général. Basée sur les principes Agile, elle en est la variante la plus utilisée de par le monde. Scrum consiste notamment à attribuer divers rôles aux membres de l’équipe de développement. Si nous en avons appris quelque chose, c’est que le product owner (voir ci-dessous) y a une position cruciale et que celui qui assume ce rôle peut déterminer le succès ou l’échec du projet à lui tout seul.

Les rôles-clés de la méthodologie Scrum sont les suivants :

• Product Owner
• Scrum Master
• Développeur Scrum

Ces rôles œuvrent suivant une organisation et des étapes communément appelées boîtes de temps :

• Sprints
• Mêlée quotidienne
• Rétrospective
• Carnet de sprint
• Carnet de produit

Rôles et événements sont définis plus précisément sur l’article Wikipédia consacré à Scrum ainsi que sur cette vidéo :

Une alternative à Scrum : Kanban

Beaucoup d’entreprises se mettent à l’approche Agile avec Scrum. Par la suite, certaines préfèrent remplacer cette méthodologie par une autre, Kanban.

Inspirée des méthodes de la gestion de projet Lean, Kanban est très appréciée dans le monde du développement pour sa clarté. En effet, avec elle, tous les travaux menés par l’équipe développement sont représentés sur un tableau, ce qui permet à tous les membres de l’équipe de suivre l’évolution globale du projet à tout moment. Nous avons pu remarquer qu’implémenter Kanban tend à améliorer le développement software et que beaucoup de consultants indépendants réputés recommandent la méthode.

Vous trouverez ici une comparaison synthétique entre Scrum et Kanban, que vous pouvez aussi découvrir dans la vidéo ci-dessous :

D’étape en étape, le produit minimum viable

Le concept de produit minimum viable s’est popularisé après la sortie du livre Lean Startup : Adoptez l’innovation continue de l’entrepreneur Eric Ries en 2008. Il correspond fortement aux besoins des start-ups et s’intègre sans heurt dans l’état d’esprit Agile. Ces dernières années, le concept est devenu un véritable pilier parmi les start-ups de technologie.

L’agilité, la rapidité des start-ups tend aujourd’hui à menacer des « grandes entreprises », plus lentes, en particulier lorsque les premières concurrencent les secondes sur des services de base. Nous pensons notamment à ce qui se fait dans le secteur financier. Ce risque de plus en plus grand pour les grandes entreprises les pousse à s’imprégner du concept de produit minimum viable et de l’état d’esprit Agile. Plus que jamais, un délai de commercialisation court est une nécessité pour rester compétitif.

La vidéo ci-dessous passe en revue trois exemples de produits minimum viables qui ont très bien réussi

TECHNICAL DEBT

In our first video, we saw how the developer made the choice of only doing part of the database layer that was needed to deliver the relevant functionality. Decisions like these might be right to make, but it can also lead to the potential danger of having too many non-finished parts in the overall system architecture giving a “technical debt”.

Technical Debt is a concept introduced by one of the Agile Manifesto authors, Ward Cunningham. As said, taking short cuts in order to e.g. put a viable product on the market faster can be a good decision, but as the metaphor implies, one should be conscious that there is a debt to pay sooner or later, simply because the quickest solution in a short perspective will rarely be the most optimal in the long run.

If there is no reason for taking a coding short-cut and a quick and dirty solution is not implemented to achieve business value but simply because the team is not ambitious or skilled enough, then technical debt has nothing to do with agile methods and business thinking, then it is just bad work!

Actually, in our experience, software developers that are not sufficiently skilled and focused on quality are the biggest reason for technical debt. We also see that the interest paid on technical debt is huge. Increasing technical debt makes changes to a software product increasingly hard to implement, which is equal to killing the product since a static software product cannot survive.

Here is an introduction to technical debt:

Ce qu’Agile n’est pas

Le manifeste pour le développement Agile indique clairement que certains aspects du développement sont prioritaires sur d’autres. Cela ne signifie pas que les aspects secondaires soient tout à fait dépourvus de valeur ou puissent être négligés. Or, ceci est parfois mal compris : certains développeurs refusent par exemple de documenter ce qu’ils font et se justifient en invoquant les principes Agile, qui à aucun moment ne préconisent d’abandonner toute documentation.

Cette présentation (p.4) montre succinctement en BD comment le manifeste Agile ne devrait pas être compris :

http://www.com-hom.com/Fiches/0904_CARA.pdf

Scaled Agile Framework (SAFe), un cadre pour la transition Agile

Les projets de développement software sont difficiles. Ceux qui portent sur des softwares complexes ou particulièrement ambitieux sont très difficiles ! Alors que beaucoup d’entreprises s’imprègnent de l’esprit Agile, de plus en plus ressentent le besoin d’une méthode pour faire passer des projets complexes ou ambitieux à Agile sans (trop de) difficultés. C’est spécialement pour cela qu’a été développé SAFe, un cadre pour la transition de projets complexes. Vous en trouverez une explication ici ainsi que sur la vidéo ci-dessous :

Comment une approche Agile peut échouer

Un changement introduit dans les processus organisationnels est toujours vecteur de risque. L’approche Agile ne fait pas exception. Au fil des années, nous avons pu remarquer que les développeurs formés à l’approche séquentielle classique sont très enclins à adopter cette nouvelle approche, mais tendent aussi à sous-estimer les changements qu’elle implique. Agile oblige à abandonner certains mécanismes de contrôle inhérents à l’approche séquentielle. En outre, Agile demande une implication accrue de la part du volet entreprise – ou, en d’autres termes, que les employés y consacrent plus de temps.

Vous êtes freelancer ou consultant indépendant ?

Abonnez-vous à notre newsletter pour recevoir des projets ou des missions freelance par mail en accord avec votre profil et vos préférences géographiques.

Vous cherchez un développeur ERP ?

Contactez-nous par mail à info@rightpeoplegroup.com en nous expliquant votre projet et ce que vous recherchez. Nous vous enverrons le CV d’un développeur web et un tarif horaire défini. Pour en savoir plus sur nos services dans ce domaine, visitez nos pages dédiées à la gestion de projets Agile ou aux experts en développement Agile.