Agilité

SABOTAGILE! MANIFESTO

Manifeste pour le sabotage du développement logiciel Agile

Nous défendons le Status Quo et visons à défendre nos carrières,
les experts de l’industrie ont découvert les techniques suivantes
permettant de simuler l’agilité sans rien changer en pratique.

Ce faisant nous en sommes arrivés à valoriser:

1) L’Engagement contractuel de responsabilité via des spécifications, des dates et des coûts fixes et prédéterminés plutôt que les individus ou les interactions.

2) Le suivi de l’état d’avancement des projets et des programmes à partir de diagrammes de Gantt, de pourcentages de complétion et de tableaux de bord synthétiques Rouge/Orange/Vert plutôt qu’un logiciel qui marche.

3) La définition de processus rigoureux avec des Dates de Livraison, des Recettes Partielles et des traces auditables plutôt que la collaboration avec le client.

4) Empêcher l’émergence du chaos et bloquer tout changement plutôt que l’adaptation au changement.

Nous reconnaissons que les méthodes de développement Agile fonctionnent peut-être pour d’autres et
nous acceptons d’utiliser son vocabulaire car c’est la mode du jour, mais en aucun cas nous ne changerons de comportement. Nous sommes des gens sérieux, nous construisons et déployons des logiciels dans le monde réel à notre manière depuis des décennies et nous avons la ferme intention de continuer à faire exactement pareil à l’avenir que ça soit efficace ou pas.

PRINCIPES SABOTAGILE!

Principes sous-jacents au manifeste Sabotagile!

Nous suivons scrupuleusement ces principes:

  • 1) Notre priorité absolue c’est que nos ressources informatiques livrent les fonctionnalités promises, auxquelles nous nous sommes contractuellement engagés, dans les temps et sans dépassement de budget.

2) Tout écart par rapport au plan initial doit être repéré et réprimé. Nous obligerons les développeurs à tenir leurs engagements sans décaler les livraisons prévues.

3) Nous pouvons augmenter l’efficacité des développeurs et réaliser des économies d’échelle en livrant moins souvent des produits plus riches fonctionnellement. Les livraisons intermédiaires sont inutiles.

4) Toujours passer par des intermédiaire entre les commerciaux et les développeurs. Les commerciaux peuvent ainsi se concentrer sur les clients et accomplir un vrai travail.

5) Utiliser le talent de prévision des managers, les objectifs de performances individuels et les courbes de Gauss pour maximiser la productivité des ressources.

6) Le mode privilégié de communication avec les équipes de développement passe par des spécifications écrites, des documents de référence et les e-mails. Ceux-ci laissent des traces auditables et forcent les développeurs à tenir leurs engagements.

7) La mesure des progrès réalisés c’est le tableau de bord synthétique de la direction qui répertorie les fonctionnalités prévues mises dans le produit.

8) Les développeurs travaillent tard le soir, les week-ends et annulent leurs congés pour tenir les deadlines.

9) Les développeurs tiennent leurs engagements en mettant le produit en production le jour dit, puis en fournissant rapidement les correctifs de bugs aux clients.

10) Profiter des économies d’échelle en s’assurant que les ressources mettent autant de fonctionnalités que possible dans chaque version. Même si personne ne les utilise c’est toujours bien sur la fiche technique.

11) Mieux vaut embaucher à prix d’or des Architectes Logiciels brillants pour concevoir le produit, des développeurs débutants moins coûteux pourront se charger de la réalisation sous leur direction.

12) A la fin du projet – si le temps le permet – on peut envisager des analyses postmortem avec les ressources, bien entendu ça ne doit pas affecter pas la capacité des ressources à accomplir un vrai travail.

13) Apporter une certaine fraicheur aux ressources en utilisant à leur intention le vocabulaire à la mode cette décennie, que ce soit pour décrire les processus, mettre à jour les manuels de procédure, ou bien dans les formations ou les communications de la direction, ceci sans changer en rien notre manière de penser ou nos comportement.

Ceci est une simple traduction, je fournis les liens vers le contenu original:
http://smoothapps.com/index.php/2017/01/sabotagile-waste-loss-challenge/
http://smoothapps.com/index.php/2016/11/sabotagile-quotient/

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s