Qu'est-ce qui rend le développement logiciel Agile si attrayant?

Le développement de logiciels agiles est devenu un mot à la mode assez amusant de nos jours.

En tant que développeur, je comprends la valeur pragmatique du développement itératif, mais (le plus souvent) ce n'est pas le choix des développeurs d'adopter une approche Agile du développement logiciel. C'est un choix de gestion top-down! Que ce soit du cristal, des méthodes agiles, dsdm, rup, xp, scrum, fdd, tdd, vous l'appelez. Ce n'est pas un choix de développeur.

Pour tous les managers, quelles sont les principales raisons de choisir de faire du développement Agile alors que (selon mon expérience) la plupart des managers n'ont même pas touché un morceau de code dans leur vie!

Exigences changeantes, livraison plus rapide

Agile est attrayant car il donne la possibilité de s'adapter aux besoins changeants plus rapidement (ou pas du tout) et de fournir ces changements au client plus rapidement.

C'est pourquoi de nombreuses entreprises échouent lors de l'utilisation d'Agile / Scrum: les responsables ne comprennent pas qu'avec une grande puissance (de fixer des dates de sortie plus rapides et de changer souvent les exigences), il est de la responsabilité de s'appuyer sur les développeurs pour les estimations . Pour que l'agilité fonctionne, le gestionnaire doit être disposé à réduire la portée.

Ils veulent le pouvoir des deux.

Suivre les tendances

Parfois, les gens font des choses, non pas à cause du mérite de ce qu'ils entreprennent (agile), mais simplement parce que c'est populaire et que d'autres essaient de faire de même.

"Quoi? Macrojam fait Agile? Pourquoi ne sommes-nous pas? Nous ne sommes pas lents, nous sommes Agiles, bon sang!"

Certaines personnes ne se soucient pas vraiment de ce que signifie être agile. Ce n'est qu'un moyen de justifier leur existence. Moutons, pression des pairs, etc.

Le codage lui-même n'est pas la principale raison pour laquelle les gestionnaires peuvent être convaincus de choisir l'agile comme méthode. Le fait que vous puissiez réagir plus rapidement à l'évolution des exigences et des priorités est séduisant. En fin de compte, le «manager» doit fournir une solution à l'utilisateur final / client / à son manager.

Si la fonctionnalité qui semblait essentielle au démarrage du projet peut être supprimée en cours de projet et remplacée par de nouvelles exigences plus pertinentes, c'est un avantage majeur.

Il est également important que la plupart (par exemple, comme dans la mêlée) chaque livraison intermédiaire soit presque prête à être mise en production. Dans le même temps, les fonctions les plus urgentes ont été développées en premier. Donc, dans le cas où le projet est annulé en raison d'une décision d'entreprise, la direction est sûre que vous vous retrouverez avec quelque chose qui fonctionnera et pourra être mis en production.

J'espère que cela t'aides.

Augmentez la visibilité sur ce qui se passe et augmentez la productivité

1. Les managers sont généralement intéressés par la visibilité qu'apporte l'agilité, en particulier avec la mêlée. C'est l'un des arguments de vente les plus utilisés dans les séminaires destinés aux managers.

2. Une productivité plus élevée est également couramment utilisée pour les attirer car elle est facile à démontrer (grâce à la visibilité). Certains évangélistes agiles leur promettent une productivité exceptionnelle de leurs employés existants. "Quoi? Je les presse déjà comme des citrons et tu me dis que je peux en avoir encore plus " ?

De nombreux managers utilisent l'agile pour écraser un peu plus leurs employés et je les ai vus utiliser le tableau de combustion comme machine de chasse de fainéants dans une grande entreprise.

Résultat? Beaucoup d'équipe distress. Ils pensaient que l'agilité résoudrait tous leurs problèmes, mais c'est exactement le contraire. Le problème était ailleurs.

Je lutte activement contre cela. C'est pourquoi parfois là où il y a une forte probabilité que la méthodologie agile soit pervertedpar la direction, je suggère de ne pas le mentionner au sein de l'entreprise.

La réponse à cette question pourrait remplir un livre.

Je pense que l'une des principales raisons est que le développement agile se concentre sur le livrable. Il se concentre toujours sur la livraison de ce qui est le plus urgent ici et maintenant.

Une autre raison est que les pratiques de planification et d'estimation basées sur l'histoire que les processus agiles suivent donnent une bien meilleure estimation de ce qui peut être livré et quand.

Un bon exemple de l'efficacité de la planification basée sur l'histoire est un projet sur lequel j'ai travaillé. Pendant quelques mois (avant d'adopter le développement agile), le chef de projet a cru que nous pouvions livrer à temps, et c'était environ 18 mois après la date limite. Tous les développeurs avaient le sentiment que c'était probablement irréaliste. Après avoir commencé la planification agile, le chef de projet avait toujours une évaluation optimiste de la situation. Mais seulement après quelques sprints, le chef de projet s'est rendu compte que l'équipe n'avait tout simplement pas la capacité de répondre à toutes les exigences dans les délais prévus. Et c'était encore plus de 12 mois à compter de la date limite.

Les pratiques agiles rendent donc la réalité plus claire bien plus tôt.

Et enfin, les équipes agiles ont tendance à adopter plus souvent des pratiques qui créent une meilleure qualité de code, par exemple un développement piloté par les tests, une refactorisation fréquente, une intégration continue, la révision du code par les pairs / la programmation par paires, etc. ne pas être tellement au point.

la plupart des managers n'ont même pas touché un morceau de code dans leur vie!

J'ai été développeur pendant 12 ans et maintenant gestionnaire pendant 5. Au cours des 5 années, je suis passé progressivement d'un gestionnaire qui codait toujours à un gestionnaire purement (je corrige encore parfois des bogues ou fais des exercices de prototypage).

