Share
Développement agile ou agile - nous entendons ces mots plus souvent ces temps-ci. Mais savons-nous vraiment de quoi il s'agit? Comment cela peut-il nous aider à devenir plus efficaces, tout en ayant beaucoup de plaisir à développer des logiciels? Comment pouvons-nous l'utiliser pour communiquer avec les gens d'affaires et rendre cette communication facile et constructive des deux côtés?
Il y avait un groupe de gars très talentueux et expérimentés développant des logiciels sérieux. Ces développeurs ont observé d'autres sociétés et équipes de développement et ont expliqué comment leurs processus facilitaient leur travail. Ils ont compilé leurs observations pour créer le Manifeste Agile. Et ils ont dit:
Nous découvrons de meilleures façons de développer un logiciel en le faisant et en aidant les autres à le faire. Grâce à ce travail, nous avons pu valoriser:
C'est-à-dire que, s'il y a de la valeur dans les éléments à droite, nous valorisons les éléments à gauche plus.
Dans cet article, je présenterai douze théories et techniques de développement agile. Ceci est juste la première étape dans le nouveau monde du processus de développement logiciel.
Notre plus grande priorité est de satisfaire le client par la livraison précoce et continue de logiciels de qualité, mais non complets. Cela signifie que nous développons des logiciels et ajoutons au moins une fonctionnalité par itération..
Imaginons que nous voulions créer un moteur de blog; nous pourrions le faire en utilisant le processus suivant:
C'est une approche simple, mais le client voit les progrès réels de son logiciel et vous donne un retour immédiat sur chaque nouvelle fonctionnalité. Il peut être parfait ou nécessiter quelques ajustements, mais vous pouvez réagir rapidement aux changements: une situation gagnant-gagnant.
Même à la fin du cycle de développement, les processus Agiles vous permettent d’accepter des changements pour renforcer l’avantage concurrentiel du client..
Le client souhaite que le projet soit terminé rapidement et le plus près possible du projet. Ceci est facilement réalisé en écoutant simplement leurs commentaires et en étant prêt pour les changements. Si nous sommes en mesure de réagir rapidement à l'évolution des exigences, nous sommes probablement le meilleur choix que notre client ait jamais fait. Agile est synonyme de communication et de changement. Nous faisons les choses comme on nous le demande, accélérant ainsi le processus de développement logiciel. Ceci est réalisé parce que nous développons de petits logiciels et qu’une modification des exigences ne nous affecte pas vraiment..
Nous devrions fournir des mises à jour de quelques semaines à quelques mois; plus la durée est courte, mieux c'est.
les clients se sentent plus confiants en nous et en notre produit à mesure de sa mise à jour
D'après mon expérience, les clients se sentent plus confiants en nous et en notre produit au fur et à mesure de sa mise à jour, ce qui est vital pour notre relation avec eux. Un autre avantage est la réaction de notre client. nous permettant de réagir en changeant de classes, de fonctionnalités, de modules ou même d’architecture. Nous ne nous réveillerons pas après des jours ou des mois de travail, seulement pour voir que tout va à la poubelle. Considérons une situation hypothétique:
Vous avez été invité à créer un module qui affichera un texte simple dans un gestionnaire de contenu. Soudainement, les exigences changent et vous devez ajouter un formulaire qui devrait envoyer un courrier électronique à une adresse configurée. En outre, le formulaire doit être personnalisable afin que l'utilisateur puisse ajouter de nouveaux champs et définir des validateurs. Donc, vous devez essentiellement oublier l'exigence de texte simple d'origine. Quand voudriez-vous savoir ce changement??
Si vous travaillez sur un projet avec votre client et livrez souvent, vous connaîtrez ces changements plus rapidement et ces changements deviendront plus faciles pour vous deux..
Ceci peut s'avérer être le principe le plus difficile auquel il est difficile de s'habituer, si vous avez développé un logiciel dans le style de l'ancienne cascade. En tant que développeur, vous ne parlez généralement pas la même langue que votre client, mais vous pouvez trouver le moyen de maintenir une communication significative avec eux. Une des meilleures façons, à mon avis, est de tout décrire avec une histoire simple qui nous dit, au développeur, à qui est destinée la fonctionnalité, quelle est sa responsabilité et pourquoi nous en avons besoin. Bien sûr, cela devient plus facile à mesure que nous travaillons avec notre client. Le développement dirigé par le comportement (BDD) est une autre approche utile, mais il s'agit d'un sujet pour un article différent..
Donnez aux personnes avec qui vous travaillez l'environnement et le soutien dont elles ont besoin et, surtout, faites-leur confiance pour faire le travail.
Il est important de créer une atmosphère attrayante et de disposer de tous les outils nécessaires pour créer de bons logiciels. Les entreprises perdent leurs meilleurs travailleurs principalement parce qu'elles ne s'en soucient pas vraiment. La conviction selon laquelle les développeurs peuvent écrire, tester et déployer des logiciels sur certains serveurs à l'aide d'un client FTP et de l'édition de fichiers de production réels a été perdue quelque part. Si vous n'avez pas condamné ces vieilles habitudes scolaires, vous feriez mieux de le faire maintenant.
Conserver les employés n’est qu’un avantage; vous pouvez également développer des logiciels plus volumineux et de meilleure qualité à un rythme plus rapide. Pensez-y: l'écriture de code réutilisable, de tests automatisés et d'un déploiement automatisé sur n'importe quel serveur (entre autres) peut avoir un impact positif sur le temps de développement. Nous pensons généralement ralentir un projet parce que nous devons apprendre à utiliser des outils utiles, tels que Jenkins, GIT, SVN, Gerrit, Behat, etc. Franchement, nous le faisons, mais nous pouvons ensuite réutiliser ces outils et concepts dans des projets futurs..
C’est la méthode la plus efficace pour transmettre des informations à nos clients et à notre équipe de développement..
Qui n'a pas été submergé et / ou en colère en voyant 6 255 384 courriels dans votre boîte de réception, car votre entreprise exige que toutes les conversations soient "sur papier"? J'ai personnellement vu cela à quelques reprises dans ma vie et je ne recommande pas de travailler dans une entreprise avec de telles habitudes. Les conversations face à face rendent la communication plus facile et plus fluide et nous permettent de donner plus d'informations. Nous pouvons utiliser des moyens de communication verbaux et non verbaux pour montrer à nos coéquipiers ce que nous pensons. C'est évidemment plus rapide que de s'envoyer un courriel.
Mais avant tout, nous devons nous faire confiance. la confiance est facilement acquise dans un environnement qui encourage la communication face à face.
C'est l'une de mes règles préférées. cela nous permet de travailler librement selon nos propres processus. Les développeurs de logiciels sont différents des autres employés. si naturellement, ils devraient être traités comme tels. Mon expérience personnelle m'a appris à ne juger personne de l'équipe de développement aussi longtemps que le travail est terminé. Les développeurs ne veulent pas créer de mauvais logiciels, et ils sont moins susceptibles de le faire si nous les laissons travailler selon leurs propres préférences. Après tout, le client est content tant que le travail qu’il a commandé est effectué correctement; ils ne se soucient pas de savoir comment cela a été fait.
Les processus agiles promeuvent le développement durable, permettant de maintenir indéfiniment un rythme constant.
Les avantages les plus connus d’Agile (tels que l’acceptation de nouvelles exigences, une réaction rapide au retour d'informations, etc.) sont largement appréciés, mais le meilleur avantage, à mon avis, est la possibilité de déterminer avec précision le temps nécessaire à un projet ou à une fonctionnalité. consommer. Après quelques livraisons, l'équipe de développement produira le numéro d'entreprise le plus précieux: la capacité. La capacité est la quantité de travail que l'équipe peut effectuer en une seule itération. Le nombre de capacités est stable après quelques itérations, et nous pouvons éviter les délais et les estimations de temps ridicules qui sont "tirés du chapeau" tout en présentant l'offre de notre société au client.
Beaucoup de gens disent que c'est impossible et la planification s'avère plus précise. Je ne suis pas d'accord; l'horaire suppose qu'il n'y aura pas d'erreurs ni de retards inévitables.
C'est un plan parfait pour une équipe parfaite, et cela n'existe pas.
L'attention continue portée à notre industrie améliore l'agilité.
Nous sommes censés évoluer et progresser. Nous devons continuer à apprendre chaque jour, car le secteur évolue à un rythme aussi rapide. À mesure que le matériel et les logiciels s’améliorent, nous devons rester à jour; sinon, on se retrouvera perdu dans la "mer du neuf" et il sera difficile de se remettre sur les rails.
Le refactoring est la solution à la plupart des problèmes. En refacturant constamment (au besoin), nous pouvons facilement appliquer de nouvelles techniques et améliorer notre architecture logicielle..
Bill Gates a dit un jour:
Si j'ai un travail compliqué à faire, je le donnerai à la personne la plus paresseuse que j'ai, car elle trouvera le moyen le plus simple de le faire..
La simplicité est la règle d'or. Cela ne signifie pas que vous devez être paresseux, mais que les développeurs compliquent leur travail la plupart du temps. Si vous ne faites que le travail souhaité par le client, sans fonctionnalités ni améliorations supplémentaires, votre charge de travail sera allégée et vous atteindrez vos objectifs. En fin de compte, c’est tout ce qui intéresse le client.
Les meilleures architectures, exigences et conceptions émergent d'équipes auto-organisées.
Nous ne sommes que des humains. on ne peut pas tout prédire.
Avez-vous déjà été dans une situation où vous avez développé une application volumineuse et prenant beaucoup de temps, et après avoir passé d'innombrables heures devant l'écran à écrire des milliers de lignes de code et à lire des articles, des tutoriels et des livres, vous vous êtes assis (e) travailler) pensait: "Maintenant, je sais comment mieux l'écrire"? Je pense que nous avons tous eu ces moments.
C’est là que la onzième règle entre en jeu. Nous avons une équipe de développeurs qui peuvent suivre les principes du développement piloté par les tests (TDD), où la refactorisation fait partie du processus. De façon magique, notre logiciel est utile, beau, bien écrit, testé et créé rapidement. Nous ne sommes que des humains. on ne peut pas tout prédire.
Tout cela vient de l'idée d'une équipe auto-organisée, où chaque membre a un rôle - non donné ou forcé - mais qui a émergé après un certain temps passé à travailler ensemble. C'est la beauté du travail d'équipe.
À intervalles réguliers, votre équipe de développement doit réfléchir à la manière de devenir plus efficace et d’ajuster son comportement en conséquence..
Cela peut nécessiter quelques cycles de développement, mais l’équipe travaillera en parfaite harmonie. Même ajouter de nouvelles personnes à cette équipe ne serait pas nuisible. Une équipe de développement agile est entièrement au service du travail. S'ils travaillent dans un environnement convivial, ils trouveront la «mélodie du travail» et vous verrez à quelle vitesse le développement logiciel peut être.
Quelques méthodologies sont dérivées de principes agiles et fondées sur ceux-ci. Je ne les décrirai pas tous car chaque méthodologie peut être traitée dans son propre article. Je vais toutefois souligner certaines des approches Agiles les plus connues. Une chose à retenir est qu’il n’existe pas de méthodologie unique pour les gouverner tous. Choisissez celui qui répond le mieux à vos besoins, et même «configurez-le» pour répondre à vos besoins spécifiques.
Créé par Ken Schwaber et Jeff Sutherland, SCRUM est un cadre orienté métier permettant de gérer les processus de développement de logiciels. Il existe de nombreux types de SCRUM. Rappelez-vous simplement que l'objectif principal est de travailler efficacement et de ne pas respecter les règles.
Créé par Kent Back, XP répertorie les meilleures pratiques que les développeurs doivent suivre lors de la création de logiciels. On l'appelle souvent “l'extension de SCRUM”. Cette méthodologie de règles orientées développement est née, SCRUM étant plutôt orienté métier..
Les deux principes principaux de Lean sont: DALAP (Décider le plus tard possible) et DAFAP (Livrer aussi vite que possible). Personnellement, je recommande de lire davantage sur cette méthodologie, car elle peut être très utile.
Il y a plus de méthodologies dans la famille Agile; J'ai simplement référencé les options les plus populaires. Si vous décidez d'utiliser Agile dans votre processus de développement, vous devez connaître la nature de ces méthodologies afin de choisir celle qui vous convient le mieux..
Les techniques agiles fonctionnent-elles vraiment?
Est-ce que les techniques Agiles fonctionnent vraiment et les méthodologies sont-elles vraiment aussi magiques que tout le monde le dit? Pas toujours.
Le problème rencontré dans les entreprises, où les méthodes Agiles n’ont donné aucun résultat (ni même empiré les choses), était une méthodologie mal choisie et un manque de conviction de la part de ses utilisateurs (membres de l’entreprise, équipe de développement, etc.). C'est pourquoi, de l'avis de l'auteur, vous devez vous assurer que toutes les personnes impliquées dans le processus comprennent les règles et savent "de quoi il s'agit."
Merci d'avoir lu!
Accentsconagua