Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
J'ai vraiment tendance à me méfier de ce genre de rapport. J'ai l'impression que la plupart du temps, si quelqu'un critique quelque chose c'est pour vendre son produit de manière plus efficace. Je ne connais Voke mais sait-on pour une fois si les intentions de ce rapport sont honnêtes ?
Généralement pour savoir qui assume le coût, le client ou toi.Envoyé par Drawingrom
C'est valable dans un cadre forfaitaire / contrat de maintenance à faible coût. Avoir plus de régie pour la maintenance des applications et pouvoir traiter indifféremment des demandes de correction / évolution du système me semble plus efficace. En tout cas éviterait d'agiter une spec validée plus ou moins tacitement par le client sous son nez pour lui montrer que oui, tu as gagné et qu'il va repasser à la caisse.
C'est un peu léger comme base de discussion de citer 2 lignes du rapport et renvoyer vers un document facturé 100 euros. Il y a des sources qui donnent beaucoup plus de détails, comme ici :
Ce que je reproche au sondage, c'est que tous les arguments présentant les méthodes agiles comme une prise de pouvoir de la part de développeurs un peu "paresseux" sont des éléments non chiffrés. L'étude fait juste état de commentaires faits par les participants ("Survey participants report that...", "We received some unprecedented scathing and shocking comments about...") mais sans donner leur nombre ni leur proportion parmi les sondés. Du coup on a l'impression qu'il se dégage du rapport une atmosphère de crainte et de suspicion flottante sans pour autant qu'il y ait de problème quantifié derrière.
- Sixty-four percent (64%) of survey participants found the transition to Agile confusing, hard, or slow. Twenty-eight percent (28%) report success with Agile.
- Out of over 200 survey participants, we received only four detailed comments describing success with Agile.
- Overwhelmingly, 40% of participants that use Agile did not identify a benefit.
- The primary benefits identified were faster releases (14%) and more feedback (13%). Some participants (7%) also noted that Agile developers were happy due to less future planning and less documentation.
- Survey participants report that developers use the guise of Agile to avoid planning and to avoid creating documentation required for future maintenance.
- We received some unprecedented scathing and shocking comments about the level of competence, professionalism, and attitudes of some members of the Agile movement.
- Be aware that the Agile movement might very well just be either a developer rebellion against unwanted tasks and schedules or just an opportunity to sell Agile services including certification and training.
Les auteurs de l'étude semblent atteints de la même inquiétude quand ils émettent l'hypothèse que les méthodes agiles pourraient être un prétexte des développeurs à freiner des 4 fers pour écrire de la documentation ou suivre un process :
Maisthe Agile movement might inspire and encourage developers to push back on processes, tools, documentation, and following plans
1/ Le manifeste agile n'a jamais dit qu'il ne fallait pas de doc, mais la juste quantité de doc, et que celle-ci est peut-être moins prioritaire qu'avoir un logiciel qui marche. Pareil pour les process et les outils. Donc il y a un garde fou "officiel" en cas d'abus éventuel des développeurs.
2/ Si à chaque suggestion d'un développeur on est paralysé par la pensée qu'il est motivé par la fainéantise, on va se couper des bonnes idées venues du terrain et uniquement faire de l'Agile "venu d'en haut" ce qui va drastiquement limiter l'intérêt et l'effet d'une adoption agile.
Donc non, l'agilité n'est pas "developer-centric" (gros contresens de l'étude). Ce sont juste des solutions hyper pragmatiques, et dans pragmatique il y a "on ne regarde pas d'où ça vient du moment que c'est efficace".
+1En quoi les méthodes Agile n'impliquent pas la rédaction d'une documentation?
Il suffit d'inclure la documentation dans le process. Là où je travaille, une tâche de documentation est systématiquement ajouté à chaque item et obligatoire pour la validation d'une fonctionnalité.Je pense qu'un des problèmes majeurs avec la doc est de la garder à jour.
C'est toujours pénible d'avoir à penser à remettre à jour la doc au fur et à mesure des avancées du projet, et au final, comme elle est souvent désynchronisée, elle finit par être presque abandonnée (ou pire, elle est faite juste parce que ca fait parti des livrables, mais sans réel envie qu'elle soit utile).
Et avec les méthodes agiles, comme on livre de plus en plus souvent, cette désynchro est de pire en pire.
Si tu fait autant d'heure supp. avec la métode agile c'est que me cycle de l'itération est trop longEt ben si les méthode AGILE sont un moyen habile de faire faire au salarié 50h au lieu de 35, il faut en effet les interdire au plus vite. Car faire du travail gratuit, c'est du vol
+1Pour répondre plus directement à la question : montrez moi un développeur qui n'est pas content de l'agile, je vous montre un projet qui n'est pas agile.
+1Donc pour moi l'agile, si c'est vraiment appliqué, ne pose aucun problème aux développeurs, elles permettent même un gros gain mais elles demande une éducation des clients et de l'implication. Si les méthodes ne sont pas vraiment appliquées, elles deviennent effectivement un problème pour l'équipe à qui on demande d’être plus réatif et plus "agiles" sans amélioration réelle des méthodes de travail ...
Non, c'est plus visible et direct dans le cadre d'un forfait mais ça reste valable dans d'autres cadres même si ça se manifeste différemment :
- En régie, ça va plutôt se concrétiser par une demande de geste commercial ou de la réduction du taux journalier (avec en cas de blocage par un non-renouvellement/remplacement de la ressource par une autre société voire un déréferencement).
- Dans le cadre d'un COTS : je connais beaucoup de personnes prêtes à racheter une licence pour avoir de nouvelles fonctionnalités, peu pour avoir la correction de bugs.
- En interne : les budgets maintenance, projet, évolution, etc. sont souvent différents (et encore je ne parle pas du reflet sur l'évaluation personnelle et donc primes et augmentation de cette distinction).
C'est pragmatique tant que l'on n’essaie pas de les appliquer systématiquement, intégralement, conformément au bouquin à la virgule prêt, sans recul ou pour une mauvaise raison.
Je pense que c'est le plus gros problème de ces méthodes : non la méthode en elle-même mais la mauvaise application de celle-ci qui en est trop souvent (du moins par rapport à mon constat personnel) faite.
Ce que je pense pour ma part c'est que les méthodes agiles sont faites pour éviter ceci: http://ocaoimh.ie/ocaoimh/2005/02/Th...re-project.jpg
En effet, l'industrie du développement de logiciels est probablement la seule où un projet n'est jamais proprement définit et fixé dès le début. Dans la construction de bâtiments par exemple, il est extrêmement rare de revoir complètement les plans d'un bâtiment alors que la construction est déjà commencé, quand tu as commencé un projet, tu le finis tel qu'il a été présenté.
Alors qu'en développement c'est l'opposé, les clients donnent des spécifications vagues, tous les détails n'y sont pas, le client ne pensent pas à tous les problèmes et ses solutions couvrent rarement tous les cas, mais on doit quand même commencer à développer immédiatement pour éviter de perdre du temps.
Les méthodes agiles permettent de pallier à ce problème en maintenant constamment la communication entre les clients, les managers et des développeurs afin que tous les problèmes puissent être couverts rapidement, et que le projet puisse avancer sans avoir un tout mettre par terre chaque fois que le client a une nouvelle idée.
méthode agile : pas de documentation
Les points de vue exposés me paraissent étranges, en effet les méthodes agiles ne prévoient pas vraiment de documentation, considérée comme une perte de temps, mais un code bien commenté et évolutif.
Donc le rapport Voke enfonce une porte ouverte, car du point de vue des auditeurs les méthodes agiles sont un cauchemar ...
Ainsi, à chaque fois que j'audite une société avec des projets s'appuyant sur une méthode agile, on ne me fournit aucune documentation et la réponse de la société est invariable : il faut que vous alliez discuter avec nos développeurs et ils vous expliqueront !
Bien sûr qu'ils m'expliquent et bien sûr que c'est un vrai bonheur pour moi que de me retrouver à bavarder côté cuisine et découvrir les recettes de leur code avec des gars passionnés et passionnants !
Seulement, un audit sérieux prend alors six mois au lieu d'une semaine et mon boss fait des bonds ...
Alors, en tant que développeur, les méthodes agiles ont très largement ma préférence, mais en tant qu'auditeur, je préfère une bonne vieille méthode présentant un dossier complet de programmation, avec analyse organique et fonctionnelle !
Superbe !Ce qui constitue pour moi le coeur des méthodes agiles :
Cycle de développement court
Développement itératif
Implication de représentants métiers du début à la fin du projet
Outillage du code avec des tests automatisés
Adaptation au changement en cours de route
Le proverbe dit que l'enfer est pavé de bonnes intentions... Je trouve que c'est un bon exemple....
Pour ce qui est de "l'Implication de représentants métiers du début à la fin du projet." En effet, c'est le top mais ça n'arrive que dans le meilleur des mondes.
Pour "Outillage du code avec des tests automatisés", C'est indispensable mais encore faut-il avoir bien défini ce doit faire le code. Je vois plus souvent passer d'erreurs d'algorithme que d'erreurs de codage. En général, si ça compile sans warning et que ça ne fait pas ce qui est attendu, c'est qu'il y a un problème de conception... pas de codage...
Concernant le reste , voilà en gros un résumé de tout ce que je déteste dans l'informatique, non seulement en tant que développeur mais également en tant qu'utilisateur.
Concernant le développement itératif, c'est très beau sur le papier mais en général ça se termine par "On va faire un truc à l'arrache très mal fait, sans tenir compte des contraintes futures (pourtant majoritairement prévisibles) pour tenir le delais de la release. On sera obligé de le refaire de zéro ensuite, et comme on manquera de temps ça sera fait tout aussi à l'arrache et ainsi de suite.
Concernant le cycle de développement court. Ça pose un réel problème de formation des utilisateurs. Généralement on a pas fini de former les utilisateurs à la version N du produit qu'on en est déjà à la N+3. (Il ne faut pas non plus oublier le temps de formation du formateur)
Quand on est développeur on ne peut rien construire de pérenne en se basant de tels projets car on passe plus de temps à s'adapter à leurs évolution qu'a avancer soi-même. Un cas typique est que l'on supplée aux fonctions manquantes dans une itération en les faisant soit même et quelques semaines ou mois plus tard, on doit tout jetter et prendre en compte leur implémentation (parfois décevantes pour les raisons "l'arrache" précitées) du projet "source".
Enfin, les adaptation au changement en cours de route.... Ah! Ca, c'est le gâteau sur la cerise ! J'ai eu un boss qui appelais ça un "Cahier des charges dynamique" (sic) Et dans son esprit, le dynamisme se situait dans la faculté à s'adapter à des changements de la demande à l'échelle de la semaine, très souvent de la journée, et parfois même de l'heure. Qu'est-ce donc si ce n'est la négation même du concept de cahier des charges ? J'avoue que j'éprouve une certaine forme de fierté malsaine à avoir fait partie du cercle relativement restreint des entreprises qui ont finalement eu recours à un wiki pour leur CDC. (médiawiki pour ses fonctions de versionning / diff / rollback)
Et si l'industrie du développement de logiciels est la seule dans ce cas, c'est justement parce que c'est possible sans frais apparents, précisément à cause de ce genre de méthodes adaptatives... N'importe qui peut comprendre que changer le plan d'une maison une fois qu'on a fini les fondations, ça donne tout au mieux une maison mal conçue. N'importe qui peut comprendre que si on casse tout, ça veut dire que tout le béton précédent était de l'argent gaspillé et qu'on repart de zéro....En effet, l'industrie du développement de logiciels est probablement la seule où un projet n'est jamais proprement définit et fixé dès le début. Dans la construction de bâtiments par exemple, il est extrêmement rare de revoir complètement les plans d'un bâtiment alors que la construction est déjà commencé, quand tu as commencé un projet, tu le finis tel qu'il a été présenté.
Dans l'esprit du client, les lignes de codes, n'ont pas de réelle valeur. Il ne vois pas la partie immergée de l'iceberg et ne comprends pas pourquoi vous ne pouvez pas lui faire gratuitement ce "petit" changement de rien du tout... D'autant plus que les commerciaux se tuent à lui expliquer que l'informatique d'aujourd'hui, c'est dynamique, souple évolutif et facile, Qu'on est des vrais pros, ultraréactifs, à la pointe de la technologie, qu'on s'adapte et qu'on l'accompagne dans son projet de façon proactive. Ajoutez à cela 2 ou 3 épisodes de séries américaines genre "NCIS" ou "les experts", où on voit les dieux du hack croiser des infos de 25 bases de données improbables en 12 secondes chrono tout en faisant la conversation... il ne faut pas être surpris par le comportement du client.
Or, être performant et s'adapter à la demande changeante et mal formulée du client, c'est justement cultiver cet affreux penchant...
Je pense que nous sommes sur la même longueur d'onde, les problèmes qu'essaye de résoudre les méthodes agiles sont dus à ce fantasme que l'informatique c'est facile pour les gens qui sont dans le métier et que n'importe qui peut s'y mettre et devenir un pro en mois d'une semaine.
Là est le vrai fantasme à l'origine de tout ce bordel.
Super... Ils viennent de découvrir la roue!!!! Félicitations. Tout le monde sait que les méthodes agiles servent de paravent contre le cahier des charges, l'analyse, la documentation... En clair, tout ce qui n'est pas du codage pur et dur. Attention, ça ne veut pas dire que c'est ce qu'elles sont réellement, mais elles servent d'alibi contre tout ça. Très franchement ça fait 10 ans que c'est le cas, et tous les développeurs sont au courant. Alors le dire aujourd'hui, quelle blague!
La rapport de Voke me fait un peu penser à une loi créée par un ministre pour les agriculteurs alors qu'il n'a jamais vu une vache de sa vie. Ah que ne ferait pas certains pour graver leur nom dans le marbre.
Il y a bien évidemment de la rédaction de specs sauf qu'au lieu de rédiger des specs de tout le projet qui va foirer au final, on rédige les specs des fonctionnalités qui vont être planifiées dans le sprint à venir.
Quant à la documentation fonctionnelle, je pense que personne chez Voke n'a du suivre un projet en SCRUM et n'a donc pas la notion de "Done"; vous savez, la fameuse suite des états d'une tâche qui dit quand celle-ci doit être considérée comme terminée !
LOL. Quand on pense que ces cabinets sont payés (grassement?) on pourrait augmenter les salaires des développeurs et "scrum master".
L'évolution est en marche
J'aimerai connaître le type de l'échantillon des sondés, car aujourd'hui la plupart des chef de projet sont des gens formés aux anciennes méthodes (type cycle en V et GANTT), surtout dans les grandes boîtes avec une batterie de développeurs "fonctionnaires".
Or l'explosion des technologies qui se trouvent disponibles aujourd'hui sur le marché (libre ou pas) imposent une adaptation des développeurs qui peuvent être amenés à travailler avec des environnements très hétérogènes.
Les méthodes agiles répondent à ce contexte et au fait que la réactivité prime aujourd'hui devant un problématique d'évolution des produits existant ou à créer.
Je sais que personnellement la contrepartie de l'innovation et du partage dans l'équipe de développement est la documentation. La documentation est très présente dans l'exploitation de cette méthode et s'en trouve indispensable dans la compréhension globale du produit et ses maintenance et évolution.
La "papy boom" va laisser place au sang neuf et aux méthodes qui satisfassent les développeurs au quotidien et le client dans le produit final.
C'est tout à fait inexact. Les méthodes agiles accordent plus de valeur à un logiciel qui fonctionne qu'à une documentation exhaustive, mais ça ne veut pas dire que toute documentation est proscrite.
C'est un truc que les agilistes répètent depuis des lustres, mais pour une raison qui doit tenir aux mystères du cerveau humain, quand les gens entendent "X est prioritaire sur Y", ils traduisent "on ne fait pas Y".
En gros tu préfères quand une grosse partie du boulot est déjà faite pour toiAlors, en tant que développeur, les méthodes agiles ont très largement ma préférence, mais en tant qu'auditeur, je préfère une bonne vieille méthode présentant un dossier complet de programmation, avec analyse organique et fonctionnelle !
Plus sérieusement, la fonction première d'une entreprise est de produire du code qui fonctionne afin de livrer à ses clients des applications qui le satisfont pleinement. Le fait d'écrire des dossiers d'analyse, d'architecture ou que sais-je n'est qu'un sous-produit de cela. Peut-être qu'on peut les écrire avant le dev, peut-être après. Peut-être qu'on peut ne pas en écrire du tout, ou le minimum possible.
Dans tous les cas, une entreprise qui met la priorité n°1 sur le fait que la documentation doit être complète et la priorité n°2 sur livrer des applis qui satisfont le client me parait dysfonctionnelle.
Parce qu'en partique c'est ce qui se passe.pour une raison qui doit tenir aux mystères du cerveau humain, quand les gens entendent "X est prioritaire sur Y", ils traduisent "on ne fait pas Y".Ce n'est pas qu'on reffuse de faire Y, c'est juste qu'on le fera "plus tard" parce que ça n'est pas prioritaire. Et une fois qu'on sera plus tard, Y ne sera toujours pas prioritaire par rapport à un nouveau X et ainsi de suite.
En théorie oui mais en pratique c'est plus souvent de produire du code qui fonctionne dans les cas prévus (On prendra bien soin de bâcler l'analyse dans l'évaluation des possibles) afin de livrer à ses clients des applications satisfaisantes mais pas trop non plus pour laisser la possibilité de vendre une nouvelle version améliorée.la fonction première d'une entreprise est de produire du code qui fonctionne afin de livrer à ses clients des applications qui le satisfont pleinement.
La fonction première d'une entreprise est de produire du code fonctionnel ET maintenable.
Or parfois, par exemple, mon équipe récupère des applis qui sont très belles et fonctionnelles, que le client porte aux nues et il déchante quand il apprends que la moindre évolution va lui couter un bras car il n'ya pas de doc, que les gars qui ont monté l'appli ne sont plus là et que le code est affreux !!
Attention, je modère mes propos.
Je ne dis pas que Méthode Agile => Solution non maintenable
Je dis Méthode Agile => Plus de flexibilité => Plus de latitude AUSSI pour faire de la m****
Justement, l'approche agile fournit un cadre qui permet de découper le logiciel en tranches fonctionnelles complètes et de faire à la fois le travail de priorité 1 et de priorité 2 dans une tranche. On évite ainsi l'effet "Saint-Glinglin".
Concrètement, dans une itération, on met tout ce qui est nécessaire à la production d'un incrément logiciel. Si on considère qu'un certain niveau de doc est nécessaire, on met des tâches de doc dans l'itération avec le temps nécessaire en face. On les fait juste après le dev.
Les deux ne sont pas incompatibles, au contraire. En fait, tu viens de décrire le principe même de l'agilité. Le plan parfait n'existe pas, et nous ne sommes pas voyants pour savoir ce dont aura besoin le client à l'instant T+1, donc on produit ce qui a le plus de valeur pour lui à l'instant T. Il sera toujours temps à T+1 de voir comment de nouvelles fonctionnalités peuvent être ajoutées s'il le souhaite.
C'est clair, assumé, les deux parties y gagnent
Je ne sais pas dans quelle entreprise tu travailles, mais j'aimerais bien connaître son nom pour ne jamais postuler !! LOL
En tant que "scrum master" j'ai l'habitude de livrer des versions stables et qui fonctionnent, bien codées et... entièrement documentée !
Le Scrum c'est comme PHP, c'est permissif. Donc tu peux vite comprendre mais de là à l'utiliser comme il faut... de l'eau va couler sous les ponts. Je suis entrer en conflit avec un chef de projet classique parce qu'après deux jours de stage sur SCRUM, il croyait tout savoir et m'expliquer comment gérer les projets en scrum !
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager