En janvier 2018, le
monde a vu la lumière du cadre Nexus mis à jour - un outil basé sur Scrum conçu pour le travail d'équipe sur de grands projets. Les auteurs de la méthodologie ont corrigé un certain nombre de définitions de termes et
modifié la procédure d'octroi de licences. Depuis le début de l'année, le Nexus Guide est sous licence Creative Commons. Et cela signifie que toute entreprise est libre d'utiliser Nexus (comme Scrum).
Parlons des caractéristiques de la méthodologie et de ses principaux composants.
/ photo de Sebastian Sikora CCQui et pourquoi a créé Nexus
En 1996, les développeurs Ken Schwaber et Jeffrey Sutherland ont présenté la communauté de développement logiciel agile
Scrum . Il s'agit d'un ensemble d'itérations strictement limitées dans le temps (sprints), pour lesquelles les développeurs doivent implémenter de nouvelles fonctions pour le programme.
Comme le note Jeff Sutherland, dans son livre
Scrum. Une méthode de gestion de projet révolutionnaire », Scrum permet aux équipes de développement d'atteindre une« super-efficacité »et d'augmenter la productivité de 300%.
Cependant, Scrum a un inconvénient - il est bien adapté pour travailler au sein d'une équipe (et le nombre recommandé de ses membres n'est que de sept personnes), mais il ne s'étend pas bien au-delà de ses frontières - lorsqu'il est nécessaire de coordonner le travail d'un grand nombre de personnes.
Pour rectifier la situation et aider à élargir la méthodologie, Ken Schwaber a
introduit le cadre Nexus en 2015. Nexus
permet d' éviter les problèmes fréquents de développement conjoint: difficultés à utiliser la même base de code et incohérences dans l'intégration des réalisations des différentes équipes.
Nexus utilise des approches itératives et incrémentielles pour faire évoluer les processus de développement logiciel. Chaque équipe travaille dans le cadre de son sprint, puis leurs résultats sont combinés. Cela facilite la coordination du développement de produits.
Composants Nexus
Le cadre comprend des rôles, des événements, des artefacts, ainsi que des règles qui sont familières à tout adhérent Scrum, qui unissent le tout. Dans Nexus, ces composants ont légèrement changé afin que la méthodologie puisse être appliquée dans des projets à grande échelle.
Rôles Selon la méthodologie Scrum, tous les participants au processus de développement se voient attribuer des rôles spécifiques. Ils peuvent être divisés en deux grands groupes - «porcs» et «poulets». Le premier comprend tous ceux qui sont directement impliqués dans la création de l'application: le Scrum Master, qui anime les réunions et contrôle le respect des principes de Scrum, le Product Owner (Product Owner), représentant les intérêts des utilisateurs finaux, et, en fait, l'équipe de développement (Équipe de développement).
Le deuxième groupe - «poulets» - comprend les utilisateurs finaux, les vendeurs, les consultants, etc.
Nexus a présenté le rôle de l'équipe d'intégration Nexus (NIT) pour aider à étendre la méthodologie. Il s'agit d'une équipe entière, qui comprend le propriétaire du produit, Scrum Master et des représentants des équipes Scrum. Leur tâche est d'évaluer et de prévenir les problèmes potentiels de développement d'équipe. Il
est important de
noter que les membres du NIT ne sont pas directement impliqués dans la programmation, mais donnent des recommandations sur l'application des principes Scrum et Nexus à tous les autres participants.
En général, l'introduction du NIT a contribué à améliorer la coordination entre les équipes grâce à la répartition compétente des tâches. Cependant, les membres de la communauté informatique
affirment que le nouveau rôle a également contribué à la création d'une sorte de «goulot d'étranglement» - lorsque les membres du NIT résolvent des problèmes d'organisation, l'équipe de développement reste inactive en attendant des instructions.
Artefacts. Dans Scrum, les artefacts sont compris comme un ensemble d'exigences pour la fonctionnalité du produit qui aident à organiser les activités des développeurs. Ces exigences sont décrites dans deux magazines: le backlog du projet et le backlog du sprint.
Le livret du projet répertorie les exigences générales en matière de fonctionnalités - les soi-disant
user stories , triées par ordre décroissant d'importance. Ils aident à se faire une idée de l'apparence du produit final.
Sprint Wish Journal - Une liste des fonctionnalités d'implémentation sélectionnées par le propriétaire du produit. Sur la base de cette liste, les développeurs suivent les tâches qui doivent être terminées avant la fin d'un sprint.
Dans Nexus, les équipes utilisent le Product Backlog au lieu du wishbook du projet. Pour simplifier l'interaction d'un grand nombre de développeurs, ce magazine est divisé en plusieurs parties. Chaque partie est «assignée» à l'une des équipes. Ainsi, tous les développeurs comprennent à quelles tâches de l'ensemble du projet ils sont engagés. Dans le même temps, chaque équipe conserve toujours son journal des souhaits de sprint.
Évènements. Tous les membres de l'équipe assistent aux réunions, parfois appelées le terme général «événements». Les «cochons» les dépensent quotidiennement et les «poulets» - au début et à la fin du projet ou du sprint. Des réunions sont nécessaires pour discuter du processus de développement, estimer les plans, identifier les goulots d'étranglement.
Pour améliorer la communication entre les différentes équipes, les développeurs Nexus ont ajouté quatre nouveaux types d'événements:
- Nexus Sprint Planning - à l'heure actuelle, les équipes décident qui est le mieux à même de gérer un Sprint particulier à partir du Product Backlog. Après cela, chaque équipe planifie son propre sprint, communiquant avec les autres équipes de mêlée afin que leurs tâches ne se chevauchent pas.
- Nexus Daily Scrum - utilisé pour discuter de la situation actuelle. Vous permet de planifier la journée ou de résoudre des problèmes d'intégration.
- Nexus Sprint Review - ici, les équipes partagent leurs succès à la fin de chaque sprint.
- Nexus Retrospective - ce temps est consacré à l'évaluation de l'expérience passée et à l'élaboration d'un plan pour améliorer le processus de développement à l'avenir.
Sur
la page officielle du guide Nexus, vous pouvez trouver un diagramme de l'interaction et de la séquence de tous ces événements.
Quand utiliser Nexus
Dans des projets à grande échelle. Le cadre permet d'organiser de manière transparente le travail de plusieurs équipes Scrum dans de grands projets. Par exemple, une entreprise indienne créant un logiciel de sécurité (les auteurs de Scrum n'ont pas divulgué son nom) a utilisé Scrum pendant un an pour développer ses produits. Au début, l'entreprise avait une seule équipe Scrum, mais bientôt leur nombre est passé à trois, et des problèmes ont commencé avec l'
intégration de solutions individuelles.
Ensuite, la société a invité un expert Scrum, et il a proposé de déplacer le flux de travail Scrum à un niveau multi-équipes - mettant en œuvre Nexus. Maintenant, selon la méthodologie Nexus, six équipes travaillent déjà, qui publient régulièrement de nouvelles versions de logiciels toutes les deux semaines.
Dans les grandes entreprises. Par exemple, le service informatique de Terminales Portuarios Peruanos (TPP), une compagnie maritime dans l'un des ports de la capitale du Pérou, a mis neuf mois pour publier une nouvelle version de son logiciel de base. Pour remédier à la situation, l'entreprise a essayé la méthodologie
Waterfall ,
RUP et les principes de
la gestion de projet traditionnelle . Cependant, tous n'ont pas apporté d'améliorations significatives et, dans certains cas, ont même empiré.
Ensuite, la société a décidé d'essayer Nexus. La technique a permis de réduire le temps de libération de trois fois et de libérer le produit tous les trois mois.
Nexus aide à établir une interaction entre les équipes, "dispersées" dans le monde entier. Les sprints quotidiens soutiennent un haut niveau de communication et d'implication des employés dans le projet.
Notez que bien que Nexus aide à coordonner le travail de nombreuses équipes de développement lors d'un travail sur un grand projet et à accélérer la publication des versions (comme c'est le cas avec TPP), il n'est toujours
pas en mesure de résoudre les problèmes liés à la structure interne de l'organisation. Par exemple, le cadre n'aura pas d'effet notable si les équipes n'ont pas suffisamment de spécialistes pour résoudre tous les problèmes.
Ainsi, Nexus est adapté pour travailler sur de grands projets (selon les créateurs de la méthodologie, il vous permet de gérer efficacement neuf équipes Scrum) et, avec une application appropriée, contribue à accélérer le processus de développement de 3-4 fois. Cependant, l'objectif principal de cette méthodologie est de résoudre les problèmes d'intégration, car elle
ne peut pas aider à résoudre d'autres problèmes organisationnels dans l'entreprise.
PS Quelques nouveaux articles du premier blog d'entreprise IaaS:
PS Plusieurs publications de notre chaîne Telegram :