L'essentiel de SCRUM

Dans la section Informatique

A picture...

Top Articles

Joomla Templates

L'essentiel de SCRUM

Computer Science - Méthodes

Written by Vincent MARTIN

Article Index
L'essentiel de SCRUM
Les acteurs
Les artefacts
liens
All Pages

Page 1 of 4

There are no translations available.

SCRUM est aujourd'hui la méthode agile la plus utilisée et la plus riche en termes de retour sur investissement. Voici, en quelques billets, l'essentiel de la méthode.

Les illustrations de cet article sont extraites du site www.implementingscrum.com. Tous les strips sont disponibles sur http://www.implementingscrum.com/section/blog/cartoons/.

Principes et valeurs

Les quatre valeurs du Manifeste Agile

Le manifeste agile (www.agilemanifesto.org) énonce quatre valeurs et douze principes fondateurs de l'Agilité.

Les quatre valeurs sont :

▪ individuals and interactions over processes and tools (mettre en œuvre des individualités et des interactions, plutôt que des procédés et des outils : la plus-value est apportée par les individus et la façon dont ils communiquent, pas par les processus ou les outils) ;

▪ working software over comprehensive documentation (produire un logiciel qui fonctionne, plutôt qu’une documentation complète (et souvent pléthorique) ;

▪ customer collaboration over contract negotiation (collaborer avec le client, plutôt que négocier un contrat : le client devient un partenaire à part entière, qui participe au projet pour donner son feedback) ;

▪ responding to change ove following a plan (répondre aux modifications plutôt que de suivre un plan : personne, pas même le client, ne peut appréhender l’ensemble des besoins dès le début du projet).

Les douze principes

Outre les quatre valeurs, l'Agilité est fondée sur fondée sur douze principes (http://agilemanifesto.org/principles.html), dont une traduction simplifiée pourrait être la suivante :

▪ 1. livrer tôt et régulièrement des logiciels qui fonctionnent ;

▪ 2. accepter le changement, même tardivement ;

▪ 3. livrer en tendant vers la période de livraison la plus courte ;

▪ 4. faire collaborer étroitement et quotidiennement les gens de l’art (le métier) et les développeurs ;

▪ 5. avoir une équipe motivée et croire en sa capacité à produire du travail de qualité ;

▪ 6. transmettre l’information en face à face (transparence) ;

▪ 7. mesurer la progression du projet par la plus-value fonctionnelle réalisée ;

▪ 8. promouvoir un rythme de développement durable ;

▪ 9. apporter une attention continue à la technique et à la qualité de la conception ;

▪ 10. privilégier la simplicité, réduire le travail inutile ;

▪ 11. croire en la responsabilité des équipes, croire que le meilleur est issu d’équipes qui s’auto-organisent ;

▪ 12. adapter régulièrement la façon de travailler en fonction des résultats des étapes précédentes.

Discussion

De ces douze principes, je retiendrai surtout :

La transparence (6) : elle permet à chacun de connaître l’état d’avancement et le niveau de qualité de ce qui a été réalisé. S’il y a des retards ou des erreurs, c’est l'un des moyens qui permettent de les détecter et donc de les corriger.

La transparence a un corollaire : le courage. Il n’est pas toujours facile de communiquer sur les choses qui ne vont pas, les retards, les tâches qui n’ont pas été faites, les reports, etc.

La transparence est aussi un levier qui permet de faciliter la mise en œuvre d’autres principes. C’est un moyen indispensable pour :

▪ connaître tous les aspects (avancement, techniques, humains) du projet,

▪ connaître le niveau de confiance que l’on peut accorder à chacun, responsabiliser les équipiers (5) ;

▪ confronter les différents points de vue et réduire les écarts,

▪ identifier ce qui a été mal fait, trop fait (10), ou de manière non convenable,

▪ s’adapter et s’améliorer (12).

La responsabilisation de l’équipe : toute personne ayant travaillé en équipe l’a constaté : responsabiliser quelqu’un, c’est lui faire confiance, le valoriser, initier un cercle vertueux avec lui. Responsabilisée, la personne se sentira plus responsable de son travail et de sa qualité, consciente de sa liberté mais aussi de l’intérêt de son travail pour elle-même comme pour l'équipe.

Les personnes responsabilisées se sentent plus concernées et plus motivées. La responsabilité – bien dosée, adaptée à celui qui la reçoit – valorise, intéresse, motive et, donc, augmente la qualité du travail fourni.

Dans une équipe pluridisciplinaire, la responsabilité de toutes les activités repose sur l'implication de chacun. C’est l’une des bases des méthodes agiles : la qualité par la motivation, l’implication, la responsabilisation pour l'ensemble du travail fourni. En d’autres termes, la fin du « C’est pas mon problème ! » (typique des activités cloisonnées : moi j'analyse, je ne teste pas).

La répartition des tâches : ce n’est pas formellement énoncé dans les grands principes, mais les équipiers, dans un projet SCRUM, et à l’exception du Product Owner ou du Scrum Master, n’ont pas de tâches prédéfinies et attribuées spécifiquement pour la durée du projet.

Dans un projet Scrum, et ça découle de ce que je disais sur la responsabilité, tous les équipiers ont le droit de participer à la planification, de proposer des solutions d'architecture, de code, de test ou d'intégration. Ils ont le droit, en accord avec l'ensemble des équipiers, de contribuer à toutes les activités de l'équipe, c'est-à-dire, in fine, de contribuer à tous les petits morceaux de ce qui, mis bout à bout, constituera le projet.

Aucune des tâches d’ingénierie – donc aucune responsabilité – n’est spécifiquement dévolue à une seule ressource, comme dans un projet « classique ». Les liens hiérarchiques, créateurs de frustrations et de rancœurs, de responsabilités à la va-vite (« c’est la faute de ... si ... »), n’existent pas entre les équipiers. La responsabilité, le succès de chaque tâche est répartie entre tous les intervenants, impliqués au même niveau.

Prev - Next >>

Comments

Add New