Applicabilité de la méthodologie Agile Software Development – mêlée comme référence

0
254
DOI: ESTE ARTIGO AINDA NÃO POSSUI DOI SOLICITAR AGORA!
ARTIGO EM PDF

SILVA, Francisco Eronildo da [1]

PINTO, Aurílio Guimarães [2]

FREITAS, Caio Guimarães [3]

ALMEIDA, Cristiany Caliri de [4]

RIBEIRO, Dallas dos Santos [5]

LEITE, Francisco Canindé da Silva  [6]

OLIVIERA, Geveson de Souza [7]

MORAIS, Gilvanete Melo de [8]

PERES, Paulo Júnior de Jesus  [9]

SILVA, Francisco Eronildo da; et.al. Applicabilité de la méthodologie Agile Software Development – mêlée comme référence. Revue scientifique pluridisciplinaire de la base de connaissances. 07 edition. année 02, vol. 03. pp 05-16, octobre 2017. ISSN : 0959-2448

Résumé

Cette étude vise à analyser la vitesse à laquelle les méthodologies agiles donnent le processus de développement de logiciel, montrant comment les compagnies utilisent ces méthodes comme un moyen de réduire le temps et efforts dans le développement de logiciels, en prenant comme faire référence à la méthodologie SCRUM. La partie de la méthodologie agile de la prémisse sur laquelle les résultats doivent être atteint rapidement sans compromettre la qualité du produit final (logiciel), en conséquence le SCRUM est une méthode qui vise à améliorer la planification des projets de logiciels dont le principe est casser le produit en petits morceaux et offrent donc les fonctionnalités sans client attendre trop longtemps pour les voir. Parmi les auteurs ont cherché à la Constitution de ce travail, conceptuel souligne Aragon Fernandes (2014), Somerville (2007), Roger Pressman (2011), Kim Pries (2010) et Ken Schwaber (2014). Les principales conclusions sont que l’utilisation de méthodologies agiles peut donner rapide software development, montrant plus d’efficacité, dynamisme et offrant des avantages aux entreprises qui adoptent la méthode, ces faits, démontrés dans cet ouvrage.

Mots clés: Agile, Scrum, gouvernance, génie logiciel.

1. Introduction

L’agile a commencé à avoir l’accent sur le 80. Le site DEVMEDIA dit : « méthodologies agiles ont été autour pendant les années, depuis les 80, mais certaines informations passent par distorsion, ce qui rendait difficile au début l’utilisation de méthodologies. Par conséquent, les développeurs sont venus à comprendre la méthodologie agile comme quelque chose qui peut, en d’autres termes, nous pouvons développer sans documentation, sans valeur par défaut et négligemment. Ce n’est pas vrai, les méthodologies agiles peuvent assurer la réussite du projet et sont utilisés dans l’industrie. » Ce travail démontre que le célèbre tuer agile axée sur les auteurs l’organisation et le soin nécessaire que le projet de logiciel doivent être efficients et efficaces, et tous les jours, vous obtenez le développement de logiciels du marché, utilisés dans les industries et organismes publics qui embauchent des usines externalisées à développer leurs systèmes.

Cette étude se contente pour montrer les avantages agiles apporte au développement de logiciels. Par exemple si vous avez le modus operandi de la CIT-s, société de logiciels qui opère dans le marché intérieur et l’adoption de la méthodologie de développement logiciel commun, mais qui est en fonction sur le client, en optant pour la méthodologie agile.

L’inspection générale de la zone de libre-échange de Manaus-SUFRAMA, qui, par le biais d’appel d’offres, engagé au service de CTI et opté pour le passage à la méthodologie agile.

SUFRAMA est une autorité fédérale responsable de la gestion des incitations fiscales. La plupart de leurs systèmes est critique et opèrent avec restrictions, donc offres le service de l’usine logicielle pour travailler avec les méthodes agiles. L’option pour les méthodes agiles en raison de la livraison rapide et de qualité parce que l’engessava traditionnel, la méthodologie du processus.

La méthode agile distribue avec une pile de papier, met l’accent sur la qualité du produit, parce que ce qui importe pour le client est le fonctionnement du logiciel.

Est-ce pas entrer dans les détails du changement dans la méthodologie adoptée par SUFRAMA et oui, illustrer que diverses industries et organismes gouvernementaux, optent pour le changement de votre modèle de développement de logiciels pour la méthodologie Agile.

En dépit d’être une option pour le développement logiciel, méthodologie agile, qui offre divers avantages au développement certainement peut ne pas convenir pour tous les projets. Pour une meilleure compréhension du sujet, vous devez examiner l’histoire du développement agile.

L’objectif général de ce travail est de faire un examen systématique de la méthodologie agile. La méthode SCRUM sera l’objet de cette étude, où ils seront répertoriés les négatifs et positifs.

Cette recherche est justifiée par la nécessité que l’industrie du logiciel doit effectuer des livraisons de produits avec le moins possible de temps à leurs clients, sans perdre de vue la qualité, l’économie et la satisfaction.

La méthodologie de cette étude est la recherche descriptive et explicative, ayant comme la collecte des données bibliographiques.

2. Développement

Cette étude débute en examinant le concept de logiciel qui a été proposé en 1968, lors d’une conférence organisée pour discuter de ce qu’on appelait alors la « crise du logiciel ». La crise du logiciel a entraîné indirectement l’introduction d’un nouveau matériel informatique basée sur des circuits intégrés. La demande de circuits intégrés, d’applications informatiques, a examiné les propositions pas réalisables et viables. Le logiciel qui en résulte a été plus grande et plus complexe que les précédents systèmes logiciels (SOMMERVILLE, 2007).

Génie logiciel est une branche de l’ingénierie, dont l’objectif est de développer au sein des systèmes de logiciels de haute qualité appropriée des coûts. Génie logiciel est une technologie de couches, impliquant des outils, de méthodes, de processus et de mettre l’accent sur la qualité. (SOMERVILLE, 2007). Toute démarche d’ingénierie (y compris les logiciels) doit reposer sur un engagement organisationnel envers la qualité.

Total de gestion de la qualité Six Sigma1 (GYGI ; DECARLO ; WILLIAMS, 2008) et philosophies similaires, ils favorisent une culture de processus d’amélioration continue et c’est cette culture qui, en fin de compte, conduit à l’élaboration d’approches plus efficaces en génie logiciel. La pierre angulaire qui prend en charge l’ingénierie logicielle est l’accent mis sur la qualité (PRESSMAN, 2011).

En ce qui concerne l’histoire du développement agile, le même a commencé en 2001, avec le « Manifesto for Agile software development », qui a été signé par Kent Beck, un ingénieur en logiciel informatique, créateur de l’Extreme Programming et piloté par les tests et seize ans plus renommés développeurs. Détails de ce fait peuvent être vérifiées à l’adresse https://www.agilealliance.org/agile101/the-agile-manifesto/.

Le manifeste met l’accent sur individus et les interactions entre les processus et les outils ; le logiciel s’exécutant plus d’une documentation complète, collaboration avec le client plutôt que négociation de contrats et les réponses pour changer à la suite d’un plan.

Cela ne prend pas loin l’importance de la documentation ou des procédés et en aucun cas concernent l’inefficacité des outils, des moyens, cependant, que la fourniture du logiciel est plus valorisée, comme déclarant Pressman :

« Le génie logiciel agile mêle philosophie avec un ensemble de principes de développement. La philosophie prône la satisfaction de la clientèle et la livraison avant l’ajout ; projet de petite équipes et motivées ; méthodes informelles ; artefacts minimale de génie logiciel et, surtout, simplicité de développement général. Les principes de l’élaboration hiérarchiser livraison plus d’analyse et de conception (bien que ces activités ne sont pas découragées) ; également donner la priorité à la communication active et continue entre les développeurs et les clients «. (Pressman, 2011)

Un projet implique les gens et les changements, surtout quand il s’agit de livraisons. De cette façon les méthodologies agiles, travaillant avec des équipes très motivées, car ils sont liés directement au processus, impliqué dans toutes les parties de celui-ci, se sentant la responsabilité sur lui le succès du travail et sachant que vous avez la possibilité de soutenir les changements au cours de l’ensemble du processus de développement.

En développement agile, vous ne pouvez pas faire un plan complet avec tout ce que nous devons accomplir pour commencer puis le développement, sans contact avec le client, au lieu de cela, développé progressivement, c'est-à-dire le produit se fait progressivement et systématiquement envoyées de cette façon, tout changement nécessaire demandé par le client ou vu par les membres du projet, à tout moment au cours du développement, pas complet car cela l’endommagerait et le changement peut être effectué sans dommages majeurs, car le projet est en cours d’élaboration et n’a pas été terminé.

Les incréments initiales du système peuvent fournir une fonctionnalité de haute priorité, afin que les clients peuvent valoriser bientôt pour le développement de votre système. Clients peuvent afficher les exigences dans la pratique et spécifier des changements devront être intégrées dans les versions ultérieures du système.

De cette façon, le client peut faire plus rapidement, l’utilisation des ressources système. Ce qui prendrait des mois à être livrés au cours des semaines et peut vérifier les bogues et spécifier les nouvelles modifications ou améliorations, n’ayant ne pas besoin d’obtenir à la fin de la mise au point de voir les problèmes.

Cette méthode fournit également une meilleure connaissance du système de l’équipe, car il comprendra l’entreprise à développer, ce qui en fait, avec plus de rapidité et de précision, et en cas d’erreurs, l’équipe perdra moins de temps pour l’analyse et peut corriger l’erreur rapidement.

Selon Aguinaldo Aragon Fernandes (2014), au départ, la mêlée a été conçue avec une mise au point nette dans la réalisation de projets de développement de logiciel dans un environnement complexe. Toutefois, il a été plus en plus appliqué dans des projets de développement de produits d’autres natures «.

Aragon déclare également que :

« La mêlée se compose d’une méthode itérative et incrémentale pour gérer des projets complexes, dont l’objectif est d’assurer une livraison plus rapide et de maximiser l’adhérence aux exigences du client, de la coopération entre les membres de l’équipe et la productivité de chaque participant. Une des méthodes de ce qu’on appelle « agile » est plus répandu dans l’informatique marché, (Aragon Fernandes 2014).

Méthodologies agiles peuvent être appliqués dans les résolutions de problèmes complexes, tels que le développement de logiciels informe Schwaber :

« Projet du complexe de situations se produisent lorsque la complexité des activités intermédiaires n’autorise pas un processus défini sous contrôlé, vous pouvez générer un produits de boucle à des niveaux acceptables de qualité. La complexité d’un projet est directement proportionnelle à la complexité des exigences des clients et de la technologie en cause, ale à dépendre en grande partie les caractéristiques de chaque membre de l’équipe, compte tenu de la diversité des savoir-faire, des connaissances et des attitudes etc., qui se trouve dans n’importe quel groupe de personnes «. Schwaber (2004)

Dans des situations comme celle-ci, Schwaber recommande d’utiliser le concept de contrôle de processus empiriques, qui utilise des mécanismes comme l’auto-organisation et de sentiment d’urgence avec les piliers suivants :

« Visibilité : tous les aspects qui influent sur les résultats escomptés doivent être visibles par les processus de contrôle.

Inspection : les divers aspects du processus devraient passer par des inspections régulières afin de détecter les variations inacceptables.

Adaptation : le processus ou les produits intermédiaires doivent être ajustées après inspection pour minimiser les futures déviations plus sévères, affaire caractéristiques et les résultats sont en dehors des limites acceptables et compromettent l’acceptation du produit final. Schwaber (2004)

La mêlée est structurée dans un ensemble de pratiques menées par des équipes dans des rôles spécifiques, organisées en un flux d’activités ou d’événements de durée fixe, totalement contrôlées avec des artefacts et des règles bien définies, qui vise à obtenir des produits utilisables à des intervalles peu de temps.

Toutes pratiques de Scrum sont basées sur un « squelette » représenté par itérations successives des activités de développement, (chaque celle qui génère une augmentation du produit), inspectés et ajustés chaque jour par les membres de son propre personnel et orienté pour une liste des exigences initiales.

Au début de chaque itération, l’équipe examine ce qui doit être fait et détermine quelles fonctionnalités viable pour être livré à la fin de l’itération. L’équipe est libre d’utiliser votre meilleur effort dans le reste de l’itération et fonctionnalités à la fin du produit final construit.

La figure ci-dessous montre le flux de Scrum :

Figure 1 : le débit de la mêlée – adapté de Schwaber (2004)
Figure 1 : le débit de la mêlée – adapté de Schwaber (2004)