quelles sont les principales raisons de choisir de faire du développement Agile

• Visibilité ou Réussite rapide / Échec rapide - Nous sommes une boutique de développement de produits avec des cycles de 6 à 24 mois. Le développement itératif avec des fonctionnalités fonctionnelles et testées a mieux reflété l'état du projet.
• Changement - Dans notre environnement, les exigences et le temps ont tendance à être fixes. Mais, l'entreprise passe trop régulièrement par des changements de direction rapides et discordants. Un développement itératif et visible a permis aux projets de changer de direction plus facilement.
• Les exigences basées sur des histoires avec un développement itératif ont facilité la collaboration avec l'entreprise qui ne comprenait pas toujours les aspects techniques des exigences ou ne comprenait pas pleinement les moteurs de certains détails. Dans nos efforts passés, des spécifications de haut niveau ou des documents d'exigences marketing n'étaient pas toujours suffisants. Maintenant, à mesure que les projets évoluent, il peut y avoir des recherches parallèles sur le marché et les clients.
• Le changement de processus est venu avec beaucoup d'autres attributs de développement comme TDD, tests automatisés par rapport à manuels, cycles de test plus serrés (nous n'avons plus de groupe QC, juste un groupe QA), et une appréciation et des efforts plus élevés liés à la qualité (nous utilisons un beaucoup plus d'outils et de métriques).

Nous aurions pu y parvenir par d'autres moyens, mais tirer parti des méthodologies et des idées agiles nous a énormément aidés.

Nous continuons également à affiner notre processus. Par exemple, l'équilibre entre le travail de conception initial par rapport à la conception juste avant la mise en œuvre. Nous examinons régulièrement toutes nos décisions pour déterminer si nous aurions pu différer les décisions de conception antérieures. Et, lorsque les choses tournent mal, combien de travail supplémentaire aurait été nécessaire jusqu'à ce que l'erreur soit identifiée. Souvent, les échecs sont des cas extrêmes qui nécessitent une analyse approfondie. L'effort pour obtenir ce détail est souvent le même que le coût de le comprendre en cours de route et de refactoring. Les équipes ne sont pas pénalisées pour ces types d'erreurs et encouragées à être plus agressives.

J'ai vu un certain nombre d'entreprises «faire» de manière agile. Malheureusement, très peu d'entre eux adoptent l' agilité. Ce que je veux dire, c'est simplement faire du développement itératif et des standups quotidiens (où la plupart de l'équipe s'assoit) ne rend pas l'équipe agile. TDD, Refactoring, Intégration Continue, Présence Client, les pratiques SOLIDES rendent une équipe Agile. Sans ceux-ci, vous tournez juste en rond.

Il y a beaucoup d'appel que le message d'Agile apporte. L'adaptabilité au changement étant la plus importante. Malheureusement, votre code ne devient pas plus adaptable simplement parce que vous changez la façon dont vous gérez le projet. Jusqu'à ce que davantage d'entreprises le réalisent, nous entendrons simplement parler de plus en plus de projets agiles qui ont échoué.

Je ne connais pas la partie mot à la mode. J'ai vraiment fait cela tout au long d'un processus pas si formalisé ou identifié. J'ai eu des clients qui regardent littéralement par-dessus mon épaule pendant que je construisais leur site Web. Sauvegardé environ 50 e-mails et le client a appris quelque chose sur ce processus - ce n'est pas facile.

L'idée entière que nous prendrons une longue période de temps pour écrire tout ce que l'utilisateur veut que le logiciel fasse, puis prendre plus de temps pour construire ce que nous pensons qu'ils veulent seulement découvrir dans les 2 secondes après avoir essayé l'application que cela n'est pas ce qu'ils attendaient est nauséabond. À quel point est-il difficile de diviser un projet ou une application en éléments raisonnables à construire et à obtenir des commentaires avant de créer un autre élément?

Je sais que c'est une simplification excessive et ne répond pas aux pratiques réelles des développeurs, mais il n'est pas difficile de vendre même au gestionnaire ou au client le moins technique. Quelle autre approche est plus attrayante? Est-ce que les clients aiment vraiment le fait que les programmeurs soient hors de leurs cheveux pendant 6 à 12 mois alors qu'ils se développent au cours d'un projet de cascade? Souhaitez-vous embaucher quelqu'un pour construire une maison de cette façon?

La direction n'impose pas ces choses aux développeurs. Les développeurs et les équipes doivent prendre des initiatives et s'efforcer de les aider à mieux faire leur travail. Le travail de la direction consiste à soutenir ces initiatives.

En tant que manager qui a écrit pas mal de code dans ma carrière, je ne suis peut-être pas la personne que vous recherchez pour y répondre. Quoi qu'il en soit, je pense que l'attrait pour Agile de nos jours a le plus à voir avec la réponse plus rapide aux besoins des clients ainsi que la réduction de la boucle de rétroaction entre les spécifications, le codage, les tests et le client. Nous nous dirigeons vers un développement plus agile pour ces mêmes raisons.

Je pense que vous ne devriez pas gâcher le processus Agile et les pratiques de codage / développement. Par exemple, Scrum ne vous dit pas comment développer votre code - tout dépend du processus qui accueille les changements.

À la fin de la journée, il s'agit de responsabiliser le développeur; il s'agit de reconnaître le fait que ces gars qui sont tout en bas de la hiérarchie sont les seuls à vraiment comprendre l'étendue de ce qui doit être fait et comment le faire, donc si vous les avez déjà embauchés pour leur expertise - pourquoi ne pas les laisser prendre le contrôle total ou plutôt, pourquoi les éloigner de la prise de décision réelle?