A6.4 Comparaison de la méthodologie TenStep avec la méthode Agile de développement de logiciels

Aperçu (A6.4. P1)

Manifeste pour le développement du logiciel Agile

 Dix-sept anarchistes ont convenu :

Nous découvrons les meilleures manières de développer un logiciel en le réalisant, et en aidant les autres à le faire. À travers ce travail nous en sommes venus à:

Processus de management de projet TenStep

Mettre en relief des individualités et des interactions, plutôt que des procédés et des outils.

Produire un logiciel entièrement testé et qui fonctionne, plutôt qu'une vaste documentation.

Établir une collaboration avec le client, plutôt que de négocier un contrat.

Réagir aux modifications, au lieu de suivre un plan.

D’après l'expérience de l’auteur, les projets accomplis dans une organisation ont une chance de réussite bien meilleure avec un ensemble cohérent de processus flexibles et évolutifs. Si ces processus ont été utilisés auparavant avec succès, il y a une plus grande probabilité que les votre le seront aussi.

Nous considérons que la méthodologie TenStep est très « légère ». Cependant elle représente le minimum des exigences nécessaires pour gérer les projets avec succès. La plupart mais non toutes les philosophies de la méthodologie TenStep soutiendront un développement prompt et rapide.

C'est-à-dire que pendant que nous valorisons les articles du côté droit, nous valorisons davantage les articles du côté gauche.

Nous suivons les principes suivants:

Notre plus grande priorité est de satisfaire le client à travers la livraison rapide et continue de logiciels valables.

La philosophie Agile encourage le développement itératif, avec les premières exigences imposées par le code du travail, suivies par plus d’exigences, et ainsi de suite. Cela est bien, mais le développement itératif n'est pas la meilleure approche pour tous les projets de logiciel. Néanmoins, quand il peut être mis en place, on devrait l’essayer.

Les changements de spécifications sont les bienvenus, même s’ils interviennent tardivement dans le développement. Le processus Agile met le changement au service de l'avantage concurrentiel du client.

Dans le cadre d’un développement itératif général, les spécifications n'ont pas besoin d'être définitivement arrêtées très tôt. Cependant, même avec le développement itératif traditionnel, à un certain point, les spécifications doivent être bloquées pour fournir quelque chose. À ce stade, le management du contenu du projet entre en jeu.

Dans le développement Agile, les spécifications peuvent changer à n’importe quel moment. L’idée est que le client peut continuer à effectuer des modifications aussi longtemps qu’il donne la priorité à ces changements au cours de l’itération appropriée. Par exemple, si le client a demandé trois rapports et qu’il en veut, plus tard, un quatrième, ce dernier rapport peut être ajouté à la liste des demandes, sans problème. A ce stade, le client donne la priorité au nouveau rapport, et s’il en est ainsi, le rapport doit être écrit. Si le budget du client est ouvert, alors il n’y a pas de processus formel de changement de contenu, et tout ce que le client veut et tout ce qu’il considère comme une priorité doit lui être livré. Si le budget du client est fixe, alors la priorité accordée à l’accomplissement d’un changement, dans son essence, signifie qu’une autre partie du travail ne sera pas réalisée. Dans ce genre de scénario, le client veut forcer la gestion de modification du contenu, en assurant que la priorité n’est accordée qu’aux modifications les plus urgentes.

L’approche TenStep affirme que lorsque des modifications interviennent, l’équipe doit être préparée à y répondre. Cependant, les modifications de spécifications ont des conséquences, en termes de budget et de dates de livraison, qui doivent être approuvées par le commanditaire. Si l’équipe agit ainsi, elle pratique le management des modifications du contenu du projet.

Délivrez fréquemment les travaux sur logiciel, toutes les semaines ou tous les mois, avec une préférence pour les échelles de temps brèves.

Le processus TenStep recommande que les grands projets soient décomposés en une série de projets plus petits, qui peuvent être livrés plus rapidement et de manière répétitive. Tous les projets n’ont pas cette flexibilité, mais, lorsque cela est possible, la préférence doit aller aux très petits projets.

Les processus Agile peuvent pousser à l’extrême le cycle court de livraison.

Certains projets de programmation extrêmes livrent selon des cycles très courts, très souvent d’une semaine. Bien que cela puisse être difficile à gérer, cette démarche n’est pas foncièrement mauvaise.

Les hommes d'affaires et les développeurs travaillent ensemble quotidiennement tout au long du projet.

C'est la meilleure approche pour rester en contact avec les besoins des clients.

Construisez vos projets autour d’individus motivés. Donnez-leur l'environnement et le soutien dont ils ont besoin, et faites-leur confiance pour qu’ils puissent réaliser leur travail.

Parfois, des personnes très motivées ont du mal à livrer les projets à temps (Deming a reconnu cela il y a un demi-siècle). Elles peuvent se concentrer un peu trop sur les détails de développement et pas assez sur la gestion du budget et des délais. Si des personnes motivées arrivaient toujours à livrer leurs projets à l'heure, il y aurait un pourcentage plus élevé de projets réussis. Parfois, vous avez besoin de placer les personnes motivées dans un environnement plus structuré où elles pourront être plus efficaces. L'auteur croit que la meilleure approche est d'établir des projets autour de personnes motivées, et de s’assurer qu’elles ont les outils, processus et qualifications qui conviennent pour réaliser le travail.

La méthode la plus efficace et la plus rentable pour transmettre des informations à l'équipe de développement et la diffuser en son sein, est la conversation de vive voix.

Il n’y a aucun doute que la communication directe est la meilleure formule dans beaucoup de circonstances. Cependant, il y a des périodes où d'autres moyens de communication sont très valables, par exemple, l’e-mail pour l’envoi de mises à jour à 20 personnes. Certaines informations pertinentes ont également besoin d’être notées par écrit pour le cas où on en aurait besoin plus tard, alors que tous les développeurs originaux seront absents. Cette documentation devrait seulement contenir les informations importantes. La documentation est rarement tenue à jour par l'équipe de soutien et pourrait perdre de la valeur au fil du temps.

Des logiciels qui fonctionnent sont le premier facteur de progrès.

Dans le cadre d’un développement itératif, le fait de disposer de logiciels fonctionnant à la fin de chaque itération est un bon moyen de mesurer les progrès. Cependant, tous les projets ne peuvent être réalisés selon une méthode de développement itérative, la mise en œuvre de packages par exemple. Aussi, dans la plupart des projets, vous pouvez continuer à surveiller le plan à l’aide des jalons majeurs de l'échéancier, pour vous assurer que vous respectez bien ce dernier.

Le Processus Agile favorise un développement durable. Les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir constamment un rythme constant.

Le développement Agile met l’accent sur une semaine de travail de 40 heures et un rythme qui peut être maintenu indéfiniment. Naturellement, avec la planification et la gestion appropriées, c'est la meilleure approche.

Une attention continue à l’excellence technique et à la bonne conception augmente la flexibilité.

L'excellence technique et l’anticipation de bonnes décisions relatives à la conception sont essentielles pour que le processus Agile puisse fonctionner.

La simplicité – l’art de maximiser l'effort de travail non fait -- est essentielle.

D’accord. Les développeurs de logiciels et les clients devraient se concentrer d'abord sur la livraison du noyau des exigences. Ceci « maximise le travail non effectué ». Cela permet également au logiciel d'être livré plus rapidement.

La méthodologie TenStep suit aussi ce modèle simple. Les projets devraient être gérés selon la taille et la complexité du travail, en tenant compte du fait que le tout le management de projet doit donner de la valeur.

Les meilleures architectures, spécifications et conceptions émergent des équipes auto- organisées.

Si chaque équipe était très performante et techniquement supérieure, il serait facile de se mettre d’accord ce point. Cependant, certaines équipes de projet ne sont pas assez mûres et n'ont pas le niveau nécessaire de compétence pour développer les meilleures conceptions et architectures. Il est important que les bonnes personnes soient choisies pour ce type de projets.

À intervalles réguliers, l'équipe réfléchit sur la façon de devenir plus efficace, puis ajuste son comportement en conséquence.

D’accord. Les équipes doivent constamment essayer de comprendre leurs forces et leurs faiblesses, et de comprendre comment les processus peuvent être améliorés. TenStep pense que ces changements recommandés devraient également se faire jour dans l'entreprise, de telle sorte que des idées d'amélioration puissent être bénéfiques pour tout le personnel.

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas www.agileAlliance.org