Un projet Scrum, toutes les responsabilités sont réparties entre trois rôles :

ProductOwner : personne chargée de gérer le produit Backlog (veiller à ce que soit visible à tous), produire et diffuser les exigences du projet, ainsi que le plan pour les livraisons successives, prioriser les résultats qui apporteront une plus grande valeur ajoutée au projet.

Scrum Master : responsable de la mise en œuvre de la méthode Scrum, aussi bien qu’enseigner à tous ceux impliqués dans les projets et s’assurer que tous suivent les règles et les pratiques.

L’équipe de mêlée : groupe développement collectivement responsable du succès de chaque itération et le projet dans son ensemble, doit être composé de personnes multidisciplinaires capables d’auto-organisation et autogestion.

Le processus prôné par Scrum couvre les éléments suivants, comme indiqué ci-dessous :

Figure 2 : éléments de Scrum – adapté de Schwaber (2004)
Figure 2 : éléments de Scrum – adapté de Schwaber (2004)

La vision : doit être préparé par ProductOwner, y compris les rejets et planifier les étapes de livraison de produit chaque Sprint, afin de maximiser le retour sur investissement du projet de développement produit.

Le Backlog de produit : aussi préparé par ProductOwner, contient une liste d’exigences fonctionnelles et non fonctionnelles, priorisés et divisé en rejets (Sprints).

La réunion de planification de Sprint : le projet est divisé en Sprints chaque trente jours civils, à être effectué une après l’autre, sans interruption. La planification est faite lors d’une réunion avec la participation de l’équipe de Scrum et de ProductOwner, à deux périodes de 4 heures chacune :

Dans la première heure est définie que la portée (« quoi ») est traitée par Sprint, grâce à la sélection des exigences produit arriéré qui sera placé sur le Backlog de Sprint.

En 4 heures de retard, la planification concrète des tâches à accomplir dans le Sprint, (« comment ») et le début officiel du Sprint, au cours de laquelle délai commence à courir le délai de 30 jours.

Sprint : la produit propre développement itération, qui a une durée fixe. Un Sprint comprend leurs réunions de planification, l’examen et rétrospective.

La mêlée quotidienne : réunion quotidienne de quinze minutes, où chaque membre de l’équipe répond aux questions suivantes :

  •  Ce que j’ai fait sur le projet depuis la dernière mêlée quotidienne ?
  • Ce que j’ai l’intention de le faire jusqu'à la prochaine mêlée quotidienne ?
  • Y a-t-il une restriction ou une entrave à la que j’ai honorer mon engagement de Sprint actuel et/ou le projet ?

En outre, l’équipe synchronise toutes les activités et les réunions du programme nécessaires à la poursuite du projet.

Détaillant un peu plus de vues parties jusqu'à présent.

Réunion d’examen du Sprint : en 4 heures, l’équipe Scrum présente à la ProductOwner (et d’autres intervenants) le travail généré en Sprint et détermine parmi eux ce qu’il faut faire dans le prochain Sprint.

La séance de Sprint rétrospective : en 3 heures, le Scrum Master encourage les membres de l’équipe d’examiner la mêlée, processus de développement de vos pratiques de naissance et le modèle de processus Scrum, afin du pour rendre plus efficace et gratifiant pour le prochain Sprint.

Selon Schwaber (2004), le Sprint planning réunions, mêlée quotidienne, l’examen et la rétrospective du Sprint sont, ensemble, les pratiques d’inspection empirique et l’adaptation de la mêlée.

Il existe deux catégories d’objets dans le contexte de la mêlée : le carnet de commandes tableaux et des graphiques qui montrent le travail qui manque encore jusqu'à la fin (nommée BurndownCharts).

Les retards sont des tables : produit arriéré se compose d’un document « vivant », développé et maintenu par ProductWoner qui, par définition, n’est jamais complète (puisqu’il y a toujours des améliorations à mettre en œuvre dans un produit jusqu'à ce qu’il est finalement retiré du circulation). Contient une liste de toutes les modifications qui seront apportées dans le produit pour les futures versions (caractéristiques, fonctions, technologies, adaptations, améliorations, corrections, etc..). ces exigences sont classés par priorité et détaillées en ce qui concerne les attributs de la description, facteurs complexes et ajustements et estimations (de l’effort et à terme) le long des futures Sprints.

Le Backlog de Sprint : définit les tâches que l’équipe Scrum doit exécuter pour créer les incréments de produit (à partir du produit Backlog) lors de l’exécution d’un Sprint. La vos détails devraient suffire pour vous d’être accompagné lors des réunions de la mêlée Dario, dans les tâches qui durent entre 4 et 16 heures.

Chaque tâche doit être documenté, au moins en ce qui concerne votre responsable, de l’État (ne pas commencées, en cours, terminé) et de la quantité d’heures de travail restant tous les jours du Sprint.

Les BurndownCharts montrent, graphiquement, le volume de travail total (autres efforts) au fil du temps, ce qui traduit votre corrélation avec la progression des équipes dans la réduction de votre travail. Peut être utilisé dans le cadre du produit Backlog (y compris tous les Sprints) ou à l’intérieur de chacun des Sprints (Sprint Burndow).

La mêlée, comme mentionnée précédemment, a été créée pour une utilisation dans des projets de logiciels dans des environnements complexes, c'est-à-dire où les exigences changent avec une certaine fréquence, ce qui peut avoir votre lunette ou votre structure de répartition du travail ou projet de WBS EAP organisé et structuré en paquets d’artefacts supplémentaires, cohérentes et utilisables, à livrer au client dans des périodes successives de quinze à trente jours chaque.

Dans un premier temps, ce concept est parfaitement applicable à n’importe quel projet ou un programme dont l’objectif est le développement de produits ou services d’une autre nature, ou même qui comporte des initiatives d’amélioration grâce à l’utilisation de méthodologies Lean, Six Sigma, etc.. En bref, le Scrum est une méthode recommandée, qui a montré l’applicabilité forte, pour les projets qui exigent la combinaison de compétences et de connaissances adaptée à une équipe et mettant en cause des efforts de collaboration.

Deuxième Pries & Quigley (2010) il sont des moyens d’adapter la mêlée pour application dans divers types de programmes et de projets complexes, tels que :

Alliant les méthodes traditionnelles de gestion de projet : peut se connecter de concepts et artefacts, tels que le WBS (structure de répartition du travail) et produit arriéré, gagné l’analyse de la valeur, le BurndowsCharts et le Plan de Communication, contrôle des réunions Sprints (planification, daily, examen, rétrospectives) etc.

Gestion de programmes complexes : adoption d’un point de presse à la mêlée, où le Backlog de produit peut être décomposé en sous l’arriéré, chacune étant consommée par votre mêlée d’équipe respectifs.

Une expertise dans les domaines fonctionnels qui dessert divers projets (par exemple, les équipes de test ou d’assurance de la qualité) : dans le produit Baclog, peut venir dans diverses conceptions et les tâches dans le carnet de commandes à un Spint, ces tâches qui s’inscrivent dans les trente jours.

Combiné avec la technologie sous la forme de « cascade » : vous pouvez fractionner le calendrier dans le modèle de durée déterminée, afin de synchroniser, par exemple, une séquence de Sprint avec un jalon (milestone) prévue dans le projet, ainsi qu’a les activités de vérification et de validation du formulaire évolution dans chaque Sprint.

Alliant l’approche Six Sigma : vous pouvez encapsuler chacune des phases de la méthodologie DMAIC (définir, mesurer, analyser, améliorer, contrôler) au Sprint, en cours d’exécution un après l’autre.

Schwaber (2004) mentionne la possibilité d’utiliser la mêlée dans un contexte de prix et le contrat Durée préfixée. Dans ces cas, l’arriéré du produit peut être utilisé non seulement pour démontrer au client que les exigences ont été comprises, mais aussi la priorité de chacun à la création de valeur a été comprise. Les exigences plus pertinents peuvent être sélectionné pour les Sprints quelques premières et les augmentations en fonctionnalité fiable chaque réunion de suivi.

Il est important de souligner que l’adoption de Scrum pour une organisation doit être faite judicieusement et qu’il y a de nombreux défis à relever.

Nous allons connecter certains points qui, si pas bien géré, peuvent compromettre l’efficacité de la méthodologie Scrum :

Il est essentiel d’avoir une équipe fonctionne bien, groupe de travail, étant donné que le succès de l’ouvrage dépend de l’effort intensif sur les compétences que chacun d’eux possède comme un différentiel ;

Il est important que chaque membre de la mêlée a un fort sentiment d’autogestion.

Garantir que les membres de l’équipe sont attribués à un seul projet.

Vous devez vous assurer de l’engagement de toutes les parties concernées (en particulier de ceux qui représentent le client).

Vous devez vous assurer que les retards sont bien documentés, il n’y a aucun malentendu entre ceux qui sont impliqués.

Il peut y avoir quelques difficultés à « atomiser » les tâches pour être placé dans chaque ligne de l’arriéré, ainsi que d’établir les dépendances entre eux, ce qui peut influer sur la planification et des progrès satisfaisants dans la mise en œuvre des Sprints.

Vous devez vous assurer que toutes les réunions (planification, quotidien, review, rétrospective) des Sprints sont transportées hors et qui la fixe fois sont effectivement remplies, au risque d’endommager le sens de la discipline, qui est cruciale pour le succès de la méthode.

Conclusion

Avant les citations de divers auteurs, est tristement célèbre pour l’agilité et la vitesse que les méthodologies agiles, en particulier la mêlée, choisie pour illustrer l’autre dans ce travail, donnent les entreprises qui embauchent des fabriques de logiciels.

Parmi les avantages, nous pouvons mettre en évidence : le plus grande souplesse dans le contrôle et la gestion de l’avancement des travaux, mettant l’accent sur le travail d’équipe et se concentrer sur des résultats rapides, une responsabilité partagée avec le groupe à l’origine d’un plus grand sens de l’engagement, des livraisons plus rapides et efficacité, raccourcir vos commentaires mettant l’accent sur la communication et en augmentant la satisfaction de la clientèle en ayant le délai de livraison de logiciels réduit, sans perdre la qualité et augmenter les profits de la société.

Références

FERNANDES, A. A. ;  ABREU, V.F. : Déploiement de la gouvernance, 4e éd., São Paulo, SP : Brasport livres et édition multimédia société Ltd., 2014.

PRESSMAN, approche professionnelle de r 2011 A du génie logiciel. Traduction Ariovaldo Griesi, Mario Moro Fecchio. 7e éd.-São Paulo, SP : MGH Editora Ltda, 2011.

PRIES, Kim H., QUIGLEI, Jon M. Scrum gestion de projets. CRC Press, 2010

SOMMERVILLE, i. génie logiciel. 8. Ed. São Paulo, Pearson Addison Wesley, 2007.

SCHWABER, Ken. Mangement de projet agile avec Scrum. Microsoft Press, 2014.

Le manifeste agile. Disponible à : <https: www.agilealliance.org/agile101/the-agile-manifesto/="">. Consulté le 21 octobre 2016.</https:>

Manifeste pour le développement logiciel Agile. Disponible à : <http: www.manifestoagil.com.br/="">.</http:> Consulté le 21 octobre 2016.

Un aperçu de la méthodologie agile. Disponible à : <http: www.devmedia.com.br/uma="" visao-geral-sobre-metodologia-agil/27944/="">.</http:> Consulté le 21 octobre 2016.

[1] Gradué en informatique, il agit comme un serveur public sur SUFRAMA, comme analyste administratif-vous.

[2] Gradué en informatique, il agit comme un serveur public sur SUFRAMA, comme analyste administratif-vous.

[3] Gradué en informatique, il agit comme un serveur public sur SUFRAMA, comme analyste administratif-vous.

[4] Diplômé en administration des affaires, agit en tant que fonctionnaire sur SUFRAMA, en tant qu’administrateur.

[5] Gradué en informatique, il agit comme un serveur public sur SUFRAMA, comme analyste administratif-vous.

[6] Gradué en informatique, il agit comme un serveur public sur SUFRAMA, comme analyste administratif-vous.

[7] Gradué en informatique, agit en tant que serveur SUFRAMA, en tant qu’analyste administratif-vous.

[8] Diplômé en économie, agit en tant que fonctionnaire sur SUFRAMA, en tant qu’économiste.

[9] Gradué en informatique, il agit comme un serveur public sur SUFRAMA, comme analyste administratif-vous.

DEIXE UMA RESPOSTA

Please enter your comment!
Please enter your name here